6lo 6man 6tisch ace acme alto anima avtcore babel bess bfcpbis bfd bier bmwg calext capport cbor ccamp cdni cellar clue codec core curdle dcrup detnet dhc dime dispatch dmarc dmm dnsop dnssd doh dots dprive dtn ecrit extra grow hip homenet httpbis i2nsf i2rs ice idr insipid intarea ippm ipsecme ipwave isis jmap kitten l2sm l2tpext lamps lime lisp lmap lpwan lwig manet mboned mile mmusic modern mpls mptcp mtgvenue netconf netmod netvc nfsv4 ntp nvo3 oauth opsawg opsec ospf pals payload pce perc pim quic radext regext rmcat roll rtcweb rtgwg sacm savi secevent sfc sidr sidrops sipbrandy sipcore slim softwire spring stir suit sunset4 taps tcpinc tcpm teas tictoc tls tokbind tram trans trill tsvwg uta v6ops xrblock IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ Charter Last Modified: 2016-04-06 Current Status: Active Chairs: Gabriel Montenegro Samita Chakrabarti Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Suresh Krishnan Tech Advisor: Ralph Droms Secretary: james woodyatt 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: 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 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 Internet-Drafts: - 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-05] (21 pages) - IPv6 Backbone Router [draft-ietf-6lo-backbone-router-05] (29 pages) - IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP [draft-ietf-6lo-blemesh-02] (10 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-00] (13 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-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) - 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-09] (17 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch [draft-ietf-6lo-paging-dispatch-05] (8 pages) - Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [draft-ietf-6lo-privacy-considerations-04] (10 pages) - An Update to 6LoWPAN ND [draft-ietf-6lo-rfc6775-update-11] (35 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-03] (27 pages) - Packet Delivery Deadline time in 6LoWPAN Routing Header [draft-lijo-6lo-expiration-time-04] (13 pages) - An Update to 6LoWPAN ND [draft-thubert-6lo-rfc6775-update-01] (22 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) * Updates RFC4944 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) * Updates RFC4944 * Updates RFC6282 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) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2016-04-06 Current Status: Active Chairs: Ole Troan Robert M. Hinden Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Suresh Krishnan 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: - 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) - 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) - 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) - 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) - 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) - 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) - The Line-Identification Option [draft-ietf-6man-lineid-08] (17 pages) - Support for adjustable maximum router lifetimes per-link [draft-ietf-6man-maxra-04] (6 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) - IPv6 ND PIO Flags IANA considerations [draft-ietf-6man-ndpioiana-02] (3 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) - 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) - IPv6 Node Requirements [draft-ietf-6man-rfc6434-bis-02] (40 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-08] (35 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) - 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: RFC5172: Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol (7 pages) * Obsoletes RFC2472 RFC5453: Reserved IPv6 Interface Identifiers (6 pages) RFC5722: Handling of Overlapping IPv6 Fragments (6 pages) * Updates RFC2460 * Updates RFC6946 RFC5871: IANA Allocation Guidelines for the IPv6 Routing Header (3 pages) * Updates RFC2460 RFC5942: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes (11 pages) * Updates RFC4861 RFC5952: A Recommendation for IPv6 Address Text Representation (14 pages) * Updates RFC4291 RFC6106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) * Obsoletes RFC5006 * Obsoletes RFC8106 RFC6164: Using 127-Bit IPv6 Prefixes on Inter-Router Links (8 pages) * Updates RFC6547 RFC6434: IPv6 Node Requirements (30 pages) * Obsoletes RFC4294 RFC6436: Rationale for Update to the IPv6 Flow Label Specification (13 pages) RFC6437: IPv6 Flow Label Specification (15 pages) * Updates RFC2205 * Updates RFC2460 * Obsoletes RFC3697 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) * Obsoletes RFC3627 * Updates RFC6164 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) * Updates RFC2460 RFC6724: Default Address Selection for Internet Protocol Version 6 (IPv6) (32 pages) * Obsoletes RFC3484 RFC6788: The Line-Identification Option (17 pages) RFC6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (10 pages) * Updates RFC3986 RFC6935: IPv6 and UDP Checksums for Tunneled Packets (12 pages) * Updates RFC2460 RFC6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums (40 pages) RFC6946: Processing of IPv6 "Atomic" Fragments (9 pages) * Updates RFC2460 * Updates RFC5722 RFC6957: Duplicate Address Detection Proxy (16 pages) RFC6980: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery (10 pages) * Updates RFC3971 * Updates RFC4861 RFC7045: Transmission and Processing of IPv6 Extension Headers (10 pages) * Updates RFC2780 * Updates RFC2460 RFC7048: Neighbor Unreachability Detection Is Too Impatient (8 pages) * Updates RFC4861 RFC7078: Distributing Address Selection Policy Using DHCPv6 (12 pages) RFC7112: Implications of Oversized IPv6 Header Chains (8 pages) * Updates RFC2460 RFC7136: Significance of IPv6 Interface Identifiers (10 pages) * Updates RFC4291 RFC7217: A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) (19 pages) RFC7346: IPv6 Multicast Address Scopes (6 pages) * Updates RFC4291 * Updates RFC4007 RFC7371: Updates to the IPv6 Multicast Addressing Architecture (10 pages) * Updates RFC3306 * Updates RFC3956 * Updates RFC4291 RFC7421: Analysis of the 64-bit Boundary in IPv6 Addressing (24 pages) RFC7527: Enhanced Duplicate Address Detection (11 pages) * Updates RFC4429 * Updates RFC4861 * Updates RFC4862 RFC7559: Packet-Loss Resiliency for Router Solicitations (6 pages) * Updates RFC4861 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) * Updates RFC4861 RFC8064: Recommendation on Stable IPv6 Interface Identifiers (9 pages) * Updates RFC2464 * Updates RFC2467 * Updates RFC2470 * Updates RFC2491 * Updates RFC2492 * Updates RFC2497 * Updates RFC2590 * Updates RFC3146 * Updates RFC3572 * Updates RFC4291 * Updates RFC4338 * Updates RFC4391 * Updates RFC5072 * Updates RFC5121 RFC8096: The IPv6-Specific MIB Modules Are Obsolete (65 pages) * Obsoletes RFC2452 * Obsoletes RFC2454 * Obsoletes RFC2465 * Obsoletes RFC2466 RFC8106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) * Obsoletes RFC6106 RFC8200: Internet Protocol, Version 6 (IPv6) Specification (42 pages) * Obsoletes RFC2460 RFC8201: Path MTU Discovery for IP version 6 (19 pages) * Obsoletes RFC1981 STD86: Internet Protocol, Version 6 (IPv6) Specification (42 pages) * Obsoletes RFC2460 STD87: Path MTU Discovery for IP version 6 (19 pages) * Obsoletes RFC1981 IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) -------------------------------------------------- Charter Last Modified: 2016-04-06 Current Status: Active Chairs: Pascal Thubert Thomas Watteyne Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Suresh Krishnan 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: 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 Oct 2017 - Initial submission of draft-ietf-6tisch-6top-sf0 to the IESG Feb 2018 - Initial submission of draft-ietf-6tisch-minimal-security to the IESG Oct 2018 - Initial submission of 6TiSCH terminology to the IESG Oct 2018 - Initial submission of draft-ietf-6tisch-dtsecurity-zerotouch-join to the IESG Nov 2018 - Initial submission of 6TiSCH architecture to the IESG Dec 2018 - Evaluate WG progress, propose new charter to the IESG Dec 2018 - 6TiSCH architecture and terminology in RFC publication queue Internet-Drafts: - 6TiSCH Operation Sublayer (6top) Interface [draft-ietf-6tisch-6top-interface-04] (34 pages) - 6top Protocol (6P) [draft-ietf-6tisch-6top-protocol-09] (45 pages) - 6TiSCH 6top Scheduling Function Zero (SF0) [draft-ietf-6tisch-6top-sf0-05] (14 pages) - 6TiSCH 6top Scheduling Function Zero / Experimental (SFX) [draft-ietf-6tisch-6top-sfx-00] (14 pages) - An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4 [draft-ietf-6tisch-architecture-13] (53 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-01] (33 pages) - Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration [draft-ietf-6tisch-minimal-21] (28 pages) - Minimal Security Framework for 6TiSCH [draft-ietf-6tisch-minimal-security-04] (23 pages) - Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e [draft-ietf-6tisch-terminology-09] (11 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) - 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) Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- Charter Last Modified: 2017-10-29 Current Status: Active Chairs: Benjamin Kaduk Jim Schaad Security Area Directors: Kathleen Moriarty Eric Rescorla Security Area Advisor: Kathleen Moriarty 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: 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. May 2016 - Submit "An Architecture for Authorization in Constrained Environments" to the IESG for publication as a Informational RFC. Sep 2016 - Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard. Internet-Drafts: - An architecture for authorization in constrained environments [draft-ietf-ace-actors-06] (33 pages) - CBOR Web Token (CWT) [draft-ietf-ace-cbor-web-token-12] (25 pages) - Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) [draft-ietf-ace-cwt-proof-of-possession-01] (14 pages) - Datagram Transport Layer Security (DTLS) Profiles for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-dtls-authorize-02] (17 pages) - Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-oauth-authz-09] (66 pages) - OSCORE profile of the Authentication and Authorization for Constrained Environments Framework [draft-ietf-ace-oscore-profile-00] (16 pages) - Use Cases for Authentication and Authorization in Constrained Environments [draft-ietf-ace-usecases-10] (30 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) Automated Certificate Management Environment (acme) --------------------------------------------------- Charter Last Modified: 2017-09-07 Current Status: Active Chairs: Rich Salz Yoav Nir Security Area Directors: Kathleen Moriarty Eric Rescorla Security Area Advisor: Kathleen Moriarty 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: Aug 2015 - Initial working group draft Mar 2016 - Submit working group draft to IESG as Proposed Standard Internet-Drafts: - Automatic Certificate Management Environment (ACME) [draft-ietf-acme-acme-09] (80 pages) - CAA Record Extensions for Account URI and ACME Method Binding [draft-ietf-acme-caa-03] (9 pages) - Extensions to Automatic Certificate Management Environment for end user S/MIME certificates [draft-ietf-acme-email-smime-01] (4 pages) - Extensions to Automatic Certificate Management Environment for email TLS [draft-ietf-acme-email-tls-02] (7 pages) - ACME IP Identifier Validation Extension [draft-ietf-acme-ip-01] (7 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 Automated Certificate Management Environment (ACME) [draft-ietf-acme-star-02] (19 pages) - ACME Identifiers and Challenges for Telephone Numbers [draft-ietf-acme-telephone-01] (8 pages) - CA Account URI Binding for CAA Records [draft-landau-acme-caa-01] (8 pages) No Requests for Comments Application-Layer Traffic Optimization (alto) --------------------------------------------- Charter Last Modified: 2016-04-18 Current Status: Active Chairs: Jan Seedorf Vijay K. Gurbani Transport Area Directors: Spencer Dawkins Mirja Kühlewind Transport Area Advisor: Mirja Kühlewind 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: Done - Submit deployment considerations document to IESG as Informational Mar 2017 - Submit cost property extension document Jul 2017 - Submit partial updates document Jul 2017 - Submit server-initiated notifications document Jul 2017 - Submit endpoing property extension document Nov 2017 - Submit network graph format document Nov 2017 - Submit alternative server discovery document Nov 2017 - Recharter or dissolve working group Nov 2017 - Submit alto service for CDNI FCI objects Internet-Drafts: - Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO [draft-ietf-alto-cdni-request-routing-alto-00] (12 pages) - ALTO Cost Calendar [draft-ietf-alto-cost-calendar-03] (26 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-08] (39 pages) - Multi-Cost Application-Layer Traffic Optimization (ALTO) [draft-ietf-alto-multi-cost-10] (29 pages) - ALTO Extension: Path Vector Cost Type [draft-ietf-alto-path-vector-02] (26 pages) - ALTO Performance Cost Metrics [draft-ietf-alto-performance-metrics-03] (29 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) - Extensible Property Maps for the ALTO Protocol [draft-ietf-alto-unified-props-new-01] (28 pages) - Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery [draft-ietf-alto-xdom-disc-01] (32 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) Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- Charter Last Modified: 2017-11-27 Current Status: Active Chairs: Sheng Jiang Toerless Eckert Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Benoit Claise 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: Autonomic networking refers to the self-managing characteristics (configuration, protection, healing, and optimization) of distributed network elements, adapting to unpredictable changes while hiding intrinsic complexity from operators and users. Autonomic Networking, which often involves closed-loop control, is applicable to the complete network (functions) lifecycle (e.g. installation, commissioning, operating, etc). An autonomic function that works in a distributed way across various network elements is a candidate for protocol design. Such functions should allow central guidance and reporting, and co-existence with non-autonomic methods of management. The general objective of this working group is to enable the progressive introduction of autonomic functions into operational networks, as well as reusable autonomic network infrastructure, in order to reduce the OpEx. This work builds on definitions and design goals, as well as a simple architecture model undertaken in the Network Management Research Group (NMRG) of the IRTF (See draft-irtf-nmrg-an-gap-analysis and its companion draft-irtf-nmrg-autonomic-network-definitions). Elements of autonomic functions already exist today. However, all such functions today have their own discovery, node identification, negotiation, transport, messaging and security mechanisms as well as non-autonomic management interfaces. There is no common infrastructure for distributed functions. This leads to inefficiencies. Additionally, management and optimisation of operational device configurations is expensive, tedious, and prone to human error. A simple example is assigning address prefixes to network segments in a large and constantly changing network. Similarly, repair or bypassing of faults requires human intervention and causes significant down time. This WG will develop a system of autonomic functions that carry out the intentions of the network operator without the need for detailed low- level management of individual devices. This will be done by providing a secure closed-loop interaction mechanism whereby network elements cooperate directly to satisfy management intent. The working group will develop a control paradigm where network processes coordinate their decisions and automatically translate them into local actions, based on various sources of information including operator-supplied configuration information or from the existing protocols, such as routing protocol, etc. While a complete solution for full autonomic networking is an ambitious goal, the initial scope of this working group's effort is much more modest: the specification of a minimum set of specific reusable infrastructure components to support autonomic interactions between devices, and to specify the application of these components to one or two elementary use cases of general value. Practically, these components should be capable of providing the following services to those distributed functions: o a common way to identify nodes o a common security model o a discovery mechanism o a negotiation mechanism to enable closed-loop interaction o a secure and logically separated communications channel o a consistent autonomic management model ANIMA and HOMENET will need to co-ordinate to ensure that the commonalities and differences in solutions are properly taken into account. Where suitable protocols, models or methods exist, they will be preferred over creating new ones. It is preferred that autonomic functions would co-exist with traditional methods of management and configuration, and the initial focus would be on self-configuration. Future work may include a more detailed systems architecture to support the development of autonomic service agents. The ANIMA working group focuses on professionally-managed networks. Like traditional network management, the topological scope of autonomic functions is expected to be limited by administrative boundaries. The goal of this working group shall be to develop one or more protocol specifications (or extensions to existing protocols) to address the following problem areas. These were selected to according to the analyzed technical gaps in draft-irtf-nmrg-an-gap-analysis: o Discovery for autonomic nodes o Negotiation for autonomic nodes Starting point: draft-carpenter-anima-gdn-protocol o Bootstrapping a trust infrastructure Starting point: draft-pritikin-anima-bootstrapping-keyinfra o Separated Autonomic Control Plane Starting point: draft-behringer-anima-autonomic-control-plane The design of these proposals should clearly target reusability. In addition, the WG will validate the application and reusability of the components to the following two use cases: o A solution for distributed IPv6 prefix management within a large-scale network. Although prefix delegation is currently supported, it relies on human action to subdivide and assign prefixes according to local requirements, and this process could become autonomic. o A solution for always-on, data plane independent connectivity between network elements (i.e., stable in the case of mis-configurations), which can be used for call home, network provisioning, or simply trouble- shooting. It is essential that these components and solutions fit together as an integrated whole. For this reason, a reference document will be developed in parallel with the individual specifications. The initial set of work items is limited to the above list to stay focused and avoid "boiling the ocean". Additional documents concerning other autonomic infrastructure components, policy intent, use cases or autonomic service agents are strongly encouraged, as individual submissions, or as submissions to the IRTF Network Network Management Research Group. Additional work items may only be added with approval from the responsible Area Director or by re-chartering. Goals and Milestones: Done - Adoption of initial drafts on AN components: Discovery and negotiation protocol(s), Bootstrap a trust infrastructure solution, Autonomic control plane solution Done - Adoption of reference model Done - Adoption of the two validation drafts Done - Submit discovery and negotiation protocol(s) to IESG (Standards Track) Apr 2016 - Submit bootstrap a trust infrastructure solution to IESG (Standards Track) Sep 2016 - Submit the two validation drafts to IESG (Informational) Sep 2016 - Submit autonomic control plane solution to IESG (Standards Track) Dec 2016 - Submit reference model to IESG (Informational) Dec 2016 - recharter to refocus scope, or close Internet-Drafts: - An Autonomic Control Plane (ACP) [draft-ietf-anima-autonomic-control-plane-13] (109 pages) - Bootstrapping Remote Secure Key Infrastructures (BRSKI) [draft-ietf-anima-bootstrapping-keyinfra-09] (69 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-00] (25 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-05] (29 pages) - Using Autonomic Control Plane for Stable Connectivity of Network OAM [draft-ietf-anima-stable-connectivity-10] (26 pages) - Voucher Profile for Bootstrapping Protocols [draft-ietf-anima-voucher-07] (22 pages) - Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) [draft-liu-anima-grasp-api-06] (25 pages) No Requests for Comments Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ Charter Last Modified: 2017-03-07 Current Status: Active Chairs: Jonathan Lennox Rachel Huang Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell 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 wide range of applications, ranging from telephony to television over IP. RTP itself has been shepherded to Full Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. As new applications have emerged, the need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications has been identified. The AVTCORE working group is chartered 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. While other working groups are chartered to work on RTCP Extended Report Extensions (XRBLOCK) and RTP Payload Formats (PAYLOAD), extensions that are generally applicable will be developed in AVTCORE. The AVTCORE working group is also chartered 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. 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: Done - Submit update for A General Mechanism for RTP Header Extensions (RFC5285) for publication as proposed standard Nov 2016 - Submit Guidelines for using the Multiplexing Features of RTP for Informational Nov 2016 - Submit Multipath RTP as experimental RFC Done - Submit Mechanism for Layer Refresh Request for Proposed Standard Jul 2017 - Submit RTP Header Extension for Video Frame Information for Proposed Standard Apr 2018 - Submit Feedback Mechanism for RTP Congestion Control 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-00] (10 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) - Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams [draft-ietf-avtcore-multiplex-guidelines-05] (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) - 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-06] (11 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) * Updates RFC2198 * Updates RFC4102 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) * Updates RFC3711 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) * Updates RFC3551 RFC7022: Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) (10 pages) * Obsoletes RFC6222 * Updates RFC3550 RFC7164: RTP and Leap Seconds (9 pages) * Updates RFC3550 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) * Obsoletes RFC5117 RFC7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) (48 pages) RFC7983: Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) (13 pages) * Updates RFC5764 RFC8035: Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing (7 pages) * Updates RFC5761 RFC8083: Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions (25 pages) * Updates RFC3550 RFC8108: Sending Multiple RTP Streams in a Single RTP Session (29 pages) * Updates RFC3550 * Updates RFC4585 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) * Obsoletes RFC5285 Babel routing protocol (babel) ------------------------------ Charter Last Modified: 2016-06-17 Current Status: Active Chairs: Donald E. Eastlake 3rd Russ White Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Alia Atlas 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. To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model to support management of home gateway routers is required as part of moving Babel to Proposed Standard. 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. - 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: Jul 2016 - WG adoption of Babel Applicability draft Jul 2016 - WG adoption of RFC6126bis Oct 2016 - WG adoption of Babel Management (Info Model & YANG Model) draft Jul 2017 - IESG Submission of RFC6126bis and potentially companion security mechanisms draft (Proposed Standard) Jul 2017 - IESG Submission of Babel Management draft (Proposed Standard) Aug 2017 - IESG Submission of Babel Applicability draft (Informational) 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-01] (5 pages) - Babel Information Model [draft-ietf-babel-information-model-01] (10 pages) - The Babel Routing Protocol [draft-ietf-babel-rfc6126bis-04] (59 pages) - Source-Specific Routing in Babel [draft-ietf-babel-source-specific-03] (11 pages) No Requests for Comments BGP Enabled ServiceS (bess) --------------------------- Charter Last Modified: 2017-12-01 Current Status: Active Chairs: Martin Vigoureux Stephane Litkowski Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Alvaro Retana 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: 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 Feb 2015 - Submit specification of BGP-signaled end-system IP/VPNs to IESG as PS Apr 2015 - Submit specification of BGP as an MVPN PE-CE protocol to IESG as PS Jun 2015 - 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 Jul 2015 - Submit specifications for VPLS multi-homing 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 Nov 2015 - Submit specifications for TRILL/E-VPN interoperability to IESG as PS Dec 2015 - Submit E-VPN OAM to IESG as PS Jun 2016 - Submit a Yang or SMI datamodel for RFC4364 to IESG as PS Jun 2016 - Submit a Yang or SMI datamodel for E-VPN 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) - 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) - Updated processing of control flags for BGP VPLS [draft-ietf-bess-bgp-vpls-control-flags-03] (8 pages) - Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection [draft-ietf-bess-datacenter-gateway-00] (11 pages) - Interconnect Solution for EVPN Overlay networks [draft-ietf-bess-dci-evpn-overlay-07] (26 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) - Updates on EVPN BUM Procedures [draft-ietf-bess-evpn-bum-procedure-updates-02] (17 pages) - A new Designated Forwarder Election for the EVPN [draft-ietf-bess-evpn-df-election-03] (15 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) - IGMP and MLD Proxy for EVPN [draft-ietf-bess-evpn-igmp-mld-proxy-00] (25 pages) - Integrated Routing and Bridging in EVPN [draft-ietf-bess-evpn-inter-subnet-forwarding-03] (27 pages) - Propagation of IPv6 Neighbor Advertisement Flags in EVPN [draft-ietf-bess-evpn-na-flags-00] (6 pages) - Optimized Ingress Replication solution for EVPN [draft-ietf-bess-evpn-optimized-ir-02] (24 pages) - A Network Virtualization Overlay Solution using EVPN [draft-ietf-bess-evpn-overlay-11] (31 pages) - Preference-based EVPN DF Election [draft-ietf-bess-evpn-pref-df-00] (12 pages) - IP Prefix Advertisement in EVPN [draft-ietf-bess-evpn-prefix-advertisement-09] (33 pages) - Operational Aspects of Proxy-ARP/ND in EVPN Networks [draft-ietf-bess-evpn-proxy-arp-nd-03] (22 pages) - Usage and applicability of BGP MPLS based Ethernet VPN [draft-ietf-bess-evpn-usage-07] (30 pages) - (PBB-)EVPN Seamless Integration with (PBB-)VPLS [draft-ietf-bess-evpn-vpls-seamless-integ-00] (10 pages) - Virtual Private Wire Service Support in Ethernet VPN [draft-ietf-bess-evpn-vpws-14] (17 pages) - Yang Data Model for EVPN [draft-ietf-bess-evpn-yang-03] (27 pages) - Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels [draft-ietf-bess-fat-pw-bgp-03] (10 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-13] (20 pages) - YANG Data Model for MPLS-based L2VPN [draft-ietf-bess-l2vpn-yang-07] (47 pages) - Yang Data Model for BGP/MPLS L3 VPNs [draft-ietf-bess-l3vpn-yang-02] (22 pages) - Multicast VPN State Damping [draft-ietf-bess-multicast-damping-06] (18 pages) - Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels [draft-ietf-bess-mvpn-bidir-04] (34 pages) - Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication [draft-ietf-bess-mvpn-bidir-ingress-replication-04] (8 pages) - Explicit Tracking with Wild Card Routes in Multicast VPN [draft-ietf-bess-mvpn-expl-track-06] (16 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-02] (18 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-05] (40 pages) - BGP as an MVPN PE-CE Protocol [draft-ietf-bess-mvpn-pe-ce-01] (12 pages) - BGP Control Plane for NSH SFC [draft-ietf-bess-nsh-bgp-control-plane-02] (53 pages) - Covering Prefixes Outbound Route Filter for BGP-4 [draft-ietf-bess-orf-covering-prefixes-06] (21 pages) - Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags [draft-ietf-bess-pta-flags-03] (7 pages) - Service Chaining using Virtual Networks with BGP VPNs [draft-ietf-bess-service-chaining-03] (41 pages) - Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) [draft-ietf-bess-spbm-evpn-02] (11 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-01] (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) - 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) - 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) - 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) - 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) - (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) - 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) - 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) Requests for Comments: RFC7441: Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes (10 pages) * Updates RFC6514 RFC7543: Covering Prefixes Outbound Route Filter for BGP-4 (21 pages) RFC7582: Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels (34 pages) * Updates RFC6513 * Updates RFC6514 * Updates RFC6625 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) * Updates RFC6514 RFC7900: Extranet Multicast in BGP/IP MPLS VPNs (65 pages) * Updates RFC6513 * Updates RFC6514 * Updates RFC6625 RFC7902: Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags (7 pages) * Updates RFC6514 RFC7988: Ingress Replication Tunnels in Multicast VPN (23 pages) * Updates RFC6513 * Updates RFC6514 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) * Updates RFC7385 Binary Floor Control Protocol Bis (bfcpbis) ------------------------------------------- Charter Last Modified: 2017-08-01 Current Status: Active Chairs: Charles Eckel Keith Drage Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach 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 Nov 2016 - 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-18] (23 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: 2015-10-26 Current Status: Active Chairs: Jeffrey Haas Reshad Rahman Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Alvaro Retana 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: 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 Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit a BFD MIB extension in support of the generic keying document 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 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 Apr 2016 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Apr 2016 - Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard Dec 2016 - Submit a BFD Yang module to the IESG to be considered as a Proposed Standard Internet-Drafts: - BFD Stability [draft-ashesh-bfd-stability-05] (6 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) - 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) - BFD for Multipoint Networks [draft-ietf-bfd-multipoint-13] (18 pages) - BFD Multipoint Active Tails. [draft-ietf-bfd-multipoint-active-tail-06] (17 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-04] (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-01] (6 pages) - BFD Stability [draft-ietf-bfd-stability-01] (5 pages) - Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management [draft-ietf-bfd-tc-mib-08] (11 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-00] (10 pages) - YANG Data Model for Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-yang-09] (67 pages) - BFD for Multipoint Networks [draft-katz-ward-bfd-multipoint-02] (29 pages) - Optimizing BFD Authentication [draft-mahesh-bfd-authentication-01] (7 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 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 RFC1122 * 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) * Updates RFC5880 RFC7726: Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) (7 pages) * Updates RFC5884 RFC7880: Seamless Bidirectional Forwarding Detection (S-BFD) (24 pages) * Updates RFC5880 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) Bit Indexed Explicit Replication (bier) --------------------------------------- Charter Last Modified: 2015-06-15 Current Status: Active Chairs: Greg Shepherd Tony Przygienda Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Alia Atlas 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: In conventional IP multicast forwarding, the packets of a given multicast "flow" are forwarded along a tree that has been constructed for the specific purpose of carrying that flow. This requires transit nodes to maintain state on a per-flow basis, and requires the transit nodes to participate in multicast-specific tree building protocols. The flow to which a packet belongs is determined by its IP source and destination address fields. BIER (Bit Index Explicit Replication) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast-specific tree building protocols. Within a given "BIER domain", an ingress node encapsulates a multicast data packet in a "BIER header". The BIER header identifies the packet's egress nodes in that domain. Each possible egress node is represented by a a single bit within a bitstring; to send a packet to a particular set of egress nodes, the ingress node sets the bits for each of those egress nodes, and clears the other bits in the bistring. Each packet can then be forwarded along the unicast shortest path tree from the ingress node to the egress nodes. Thus there are no per-flow forwarding entries. Due to the particular sensitivity of adding new significant functionality into the data-plane at high link speeds, the BIER work will progress as Experimental. The scope of the experiment will be documented in the output of the Working Group. As described in item (9) below, the work may become Standards Track once there is sufficient experience with the benefits and downsides of the technology. BIER is initially chartered to do experimental work on this new multicast forwarding mechanism as follows: 1) BIER architecture: The WG will publish an architecture, based upon draft-wijnands-bier-architecture-04. It will discuss the security properties of BIER. It will include the normative algorithm for how BIER packet forwarding is done. It will specify the information that is required to be in a BIER header so that a router can support BIER forwarding. 2) BIER encapsulation: The working group should assume that the technology will need to be embedded in the data plane and operate at very high packet line speeds. The WG will publish a document defining an MPLS-based encapsulation based upon draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need to have a high-quality and stable RFC for a new data-plane encapsulation, the MPLS-based encapsulation draft shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. As a secondary focus, the WG may also work on one non-MPLS data-plane encapsulation. This draft also shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. This draft must focus on and include the following details: a) What is the applicability of the encapsulation and for which use-cases is this encapsulation required? b) Does this proposed encapsulation imply any changes to the MPLS-based encapsulation? c) What design choices have been made for the encapsulation type and the included fields. d) The proposed encapsulation with considerations given to at least OAM, Class of Service, security, fragmentation, TTL. 3) Transition Mechanisms: The WG will describe how BIER can be partially deployed and still provide useful functionality. A minimum of the necessary mechanisms to support incremental deployment and/or managing different BIER mask-length compatibility may be defined. Each such mechanism must include an applicability statement to differentiate its necessity from other proposed mechanisms. 4) Applicability Statements: The WG will describe how BIER can be applied to multicast L3VPN and to EVPN. This draft will describe what mechanism is used to communicate the group membership between the ingress router and the egress routers, what scalability considerations may arise, and any deployment considerations. The WG will work on additional applicability statements, as needed, describing how BIER can be applied; for example, this may be needed to clarify how a non-MPLS data-plane encapsulation would be used. 5) Use Case: The WG may produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases. This would be based upon draft-kumar-bier-use-cases-01. 6) 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. 7) Management models: The WG may work on YANG models and, if needed, MIB modules to support common manageability. 8) IGP extensions. When a BIER domain falls within a "link state IGP"" network, the information needed to set up the BIER forwarding tables (e.g., the mapping between a given bit position and a given egress router) may be carried in the link state advertisements of the IGP. The link state advertisments may also carry other information related to forwarding (e.g., the IGP may support multiple topologies, in which case it may be necessary to advertise which topologies are to be used for BIER forwarding). Any necessary extensions to the IGP will be specified by the WG as Experimental, in cooperation with the ISIS and OSPF WGs. 9) Deployment Evaluation: Once there is deployment experience, the WG will produce an Informational RFC describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms. Ideally, this should also contain an analysis of the impact and benefit of the new BIER data-plane to the overall Internet architecture. This document is intended to be used to evaluate whether to recharter BIER to produce Standards Track RFCs. The BIER working group will coordinate with several different working groups and must include the relevant other working groups during working group last call on the relevant drafts. BIER will coordinate with MPLS on the MPLS-based encapsulation and associated MPLS-based OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions to flood BIER-related information. BIER will coordinate with BESS and IDR on the applicability of existing BGP-based mechanisms for providing multicast group membership information. BIER will coordinate with PIM on the applicability of and extensions to PIM, IGMP, and MLD to support BIER; BIER will work directly on the applicability statements, as needed. Goals and Milestones: Mar 2015 - WG Call for Adoption of draft related to BIER problem statement Mar 2015 - WG Call for Adoption of draft related to BIER MPLS encapsulation Mar 2015 - WG Call for Adoption of draft related to OSPF BIER extensions Mar 2015 - WG Call for Adoption of draft related to BIER MVPNs Mar 2015 - WG Call for Adoption of draft related to ISIS BIER ranges Mar 2015 - WG Call for Adoption of draft related to BIER use cases Mar 2015 - WG Call for Adoption of draft related to BIER OAM Jul 2015 - WG Call for Adoption of draft related to BIER Transition Mechanisms Jul 2015 - WG Call for Adoption of draft related to BIER YANG Model / MIB Aug 2015 - WG Last Call on draft related to BIER problem statement Aug 2015 - WG Last Call on draft related to OSPF BIER extensions Aug 2015 - WG Last Call on draft related to ISIS BIER ranges Dec 2024 - WG Call for Adoption of draft related to BIER deployment experience Dec 2024 - WG Last Call on draft related to BIER architecture Dec 2024 - WG Last Call on draft related to BIER MPLS encapsulation Dec 2024 - WG Last Call on draft related to BIER MVPNs Dec 2024 - WG Last Call on draft related to BIER use cases Dec 2024 - WG Last Call on draft related to BIER OAM Dec 2024 - WG Last Call on draft related to BIER Transition Mechanisms Dec 2024 - WG Last Call on draft related to BIER YANG Model / MIB Dec 2024 - WG Last Call on draft related to BIER deployment experience 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) - BGP Link-State extensions for BIER [draft-ietf-bier-bgp-ls-bier-ext-01] (8 pages) - YANG Data Model for BIER Protocol [draft-ietf-bier-bier-yang-02] (19 pages) - EVPN BUM Using BIER [draft-ietf-bier-evpn-00] (12 pages) - BGP Extensions for BIER [draft-ietf-bier-idr-extensions-04] (7 pages) - BIER support via ISIS [draft-ietf-bier-isis-extensions-06] (11 pages) - BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols [draft-ietf-bier-mld-00] (14 pages) - Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks [draft-ietf-bier-mpls-encapsulation-12] (24 pages) - Multicast VPN Using BIER [draft-ietf-bier-mvpn-09] (17 pages) - Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-oam-requirements-05] (6 pages) - OSPF Extensions for BIER [draft-ietf-bier-ospf-bier-extensions-10] (9 pages) - Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-path-mtu-discovery-03] (8 pages) - BIER Ping and Trace [draft-ietf-bier-ping-03] (25 pages) - Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-pmmm-oam-03] (7 pages) - Bit Indexed Explicit Replication (BIER) Problem Statement [draft-ietf-bier-problem-statement-00] (13 pages) - Traffic Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-arch-00] (30 pages) - BIER Use Cases [draft-ietf-bier-use-cases-06] (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) Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2017-10-03 Current Status: Active Chairs: Al Morton Sarah Banks Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: bmwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bmwg Archive: https://mailarchive.ietf.org/arch/browse/bmwg/ Description of Working Group: The Benchmarking Methodology Working Group (BMWG) will continue to produce a series of recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services. Taking a view of networking divided into planes, the scope of work includes benchmarks for the management, control, and forwarding planes. Each recommendation will describe the class of equipment, 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 detailed description of the task, as listed below. 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. The BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: BGP Control-plane Convergence Methodology (Terminology is complete): With relevant performance characteristics identified, BMWG will prepare a Benchmarking Methodology Document with review from the Routing Area (e.g., the IDR working group and/or the RTG-DIR). The Benchmarking Methodology will be Last-Called in all the groups that previously provided input, including another round of network operator input during the last call. SIP Networking Devices: Develop new terminology and methods to characterize the key performance aspects of network devices using SIP, including the signaling plane scale and service rates while considering load conditions on both the signaling and media planes. This work will be harmonized with related SIP performance metric definitions prepared by the PMOL working group. Traffic Management: Develop the methods to characterize the capacity of traffic management features in network devices, such as classification, policing, shaping, and active queue management. Existing terminology will be used where appropriate. Configured operation will be verified as a part of the methodology. The goal is a methodology to assess the maximum forwarding performance that a network device can sustain without dropping or impairing packets, or compromising the accuracy of multiple instances of traffic management functions. This is the benchmark for comparison between devices. Another goal is to devise methods that utilize flows with congestion-aware transport as part of the traffic load and still produce repeatable results in the isolated test environment. IPv6 Neighbor Discovery: Large address space in IPv6 subnets presents several networking challenges, as described in RFC 6583. Indexes to describe the performance of network devices, such as the number of reachable devices on a sub-network, are useful benchmarks to the operations community. The BMWG will develop the necessary terminology and methodologies to measure such benchmarks. In-Service Software Upgrade: Develop new methods and benchmarks to characterize the upgrade of network devices while in-service, considering both data and control plane operations and impacts. These devices are generally expected to maintain control plane session integrity, including routing connections. Quantification of upgrade impact will include packet loss measurement, and other forms of recovery behavior will be noted accordingly. The work will produce a definition of ISSU, which will help refine the scope. Liaisons will be established as needed. Data Center Benchmarking: This work will define additional terms, benchmarks, and methods applicable to data center performance evaluations. This includes data center specific congestion scenarios, switch buffer analysis, microburst, head of line blocking, while also using a wide mix of traffic conditions. Some aspects from BMWG's past work are not meaningful when testing switches that implement new IEEE specifications in the area of data center bridging. For example, throughput as defined in RFC 1242 cannot be measured when testing devices that implement three new IEEE specifications: priority-based flow control (802.1Qbb); priority groups (802.1Qaz); and congestion notification (802.1Qau). This work will update RFC1242, RFC2544, RFC2889 (and other key RFCs), and exchange Liaisons with relevant SDOs, especially at WG Last Call. VNF and Related Infrastructure Benchmarking: Benchmarking Methodologies have reliably characterized many physical devices. This work item extends and enhances the methods to virtual network functions (VNF) and their unique supporting infrastructure. A first deliverable from this activity will be a document that considers the new benchmarking space to ensure that common issues are recognized from the start, using background materials from industry and SDOs (e.g., IETF, ETSI NFV). Benchmarks for platform capacity and performance characteristics of virtual routers, switches, and related components will follow, including comparisons between physical and virtual network functions. In many cases, the traditional benchmarks should be applicable to VNFs, but the lab set-ups, configurations, and measurement methods will likely need to be revised or enhanced. Goals and Milestones: Done - Basic BGP Convergence Benchmarking Methodology to IESG Review Done - Terminology for SIP Device Benchmarking to IESG Review Done - Methodology for SIP Device Benchmarking to IESG Review Done - Draft on Traffic Management Benchmarking to IESG Review Done - Draft on In-Service Software Upgrade Benchmarking to IESG Review Aug 2016 - Draft on VNF Benchmarking Considerations to IESG Review Mar 2017 - Draft on vSwitch Benchmarking in OPNFV to IESG Review Jul 2017 - Methodology for IPv6 Transition Technologies to IESG Review Jul 2017 - Methodology for SDV Controller Benchmarking to IESG Review Jul 2017 - Terminology for SDV Controller Benchmarking to IESG Review Dec 2017 - Draft on IPv6 Neighbor Discovery to IESG Review Dec 2017 - Drafts on Data Center Benchmarking to IESG Review Internet-Drafts: - Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful [draft-ietf-bmwg-2544-as-08] (11 pages) - Framework for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-framework-00] (7 pages) - Methodology Guidelines for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-meth-09] (13 pages) - Methodology for Benchmarking Accelerated Stress with Operational EBGP Instabilities [draft-ietf-bmwg-acc-bench-meth-ebgp-00] (9 pages) - Methodology for Benchmarking Accelerated Stress with Operational Security [draft-ietf-bmwg-acc-bench-meth-opsec-00] (7 pages) - Terminology for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-term-13] (27 pages) - Methodology for ATM Benchmarking [draft-ietf-bmwg-atm-method-03] (127 pages) - Terminology for ATM Benchmarking [draft-ietf-bmwg-atm-term-00] (32 pages) - Terminology for ATM ABR Benchmarking [draft-ietf-bmwg-atm-term-abr-03] (16 pages) - 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) - 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) - 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 SDN Controller Performance [draft-ietf-bmwg-sdn-controller-benchmark-meth-07] (53 pages) - Terminology for Benchmarking SDN Controller Performance [draft-ietf-bmwg-sdn-controller-benchmark-term-07] (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-08] (26 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) * Updates RFC1242 * Updates RFC2544 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) * Updates RFC2544 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) Calendaring Extensions (calext) ------------------------------- Charter Last Modified: 2016-05-06 Current Status: Active Chairs: Daniel Migault Donald E. Eastlake 3rd Philipp Kewisch Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov 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: 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 May 2017 - Send attachment dratf to IESG Jun 2017 - Send Event Publication draft to IESG Jul 2017 - Send iCal relation draft to IESG 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) - CalDAV Managed Attachments [draft-ietf-calext-caldav-attachments-03] (36 pages) - Event Publishing Extensions to iCalendar [draft-ietf-calext-eventpub-extensions-05] (31 pages) - New Properties for iCalendar [draft-ietf-calext-extensions-05] (23 pages) - Support for iCalendar Relationships [draft-ietf-calext-ical-relations-03] (19 pages) - JSCalendar: A JSON representation of calendar data [draft-ietf-calext-jscalendar-00] (51 pages) - Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) [draft-ietf-calext-rscale-04] (21 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) * Updates RFC5545 * Updates RFC6321 * Updates RFC7265 RFC7953: Calendar Availability (24 pages) * Updates RFC4791 * Updates RFC5545 * Updates RFC6638 RFC7986: New Properties for iCalendar (23 pages) * Updates RFC5545 Captive Portal Interaction (capport) ------------------------------------ Charter Last Modified: 2017-07-10 Current Status: Active Chairs: Erik Kline Martin Thomson Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach 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: Aug 2018 - Protocol to discover and interact with a Captive Portal Aug 2018 - API for Captive Portal Interaction Internet-Drafts: - Captive Portal API [draft-ietf-capport-api-00] (6 pages) - CAPPORT Architecture [draft-ietf-capport-architecture-00] (14 pages) No Requests for Comments Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- Charter Last Modified: 2017-01-09 Current Status: Active Chairs: Francesca Palombini Joe Hildebrand Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov 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 7159) 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 will update RFC 7049 to fix verified errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for popular deployed codebases. The resulting document will be targeted at becoming 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 would be useful if protocol specifications could use a description format for the data in CBOR-encoded messages. The CBOR data definition language (CDDL, based on draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. The CBOR WG will complete the development of this specification by creating an Informational or Standards Track RFC. The document should specify its applicability statement in relationship to YANG data modelling language. In parallel to the work on CDDL, the WG will examine the CBOR extension for tagging of Typed Arrays (based on draft-jroatch-cbor-tags) and the CBOR extension for tagging of Object Identifiers and UUIDs (based on draft-bormann-cbor-tags-oid) that use CBOR's extensibility mechanisms to provide additional data types as used in certain applications. Where these proposals are deemed useful and do not require significant new development, the CBOR WG will complete these specifications as well. The WG will recharter before working on any further CBOR extensions. Goals and Milestones: May 2017 - Submit rfc7049bis to IESG as a Proposed Standard Oct 2017 - Submit CDDL to IESG as an Informational or Proposed Standard RFC Internet-Drafts: - Concise Binary Object Representation (CBOR) [draft-ietf-cbor-7049bis-01] (57 pages) - Concise data definition language (CDDL): a notational convention to express CBOR data structures [draft-ietf-cbor-cddl-01] (55 pages) No Requests for Comments Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2015-10-07 Current Status: Active Chairs: Daniele Ceccarelli Fatai Zhang Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana 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: 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 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 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) - RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) [draft-ietf-ccamp-additional-signal-type-g709v3-04] (5 pages) - YANG Alarm Module [draft-ietf-ccamp-alarm-module-00] (58 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) - 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) - A framework for Management and Control of DWDM optical interface parameters [draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-09] (29 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 DWDM networks [draft-ietf-ccamp-flexible-grid-ospf-ext-09] (18 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) - 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) - 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) - 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-05] (21 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 Radio Link [draft-ietf-ccamp-mw-yang-02] (39 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) - OSPF-Traffic Engineering Link Availability Extension for Links with Variable Discrete Bandwidth [draft-ietf-ccamp-ospf-availability-extension-13] (9 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-02] (13 pages) - OTN Tunnel YANG Model [draft-ietf-ccamp-otn-tunnel-model-01] (28 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-08] (10 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 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 Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation [draft-ietf-ccamp-wson-iv-info-05] (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 Optical Networks [draft-ietf-ccamp-wson-yang-09] (16 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-08] (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) 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 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 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) * Updates RFC3473 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 RFC3630 * 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 RFC3471 * 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) * Obsoletes RFC3946 * Updates RFC6344 RFC4631: Link Management Protocol (LMP) Management Information Base (MIB) (83 pages) * Obsoletes RFC4327 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) * Updates RFC3473 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 RFC3471 * Updates RFC4873 * Updates RFC6780 RFC4873: GMPLS Segment Recovery (25 pages) * Updates RFC3473 * Updates RFC4872 RFC4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) (27 pages) * Updates RFC3209 * Updates RFC3473 * Updates RFC6001 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 RFC3473 * 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) * Updates RFC2961 * Updates RFC3473 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) * Updates RFC3209 * Updates RFC3473 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 RFC3209 * Updates RFC3473 * Obsoletes RFC4420 * 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) * Updates RFC4202 * Updates RFC4203 * Updates RFC4206 * Updates RFC4874 * Updates RFC4974 * Updates RFC5307 RFC6002: Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions (10 pages) * Updates RFC3471 * Updates RFC3473 * Updates RFC3945 * Updates RFC4202 * Updates RFC4203 * Updates RFC5307 RFC6003: Ethernet Traffic Parameters (14 pages) * Updates RFC3471 * Updates RFC3473 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) * Updates RFC3477 * Updates RFC4206 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 RFC3471 * Updates RFC7699 RFC6344: Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) (21 pages) * Updates RFC4606 RFC6373: MPLS Transport Profile (MPLS-TP) Control Plane Framework (57 pages) RFC6387: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (11 pages) * Obsoletes RFC5467 RFC6510: Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects (8 pages) * Updates RFC4875 * Updates RFC5420 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) * Updates RFC2205 * Updates RFC3209 * Updates RFC3473 * Updates RFC4872 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) * Obsoletes RFC5787 * Updates RFC5786 RFC6898: Link Management Protocol Behavior Negotiation and Configuration Modifications (11 pages) * Updates RFC4204 * Updates RFC4207 * Updates RFC4209 * Updates RFC5818 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) * Updates RFC3471 * Updates RFC4202 * Updates RFC4203 * Updates RFC5307 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 RFC4328 * 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) * Updates RFC3471 * Updates RFC6205 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) * Updates RFC7139 RFC7963: RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) (5 pages) Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Charter Last Modified: 2017-11-21 Current Status: Active Chairs: Francois Le Faucheur Kevin J. Ma Phil Sorber Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov 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: 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 Jun 2018 - Recharter or dissolve Jun 2018 - Submit specification of URI Signing for CDNI to IESG as Proposed Standard Internet-Drafts: - 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) - 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 Distribution Network Interconnection (CDNI) Requirements [draft-ietf-cdni-requirements-17] (23 pages) - URI Signing for CDN Interconnection (CDNI) [draft-ietf-cdni-uri-signing-13] (36 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) * Obsoletes RFC3570 RFC7336: Framework for Content Distribution Network Interconnection (CDNI) (58 pages) * Obsoletes RFC3466 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) Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ Charter Last Modified: 2015-11-20 Current Status: Active Chairs: Tessa Fallon Tim Terriberry Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell 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 2017 - Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication Apr 2017 - Submit specification for EBML to IESG (Standards Track) Jul 2017 - Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication Jul 2017 - Submit specification for FFV1 video codec version 4 to IESG (Standards Track) Sep 2017 - Submit specification for Matroska container format version 4 to IESG (Standards Track) Dec 2017 - Submit specification for FLAC audio codec to IESG (Standards Track) Internet-Drafts: - Extensible Binary Meta Language [draft-ietf-cellar-ebml-04] (38 pages) - FF Video Codec 1 [draft-ietf-cellar-ffv1-01] (40 pages) - FF Video Codec 1 [draft-niedermayer-cellar-ffv1-02] (36 pages) No Requests for Comments ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Paul Kyzivat Roni Even Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Mailing Lists: General Discussion: clue@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/clue Archive: https://mailarchive.ietf.org/arch/browse/clue/ Description of Working Group: In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite. However, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of the multiple streams of audio and video comprising the media flows. The WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize user experience. This working group is chartered to specify the following information about media streams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and loudspeakers - relative to each other and to likely positions of participants * Viewpoint, field of view/capture for camera/microphone/display/loudspeaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams * Usage of the stream, for example whether the stream is presentation, or document camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection) Information between sources and sinks about media stream capabilities will be exchanged. The working group will define the semantics, syntax, and transport mechanism for communicating the necessary information. It will consider whether existing protocols for signaling, messaging and transport are adequate or need to be extended. Any extensions to IETF protocols will be done in appropriate WGs, for example extensions to SDP in MMUSIC. The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as specifying the audio and video streams for defined speakers. Specifying the location of the current speakers relative to display microphones needs to be provided dynamically as speakers move. As part of the receiver telling the sender what it wants dynamically, explicit receiver notification to the sender of the desired video stream and video pause will be considered. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on multiple RTP audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate. Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas (e.g., OPS and SEC), and working groups including AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Goals and Milestones: Done - Submit informational draft to IESG on use cases Done - Submit informational draft to IESG on requirements Done - Submit standards track draft to IESG on Framework Done - Submit standards track draft to IESG on Data Model Done - Submit standards track draft to IESG on CLUE Protocol Done - Submit standards track draft to IESG on CLUE Data Channel Done - Submit standards track draft to IESG on Usage of RTP Done - Submit standards track draft to IESG on Overall Signaling and usage of SDP Internet-Drafts: - CLUE Protocol Data Channel [draft-holmberg-clue-datachannel-04] (11 pages) - An XML Schema for the CLUE data model [draft-ietf-clue-data-model-schema-17] (77 pages) - CLUE Protocol data channel [draft-ietf-clue-datachannel-14] (14 pages) - Framework for Telepresence Multi-Streams [draft-ietf-clue-framework-25] (84 pages) - CLUE protocol [draft-ietf-clue-protocol-14] (62 pages) - Mapping RTP streams to CLUE Media Captures [draft-ietf-clue-rtp-mapping-14] (14 pages) - Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) [draft-ietf-clue-signaling-13] (41 pages) - Requirements for Telepresence Multistreams [draft-ietf-clue-telepresence-requirements-07] (12 pages) - Use Cases for Telepresence Multistreams [draft-ietf-clue-telepresence-use-cases-09] (17 pages) - CLUE Signaling [draft-kyzivat-clue-signaling-08] (41 pages) Requests for Comments: RFC7205: Use Cases for Telepresence Multistreams (17 pages) RFC7262: Requirements for Telepresence Multistreams (12 pages) Internet Wideband Audio Codec (codec) ------------------------------------- Charter Last Modified: 2015-06-15 Current Status: Active Chairs: Mo Zanaty Tim Terriberry Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell Tech Advisor: Stephan Wenger Mailing Lists: General Discussion: codec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/codec Archive: https://mailarchive.ietf.org/arch/browse/codec/ Description of Working Group: Problem Statement According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions: 1. Are optimized for use in interactive Internet applications. 2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. 3. Can be widely implemented and easily distributed among application developers, service operators, and end users. There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications. There exist codecs that can be widely implemented and easily distributed, but that are not standardized through any SDO; according to reports, this lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications. There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications. According to application developers and service operators, an audio codec that meets all three of these would: (1) enable protocol designers to more easily specify a mandatory-to-implement codec in their protocols and thus improve interoperability; (2) enable developers to more easily easily build innovative, interactive applications for the Internet; (3) enable service operators to more easily deploy affordable, high-quality audio services on the Internet; and (4) enable end users of Internet applications and services to enjoy an improved user experience. Objectives The goal of this working group is to ensure the existence of a single high-quality audio codec that is optimized for use over the Internet and that can be widely implemented and easily distributed among application developers, service operators, and end users. At present it appears that ensuring the existence of such a codec will require a development effort within the working group, however if a candidate codec is presented that achieves the goal then the working group should seriously consider stopping its development work. The core technical considerations for such a codec include, but are not necessarily limited to, the following: 1. Designing for use in interactive applications (examples include, but are not limited to, point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet as identified and prioritized by the working group 3. Ensuring interoperability and clean integration with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signaling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, the result should not depend on the details of any particular signaling technology Optimizing for very low bit rates (typically below 2.4 kbps) and for non-interactive audio is out of scope because such work might necessitate specialized optimizations. Although a codec produced by this working group or another standards organization might be used as a mandatory-to-implement technology by designers of particular Internet protocols, it is explicitly not a goal of the working group to produce or select a codec that will be mandated for use across the entire IETF or Internet community nor would their be any expectation that this would be the only mandatory-to-implement codec. Based on the working group's analysis of the design space, the working group might determine that it needs to produce more than one codec, or a codec with multiple modes; however, it is not the goal of working group to produce more than one codec, and to reduce confusion in the marketplace the working group shall endeavor to produce as few codecs as possible. In completing its work, the working group should collaborate with other IETF working groups to complete particular tasks. These might include, but would not be limited to, the following: - Within the AVT WG, define the codec's payload format for use with the Real-time Transport Protocol (RTP). - Collaborate with working groups in the Transport Area to identify important aspects of packet transmission over the Internet. - Collaborate with working groups in the Transport Area to understand the degree of rate adaptation desirable, and to reflect that understanding in the design of a codec that can adjust its transmission in a way that minimizes disruption to the audio. - Collaborate with working groups in the RAI Area to ensure that information about and negotiation of the codec can be easily represented at the signaling layer. In accordance with the liaison agreement in place, the working group will continue to coordinate with the ITU-T (Study group 16), with the intent of submitting the completed codec RFC for co-publication by the ITU-T if the ITU-T finds that appropriate. The working group will communicate a detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the requirements and goals. Information about codecs being standardized will be available to other SDOs in the form of internet drafts and the working group welcomes technical feedback from other SDOs and experts from other organizations. Suggested Codec Standardization Guidelines and Requirements for achieving the foregoing objectives are provisionally outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and, if accepted as work items of the working group, will be refined by the working group in accordance with the usual IETF procedures. A codec that can be widely implemented and easily distributed among application developers, service operators, and end users is preferred. Many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or attempt to adhere to other special conditions or restrictions. Because such encumbrances have made it difficult to widely implement and easily distribute high-quality audio codecs across the entire Internet community, the working group prefers unencumbered technologies in a way that is consistent with BCP 78 and BCP 79. In particular, the working group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use. Deliverables 1. A set of Codec Standardization Guidelines that define the work processes of the working group. This document shall be Informational. 2. A set of technical Requirements. This document shall be Informational. 3. Specification of a codec that meets the agreed-upon requirements, in the form of an Internet-Draft that defines the codec algorithm along with source code for a reference implementation. The text description of the codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that this document shall be a Proposed Standard document. Goals and Milestones: Done - WGLC on Codec Standardization Guidelines Done - WGLC on Requirements, liaise to other SDOs Done - Requirements to IESG (Informational) Done - Liaise requirements RFC to other SDOs Done - WGLC on codec specification, liaise to other SDOs Done - Codec Standardization Guidelines to IESG (Informational) Done - WGLC #2 on Codec specification Done - Submit codec specification to IESG (Standards Track) Done - Container format for OPUS codec to IESG as PS Nov 2016 - Submit Ambisonics channel mapping to IESG (Standards Track) Feb 2017 - Error and bugfix update(s) to RFC 6716 Internet-Drafts: - Ambisonics in an Ogg Opus Container [draft-ietf-codec-ambisonics-04] (8 pages) - Definition of the IETF Interactive Audio Codec [draft-ietf-codec-description-00] (12 pages) - Guidelines for Development of an Audio Codec within the IETF [draft-ietf-codec-guidelines-08] (14 pages) - Definition of the Harmony Audio Codec [draft-ietf-codec-harmony-00] (12 pages) - Ogg Encapsulation for the Opus Audio Codec [draft-ietf-codec-oggopus-14] (35 pages) - Definition of the Opus Audio Codec [draft-ietf-codec-opus-16] (326 pages) - Updates to the Opus Audio Codec [draft-ietf-codec-opus-update-10] (12 pages) - Requirements for an Internet Audio Codec [draft-ietf-codec-requirements-05] (17 pages) - Summary of Opus listening test results [draft-ietf-codec-results-03] (23 pages) Requests for Comments: RFC6366: Requirements for an Internet Audio Codec (17 pages) RFC6569: Guidelines for Development of an Audio Codec within the IETF (14 pages) RFC6716: Definition of the Opus Audio Codec (326 pages) * Updates RFC8251 RFC7845: Ogg Encapsulation for the Opus Audio Codec (35 pages) * Updates RFC5334 RFC8251: Updates to the Opus Audio Codec (12 pages) * Updates RFC6716 Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2017-04-21 Current Status: Active Chairs: Carsten Bormann Jaime Jimenez Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov 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: 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 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 Internet-Drafts: - 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-02] (23 pages) - CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets [draft-ietf-core-coap-tcp-tls-11] (51 pages) - CoAP Simple Congestion Control/Advanced [draft-ietf-core-cocoa-02] (17 pages) - CoAP Management Interface [draft-ietf-core-comi-02] (56 pages) - Dynamic Resource Linking for Constrained RESTful Environments [draft-ietf-core-dynlink-04] (16 pages) - Echo and Request-Tag [draft-ietf-core-echo-request-tag-00] (17 pages) - PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) [draft-ietf-core-etch-04] (21 pages) - Group Communication for the Constrained Application Protocol (CoAP) [draft-ietf-core-groupcomm-25] (46 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-10] (27 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-09] (19 pages) - Object Security for Constrained RESTful Environments (OSCORE) [draft-ietf-core-object-security-08] (59 pages) - Observing Resources in the Constrained Application Protocol (CoAP) [draft-ietf-core-observe-16] (30 pages) - CoRE Resource Directory: DNS-SD mapping [draft-ietf-core-rd-dns-sd-00] (10 pages) - CoRE Resource Directory [draft-ietf-core-resource-directory-12] (64 pages) - Media Types for Sensor Measurement Lists (SenML) [draft-ietf-core-senml-12] (46 pages) - YANG Schema Item iDentifier (SID) [draft-ietf-core-sid-03] (25 pages) - CBOR Encoding of Data Modeled with YANG [draft-ietf-core-yang-cbor-05] (32 pages) Requests for Comments: RFC6690: Constrained RESTful Environments (CoRE) Link Format (22 pages) RFC7252: The Constrained Application Protocol (CoAP) (112 pages) * Updates RFC7959 RFC7390: Group Communication for the Constrained Application Protocol (CoAP) (46 pages) RFC7641: Observing Resources in the Constrained Application Protocol (CoAP) (30 pages) RFC7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP) (37 pages) * Updates RFC7252 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) CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Daniel Migault Rich Salz Security Area Directors: Kathleen Moriarty Eric Rescorla Security Area Advisor: Eric Rescorla 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] (17 pages) - Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) [draft-ietf-curdle-cms-eddsa-signatures-08] (8 pages) - Deprecate 3DES and RC4 in Kerberos [draft-ietf-curdle-des-des-des-die-die-die-05] (9 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) - GSS-API Key Exchange with SHA2 [draft-ietf-curdle-gss-keyex-sha2-04] (16 pages) - Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure [draft-ietf-curdle-pkix-07] (18 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-06] (3 pages) - Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH) [draft-ietf-curdle-rsa-sha2-12] (8 pages) - Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 [draft-ietf-curdle-ssh-curves-07] (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 Ed 448 public key algorithms for the Secure Shell (SSH) protocol [draft-ietf-curdle-ssh-ed25519-ed448-00] (5 pages) - Extension Negotiation in Secure Shell (SSH) [draft-ietf-curdle-ssh-ext-info-15] (13 pages) - Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) [draft-ietf-curdle-ssh-kex-sha2-10] (16 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 new Cryptographic Algorithm Object Identifier Range [draft-schaad-curdle-oid-registry-03] (5 pages) Requests for Comments: 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) * Updates RFC4250 * Updates RFC4253 RFC8270: Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits (5 pages) * Updates RFC4419 DKIM Crypto Update (dcrup) -------------------------- Charter Last Modified: 2017-04-28 Current Status: Active Chairs: Murray Kucherawy Rich Salz Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Tech Advisor: Eric Rescorla Mailing Lists: General Discussion: dcrup@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dcrup Archive: https://mailarchive.ietf.org/arch/browse/dcrup/ Description of Working Group: The DKIM Crypto Update (DCRUP) Working Group is chartered to update DomainKeys Identified Mail (DKIM, RFC 6376) to handle more modern cryptographic algorithms and key sizes. DKIM (RFC 6376) signatures include a tag that identifies the hash algorithm and signing algorithm used in the signature. The only current algorithm is RSA, with advice that signing keys should be between 1024 and 2048 bits. While 1024 bit signatures are common, longer signatures are not because bugs in DNS provisioning software prevent publishing longer keys as DNS TXT records. DKIM also currently supports use of SHA1 coupled with RSA. SHA1 has been formally deprecated due to weakness in numerous contexts. The community wishes to discourage its continued use in the DKIM context. DCRUP will consider four types of changes to DKIM: additional signing algorithms such as those based on elliptic curves; changes to key strength advice and requirements; deprecating the use of SHA1; and new public key forms, such as putting the public key in the signature and a hash of the key in the DNS to bypass bugs in DNS provisioning software that prevent publishing longer keys as DNS TXT records. Changes will be limited to existing implemented algorithms and key forms. Other changes to DKIM, such as new message canonicalization schemes, are out of scope. The WG will as far as possible avoid changes incompatible with deployed DKIM signers and verifiers. Goals and Milestones: Oct 2017 - Agree what algorithms and key formats to add or deprecate Dec 2017 - Submit WG draft to IESG as Proposed Standard Internet-Drafts: - A new cryptographic signature method for DKIM [draft-ietf-dcrup-dkim-crypto-08] (6 pages) - Defining Elliptic Curve Cryptography Algorithms for use with DKIM [draft-ietf-dcrup-dkim-ecc-01] (7 pages) - Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) [draft-ietf-dcrup-dkim-usage-06] (5 pages) Requests for Comments: RFC8301: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) (5 pages) * Updates RFC6376 Deterministic Networking (detnet) --------------------------------- Charter Last Modified: 2017-12-01 Current Status: Active Chairs: Janos Farkas Lou Berger Patricia Thaler Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Deborah Brungard Secretary: Jouni Korhonen 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 will specify an overall architecture 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. Candidate Layer 3 data plane technologies that may be used, without modification, 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 data plane will be compatible with the work done in IEEE802.1 TSN. The Working Group's scope explicitly excludes modifications of transport protocols, OAM, Layer 3 forwarding, encapsulations, and control plane protocols. 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 to support a data plane method of flow identification and packet forwarding over Layer 3. 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 augmented base models. As needed, problem statement: This effort will establish the deployment environment and deterministic network requirements. As needed, vertical requirements: This effort will detail the requirements for deterministic networks in various industries, for example, professional audio, electrical utilities, building automation systems, wireless for industrial applications. To investigate whether existing data plane encryption mechanisms can be applied, possibly opportunistically, to improve security and privacy. The WG coordinates with other relevant IETF Working Groups, including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, and 6TisSCH. 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. The WG will liaise with appropriate groups in IEEE and other Standards Development Organizations (SDOs). WG deliverables include: Overall architecture Data plane specification Data flow information model YANG models WG sustaining/informational documents may include: These documents may not necessarily be published, but may be maintained in a draft form or on a collaborative Working Group wiki to support the efforts of the Working Group and help new comers: Problem statement and (constrained) deployment environments User-driven use cases Goals and Milestones: Dec 2015 - WG adoption of use cases Dec 2015 - WG adoption of problem statement (with supported deployments) Jan 2016 - WG adoption of architecture document Apr 2016 - WG adoption of data plane specification May 2016 - WG adoption of data flow information model Aug 2016 - WG adoption of YANG model Sep 2016 - Finalize use cases (informational) Sep 2016 - Finalize problem statement (informational) Nov 2016 - Submit architecture (Standards Track) Jan 2017 - Submit data plane specification (Standards Track) Feb 2017 - Submit data flow information model (informational) Apr 2017 - Submit YANG model (Standards Track) Apr 2017 - Re-charter or close 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) - Deterministic Networking Use Cases [draft-grossman-detnet-use-cases-01] (81 pages) - Deterministic Networking Architecture [draft-ietf-detnet-architecture-04] (41 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-01] (37 pages) - DetNet Flow Information Model [draft-ietf-detnet-flow-information-model-00] (22 pages) - Deterministic Networking Problem Statement [draft-ietf-detnet-problem-statement-02] (11 pages) - Deterministic Networking (DetNet) Security Considerations [draft-ietf-detnet-security-01] (39 pages) - Deterministic Networking Use Cases [draft-ietf-detnet-use-cases-13] (91 pages) - Deterministic Networking (DetNet) Security Considerations [draft-sdt-detnet-security-01] (35 pages) No Requests for Comments Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2016-08-10 Current Status: Active Chairs: Bernie Volz Tomek Mrugalski Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Suresh Krishnan 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 and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. 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 outside of scope for the DHC WG. Such options should be defined within their respective WGs 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. Develop extensions to the DHCPv6 infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - DHCPv6 Stateful issues - DHCPv6 Failover - DHCPv6 Load Balancing - Extending DHCPv6 to work with multiple provisioning domains - DHCP provisioning of IPv4 clients over IPv6 networks - Access Network Identifier options - DNS registration for SLAAC - Active leasequery - Secure DHCPv6 with Public Key - Dynamic Allocation of Shared IPv4 Addresses Additional topics may only be added with approval from the responsible Area Director or by re-chartering. 2. Develop documents that help explain operational considerations for the wider community. 3. Issue updated versions of the DHCP base specifications-- RFC 3315 (DHCPv6), RFC 3633 (DHCPv6 Prefix Delegation) and RFC 3736 (Stateless DHCPv6) so as to fix errata and bring the documents to the point where they can advance along the IETF Standards Track. 4. In the process of updating the DHCP base specifications, in cases where time is of the essence, issue corrections and clarifications of the specifications in order to quickly address interoperability problems. 5. Write analyses and interoperability reports on existing DHC documents, including base specs. 6. When serious interoperability problems are found in other DHCP specifications, issue updated versions of those specifications to address the interoperability problems. Goals and Milestones: Done - WG last call draft-ietf-dhc-dhcpv6-stateful-issues Done - WG last call on access-network-identifier Done - Submit stateful issues draft to IESG Failed Last Call - WG last calll on draft-ietf-dhc-addr-registration Sent to IESG - Submit dhc-sedhcpv6 draft to IESG Done - Adopt 3315bis draft Done - Submit access-network-identifier to IESG Done - WG last call draft-ietf-dhc-topo-conf Abandoned document - Submit stable-privacy-addresses to IESG Done - WG last call on DHCP privacy drafts Done - Submit DHCP privacy drafts to IESG Done - Submit draft-ietf-dhc-topo-conf to IESG Done - WG last call revised draft-ietf-dhc-dhcpv6-failover-design Done - Submit dhcpv6-failover-design to IESG Done - WG last call on 331bis draft Done - WG last call draft-ietf-dhc-relay-server-security Done - Submit draft-ietf-dhc-relay-server-security to IESG Done - Submit draft-ietf-dhc-relay-port to IESG Done - Submit 3315bis draft to IESG Internet-Drafts: - Access-Network-Identifier Option in DHCP [draft-bhandari-dhc-access-network-identifier-04] (17 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) - 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) - DHCPv4 over DHCPv6 Source Address Option [draft-ietf-dhc-dhcp4o6-saddr-opt-01] (12 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-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-05] (102 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) - 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) - 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) bis [draft-ietf-dhc-rfc3315bis-10] (141 pages) - DHCP Safe Failover Protocol [draft-ietf-dhc-safe-failover-proto-00] (29 pages) - DHCP Schema for LDAP [draft-ietf-dhc-schema-02] (23 pages) - Secure DHCPv6 Using CGAs [draft-ietf-dhc-secure-dhcpv6-07] (18 pages) - Securing DHCP [draft-ietf-dhc-securing-dhc-00] (5 pages) - Security Architecture for DHCP [draft-ietf-dhc-security-arch-01] (14 pages) - Security Requirements for the DHCP protocol [draft-ietf-dhc-security-requirements-00] (12 pages) - Secure DHCPv6 [draft-ietf-dhc-sedhcpv6-21] (31 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB [draft-ietf-dhc-server-mib-10] (37 pages) - DHCP Server Identifier Override Suboption [draft-ietf-dhc-server-override-05] (7 pages) - The Server Identification Option for DHCP [draft-ietf-dhc-sio-00] (6 pages) - 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) - 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) - 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) - 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) * Updates RFC3315 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) * Obsoletes RFC2489 RFC1531: Dynamic Host Configuration Protocol (39 pages) * Obsoletes RFC1541 RFC1532: Clarifications and Extensions for the Bootstrap Protocol (22 pages) * Updates RFC951 * Obsoletes RFC1542 RFC1533: DHCP Options and BOOTP Vendor Extensions (30 pages) * Obsoletes RFC1048 * Obsoletes RFC1084 * Obsoletes RFC1395 * Obsoletes RFC1497 * Obsoletes RFC2132 RFC1534: Interoperation Between DHCP and BOOTP (4 pages) RFC2131: Dynamic Host Configuration Protocol (45 pages) * Obsoletes RFC1541 * Updates RFC3396 * Updates RFC4361 * Updates RFC5494 * Updates RFC6842 RFC2132: DHCP Options and BOOTP Vendor Extensions (34 pages) * Obsoletes RFC1533 * 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) 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) * Obsoletes RFC2489 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 RFC3396: Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) (9 pages) * Updates RFC2131 RFC3442: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (9 pages) * Updates RFC2132 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 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) RFC3736: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 (9 pages) 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) * Updates RFC2132 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) 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 RFC2131 * Updates RFC2132 * Updates RFC3315 * 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) * Updates RFC2132 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) * Updates RFC4388 RFC6221: Lightweight DHCPv6 Relay Agent (17 pages) * Updates RFC3315 RFC6355: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) (5 pages) RFC6422: Relay-Supplied DHCP Options (8 pages) * Updates RFC3315 RFC6603: Prefix Exclude Option for DHCPv6-based Prefix Delegation (10 pages) * Updates RFC3633 RFC6607: Virtual Subnet Selection Options for DHCPv4 and DHCPv6 (26 pages) * Updates RFC3046 RFC6644: Rebind Capability in DHCPv6 Reconfigure Messages (10 pages) * Updates RFC3315 RFC6656: Description of Cisco Systems' Subnet Allocation Option for DHCPv4 (24 pages) RFC6704: Forcerenew Nonce Authentication (12 pages) * Updates RFC3203 RFC6842: Client Identifier Option in DHCP Server Replies (5 pages) * Updates RFC2131 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) * Updates RFC3315 RFC7227: Guidelines for Creating New DHCPv6 Options (35 pages) * Updates RFC3315 RFC7283: Handling Unknown DHCPv6 Messages (7 pages) * Updates RFC3315 RFC7341: DHCPv4-over-DHCPv6 (DHCP 4o6) Transport (16 pages) RFC7550: Issues and Recommendations with Multiple Stateful DHCPv6 Options (24 pages) * Updates RFC3315 * Updates RFC3633 RFC7618: Dynamic Allocation of Shared IPv4 Addresses (15 pages) RFC7653: DHCPv6 Active Leasequery (30 pages) * Updates RFC5460 RFC7724: Active DHCPv4 Lease Query (28 pages) * Updates RFC6926 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) Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2017-03-31 Current Status: Active Chairs: Jouni Korhonen Lionel Morand Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Ben Campbell 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: 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 Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' 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 Jan 2016 - Submit I-D 'Diameter Overload Control Rate Abatement Algorithm' 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 Oct 2016 - Submit RFC4006bis as a working group document. Aug 2017 - Submit RFC4006bis to the IESG. 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] (18 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-07] (19 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-10] (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] (22 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-06] (122 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) * Updates RFC3588 * Obsoletes RFC6733 RFC5729: Clarifications on the Routing of Diameter Requests Based on the Username and the Realm (11 pages) * Updates RFC3588 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) * Updates RFC3588 RFC6733: Diameter Base Protocol (152 pages) * Obsoletes RFC3588 * Obsoletes RFC5719 * Updates RFC7075 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) * Updates RFC6733 RFC7155: Diameter Network Access Server Application (70 pages) * Obsoletes RFC4005 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) 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) Dispatch (dispatch) ------------------- Charter Last Modified: 2015-11-01 Current Status: Active Chairs: Cullen Jennings Mary Barnes Murray Kucherawy Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell 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-01] (21 pages) No Requests for Comments Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- Charter Last Modified: 2016-05-05 Current Status: Active Chairs: Barry Leiba Ned Freed Tim Draegen Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov 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 has been submitted as an Independent Submission to become an Informational RFC. 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 three 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 authentication requirements that are desirable. 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 Work Items ---------- Phase I: Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. Phase II: Specification of DMARC improvements to support indirect mail flows Draft Guide on DMARC Usage Phase III: Review and refinement of the DMARC specification Completion of Guide on DMARC 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 draft on DMARC interop issues + possible methods to address Oct 2016 - Complete Authenticated Received Chain (ARC) protocol spec Feb 2017 - Complete Authenticated Received Chain (ARC) usage recommendations Internet-Drafts: - 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-00] (8 pages) - Authenticated Received Chain (ARC) Protocol [draft-ietf-dmarc-arc-protocol-11] (54 pages) - Recommended Usage of the Authenticated Received Chain (ARC) [draft-ietf-dmarc-arc-usage-04] (16 pages) - Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows [draft-ietf-dmarc-interoperability-18] (27 pages) Requests for Comments: RFC7960: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows (27 pages) Distributed Mobility Management (dmm) ------------------------------------- Charter Last Modified: 2017-09-25 Current Status: Active Chairs: Dapeng Liu Sri Gundavelli Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Suresh Krishnan 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: 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). 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. 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) - MN Identifier Types for RFC 4283 Mobile Node Identifier Option [draft-ietf-dmm-4283mnids-06] (13 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-03] (15 pages) - Distributed Mobility Anchoring [draft-ietf-dmm-distributed-mobility-anchoring-07] (46 pages) - Protocol for Forwarding Policy Configuration (FPC) in DMM [draft-ietf-dmm-fpc-cpdp-09] (129 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-13] (16 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-00] (20 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) Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Suzanne Woolf Tim Wicinski Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: https://mailarchive.ietf.org/arch/browse/dnsop/ Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software and services and for the administration of DNS zones. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Describe practices by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, TLD name servers, or any other resolver or server functioning as part of the global DNS. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software and services, including root, TLD, and recursive servers. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning DNS operational procedures in IPv6 and mixed IPv6-IPv4 networks, and provide documentation and guidance on DNS-related IPv6 transition and coexistence issues. 4. Publish documents to address operational issues with the DNS protocols by extending or performing protocol maintenance on them. Act as focal-point for operator discussion and provide advice to the Ops ADs and other WGs on EDNS0 options, new RRTYPEs, DNSSEC, record synthesis, or other mechanics of extending DNS to support other applications. 5. Serve as a home for drafts that document the problem space around existing or new DNS issues. The group, with the advice and consent of the responsible AD in coordination with other areas, will then decide whether these issues belong in DNSOP under the existing charter and, if not, will work with the authors and appropriate ADs to determine the proper place for the work to be carried out. 6. Publish documents that attempt to better define the overlapping area among the public DNS root, DNS-like names as used in local or restricted naming scopes, and the 'special names' registry that IETF manages, perhaps including how they might interact. This work must take into consideration issues that are strictly beyond the operation of the DNS itself, and the working group will consult with IETF liaisons to other organizations as appropriate. Goals and Milestones: Nov 2014 - 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) - The .onion Special-Use Domain Name [draft-appelbaum-dnsop-onion-tld-01] (6 pages) - DNS Multiple QTYPEs [draft-bellis-dnsext-multi-qtypes-05] (7 pages) - DNS Session Signaling [draft-bellis-dnsop-session-signal-02] (13 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 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-00] (24 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) - 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) - 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) - 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) - The ALT Special Use Top Level Domain [draft-ietf-dnsop-alt-tld-09] (11 pages) - Address-specific DNS Name Redirection (ANAME) [draft-ietf-dnsop-aname-01] (12 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) - DNS Scoped Data Through Global '_Underscore' Naming of Attribute Leaves [draft-ietf-dnsop-attrleaf-02] (13 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) - Automating DNSSEC Delegation Trust Maintenance [draft-ietf-dnsop-delegation-trust-maintainance-14] (18 pages) - C-DNS: A DNS Packet Capture Format [draft-ietf-dnsop-dns-capture-format-04] (50 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-01] (15 pages) - DNS Terminology [draft-ietf-dnsop-dns-terminology-05] (27 pages) - DNS wire-format over HTTP [draft-ietf-dnsop-dns-wireformat-http-01] (10 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) - 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-00] (9 pages) - Distributing Authoritative Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-hardie-shared-root-server-07] (11 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-04] (14 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 Sentinel for Detecting Trusted Keys in DNSSEC [draft-ietf-dnsop-kskroll-sentinel-00] (8 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) - 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 Respond. [draft-ietf-dnsop-no-response-issue-08] (25 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) - 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) - 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-04] (10 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) - DNSSEC Operational Practices, Version 2 [draft-ietf-dnsop-rfc4641bis-13] (71 pages) - Security Considerations for RFC5011 Publishers [draft-ietf-dnsop-rfc5011-security-considerations-11] (20 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) - 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-00] (10 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-05] (50 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) - DNS Terminology [draft-ietf-dnsop-terminology-bis-08] (44 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) - DNS Transport over TCP - Operational Requirements [draft-kristoff-dnsop-dns-tcp-requirements-02] (11 pages) - Definition and Use of DNSSEC Negative Trust Anchors [draft-livingood-dnsop-negative-trust-anchors-01] (17 pages) - DNS catalog zones [draft-muks-dnsop-dns-catalog-zones-03] (18 pages) - DNS message checksums [draft-muks-dnsop-dns-message-checksums-01] (9 pages) - Managing DS records from parent via CDS/CDNSKEY [draft-ogud-dnsop-maintain-ds-00] (8 pages) - DNS wire-format over HTTP [draft-song-dns-wireformat-http-04] (10 pages) - Serving Stale Data to Improve DNS Resiliency [draft-tale-dnsop-serve-stale-02] (10 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) - 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-07] (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) BCP40: Root Name Server Operational Requirements (10 pages) * Obsoletes RFC2010 BCP91: DNS IPv6 Transport Operational Guidelines (5 pages) RFC2870: Root Name Server Operational Requirements (10 pages) * Obsoletes RFC2010 * 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 RFC2541 * 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) * Obsoletes RFC4641 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) * Obsoletes RFC6304 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) RFC7719: DNS Terminology (27 pages) RFC7766: DNS Transport over TCP - Implementation Requirements (19 pages) * Obsoletes RFC5966 * Updates RFC1035 * Updates RFC1123 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) * Updates RFC1034 * Updates RFC2308 RFC8027: DNSSEC Roadblock Avoidance (19 pages) RFC8078: Managing DS Records from the Parent via CDS/CDNSKEY (10 pages) * Updates RFC7344 RFC8109: Initializing a DNS Resolver with Priming Queries (7 pages) RFC8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) (13 pages) RFC8198: Aggressive Use of DNSSEC-Validated Cache (13 pages) * Updates RFC4035 RFC8244: Special-Use Domain Names Problem Statement (25 pages) Extensions for Scalable DNS Service Discovery (dnssd) ------------------------------------------------------ Charter Last Modified: 2017-11-15 Current Status: Active Chairs: David Schinazi Tim Chown Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Terry Manderson 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: 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 May 2017 - Submit DNS Push draft to the IESG as Standards Track RFC Jul 2017 - Adopt hybrid-proxy implementation draft as WG document 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 Internet-Drafts: - Privacy Extensions for DNS-SD [draft-huitema-dnssd-privacy-02] (20 pages) - Discovery Proxy for Multicast DNS-Based Service Discovery [draft-ietf-dnssd-hybrid-07] (37 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) - Device Pairing Using Short Authentication Strings [draft-ietf-dnssd-pairing-03] (11 pages) - Device Pairing Design Issues [draft-ietf-dnssd-pairing-info-00] (15 pages) - Privacy Extensions for DNS-SD [draft-ietf-dnssd-privacy-03] (25 pages) - DNS Push Notifications [draft-ietf-dnssd-push-13] (41 pages) - Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions [draft-ietf-dnssd-requirements-06] (14 pages) - Device Pairing Using Short Authentication Strings [draft-kaiser-dnssd-pairing-00] (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) DNS Over HTTPS (doh) -------------------- Charter Last Modified: 2017-09-29 Current Status: Active Chairs: Benjamin M. Schwartz David C Lawrence Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Tech Advisor: Warren Kumari Mailing Lists: General Discussion: doh@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/doh Archive: https://mailarchive.ietf.org/arch/browse/doh/ Description of Working Group: This working group will standardize encodings for DNS queries and responses that are suitable for use in HTTPS. This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience problems. The working group will re-use HTTPS methods, error codes, and other semantics to the greatest extent possible. The use of HTTPS and its existing PKI provides integrity and confidentiality, and it also allows interoperation with common HTTPS infrastructure and policy. The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS clients (e.g., operating system stub resolvers) and recursive resolvers. While access to DNS-over-HTTPS servers from JavaScript running in a typical web browser is not the primary use case for this work, precluding the ability to do so would require additional preventative design. The working group will not engage in such preventative design. The working group will analyze the security and privacy issues that could arise from accessing DNS over HTTPS. In particular, the working group will consider the interaction of DNS and HTTP caching. The working group will coordinate with the DNSOP and INTAREA working groups for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics, respectvely. In particular, DNSOP will be consulted for guidance on the operational impacts that result from traditional host behaviors (i.e., stub-resolver to recursive-resolver interaction) being replaced with the specified mechanism. Specification of how DNS-formatted data may be used for use cases beyond normal DNS queries is out of scope for the working group. The working group may define mechanisms for discovery of DOH servers similar to existing mechanisms for discovering other DNS servers if the chairs determine that there is both sufficient interest and working group consensus. The working group will use draft-hoffman-dispatch-dns-over-https as input. Goals and Milestones: Apr 2018 - Submit specification for performing DNS queries over HTTPS to the IESG for publication as PS Internet-Drafts: - DNS Queries over HTTPS [draft-ietf-doh-dns-over-https-03] (16 pages) No Requests for Comments DDoS Open Threat Signaling (dots) --------------------------------- Charter Last Modified: 2017-04-04 Current Status: Active Chairs: Roman Danyliw Tobias Gondrom Security Area Directors: Kathleen Moriarty Eric Rescorla Security Area Advisor: Kathleen Moriarty Secretary: Liang Xia 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: Jul 2017 - Requirements document to WGLC Jul 2017 - Use case document to WGLC Sep 2017 - Architecture document to WGLC Dec 2017 - Signal channel document as proposed standard to WGLC Dec 2017 - Data channel document as proposed standard to WGLC Internet-Drafts: - Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture [draft-ietf-dots-architecture-05] (30 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification [draft-ietf-dots-data-channel-13] (40 pages) - Distributed Denial of Service (DDoS) Open Threat Signaling Requirements [draft-ietf-dots-requirements-12] (20 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification [draft-ietf-dots-signal-channel-17] (84 pages) - Use cases for DDoS Open Threat Signaling [draft-ietf-dots-use-cases-09] (23 pages) No Requests for Comments DNS PRIVate Exchange (dprive) ----------------------------- Charter Last Modified: 2017-07-03 Current Status: Active Chairs: Brian Haberman Tim Wicinski Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Terry Manderson 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, 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 primary focus of this Working Group is to develop mechanisms that provide confidentiality between DNS Clients and Iterative Resolvers, but it may also later consider mechanisms that provide confidentiality between Iterative Resolvers and Authoritative Servers, or provide end-to-end confidentiality of DNS transactions. Some of the results of this working group may be experimental. The Working Group will also develop an evaluation document to provide methods for measuring the performance against pervasive monitoring; and how well the goal is met. The Working Group will also develop a document providing example assessments for common use cases. 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 [draft-bortzmeyer-dnsop-dns-privacy], 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). Some of the main design goals (in no particular order) are: - Provide confidentiality to DNS transactions (for the querier). - Maintain backwards compatibility with legacy DNS implementations. - Require minimal application-level changes. - Require minimal additional configuration or effort from applications or users Goals and Milestones: Done - WG LC on an problem statement document Done - WG selects one or more primary protocol directions Done - WG LC on primary protocol directions Internet-Drafts: - DNS privacy considerations [draft-bortzmeyer-dnsop-dns-privacy-02] (12 pages) - Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS [draft-dgr-dprive-dtls-and-tls-profiles-00] (17 pages) - TLS for DNS: Initiation and Performance Considerations [draft-hzhwm-dprive-start-tls-for-dns-02] (15 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) - Usage and (D)TLS Profiles for DNS-over-(D)TLS [draft-ietf-dprive-dtls-and-tls-profiles-11] (29 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 Policy for EDNS(0) [draft-ietf-dprive-padding-policy-03] (9 pages) - DNS Privacy Considerations [draft-ietf-dprive-problem-statement-06] (17 pages) - TLS for DNS: Initiation and Performance Considerations [draft-ietf-dprive-start-tls-for-dns-01] (18 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: 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) RFC8094: DNS over Datagram Transport Layer Security (DTLS) (13 pages) Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ Charter Last Modified: 2016-06-06 Current Status: Active Chairs: Marc Blanchet Rick Taylor Transport Area Directors: Spencer Dawkins Mirja Kühlewind Transport Area Advisor: Spencer Dawkins 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: Done - Use Cases for evolving the DTN specifications and list of work items to be worked on. Dec 2016 - RFC5050bis Dec 2016 - TCP CL update Feb 2017 - Neighbor Discovery Feb 2017 - Network Management Requirements Feb 2017 - Key Management Requirements May 2017 - Registry of Service Identifiers May 2017 - Addressing Architecture May 2017 - Bundle Security Protocol May 2017 - Custody Internet-Drafts: - Bundle Protocol Version 7 [draft-ietf-dtn-bpbis-10] (48 pages) - Bundle Protocol Security Specification [draft-ietf-dtn-bpsec-06] (32 pages) - Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 [draft-ietf-dtn-tcpclv4-06] (38 pages) No Requests for Comments Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Allison Mankin Roger Marshall Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach 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: 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 Aug 2017 - 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 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 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) - Data-Only Emergency Calls [draft-ietf-ecrit-data-only-ea-14] (22 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-00] (10 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-04] (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 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) * Updates RFC5031 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) * Updates RFC5985 * Updates RFC6881 RFC7852: Additional Data Related to an Emergency Call (113 pages) * Updates RFC6443 * Updates RFC6881 RFC8147: Next-Generation Pan-European eCall (43 pages) RFC8148: Next-Generation Vehicle-Initiated Emergency Calls (40 pages) Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- Charter Last Modified: 2017-11-14 Current Status: Active Chairs: Bron Gondwana Jiankang Yao Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov 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: Sep 2017 - Submit "Sieve Email Filtering: Delivering to Special-Use Mailboxes" to IESG as a Proposed Standard Oct 2017 - Submit "IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST" to IESG as a Proposed Standard Dec 2017 - Submit "64bit body part and message sizes in IMAP4" to IESG as a Proposed Standard 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) - 64bit body part and message sizes in IMAP4 [draft-ietf-extra-imap-64bit-02] (7 pages) - IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST [draft-ietf-extra-imap-list-myrights-01] (6 pages) - Sieve Extension: File Carbon Copy (Fcc) [draft-ietf-extra-sieve-fcc-01] (8 pages) - Sieve Email Filtering: Delivering to Special-Use Mailboxes [draft-ietf-extra-sieve-special-use-01] (8 pages) No Requests for Comments Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Christopher Morrow Peter Schoenmaker Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Warren Kumari Tech Advisors: Bill Fenner Vijay Gill 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) - 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] (11 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 Negative Impact of Maintenance through BGP Session Culling [draft-ietf-grow-bgp-session-culling-05] (9 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 BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-adj-rib-out-00] (8 pages) - Support for Local RIB in BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-local-rib-00] (14 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) - Problem Definition and Classification of BGP Route Leaks [draft-ietf-grow-route-leak-problem-definition-06] (11 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) - 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) * Obsoletes RFC1519 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) 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) * Obsoletes RFC1519 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) 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) * Updates RFC4271 Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2015-06-15 Current Status: Active Chair: Gonzalo Camarillo Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Terry Manderson 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: 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 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 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-06] (50 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-27] (60 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-18] (42 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) * Updates RFC5201 * 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) * Obsoletes RFC4843 RFC7401: Host Identity Protocol Version 2 (HIPv2) (128 pages) * Obsoletes RFC5201 * Updates RFC8002 RFC7402: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (40 pages) * Obsoletes RFC5202 RFC8002: Host Identity Protocol Certificates (13 pages) * Obsoletes RFC6253 * Updates RFC7401 RFC8003: Host Identity Protocol (HIP) Registration Extension (16 pages) * Obsoletes RFC5203 RFC8004: Host Identity Protocol (HIP) Rendezvous Extension (14 pages) * Obsoletes RFC5204 RFC8005: Host Identity Protocol (HIP) Domain Name System (DNS) Extension (18 pages) * Obsoletes RFC5205 RFC8046: Host Mobility with the Host Identity Protocol (37 pages) * Obsoletes RFC5206 RFC8047: Host Multihoming with the Host Identity Protocol (22 pages) Home Networking (homenet) ------------------------- Charter Last Modified: 2017-09-06 Current Status: Active Chairs: Barbara Stark Ray Bellis Stephen Farrell Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Terry Manderson 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: 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 Nov 2017 - First WG draft on perimeter security Mar 2018 - Submission of the name resolution draft to the IESG as Standards Track RFC Mar 2018 - Submission of the service discovery draft to the IESG as Standards Track RFC Nov 2018 - Submission of the perimeter security 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-05] (9 pages) - Distributed Node Consensus Protocol [draft-ietf-homenet-dncp-12] (41 pages) - Special Use Domain 'home.arpa.' [draft-ietf-homenet-dot-14] (11 pages) - Outsourcing Home Network Authoritative Naming Service [draft-ietf-homenet-front-end-naming-delegation-06] (34 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 Homenet Naming Architecture [draft-ietf-homenet-naming-architecture-dhc-options-05] (28 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) - Simple Homenet Naming and Service Discovery Architecture [draft-ietf-homenet-simple-naming-00] (14 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) Hypertext Transfer Protocol (httpbis) ------------------------------------- Charter Last Modified: 2017-02-06 Current Status: Active Chairs: Mark Nottingham Patrick McManus Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov Tech Advisor: Allison Mankin 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. The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 as the definition of HTTP/1.1 and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP/1.1 * A document (or set of documents) that specifies HTTP/2.0, an improved binding of HTTP's semantics to an underlying transport. HTTP/1.1 -------- HTTP/1.1 is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * 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 * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes. Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status. In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments HTTP/2.0 -------- There is emerging implementation experience and interest in a protocol that retains the semantics of HTTP without the legacy of HTTP/1.x message framing and syntax, which have been identified as hampering performance and encouraging misuse of the underlying transport. The Working Group will produce a specification of a new expression of HTTP's current semantics in ordered, bi-directional streams. As with HTTP/1.x, the primary target transport is TCP, but it should be possible to use other transports. Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point; proposals are to be expressed in terms of changes to that document. Note that consensus is required both for changes to the document and anything that remains in the document. In particular, because something is in the initial document does not imply that there is consensus around the feature or how it is specified. The deliverable of the WG is HTTP/2.0, and there is no consideration of preserving backwards compatibility with the initial starting point. As part of the HTTP/2.0 work, the following issues are explicitly called out for consideration: * A negotiation mechanism that is capable of not only choosing between HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other transports (for example). * Header compression (which may encompass header encoding or tokenisation) * Server push (which may encompass pull or other techniques) It is expected that HTTP/2.0 will: * Substantially and measurably improve end-user perceived latency in most cases, over HTTP/1.1 using TCP. * Address the "head of line blocking" problem in HTTP. * Not require multiple connections to a server to enable parallelism, thus improving its use of TCP, especially regarding congestion control. * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields. * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2). * Clearly identify any new extensibility points and policy for their appropriate use. The resulting specification(s) are expected to meet these goals for common existing deployments of HTTP; in particular, Web browsing (desktop and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and intermediation (by proxies, corporate firewalls, "reverse" proxies and Content Delivery Networks). Likewise, current and future semantic extensions to HTTP/1.x (e.g., headers, methods, status codes, cache directives) should be supported in the new protocol. Note that this does not include uses of HTTP where non-specified behaviours are relied upon (e.g., connection state such as timeouts or client affinity, and "interception" proxies); these uses may or may not be enabled by the final product. Explicitly out-of-scope items include: * Specifying the use of alternate transport-layer protocols. Note that it is expected that the Working Group will work with the TLS working group to define how the protocol is used with the TLS Protocol; any revisions to RFC 2818 will be done in the TLS working group. * Specifying how the HTTP protocol is to be used or presented in a specific use case (e.g., in Web browsers). The Working Group will coordinate this item with: * The TLS Working Group, regarding use of TLS. * The Transport Area, regarding impact on and interaction with transport protocols. * The HYBI Working Group, regarding the possible future extension of HTTP/2.0 to carry WebSockets semantics. The Working Group will give priority to HTTP/1.1 work until that work is complete. Other HTTP-Related Work ----------------------- The Working Group may define additional extensions to HTTP as work items, provided that: * 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 Directors approve the addition and add corresponding milestones. Additionally, the Working Group will not start work on any extensions that are specific to HTTP/2.0 until the HTTP/2.0 work is completed. Goals and Milestones: Done - First HTTP/1.1 Revision Internet Draft Done - First HTTP Security Properties Internet Draft Done - Call for Proposals for HTTP/2.0 Done - Working Group Last Call for HTTP/1.1 Revision Done - First WG draft of HTTP/2.0, based upon draft-mbelshe-httpbis-spdy-00 Held / eliminated - Working Group Last Call for HTTP Security Properties Done - Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard Done - Working Group Last call for HTTP/2.0 Done - Submit HTTP/2.0 to IESG for consideration as a Proposed Standard Done - Submit The Hypertext Transfer Protocol Status Code 308 to IESG for consideration as Internet Standard Done - Submit HTTP Client-Initiated Content-Encoding to IESG for consideration as Proposed Standard Done - Submit Tunnel Protocol for CONNECT to IESG for consideration as Proposed Standard Done - Submit HTTP Authentication-Info and Proxy-Authentication-Info to IESG for consideration as Proposed Standard Done - Submit HTTP Legally Restricted Status Code to IESG for consideration as a Proposed Standard Done - Submit Alternative Services to IESG for consideration as a Proposed Standard Done - Submit HTTP Opportunistic Security to IESG for consideration as Experimental Done - Submit Character Encoding and Language for Parameters to IESG for consideration as Internet Standard May 2016 - Submit the Key HTTP Response Header Field for consideration as a Proposed Standard Internet-Drafts: - Secondary Certificate Authentication in HTTP/2 [draft-bishop-httpbis-http2-additional-certs-05] (21 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-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) - On the use of HTTP as a Substrate [draft-ietf-httpbis-bcp56bis-00] (17 pages) - Cache Digests for HTTP/2 [draft-ietf-httpbis-cache-digest-02] (13 pages) - Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding [draft-ietf-httpbis-cice-03] (7 pages) - HTTP Client Hints [draft-ietf-httpbis-client-hints-05] (14 pages) - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) [draft-ietf-httpbis-content-disp-09] (14 pages) - Deprecate modification of 'secure' cookies from non-secure origins [draft-ietf-httpbis-cookie-alone-01] (6 pages) - Cookie Prefixes [draft-ietf-httpbis-cookie-prefixes-00] (6 pages) - Same-Site Cookies [draft-ietf-httpbis-cookie-same-site-00] (14 pages) - 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-02] (18 pages) - Bootstrapping WebSockets with HTTP/2 [draft-ietf-httpbis-h2-websockets-00] (7 pages) - HPACK: Header Compression for HTTP/2 [draft-ietf-httpbis-header-compression-12] (55 pages) - Structured Headers for HTTP [draft-ietf-httpbis-header-structure-03] (18 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-00] (21 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) - 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] (10 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) - HTTP Random Access and Live Content [draft-ietf-httpbis-rand-access-live-02] (10 pages) - Using Early Data in HTTP [draft-ietf-httpbis-replay-02] (11 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-02] (48 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) - The ALPN HTTP Header Field [draft-ietf-httpbis-tunnel-protocol-05] (7 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) - 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) * Updates RFC2616 RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (89 pages) * Updates RFC2818 * Updates RFC2817 * Obsoletes RFC2616 * Obsoletes RFC2145 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (101 pages) * Updates RFC2817 * Obsoletes RFC2616 RFC7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests (28 pages) * Obsoletes RFC2616 RFC7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests (25 pages) * Obsoletes RFC2616 RFC7234: Hypertext Transfer Protocol (HTTP/1.1): Caching (43 pages) * Obsoletes RFC2616 RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication (19 pages) * Updates RFC2617 * Obsoletes RFC2616 * Obsoletes RFC2617 RFC7236: Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations (3 pages) RFC7237: Initial Hypertext Transfer Protocol (HTTP) Method Registrations (5 pages) RFC7538: The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) (6 pages) * Obsoletes RFC7238 RFC7540: Hypertext Transfer Protocol Version 2 (HTTP/2) (96 pages) RFC7541: HPACK: Header Compression for HTTP/2 (55 pages) RFC7615: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields (6 pages) * Obsoletes RFC2617 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) * Obsoletes RFC5987 RFC8188: Encrypted Content-Encoding for HTTP (16 pages) RFC8246: HTTP Immutable Responses (6 pages) RFC8297: An HTTP Status Code for Indicating Hints (7 pages) Interface to Network Security Functions (i2nsf) ----------------------------------------------- Charter Last Modified: 2017-07-18 Current Status: Active Chairs: Linda Dunbar Yoav Nir Security Area Directors: Kathleen Moriarty Eric Rescorla Security Area Advisor: Kathleen Moriarty 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: 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) Nov 2016 - Adopt info model as WG document (if desired) Dec 2016 - Adopt examination of existing secure communication mechanisms as WG document Feb 2017 - Adopt data models as WG document Apr 2017 - Adopt applicability statements as WG Document Apr 2017 - Adopt IANA registry consideration as WG document Apr 2017 - 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 Oct 2017 - Data Models and Applicability Statements to IESG for publication Dec 2017 - Working group re-charter or close 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) - Applicability of Interfaces to Network Security Functions to Network-Based Security Services [draft-ietf-i2nsf-applicability-01] (19 pages) - Information Model of NSFs Capabilities [draft-ietf-i2nsf-capability-00] (57 pages) - Requirements for Client-Facing Interface to Security Controller [draft-ietf-i2nsf-client-facing-interface-req-04] (24 pages) - Framework for Interface to Network Security Functions [draft-ietf-i2nsf-framework-10] (23 pages) - Analysis of Existing work for I2NSF [draft-ietf-i2nsf-gap-analysis-03] (48 pages) - Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases [draft-ietf-i2nsf-problem-and-use-cases-16] (29 pages) - Software-Defined Networking (SDN)-based IPsec Flow Protection [draft-ietf-i2nsf-sdn-ipsec-flow-protection-00] (47 pages) - Interface to Network Security Functions (I2NSF) Terminology [draft-ietf-i2nsf-terminology-05] (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) Interface to the Routing System (i2rs) -------------------------------------- Charter Last Modified: 2016-06-07 Current Status: Active Chairs: Russ White Susan Hares Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Alia Atlas 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: RFC7921 - Request publication of an Informational document defining the problem statement RFC7921 - Request publication of an Informational document defining the high-level architecture Mar 2016 - Request Publication of Filter-Based RIB Data Model Done - Working Group adoption of Filter-Based RIB Yang 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 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 Routing Information Base (RIB) [draft-ietf-i2rs-rib-data-model-09] (68 pages) - Routing Information Base Info Model [draft-ietf-i2rs-rib-info-model-13] (25 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-04] (29 pages) - A YANG Data Model for Layer-2 Network Topologies [draft-ietf-i2rs-yang-l2-network-topology-03] (20 pages) - A YANG Data Model for Layer 3 Topologies [draft-ietf-i2rs-yang-l3-topology-16] (34 pages) - A Data Model for Network Topologies [draft-ietf-i2rs-yang-network-topo-20] (52 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) Interactive Connectivity Establishment (ice) -------------------------------------------- Charter Last Modified: 2015-10-20 Current Status: Active Chairs: Ari Keränen Peter Thatcher Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell Tech Advisor: Martin Stiemerling Mailing Lists: General Discussion: ice@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ice Archive: https://mailarchive.ietf.org/arch/browse/ice/ Description of Working Group: Interactive Connectivity Establishment (ICE) is at the same time a NAT traversal technique, a multihomed address selection technique, and a dual stack address selection technique that works by including multiple IP addresses and ports in both the request and response messages of a connectivity establishment transaction. It makes no assumptions regarding network topology on the local or remote side. Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. This situation has changed drastically as ICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. ICE was originally defined for the Offer-Answer (RFC 3264) protocol used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and other realtime media establishment protocols have used the protocol. ICE is also used by non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC 6940). The goal of the ICE Working Group is to consolidate the various initiatives to update and improve ICE, and to help ensure suitability and consistency in the environments ICE operates in. Current work in this area includes an updated version of the ICE RFC (ICEbis), Trickle ICE and dualstack/multihomed fairness. This work will make ICE more flexible, robust and more suitable for changing mobile environments without major changes to the original ICE RFC. The ICE workgroup will consider new work items that follow this pattern. The core ICE work will offer guidance to help minimize the unintentional exposure of IP addresses. ICE is an application controlled protocol that leverages a set of network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and related protocol work done in the TRAM working group must be closely synchronized with the work in this working group. To avoid interoperability issues and unwanted behavior it is desired to increase the interaction with other working groups dealing with network protocols closer to the wire. Example of such work may be, but not limited to: issues regarding multi-homing, multi subnet and prefixes, QoS, transport selection and congestion control. From the application side, the users of ICE, there is a need to make sure what is specified is actually usable. Getting input from the application working groups will be helpful (RTCWEB, HIP, MMUSIC, P2PSIP). Goals and Milestones: Done - Submit Dual-stack Fairness with ICE as Proposed Standard Dec 2016 - Submit a revision of ICE (RFC 5245) as Proposed Standard (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC) Jan 2017 - Submit Trickle ICE as Proposed Standard (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC) Internet-Drafts: - ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines [draft-ietf-ice-dualstack-fairness-07] (10 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal [draft-ietf-ice-rfc5245bis-17] (95 pages) - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol [draft-ietf-ice-trickle-16] (32 pages) No Requests for Comments Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2017-02-09 Current Status: Active Chairs: John Scudder Susan Hares Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana 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: 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 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 Internet-Drafts: - 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 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-08] (8 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 Communities Attribute [draft-ietf-idr-bgp-ext-communities-09] (12 pages) - Extended Message support for BGP [draft-ietf-idr-bgp-extended-messages-24] (6 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-05] (9 pages) - Notification Message support for BGP Graceful Restart [draft-ietf-idr-bgp-gr-notification-13] (7 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-10] (6 pages) - Issues in Revising BGP-4 (RFC1771 to RFC4271) [draft-ietf-idr-bgp-issues-06] (170 pages) - Advertising Node Admin Tags in BGP Link-State Advertisements [draft-ietf-idr-bgp-ls-node-admin-tag-extension-03] (11 pages) - BGP Link-State extensions for Segment Routing [draft-ietf-idr-bgp-ls-segment-routing-ext-04] (27 pages) - Signaling Maximum SID Depth using Border Gateway Protocol Link-State [draft-ietf-idr-bgp-ls-segment-routing-msd-01] (7 pages) - Signalling ERLD using BGP-LS [draft-ietf-idr-bgp-ls-segment-routing-rld-01] (6 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 Model for Service Provider Networks [draft-ietf-idr-bgp-model-02] (98 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-02] (10 pages) - BGP Optimal Route Reflection (BGP-ORR) [draft-ietf-idr-bgp-optimal-route-reflection-15] (13 pages) - Address-Prefix-Based Outbound Route Filter for BGP-4 [draft-ietf-idr-bgp-prefix-orf-05] (6 pages) - Segment Routing Prefix SID extensions for BGP [draft-ietf-idr-bgp-prefix-sid-13] (17 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 extensions for Segment Routing BGP Egress Peer Engineering [draft-ietf-idr-bgpls-segment-routing-epe-14] (21 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) - 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 MPLS-TE Extended admin Group Using BGP [draft-ietf-idr-eag-distribution-05] (5 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-05] (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-09] (10 pages) - Applying BGP flowspec rules on a specific interface set [draft-ietf-idr-flowspec-interfaceset-03] (15 pages) - Dissemination of Flow Specification Rules for L2 VPN [draft-ietf-idr-flowspec-l2vpn-07] (13 pages) - BGP Flow Specification Filter for MPLS Label [draft-ietf-idr-flowspec-mpls-match-01] (8 pages) - Dissemination of NVO3 Flow Specification Rules [draft-ietf-idr-flowspec-nvo3-01] (13 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-03] (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-06] (6 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-03] (17 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-01] (10 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-01] (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-06] (33 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-07] (24 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) - Making Route Servers Aware of Data Link Failures at IXPs [draft-ietf-idr-rs-bfd-03] (12 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-08] (7 pages) - Advertising Segment Routing Policies in BGP [draft-ietf-idr-segment-routing-te-policy-01] (32 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) - 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-08] (27 pages) - BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions [draft-ietf-idr-te-pm-bgp-08] (9 pages) - The BGP Tunnel Encapsulation Attribute [draft-ietf-idr-tunnel-encaps-08] (41 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-04] (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) - 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) - BGP FlowSpec Redirect to Generalized Segment ID Action [draft-li-idr-flowspec-redirect-generalized-sid-00] (8 pages) - BGP FlowSpec Extensions for Routing Policy Distribution (RPD) [draft-li-idr-flowspec-rpd-02] (23 pages) - BGP Extensions for Service-Oriented MPLS Path Programming (MPP) [draft-li-idr-mpls-path-programming-04] (14 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) - 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) - Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 234 [draft-snijders-idr-deprecate-30-31-129-02] (3 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) - 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) - Distribution of MPLS-TE Extended admin Group Using BGP [draft-wang-idr-eag-distribution-02] (5 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) - 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 RFC1105 * 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) * Obsoletes RFC1163 RFC1268: Application of the Border Gateway Protocol in the Internet (13 pages) * Obsoletes RFC1164 * 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 RFC1268 * 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) * Obsoletes RFC1656 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 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) * Updates RFC1966 * Obsoletes RFC4456 RFC2842: Capabilities Advertisement with BGP-4 (5 pages) * Obsoletes RFC3392 RFC2858: Multiprotocol Extensions for BGP-4 (11 pages) * Obsoletes RFC2283 * Obsoletes RFC4760 RFC2918: Route Refresh Capability for BGP-4 (4 pages) * Updates RFC7313 RFC3065: Autonomous System Confederations for BGP (11 pages) * Obsoletes RFC1965 * Obsoletes RFC5065 RFC3345: Border Gateway Protocol (BGP) Persistent Route Oscillation Condition (19 pages) RFC3392: Capabilities Advertisement with BGP-4 (6 pages) * Obsoletes RFC2842 * Obsoletes RFC5492 RFC3562: Key Management Considerations for the TCP MD5 Signature Option (7 pages) RFC4223: Reclassification of RFC 1863 to Historic (3 pages) * Obsoletes RFC1863 RFC4271: A Border Gateway Protocol 4 (BGP-4) (104 pages) * Obsoletes RFC1771 * Updates RFC6286 * Updates RFC6608 * Updates RFC6793 * Updates RFC7607 * Updates RFC7606 * Updates RFC7705 * Updates RFC8212 RFC4272: BGP Security Vulnerabilities Analysis (22 pages) RFC4273: Definitions of Managed Objects for BGP-4 (32 pages) * Obsoletes RFC1269 * Obsoletes RFC1657 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) * Obsoletes RFC1966 * Obsoletes RFC2796 * Updates RFC7606 RFC4486: Subcodes for BGP Cease Notification Message (6 pages) * Updates RFC8203 RFC4724: Graceful Restart Mechanism for BGP (15 pages) RFC4760: Multiprotocol Extensions for BGP-4 (12 pages) * Obsoletes RFC2858 * 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) * Obsoletes RFC3065 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) * Obsoletes RFC3392 RFC5575: Dissemination of Flow Specification Rules (22 pages) * Updates RFC7674 RFC6286: Autonomous-System-Wide Unique BGP Identifier for BGP-4 (4 pages) * Updates RFC4271 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) * Updates RFC4271 RFC6793: BGP Support for Four-Octet Autonomous System (AS) Number Space (12 pages) * Obsoletes RFC4893 * Updates RFC4271 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) * Updates RFC1930 RFC7153: IANA Registries for BGP Extended Communities (16 pages) * Updates RFC5701 * Updates RFC4360 RFC7196: Making Route Flap Damping Usable (8 pages) RFC7300: Reservation of Last Autonomous System (AS) Numbers (5 pages) * Updates RFC1930 RFC7311: The Accumulated IGP Metric Attribute for BGP (15 pages) RFC7313: Enhanced Route Refresh Capability for BGP-4 (8 pages) * Updates RFC2918 RFC7606: Revised Error Handling for BGP UPDATE Messages (19 pages) * Updates RFC1997 * Updates RFC4271 * Updates RFC4360 * Updates RFC4456 * Updates RFC4760 * Updates RFC5543 * Updates RFC5701 * Updates RFC6368 RFC7607: Codification of AS 0 Processing (5 pages) * Updates RFC4271 RFC7674: Clarification of the Flowspec Redirect Extended Community (7 pages) * Updates RFC5575 RFC7705: Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute (16 pages) * Updates RFC4271 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) * Updates RFC4486 INtermediary-safe SIP session ID (insipid) ------------------------------------------ Charter Last Modified: 2017-08-01 Current Status: Active Chairs: Gonzalo Salgueiro Keith Drage Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell Mailing Lists: General Discussion: insipid@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/insipid Archive: https://mailarchive.ietf.org/arch/browse/insipid/ Description of Working Group: An end-to-end session identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments of Back-to-Back User Agents (B2BUAs) devices like Session Border Controllers (SBC) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end session identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. A SIP end-to-end session identifier has been considered as possible solution of different use cases like troubleshooting, billing, session recording, media and signaling correlation, and so forth. Some of these requirements come from other working groups within the RAI area (e.g., SIPRec). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same "session ID" value so that it is possible to identify a call end-to-end even when performing inter working between protocols. Troubleshooting SIP signalling end-to-end becomes impractical as networks grow and become interconnected, including connection via transit networks, because the path that SIP signalling will take between clients cannot be predicted and the signalling volume and geographical spread are too large. This group will focus on two documents: The first document will specify a SIP identifier that has the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries. In doing this work, the group will pay attention to the privacy implications of a "session ID", for example considering the possibility to make it intractable for nodes to correlate "session IDs" generated by the same user for different sessions. The second document will define an indicator that can be added to the SIP protocol to indicate that signalling should be logged. The indicator will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. Goals and Milestones: Done - Requirements and use cases for new identifier sent to IESG (Informational) Done - Requirements for marking SIP sessions for logging to IESG (Informational) Done - Specification of the new identifier sent to the IESG (Proposed Standard) Jun 2017 - Protocol for marking SIP sessions for logging to IESG (Proposed Standard) Internet-Drafts: - Marking SIP Messages to be Logged [draft-ietf-insipid-logme-marking-09] (37 pages) - Requirements for Marking SIP Messages to be Logged [draft-ietf-insipid-logme-reqs-12] (11 pages) - End-to-End Session Identification in IP-Based Multimedia Communication Networks [draft-ietf-insipid-session-id-27] (45 pages) - Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks [draft-ietf-insipid-session-id-reqts-11] (15 pages) Requests for Comments: RFC7206: Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks (15 pages) RFC7989: End-to-End Session Identification in IP-Based Multimedia Communication Networks (45 pages) * Obsoletes RFC7329 RFC8123: Requirements for Marking SIP Messages to be Logged (11 pages) Internet Area Working Group (intarea) ------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Juan-Carlos Zúñiga Wassim Haddad Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Suresh Krishnan 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 and multicast [draft-ietf-intarea-broadcast-consider-08] (13 pages) - Using the IPv6 Flow Label for Load Balancing in Server Farms [draft-ietf-intarea-flow-label-balancing-03] (13 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-05] (37 pages) - Extensions for Generic UDP Encapsulation [draft-ietf-intarea-gue-extensions-03] (38 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] (17 pages) - Discovering Provisioning Domain Names and Data [draft-ietf-intarea-provisioning-domains-00] (22 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-08] (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) * Updates RFC2113 * Updates RFC2711 BCP177: IPv6 Support Required for All IP-Capable Nodes (6 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) * Updates RFC2113 * Updates RFC2711 RFC6540: IPv6 Support Required for All IP-Capable Nodes (6 pages) RFC6864: Updated Specification of the IPv4 ID Field (19 pages) * Updates RFC1122 * Updates RFC2003 * Updates RFC791 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) IP Performance Measurement (ippm) --------------------------------- Charter Last Modified: 2017-08-29 Current Status: Active Chairs: Bill Cerveny Brian Trammell Transport Area Directors: Spencer Dawkins Mirja Kühlewind Transport Area Advisor: Spencer Dawkins Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: https://mailarchive.ietf.org/arch/browse/ippm/ Description of Working Group: The IP Performance Measurement (IPPM) Working Group develops and maintains standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services and applications running over transport layer protocols (e.g. TCP, UDP) over IP. It also develops and maintains methodologies and protocols for the measurement of these metrics. These metrics, protocols, and methodologies are designed such that they can be used by network operators, end users, or independent testing groups. Metrics developed by the IPPM WG are intended to provide unbiased quantitative performance measurements. The IPPM WG works to foster commonality and comparability of metrics and measurements across IETF protocols at different layers. Its work is limited to metrics and methodologies which are applicable over transport-layer protocols over IP, and does not specify encapsulations required for measurements over non-IP layers. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. The working group will continue advancing the most useful of these metrics along the standards track, using the guidelines stated in RFC 6576. To the extent possible, these metrics will be used as the basis for future work on metrics in the WG. The WG will seek to develop new metrics and models to accurately characterize the network paths under test and/or the performance of transport and application layer protocols on these paths. The WG will balance the need for new metrics with the desire to minimize the introduction of new metrics, and will require that new metric definitions state how the definition improves on an existing metric definition, or assesses a property of network performance not previously covered by a defined metric. Metric definitions will follow the template given in RFC 6390. Additional methods will be defined for the composition and calibration of IPPM-defined metrics, as well as active, passive and hybrid measurement methods for these metrics. In addition, the WG encourages work which describes the applicability of metrics and measurement methods, especially to improve understanding of the tradeoffs involved among active, passive, and hybrid methods. The WG may update its core framework RFC 2330 as necessary to accommodate these activities. The WG has produced protocols for communication among test equipment to enable the measurement of the one- and two-way metrics (OWAMP and TWAMP respectively). These protocols will be advanced along the standards track. The work of the WG will take into account the suitability of measurements for automation, in order to support large-scale measurement efforts. This may result in further developments in protocols such as OWAMP and TWAMP. Agreement about the definitions of metrics and methods of measurement enables accurate, reproducible, and equivalent results across different implementations. To this end, the WG defines and maintains a registry of metric definitions. The WG encourages work which assesses the comparability of measurements of IPPM metrics with metrics developed elsewhere. The WG also encourages work which improves the availability of information about the context in which measurements were taken, for example (but not limited to) measurement implementation information, estimates of confidence in these measurements, conditions on the network(s) on which measurements are taken, and/or information about the data-plane topology of these network(s). In the interest of measurement comparability, the WG may define data formats and information models for the storage and exchange of the results of measurements defined within IPPM. The IPPM WG seeks cooperation with other appropriate standards bodies and forums to promote consistent approaches and metrics. Within the IETF process, IPPM metric definitions and measurement protocols will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersects with the requirement of these specific metrics. The WG will, on request, provide input to other IETF working groups on the use and implementation of these metrics. Goals and Milestones: Done - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational Done - Submit draft updating the IPPM Framework (2330-update) to IESG as Proposed Standard Done - Submit draft on reference path for measurement location to IESG as Informational Done - Submit draft on access rate measurement protocol problem statement to IESG as Informational Done - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Standard Done - Submit draft on "A One-Way Delay Metric for IPPM" (RFC 2679 bis) as Internet Standard Done - Submit draft on "A One-Way Loss Metric for IPPM" (RFC 2680 bis) as Internet Standard Done - Submit draft on DSCP and ECN monitoring in TWAMP to IESG as Proposed Standard Done - Submit draft on the UDP Checksum Trailer in OWAMP and TWAMP to the IESG as Informational Done - Submit a draft defining terminology for the continuum of passive and active measurement to the IESG as Informational Done - Submit draft on model-based TCP bulk transfer capacity metrics to IESG as Experimental Done - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) Destination Option as Proposed Standard Done - submit a Standards Track document to the IESG adding support for IEEE-1588 timestamps to TWAMP Oct 2017 - 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 Jul 2018 - Submit draft on core registry for performance metrics to IESG as Proposed Standard Jul 2018 - submit a Standards Track document to the IESG defining initial contents of performance metric registry Jul 2018 - submit a Standards Track document to the IESG updating RFC2330 to cover IPv6 Nov 2018 - submit a Standards Track draft on inband OAM based measurement methodologies to the IESG Internet-Drafts: - Two-Way Active Measurement Protocol (TWAMP) Data Model [draft-cmzrjp-ippm-twamp-yang-02] (56 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) - IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework [draft-ietf-ippm-2330-ipv6-02] (14 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) - 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 Metric Registry Entries [draft-ietf-ippm-initial-registry-05] (92 pages) - Data Fields for In-situ OAM [draft-ietf-ippm-ioam-data-01] (29 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-13] (34 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] (53 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) - 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) - OWAMP and TWAMP Well-Known Port Assignments [draft-ietf-ippm-port-twamp-test-00] (9 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-00] (22 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-00] (16 pages) - Simple Two-way Active Measurement Protocol (STAMP) Data Model [draft-ietf-ippm-stamp-yang-00] (29 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-05] (65 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) - UDP Checksum Trailer in OWAMP and TWAMP [draft-mizrahi-ippm-checksum-trailer-02] (11 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) - 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 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 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 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) * Updates RFC5357 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) * Updates RFC5357 RFC6038: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features (18 pages) * Updates RFC5357 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) * Obsoletes RFC4148 * Updates RFC4737 * Updates RFC5560 * Updates RFC5644 * Updates RFC6049 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) * Updates RFC2330 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) * Obsoletes RFC2679 RFC7680: A One-Way Loss Metric for IP Performance Metrics (IPPM) (22 pages) * Obsoletes RFC2680 RFC7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) (15 pages) * Updates RFC4656 * Updates RFC5337 * Updates RFC5357 RFC7718: Registries for the One-Way Active Measurement Protocol (OWAMP) (7 pages) * Updates RFC4656 RFC7750: Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) (11 pages) * Updates RFC5357 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) STD81: A One-Way Delay Metric for IP Performance Metrics (IPPM) (27 pages) * Obsoletes RFC2679 STD82: A One-Way Loss Metric for IP Performance Metrics (IPPM) (22 pages) * Obsoletes RFC2680 IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Charter Last Modified: 2017-03-29 Current Status: Active Chairs: David Waltermire Tero Kivinen Security Area Directors: Kathleen Moriarty Eric Rescorla Security Area Advisor: Eric Rescorla 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), 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 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: IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol. IKEv2 utilizes a number of cryptographic algorithms in order to provide security services. To support interoperability a number of mandatory-to-implement (MTI) algorithms are defined in RFC4307 for IKEv2 and in RFC7321 for ESP/AH. There is interest in updating the MTIs in RFC4307 and RFC7321 based on new algorithms, changes to the understood security strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 and RFC7321 proposing updates to the MTI algorithms used by IKEv2 and IPsec to address these changes. There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange and EdDSA for authentication in the IKEv2 protocol. The group will extend the IKEv2 protocol to support key agreement using these curves and their related functions. 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 IKEv2 to have similar quantum resistant properties than IKEv1 had. There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE and ESP packets need to be transmitted over TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP. The group will also provide guidance on how to detect when IKE cannot be negotiated over UDP, and TCP should be used as a fallback Split-DNS is a common configuration for VPN deployments, in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in form of 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. This charter will expire in December 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Done - IETF Last Call on DDoS protection Done - IETF Last Call on Curve25519 and Curve448 for IKEv2 Done - IETF Last Call on cryptographic algorithms for IKEv2 Done - IETF Last Call on cryptographic algorithms for ESP / AH Done - IETF Last Call on TCP Encapsulation of IKE and IPsec Jan 2017 - IETF Last Call on Using EdDSA in the IKEv2 Feb 2017 - IETF Last Call on Split-DNS Configuration for IKEv2 Feb 2017 - IETF Last Call on Implicit IV in IPsec Jun 2017 - IETF Last Call on partially quantum resistant IKEv2 Internet-Drafts: - Postquantum Preshared Keys for IKEv2 [draft-fluhrer-qr-ikev2-04] (11 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 Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (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) - 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) - IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-ipv6-config-03] (32 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 IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) [draft-ietf-ipsecme-implicit-iv-00] (7 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) - 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) - Postquantum Preshared Keys for IKEv2 [draft-ietf-ipsecme-qr-ikev2-01] (18 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 IKEv2 [draft-ietf-ipsecme-split-dns-04] (11 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) 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) * Obsoletes RFC4306 * Obsoletes RFC4718 * Updates RFC5998 * Updates RFC6989 * Updates RFC6989 * Obsoletes RFC7296 RFC5998: An Extension for EAP-Only Authentication in IKEv2 (16 pages) * Updates RFC5996 RFC6027: IPsec Cluster Problem Statement (12 pages) RFC6071: IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (63 pages) * Obsoletes RFC2411 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) * Updates RFC5996 * Updates RFC5996 RFC7018: Auto-Discovery VPN Problem Statement and Requirements (12 pages) RFC7296: Internet Key Exchange Protocol Version 2 (IKEv2) (142 pages) * Obsoletes RFC5996 * 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 RFC4835 * 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) * Updates RFC7296 RFC7619: The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) (12 pages) * Updates RFC4301 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) * Obsoletes RFC7321 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) * Obsoletes RFC4307 * Updates RFC7296 STD79: Internet Key Exchange Protocol Version 2 (IKEv2) (142 pages) * Obsoletes RFC5996 IP Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------- Charter Last Modified: 2016-10-18 Current Status: Active Chairs: Carlos Jésus Bernardos Russ Housley Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Suresh Krishnan 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: 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 May 2017 - Submit "IPv6 over 802.11-OCB" to IESG Oct 2017 - Submit "ITS General Problem Area" to IESG May 2018 - Submit "Problem Statement" to IESG Internet-Drafts: - Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) [draft-ietf-ipwave-ipv6-over-80211ocb-13] (38 pages) - Problem Statement for IP Wireless Access in Vehicular Environments [draft-ietf-ipwave-problem-statement-00] (19 pages) - IP-based Vehicular Networking: Use Cases, Survey and Problem Statement [draft-ietf-ipwave-vehicular-networking-01] (50 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) No Requests for Comments IS-IS for IP Internets (isis) ----------------------------- Charter Last Modified: 2015-06-15 Current Status: Active Chairs: Christian Hopps Hannes Gredler Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Alia Atlas Tech Advisor: David Ward Mailing Lists: General Discussion: isis-wg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/isis-wg Archive: https://mailarchive.ietf.org/arch/browse/isis-wg/ Description of Working Group: IS-IS is an IGP specified and standarized by ISO and incorporating extensions to support IP. It has been deployed successfully in the Internet for several years years. The IS-IS Working Group is chartered to document current protocol implementation practices and improvements, as well as to propose further extensions to be used within the scope of IS-IS and IP routing. Short term, the WG is expected to deliver a set of documents describing common implementation practices and extensions necessary to scale the protocol. These specifications will encourage multiple, inter-operable vendor implementations. This working group will interact with other standards bodies that have responsibility for standardizing IS-IS. The status of the WG documents maintained by the WG chairs can be found at http://skat.usc.edu/~tli/Schedule.htm. Goals and Milestones: Done - Submit I-D on IS-IS Traffic Engineering Extensions Done - Submit I-D on IS-IS HMAC-MD5 Authentication Done - Submit I-D on Maintaining more than 255 adjacencies in IS-IS Done - Submit I-D on Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS Done - Submit I-D on IS-IS MIB Done - Submit IS-IS Traffic Engineering Extensions to IESG for publication as an Informational RFC Done - Submit IS-IS HMAC-MD5 Authentication to IESG for publication as an Informational RFC Done - Submit Maintaining more than 255 adjacencies in IS-IS to IESG for publication as an Informational RFC Done - Submit Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS to IESG for publication as an Informational RFC Done - Submit IPv6 to IESG for publication as an Informational RFC Done - Submit M-ISIS to IESG for publication as an Informational RFC Done - Submit 256+ Fragments to IESG for publication as an Informational RFC Done - Submit Administrative Tags to IESG for publication as an Informational RFC Done - Submit Interoperable IP Networks to IESG for publication as an Informational RFC Done - Submit Interoperable Networks to IESG for publication as an Informational RFC Done - Submit P2P over LAN to IESG for publication as an Informational RFC Done - Submit Gracefull Restart to IESG for publication as an Informational RFC Jun 2005 - Submit Experimental TLVs to IESG for publication as an Informational RFC Done - Submit Definition of an IS-IS Link Attribute sub-TLV to IESG for publication as Informational RFC Done - Submit A Policy Control Mechanism in IS-IS Using Administrative Tags to IESG for publication as Informational RFC Done - Submit IS-IS MIB to IESG for consideration as a Proposed Standard Done - Submit Multi Topology (MT) Routing in ISIS to IESG for publication as Informational RFC Done - Submit IS-IS extensions for advertising router information to IESG for publication as Informational RFC Done - Submit Routing IPv6 with IS-IS to IESG for publication as Proposed Standard Nov 2005 - Review WG's priorities and future potential Internet-Drafts: - IPv6 Source/Destination Routing using IS-IS [draft-baker-ipv6-isis-dst-src-routing-07] (12 pages) - IS-IS Path Computation and Reservation [draft-farkas-isis-pcr-02] (31 pages) - IS-IS Flooding Scope LSPs [draft-ginsberg-isis-fs-lsp-01] (19 pages) - Advertising L2 Bundle Member Link Attributes in IS-IS [draft-ginsberg-isis-l2bundles-02] (13 pages) - IS-IS Multi-Instance [draft-ginsberg-isis-mi-bis-01] (15 pages) - IS-IS Prefix Attributes for Extended IP and IPv6 Reachability [draft-ginsberg-isis-prefix-attributes-01] (7 pages) - IS-IS Minimum Remaining Lifetime [draft-ginsberg-isis-remaining-lifetime-00] (9 pages) - IS-IS Extensions for Advertising Router Info [draft-ginsberg-isis-rfc4971bis-00] (9 pages) - IS-IS TE Attributes per application [draft-ginsberg-isis-te-app-03] (15 pages) - Updates to IS-IS TLV Codepoints Registry [draft-ginsberg-isis-tlv-codepoints-00] (7 pages) - IS-IS Support for Unidirectional Links [draft-ginsberg-isis-udl-01] (17 pages) - Advertising TE protocols in IS-IS [draft-hegde-isis-advertising-te-protocols-03] (11 pages) - Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies [draft-ietf-isis-3way-05] (9 pages) - A Policy Control Mechanism in IS-IS Using Administrative Tags [draft-ietf-isis-admin-tags-04] (8 pages) - Further Integration of IS-IS; Appletalk, IPX, and Other Protocols [draft-ietf-isis-atipx-00] (24 pages) - IS-IS Autoconfiguration [draft-ietf-isis-auto-conf-05] (15 pages) - IS-IS Automatic Encapsulation [draft-ietf-isis-auto-encap-03] (24 pages) - IS-IS BFD-Enabled TLV [draft-ietf-isis-bfd-tlv-03] (7 pages) - Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information [draft-ietf-isis-caps-07] (9 pages) - Extensions to ISIS for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-isis-diff-te-00] (7 pages) - Domain-wide Prefix Distribution with Two-Level IS-IS [draft-ietf-isis-domain-wide-03] (14 pages) - Dynamic Hostname Exchange Mechanism for IS-IS [draft-ietf-isis-dyname-03] (5 pages) - Advertising Tunnelling Capability in IS-IS [draft-ietf-isis-encapsulation-cap-01] (11 pages) - TLV for Experimental Use [draft-ietf-isis-experimental-tlv-05] (0 pages) - Extended Ethernet Frame Size Support [draft-ietf-isis-ext-eth-01] (0 pages) - Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit [draft-ietf-isis-ext-lsp-frags-02] (14 pages) - IS-IS Extended Sequence Number TLV [draft-ietf-isis-extended-sequence-no-tlv-06] (12 pages) - IS-IS Flooding Scope Link State PDUs (LSPs) [draft-ietf-isis-fs-lsp-02] (23 pages) - Advertising Generic Information in IS-IS [draft-ietf-isis-genapp-04] (11 pages) - Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-isis-gmpls-extensions-19] (11 pages) - Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication [draft-ietf-isis-hmac-04] (6 pages) - IS-IS Generic Cryptographic Authentication [draft-ietf-isis-hmac-sha-07] (12 pages) - IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging [draft-ietf-isis-ieee-aq-05] (37 pages) - Point-to-Point Operation over LAN in Link State Routing Protocols [draft-ietf-isis-igp-p2p-over-lan-06] (10 pages) - Recommendations for Interoperable IP Networks using IS-IS [draft-ietf-isis-interoperable-01] (20 pages) - Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) [draft-ietf-isis-ip-interoperable-02] (11 pages) - Routing IPv6 with IS-IS [draft-ietf-isis-ipv6-07] (7 pages) - IPv6 Source/Destination Routing using IS-IS [draft-ietf-isis-ipv6-dst-src-routing-00] (12 pages) - IPv6 Traffic Engineering in IS-IS [draft-ietf-isis-ipv6-te-08] (10 pages) - Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) [draft-ietf-isis-iso-interoperable-02] (15 pages) - L1/L2 Optimal IS-IS Routing [draft-ietf-isis-l1l2-00] (7 pages) - Advertising L2 Bundle Member Link Attributes in IS-IS [draft-ietf-isis-l2bundles-07] (18 pages) - Extensions to IS-IS for Layer-2 Systems [draft-ietf-isis-layer2-11] (7 pages) - Definition of an IS-IS Link Attribute Sub-TLV [draft-ietf-isis-link-attr-03] (6 pages) - IS-IS Multi-Instance [draft-ietf-isis-mi-08] (14 pages) - IS-IS Multi-Instance [draft-ietf-isis-mi-bis-03] (16 pages) - Integrated IS-IS Management Information Base [draft-ietf-isis-mib-04] (97 pages) - Signaling Entropy Label Capability and Readable Label-stack Depth Using IS-IS [draft-ietf-isis-mpls-elc-03] (6 pages) - Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRT) [draft-ietf-isis-mrt-03] (14 pages) - Multiple Levels of Hierarchy with IS-IS [draft-ietf-isis-multilevel-routing-00] (10 pages) - Routing over Nonbroadcast Multiaccess Links [draft-ietf-isis-nbma-00] (39 pages) - Advertising Node Administrative Tags in IS-IS [draft-ietf-isis-node-admin-tag-11] (11 pages) - IS-IS Optimized Multipath (ISIS-OMP) [draft-ietf-isis-omp-01] (8 pages) - IS-IS Operational Enhancements for Network Maintenance Events [draft-ietf-isis-oper-enhance-03] (6 pages) - Experience with the Integrated ISIS Protocol [draft-ietf-isis-opexp-01] (25 pages) - IS-IS Path Control and Reservation [draft-ietf-isis-pcr-05] (33 pages) - IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability [draft-ietf-isis-prefix-attributes-04] (9 pages) - TLV for Proprietary Use [draft-ietf-isis-proprietary-tlv-00] (5 pages) - Integrated ISIS Protocol Analysis [draft-ietf-isis-prot-anal-01] (20 pages) - Purge Originator Identification TLV for IS-IS [draft-ietf-isis-purge-tlv-05] (6 pages) - IS-IS Registry Extension for Purges [draft-ietf-isis-reg-purge-01] (4 pages) - IS-IS Minimum Remaining Lifetime [draft-ietf-isis-remaining-lifetime-04] (9 pages) - Restart Signaling for Intermediate System to Intermediate System (IS-IS) [draft-ietf-isis-restart-05] (21 pages) - IS-IS Routing with Reverse Metric [draft-ietf-isis-reverse-metric-09] (13 pages) - Reclassification of RFC 1142 to Historic [draft-ietf-isis-rfc1142-to-historic-00] (3 pages) - Dynamic Hostname Exchange Mechanism for IS-IS [draft-ietf-isis-rfc2763bis-00] (6 pages) - Domain-Wide Prefix Distribution with Two-Level IS-IS [draft-ietf-isis-rfc2966bis-03] (16 pages) - IS-IS Transient Blackhole Avoidance [draft-ietf-isis-rfc3277bis-00] (9 pages) - Three-Way Handshake for IS-IS Point-to-Point Adjacencies [draft-ietf-isis-rfc3373bis-01] (11 pages) - IS-IS Cryptographic Authentication [draft-ietf-isis-rfc3567bis-03] (11 pages) - Restart Signaling for IS-IS [draft-ietf-isis-rfc3847bis-00] (22 pages) - IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-isis-rfc4205bis-00] (12 pages) - IS-IS Extensions for Advertising Router Information [draft-ietf-isis-rfc4971bis-04] (10 pages) - Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS [draft-ietf-isis-rfc6326bis-03] (45 pages) - IS-IS Route Preference for Extended IP and IPv6 Reachability [draft-ietf-isis-route-preference-02] (11 pages) - Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS [draft-ietf-isis-sbfd-discriminator-02] (5 pages) - IS-IS Extensions for Segment Routing [draft-ietf-isis-segment-routing-extensions-15] (34 pages) - Signaling MSD (Maximum SID Depth) using IS-IS [draft-ietf-isis-segment-routing-msd-09] (9 pages) - YANG Data Model for IS-IS Segment Routing [draft-ietf-isis-sr-yang-03] (23 pages) - Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol Environments [draft-ietf-isis-tcpip-01] (98 pages) - IS-IS TE Attributes per application [draft-ietf-isis-te-app-03] (17 pages) - IS-IS Extensions for Traffic Engineering [draft-ietf-isis-te-bis-00] (17 pages) - IS-IS Traffic Engineering (TE) Metric Extensions [draft-ietf-isis-te-metric-extensions-11] (18 pages) - Updates to the IS-IS TLV Codepoints Registry [draft-ietf-isis-tlv-codepoints-02] (7 pages) - Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) [draft-ietf-isis-traffic-05] (13 pages) - Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance [draft-ietf-isis-transient-01] (6 pages) - Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS [draft-ietf-isis-trill-05] (25 pages) - IS-IS Support for Unidirectional Links [draft-ietf-isis-udl-02] (19 pages) - Maintaining more than 255 adjacencies in IS-IS [draft-ietf-isis-wg-255adj-02] (6 pages) - Simplified Extension of Link State PDU (LSP) Space for IS-IS [draft-ietf-isis-wg-extlsp-05] (12 pages) - IS-IS Mesh Groups [draft-ietf-isis-wg-mesh-group-01] (8 pages) - Management Information Base for Intermediate System to Intermediate System (IS-IS) [draft-ietf-isis-wg-mib-26] (103 pages) - M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) [draft-ietf-isis-wg-multi-topology-12] (14 pages) - IS-IS over IPv4 [draft-ietf-isis-wg-over-ip-02] (8 pages) - Optional Checksums in Intermediate System to Intermediate System (ISIS) [draft-ietf-isis-wg-snp-checksum-02] (4 pages) - Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System [draft-ietf-isis-wg-tlv-codepoints-00] (5 pages) - YANG Data Model for IS-IS protocol [draft-ietf-isis-yang-isis-cfg-19] (113 pages) - Extended Ethernet Frame Size Support [draft-kaplan-isis-ext-eth-02] (0 pages) - Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRT) [draft-li-isis-mrt-02] (15 pages) - ISIS Auto-Configuration [draft-liu-isis-auto-conf-06] (14 pages) - IS-IS Extensions for Segment Routing [draft-previdi-isis-segment-routing-extensions-05] (27 pages) - Advertising Per-node Admin Tags in IS-IS [draft-psarkar-isis-node-admin-tag-03] (13 pages) - Signaling MSD (Maximum SID Depth) using IS-IS [draft-tantsura-isis-segment-routing-msd-02] (6 pages) - Advertising Tunnelling Capability in IS-IS [draft-xu-isis-encapsulation-cap-07] (11 pages) - IS-IS Extensions for Flow Specification [draft-you-isis-flowspec-extensions-04] (15 pages) Requests for Comments: RFC2763: Dynamic Hostname Exchange Mechanism for IS-IS (5 pages) * Obsoletes RFC5301 RFC2966: Domain-wide Prefix Distribution with Two-Level IS-IS (14 pages) * Obsoletes RFC5302 RFC2973: IS-IS Mesh Groups (8 pages) RFC3277: Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance (6 pages) RFC3358: Optional Checksums in Intermediate System to Intermediate System (ISIS) (4 pages) RFC3359: Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System (5 pages) RFC3373: Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies (9 pages) * Obsoletes RFC5303 RFC3567: Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication (6 pages) * Obsoletes RFC5304 RFC3719: Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) (15 pages) RFC3784: Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) (13 pages) * Obsoletes RFC5305 * Updates RFC4205 RFC3786: Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit (14 pages) * Obsoletes RFC5311 RFC3787: Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) (11 pages) RFC3847: Restart Signaling for Intermediate System to Intermediate System (IS-IS) (21 pages) * Obsoletes RFC5306 RFC4205: Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (11 pages) * Updates RFC3784 * Obsoletes RFC5307 RFC4444: Management Information Base for Intermediate System to Intermediate System (IS-IS) (103 pages) RFC4971: Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information (9 pages) * Obsoletes RFC7981 RFC5029: Definition of an IS-IS Link Attribute Sub-TLV (6 pages) RFC5120: M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) (14 pages) RFC5130: A Policy Control Mechanism in IS-IS Using Administrative Tags (8 pages) RFC5301: Dynamic Hostname Exchange Mechanism for IS-IS (6 pages) * Obsoletes RFC2763 * Updates RFC6232 RFC5302: Domain-Wide Prefix Distribution with Two-Level IS-IS (16 pages) * Updates RFC1195 * Obsoletes RFC2966 RFC5303: Three-Way Handshake for IS-IS Point-to-Point Adjacencies (11 pages) * Obsoletes RFC3373 RFC5304: IS-IS Cryptographic Authentication (11 pages) * Updates RFC1195 * Obsoletes RFC3567 * Updates RFC6233 * Updates RFC6232 RFC5305: IS-IS Extensions for Traffic Engineering (17 pages) * Obsoletes RFC3784 * Updates RFC5307 RFC5306: Restart Signaling for IS-IS (22 pages) * Obsoletes RFC3847 RFC5307: IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (12 pages) * Obsoletes RFC4205 * Updates RFC5305 * Updates RFC6001 * Updates RFC6002 * Updates RFC7074 RFC5308: Routing IPv6 with IS-IS (7 pages) * Updates RFC7775 RFC5309: Point-to-Point Operation over LAN in Link State Routing Protocols (10 pages) RFC5310: IS-IS Generic Cryptographic Authentication (12 pages) * Updates RFC6233 * Updates RFC6232 RFC5311: Simplified Extension of Link State PDU (LSP) Space for IS-IS (12 pages) * Obsoletes RFC3786 RFC6119: IPv6 Traffic Engineering in IS-IS (10 pages) RFC6165: Extensions to IS-IS for Layer-2 Systems (7 pages) RFC6213: IS-IS BFD-Enabled TLV (7 pages) RFC6232: Purge Originator Identification TLV for IS-IS (6 pages) * Updates RFC5301 * Updates RFC5304 * Updates RFC5310 RFC6233: IS-IS Registry Extension for Purges (4 pages) * Updates RFC3563 * Updates RFC5304 * Updates RFC5310 RFC6326: Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS (25 pages) * Obsoletes RFC7176 RFC6329: IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging (37 pages) RFC6822: IS-IS Multi-Instance (14 pages) * Obsoletes RFC8202 RFC6823: Advertising Generic Information in IS-IS (11 pages) RFC7142: Reclassification of RFC 1142 to Historic (3 pages) * Obsoletes RFC1142 RFC7176: Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS (45 pages) * Obsoletes RFC6326 RFC7356: IS-IS Flooding Scope Link State PDUs (LSPs) (23 pages) RFC7370: Updates to the IS-IS TLV Codepoints Registry (7 pages) RFC7602: IS-IS Extended Sequence Number TLV (12 pages) RFC7775: IS-IS Route Preference for Extended IP and IPv6 Reachability (11 pages) * Updates RFC5308 RFC7794: IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability (9 pages) RFC7810: IS-IS Traffic Engineering (TE) Metric Extensions (18 pages) RFC7813: IS-IS Path Control and Reservation (33 pages) RFC7883: Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS (5 pages) RFC7917: Advertising Node Administrative Tags in IS-IS (11 pages) RFC7981: IS-IS Extensions for Advertising Router Information (10 pages) * Obsoletes RFC4971 RFC7987: IS-IS Minimum Remaining Lifetime (9 pages) RFC8196: IS-IS Autoconfiguration (15 pages) RFC8202: IS-IS Multi-Instance (16 pages) * Obsoletes RFC6822 JSON Mail Access Protocol (jmap) -------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Barry Leiba Bron Gondwana Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Alexey Melnikov 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: A number of JSON-based email access protocols have been developed that are proprietary, non-standard, and incompatible with each other. These protocols are proliferating due to existing standards being insufficient or poorly suited to the environments they are operating in, particularly mobile and webmail. The use of multiple protocols to perform actions within a single application creates significant support challenges, as users may get a variety of partial failure modes (for example, can receive email but cannot send new messages). This is further exacerbated if the different protocols are authenticated separately. JMAP specifies the interactions between email clients and mail stores, providing an alternative to IMAP and SMTP submission. The JMAP working group will specify a mechanism to allow clients to both view and send email from a server over a single HTTPS channel with minimal round trips. A single protocol for receipt and submission will resolve long- standing difficulties users face setting up clients to talk to servers. The protocol will support push notification of changes using the mechanism defined in RFC 8030. This will give mobile clients benefits in terms of battery life and network usage. It will also support push notifications via server-sent events (https://www.w3.org/TR/eventsource/) for direct connection to clients that can support persistent TCP connections. Work on JMAP will be bound by the following constraints: 1) The protocol will operate on RFC 5322/MIME (RFC 2045-2047, etc.) message objects or information extracted from them. 2) JMAP needs to be implementable on top of an IMAP server, which also supports IMAP extensions specified below. The JMAP data model needs to remain backwards compatible with the IMAP mailstore model (where a message is always associated with a single mailbox), but it might support other underlying models (e.g. Gmail-style labels). The Working Group will discuss and document how a single server or proxy implementation can implement both IMAP and JMAP at the same time. 3) "Email submission by placing into designated outbox mailbox" will take into consideration extensive IMAPEXT mailing list discussions on message submission through IMAP. 4) The work of this group is limited to developing a protocol for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 5) New end-to-end encryption mechanisms are out of scope, but the work should consider how to integrate with existing standards such as S/MIME and OpenPGP. 6) The working group will coordinate with the Security Area on credential management and authentication. The work will be based on draft-jenkins-jmap and draft-jenkins-jmapmail. Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. 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. However gratuitous changes to proposed design should be avoided. Input to working group discussions shall include: - CONDSTORE and QRESYNC [RFC 7162] - Collection Synchronisation for WebDav [RFC 6578] - IMAP SPECIAL-USE [RFC 6154] - IMAP SORT and THREAD Extensions [RFC 5256] - LEMONADE and experiences from adoption of its output [https://datatracker.ietf.org/wg/lemonade/charter/] - SMTP SUBMISSION [RFC 6409] - SMTP BURL [RFC 4468] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on a new protocol for client to server email synchronisation. The working group may choose not to publish this as an RFC. - A document describing an extensible protocol and data structures, with support for flood control and batched operations. - A document describing how to use the extensible protocol over HTTPS with the data structures expressed as JSON. - A document describing a data model for email viewing, management, searching, and submission on top of the extensible protocol. - A document describing how JMAP to IMAP/SUBMIT proxies can be implemented. Among different considerations, the document will cover security considerations involved in operating such a proxy. - A document describing how a dual IMAP and JMAP server implementation can be done. This can be combined with the above document, if that makes sense. - An executable test suite and documented test cases to assist developers of JMAP servers to ensure they conform to the specifications. Goals and Milestones: Jun 2017 - Submit detailed problem statement, if desired by the WG (Informational) Dec 2017 - Submit document describing generic protocol and data structures (Standards Track) Dec 2017 - Submit document describing mail data model and protocol (Standards Track) Mar 2018 - Submit document with guidance for implementation of IMAP servers and proxies (Informational) Internet-Drafts: - JSON Meta Application Protocol [draft-ietf-jmap-core-03] (44 pages) - JMAP for Mail [draft-ietf-jmap-mail-03] (42 pages) No Requests for Comments Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Benjamin Kaduk Matthew A. Miller Security Area Directors: Kathleen Moriarty Eric Rescorla Security Area Advisor: Eric Rescorla 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-02] (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) - 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-04] (31 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) - PKINIT Algorithm Agility [draft-ietf-kitten-pkinit-alg-agility-01] (18 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-06] (94 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-16] (34 pages) - Stackable Generic Security Service Pseudo-Mechanisms [draft-ietf-kitten-stackable-pseudo-mechs-02] (17 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) Requests for Comments: RFC4178: The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism (22 pages) * Obsoletes RFC2478 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) * Updates RFC2743 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 RFC2853 RFC6331: Moving DIGEST-MD5 to Historic (6 pages) * Obsoletes RFC2831 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) * Updates RFC4120 RFC7802: A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism (8 pages) * Obsoletes RFC4402 RFC8009: AES Encryption with HMAC-SHA2 for Kerberos 5 (19 pages) RFC8062: Anonymity Support for Kerberos (18 pages) * Obsoletes RFC6112 * Updates RFC4120 * Updates RFC4121 * Updates RFC4556 RFC8070: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension (9 pages) RFC8129: Authentication Indicator in Kerberos Tickets (6 pages) * Updates RFC4120 L2VPN Service Model (l2sm) -------------------------- Charter Last Modified: 2016-11-04 Current Status: Active Chairs: Adrian Farrel Qin Wu Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: l2sm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2sm Archive: https://mailarchive.ietf.org/arch/browse/l2sm/ Description of Working Group: The IETF and the industry in general is currently specifying a set of YANG models for network element and protocol configuration. This is an essential first step, but the end goal is a full system configuration that enables service agility to speed service creation and delivery and allows the deployment of innovative new services across networks. Services are built from a combination of network element and protocol configuration, but are specified to service users in more abstract terms. The Layer Two Virtual Private Network Service Model (L2SM) working group is a short-lived WG. It is tasked to create a YANG data model that describes a L2VPN service (a L2VPN customer service model). The model can be used for communication between customers and network operators, and to provide input to automated control and configuration applications. It is recognized that it would be beneficial to have a common base model that addresses multiple popular L2VPN service types. The working group will derive a single data model that includes support for the following: - point-to-point Virtual Private Wire Services (VPWS), - multipoint Virtual Private LAN services (VPLS) that use LDP-signaled Pseudowires - multipoint Virtual Private LAN services (VPLS) that use a Border Gateway Protocol (BGP) control plane as described in RFC4761 and RFC6624 - Ethernet VPNs specified in RFC 7432. Other L2VPN service types may be included if there is consensus in the working group. It needs to be clearly understood that this L2VPN customer service model is not an L2VPN configuration model. That is, it does not provide details for configuring network elements or protocols: that work is expected to be carried out in other protocol-specific working groups. Instead, the L2VPN customer service model contains the characteristics of the service as discussed between the operators and their customers. A separate process is responsible for mapping this customer service model onto the protocols and network elements depending on how the network operator chooses to realise the service. The deliverable from this working group will provide information that other working groups can use to evaluate the set of YANG models that they have already developed or that are under development. This will help them to identify any missing models or details. Thus, the deliverable can be viewed as driving requirements for service delivery models so that the customer service parameters can be mapped into inputs used by the protocol configuration models. The working group will learn from the experience of the L3SM working group and it is expected that the L2SM data model will have similar structure to the L3SM data model to enable benefits of common code, provide shared user experience, and leverage discussions that took place during the L3SM development. The working group should consider draft-wen-l2sm-l2vpn-service-model as a starting point. The working group will coordinate with other working groups responsible for L2VPN protocol work (most notably with BESS and PALS). It will also coordinate with other organizations working on related L2VPN data models (such as the MEF). Goals and Milestones: Dec 2016 - Adopt WG draft for data model Oct 2017 - Request publication of data model as Standards Track RFC Dec 2017 - Close working group Internet-Drafts: - A YANG Data Model for L2VPN Service Delivery [draft-ietf-l2sm-l2vpn-service-model-05] (149 pages) No Requests for Comments Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- Charter Last Modified: 2015-10-07 Current Status: Active Chairs: Carlos Pignataro Ignacio Goyret Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Deborah Brungard Mailing Lists: General Discussion: l2tpext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2tpext Archive: https://mailarchive.ietf.org/arch/browse/l2tpext/ Description of Working Group: This group is responsible for extensions to the Layer 2 Tunneling Protocol. Examples of L2TP "extensions" include any changes to the L2TP encapsulation, control messages, or new AVPs sent in IETF standard control messages. I. L2TP Background: L2TP (RFC2661) provides a means for tunneling PPP over IP. Because PPP can effectivly carry any traffic (e.g., IP (RFC 1332), IPX (RFC 1552), etc.) it can effectively be used to tunnel arbitrary protocols over IP. L2TP provides: - An extensible control protocol for dynamic setup, maintenance, and teardown of multiple layer 2 tunnels between two logical endpoints. - An encapsulation method for tunneling PPP frames between each endpoint. This includes multiplexing of multiple, discrete, PPP streams between each endpoint. L2TP looks (in most ways) like just another point-to-point link to PPP and may thereby take advantage of the work done for any protocol defined for use over a traditional PPP WAN link. It should be noted, however, that the ability to dynamically establish a PPP connection between any two IP connected endpoints brings new applications and challenges of scale to existing PPP implementations and protocol definitions that must be considered. As high-speed broadband access to the home replaces traditional dialup infrastructure, L2TP has been utilized as one standard method for aggregation and delivery of PPP connections over packet networks. Thus, rather than a relatively small scale or low speed circuit-switched connection such as an analog modem or ISDN connection at the L2TP Access Concentrator (LAC), we see PPP being received over ATM PVCs which are generally higher speed and "always-on" vs. temporally connected. Further, there are non-IETF standard PPP tunneling protocols that have been developed and deployed, including PPPoE (RFC 2516) and the 3GPP2 Wireless GPRS Tunneling Protocol Standard (http://www.3gpp.org) that interface with L2TP at various points in the network. While it is unfortunate that there is more than one standard method for tunneling PPP defined, each of these have their own installed bases and specific application-driven nuances. Proper integration with these various tunneling methods as they "hand-off" to the L2TP portion of the network must be ensured. II. L2TP Interaction with PWE3 for Pseudo-Wire Transport: In addition to tunneling PPP, L2TPEXT will develop protocol extensions necessary for the tunneling of specific "pseudo-wires" as defined in the PWE3 WG. Specific milestone identification for this activity is currently subject to ongoing work and results from PWE3. III. WG Activities The Working Group is currently focussed on the following activities: - RFC2661 bundles data transport, protocol signaling, and PPP emulation methods into a single document. This working group will separate RFC2661 into stand-alone documents for greater modularity. This will consist of a base L2TP document defining common tunneling constructs and encapsulation, and a PPP document defining the use of these constructs for tunneling of PPP sessions as defined in RFC2661. Documents for tunneling of pseudo-wires defined in PWE3 will be forthcoming as well. As RFC2661 is rewritten to separate the tunnel setup and maintenance sections for support of new applications and increased modularity, some modifications to the base protocol may be necessary. This includes addition of a Pseudo Wire AVP to identify the pseudo wire being carried (with PPP identified as 0). In all cases, these will follow the extensible models offered in the L2TP base protocol design, with as much attention to backwards compatibility as possible given the new requirements. In addition to its broader scope, L2TPEXT has ongoing work to complete from its inception as a tunneling protocol for PPP only. While RFC2661 will ultimately be made obsolete by a new L2TP base specification and companion PPP over L2TP specification, documents based on RFC2661 which do not require this new degree of modularity will still be published in the near term. These include: - Identification of specific parameters and modes of IPsec in order to aid interoperability when IPsec is used to secure L2TP traffic. - An L2TP MIB for network management. - An L2TP Differentiated Services Extension to negotiate DSCP parameters to be set for packets associated with a given L2TP tunnel, sessions within a tunnel, or L2TP control traffic which may need differentiated QoS settings. - Extensions to L2TP for additional or more robust control information for informational or operational purposes as deemed necessary based on operational experience. These include better transfer of L2TP PPP LCP Information between tunnel endpoints when such state needs to be shared, PPP Disconnect codes within L2TP control messages for better debugging, and L2TP session information for enhanced logging, billing, and error reporting. - Standard methods for operation over such packet networks such as Frame Relay and AAL5. - L2TP defines a base encapsulation for operation in typical environments for tunneling PPP at the time RFC2661 was being developed. In cases where bandwidth cost is at a premium, the size of the L2TP header becomes more significant. L2TP will define a compressed version of the L2TP header for these environments that takes advantage of the L2TP control plane to establish operational parameters allowing removal of information from individual packets. Goals and Milestones: Done - Submit L2TP over Frame Relay to IESG for consideration as a Proposed Standard Done - Submit L2TP Security to IESG for consideration as a Proposed Standard Done - Submit L2TP PPP Disconnect Information to IESG for consideration as a Proposed Standard Done - Submit L2TP ATM extensions to IESG for consideration as a Proposed Standard Done - Submit L2TP MIB to IESG for consideration as a Proposed Standard Done - Submit L2TP Link Information to IESG for consideration as a Proposed Standard Done - Submit L2TP Session Info to IESG for consideration as a Proposed Standard Done - Submit L2TP Differentiated Services to IESG for consideration as a Proposed Standard Done - Submit L2TP over AAL5 to IESG for consideration as a Proposed Standard Done - Submit initial Internet-Draft of L2TP Base Specification Done - Submit initial Internet-Draft of PPP over L2TP Done - Submit final Internet-Draft of L2TPv3 Base Specification to IESG Done - Submit Internet-Draft of HDLC over L2TPv3 to IESG Done - Submit Internet-Draft of Frame Relay over L2TPv3 to IESG Done - Submit L2VPN Extensions for L2TP to IESG Done - Submit Internet-Draft of Ethernet over L2TPv3 to IESG Done - WG Last Call on L2TP Failover Mar 2008 - Submit Internet-Draft of PPP over L2TPv3 to IESG Done - WG Last Call on TDM over L2TPv3 Jun 2008 - WG Last Call on IP over L2TPv3 Internet-Drafts: - Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) [draft-dasilva-l2tp-relaysvc-08] (17 pages) - Advertising S-BFD Discriminators in L2TPv3 [draft-gp-l2tpext-sbfd-discriminator-00] (5 pages) - Layer Two Tunneling Protocol - Setup of TDM Pseudowires [draft-ieft-l2tpext-tdm-03] (8 pages) - L2TP Alternate Data Channel ('ADC') [draft-ietf-l2tpext-adc-00] (4 pages) - Layer Two Tunnelling Protocol (L2TP): ATM access network extensions [draft-ietf-l2tpext-atmext-04] (19 pages) - Layer Two Tunneling Protocol : ATM Access Network Extensions [draft-ietf-l2tpext-atmext-rfc3301-bis-00] (18 pages) - Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values [draft-ietf-l2tpext-circuit-status-extensions-05] (11 pages) - Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension [draft-ietf-l2tpext-ds-05] (10 pages) - Ethernet Service Type for Layer Two Tunneling Protocol [draft-ietf-l2tpext-eth-00] (6 pages) - Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" [draft-ietf-l2tpext-failover-12] (26 pages) - Layer Two Tunneling Protocol (L2TP) over Frame Relay [draft-ietf-l2tpext-fr-01] (7 pages) - Keyed IPv6 Tunnel [draft-ietf-l2tpext-keyed-ipv6-tunnel-07] (12 pages) - A YANG Data Model for Keyed IPv6 Tunnels [draft-ietf-l2tpext-keyed-v6-tunnel-yang-03] (15 pages) - Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) [draft-ietf-l2tpext-l2tp-atm-03] (13 pages) - Layer Two Tunneling Protocol - Version 3 (L2TPv3) [draft-ietf-l2tpext-l2tp-base-15] (94 pages) - Layer Two Tunneling Protocol "L2TP" Management Information Base [draft-ietf-l2tpext-l2tp-mib-04] (70 pages) - PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-l2tp-ppp-08] (44 pages) - Layer Two Tunneling Protocol 'L2TP' [draft-ietf-l2tpext-l2tpbis-01] (77 pages) - L2TP Header Compression ('L2TPHC') [draft-ietf-l2tpext-l2tphc-06] (7 pages) - Layer Two Tunneling Protocol (Version 3) "L2TPv3" Management Information Base [draft-ietf-l2tpext-l2tpmib-base-02] (55 pages) - Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-l2vpn-07] (15 pages) - Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation [draft-ietf-l2tpext-link-07] (10 pages) - Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-mcast-05] (28 pages) - Layer Two Tunneling Protocol 'L2TP' Multi-Protocol Label Switching Extension [draft-ietf-l2tpext-mpls-00] (5 pages) - L2TP Disconnect Cause Information [draft-ietf-l2tpext-ppp-discinfo-04] (10 pages) - L2TP Proxy Authenticate Extensions for EAP [draft-ietf-l2tpext-proxy-authen-ext-eap-02] (11 pages) - Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-pwe3-atm-04] (26 pages) - Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-pwe3-ethernet-09] (14 pages) - Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-pwe3-fr-07] (14 pages) - High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) [draft-ietf-l2tpext-pwe3-hdlc-07] (11 pages) - Signaling and Encapsulation for the Transport of IP over L2TPv3 [draft-ietf-l2tpext-pwe3-ip-05] (20 pages) - RADIUS & L2TP Extended NAS-Port AVPs [draft-ietf-l2tpext-radius-ext-nas-port-02] (14 pages) - Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update [draft-ietf-l2tpext-rfc2661-iana-01] (5 pages) - Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-sbfd-discriminator-05] (6 pages) - Securing L2TP using IPsec [draft-ietf-l2tpext-security-08] (28 pages) - L2TP Session Information (``SESINFO'') [draft-ietf-l2tpext-sesinfo-04] (4 pages) - L2TP Service Type [draft-ietf-l2tpext-svctype-01] (7 pages) - Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires [draft-ietf-l2tpext-tdm-07] (11 pages) - PPP over L2TP Tunnel Switching [draft-ietf-l2tpext-tunnel-switching-08] (16 pages) - Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-v92-moh-05] (13 pages) - L2TP Over AAL5 and FUNI [draft-ietf-pppext-l2tp-atm-02] (11 pages) - Layer Two Tunnelling Protocol : ATM access network extensions. [draft-ietf-pppext-l2tp-atmext-01] (14 pages) - Layer Two Tunneling Protocol ''L2TP'' IP Differential Services Extension [draft-ietf-pppext-l2tp-ds-03] (5 pages) - Layer Two Tunneling Protocol (L2TP) over Frame Relay [draft-ietf-pppext-l2tp-fr-02] (7 pages) - Layer Two Tunneling Protocol 'L2TP' Management Information Base [draft-ietf-pppext-l2tp-mib-05] (68 pages) - Layer Two Tunneling Protocol ''L2TP'' Multi-Protocol Label Switching Extension [draft-ietf-pppext-l2tp-mpls-02] (5 pages) - Securing L2TP using IPSEC [draft-ietf-pppext-l2tp-security-05] (14 pages) - A YANG Data Model for Keyed IPv6 Tunnels [draft-sun-l2tpext-keyed-v6-tunnel-yang-01] (14 pages) Requests for Comments: BCP68: Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update (5 pages) RFC3070: Layer Two Tunneling Protocol (L2TP) over Frame Relay (7 pages) RFC3145: L2TP Disconnect Cause Information (10 pages) RFC3193: Securing L2TP using IPsec (28 pages) RFC3301: Layer Two Tunnelling Protocol (L2TP): ATM access network extensions (19 pages) RFC3308: Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension (10 pages) RFC3355: Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) (13 pages) RFC3371: Layer Two Tunneling Protocol "L2TP" Management Information Base (70 pages) RFC3437: Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation (10 pages) RFC3438: Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update (5 pages) RFC3573: Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) (13 pages) RFC3817: Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) (17 pages) RFC3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3) (94 pages) * Updates RFC5641 RFC4045: Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP) (28 pages) RFC4349: High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) (11 pages) * Updates RFC5641 RFC4454: Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (26 pages) * Updates RFC5641 RFC4591: Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (14 pages) * Updates RFC5641 RFC4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) (15 pages) RFC4719: Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (14 pages) * Updates RFC5641 RFC4951: Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" (26 pages) RFC5611: Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires (11 pages) RFC5641: Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values (11 pages) * Updates RFC3931 * Updates RFC4349 * Updates RFC4454 * Updates RFC4591 * Updates RFC4719 RFC7886: Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3) (6 pages) RFC8159: Keyed IPv6 Tunnel (12 pages) Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chair: Russ Housley Security Area Directors: Kathleen Moriarty Eric Rescorla Security Area Advisor: Eric Rescorla 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 current charter encompasses updates to satisfy the following needs: 1. Specify the way to include an i18n email address as a subject alternative name and an issuer alternative name. draft-melnikov-spasm-eai-addresses is a proposal in this space. 2. Specify the way to use authenticated encryption in S/MIME. draft-schaad-rfc5751-bis is a proposal in this space. In addition, the LAMPS Working Group may investigate other updates to the documents produced by the PKIX and S/MIME Working Groups, but the LAMPS Working Group shall not adopt any of these potential work items without rechartering. No such re-chartering is envisaged until one or more of the above work items have been successfully delivered to the RFC editor queue. Goals and Milestones: Done - WG adoption of a draft to specify the way to use authenticated encryption in S/MIME Done - WG adoption of a draft to specify the way to include an i18n email address as a subject alternative name and an issuer alternative name Jan 2017 - WGLC for a draft to specify the way to include an i18n email address as a subject alternative name and an issuer alternative name Apr 2017 - WGLC for draft to specify the way to use authenticated encryption in S/MIME Internet-Drafts: - Internationalized Email Addresses in X.509 certificates [draft-ietf-lamps-eai-addresses-16] (11 pages) - Put Your Internet Draft Title Here [draft-ietf-lamps-pkix-shake-00] (7 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-04] (25 pages) - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification [draft-ietf-lamps-rfc5751-bis-06] (57 pages) No Requests for Comments Layer Independent OAM Management in the Multi-Layer Environment (lime) ---------------------------------------------------------------------- Charter Last Modified: 2015-06-15 Current Status: Active Chairs: Carlos Pignataro Ron Bonica Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: lime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lime Archive: https://mailarchive.ietf.org/arch/browse/lime/ Description of Working Group: Network Operators are increasingly challenged with operational and management limitations in network deployments due to Operations, Administration, and Maintenance (OAM) operating at different administrative and technology layers. This problem is exacerbated by the lack of a common architectural OAM management in those different layers and protocols. New work on network virtualization further complicates the layering model and the problems of coordinating OAM between layers and protocols. The absence of a common approach to OAM management has made it difficult for operators to: - Suppress large numbers of unnecessary alarms and notifications related to defects and failures arising in lower layers and visible in each higher layer - Quickly identify root causes of network failures - Coordinate end-to-end performance measurement with the results of performance monitoring at different layers in the network - Correlate defects, faults, and network failures between the different layers to improve efficiency of defect and fault localization and provide better OAM visibility. The LIME working group will concentrate on the operational challenges in consistent handling of end-to-end OAM and coordination of OAM within underlying network layers. This work will enable consistent configuration, reporting, and presentation for the OAM mechanisms used to manage the network, regardless of the layers and technologies, including management mechanisms to facilitate better mapping between information reported from OAM mechanisms that operate in different network layers. It will also produce architectural guidelines for the development of new OAM tools and protocols in both management plane and data plane so that they may be coherent with these mechanisms and more easily integrated from an operational points of view. The working group will work on the following deliverables: - YANG data model(s) for generic layer-independent and technology-independent configuration, reporting and presentation for OAM mechanisms. - An architecture for OAM that can be used as guidance by other IETF working groups developing new OAM protocols or modifying existing OAM protocols, at any layer and for any technology. This guidance will cover both the management and data planes. Existing OAM architectures will be reviewed. - Applicability document: The YANG model(s) specified in this working group must be usable and extensible by the existing OAM technologies. This usability and extensibility must be demonstrated, for example with IP Ping, traceroute, BFD, and LSP Ping. Note the technology-specific data model extensions should ideally be worked on in the respective working groups. The working group will explore and document use-cases for converged management of OAM in multi-layer and multi-technology networks that triggered this work. The use cases will consider scenarios that include (but are not limited to) those that rely upon a centralized control point responsible for the overall OAM management and those that assume the delegation of layer-specific OAM management control points. The working group will decide later whether the use case document needs to be published as an RFC. If the working group finds it necessary to work on an information model before the data model, it might do so. The working group will decide later whether the information model needs to be published as an RFC. The initial scope is restricted to a single administrative domain and may be extended for inter-domain scenarios in future as and when a need rises. The working group will not develop any new OAM protocols. The LIME WG is not chartered to work on information or data models specific to any data plane or forwarding plane technology that is developed outside of the IETF. However, it is the intention that the generic information and data models produced by the working group should be applicable to multiple layers and technologies in a technology agnostic fashion. Therefore, it is anticipated that the working group will closely coordinate its activities with other SDOs (including, but not limited to the ITU-T, MEF, IEEE, BBF and 3GPP) to ensure that the generic models are harmonized with work done in those SDOs and are applicable to many technologies. Goals and Milestones: Feb 2015 - Adopt the WG draft on YANG data model(s) May 2015 - Adopt the WG draft on LIME Architecture Aug 2015 - Adopt the WG draft for Applicability of the generic model Sep 2015 - Submit the YANG model(s) document to IESG as a Proposed Standards RFC Nov 2015 - Submit the Architecture document to IESG for review as an informational RFC Apr 2016 - Submit the Applicability document to IESG for review as an Informational RFC Apr 2016 - Recharter or conclude Internet-Drafts: - Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols [draft-ietf-lime-yang-connection-oriented-oam-model-04] (53 pages) - Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols that use Connectionless Communications [draft-ietf-lime-yang-connectionless-oam-18] (57 pages) - Retrieval Methods YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols that use Connectionless Communications [draft-ietf-lime-yang-connectionless-oam-methods-13] (37 pages) - Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols [draft-ietf-lime-yang-oam-model-10] (52 pages) - Generic YANG Data Model for Connection Less Operations, Administration, and Maintenance(OAM) protocols [draft-kumar-lime-yang-connectionless-oam-05] (62 pages) - Generic YANG Data Model for Operations, Administration, and Maintenance (OAM) [draft-tissa-lime-yang-oam-model-06] (48 pages) No Requests for Comments Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2017-03-15 Current Status: Active Chairs: Joel M. Halpern Luigi Iannone Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Deborah Brungard Secretaries: Padma Pillay-Esnault Wassim Haddad 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: - 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 EID Anonymity [draft-farinacci-lisp-eid-anonymity-02] (9 pages) - LISP Geo-Coordinate Use-Cases [draft-farinacci-lisp-geo-04] (10 pages) - LISP Canonical Address Format (LCAF) [draft-farinacci-lisp-lcaf-10] (29 pages) - LISP Distinguished Name Encoding [draft-farinacci-lisp-name-encoding-04] (5 pages) - LISP Predictive RLOCs [draft-farinacci-lisp-predictive-rlocs-02] (13 pages) - LISP Traffic Engineering Use-Cases [draft-farinacci-lisp-te-12] (18 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-24] (75 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 EID Anonymity [draft-ietf-lisp-eid-anonymity-01] (9 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-01] (23 pages) - LISP Generic Protocol Extension [draft-ietf-lisp-gpe-00] (8 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-01] (22 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) - 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-01] (14 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-rfc6830bis-08] (53 pages) - Locator/ID Separation Protocol (LISP) Control-Plane [draft-ietf-lisp-rfc6833bis-07] (42 pages) - LISP-Security (LISP-SEC) [draft-ietf-lisp-sec-14] (23 pages) - Signal-Free LISP Multicast [draft-ietf-lisp-signal-free-multicast-07] (23 pages) - LISP Traffic Engineering Use-Cases [draft-ietf-lisp-te-01] (17 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 LCAF [draft-ietf-lisp-vendor-lcaf-00] (5 pages) - LISP Virtual Private Networks (VPNs) [draft-ietf-lisp-vpn-01] (16 pages) - LISP YANG Model [draft-ietf-lisp-yang-06] (56 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) - 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) * Updates RFC6830 Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Dan Romascanu Jason Weil Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: lmap@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/lmap Archive: https://mailarchive.ietf.org/arch/browse/lmap/ Description of Working Group: The Large-Scale Measurement of Broadband Performance (LMAP) working group standardizes the LMAP measurement system for performance measurements of broadband access devices such as home and enterprise edge routers, personal computers, mobile devices, set top box, whether wired or wireless. Measuring portions of the Internet on a large scale is essential for accurate characterizations of performance over time and geography, for network diagnostic investigations by providers and their users, and for collecting information to support public policy development. The goal is to have the measurements (made using the same metrics and mechanisms) for a large number of points on the Internet, and to have the results collected and stored in the same form. The LMAP working group is chartered to specify an information model, the associated data models, and select/extend one or more protocols for the secure communication: 1. A Control Protocol, from a Controller to instruct Measurement Agents what performance metrics to measure, when to measure them, how/when to report the measurement results to a Collector, 2. A Report Protocol, for a Measurement Agent to report the results to the Collector. The data models should be extensible for new and additional measurements. LMAP will consider re-use of existing data models languages. A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator). However, the components of an LMAP measurement system can be deployed in administrative domains that are not owned by the measuring organization. Thus, the system of functions deployed by a single organization constitutes a single LMAP domain which may span ownership or other administrative boundaries. The LMAP architecture will allow for measurements that utilize either IPv4 or IPv6, or possibly both. Devices containing Measurement Agents may have several interfaces using different link technologies. Multiple address families and interfaces must be considered in the Control and Report protocols. It is assumed that different organization's LMAP measurement domains can overlap, and that active measurement packets appear along with normal user traffic when crossing another organization's network. There is no requirement to specify a mechanism for coordination between the LMAP measurements in overlapping domains (for instance a home network with MAs on the home gateway, set top box and laptop). In principle, there are no restrictions on the type of device in which the MA function resides. Both active and passive measurements are in scope, although there may be differences in their applicability to specific use cases, or in the security measures needed according to the threats specific to each measurement category. LMAP will not standardize performance metrics. The LMAP WG will consider privacy as a core requirement and will ensure that by default measurement and collection mechanisms and protocols standardized operate in a privacy-sensitive manner, for example, ensuring that measurements are not personally identifying except where permission for such has been granted by identified subjects. Note that this does not mean that all uses of LMAP need to turn on all privacy features but it does mean that privacy features do need to be at least well-defined. Standardizing control of end users Measurement Agents is out of scope. However, end users can obtain an MA to run measurement tasks if desired and report their results to whomever they want, most likely the supplier of the MA. This provides for user-initiated on-demand measurement, which is an important component of the ISP use case. Inter-organization communication of results is out of scope of the LMAP charter. The management protocol to bootstrap the MAs in measurement devices is out of scope of the LMAP charter. Service parameters, such as product category, can be useful to decide which measurements to run and how to interpret the results. These parameters are already gathered and stored by existing operations systems. Discovering the service parameters on the MAs or sharing the service parameters between MAs are out of the scope. However, if the service parameters are available to the MAs, they could be reported with the measurement results in the Report Protocol. Deciding the set of measurements to run is a business decision and is out of scope of the LMAP charter. Protection against the intentional or malicious insertion of inaccuracies into the overall system or measurement process (sometimes known as "gaming the system") is outside the scope of work. The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the information model, and with other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics. The LMAP WG will produce the following work items: 1. The LMAP Framework - provides common terminology, basic architecture elements, and justifies the simplifying constraints 2. The LMAP Use Cases - provides the motivating use cases as a basis for the work 3. Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes * The metric(s) that can be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed) * The schedule: when the measurement should be run and how the results should be reported (when and to which Collector) * The report: the metric(s) measured and when, the actual result, and supporting metadata such as location. Result reports may be organized in batches or may be reported immediately, such as for an on-demand measurement. 4. The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This may be a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or NETCONF). 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). Goals and Milestones: Sep 2013 - Initial WG I-D for the LMAP Framework including terminology Sep 2013 - Initial WG I-D for the LMAP Use cases Dec 2013 - Submit the LMAP Framework I-D to the IESG for consideration as Informational RFC Dec 2013 - Submit I-D on the LMAP Use cases to the IESG for consideration as Informational RFC Jan 2014 - Initial WG I-D for LMAP Information models Apr 2014 - Initial WG I-D for the Control protocol Apr 2014 - Initial WG I-D for the Report protocol Apr 2014 - Initial WG I-D for a Data model for LMAP control information Apr 2014 - Initial WG I-D for a Data model for LMAP report information Jul 2014 - Submit the LMAP Information models I-D to the IESG for consideration as Standards track RFC Dec 2014 - Submit the Control protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 - Submit the Report protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 - Submit the Data model for LMAP control I-D to the IESG for consideration as Standards track RFC Dec 2014 - Submit the Data model for LMAP report I-D to the IESG for consideration as Standards track RFC Internet-Drafts: - A Framework for Large-Scale Measurement of Broadband Performance (LMAP) [draft-ietf-lmap-framework-14] (55 pages) - Information Model for Large-Scale Measurement Platforms (LMAPs) [draft-ietf-lmap-information-model-18] (53 pages) - Using RESTCONF with LMAP Measurement Agents [draft-ietf-lmap-restconf-04] (11 pages) - Router Buffer Sizes In The WAN [draft-ietf-lmap-router-buffer-sizes-ksubram-00] (9 pages) - Large-Scale Broadband Measurement Use Cases [draft-ietf-lmap-use-cases-06] (17 pages) - A YANG Data Model for LMAP Measurement Agents [draft-ietf-lmap-yang-12] (59 pages) Requests for Comments: RFC7536: Large-Scale Broadband Measurement Use Cases (17 pages) RFC7594: A Framework for Large-Scale Measurement of Broadband Performance (LMAP) (55 pages) RFC8193: Information Model for Large-Scale Measurement Platforms (LMAPs) (53 pages) RFC8194: A YANG Data Model for LMAP Measurement Agents (59 pages) IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- Charter Last Modified: 2016-10-14 Current Status: Active Chairs: Alexander Pelov Pascal Thubert Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Suresh Krishnan 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. To unleash the full power of LPWA technologies and their ecosystems, there is a need to couple them with other ecosystems that 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 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 to ensure that the work taking place corresponds to real demands and that the proposed solutions are indeed applicable. The group will produce informational work describing LPWA technologies and their needs as well as new standard work to optimize IPv6-based communications to the end device The group will: 1. Produce an Informational document describing and relating some selected LPWA technologies. This work will document the common characteristics and highlight actual needs that the IETF could serve; but it is not intended to provide a competitive analysis. It is expected that the information contained therein originates from and is reviewed by people who work on the respective LPWA technologies. 2. Produce a Standards Track document to enable the compression and fragmentation of a CoAP/UDP/IPv6 packet over LPWA networks. This will be achieved through stateful mechanisms, specifically designed for star topology and severely constrained links. The work will include the definition of generic data models to describe the compression and fragmentation contexts. This work may also include to define technology- specific adaptations of the generic compression/fragmentation mechanism wherever necessary. Goals and Milestones: Done - Adopt LPWAN specifications as WG item Done - Adopt IP/UDP compression and fragmentation mechanism as a WG item Done - Adopt CoAP compression mechanism as a WG item Done - Submit LPWAN specification to the IESG for publication as an Informational Document May 2017 - Submit IP/UDP compression and fragmentation mechanism to the IESG for publication as a Proposed Standard Jul 2017 - Submit CoAP compression mechanism to the IESG for publication as a Proposed Standard Internet-Drafts: - LPWAN Static Context Header Compression (SCHC) for CoAP [draft-ietf-lpwan-coap-static-context-hc-02] (18 pages) - LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP [draft-ietf-lpwan-ipv6-static-context-hc-09] (56 pages) - LPWAN Overview [draft-ietf-lpwan-overview-08] (43 pages) No Requests for Comments Light-Weight Implementation Guidance (lwig) ------------------------------------------- Charter Last Modified: 2017-09-19 Current Status: Active Chairs: Mohit Sethi Zhen Cao Internet Area Directors: Suresh Krishnan Terry Manderson Internet Area Advisor: Suresh Krishnan 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: 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 Dec 2016 - Submit the energy efficient implementation guidance document to the IESG for publication as an Informational RFC Jan 2017 - Submit the lightweight crypto implementation document to the IESG for publication as an Informational RFC Mar 2017 - Submit the CoAP implementation document to the IESG for publication as an Informational RFC Nov 2017 - Submit the TCP over constrained networks guidance document to the IESG for publication as an Informational RFC Mar 2018 - Submit the minimal ESP guidance document to the IESG for publication as an Informational RFC Internet-Drafts: - TCP over Constrained-Node Networks [draft-gomez-lwig-tcp-constrained-node-networks-03] (17 pages) - Building Power-Efficient CoAP Devices for Cellular Networks [draft-ietf-lwig-cellular-06] (16 pages) - CoAP Implementation Guidance [draft-ietf-lwig-coap-05] (30 pages) - Practical Considerations and Implementation Experiences in Securing Smart Object Networks [draft-ietf-lwig-crypto-sensors-05] (33 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) - Neighbor Management Policy for 6LoWPAN [draft-ietf-lwig-nbr-mgmt-policy-00] (18 pages) - TCP Usage Guidance in the Internet of Things (IoT) [draft-ietf-lwig-tcp-constrained-node-networks-01] (20 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) Requests for Comments: RFC7228: Terminology for Constrained-Node Networks (17 pages) RFC7815: Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation (41 pages) Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2015-06-15 Current Status: Active Chairs: Justin Dean Stan Ratliff Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Alvaro Retana Secretary: Ulrich Herberg 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 DiffServ Aware Credit Windowing Extension [draft-ietf-manet-dlep-da-credit-extension-03] (24 pages) - DLEP Lantency Range Extension [draft-ietf-manet-dlep-latency-extension-01] (5 pages) - Link Identifier Extension to DLEP [draft-ietf-manet-dlep-lid-extension-01] (8 pages) - DLEP Multi-Hop Forwarding Extension [draft-ietf-manet-dlep-multi-hop-extension-03] (10 pages) - DLEP Control Plane Based Pause Extension [draft-ietf-manet-dlep-pause-extension-02] (11 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) * Obsoletes RFC6622 RFC7183: Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) (15 pages) * Updates RFC7181 * Updates RFC6130 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) * Updates RFC7181 RFC7188: Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs (16 pages) * Updates RFC7181 * Updates RFC6130 * 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) * Updates RFC6130 * Updates RFC7181 RFC7631: TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format (15 pages) * Updates RFC5444 * Updates RFC7722 RFC7722: Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) (23 pages) * Updates RFC7188 * Updates RFC7631 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) * Obsoletes RFC6779 RFC7985: Security Threats to Simplified Multicast Forwarding (SMF) (15 pages) * Updates RFC7186 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) * Updates RFC5444 MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Greg Shepherd Leonard Giuliano Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Warren Kumari Tech Advisor: Scott Bradner Mailing Lists: General Discussion: mboned@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mboned Archive: https://mailarchive.ietf.org/arch/browse/mboned/ Description of Working Group: The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet, inter-domain and single domain. This activity will include, but not be limited to: - Document deployment of multicast routing in the global Internet. - Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies. - Based on reports and other information, provide feedback to other relevant working groups. - Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects. - Analyze the need for IPv4 - IPv6 multicast transition solutions - Develop tools, extend protocols and provide operational and implementation advice that assists in multicast administration, diagnostics, troubleshooting and deployment between/within native and non-native environments. - Development of routing and group membership protocols is out of scope. This working group may develop requirements and assist in review and feedback of documents in other working groups responsible for such protocols. Goals and Milestones: Jan 2014 - Submit Mtracev2 to IESG for Proposed Standards Mar 2014 - Work with TSV area to submit multicast transport guidelines for congestion control Mar 2014 - Submit Overview of Multicast in the Data Center to IESG for Informational Internet-Drafts: - IPv6 Multicast Address With Embedded IPv4 Multicast Address [draft-ietf-mboned-64-multicast-address-format-06] (12 pages) - Overview of the Internet Multicast Addressing Architecture [draft-ietf-mboned-addrarch-07] (14 pages) - Lightweight Multicast Address Discovery Problem Space [draft-ietf-mboned-addrdisc-problems-02] (11 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-admin-ip-space-05] (8 pages) - 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) - Multicast in the Data Center Overview [draft-ietf-mboned-dc-deploy-01] (11 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-01] (20 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-22] (36 pages) - AAA and Admission Control Framework for Multicasting [draft-ietf-mboned-multiaaa-framework-12] (22 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) - 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) BCP23: Administratively Scoped IP Multicast (8 pages) BCP51: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) * Updates RFC2780 * Obsoletes RFC3138 * Obsoletes RFC3171 BCP53: GLOP Addressing in 233/8 (5 pages) * Obsoletes RFC2770 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) * Obsoletes RFC2770 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 RFC3306 * 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) * Obsoletes RFC2932 RFC5771: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) * Updates RFC2780 * Obsoletes RFC3138 * Obsoletes RFC3171 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) * Obsoletes RFC2908 RFC6450: Multicast Ping Protocol (24 pages) RFC6676: Multicast Addresses for Documentation (7 pages) RFC7450: Automatic Multicast Tunneling (82 pages) RFC8313: Use of Multicast across Inter-domain Peering Points (44 pages) Managed Incident Lightweight Exchange (mile) -------------------------------------------- Charter Last Modified: 2016-04-20 Current Status: Active Chairs: Nancy Cam-Winget Takeshi Takahashi Security Area Directors: Kathleen Moriarty Eric Rescorla Security Area Advisor: Kathleen Moriarty 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 Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. The MILE WG is focused on two areas: IODEF, the data format and extensions to represent incident and indicator data, and RID, the policy and transport for structured data. With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience. Use by 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) and the recent cyber security Executive Order in the US. International groups, such as 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 or are working to develop data representations relevant to their use cases that may compliment/extend IODEF or be useful to exchange using RID and related transport protocols. - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. - Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. - RID may require modifications to address data provenance, additional policy options, or other changes now that there are multiple interoperable implementations of RFC6545 and RFC6546. With the RID implementations in the open source community, increased use and experimentation may demonstrate the need for a revision. Goals and Milestones: Done - Submit a draft on the representation of Structured Cybersecurity Information in IODEF to the IESG for publication as a Standards Track RFC Done - Submit a draft on enumeration reference formats for IODEF to the IESG for publication as a Standards Track RFC Done - Submit an update of RFC5070 to the IESG for publication as a Standards Track RFC Mar 2017 - Submit a draft on RESTful indicator exchange using IODEF/RID to the IESG for publication as an Informational RFC Mar 2017 - Submit a draft on guidance for IODEF applications to the IESG for publication as an Informational RFC Mar 2017 - 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 IODEF [draft-ietf-mile-jsoniodef-02] (55 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 [draft-ietf-mile-rolie-16] (45 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 XMPP for Security Information Exchange [draft-ietf-mile-xmpp-grid-04] (21 pages) Requests for Comments: RFC6545: Real-time Inter-network Defense (RID) (84 pages) * Obsoletes RFC6045 RFC6546: Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS (8 pages) * Obsoletes RFC6046 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) * Updates RFC5070 * 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) * Obsoletes RFC5070 * Obsoletes RFC6685 RFC8134: Management Incident Lightweight Exchange (MILE) Implementation Report (16 pages) RFC8274: Incident Object Description Exchange Format Usage Guidance (33 pages) Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Last Modified: 2015-10-16 Current Status: Active Chairs: Bo Burman Flemming Andreasen Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Ben Campbell 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 Aug 2017 - Submit RTP Payload Format Constraints as Proposed Standard Sep 2017 - Submit SDP Negotiation of DataChannel sub-protocols as Proposed Standard Sep 2017 - Submit Interactive Connectivity Establishment (ICE) with SDP offer/answer and SIP as Proposed Standard Oct 2017 - Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard Oct 2017 - Submit SIP usage for Trickle ICE as Proposed Standard Oct 2017 - Submit Using Simulcast in SDP and RTP Sessions as Proposed Standard Dec 2017 - Submit Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile as Proposed Standard Mar 2018 - Submit revised SDP specification to IETF as Proposed Standard Mar 2018 - Submit MSRP over Data Channels as Proposed Standard Mar 2018 - Submit Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol as Proposed Standard Internet-Drafts: - 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-16] (42 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-16] (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) - 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-16] (18 pages) - MSRP over Data Channels [draft-ietf-mmusic-msrp-usage-data-channel-07] (17 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-24] (58 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-13] (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-48] (67 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-16] (96 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-11] (40 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 Transport Layer Security with the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-uks-01] (13 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) - 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 Trickle ICE [draft-ietf-mmusic-trickle-ice-sip-12] (45 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) * Obsoletes RFC2543 * Updates RFC6157 RFC3266: Support for IPv6 in Session Description Protocol (SDP) (5 pages) * Updates RFC2327 * Obsoletes RFC4566 RFC3388: Grouping of Media Lines in the Session Description Protocol (SDP) (11 pages) * Obsoletes RFC5888 RFC3524: Mapping of Media Streams to Resource Reservation Flows (6 pages) RFC3605: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) (8 pages) RFC3890: A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) (22 pages) RFC4091: The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework (7 pages) * Obsoletes RFC5245 RFC4145: TCP-Based Media Transport in the Session Description Protocol (SDP) (15 pages) * Updates RFC4572 RFC4317: Session Description Protocol (SDP) Offer/Answer Examples (24 pages) RFC4435: A Framework for the Usage of Internet Media Guides (IMGs) (22 pages) RFC4473: Requirements for Internet Media Guides (IMGs) (23 pages) RFC4566: SDP: Session Description Protocol (49 pages) * Obsoletes RFC2327 * Obsoletes RFC3266 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) * Updates RFC4145 * 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) * Updates RFC3312 RFC5245: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols (117 pages) * Obsoletes RFC4091 * Obsoletes RFC4092 * Updates RFC6336 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) * Obsoletes RFC3388 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) * Obsoletes RFC4756 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) * Updates RFC5245 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) * Updates RFC5939 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) * Obsoletes RFC2326 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) * Obsoletes RFC4572 Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------------------------------------------ Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Steve Donovan Tom McGarry Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Mailing Lists: General Discussion: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: https://mailarchive.ietf.org/arch/browse/modern/ Description of Working Group: The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing the acquisition and resolution of telephone numbers (TNs) in an IP environment. Devices, applications, and network tools increasingly need to request and acquire TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment. The working group will also identify protocol mechanisms to support the interactions between the functions defined by the framework. This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs, with a preference for use of existing protocol mechanisms. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. Maintaining reliability, real-time application performance, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM as well as work in other relevant standards organizations. The work of this group will focus on TNs, as defined in RFC3966, and blocks of TNs, that are used to initiate communication with another user of a service. The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164, and is cognizant of other related ITU-T Recommendations, including E.164.1 and E.190. There is an expectation that aspects of the architecture and protocols defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reuse of MODERN mechanisms are out of scope for the MODERN working group. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. Goals and Milestones: Mar 2016 - Submit Architecture Overview Draft to IESG (Informational) Jul 2016 - Submit Information Model Draft to IESG (Standards Track) Jan 2017 - Submit TN Resolution Draft to IESG (Standards Track) Apr 2017 - Submit Enrollment Data Access Process Draft to IESG (Standards Track) Jun 2017 - Submit Enrollment Process Draft to IESG (Standards Track) Internet-Drafts: - Modern Problem Statement, Use Cases, and Framework [draft-ietf-modern-problem-framework-03] (23 pages) No Requests for Comments Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 2016-07-27 Current Status: Active Chairs: George Swallow Loa Andersson Nicolai Leymann Routing Area Directors: Alia Atlas Deborah Brungard Alvaro Retana Routing Area Advisor: Deborah Brungard Secretary: Tarek Saad 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: 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 Mar 2015 - Submit draft-ietf-mpls-tp-oam-id-mib 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 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 Done - Submit draft-ietf-mpls-lsp-ping-registry for publication Done - Submit draft-ietf-mpls-oam-ipv6-rao for publication 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 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) - 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) - 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) - Gap Analysis for Operating IPv6-only MPLS Networks [draft-george-mpls-ipv6-only-gap-05] (24 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-05] (16 pages) - Bidirectional Forwarding Detection (BFD) Directed Return Path [draft-ietf-mpls-bfd-directed-08] (8 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-00] (27 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-06] (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] (19 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 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-03] (76 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/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces [draft-ietf-mpls-lsp-ping-lag-multipath-03] (27 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) - 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-03] (37 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-03] (58 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-01] (20 pages) - UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks [draft-ietf-mpls-rfc6374-udp-return-path-05] (10 pages) - Refresh Interval Independent FRR Facility Protection [draft-ietf-mpls-ri-rsvp-frr-02] (24 pages) - Resilient MPLS Rings [draft-ietf-mpls-rmr-06] (14 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-00] (21 pages) - Hub and Spoke Multipoint Label Switched Path Tunnels [draft-ietf-mpls-rsvp-te-hsmp-lsp-01] (8 pages) - Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths [draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09] (10 pages) - Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) [draft-ietf-mpls-rsvp-te-p2mp-07] (53 pages) - Applicability Statement for Extensions to RSVP for LSP-Tunnels [draft-ietf-mpls-rsvp-tunnel-applicability-02] (8 pages) - Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) [draft-ietf-mpls-rsvp-unnum-08] (9 pages) - MPLS Upstream Label Assignment for RSVP-TE [draft-ietf-mpls-rsvp-upstream-05] (10 pages) - 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) - Synonymous Flow Label Framework [draft-ietf-mpls-sfl-framework-01] (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) - Entropy label for SPRING tunnels [draft-ietf-mpls-spring-entropy-label-08] (23 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) - A YANG Data Model for MPLS Static LSPs [draft-ietf-mpls-static-yang-04] (21 pages) - RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels [draft-ietf-mpls-summary-frr-rsvpte-00] (16 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-06] (16 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) - 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) - 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) - 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) - 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) 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 RFC3032 * 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 RFC3032 * Updates RFC5462 RFC3468: The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols (11 pages) * Updates RFC3212 * Updates RFC3472 * Updates RFC3475 * Updates RFC3476 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 RFC4182: Removing a Restriction on the use of MPLS Explicit NULL (7 pages) * Updates RFC3032 * Updates RFC5462 * Updates RFC7274 RFC4201: Link Bundling in MPLS Traffic Engineering (TE) (12 pages) * Updates RFC3471 * Updates RFC3472 * Updates RFC3473 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 RFC1122 * 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) * Updates RFC3209 * Updates RFC3473 * 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) * Obsoletes RFC3036 * 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) * Updates RFC3032 * Updates RFC4023 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) * Updates RFC3032 * Updates RFC3270 * Updates RFC3272 * Updates RFC3443 * Updates RFC3469 * Updates RFC3564 * Updates RFC3985 * Updates RFC4182 * Updates RFC4364 * Updates RFC4379 * Updates RFC4448 * Updates RFC4761 * Updates RFC5129 RFC5561: LDP Capabilities (12 pages) RFC5586: MPLS Generic Associated Channel (19 pages) * Updates RFC3032 * Updates RFC4385 * Updates RFC5085 * 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) * Updates RFC3209 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) * Updates RFC5443 RFC6178: Label Edge Router Forwarding of IPv4 Option Packets (9 pages) * Updates RFC3031 RFC6215: MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (6 pages) * Updates RFC5921 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 RFC4379 * Updates RFC7537 * Obsoletes RFC8029 RFC6425: Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping (28 pages) * Updates RFC4379 RFC6426: MPLS On-Demand Connectivity Verification and Route Tracing (22 pages) * Updates RFC4379 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) * Updates RFC6371 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 RFC5036 * Updates RFC7552 RFC6790: The Use of Entropy Labels in MPLS Forwarding (25 pages) * Updates RFC3031 * Updates RFC3107 * Updates RFC3209 * Updates RFC5036 * 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) * Updates RFC4379 * 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) * Updates RFC5586 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) * Updates RFC6428 * Updates RFC6427 * Updates RFC6378 * Updates RFC6374 * Updates RFC5586 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 RFC6378 * Updates RFC8234 RFC7274: Allocating and Retiring Special-Purpose MPLS Labels (11 pages) * Updates RFC6790 * Updates RFC6478 * Updates RFC6391 * Updates RFC5960 * Updates RFC5921 * Updates RFC5586 * Updates RFC5331 * Updates RFC4928 * Updates RFC4182 * Updates RFC3811 * Updates RFC3209 * Updates RFC3038 * Updates RFC3032 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) * Updates RFC6378 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) * Updates RFC3212 * Updates RFC4447 * Updates RFC5036 * Updates RFC5918 * Updates RFC6388 * Updates RFC7140 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) * Updates RFC6826 * Updates RFC7246 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) * Updates RFC6790 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) * Updates RFC4379 RFC7510: Encapsulating MPLS in UDP (19 pages) RFC7524: Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) (42 pages) RFC7537: IANA Registries for LSP Ping Code Points (7 pages) * Updates RFC4379 * Updates RFC6424 * Obsoletes RFC8029 RFC7552: Updates to LDP for IPv6 (24 pages) * Updates RFC5036 * Updates RFC6720 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) * Updates RFC7110 RFC7743: Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping (18 pages) * Updates RFC4379 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) * Updates RFC6790 RFC8029: Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures (78 pages) * Obsoletes RFC4379 * Obsoletes RFC6424 * Obsoletes RFC6829 * Obsoletes RFC7537 * Updates RFC1122 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) * Updates RFC7473 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) * Updates RFC7271 RFC8256: Requirements for Hitless MPLS Path Segment Monitoring (16 pages) RFC8277: Using BGP to Bind MPLS Labels to Address Prefixes (23 pages) * Obsoletes RFC3107 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) Multipath TCP (mptcp) --------------------- Charter Last Modified: 2016-04-06 Current Status: Active Chairs: Philip Eardley Yoshifumi Nishida Transport Area Directors: Spencer Dawkins Mirja Kühlewind Transport Area Advisor: Mirja Kühlewind Mailing Lists: General Discussion: multipathtcp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp Archive: https://mailarchive.ietf.org/arch/browse/multipathtcp/ Description of Working Group: The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. Key goals for MPTCP are: to be deployable and usable without significant changes to existing Internet infrastructure; to be usable by unmodified applications; and to be stable and congestion-safe over the wide range of existing Internet paths, including NAT interactions. MPTCP assumes that both peers are modified and that one or both peers have multiple addresses, which often results in different network paths that are at least partially divergent (however, note there is no guarantee that the paths are divergent at all). In its initial charter the WG produced experimental or informational documents that defined: a. An architectural framework for congestion-dependent multipath transport protocols. It describes the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. b. A security threat analysis for multipath TCP. c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. d. Extensions to current TCP to support multi-addressed multipath TCP. This covers all on-the-wire changes required to create a two-ended MPTCP solution using multiple IP addresses at one or both ends. It includes a basic security solution. e. Application Interface Considerations. It summarises the impact that MPTCP may have on applications, such as changes in performance. Also, it describes an optional, basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. The working group now re-charters to progress various aspects of MPTCP. The primary goal of the working group is to create a bis version of the protocol document on the Standards track. This develops the current Experimental document (item d above), incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM. There already exists a reference Linux implementation and other implementation and experimental activity is on-going and will continue during 2012, with the objective of progressing the protocol to Standards Track during 2013. The working group will also explore and document results with several of the proposed use cases for MPTCP in more detail, to ensure that MPTCP works well in practice and that operational experiences and issues are understood and captured. Likely use cases are to offload traffic from 3G to WiFi, and to manage traffic within a data centre. Another scenario is to enable, without changing the MPTCP protocol, operation of a single-homed, MPTCP end host on a campus network that has multiple providers. Prior to publishing a Standards Track specification, the working group will document experimental results and operational experiences to-date. This should consider not just experience with well-connected fat-pipe networks and long-lived flows, but also consider a broader links and types of applications; particularly looking for cases where MPTCP could be detrimental in some way. The working group will document implementation advice. The current documents have several points where an implementer may benefit from guidance, for example about heuristics such as buffer sizing, or from advice about alternative implementations such as bump-in-the-stack. Finally, the working group will explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled. For example, potentially helping MPTCP's incremental deployment by allowing only one end host to be MPTCP-enabled and the middlebox acts as an MPTCP proxy for the other end host, which runs TCP; and potentially helping some mobility scenarios, where the middlebox acts as an anchor between two MPTCP-enabled hosts. The working group will detail what real problems an MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP architecture (RFC6182), what proxy approach might be justified as compared against alternative solutions to the problems, and the likely feasibility of solving the technical and security issues. Goals and Milestones: Done - Established WG consensus on the Architecture Done - Submit to IESG architectural guidelines and security threat analysis as informational RFC(s) Done - Submit to IESG basic coupled congestion control as an experimental RFC Done - Consensus on what high-level changes are needed to the current MPTCP Experimental document in order to progress it on the standards track Done - Use-cases and operational experiences (Informational) to IESG Nov 2017 - Enhanced API (Informational) to IESG Mar 2018 - MPTCP standards track protocol to IESG Apr 2018 - Re-charter or close Internet-Drafts: - Multipath TCP (MPTCP) Application Interface Considerations [draft-ietf-mptcp-api-07] (31 pages) - Architectural Guidelines for Multipath TCP Development [draft-ietf-mptcp-architecture-05] (28 pages) - Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) [draft-ietf-mptcp-attacks-04] (19 pages) - Coupled Congestion Control for Multipath Transport Protocols [draft-ietf-mptcp-congestion-07] (12 pages) - Use Cases and Operational Experience with Multipath TCP [draft-ietf-mptcp-experience-07] (30 pages) - TCP Extensions for Multipath Operation with Multiple Addresses [draft-ietf-mptcp-multiaddressed-12] (64 pages) - TCP Extensions for Multipath Operation with Multiple Addresses [draft-ietf-mptcp-rfc6824bis-09] (73 pages) - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses [draft-ietf-mptcp-threat-08] (17 pages) Requests for Comments: RFC6181: Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses (17 pages) RFC6182: Architectural Guidelines for Multipath TCP Development (28 pages) RFC6356: Coupled Congestion Control for Multipath Transport Protocols (12 pages) RFC6824: TCP Extensions for Multipath Operation with Multiple Addresses (64 pages) RFC6897: Multipath TCP (MPTCP) Application Interface Considerations (31 pages) RFC7430: Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) (19 pages) RFC8041: Use Cases and Operational Experience with Multipath TCP (30 pages) Meeting Venue (mtgvenue) ------------------------ Charter Last Modified: 2018-01-30 Current Status: Active Chairs: Charles Eckel Pete Resnick General Area Directors: Alissa Cooper General Area Advisor: Alissa Cooper Mailing Lists: General Discussion: mtgvenue@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mtgvenue Archive: https://mailarchive.ietf.org/arch/search/?email_list=mtgvenue Description of Working Group: The selection of meeting venues for our physical meetings is a common area of discussion at the IETF and feedback for the IAOC and its meeting committee. A specification of the venue selection process and criteria would be useful. With community discussion and agreement such a specification will be very helpful in improving the process and ensuring that the relevant criteria are properly identified. The discussion itself may also be helpful. For instance, due to recent discussions, potential future destinations are announced to the community to help identify potential issues early. These processes and criteria support the overall IETF meeting strategy. The IETF complements its mostly online work with three physical meetings each year, obviously for the purpose of the standards development work but also for the opportunities for high-bandwidth collaboration, cross-pollination of ideas, and focusing on running code. Existing geographic distribution policy explicitly calls for rotating meeting locations equally among the largest sources of IETF attendees, previously defined as North America, Europe, and Asia, while reserving a possibility for exceptions. The exceptions are, for instance, meetings outside those regions. The rationale is to meet in different geographic regions in order to spread the difficulty and cost of travel among the attendees. The rotation policy, known as the 1-1-1-* model -- with the asterisk denoting the exceptions -- was set by the IESG, documented in https://iaoc.ietf.org/minutes/2010-11-10-iaoc-minutes.txt. The MTGVENUE working group is the forum where the IETF community can discuss and agree on what should go into the policies, the selection process, and the detailed criteria going forward. All criteria and all other aspects of the process are open for discussion. The purpose of the working group is to produce a community consensus document(s) that help drive the meeting selection process in a manner that the community is comfortable with. The working group shall produce guidance on two areas: 1. A specification of the geographic IETF meeting policy, currently described as the "1-1-1-*" policy. The policy going forward is up to the working group. 2. A specification that describes the detailed meeting venue selection process and criteria, the contents of which are also up to the working group. The specification(s) are expected to be Best Current Practice (BCP) documents. The specifications are expected to provide clear guidance to meeting selections, be implementable in our operating environment, and take into account the needs of the highly diverse IETF community. This working group is not chartered to develop criteria for virtual meetings, be those WG meetings or broader ones. Goals and Milestones: Mar 2016 - Initial individual draft on venue selection process and criteria Jul 2016 - Initial individual draft on IETF meeting geographic distribution policy Nov 2016 - Submission of the final working group draft on IETF meeting geographic distribution policy to the IESG Feb 2017 - Submission of the final working group draft on venue selection process and criteria to the IESG Internet-Drafts: - IAOC Plenary Meeting Venue Selection Process [draft-baker-mtgvenue-iaoc-venue-selection-process-03] (15 pages) - IETF Plenary Meeting Venue Selection Process [draft-ietf-mtgvenue-iaoc-venue-selection-process-12] (18 pages) - High level guidance for the meeting policy of the IETF [draft-ietf-mtgvenue-meeting-policy-03] (5 pages) No Requests for Comments Network Configuration (netconf) ------------------------------- Charter Last Modified: 2017-07-27 Current Status: Active Chairs: Kent Watsen Mahesh Jethanandani Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Benoit Claise 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 for YANG data model driven management, for the necessary framework where these protocols run, and for the YANG modules that formalize protocol behavior and are required from a protocol perspective. The NETCONF protocol (RFC 6241) provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF is based on secure transport (SSH is mandatory to implement while TLS is an optional transport). 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 published the RESTCONF protocol (RFC 8040) which provides an interface over HTTPS for accessing data defined in YANG. RESTCONF is based on the capabilities of, and uses the datastore concept defined in, the NETCONF protocol specification. In support of RESTCONF the YANG Patch (RFC 8072) mechanism has been provided for applying patches to configuration datastores. The YANG Module Library (RFC 7895) provides information about all YANG modules used by a network management server. Last but not least NETCONF and RESTCONF Call Home (RFC 8071) have been developed, which enable a server to initiate a secure connection to a NETCONF or RESTCONF client respectively. In the current phase of NETCONF's incremental development the Working Group will focus on following items: 1. Finalize the YANG data module for a system-level keystore mechanism, which can be used to hold asymmetric private keys and certificates that are trusted by the system advertising support for this module. Based on the known dependencies (multiple NETCONF documents), this draft has the highest priority for the WG. 2. Finalize Server and Client Configuration YANG modules for both NETCONF and RESTCONF as well as the Client and Server Models for SSH and TLS. 3. Finalize the Zero-touch provisioning for NETCONF or RESTCONF-based Management as a technique to establish a secure network management relationship between a newly delivered network device configured with just its factory default settings, and the Network Management System. 4. Provide a revised version of NETCONF Access Control Model (RFC 6536) by adding support for RESTCONF and for YANG 1.1 constructs like "action" and the (locally-scoped) "notification" statements. 5. Provide a set of documents enabling advanced notification/subscription capabilities, which gracefully co-exist with deployments of NETCONF Event Notification (RFC 5277). The new capabilities include transport independence and multiple dynamic and configured subscriptions in a single transport session. RFC 5277 will be obsoleted in parallel with the publication of the new document set. The following specifications will be published: - A protocol-independent notification framework, explaining the concepts of subscriptions, filters, subscription state notifications, replay, etc. and defining the associated YANG data model, RPCs, etc. - Definition of notifications sent over NETCONF and HTTP. Examples for the encoding of YANG notifications in XML and JSON will be given and considerations for parallel support and implementation compatibility with RFC 5277 will be included. - Definition of notifications sent over RESTCONF and HTTP2 and of how YANG notifications are encoded in XML and JSON, including specifics of call-home and heartbeat for subscriptions. - The subscription and push mechanism for YANG datastores allowing subscriber applications to request updates from a YANG datastore. - Definition of transport agnostic notification headers and of a mechanism for bundling multiple YANG notifications into a single message. 6. Based on the revised datastore concept work in NETMOD, provide a revision for the NETCONF and RESTCONF protocols and the used datastore framework. 7. Coordinate with I2RS to support the I2RS profile use of RESTCONF and, optionally, NETCONF, and the I2RS dynamic datastore(s). Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for NETCONF Protocol (RFC6241) and NETCONF over SSH (RFC6242) and addressing any reported errata. Goals and Milestones: Telechat on Oct 26th - Submit RFC 6536bis to AD/IESG for consideration as Proposed Standard Dec 2017 - WGLC for Zero-touch Configuration Mechanism Dec 2017 - WGLC for advanced Notification/Subscription Specifications Dec 2017 - WGLC for NMDA NETCONF Dec 2017 - WGLC for NMDA RESTCONF Dec 2017 - WGLC for YANG Library bis (as Standards Track) Jan 2018 - WGLC for System-level Keystore Mechanism Jan 2018 - WGLC for Server and Client Configuration Models for NETCONF and RESTCONF Jan 2018 - WGLC for Client and Server Configuration Models for SSH and TLS Jan 2018 - WGLC for YANG Push Mar 2018 - WGLC for RESTCONF and HTTP Transport for Event Notifications Mar 2018 - WGLC for NETCONF Support for Event Notifications Mar 2018 - WGLC for YANG Notification Headers and Bundles 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 Model for a "Keystore" Mechanism [draft-ietf-netconf-keystore-04] (27 pages) - YANG Module for NETCONF Monitoring [draft-ietf-netconf-monitoring-15] (28 pages) - NETCONF Client and Server Models [draft-ietf-netconf-netconf-client-server-05] (52 pages) - NETCONF Support for Event Notifications [draft-ietf-netconf-netconf-event-notifications-06] (20 pages) - NETCONF Extensions to Support the Network Management Datastore Architecture [draft-ietf-netconf-nmda-netconf-03] (17 pages) - RESTCONF Extensions to Support the Network Management Datastore Architecture [draft-ietf-netconf-nmda-restconf-02] (7 pages) - NETCONF Event Notifications [draft-ietf-netconf-notification-14] (35 pages) - Notification Message Headers and Bundles [draft-ietf-netconf-notification-messages-02] (22 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-05] (38 pages) - RESTCONF Collection Resource [draft-ietf-netconf-restconf-collection-00] (17 pages) - RESTCONF and HTTP Transport for Event Notifications [draft-ietf-netconf-restconf-notif-04] (16 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 Module [draft-ietf-netconf-rfc6536bis-09] (56 pages) - YANG Library [draft-ietf-netconf-rfc7895bis-04] (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-05] (34 pages) - Custom Subscription to Event Streams [draft-ietf-netconf-subscribed-notifications-09] (59 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) - 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-05] (29 pages) - UDP based Publication Channel for Streaming Telemetry [draft-ietf-netconf-udp-pub-channel-01] (12 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) - YANG Datastore Subscription [draft-ietf-netconf-yang-push-13] (56 pages) - Zero Touch Provisioning for NETCONF or RESTCONF based Management [draft-ietf-netconf-zerotouch-19] (80 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) * Obsoletes RFC4741 * Updates RFC7803 RFC6242: Using the NETCONF Protocol over Secure Shell (SSH) (11 pages) * Obsoletes RFC4742 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) RFC7589: Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication (11 pages) * Obsoletes RFC5539 RFC7895: YANG Module Library (13 pages) RFC8040: RESTCONF Protocol (137 pages) RFC8071: NETCONF Call Home and RESTCONF Call Home (13 pages) RFC8072: YANG Patch Media Type (39 pages) Network Modeling (netmod) ------------------------- Charter Last Modified: 2017-12-15 Current Status: Active Chairs: Joel Jaeggli Kent Watsen Lou Berger Operations and Management Area Directors: Benoit Claise Warren Kumari Operations and Management Area Advisor: Benoit Claise Secretary: Zitao Wang 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) - Network Access Control List (ACL) YANG Data Model [draft-ietf-netmod-acl-model-16] (54 pages) - An Architecture for Network Management Using NETCONF and YANG [draft-ietf-netmod-arch-10] (30 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] (56 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-05] (27 pages) - A YANG Data Model for IP Management [draft-ietf-netmod-ip-cfg-14] (30 pages) - Terminology and Requirements for Enhanced Handling of Operational State [draft-ietf-netmod-opstate-reqs-04] (6 pages) - Network Management Datastore Architecture [draft-ietf-netmod-revised-datastores-10] (39 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 YANG Data Model Documents [draft-ietf-netmod-rfc6087bis-17] (71 pages) - A YANG Data Model for Interface Management [draft-ietf-netmod-rfc7223bis-03] (48 pages) - A YANG Data Model for IP Management [draft-ietf-netmod-rfc7277bis-03] (32 pages) - A YANG Data Model for Routing Management (NMDA Version) [draft-ietf-netmod-rfc8022bis-11] (77 pages) - A YANG Data Model for Routing Management [draft-ietf-netmod-routing-cfg-25] (64 pages) - YANG Schema Mount [draft-ietf-netmod-schema-mount-08] (27 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-03] (27 pages) - A YANG Data Model for Syslog Configuration [draft-ietf-netmod-syslog-model-19] (35 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) - JSON Encoding of Data Modeled with YANG [draft-ietf-netmod-yang-json-10] (20 pages) - Defining and Using Metadata with YANG [draft-ietf-netmod-yang-metadata-07] (21 pages) - YANG Module Classification [draft-ietf-netmod-yang-model-classification-08] (11 pages) - YANG Tree Diagrams [draft-ietf-netmod-yang-tree-diagrams-05] (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) - 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) - Sub-interface VLAN YANG Data Models [draft-wilton-netmod-intf-vlan-yang-04] (27 pages) Requests for Comments: RFC6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) (173 pages) RFC6021: Common YANG Data Types (26 pages) * Obsoletes RFC6991 RFC6087: Guidelines for Authors and Reviewers of YANG Data Model Documents (26 pages) 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) * Obsoletes RFC6021 RFC7223: A YANG Data Model for Interface Management (39 pages) RFC7224: IANA Interface Type YANG Module (37 pages) RFC7277: A YANG Data Model for IP Management (30 pages) 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) RFC7951: JSON Encoding of Data Modeled with YANG (20 pages) RFC7952: Defining and Using Metadata with YANG (21 pages) * Updates RFC6110 RFC8022: A YANG Data Model for Routing Management (64 pages) RFC8199: YANG Module Classification (11 pages) Internet Video Codec (netvc) ---------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Mo Zanaty Natasha Rooney Applications and Real-Time Area Directors: Ben Campbell Alexey Melnikov Adam Roach Applications and Real-Time Area Advisor: Adam Roach Mailing Lists: General Discussion: video-codec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/video-codec Archive: https://mailarchive.ietf.org/arch/browse/video-codec/ Description of Working Group: Objectives This WG is chartered to produce a high-quality video codec that meets the following conditions: 1. Is competitive (in the sense of having comparable or better performance) with current video codecs in widespread use. 2. Is optimized for use in interactive web applications. 3. Is viewed as having IPR licensing terms that allow it to be widely implemented and deployed. To elaborate, this video codec will need to be commercially interesting to implement by being competitive with the video codecs in widespread use at the time it is finalized. This video codec will need to be optimized for the real-world conditions of the public, best-effort Internet. It should include, but may not be limited to, the ability to support fast and flexible congestion control and rate adaptation, the ability to quickly join broadcast streams and the ability to be optimized for captures of content typically shared in interactive communications. The objective is to produce a video codec that can be implemented, distributed, and deployed by open source and closed source software as well as implemented in specialized hardware. The working group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." In keeping with this BCP, the WG will prefer algorithms or tools where there are verifiable reasons to believe they are available on an royalty-free (RF) basis. In developing the codec specification, the WG may consider information concerning old prior art or the results of research indicating royalty-free availability of particular techniques. Note that the preference stated in BCP 79 cannot guarantee that the working group will produce an IPR unencumbered codec. Process The core technical considerations for such a codec include, but are not necessarily limited to, the following: 1. High compression efficiency that is competitive with existing popular video codecs. 2. Reasonable computational complexity that permits real-time operation on existing, popular hardware, including mobile devices, and efficient implementation in new hardware designs. 3. Use in interactive real-time applications, such as point-to-point video calls, multi-party video conferencing, telepresence, teleoperation, and in-game video chat. 4. Resilient in the real-world transport conditions of the Internet, such as the flexibility to rapidly respond to changing bandwidth availability and loss rates, etc. 5. Integratable with common Internet applications and Web APIs (e.g., the HTML5