avtcore
payload
bfcpbis
calext
capport
cellar
cbor
core
cdni
clue
dispatch
dcrup
doh
dmarc
extra
ecrit
httpbis
ice
insipid
netvc
codec
jmap
modern
xrblock
mmusic
perc
rtcweb
regext
stir
slim
sipcore
sipbrandy
uta
mtgvenue
dmm
dprive
dhc
dnssd
homenet
hip
intarea
ipwave
6man
lpwan
6lo
6tisch
lwig
ntp
softwire
savi
sunset4
tictoc
anima
bmwg
dime
dnsop
grow
v6ops
l2sm
lmap
lime
mboned
netconf
netmod
opsec
opsawg
radext
sidrops
babel
bess
bfd
bier
ccamp
detnet
idr
i2rs
isis
l2tpext
lisp
manet
mpls
nvo3
ospf
pce
pim
pals
rtgwg
roll
sidr
sfc
spring
teas
trill
ace
acme
kitten
curdle
dots
i2nsf
ipsecme
lamps
mile
trans
sacm
secevent
suit
tokbind
tls
oauth
alto
dtn
ippm
mptcp
nfsv4
quic
rmcat
tcpinc
tcpm
tsvwg
taps
tram


Audio/Video Transport Core Maintenance (avtcore)
------------------------------------------------

Charter
Last Modified: 2017-03-07

Current Status: Active

Chairs:
    Jonathan Lennox <[email protected]>
    Rachel Huang <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



Audio/Video Transport Payloads (payload)
----------------------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Ali C. Begen <[email protected]>
    Roni Even <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/payload
    Archive:            https://mailarchive.ietf.org/arch/browse/payload/

Description of Working Group:


   The PAYLOAD working group is tasked with the specification and
   maintenance of payload formats for use with the Real-Time Transport
   Protocol, RTP [RFC3550]. The group will follow the guidelines
   established in "Guidelines for Writers of RTP Payload Format
   Specifications" [BCP 36], the "How to Write an RTP Payload Format"
   (under development) and is responsible for maintaining those
   guidelines.

   This working group will develop RTP payload formats for new media
   codecs, review and revise existing payload formats to advance those
   which are useful to Draft Standard or Standard, and declare others
   Historic.




Goals and Milestones:
 Done     - Submit RTP Payload Format for MIDI for Proposed Standard
 Done     - Submit RTP Payload Format for MPEG-4 Audio/Visual Streams for Proposed Standard
 Done     - Submit RTP Payload Format for DV (IEC 61834) Video for Proposed Standard
 Done     - Submit RTP Payload Format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) for Proposed Standard
 Done     - Submit RTP profile for the carriage of SMPTE 336M data for Proposed Standard
 Done     - Submit How to Write an RTP Payload Format for Informational
 Done     - Submit RTP Payload Format for VP8 Video for Proposed Standard
 Done     - Submit RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs for Proposed Standard
 Done     - Submit RTP Payload Format for G.711.0 for Proposed Standard
 Done     - Submit RTP Payload Format for High Efficiency Video Coding for Proposed Standard.
 Done     - Submit RTP Payload Format for Opus Speech and Audio Codec as proposed standard
 Done     - Submit RTP Payload Format for SMPTE ST 291 Ancillary Data for Proposed Standard
 Done     - submit RTP Payload Format for MELPe Codec
 Mar 2017 - Submit RTP Payload Format for Non-Interleaved and Interleaved Parity FEC
 Mar 2017 - Submit RTP Payload Format for VP9 Video for Proposed Standard
 May 2017 - submit RTP Payload Format for VC-2 HQ Profile Video

Internet-Drafts:
 - RTP Payload Format for MPEG-4 Audio/Visual Streams [draft-ietf-avt-rfc3016bis-02] (32 pages)
 - RTP Payload Format for DV (IEC 61834) Video [draft-ietf-avt-rfc3189bis-04] (19 pages)
 - RTP Payload Format for MIDI [draft-ietf-avt-rfc4695-bis-10] (171 pages)
 - RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) [draft-ietf-avt-rtp-evrc-nw-10] (21 pages)
 - RTP Payload Format for G.718 Speech/Audio [draft-ietf-avt-rtp-g718-05] (27 pages)
 - RTP Payload Format for IP-MR Speech Codec [draft-ietf-avt-rtp-ipmr-15] (19 pages)
 - RTP Payload Format for the iSAC Codec [draft-ietf-avt-rtp-isac-04] (16 pages)
 - RTP Payload Format for SMPTE 336M Encoded Data [draft-ietf-avt-rtp-klv-02] (12 pages)
 - RTP Payload Format for MVC Video [draft-ietf-avt-rtp-mvc-01] (25 pages)
 - RTP Payload Format for Bluetooth's SBC audio codec [draft-ietf-avt-rtp-sbc-01] (23 pages)
 - RTP Payload Format for Scalable Video Coding [draft-ietf-avt-rtp-svc-27] (100 pages)
 - RTP Payload Format for Flexible Forward Error Correction (FEC) [draft-ietf-payload-flexible-fec-scheme-05] (38 pages)
 - RTP Payload Format for G.711.0 [draft-ietf-payload-g7110-06] (32 pages)
 - RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec [draft-ietf-payload-melpe-06] (30 pages)
 - RTP Payload Format for MPEG-4 Audio/Visual Streams [draft-ietf-payload-rfc3016bis-03] (35 pages)
 - RTP Payload Format for DV (IEC 61834) Video [draft-ietf-payload-rfc3189bis-03] (18 pages)
 - RTP Payload Format for MIDI [draft-ietf-payload-rfc4695-bis-02] (171 pages)
 - RTP Payload for SMPTE ST 291-1 Ancillary Data [draft-ietf-payload-rtp-ancillary-14] (19 pages)
 - RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs [draft-ietf-payload-rtp-aptx-05] (16 pages)
 - RTP Payload Format for G.718 Speech/Audio [draft-ietf-payload-rtp-g718-03] (27 pages)
 - RTP Payload Format for High Efficiency Video Coding (HEVC) [draft-ietf-payload-rtp-h265-15] (86 pages)
 - How to Write an RTP Payload Format [draft-ietf-payload-rtp-howto-14] (65 pages)
 - RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data [draft-ietf-payload-rtp-klv-04] (13 pages)
 - RTP Payload Format for MVC Video [draft-ietf-payload-rtp-mvc-02] (30 pages)
 - RTP Payload Format for the Opus Speech and Audio Codec [draft-ietf-payload-rtp-opus-11] (18 pages)
 - RTP Payload Format for Bluetooth's SBC Audio Codec [draft-ietf-payload-rtp-sbc-07] (23 pages)
 - RTP Payload Format for VC-2 HQ Profile Video [draft-ietf-payload-rtp-vc2hq-04] (21 pages)
 - RTP Payload Format for VP8 Video [draft-ietf-payload-vp8-17] (27 pages)
 - RTP Payload Format for VP9 Video [draft-ietf-payload-vp9-04] (22 pages)

Requests for Comments:
 RFC6190: RTP Payload Format for Scalable Video Coding (100 pages)
 RFC6262: RTP Payload Format for IP-MR Speech Codec (19 pages)
 RFC6295: RTP Payload Format for MIDI (171 pages)
          * Obsoletes RFC4695
 RFC6416: RTP Payload Format for MPEG-4 Audio/Visual Streams (35 pages)
          * Obsoletes RFC3016
 RFC6469: RTP Payload Format for DV (IEC 61834) Video (18 pages)
          * Obsoletes RFC3189
 RFC6597: RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data (13 pages)
 RFC6884: RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) (21 pages)
 RFC7310: RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs (16 pages)
 RFC7587: RTP Payload Format for the Opus Speech and Audio Codec (18 pages)
 RFC7655: RTP Payload Format for G.711.0 (32 pages)
 RFC7741: RTP Payload Format for VP8 Video (27 pages)
 RFC7798: RTP Payload Format for High Efficiency Video Coding (HEVC) (86 pages)
 RFC8088: How to Write an RTP Payload Format (65 pages)
          * Updates RFC2736
 RFC8130: RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec (30 pages)



Binary Floor Control Protocol Bis (bfcpbis)
-------------------------------------------

Charter
Last Modified: 2017-08-01

Current Status: Active

Chairs:
    Charles Eckel <[email protected]>
    Keith Drage <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Calendaring Extensions (calext)
-------------------------------

Charter
Last Modified: 2016-05-06

Current Status: Active

Chairs:
    Daniel Migault <[email protected]>
    Donald E. Eastlake 3rd <[email protected]>
    Philipp Kewisch <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 <[email protected]>
    Martin Thomson <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Codec Encoding for LossLess Archiving and Realtime transmission (cellar)
------------------------------------------------------------------------

Charter
Last Modified: 2015-11-20

Current Status: Active

Chairs:
    Tessa Fallon <[email protected]>
    Tim Terriberry <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Concise Binary Object Representation Maintenance and Extensions (cbor)
----------------------------------------------------------------------

Charter
Last Modified: 2017-01-09

Current Status: Active

Chairs:
    Francesca Palombini <[email protected]>
    Joe Hildebrand <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Constrained RESTful Environments (core)
---------------------------------------

Charter
Last Modified: 2017-04-21

Current Status: Active

Chairs:
    Carsten Bormann <[email protected]>
    Jaime Jimenez <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Content Delivery Networks Interconnection (cdni)
------------------------------------------------

Charter
Last Modified: 2017-11-21

Current Status: Active

Chairs:
    Francois Le Faucheur <[email protected]>
    Kevin J. Ma <[email protected]>
    Phil Sorber <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



ControLling mUltiple streams for tElepresence (clue)
----------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Paul Kyzivat <[email protected]>
    Roni Even <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Dispatch (dispatch)
-------------------

Charter
Last Modified: 2015-11-01

Current Status: Active

Chairs:
    Cullen Jennings <[email protected]>
    Mary Barnes <[email protected]>
    Murray Kucherawy <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

DKIM Crypto Update (dcrup)
--------------------------

Charter
Last Modified: 2017-04-28

Current Status: Active

Chairs:
    Murray Kucherawy <[email protected]>
    Rich Salz <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Tech Advisor:
    Eric Rescorla <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



DNS Over HTTPS (doh)
--------------------

Charter
Last Modified: 2017-09-29

Current Status: Active

Chairs:
    Benjamin M. Schwartz <[email protected]>
    David C Lawrence <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Tech Advisor:
    Warren Kumari <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Domain-based Message Authentication, Reporting & Conformance (dmarc)
--------------------------------------------------------------------

Charter
Last Modified: 2016-05-05

Current Status: Active

Chairs:
    Barry Leiba <[email protected]>
    Ned Freed <[email protected]>
    Tim Draegen <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Email mailstore and eXtensions To Revise or Amend (extra)
---------------------------------------------------------

Charter
Last Modified: 2017-11-14

Current Status: Active

Chairs:
    Bron Gondwana <[email protected]>
    Jiankang Yao <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Emergency Context Resolution with Internet Technologies (ecrit)
---------------------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Allison Mankin <[email protected]>
    Roger Marshall <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 <mapping> 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 <mapping> 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)



Hypertext Transfer Protocol (httpbis)
-------------------------------------

Charter
Last Modified: 2017-02-06

Current Status: Active

Chairs:
    Mark Nottingham <[email protected]>
    Patrick McManus <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Tech Advisor:
    Allison Mankin <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       [email protected]
    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)



Interactive Connectivity Establishment (ice)
--------------------------------------------

Charter
Last Modified: 2015-10-20

Current Status: Active

Chairs:
    Ari Keränen <[email protected]>
    Peter Thatcher <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Tech Advisor:
    Martin Stiemerling <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

INtermediary-safe SIP session ID (insipid)
------------------------------------------

Charter
Last Modified: 2017-08-01

Current Status: Active

Chairs:
    Gonzalo Salgueiro <[email protected]>
    Keith Drage <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 Video Codec (netvc)
----------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Mo Zanaty <[email protected]>
    Natasha Rooney <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 <video> tag and WebRTC API, live streaming, adaptive streaming, and common media-related APIs) without depending on any particular API.

 The working group will consider the impacts its decisions have on the efficiency of transcoding to and from other existing video codecs.


 Non-Goals

 It is explicitly not a goal of the working group to produce a codec that will be mandated for implementation across the entire IETF or Internet community.

 Based on the working group's analysis of the design space, the working group might determine that it needs to produce a codec with multiple modes of operation. The WG may produce a codec that is highly configurable, operating in many different modes with the ability to smoothly be extended with new modes in the future.


 Collaboration

 In completing its work, the working group will seek cross-WG review with other relevant IETF working groups, including PAYLOAD, RMCAT, RTCWEB, MMUSIC, and other IETF WGs that make use of or handle negotiation of codecs. The WG will liaise with groups in other SDOs, such as the W3C HTML, Device APIs and WebRTC working groups; ITU-T (Study group 16); ISO/IEC (JTC1/SC29 WG11); 3GPP (SA4); and JCT-VC.

 It is expected that an open source reference version of the codec will be developed in parallel with the working group's work.


 Deliverables

 1. A set of technical requirements and evaluation criteria. The WG may choose to pursue publication of these in an RFC if it deems that to be beneficial.

 2. Proposed Standard specification of an encoded bit stream and decoder operation where the normative formats and algorithms are described in English text and not as code.

 3. Source code for a reference implementation (documented in an informational document) that includes both an encoder and a decoder.

 4. Specification of a storage format for file transfer of the encoded video as an elementary stream compatible with existing, popular container formats to support non-interactive (HTTP) streaming, including live encoding and both progressive and large-chunk downloads. The WG will not develop a new container format.

 5. A collection of test results, either from tests conducted by the working group or made publicly available elsewhere, characterizing the performance of the codec.


Goals and Milestones:
 Jul 2016 - Requirements and evaluation criteria to IESG, if the WG so chooses (Informational)
 May 2017 - Submit codec specification to IESG (Standards Track)
 May 2017 - Submit reference implementation to IESG (Informational)
 May 2017 - Submit storage format specification to IESG (Standards Track)
 Dec 2017 - Test result document to IESG, if the WG so chooses (Informational)

Internet-Drafts:
 - <Video Codec Requirements and Evaluation Methodology> [draft-ietf-netvc-requirements-07] (25 pages)
 - Video Codec Testing and Quality Measurement [draft-ietf-netvc-testing-06] (23 pages)

No Requests for Comments

Internet Wideband Audio Codec (codec)
-------------------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Mo Zanaty <[email protected]>
    Tim Terriberry <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Tech Advisor:
    Stephan Wenger <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



JSON Mail Access Protocol (jmap)
--------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Barry Leiba <[email protected]>
    Bron Gondwana <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)
------------------------------------------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Steve Donovan <[email protected]>
    Tom McGarry <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Metric Blocks for use with RTCP's Extended Report Framework (xrblock)
---------------------------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Dan Romascanu <[email protected]>
    Shida Schubert <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/xrblock
    Archive:            https://mailarchive.ietf.org/arch/browse/xrblock/

Description of Working Group:


   RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" established
   a framework to allow new information to be conveyed in RTCP,
   supplementing the original report blocks defined in RFC 3550, "RTP: A
   Transport Protocol for Real-Time Applications".

   The XRBLOCK working group is chartered to work within this framework,
   evaluating proposals for report block definitions containing new
   metrics. The group will follow the guidelines established in RFC5968,
   "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP
   Monitoring Architecture being developed in the AVTCORE working group.
   The group will consider the guidelines for performance metric
   development currently being discussed in the PMOL working group.




Goals and Milestones:
 Done     - Submit RTCP XR Report Block for Measurement Identity Reporting to IESG
 Done     - Submit RTCP XR Report Block for Delay metric Reporting to IESG
 Done     - Submit RTCP XR Report Block for Packet Delay Variation Metric Reporting to IESG
 Done     - Submit RTCP XR Report Block for Discard metric Reporting to IESG
 Done     - Submit RTCP XR Report Block for Run Length Encodings of Discarded Packets to IESG
 Done     - Submit RTCP XR Report Block for Burst/Gap Discard metric Reporting to IESG
 Done     - Submit RTCP XR Report Block for Burst/Gap Loss metric Reporting to IESG
 Done     - Submit RTCP XR Report Block for QoE Metrics Reporting to IESG
 Done     - Submit RTCP XR Report Block for Jitter Buffer Metric Reporting to IESG
 Done     - Submit RTCP XR Report Block for Summary Statistics Metrics Reporting
 Done     - Submit RTCP XR Report Block for Transport Stream (TS) Decodability Metric
 Done     - Submit RTCP XR Report Block for Loss Concealment metric Reporting to IESG
 Done     - Submit RTCP XR Report Block for Synchronization Delay and Offset Metrics Reporting
 Done     - Submit RTCP XR Report Block for Bytes Discarded Metrics Reporting to IESG
 Done     - Submit RTCP XR Report Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting to IESG
 Jan 2015 - Submit RTCP XR Report Block for Post-Repair Loss Count Metrics Reporting to IESG
 Mar 2015 - Submit Considerations for Selecting RTCP Extended Report (XR) Metrics for the RTCWEB Statistics API to IESG

Internet-Drafts:
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics [draft-ietf-xrblock-independent-burst-gap-discard-03] (15 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting [draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14] (14 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting [draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12] (16 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric [draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02] (12 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Concealed Seconds Metric Reporting [draft-ietf-xrblock-rtcp-xr-concsec-03] (12 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting [draft-ietf-xrblock-rtcp-xr-decodability-12] (11 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting [draft-ietf-xrblock-rtcp-xr-delay-12] (9 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting [draft-ietf-xrblock-rtcp-xr-discard-15] (12 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets [draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09] (11 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting [draft-ietf-xrblock-rtcp-xr-jb-14] (14 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications [draft-ietf-xrblock-rtcp-xr-loss-conceal-12] (22 pages)
 - Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block [draft-ietf-xrblock-rtcp-xr-meas-identity-10] (9 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting [draft-ietf-xrblock-rtcp-xr-pdv-08] (13 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics [draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11] (11 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting [draft-ietf-xrblock-rtcp-xr-psi-decodability-07] (11 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting [draft-ietf-xrblock-rtcp-xr-qoe-17] (23 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting [draft-ietf-xrblock-rtcp-xr-summary-stat-11] (21 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting [draft-ietf-xrblock-rtcp-xr-synchronization-09] (13 pages)
 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications [draft-ietf-xrblock-rtcp-xr-video-lc-06] (16 pages)
 - Real-time Transport Control Protocol Extension Report for Run Length Encoding of Discarded Packets [draft-ietf-xrblock-rtcp-xt-discard-metrics-00] (10 pages)
 - Considerations for Selecting RTCP Extended Report (XR) Metrics for the WebRTC Statistics API [draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-07] (17 pages)

Requests for Comments:
 RFC6776: Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block (9 pages)
 RFC6798: RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting (13 pages)
 RFC6843: RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting (9 pages)
 RFC6958: RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting (16 pages)
 RFC6990: RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting (11 pages)
 RFC7002: RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting (12 pages)
 RFC7003: RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting (14 pages)
 RFC7004: RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting (21 pages)
 RFC7005: RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting (14 pages)
 RFC7097: RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets (11 pages)
 RFC7243: RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric (12 pages)
 RFC7244: RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting (13 pages)
 RFC7266: RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting (23 pages)
 RFC7294: RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications (22 pages)
 RFC7380: RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting (11 pages)
 RFC7509: RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics (11 pages)
 RFC7867: RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications (16 pages)
 RFC8015: RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics (15 pages)



Multiparty Multimedia Session Control (mmusic)
----------------------------------------------

Charter
Last Modified: 2015-10-16

Current Status: Active

Chairs:
    Bo Burman <[email protected]>
    Flemming Andreasen <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



Privacy Enhanced RTP Conferencing  (perc)
-----------------------------------------

Charter
Last Modified: 2017-04-18

Current Status: Active

Chairs:
    Nils Ohlmeier <[email protected]>
    Suhas Nandakumar <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/perc
    Archive:            https://mailarchive.ietf.org/arch/browse/perc/

Description of Working Group:

 RTP-based real-time multi-party interactive media conferencing is in widespread use today. Many of the deployments use one or more centrally located media distribution devices that perform selective forwarding of mixed-media streams received from the participating endpoints. The media transport protocol commonly used is RTP (RFC3550). There are various signaling systems used to establish these multi-party conferences.

 These conferences require security to ensure that the RTP media and related metadata of the conference is kept private and only available to the set of invited participants and other devices trusted by those participants with their media.  At the same time, multi-party media conferences need source authentication and integrity checks to protect against modifications, insertions, and replay attacks.  Media distribution devices supporting these conferences may also perform RTP header changes, and they often consume and create RTCP messages for efficient media handling.

 To date, deployment models for these multi-party media distribution devices do not enable the devices to perform their functions without having keys to decrypt the participants' media, primarily using Secure RTP (RFC3711) to provide session security.

 This trust model has limitations and prevents or hampers deployment of secure RTP conferencing in a multitude of cases, including outsourcing, legal requirements on confidentiality, and utilization of virtualized servers. Thus, a new architectural model and related specifications are needed, with a focused effort from the RTP and Security communities.

 WG Objectives

 This WG will work on a solution that enables centralized SRTP-based conferencing, where the central device distributing the media is not required to be trusted with the keys to decrypt the participants' media. The media must be kept confidential and authenticated between an originating endpoint and the explicitly allowed receiving endpoints or other devices. The meta information provided to the central device is to be limited to the minimal required for it to perform its function to preserve the conference participants privacy. Further, it is desired that a solution still provides replay protection, so that the media distribution devices cannot replay previous parts of the media.

 The solution must also provide security for each hop between endpoints and multi-party media distribution devices and between multi-party media distribution devices. The RTCP messages and RTP header extensions required for the media distribution device to perform the selective media forwarding may require both source authentication and integrity as well as confidentiality. The solution may also consider providing end-to-end security for a subset of the RTCP messages or RTP header extensions.

 The solution should be implementable by both SIP (RFC3261) and WebRTC endpoints (draft-ietf-rtcweb-overview). How telepresence endpoints using the protocols defined in the CLUE working group could utilize the defined security solution needs to be considered. However, it is acknowledged that limitations may exist, resulting in restricted functionality or need for additional adaptations of the CLUE protocols.

 This working group will perform the following work:

 1.    Define a general architecture and RTP topology(s) that enables end-to-end media security for multi-party RTP conferencing.
 2.    Define the trust model and describe the resulting security properties.
 3.    Document models considered for integrating the solution with WebRTC, SIP and CLUE establishment of conferencing sessions.
 4.    Specify any necessary extensions to SRTP.
 5.   Define needed Key Management Functions that distribute the keys. The system needs to be able to bind the media to the identity of the sender of the media and/or the identity of the conference.

 Collaboration

 If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. Potential items that might require work in other WGs are DTLS extensions (TLS WG) and RTP header extensions (AVTEXT WG). This work requires strong collaboration with the security area. We will notify, and when needed coordinate with, AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work.

 Non-Goals

 The PERC working group is not chartered to extend any signaling system used to establish the RTP-based conferences. It will, however, need to consider in its architecture how the solution may integrate with these systems, and document such consideration for WebRTC, SIP, and CLUE. The specification of how a particular system integrates the security solution will happen outside of this working group, in suitable venues.

 The WG will not consider non-real-time usage, multicast-based media distribution, or Security descriptions-based keying (RFC4568).

 Input to the WG

 Proposals already existing relating to this charter proposal:

 https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/
 https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/
 https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/




Goals and Milestones:
 Dec 2017 - Submit SRTP protocol extension specification to IESG (Standards Track)
 Dec 2017 - Submit Key-management protocol specification to IESG (Standards Track)
 Dec 2017 - Submit encrypted key transport specification to IESG (Standards Track)
 Mar 2018 - Submit architecture or framework specification to IESG (Standards Track)
 Mar 2018 - Submit documentation of how to integrate solution in SIP, WebRTC and CLUE to IESG (Informational)

Internet-Drafts:
 - SRTP Double Encryption Procedures [draft-ietf-perc-double-07] (16 pages)
 - DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange [draft-ietf-perc-dtls-tunnel-02] (16 pages)
 - A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing [draft-ietf-perc-private-media-framework-05] (24 pages)
 - Encrypted Key Transport for DTLS and Secure RTP [draft-ietf-perc-srtp-ekt-diet-06] (24 pages)

No Requests for Comments

Real-Time Communication in WEB-browsers (rtcweb)
------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Cullen Jennings <[email protected]>
    Sean Turner <[email protected]>
    Ted Hardie <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/rtcweb
    Archive:            https://mailarchive.ietf.org/arch/browse/rtcweb/

Description of Working Group:


   There are a number of proprietary implementations that provide direct
   interactive rich communication using audio, video, collaboration,
   games, etc. between two peers' web-browsers. These are not
   interoperable, as they require non-standard extensions or plugins to
   work.  There is a desire to standardize the basis for such
   communication so that interoperable communication can be established
   between any compatible browsers. The goal is to enable innovation on
   top of a set of basic components.  One core component is to enable
   real-time media like audio and video, a second is to enable data
   transfer directly between clients.

   This work will be done in collaboration with the W3C.  The IETF WG
   will produce architecture and requirements for selection and profiling
   of the on the wire protocols. The architecture needs to be coordinated
   with W3C.  The IETF WG work will identify state information and events
   that need to be exposed in the APIs as input to W3C. The W3C will be
   responsible for defining APIs to ensure that application developers
   can control the components. We will reach out to the developer
   community for consultation and early feedback on implementation.

   The security and privacy goals and requirements will be developed by
   the WG. The security model needs to be coordinated with the W3C.  The
   work will also consider where support for extensibility is needed. RTP
   functionalities, media formats, security algorithms are example of
   things that commonly need extensions, additions or replacement, and
   thus some support for negotiation between clients is required.

   The WG will perform the following work:

   1.  Define the communication model in detail, including how session
       management is to occur within the model.

   2.  Define a security model that describes the security and privacy
       goals and specifies the security protocol mechanisms necessary
       to achieve those goals.

   3.  Define the solution - protocols and API requirements - for
       firewall and NAT traversal.

   4.  Define which media functions and extensions shall be supported in
       the client and their usage for real-time media, including media
       adaptation to ensure congestion safe usage.

   5.  Define what functionalities in the solution, such as media codecs,
       security algorithms, etc., can be extended and how the
       extensibility mechanisms works.

   6.  Define a set of media formats that must or should be supported by
       a client to improve interoperability.

   7.  Define how non media data is transported between clients in a
       secure and congestion safe way.

   8.  Provide W3C input for the APIs that comes from the communication
       model and the selected components and protocols that are part of
       the solution.

   9.  The group will consider options for interworking with legacy VoIP
       equipment.

   This work will be done primarily by using already defined protocols or
   functionalities. If there is identification of missing protocols or
   functionalities, such work can be requested to be done in another
   working group with a suitable charter or by requests for chartering it
   in this WG or another WG. The following topics will be out of scope
   for the initial phase of the WG: RTSP, RSVP, NSIS, Location services,
   Resource Priority, and IM & Presence specific features.

   The products of the working group will support security and keying as
   required by BCP 61 and be defined for IPv4, IPv6, and dual stack
   deployments. The Working Group will consider the possibility of
   defining a browser component that implements an existing session
   negotiation and management protocol. The working group will 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 use in web browsers.




Goals and Milestones:
 Feb 2014 - Complete Overview (and hold for dependency resolution) (draft-ietf-rtcweb-overview)
 Done     - Send Use Cases document (draft-ietf-rtcweb-use-cases-and- requirements) to IESG for publication as Informational
 Mar 2014 - Send Security and Privacy Problem Statement (draft-ietf- rtcweb-security) to IESG for publication as Informational
 Apr 2014 - Send Media Transport (draft-ietf-rtcweb-rtp-usage) to IESG for publication as Proposed Standard
 Apr 2014 - Audio Processing and Audio Codecs (draft-ietf-rtcweb-audio) to IESG for publication as Proposed Standard
 May 2014 - Send Data Stream Transport for non-media data (draft-ietf- rtcweb-data-channel) to IESG for publication as Proposed Standard
 Jun 2014 - Send Security Solution (draft-ietf-rtcweb-security-arch) to IESG for publication as Proposed Standard
 Jun 2014 - Send Specification of Transport Protocols and their NAT Traversal to IESG for publication as Proposed Standard
 Sep 2014 - Send Signalling Negotiation and NAT Traversal (draft-ietf- rtcweb-jsep) to IESG for publication as Proposed Standard
 Sep 2014 - Send STUN Usage for Consent Freshness to IESG for publication as proposed standard
 Dec 2014 - Video Processing and Video Codecs (draft-ietf-rtcweb-video) to IESG for publication as Proposed StandardVideo Processing and Video Codecs (draft-ietf-rtcweb-video) to IESG for publication as Proposed Standard
 Dec 2014 - Send Overview (after dependencies are ready) to IESG for publication as Applicability Statement

Internet-Drafts:
 - WebRTC Gateways [draft-alvestrand-rtcweb-gateways-02] (5 pages)
 - Overview: Real Time Protocols for Brower-based Applications [draft-alvestrand-rtcweb-overview-01] (14 pages)
 - Web Real-Time Communication Use-cases and Requirements [draft-holmberg-rtcweb-ucreqs-01] (11 pages)
 - Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)  [draft-ietf-rtcweb-alpn-04] (7 pages)
 - WebRTC Audio Codec and Processing Requirements [draft-ietf-rtcweb-audio-11] (7 pages)
 - Additional WebRTC Audio Codecs for Interoperability [draft-ietf-rtcweb-audio-codecs-for-interop-06] (12 pages)
 - IANA Registry for RTCWeb Constrainable Properties [draft-ietf-rtcweb-constraints-registry-03] (5 pages)
 - WebRTC Data Channels [draft-ietf-rtcweb-data-channel-13] (16 pages)
 - WebRTC Data Channel Establishment Protocol [draft-ietf-rtcweb-data-protocol-09] (13 pages)
 - WebRTC Forward Error Correction Requirements [draft-ietf-rtcweb-fec-07] (12 pages)
 - WebRTC Gateways [draft-ietf-rtcweb-gateways-02] (7 pages)
 - WebRTC IP Address Handling Requirements [draft-ietf-rtcweb-ip-handling-04] (9 pages)
 - JavaScript Session Establishment Protocol [draft-ietf-rtcweb-jsep-24] (115 pages)
 - Overview: Real Time Protocols for Browser-based Applications [draft-ietf-rtcweb-overview-19] (24 pages)
 - DSCP and other packet markings for RTCWeb QoS [draft-ietf-rtcweb-qos-00] (10 pages)
 - Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC [draft-ietf-rtcweb-return-02] (18 pages)
 - Web Real-Time Communication (WebRTC): Media Transport and Use of RTP [draft-ietf-rtcweb-rtp-usage-26] (46 pages)
 - Annotated Example SDP for WebRTC [draft-ietf-rtcweb-sdp-08] (107 pages)
 - Security Considerations for WebRTC [draft-ietf-rtcweb-security-10] (25 pages)
 - WebRTC Security Architecture [draft-ietf-rtcweb-security-arch-13] (40 pages)
 - Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness [draft-ietf-rtcweb-stun-consent-freshness-16] (10 pages)
 - Transports for WebRTC [draft-ietf-rtcweb-transports-17] (20 pages)
 - Web Real-Time Communication Use Cases and Requirements [draft-ietf-rtcweb-use-cases-and-requirements-16] (28 pages)
 - WebRTC Video Processing and Codec Requirements [draft-ietf-rtcweb-video-06] (10 pages)
 - STUN Usage for Consent Freshness [draft-muthu-behave-consent-freshness-04] (7 pages)
 - SDP for the WebRTC [draft-nandakumar-rtcweb-sdp-08] (104 pages)
 - Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC [draft-schwartz-rtcweb-return-06] (18 pages)
 - WebRTC IP Address Handling Recommendations [draft-shieh-rtcweb-ip-handling-00] (6 pages)

Requests for Comments:
 RFC7478: Web Real-Time Communication Use Cases and Requirements (28 pages)
 RFC7675: Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness (10 pages)
 RFC7742: WebRTC Video Processing and Codec Requirements (10 pages)
 RFC7874: WebRTC Audio Codec and Processing Requirements (7 pages)
 RFC7875: Additional WebRTC Audio Codecs for Interoperability (12 pages)



Registration Protocols Extensions (regext)
------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Antoin Verschuren <[email protected]>
    James Galvin <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/regext
    Archive:            https://mailarchive.ietf.org/arch/browse/regext/

Description of Working Group:

 The Extensible Provisioning Protocol (EPP, Standard 69) is the
 standard domain name provisioning protocol for top-level domain name
 registries.  To avoid many separate EPP extensions that provide
 the same functions, it's important to coordinate and standardize EPP
 extensions.

 The EPP Extensions (EPPEXT) working group completed its first goal of
 creating an IANA registry of EPP extensions.  The registration process
 of the registry is documented in RFC7451.  Extensions may be
 registered for informational purposes as long as there is a published
 specification that has been reviewed by a designated expert.

 The Registration Data Access Protocol (RDAP, RFCs 7480-7484) is the
 proposed standard for retrieving registration metadata from both
 domain name and Regional Internet Registries.  To ensure interoperable
 implementations it's important to coordinate and standardize
 extensions and profiles to be used by registries.

 Extensions in both cases that are targeted for the Standards Track are
 subject to more thorough review and open discussion within the IETF.

 In addition, commonality may be discovered in related extensions,
 especially EPP extensions listed on the EPP extension registry, for
 which it would makes sense to merge them into a single standard
 extension everybody agrees on.

 The REGEXT working group is the home of the coordination effort for
 standards track extensions.  The selection of extensions for standards
 track shall incorporate the following guidelines.

 1. Proprietary documented extensions and individual submissions of
 informational or experimental EPP extensions will follow the expert
 review process as described in RFC7451 for inclusion in the EPP
 extensions registry. These documents will not be part of the REGEXT
 working group work or milestones. The working group may discuss or
 advise on these documents.

 2. Extensions that seek standards track status can be suggested for WG
 adoption.  If accepted by the working group then the development of
 the standard may proceed.

 3. When there are no more proposals for Standards-Track extensions,
 the working group will either close or become dormant, with the
 decision made in consultation with the responsible AD.  The charter
 will be reviewed by the end of 2017 and will be refreshed by
 rechartering if there is still a reason to keep the working group
 going.  In any case, the mailing list will remain open and available
 for the use of the expert review process as described in RFC7451.

 The working group will also identify the requirements for a
 registration protocol that allows a third-party service provider to
 exchange information with a registry without the need of a registrar
 proxy in the middle of the exchange.  These requirements will be
 documented in an Informational RFC.

 The working group will focus initially on the backlog of EPP and RDAP
 extensions.

Goals and Milestones:
 RFC 8056     - Submit for publication "EPP and RDAP Status Mapping"
 Jun 2017 - Submit for publication "Launch Phase Mapping for EPP"
 Jul 2017 - Submit for publication "Registry Fee Extension for EPP"
 Nov 2017 - Submit for publication "Organization Extension for EPP"
 Nov 2017 - Submit for publication "EPP Organization Mapping"
 Nov 2017 - Submit for publication "Change Poll Extension for EPP"
 Nov 2017 - Submit for publication "Allocation Token Extension for EPP"
 Jan 2018 - Submit for publication an informational RFC with requirements for a registration protocol for third-party DNS providers
 May 2018 - Submit for publication "Validate Mapping for the Extensible Provisioning Protocol"
 Jun 2018 - Submit for publication "EPP Domain Name Mapping Extension for Bundling Registration"

Internet-Drafts:
 - Key Relay Mapping for the Extensible Provisioning Protocol [draft-ietf-eppext-keyrelay-12] (16 pages)
 - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-eppext-launchphase-07] (61 pages)
 - ICANN TMCH functional specifications [draft-ietf-eppext-tmch-func-spec-01] (60 pages)
 - Allocation Token Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-allocation-token-06] (22 pages)
 - Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration [draft-ietf-regext-bundling-registration-02] (21 pages)
 - Change Poll Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-change-poll-07] (26 pages)
 - Third Party DNS operator to Registrars/Registries Protocol [draft-ietf-regext-dnsoperator-to-rrr-protocol-04] (15 pages)
 - Registry Fee Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-fees-09] (36 pages)
 - Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping [draft-ietf-regext-epp-rdap-status-mapping-04] (11 pages)
 - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-launchphase-07] (70 pages)
 - Extensible Provisioning Protocol (EPP) China Name Verification Mapping [draft-ietf-regext-nv-mapping-00] (37 pages)
 - Extensible Provisioning Protocol (EPP) Organization Mapping [draft-ietf-regext-org-01] (35 pages)
 - Organization Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-org-ext-01] (19 pages)
 - Registration Data Access Protocol (RDAP) Object Tagging [draft-ietf-regext-rdap-object-tag-00] (12 pages)
 - Extensible Provisioning Protocol (EPP) Reseller Mapping [draft-ietf-regext-reseller-01] (30 pages)
 - Reseller Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-reseller-ext-01] (18 pages)
 - ICANN TMCH functional specifications [draft-ietf-regext-tmch-func-spec-03] (62 pages)
 - Validate Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-validate-03] (14 pages)
 - Verification Code Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-verificationcode-02] (35 pages)

Requests for Comments:
 RFC8056: Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping (11 pages)
 RFC8063: Key Relay Mapping for the Extensible Provisioning Protocol (16 pages)



Secure Telephone Identity Revisited (stir)
------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Robert Sparks <[email protected]>
    Russ Housley <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Adam Roach <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/stir
    Archive:            https://mailarchive.ietf.org/arch/browse/stir/

Description of Working Group:

 The STIR working group will specify Internet-based mechanisms that allow
 verification of the calling party's authorization to use a particular
 telephone number for an incoming call.  Since it has  become fairly easy
 to present an incorrect source telephone number, a growing set of
 problems have emerged over the last decade.  As with email, the claimed
 source identity of a SIP request is not verified, permitting
 unauthorized use of the source identity as part of deceptive and
 coercive activities, such as robocalling (bulk unsolicited commercial
 communications), vishing (voicemail hacking, and impersonating banks)
 and swatting (impersonating callers to emergency services to stimulate
 unwarranted large scale law enforcement deployments).  In addition, use
 of an incorrect source telephone number facilitates wire fraud or can
 lead to a return call at premium rates.

 SIP is one of the main VoIP technologies used by parties that want to
 present an incorrect origin, in this context an origin telephone number.
 Several previous efforts have tried to secure the origins of SIP
 communications, including RFC 3325, RFC 4474, and the VIPR working
 group.  To date, however, true validation of the source of SIP calls has
 not seen any appreciable deployment.  Several factors contributed to
 this lack of success, including: failure of the problem to be seen as
 critical at the time; lack of any technical means of producing a proof
 of authorization to use telephone numbers; misalignment of the
 mechanisms proposed by RFC 4474 with the complex deployment environment
 that has emerged for SIP; lack of end-to-end SIP session establishment;
 and inherent operational problems with a transitive trust model.  To
 make deployment of this solution more likely, consideration must be
 given to latency, real-time performance, computational overhead, and
 administrative overhead for the legitimate call source and all
 verifiers.

 As its priority mechanism work item, the working group will specify a
 SIP header-based mechanism for verification that the originator of a SIP
 session is authorized to use the claimed source telephone number, where
 the session is established with SIP end to end.  This is called an in-
 band mechanism. The mechanism will use a canonical telephone number
 representation specified by the working group, including any mappings
 that  might be needed between the SIP header fields and the canonical
 telephone  number representation.  The working group will consider
 choices for protecting identity information and credentials used.  This
 protection will likely be based on a digital signature mechanism that
 covers a set of information in the SIP header fields, and verification
 will employ a credential that contains the public key that is associated
 with the one or more telephone numbers.  Credentials used with this
 mechanism will be derived from existing telephone number assignment and
 delegation models.  That is, when a telephone number or range of
 telephone numbers is delegated to an entity, relevant credentials will
 be generated (or modified) to reflect such delegation.  The mechanism
 must allow a telephone number holder to further delegate and revoke use
 of a telephone number without compromising the global delegation scheme.

 In addition to its priority mechanism work item, the working group will
 consider a mechanism for verification of the originator during session
 establishment in an environment with one or more non-SIP hops, most
 likely requiring an out-of-band authorization mechanism.  However, the
 in-band and the out-of-band mechanisms should share as much in common as
 possible, especially the credentials.  The in-band mechanism must be
 sent to the IESG for approval and publication prior to the out-of-band
 mechanism.

 The work of this group is limited to developing a solution for telephone
 numbers. Expansion of the authorization mechanism to identities using the
 user@domain or other name forms is out of scope.

 The working group will coordinate with the Security Area on credential
 management and signature mechanics.

 The working group will coordinate with other working groups in the RAI
 Area regarding signaling through existing deployments.

 The working group welcomes input from potential implementors or
 operators of technologies developed by this working group.  For example,
 national numbering authorities might consider acting as credential
 authorities for telephone numbers within their purview.

 It is important to note that while the main focus of this working group
 is telephone numbers, the STIR working group will not develop any
 mechanisms that require changes to circuit-switched technologies.

 Authentication and authorization of identity is closely linked to
 privacy, and these security features sometimes come at the cost of
 privacy.  Anonymous calls are already defined in SIP standards, and this
 working group will not propose changes to these standards.  In order to
 support anonymity, the working group will provide a solution in which
 the called party receives an indication that the source telephone number
 is unavailable.  This working group, to the extent feasible, will
 specify privacy-friendly mechanisms that do not reveal any more
 information to user agents or third parties than a call that does not
 make use of secure telephone identification mechanisms.

 Input to working group discussions shall include:

   - Private Extensions to the Session Initiation Protocol (SIP)
     for Asserted Identity within Trusted Networks
     [RFC 3325]

   - Enhancements for Authenticated Identity Management in the
     Session Initiation Protocol (SIP)
     [RFC 4474]

   - Secure Call Origin Identification
     [draft-cooper-iab-secure-origin-00]

   - Secure Origin Identification: Problem Statement, Requirements,
     and Roadmap
     [draft-peterson-secure-origin-ps-00]

   - Authenticated Identity Management in the Session Initiation
     Protocol (SIP)
     [draft-jennings-dispatch-rfc4474bis-00]

 The working group will deliver the following:

   - A problem statement detailing the deployment environment and
     situations that motivate work on secure telephone identity

   - A threat model for the secure telephone identity mechanisms

   - A privacy analysis of the secure telephone identity mechanisms

   - A document describing the SIP in-band mechanism for telephone
     number-based identities during call setup

   - A document describing the credentials required to support
     telephone number identity authentication

   - A document describing the out-of-band mechanism for telephone
     number-based identities during call setup

Goals and Milestones:
 Done     - Submit problem statement for Informational
 Done     - Submit threat model for Informational
 Done     - Submit in-band mechanism for Proposed Standard
 Done     - Submit credential specification for Proposed Standard
 Nov 2017 - Submit out-of-band mechanism for Proposed Standard
 Mar 2018 - Submit Privacy analysis for Informational

Internet-Drafts:
 - Secure Telephone Identity Credentials: Certificates [draft-ietf-stir-certificates-18] (22 pages)
 - OCSP Usage for Secure Telephone Identity Certificates [draft-ietf-stir-certificates-ocsp-00] (12 pages)
 - STIR Out-of-Band Architecture and Use Cases [draft-ietf-stir-oob-01] (18 pages)
 - Personal Assertion Token (PASSporT) [draft-ietf-stir-passport-11] (22 pages)
 - PASSporT Extension for Diverted Calls [draft-ietf-stir-passport-divert-01] (9 pages)
 - PASSporT Extension for Rich Call Data [draft-ietf-stir-passport-rcd-00] (10 pages)
 - PASSporT SHAKEN Extension (SHAKEN) [draft-ietf-stir-passport-shaken-00] (7 pages)
 - Secure Telephone Identity Problem Statement and Requirements [draft-ietf-stir-problem-statement-05] (25 pages)
 - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-ietf-stir-rfc4474bis-16] (45 pages)
 - PASSporT Extension for Resource-Priority Authorization [draft-ietf-stir-rph-03] (9 pages)
 - Secure Telephone Identity Threat Model [draft-ietf-stir-threats-04] (13 pages)

Requests for Comments:
 RFC7340: Secure Telephone Identity Problem Statement and Requirements (25 pages)
 RFC7375: Secure Telephone Identity Threat Model (13 pages)



Selection of Language for Internet Media (slim)
-----------------------------------------------

Charter
Last Modified: 2017-11-11

Current Status: Active

Chair:
    Dr. Bernard D. Aboba Ph.D. <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/slim
    Archive:            https://mailarchive.ietf.org/arch/browse/slim/

Description of Working Group:

 A mutually comprehensible language is helpful for human communication.
 This is true across a range of circumstances and environments.  In
 general, the problem is most acute in situations where there is not a
 clear choice for a single language, such as environments lacking
 contextual or out-of-band information regarding the identity of the
 parties and the language to be used.

 The group will address two specific cases that most urgently need a
 technical solution: One problem space is non-real-time communication,
 specifically email for one-to-many or where the set of recipients is
 dynamic or different recipients require different languages; the other
 is real-time communication, specifically emergency calling, preferably
 also useful for other cases where the parties may not know each other
 personally or where one party wishes to accommodate people with varying
 language and media needs.

 In the real-time communication case, language and media are
 intrinsically linked, for example, signed languages require a video
 media.

 While the two use cases are in different contexts (real time and
 non-real-time), the fundamental goal is the same: to enable selection of
 the best-fit language(s) for a specific situation.  Some of the details
 will also be in common across the cases, e.g., the language tags.
 Having a single WG address both cases makes it clear that these are two
 aspects of the same basic problem.  A single WG also makes it easier to
 maximize similarities and avoid unnecessary fragmentation of the
 solutions and facilitates broader review.

 The group will start by producing specifications for email and for
 real-time communications.

 In the email case, the group will determine a MIME based solution (based
 on draft-tomkinson-slim-multilangcontent) that enables a single email
 message to contain multiple language versions of the content, with
 provisions to help clients select a best-fit version.

 In the real-time communication case, the group will produce a
 specification (based on draft-gellens-slim-negotiating-human-language)
 enabling negotiation of a human language per media stream.  The
 specification must be suitable for use in emergency communications as
 specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate
 media); it is desirable to also be suitable for use in non-emergency
 real-time communications that share the same call set-up and media
 negotiation protocols.  The mechanism will permit the caller's media and
 language needs and preferences to be matched against what the called
 party is able to provide.  Alternatives such as doing the media
 negotiation in SIP have been explored in the past and are out of scope
 (although SIP-based mechanisms may be introduced when routing
 considerations are addressed).

 The group's initial focus will not be on supporting language-based call
 routing decisions.  Once the initial work is sufficiently progressed, the
 group may  address call routing, with the timing at the judgment of the
 chairs.

 Recognizing that complex solutions are significantly less
 likely to see widespread deployment, the group will solve the most
 common use cases and avoid adding complexity to solve edge or
 less-common cases.

 By adding language to the existing media negotiation mechanism as used
 in RFC 6443 and RFC 6881, the group can meet the basic use cases with
 minimal added complexity and be able to enhance later for additional use
 cases as needed.

Goals and Milestones:
 Mar 2016 - Submit "Multiple Language Content Type" to the IESG (based on draft-tomkinson-slim-multilangcontent)
 Mar 2016 - Submit "Negotiating Human Language in Real-Time Communications" to the IESG (based on draft-gellens-slim-negotiating-human-language)

Internet-Drafts:
 - Multiple Language Content Type [draft-ietf-slim-multilangcontent-14] (19 pages)
 - Negotiating Human Language in Real-Time Communications [draft-ietf-slim-negotiating-human-language-23] (17 pages)
 - SLIM Use Cases [draft-ietf-slim-use-cases-01] (7 pages)

Requests for Comments:
 RFC8255: Multiple Language Content Type (19 pages)



Session Initiation Protocol Core (sipcore)
------------------------------------------

Charter
Last Modified: 2017-03-30

Current Status: Active

Chairs:
    Brian Rosen <[email protected]>
    Jean Mahoney <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/sipcore
    Archive:            https://mailarchive.ietf.org/arch/browse/sipcore/

Description of Working Group:

 The Session Initiation Protocol Core (SIPCore) working group is
 chartered to maintain and continue the development of the SIP protocol,
 currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
 6665.

 The SIPCore working group will concentrate on specifications that update
 or replace the core SIP specifications named above as well as
 specifications pertaining to small, self-contained SIP protocol
 extensions.  The process and requirements for new SIP extensions are
 documented in RFC5727, "Change Process for the Session Initiation
 Protocol".

 Throughout its work, the group will strive to maintain the basic model
 and architecture defined by SIP. In particular:

   1. Services and features are provided end-to-end whenever possible.

   2. Reuse of existing Internet protocols and architectures and
      integrating with other Internet applications is crucial.

   3. Standards-track extensions and new features must be generally
      applicable, and not applicable only to a specific set of session
      types.

   4. Simpler solutions that solve a given problem should be favored
       over more complex solutions.

 The primary source of change requirements to the core SIP specifications
 (enumerated above) will be a) interoperability problems that stem from
 ambiguous, or under-defined specification, and b) requirements from
 other working groups in the ART Area. The primary source of new protocol
 extensions is the DISPATCH working group, which will generally make the
 determination regarding whether new SIP-related work warrants a new
 working group or belongs in an existing one.


Goals and Milestones:
 Done     - INFO package framework to IESG (PS)
 Done     - Termination of early dialog prior to final response to IESG (PS)
 Done     - Invite Transaction Handling Correction to IESG (PS)
 Done     - Extension for use in etags in conditional notification to IESG (PS)
 Done     - SIP Events throttling mechanism to IESG (PS)
 Done     - Presence Scaling Requirements to IESG as Info
 Done     - Mechanism for indicating support for keep-alives (PS)
 Done     - Example security flows to IESG (Informational)
 Done     - Location Conveyance with SIP to IESG (PS)
 Done     - Error corrections and clarifications to RFC3265 to IESG (PS)
 Dropped     - WGLC on requirements for a mechanism to indicate proxy capabilities to both endpoints and other proxies in the path of a REGISTER transaction or a dialog-forming transaction.
 Done     - Delivering request-URI and parameters to UAS via proxy to IESG (PS)
 Done     - Mechanism to indicate proxy capabilities to both endpoints and other intermediaries in the path of a REGISTER transaction or dialog-forming transaction to IESG (PS)
 Done     - WebSockets transport definition for SIP to the IESG (proposed standard)
 Done     - Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs
 Done     - Request publication of a SIP response code for unwanted communications
 Apr 2017 - Request publication of a mechanism for labeling the nature of SIP calls
 Done     - Request publication of a clarification of the use of Content-ID as a SIP header field
 May 2017 - Request publication of a clarification of the use of the "name-addr" production in SIP header fields
 Dec 2017 - Request publication of mechanisms for rapid dual-stack protocol selection in SIP

Internet-Drafts:
 - Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog [draft-ietf-sipcore-199-06] (14 pages)
 - A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework [draft-ietf-sipcore-6665-clarification-00] (4 pages)
 - SIP Call-Info Parameters for Labeling Calls [draft-ietf-sipcore-callinfo-spam-02] (9 pages)
 - Content-ID Header Field in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-content-id-10] (14 pages)
 - Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network [draft-ietf-sipcore-dns-dual-stack-08] (10 pages)
 - Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control [draft-ietf-sipcore-event-rate-control-09] (25 pages)
 - Session Initiation Protocol (SIP) INFO Method and Package Framework [draft-ietf-sipcore-info-events-10] (36 pages)
 - Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests [draft-ietf-sipcore-invfix-01] (20 pages)
 - Indication of Support for Keep-Alive [draft-ietf-sipcore-keep-12] (18 pages)
 - Location Conveyance for the Session Initiation Protocol [draft-ietf-sipcore-location-conveyance-09] (35 pages)
 - Clarifications for When to Use the name-addr Production in SIP Messages [draft-ietf-sipcore-name-addr-guidance-02] (6 pages)
 - A P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP) [draft-ietf-sipcore-originating-cdiv-parameter-01] (13 pages)
 - Scaling Requirements for Presence in SIP/SIMPLE [draft-ietf-sipcore-presence-scaling-requirements-02] (9 pages)
 - IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field [draft-ietf-sipcore-priority-00] (3 pages)
 - Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-proxy-feature-12] (19 pages)
 - Requirements for indication of features supported by a SIP proxy [draft-ietf-sipcore-proxy-feature-reqs-03] (9 pages)
 - ISUP Cause Location Parameter for the SIP Reason Header Field [draft-ietf-sipcore-reason-q850-loc-02] (6 pages)
 - Clarifications for the Use of REFER with RFC 6665 [draft-ietf-sipcore-refer-clarifications-04] (6 pages)
 - Explicit Subscriptions for the REFER Method [draft-ietf-sipcore-refer-explicit-subscription-03] (14 pages)
 - Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-reinvite-08] (26 pages)
 - SIP-Specific Event Notification [draft-ietf-sipcore-rfc3265bis-09] (53 pages)
 - An Extension to the Session Initiation Protocol (SIP) for Request History Information [draft-ietf-sipcore-rfc4244bis-12] (36 pages)
 - Session Initiation Protocol (SIP) History-Info Header Call Flow Examples [draft-ietf-sipcore-rfc4244bis-callflows-08] (52 pages)
 - Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms [draft-ietf-sipcore-sec-flows-09] (67 pages)
 - Session Initiation Protocol (SIP) Session Timer Glare Handling [draft-ietf-sipcore-sessiontimer-race-00] (8 pages)
 - Third-Party Authentication for Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-authn-02] (17 pages)
 - Push Notification with the Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-push-04] (15 pages)
 - The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-websocket-10] (25 pages)
 - A SIP Response Code for Unwanted Calls [draft-ietf-sipcore-status-unwanted-06] (8 pages)
 - An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification [draft-ietf-sipcore-subnot-etags-04] (25 pages)
 - The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" [draft-rosen-rph-reg-policy-01] (2 pages)

Requests for Comments:
 RFC5839: An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification (25 pages)
 RFC6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests (20 pages)
          * Updates RFC3261
 RFC6086: Session Initiation Protocol (SIP) INFO Method and Package Framework (36 pages)
          * Obsoletes RFC2976
 RFC6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) (26 pages)
          * Updates RFC3261
 RFC6216: Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms (67 pages)
 RFC6223: Indication of Support for Keep-Alive (18 pages)
 RFC6228: Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog (14 pages)
 RFC6442: Location Conveyance for the Session Initiation Protocol (35 pages)
          * Updates RFC8262
 RFC6446: Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control (25 pages)
          * Updates RFC3265
 RFC6665: SIP-Specific Event Notification (53 pages)
          * Obsoletes RFC3265
          * Updates RFC3261
          * Updates RFC4660
          * Updates RFC7621
 RFC6809: Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) (19 pages)
 RFC6878: IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field (3 pages)
          * Updates RFC3261
 RFC7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information (36 pages)
          * Obsoletes RFC4244
 RFC7118: The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) (25 pages)
 RFC7131: Session Initiation Protocol (SIP) History-Info Header Call Flow Examples (52 pages)
 RFC7134: The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" (2 pages)
          * Updates RFC4412
 RFC7614: Explicit Subscriptions for the REFER Method (14 pages)
 RFC7621: A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework (4 pages)
          * Updates RFC6665
 RFC7647: Clarifications for the Use of REFER with RFC 6665 (6 pages)
          * Updates RFC3515
 RFC7984: Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network (10 pages)
          * Updates RFC3263
 RFC8197: A SIP Response Code for Unwanted Calls (8 pages)
 RFC8217: Clarifications for When to Use the name-addr Production in SIP Messages (6 pages)
          * Updates RFC3261
          * Updates RFC3325
          * Updates RFC3515
          * Updates RFC3892
          * Updates RFC4508
          * Updates RFC5002
          * Updates RFC5318
          * Updates RFC5360
          * Updates RFC5502
 RFC8262: Content-ID Header Field in the Session Initiation Protocol (SIP) (14 pages)
          * Updates RFC5621
          * Updates RFC5368
          * Updates RFC6442



SIP Best-practice Recommendations Against Network Dangers to privacY (sipbrandy)
--------------------------------------------------------------------------------

Charter
Last Modified: 2016-08-03

Current Status: Active

Chairs:
    Gonzalo Camarillo <[email protected]>
    Gonzalo Salgueiro <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/sipbrandy
    Archive:            https://mailarchive.ietf.org/arch/browse/sipbrandy/

Description of Working Group:

 SIP with the SDP Offer/Answer model, along with RTP are widely used in
 modern communications networks. But while secure RTP (SRTP) is available
 to provide integrity and privacy protection to such communication, it is
 rarely used end-to-end. This lack is due to several factors, notably the
 pervasive use of signaling and media intermediaries in such networks and
 the difficulties involved in deployment of strong identity mechanisms
 for SIP. These factors are complicated by the fact that there are
 several incompatible approaches to SRTP key exchange.

 The current situation is unacceptable in the face of pervasive
 monitoring, which RFC 7258 describes as "an attack on privacy". In
 addition, the STIR working group is, at the time of this writing,
 revising RFC 4744 to make strong identity attestations for SIP easier to
 deploy. This gives the IETF an opportunity to define best practices to
 improve privacy protections for users of SIP based communication, in
 ways that improve upon the status-quo.

 Objectives:

 The SIPBRANDY working group will define best practices for establishing
 two-party, SIP-signaled SRTP sessions with end-to-end security
 associations, including a single, preferred SRTP key exchange mechanism.
 These practices are expected to be deployable across typical SIP
 networks, without the sharing of SRTP keying material with
 intermediaries or third parties. These practices should protect against
 man-in-the-middle attacks.

 While confidentiality is the first priority of the working group, it may
 work on aligning these practices with WebRTC, for example by defining
 best practices for ensuring recipients of media flows have indicated the
 desire to receive them, in order to prevent or mitigate the denial-of-
 service attack described in RFC 5245, section 18.5.1. Likewise, the WG
 may consider compatibility with aspects of PERC.

 The working group will additionally coordinate with the MMUSIC working
 group to define opportunistic security [RFC 7435] for SIP-signaled media
 sessions for situations where strong protections are not necessary or
 not feasible.

 Non-Goals:

 The working group is not expected to define practices for multi-party
 session topologies, especially those involving media distribution
 devices.

 The working group is not expected to define new protocols or modify
 existing ones; rather it will define practices for using existing
 protocols. If the working group discovers gaps that require creation or
 modification protocols, it will forward those gaps to the appropriate
 working groups.

 Inputs and Collaboration:

 The WG will consider draft-peterson-dispatch-rtpsec and
 draft-johnston-dispatch-osrtp as input to the work. The WG is expected
 to collaborate closely with SIPCORE, AVTCORE, STIR, MMUSIC, RTCWEB,
 PERC, and possibly DISPATCH.

Goals and Milestones:
 Done     - Draft Adoption - Best Practices for end-to-end SRTP
 Done     - Draft Adoption - Best Practices for Opportunistic SRTP
 Mar 2017 - Submit End-to-End SRTP draft to the IESG for consideration as BCP
 Mar 2017 - Inform MMUSIC or other appropriate WGs of any changes needed to support Opportunistic SRTP (Not expected to be published as an RFC)
 Nov 2017 - Submit Opportunistic SRTP draft to IESG for consideration as BCP

Internet-Drafts:
 - An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) [draft-ietf-sipbrandy-osrtp-03] (8 pages)
 - Best Practices for Securing RTP Media Signaled with SIP [draft-ietf-sipbrandy-rtpsec-03] (14 pages)

No Requests for Comments

Using TLS in Applications (uta)
-------------------------------

Charter
Last Modified: 2017-11-14

Current Status: Active

Chairs:
    Leif Johansson <[email protected]>
    Valery Smyslov <[email protected]>

Applications and Real-Time Area Directors:
    Ben Campbell <[email protected]>
    Alexey Melnikov <[email protected]>
    Adam Roach <[email protected]>

Applications and Real-Time Area Advisor:
    Alexey Melnikov <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/uta
    Archive:            https://mailarchive.ietf.org/arch/browse/uta/

Description of Working Group:

 There is a renewed and urgent interest in the IETF to increase the security of transmissions over the Internet. Many application protocols have defined methods for using TLS to authenticate the server (and sometimes the client), and to encrypt the connection between the client and server. However, there is a diversity of definitions and requirements, and that diversity has caused confusion for application developers and also has led to lack of interoperability or lack of deployment. Implementers and deployers are faced with multiple security issues in real-world usage of TLS, which currently does not preclude insecure ciphers and modes of operation.

 This WG has the following tasks:

 - Update the definitions for using TLS over a set of representative application protocols.  This includes communication with proxies, between servers, and between peers, where appropriate, in addition to client/server communication.

 - Specify a set of best practices for TLS clients and servers, including but not limited to recommended versions of TLS, using forward secrecy, and one or more ciphersuites and extensions that are mandatory to implement.

 - Consider, and possibly define, a standard way for an application client and server to use unauthenticated encryption through TLS when server and/or client authentication cannot be achieved.

 - Create a document that helps application protocol developers use TLS in future application definitions.

 The initial set of representative application protocols is SMTP, POP, IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use TLS might later be updated using the guidelines from this WG, and that those updates will happen through other WGs or through individual submissions.

 The WG will make the fewest changes needed to achieve good interoperable security for the applications using TLS.  No changes to TLS itself will be made in this WG, and the WG will ensure that changes to current versions of popular TLS libaries will not be required to conform to the WG's specifications.

 This WG will collaborate with other IETF WGs, in particular with the TLS and DANE WGs.

Goals and Milestones:

Internet-Drafts:
 - Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access [draft-ietf-uta-email-deep-12] (26 pages)
 - Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols [draft-ietf-uta-email-tls-certs-09] (13 pages)
 - SMTP MTA Strict Transport Security (MTA-STS) [draft-ietf-uta-mta-sts-14] (25 pages)
 - SMTP Require TLS Option [draft-ietf-uta-smtp-require-tls-01] (15 pages)
 - SMTP TLS Reporting [draft-ietf-uta-smtp-tlsrpt-14] (26 pages)
 - Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) [draft-ietf-uta-tls-attacks-05] (13 pages)
 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-ietf-uta-tls-bcp-11] (27 pages)
 - Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) [draft-ietf-uta-xmpp-07] (9 pages)
 - Deployable Enhanced Email Privacy (DEEP) [draft-newman-email-deep-02] (35 pages)

Requests for Comments:
 BCP195: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (27 pages)
 RFC7457: Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) (13 pages)
 RFC7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (27 pages)
 RFC7590: Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) (9 pages)
          * Updates RFC6120
 RFC7817: Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols (13 pages)
          * Updates RFC2595
          * Updates RFC3207
          * Updates RFC3501
          * Updates RFC5804
 RFC8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access (26 pages)
          * Updates RFC1939
          * Updates RFC2595
          * Updates RFC3501
          * Updates RFC5068
          * Updates RFC6186
          * Updates RFC6409



Meeting Venue (mtgvenue)
------------------------

Charter
Last Modified: 2018-01-30

Current Status: Active

Chairs:
    Charles Eckel <[email protected]>
    Pete Resnick <[email protected]>

General Area Directors:
    Alissa Cooper <[email protected]>

General Area Advisor:
    Alissa Cooper <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Distributed Mobility Management (dmm)
-------------------------------------

Charter
Last Modified: 2017-09-25

Current Status: Active

Chairs:
    Dapeng Liu <[email protected]>
    Sri Gundavelli <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



DNS PRIVate Exchange (dprive)
-----------------------------

Charter
Last Modified: 2017-07-03

Current Status: Active

Chairs:
    Brian Haberman <[email protected]>
    Tim Wicinski <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Terry Manderson <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Dynamic Host Configuration (dhc)
--------------------------------

Charter
Last Modified: 2016-08-10

Current Status: Active

Chairs:
    Bernie Volz <[email protected]>
    Tomek Mrugalski <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Extensions for Scalable DNS Service Discovery  (dnssd)
------------------------------------------------------

Charter
Last Modified: 2017-11-15

Current Status: Active

Chairs:
    David Schinazi <[email protected]>
    Tim Chown <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Terry Manderson <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Home Networking (homenet)
-------------------------

Charter
Last Modified: 2017-09-06

Current Status: Active

Chairs:
    Barbara Stark <[email protected]>
    Ray Bellis <[email protected]>
    Stephen Farrell <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Terry Manderson <[email protected]>

Tech Advisor:
    Acee Lindem <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Host Identity Protocol (hip)
----------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chair:
    Gonzalo Camarillo <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Terry Manderson <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Internet Area Working Group (intarea)
-------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Juan-Carlos Zúñiga <[email protected]>
    Wassim Haddad <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 Wireless Access in Vehicular Environments (ipwave)
-----------------------------------------------------

Charter
Last Modified: 2016-10-18

Current Status: Active

Chairs:
    Carlos Jésus Bernardos <[email protected]>
    Russ Housley <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

IPv6 Maintenance (6man)
-----------------------

Charter
Last Modified: 2016-04-06

Current Status: Active

Chairs:
    Ole Troan <[email protected]>
    Robert M. Hinden <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 Low Power Wide-Area Networks (lpwan)
----------------------------------------------

Charter
Last Modified: 2016-10-14

Current Status: Active

Chairs:
    Alexander Pelov <[email protected]>
    Pascal Thubert <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

IPv6 over Networks of Resource-constrained Nodes (6lo)
------------------------------------------------------

Charter
Last Modified: 2016-04-06

Current Status: Active

Chairs:
    Gabriel Montenegro <[email protected]>
    Samita Chakrabarti <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Tech Advisor:
    Ralph Droms <[email protected]>

Secretary:
    james woodyatt <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 over the TSCH mode of IEEE 802.15.4e (6tisch)
--------------------------------------------------

Charter
Last Modified: 2016-04-06

Current Status: Active

Chairs:
    Pascal Thubert <[email protected]>
    Thomas Watteyne <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Light-Weight Implementation Guidance (lwig)
-------------------------------------------

Charter
Last Modified: 2017-09-19

Current Status: Active

Chairs:
    Mohit Sethi <[email protected]>
    Zhen Cao <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Network Time Protocol (ntp)
---------------------------

Charter
Last Modified: 2017-08-09

Current Status: Active

Chairs:
    Dieter Sibold <[email protected]>
    Karen O'Donoghue <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/ntp
    Archive:            https://mailarchive.ietf.org/arch/browse/ntp/

Description of Working Group:


   The Network Time Protocol (NTP) is widely deployed and used
   in the Internet. However, the standardization status of this
   protocol has lagged in the IETF. RFC 1305 (NTP version 3) was
   published in March 1992 and remains unchanged and at Draft
   Standard status. RFC 1305 represents the majority of full NTP
   implementations deployed today. RFC 2030 (SNTP version 4)
   was published as an Informational RFC in October 1996 as a
   lightweight version of NTP for deployments not requiring the full
   functionality of NTP. SNTP now represents the majority of both
   NTP traffic and NTP implementation issues on the Internet. A
   good deal of work has been produced in the NTP community
   updating both NTPv3 and SNTPv4. This work is ongoing and
   available through the collaborative development effort in the NTP
   community, but it has not been reflected back into the NTP
   specifications.

   The goal of this working group is to document NTPv4 based on
   the extensive work of the NTP community and to advance the
   standardization status of NTP. It is an explicit goal of this effort to
   have NTPv4 interoperate with the deployed base avoiding any
   backwards-incompatible changes.

   A number of topics have been raised as potential work items for
   an update to NTP including support for IPv6, security
   considerations including authentication, automatic configuration
   including possible requirements for DHCP, and algorithm
   improvements. This working group will focus first on delivering
   NTPv4 and will defer additional development efforts until after
   the delivery of NTPv4. Support for IPv6 and defining
   mechanisms for securing NTP transactions is considered part of
   the core NTPv4 functionality. Potential further modifications and
   additions to the NTP protocol will be documented for possible
   further work beyond the initial NTPv4 effort.

   The working group will initially focus on the following
   deliverables:
   1. NTPv4 Scope and Requirements Document
   (documenting the scope of the NTPv4 update and
   identifying issues deferred for future work).
   2. NTPv4 Protocol Specification (documenting the protocol
   on the wire)
   3. NTPv4 Architecture and Algorithms Specification
   (documenting the architecture, mathematical algorithms,
   and behavior of NTP servers and clients)
   4. NTPv4 MIB (provision for management and monitoring
   of NTP via SNMP)




Goals and Milestones:
 Done     - NTP BOF at IETF 61
 Done     - NTP WG Charter Approved
 Done     - Draft of Scope and Requirements Document
 Done     - Draft of NTP Protocol Specification
 Done     - Draft of MIB Specification
 Done     - Draft of NTP Algorithms Specification
 Done     - Draft of NTP Autokey Specification - Informational RFC
 Done     - WG Last Call NTP Protocol Specification
 Done     - WG Last Call NTP MIB Specification
 Done     - Draft of NTP Control Protocol - Informational RFC
 Done     - WG Last Call NTP Autokey Specification - Informational RFC
 Done     - WG Last Call NTP Control Protocol - Informational RFC
 Feb 2016 - WGLC for Network Time Security
 Feb 2016 - WGLC for Using the Network Time Security Specification to Secure the Network Time Protocol
 Feb 2016 - WGLC Protecting Network Time Security Messages with the Cryptographic Message Syntax (CMS)
 Apr 2016 - Publish UDP Checksum Complement in the Network Time Protocol (NTP)
 Apr 2016 - Publish The Network Time Protocol Version 4 (NTPv4) Extension Fields
 Apr 2016 -  WGLC Network Time Protocol Best Current Practices

Internet-Drafts:
 - On Implementing Time [draft-aanchal-time-implementation-guidance-00] (9 pages)
 - Message Authentication Codes for the Network Time Protocol  [draft-aanchal4-ntp-mac-03] (12 pages)
 - NTP Client Data Minimization [draft-dfranke-ntp-data-minimization-02] (5 pages)
 - Control Messages Protocol for Use with Network Time Protocol Version 4 [draft-haberman-ntpwg-mode-6-cmds-02] (15 pages)
 - Network Time Protocol Version 4: Autokey Specification [draft-ietf-ntp-autokey-08] (58 pages)
 - Network Time Protocol Best Current Practices [draft-ietf-ntp-bcp-06] (22 pages)
 - UDP Checksum Complement in the Network Time Protocol (NTP) [draft-ietf-ntp-checksum-trailer-07] (14 pages)
 - Protecting Network Time Security Messages with the Cryptographic Message Syntax (CMS) [draft-ietf-ntp-cms-for-nts-message-06] (19 pages)
 - NTP Client Data Minimization [draft-ietf-ntp-data-minimization-01] (6 pages)
 - Network Time Protocol (NTP) Server Option for DHCPv6 [draft-ietf-ntp-dhcpv6-ntp-opt-06] (9 pages)
 - Network Time Protocol Version 4 (NTPv4) Extension Fields [draft-ietf-ntp-extension-field-07] (8 pages)
 - Message Authentication Code for the Network Time Protocol [draft-ietf-ntp-mac-03] (4 pages)
 - Control Messages Protocol for Use with Network Time Protocol Version 4 [draft-ietf-ntp-mode-6-cmds-03] (21 pages)
 - Network Time Security [draft-ietf-ntp-network-time-security-15] (39 pages)
 - The Network Time Protocol Version 4 Algorithm Specification [draft-ietf-ntp-ntpv4-algorithms-01] (25 pages)
 - Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) [draft-ietf-ntp-ntpv4-mib-07] (26 pages)
 - Network Time Protocol Version 4: Protocol and Algorithms Specification [draft-ietf-ntp-ntpv4-proto-13] (110 pages)
 - Guidelines for Defining Packet Timestamps [draft-ietf-ntp-packet-timestamps-00] (14 pages)
 - Network Time Protocol REFID Updates [draft-ietf-ntp-refid-updates-02] (11 pages)
 - Requirements for Network Time Protocol Version 4 [draft-ietf-ntp-reqs-01] (16 pages)
 - Network Time Security for the Network Time Protocol [draft-ietf-ntp-using-nts-for-ntp-10] (27 pages)
 - A YANG Data Model for NTP [draft-ietf-ntp-yang-data-model-01] (43 pages)
 - The Network Time Protocol Version 4 (NTPv4) MAC Extension Field [draft-mayer-ntp-mac-extension-field-00] (6 pages)
 - Guidelines for Defining Packet Timestamps [draft-mizrahi-intarea-packet-timestamps-01] (14 pages)
 - Using UDP Checksum Trailers in the Network Time Protocol (NTP) [draft-mizrahi-ntp-checksum-trailer-02] (10 pages)
 - Using NTP Extension Fields without Authentication [draft-mizrahi-ntp-extension-field-03] (9 pages)
 - Network Time Protocol Best Current Practices [draft-reilly-ntp-bcp-02] (18 pages)
 - Network Time Protocol I-Do Extension Field [draft-stenn-ntp-i-do-03] (6 pages)
 - Network Time Protocol IPv6 REFID Hash [draft-stenn-ntp-ipv6-refid-hash-00] (4 pages)
 - Network Time Protocol Last Extension Field [draft-stenn-ntp-last-extension-00] (4 pages)
 - Network Time Protocol Leap Smear REFID [draft-stenn-ntp-leap-smear-refid-00] (5 pages)
 - Network Time Protocol Suggest REFID Extension Field [draft-stenn-ntp-suggest-refid-02] (6 pages)

Requests for Comments:
 RFC5905: Network Time Protocol Version 4: Protocol and Algorithms Specification (110 pages)
          * Obsoletes RFC1305
          * Obsoletes RFC4330
          * Updates RFC7822
 RFC5906: Network Time Protocol Version 4: Autokey Specification (58 pages)
 RFC5907: Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) (26 pages)
 RFC5908: Network Time Protocol (NTP) Server Option for DHCPv6 (9 pages)
 RFC7821: UDP Checksum Complement in the Network Time Protocol (NTP) (14 pages)
 RFC7822: Network Time Protocol Version 4 (NTPv4) Extension Fields (8 pages)
          * Updates RFC5905



Softwires (softwire)
--------------------

Charter
Last Modified: 2016-04-07

Current Status: Active

Chairs:
    Ian Farrer <[email protected]>
    Yong Cui <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Terry Manderson <[email protected]>

Tech Advisor:
    Xing Li <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/softwires
    Archive:            https://mailarchive.ietf.org/arch/browse/softwires

Description of Working Group:


     The Softwires Working Group is specifying the standardization of
     discovery, control and encapsulation methods for connecting IPv4
     networks across IPv6 networks and IPv6 networks across IPv4 networks
     in a way that will encourage multiple, inter-operable
     implementations.

     For various reasons, native IPv4 and/or IPv6 transport may not be
     available in all cases, and there is a need to tunnel IPv4 in IPv6
     or IPv6 in IPv4 to cross a part of the network which is not IPv4 or
     IPv6 capable. The Softwires Problem Statement, RFC 4925, identifies
     two distinct topological scenarios that the Working Group will
     provide solutions for: "Hubs and Spokes" and "Mesh." In the former
     case (Hubs and Spokes), hosts or "stub" networks are attached via
     individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4
     softwires to a centralized Softwire Concentrator. In the latter case
     (Mesh), network islands of one Address Family (IPv4 or IPv6) are
     connected over a network of another Address Family via point to
     multi-point softwires among Address Family Border Routers (AFBRs).

     The Softwires Working Group will reuse existing technologies as much
     as possible and only when necessary, create additional protocol
     building blocks.

     For generality, all base softwires encapsulation mechanisms should
     support all combinations of IP versions over one other (IPv4 over
     IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4/IPv6
     translation mechanisms, new addressing schemes, and block address
     assignments are out of scope. DHCP options developed in this working
     group will be reviewed jointly with the DHC Working Group.  RADIUS
     attributes developed in the Softwires Working Group will be reviewed
     jointly with the RADEXT Working Group.  The MIB Doctors directorate
     will be asked to review any MIB modules developed in the Softwires
     Working Group.  BGP and other routing and signaling protocols
     developed in this group will be reviewed jointly with the proper
     working groups and other workings that may take interest (e.g. IDR,
     L3VPN, PIM, LDP, SAAG, etc).

     The specific work areas for this working group are:

     1. Developments for Mesh softwires topology; the Mesh topology work
        will be reviewed in the L3VPN and IDR Working Groups
        - multicast
        - MIB module

     2. Developments for 6rd:
        - multicast
        - operational specification
        - RADIUS attribute for 6rd server
        - MIB module
        - Gateway-initiated 6rd (GI-6rd)

     3. Developments for Dual-Stack Lite (DS-Lite):
        - multicast
        - operational specification
        - RADIUS attribute for AFTR
        - proxy extensions; GI-DS-Lite; No NAT on AFTR
        - MIB module

     4. Developments for stateless legacy IPv4 carried over IPv6
        - develop a solution motivation document to be published as an
          RFC
        - develop a protocol specification response to the solution
          motivation document; this work item will not be taken through
          Working Group last call until the solution motivation document
          has been published or approved for publication

     5. Finalize discovery and configuration mechanisms for a gateway to
        use DS-Lite or 6rd; these discovery and configuration mechanisms
        must take into a account other operating environments such as
        dual-stack and tunneling mechanisms not defined by the Softwires
        Working Group.  Development of new mechanisms will involve the
        DHC and/or V6OPS Working Groups as appropriate

   Other work items would require Working Group approval and rechartering.




Goals and Milestones:
 Done     - Submit a problem statement to the IESG to be considered as an Informational RFC
 Done     - Submit DS-lite RADIUS attribute document for Proposed Standard
 Done     - Adopt DS-lite operational document as a Working Group document
 Done     - Submit 6rd RADIUS attribute document for Proposed Standard
 Done     - Submit GI DS-lite document for Proposed Standard
 Done     - Adopt DS-Lite without NAT document as a Working Group document
 Moved to dhc working group     - Adopt DHCPv4 over tunnel document as a Working Group document
 Done     - Adopt Multicast extensions document as a Working Group document
 Done     - Submit DS-lite operational document for Informational
 Done     - Adopt stateless legacy IPv4 solution motivation document as a Working Group document
 Done     - Submit DS-Lite without NAT document for Informational
 Moved to dhc working group     - Submit DHCPv4 over tunnel document for Proposed Standard
 Nov 2011 - Submit Multicast extensions document for Informational
 Done     - Adopt DS-lite MIB module document as a Working Group document
 Done     - Adopt Mesh topology MIB module document as a Working Group document
 Done     - Submit stateless legacy IPv4 solution motivation document for Informational
 Done     - Adopt stateless legacy IPv4 specification document as a Working Group document
 Done     - Submit stateless legacy IPv4 specification document for Proposed Standard
 Done     - Submit DS-lite MIB module document for Proposed Standard
 Done     - Submit Mesh topology MIB module document for Proposed Standard

Internet-Drafts:
 - Unified IPv4-in-IPv6 Softwire CPE [draft-bfmk-softwire-unified-cpe-02] (13 pages)
 - YANG Data Model for the DS-Lite Address Family Transition Router (AFTR) [draft-boucadair-softwire-dslite-yang-04] (30 pages)
 - Definitions of Managed Objects for 6rd [draft-cai-softwire-6rd-mib-05] (10 pages)
 - Lightweight 4over6: An Extension to the DS-Lite Architecture [draft-cui-softwire-b4-translated-ds-lite-11] (19 pages)
 - Definitions of Managed Objects for MAP-E [draft-fu-softwire-map-mib-05] (13 pages)
 - IPv4 unicast/multicast VPNs over an IPv6 core [draft-ietf-softwire-4over6vpns-00] (7 pages)
 - IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd) [draft-ietf-softwire-4rd-10] (45 pages)
 - RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [draft-ietf-softwire-6rd-radius-attrib-11] (12 pages)
 - BGP Traffic Engineering Attribute [draft-ietf-softwire-bgp-te-attribute-04] (6 pages)
 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite [draft-ietf-softwire-ds-lite-tunnel-option-10] (7 pages)
 - Deployment Considerations for Dual-Stack Lite [draft-ietf-softwire-dslite-deployment-08] (14 pages)
 - Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs) [draft-ietf-softwire-dslite-mib-15] (27 pages)
 - Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network [draft-ietf-softwire-dslite-multicast-18] (23 pages)
 - RADIUS Extensions for Dual-Stack Lite [draft-ietf-softwire-dslite-radius-ext-07] (11 pages)
 - A YANG Data Module for Dual-Stack Lite (DS-Lite) [draft-ietf-softwire-dslite-yang-14] (20 pages)
 - Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [draft-ietf-softwire-dual-stack-lite-11] (32 pages)
 - BGP IPsec Tunnel Encapsulation Attribute [draft-ietf-softwire-encaps-ipsec-03] (8 pages)
 - The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute [draft-ietf-softwire-encaps-safi-05] (13 pages)
 - Gateway-Initiated Dual-Stack Lite Deployment [draft-ietf-softwire-gateway-init-ds-lite-08] (15 pages)
 - Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) [draft-ietf-softwire-hs-framework-l2tpv2-13] (41 pages)
 - IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification [draft-ietf-softwire-ipv6-6rd-10] (18 pages)
 - Load-Balancing for Mesh Softwires [draft-ietf-softwire-lb-03] (6 pages)
 - Deployment Considerations for Lightweight 4over6 [draft-ietf-softwire-lightweight-4over6-deployment-01] (23 pages)
 - Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture [draft-ietf-softwire-lw4over6-13] (22 pages)
 - Mapping of Address and Port with Encapsulation (MAP-E) [draft-ietf-softwire-map-13] (35 pages)
 - Mapping of Address and Port (MAP) - Deployment Considerations [draft-ietf-softwire-map-deployment-06] (29 pages)
 - DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients [draft-ietf-softwire-map-dhcp-12] (18 pages)
 - Definitions of Managed Objects for MAP-E [draft-ietf-softwire-map-mib-12] (16 pages)
 - RADIUS Attribute for Softwire Address plus Port based Mechanisms [draft-ietf-softwire-map-radius-14] (32 pages)
 - Mapping of Address and Port using Translation (MAP-T) [draft-ietf-softwire-map-t-08] (27 pages)
 - Softwire Mesh Framework [draft-ietf-softwire-mesh-framework-06] (31 pages)
 - Softwire Mesh Management Information Base (MIB) [draft-ietf-softwire-mesh-mib-14] (18 pages)
 - IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Network [draft-ietf-softwire-mesh-multicast-19] (19 pages)
 - DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes [draft-ietf-softwire-multicast-prefix-option-15] (9 pages)
 - Softwire Problem Statement [draft-ietf-softwire-problem-statement-03] (23 pages)
 - Public IPv4-over-IPv6 Access Network [draft-ietf-softwire-public-4over6-10] (13 pages)
 - Softwire Security Analysis and Requirements [draft-ietf-softwire-security-requirements-09] (28 pages)
 - Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions [draft-ietf-softwire-stateless-4v6-motivation-05] (15 pages)
 - Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism [draft-ietf-softwire-unified-cpe-08] (11 pages)
 - Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop [draft-ietf-softwire-v4nlri-v6nh-02] (10 pages)
 - YANG Modules for IPv4-in-IPv6 Address plus Port Softwires [draft-ietf-softwire-yang-03] (41 pages)
 - RADIUS Attribute for MAP [draft-jiang-softwire-map-radius-04] (14 pages)
 - Dynamic IPv4 Provisioning for Lightweight 4over6 [draft-liu-softwire-lw4over6-dynamic-provisioning-02] (9 pages)
 - A YANG Data Model for IPv4-in-IPv6 Softwires [draft-sun-softwire-yang-05] (31 pages)

Requests for Comments:
 RFC4925: Softwire Problem Statement (23 pages)
 RFC5512: The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute (13 pages)
 RFC5543: BGP Traffic Engineering Attribute (6 pages)
          * Updates RFC7606
 RFC5549: Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop (10 pages)
 RFC5565: Softwire Mesh Framework (31 pages)
 RFC5566: BGP IPsec Tunnel Encapsulation Attribute (8 pages)
 RFC5571: Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) (41 pages)
 RFC5619: Softwire Security Analysis and Requirements (28 pages)
 RFC5640: Load-Balancing for Mesh Softwires (6 pages)
 RFC5969: IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification (18 pages)
 RFC6333: Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (32 pages)
          * Updates RFC7335
 RFC6334: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite (7 pages)
 RFC6519: RADIUS Extensions for Dual-Stack Lite (11 pages)
 RFC6674: Gateway-Initiated Dual-Stack Lite Deployment (15 pages)
 RFC6908: Deployment Considerations for Dual-Stack Lite (14 pages)
 RFC6930: RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) (12 pages)
 RFC7040: Public IPv4-over-IPv6 Access Network (13 pages)
 RFC7596: Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture (22 pages)
 RFC7597: Mapping of Address and Port with Encapsulation (MAP-E) (35 pages)
 RFC7598: DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients (18 pages)
 RFC7599: Mapping of Address and Port using Translation (MAP-T) (27 pages)
 RFC7600: IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd) (45 pages)
 RFC7856: Softwire Mesh Management Information Base (MIB) (18 pages)
 RFC7870: Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs) (27 pages)
 RFC8026: Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism (11 pages)
 RFC8114: Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network (23 pages)
 RFC8115: DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes (9 pages)



Source Address Validation Improvements (savi)
---------------------------------------------

Charter
Last Modified: 2016-04-06

Current Status: Active

Chair:
    Jean-Michel Combes <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Tech Advisor:
    Jianping Wu <[email protected]>

Secretary:
    Jun Bi <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/savi
    Archive:            https://mailarchive.ietf.org/arch/browse/savi/

Description of Working Group:


   While ingress filtering [RFC 2827, BCP 38] provides a way to validate
   IP source addresses at an aggregated level, there is not yet a
   standardized mechanism for IP source address validation at a finer
   granularity. Having a finer granularity would be helpful in a number
   of situations, including filtering traffic from customer interfaces
   implemented as ports in a layer 3 aware bridge or a router, general
   improvements in filtering accuracy in enterprise networks, etc.
   Depending on the situation, there may be a requirement for blocking
   spoofed packets or merely logging packets that appear to be spoofed.

   Partial solutions exist to prevent nodes from spoofing the IP source
   address of another node in the same IP link (e.g., the "IP source
   guard"), but are proprietary. The purpose of the proposed "Source
   Address Validation Improvements" working group is to standardize
   mechanisms that prevent nodes attached to the same IP link from
   spoofing each other's IP addresses.

   The scope of the WG is as follows:

   - The working group considers only solutions implemented on systems
   located on the same IP link as a to-be-verified node. The goal of the
   working group is the LAN environment and solutions running in routers or
   layer 3 aware Ethernet bridges.

   - Both IPv4 and IPv6 need to be covered.

   - The first goal of the working group is on unicast traffic, but
   using the same mechanisms to police multicast traffic is also
   within the scope.

   - All address assignment mechanisms need to be supported, including
   stateless, stateful, and manual configuration; as well as privacy and
   cryptographically generated addresses.

   - Solutions are preferably based on observing user traffic, or on
   observing or using existing signaling protocols. Examples of
   protocols that can be useful to observe/use are ARP, Neighbor
   Discovery, DHCP, and DHCP Prefix Delegation protocols. Observing
   addresses in IP headers can also be useful. The gathered
   information is used to determine what IP source addresses in
   packets are appropriate. Where automatic operation is impossible
   or would lead to sub-optimal validation results, solutions may
   require manual configuration.

   - Interdomain scenarios (across Autonomous Systems) that require
   information from routing protocols like BGP are out of scope.
   Nevertheless, solution may observe routing protocol signaling
   to detect that a device is a router.

   - Tracking other protocols is not within the scope of the WG.

   - No changes to hosts are allowed.

   - The WG is prohibited from creating its own protocols
   or extensions/modifications of current protocols.

   These limitations in the scope may be relaxed through later
   rechartering. For instance, solutions tailored for PPP links
   and specific environments may be added later, or solutions
   involving co-operation of the nodes on the link may be
   developed once the baseline solutions have been completed.
   However, the WG is already chartered to work also on a
   solution for Ethernet-based broadband access networks that
   are used in DSL environments. This work is a specialization
   of the working group's primary LAN-based solution.

   In order to reach a result that is widely usable and unlikely to
   disturb existing network practices, the working group needs to
   take into account

   - nodes that use static addresses,
   - nodes with multiple IP addresses on the same interface,
   - nodes that use multiple link-layer addresses on the same interface,
   - nodes that have multiple interfaces to the same link,
   - attachment of another bridge at a bridge port,
   - presence of routers, NATs, and other similar devices on the same link,
   including their distinction from hosts with multiple interfaces or
   hosts with multiple IP addresses on a single interface,
   - use of SEcure Neighbor Discovery in some networks,
   - nodes that move to another port on the same link, and
   - hosts with anycast addresses.

   However, should such wide applicability turn out to be impossible,
   the working group will document the limitations of the solutions
   in due manner. In particular, it is likely that anycast addressing
   and nodes that employ multiple interfaces for load balancing at
   link layer are indistinguishable from an actual spoofing attack.
   There may also be a difference in the applicability between blocking
   and merely logging spoofed packets. In any case, the solutions
   may require to be explicitly turned on for each network or interface
   where they are applicable.

   For background information, the working group will also develop a
   threats analysis document that describes what threats the solutions
   from the WG protect against. This document also contrasts SAVI
   to existing solutions.




Goals and Milestones:
 Jul 2008 - WG approval
 Aug 2008 - First WG draft on threats document
 Oct 2008 - First WG draft on SLAAC solution
 Dec 2008 - First WG draft on SeND solution
 Dec 2009 - First WG draft on DHCP solution
 Dec 2009 - First WG draft on protocol framework
 Mar 2010 - Submit document on threats to IESG for Informational RFC
 Mar 2010 - First WG draft on solution for Ethernet-based broadband access networks
 Dec 2010 - Submit Ethernet-based broadband access network solution to IESG for Proposed Standard
 Dec 2010 - Submit protocol framework to IESG for Informational RFC
 Dec 2010 - Submit SLAAC solution to IESG for Proposed Standard
 Dec 2010 - Submit SeND solution to IESG for Proposed Standard
 Dec 2010 - Submit DHCP solution to IESG for Proposed Standard
 Apr 2011 - First WG draft on mix scenario solution
 Jul 2011 - Submit mix scenario solution to IESG for Proposed Standard

Internet-Drafts:
 - Source Address Validation Improvement (SAVI) Solution for DHCP [draft-ietf-savi-dhcp-34] (54 pages)
 - FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses [draft-ietf-savi-fcfs-14] (35 pages)
 - Source Address Validation Improvement (SAVI) Framework [draft-ietf-savi-framework-06] (14 pages)
 - Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario [draft-ietf-savi-mix-15] (12 pages)
 - A Solution Space Analysis for First-Hop IP Source Address Validation [draft-ietf-savi-rationale-00] (6 pages)
 - SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) [draft-ietf-savi-send-11] (38 pages)
 - Source Address Validation Improvement (SAVI) Threat Scope [draft-ietf-savi-threat-scope-08] (25 pages)

Requests for Comments:
 RFC6620: FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses (35 pages)
 RFC6959: Source Address Validation Improvement (SAVI) Threat Scope (25 pages)
 RFC7039: Source Address Validation Improvement (SAVI) Framework (14 pages)
 RFC7219: SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) (38 pages)
 RFC7513: Source Address Validation Improvement (SAVI) Solution for DHCP (54 pages)
 RFC8074: Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario (12 pages)



Sunsetting IPv4 (sunset4)
-------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Marc Blanchet <[email protected]>
    Wesley George <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Terry Manderson <[email protected]>

Tech Advisors:
    Fred Baker <[email protected]>
    Martin Stiemerling <[email protected]>
    Stewart Bryant <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/sunset4
    Archive:            https://mailarchive.ietf.org/arch/browse/sunset4/

Description of Working Group:

   Global IPv4 addresses, once considered plentiful, are an
   increasingly scarce resource for many who wish to connect to the
   Internet today. IPv6 provides an abundance of freely available
   addresses, and while deployment alongside IPv4 has begun in
   earnest, much work remains.

   In order to fully transition the Internet to IPv6, individual
   applications, hosts, and networks that have enabled IPv6 must also
   be able to operate fully in the absence of IPv4. The Working Group
   will point out specific areas of concern, provide recommendations,
   and standardize protocols that facilitate the graceful "sunsetting"
   of the IPv4 Internet in areas where IPv6 has been deployed. This
   includes the act of shutting down IPv4 itself, as well as the
   ability of IPv6-only portions of the Internet to continue to
   connect with portions of the Internet that remain IPv4-only.

   While this work obviously spans multiple IETF areas including
   Internet, Operations, Transport, Applications, and Routing, this
   working group provides a single venue for the consideration of IPv4
   sunsetting. Work in this group shall never impede the deployment of
   IPv6, will not duplicate functions and capabilities already
   available in existing technologies, and should demonstrate
   widespread operational need. Cross-area coordination and support
   is essential.

   Disabling IPv4 in applications, hosts, and networks is new
   territory for much of the Internet today, and it is expected that
   problems will be uncovered including those related to basic IPv4
   functionality, interoperability, as well as potential security
   concerns. The working group will report on common issues, provide
   recommendations, and, when necessary, protocol extensions in order
   to facilitate disabling IPv4 in networks where IPv6 has been
   deployed.

   Operational scenarios considered by the working group shall include
   IPv6-only nodes and networks as the goal. Work on technologies that
   involve increased sharing of global IPv4 addresses should be
   limited to what is necessary for communicating with endpoints or
   over networks that are IPv6-only.

   The initial work items are:

   * NAT64 port allocation and address sharing methods involving
     scenarios where an IPv6-only node is present (and NAT44, as it
     overlaps NAT64 address sharing and port use). This may require a
     description of the use of an existing protocol, the development
     of extensions to an existing protocol, or the definition of an
     entirely new protocol.

   * Gap analysis of IPv4/IPv6 features to facilitate IPv4 sunsetting

   * Provisioning methods to signal a dual-stack host to disable or
     depreference the use of IPv4

Goals and Milestones:
 Dec 2015 - Submit gap analysis on IPv4 sunsetting to IESG for consideration as an Informational RFC
 Dec 2015 - Submit NAT64 port allocation and address sharing methods to IESG for consideration as an Informational RFC
 Apr 2016 - Submit provisioning methods to signal a dual-stack host to disable the use of IPv4 to IESG for consideration as Proposed Standard
 Jul 2017 - IPv6 Support Within IETF work

Internet-Drafts:
 - Gap Analysis for IPv4 Sunset [draft-ietf-sunset4-gapanalysis-09] (11 pages)
 - IETF: End Work on IPv4 [draft-ietf-sunset4-ipv6-ietf-01] (3 pages)
 - Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses [draft-ietf-sunset4-nat64-port-allocation-02] (18 pages)
 - Turning off IPv4 Using DHCPv6 or Router Advertisements [draft-ietf-sunset4-noipv4-01] (14 pages)

No Requests for Comments

Timing over IP Connection and Transfer of Clock (tictoc)
--------------------------------------------------------

Charter
Last Modified: 2016-04-06

Current Status: Active

Chairs:
    Karen O'Donoghue <[email protected]>
    Yaakov Stein <[email protected]>

Internet Area Directors:
    Suresh Krishnan <[email protected]>
    Terry Manderson <[email protected]>

Internet Area Advisor:
    Suresh Krishnan <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/tictoc
    Archive:            https://mailarchive.ietf.org/arch/browse/tictoc/

Description of Working Group:


   The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is
   concerned with highly accurate time and frequency distribution over
   native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While
   this need arises from a variety of sources (see
   draft-bryant-tictoc-probstat-01.txt), the application areas of focus for
   this WG are:

   (1) Network infrastructures with the need for highly accurate time and
   frequency distribution within well-engineered service provider or
   enterprise campus networks. On-path support with specialized hardware
   may be expected to be available at one or more hops on a given path.

   (2) Individual hosts and devices on the public Internet requiring
   functionality or performance not currently available in NTP. On-path
   support may be utilized if available, but is not expected. This
   application brings additional requirements beyond improved accuracy, for
   example, the traceable and authenticated distribution of UTC time,
   including correct handling of leap seconds.

   The NTP Working Group is currently standardizing the fourth version of
   NTP for time distribution over IP networks. The NTP WG has focused its
   deliverables largely on standardizing the currently deployed NTPv4,
   while collecting requirements for future extensions. These requirements
   will transition to the tictoc WG for further development. Meeting those
   requirements may include revision of the protocol to a new version
   level. However, in all cases backwards compatibility and coexistence
   with currently deployed NTPv4 is a paramount concern. An applicability
   statement will describe the use cases for which any extension of NTP is
   targeted.

   The IEEE Test and Measurement Society is in the closing stages of
   standardizing a second version of IEEE1588. This is unofficially known
   as IEEE1588v2 and is expected to be published as IEEE1588-2008.
   IEEE1588v2 is emerging as a viable solution for time transfer over
   service provider and campus Ethernet networks, and for which on-path
   hardware support is becoming available. IEEE1588v2 specifically
   encourages other standards organizations to adapt it to their
   requirements, and provides guidelines for doing so. TICTOC will
   determine whether a profile for IEEE1588v2 over IP or MPLS-enabled IP
   networks would be suitable for (1), and if so will produce a profile
   within the guidelines provided in the IEEE1588v2 specification. An
   applicability statement will describe the use cases for which any
   profile of IEEE1588v2 is targeted.

   Time and Frequency distribution is considered by many to be a complex
   and often esoteric subject area. The WG will develop a modular framework
   in order to map out components within the solution space, define
   terminology, and identify common areas of protocol work that can be
   capitalized upon.

   TICTOC will also consider the co-existence of IEEE1588v2 and NTP in the
   same network. In doing so, TICTOC will first verify that the data model
   of NTP can be accommodated by IEEE1588v2 protocol operation and document
   any deficiencies compared to NTP. If there is a need to map the data
   models, it will produce a specification for how to utilize IEEE 1588 in
   a localized region as one portion of an NTP-based system.

   TICTOC protocols will be applicable to a variety of link layer
   technologies. To get the highest quality time and frequency transfer the
   user should take advantage of two types of on-path service where they
   are available: Link based frequency transfer, and hop-by-hop delay
   correction (for time).  Examples of link based frequency support are
   SONET/SDH, TDM, Synchronous Ethernet and DSL with timing reference
   support. The main types of support that can be provided by a network
   element are boundary clock (where the clock is regenerated at the node
   in a multistage master slave relationship) and transparent clock where
   corrections are applied to time transfer packets as they pass through to
   compensate for the queuing delay, and where known for asymmetry in the
   link delay.  Transparent clock  (queue delay correction) requires
   routers to identify a time transfer packet, record the queuing delay,
   and either apply an on the fly correction to the packet, or to generate
   a follow-up packet with the necessary time correction information.
   TICTOC will ensure that any transparent clock design is acceptable in an
   Internet environment. On-path support is not a given, and TICTOC will
   investigate methods for automatically discovering when this support is
   available and when it is not.

   TICTOC will transfer time and frequency over both IP and IP enabled MPLS
   PSNs.  One of the major users of TICTOC technology is the service
   provider community, where MPLS enabled IP networks are common. If
   necessary, TICTOC may take advantage of the path control properties of
   MPLS and the ability to signal modifications to per packet forwarding
   behavior.

   The security of time transfer, including the authentication of the time
   reference is an important consideration and must be designed in from the
   beginning.

   The ultimate system-level accuracy of time and frequency transfer
   depends on a number of factors outside the scope of the protocols
   themselves. Thus, even if it is possible for TICTOC to make a number of
   improvements at the protocol level to facilitate more accurate time and
   frequency transfer, it is impossible for the WG to provide system-level
   accuracy guarantees on its own.

   The TICTOC WG will co-ordinate with the PWE3 and NTP WGs in the IETF, as
   well as IEEE1588, IEEE 802.1AS and ITU-T SG15 Q13. It is also expected
   that active individuals in the TICTOC WG will propose the formation of
   an IRTF RG to study more advanced aspects of time and frequency
   distribution.


   First phase Objectives:

   - To develop a time and frequency distribution requirements document for
   the two cases listed above, including coexistence of the two as appropriate.

   - To develop a document defining the modular breakdown of functionality
   within the solution space.

   - To determine the extent to which these requirements can be satisfied
   using IEEE1588v2 and NTPv4 within each use case, along with an
   associated gap analysis for what requirements are not met without
   adaptation or extension of these protocols.

   - To develop an IEEE1588v2 profile as necessary for time and frequency
   distribution, with primary focus on (1). This profile will include a MIB
   module for IEEE1588v2.

   - To develop extensions to NTPv4 as necessary for time and frequency
   distribution, with primary focus on (2).

   - If required, to develop mechanisms for coexistence of IEEE1588v2 and NTP.

   - To document threat analyses and security mechanisms for all protocols
   developed by the WG.

   - To document media mappings for link layer technologies of interest.

   Second phase Objectives (requiring re-charter of the WG):

   To propose and document algorithms, protocols and mechanisms for
   transport, frequency acquisition, ranging, and packet selection/discard,
   master clock selection, path selection, OAM, synchronization status
   messaging, performance monitoring, security, and network management.




Goals and Milestones:
 Done     - Security document(s) document exits WGLC
 Mar 2016 - 1588v2 profile, if needed, document exits WGLC
 Apr 2016 - MIB for IEEE 1588v2 profile and NTPv4 extensions (TICTOC MIB) document exits WGLC
 May 2016 - Prioritize second phase deliverables and add milestones or re-charter document exits WGLC
 Jun 2016 - IEEE 1588v2 YANG Model exits WGLC
 Jun 2016 - Publish Experimental RFC on multi-path time synchronization
 Jul 2016 - Publish Experimental RFC on transporting time over MPLS

Internet-Drafts:
 - TICTOC Problem Statement [draft-bryant-tictoc-probstat-02] (16 pages)
 - Problem Statements of Scalable Synchronization Networks [draft-hjxl-ssn-ps-00] (9 pages)
 - Transporting Timing messages over MPLS Networks [draft-ietf-tictoc-1588overmpls-07] (19 pages)
 - YANG Data Model for IEEE 1588-2008 [draft-ietf-tictoc-1588v2-yang-07] (29 pages)
 - Multipath Time Synchronization [draft-ietf-tictoc-multi-path-synchronization-07] (17 pages)
 - Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast Messages [draft-ietf-tictoc-ptp-enterprise-profile-09] (12 pages)
 - Precision Time Protocol Version 2 (PTPv2) Management Information Base [draft-ietf-tictoc-ptp-mib-12] (64 pages)
 - TICTOC Requirement [draft-ietf-tictoc-requirements-01] (32 pages)
 - Security Requirements of Time Protocols in Packet Switched Networks [draft-ietf-tictoc-security-requirements-12] (36 pages)
 - YANG Data Model for IEEE 1588v2 [draft-jlx-tictoc-1588v2-yang-04] (22 pages)
 - Multi-Path Time Synchronization [draft-shpiner-multi-path-synchronization-03] (16 pages)
 - Architecture for the Transmission of Timing over Packet Networks [draft-stein-tictoc-modules-03] (22 pages)

Requests for Comments:
 RFC7384: Security Requirements of Time Protocols in Packet Switched Networks (36 pages)
 RFC8039: Multipath Time Synchronization (17 pages)
 RFC8173: Precision Time Protocol Version 2 (PTPv2) Management Information Base (64 pages)



Autonomic Networking Integrated Model and Approach (anima)
----------------------------------------------------------

Charter
Last Modified: 2017-11-27

Current Status: Active

Chairs:
    Sheng Jiang <[email protected]>
    Toerless Eckert <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Benoit Claise <[email protected]>

Tech Advisor:
    Nancy Cam-Winget <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Benchmarking Methodology (bmwg)
-------------------------------

Charter
Last Modified: 2017-10-03

Current Status: Active

Chairs:
    Al Morton <[email protected]>
    Sarah Banks <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Warren Kumari <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Diameter Maintenance and Extensions (dime)
------------------------------------------

Charter
Last Modified: 2017-03-31

Current Status: Active

Chairs:
    Jouni Korhonen <[email protected]>
    Lionel Morand <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Ben Campbell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Domain Name System Operations (dnsop)
-------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Suzanne Woolf <[email protected]>
    Tim Wicinski <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Warren Kumari <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Global Routing Operations (grow)
--------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Christopher Morrow <[email protected]>
    Peter Schoenmaker <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Warren Kumari <[email protected]>

Tech Advisors:
    Bill Fenner <[email protected]>
    Vijay Gill <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



IPv6 Operations (v6ops)
-----------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Fred Baker <[email protected]>
    Lee Howard <[email protected]>
    Ron Bonica <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Warren Kumari <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/v6ops
    Archive:            https://mailarchive.ietf.org/arch/browse/v6ops/

Description of Working Group:

 The global deployment of IPv6 is underway, creating an Internet
 consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and
 IPv6+translation networks and nodes. This deployment must be properly
 handled to avoid the division of the Internet into separate IPv4 and
 IPv6 networks, ensuring addressing and connectivity for all IPv4 and
 IPv6 nodes.  IPv6 deployment has resulted in the shutdown of IPv4 in
 some networks. Removing IPv4 constraints has resulted in innovations
 in IPv6 network operations.

 The IPv6 Operations Working Group (v6ops) develops guidelines for the
 deployment and operation of new and existing IPv6 networks.

 The goals of the v6ops working group are:

 1. Solicit input from network operators and users to identify
 operational issues with IPv6 networks, and determine solutions or
 workarounds to those issues.

 2. Solicit input from network operators and users to identify
 operational interaction issues with the IPv4 networks, and determine
 solutions or workarounds to those issues.

 3. Solicit discussion and documentation of the issues and opportunities
 in IPv6-only operation, and of the resulting innovations.

 4. Operational solutions for identified issues should be developed in
 v6ops and documented in informational or BCP drafts.

 5. Document operational requirements for IPv6 networks.

 These documents should document IPv6 operational experience, including
 interactions with IPv4, in dual stack networks, IPv6 networks with IPv4
 delivered as an overlay or translation service, or IPv6-only networks.

 IPv6 operational and deployment issues with specific protocols or
 technologies (such as Applications, Transport Protocols, Routing
 Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
 the groups or areas responsible for those protocols or
 technologies. However, the v6ops Working Group may provide input to
 those areas/groups, as needed, and cooperate with those areas/groups in
 reviewing solutions to IPv6 operational and deployment problems.

 Future work items within this scope will be adopted by the Working Group
 only if there is a substantial expression of interest from the community
 and if the work clearly does not fit elsewhere in the IETF.

 There must be a continuous expression of interest for the Working Group
 to work on a particular work item. If there is no longer sufficient
 interest in the Working Group in a work item, the item may be removed
 from the list of Working Group items.


Goals and Milestones:
 Jul 2017 - Describe routing choices and trade-offs for enterprise and service provider networks
 Jul 2017 - File recommendation on how to build a commercial WiFi network
 Nov 2017 - Prefix for use by IPv4/IPv6 translators in a network
 Nov 2017 - Advice on use of ULAs in networks
 Nov 2017 - Update RFC 7084 (IPv6 CE Requirements)
 Nov 2017 - Update RFC 6555 with experience
 Nov 2017 - Requirements for IPv6 Routers in a general purpose network

Internet-Drafts:
 - SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments [draft-anderson-v6ops-siit-dc-01] (30 pages)
 - SIIT-DC: Dual Translation Mode [draft-anderson-v6ops-siit-dc-2xlat-00] (8 pages)
 - IPv6 Address Assignment to End Sites [draft-ietf-v6ops-3177bis-end-sites-01] (9 pages)
 - Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks [draft-ietf-v6ops-3gpp-analysis-11] (24 pages)
 - Transition Scenarios for 3GPP Networks [draft-ietf-v6ops-3gpp-cases-03] (12 pages)
 - IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) [draft-ietf-v6ops-3gpp-eps-08] (36 pages)
 - 464XLAT: Combination of Stateful and Stateless Translation [draft-ietf-v6ops-464xlat-10] (14 pages)
 - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-6204bis-12] (21 pages)
 - Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link [draft-ietf-v6ops-64share-10] (10 pages)
 - Advisory Guidelines for 6to4 Deployment [draft-ietf-v6ops-6to4-advisory-02] (20 pages)
 - Security Considerations for 6to4 [draft-ietf-v6ops-6to4-security-04] (41 pages)
 - Deprecating the Anycast Prefix for 6to4 Relay Routers [draft-ietf-v6ops-6to4-to-historic-11] (10 pages)
 - IPv6 Deployment Scenarios in 802.16 Networks [draft-ietf-v6ops-802-16-deployment-scenarios-07] (16 pages)
 - IPv6 Unicast Address Assignment Considerations [draft-ietf-v6ops-addcon-10] (35 pages)
 - Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules [draft-ietf-v6ops-addr-select-ps-09] (17 pages)
 - Requirements for Address Selection Mechanisms [draft-ietf-v6ops-addr-select-req-07] (7 pages)
 - Application Aspects of IPv6 Transition [draft-ietf-v6ops-application-transition-03] (33 pages)
 - Goals for Registered Assisted Tunneling [draft-ietf-v6ops-assisted-tunneling-requirements-01] (14 pages)
 - Balanced Security for IPv6 Residential CPE [draft-ietf-v6ops-balanced-ipv6-security-01] (9 pages)
 - ISP IPv6 Deployment Scenarios in Broadband Access Networks [draft-ietf-v6ops-bb-deployment-scenarios-05] (81 pages)
 - IPv6 Campus Transition Scenario Description and Analysis [draft-ietf-v6ops-campus-transition-01] (28 pages)
 - IPv6 Prefix Length Recommendation for Forwarding [draft-ietf-v6ops-cidr-prefix-03] (6 pages)
 - IPv4 Service Continuity Prefix [draft-ietf-v6ops-clatip-04] (4 pages)
 - Using Conditional Router Advertisements for Enterprise Multihoming [draft-ietf-v6ops-conditional-ras-00] (17 pages)
 - Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service [draft-ietf-v6ops-cpe-simple-security-16] (36 pages)
 - IPv6 Operational Guidelines for Datacenters [draft-ietf-v6ops-dc-ipv6-01] (22 pages)
 - Routing-Related Design Choices for IPv6 Networks [draft-ietf-v6ops-design-choices-12] (26 pages)
 - DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration [draft-ietf-v6ops-dhcpv6-slaac-problem-07] (23 pages)
 - IPv6 Enterprise Network Analysis - IP Layer 3 Focus [draft-ietf-v6ops-ent-analysis-07] (32 pages)
 - IPv6 Enterprise Network Scenarios [draft-ietf-v6ops-ent-scenarios-05] (17 pages)
 - Enterprise IPv6 Deployment Guidelines [draft-ietf-v6ops-enterprise-incremental-ipv6-06] (34 pages)
 - IPv6 Enterprise Networks Scenarios [draft-ietf-v6ops-entnet-scenarios-00] (17 pages)
 - Happy Eyeballs: Success with Dual-Stack Hosts [draft-ietf-v6ops-happy-eyeballs-07] (15 pages)
 - Host Address Availability Recommendations [draft-ietf-v6ops-host-addr-availability-07] (15 pages)
 - Best Current Practice for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-bcp-01] (34 pages)
 - Recommendations for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-recs-03] (38 pages)
 - IPv6 Guidance for Internet Content Providers and Application Service Providers [draft-ietf-v6ops-icp-guidance-05] (24 pages)
 - An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition [draft-ietf-v6ops-incremental-cgn-03] (13 pages)
 - Using IPsec to Secure IPv6-in-IPv4 Tunnels [draft-ietf-v6ops-ipsec-tunnels-05] (23 pages)
 - Survey of IPv4 Addresses in Currently Deployed IETF Standards [draft-ietf-v6ops-ipv4survey-00] (0 pages)
 - Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-apps-04] (50 pages)
 - Survey of IPv4 Addresses in Currently Deployed IETF General Area Standards [draft-ietf-v6ops-ipv4survey-gen-00] (0 pages)
 - Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-int-03] (49 pages)
 - Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-intro-06] (10 pages)
 - Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-ops-05] (43 pages)
 - Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-routing-03] (15 pages)
 - Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-sec-04] (25 pages)
 - Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-subip-04] (6 pages)
 - Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-trans-05] (31 pages)
 - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-09] (17 pages)
 - Advanced Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-bis-01] (15 pages)
 - A Discard Prefix for IPv6 [draft-ietf-v6ops-ipv6-discard-prefix-05] (6 pages)
 - Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [draft-ietf-v6ops-ipv6-ehs-in-real-world-02] (15 pages)
 - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06] (22 pages)
 - Analysis of Failure Cases in IPv6 Roaming Scenarios [draft-ietf-v6ops-ipv6-roaming-analysis-07] (19 pages)
 - Requirements for IPv6 Routers [draft-ietf-v6ops-ipv6rtr-reqs-01] (30 pages)
 - Emerging Service Provider Scenarios for IPv6 Deployment [draft-ietf-v6ops-isp-scenarios-00] (23 pages)
 - Scenarios and Analysis for Introducing IPv6 into ISP Networks [draft-ietf-v6ops-isp-scenarios-analysis-03] (28 pages)
 - Stateless Source Address Mapping for ICMPv6 Packets [draft-ietf-v6ops-ivi-icmp-address-07] (6 pages)
 - Basic Transition Mechanisms for IPv6 Hosts and Routers [draft-ietf-v6ops-mech-v2-07] (27 pages)
 - Monitoring Dual Stack/IPv6-only Networks and Services [draft-ietf-v6ops-monitor-ds-ipv6-00] (10 pages)
 - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-multihoming-without-nat66-00] (19 pages)
 - Local Network Protection for IPv6 [draft-ietf-v6ops-nap-06] (36 pages)
 - NAT64 Deployment Options and Experience [draft-ietf-v6ops-nat64-experience-10] (22 pages)
 - IPv4/IPv6 Coexistence and Transition: Requirements for solutions [draft-ietf-v6ops-nat64-pb-statement-req-00] (17 pages)
 - Reasons to Move NAT-PT to Experimental [draft-ietf-v6ops-natpt-to-exprmntl-03] (25 pages)
 - Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status [draft-ietf-v6ops-natpt-to-historic-00] (25 pages)
 - IPv6 Neighbor Discovery On-Link Assumption Considered Harmful [draft-ietf-v6ops-onlinkassumption-04] (8 pages)
 - Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) [draft-ietf-v6ops-pmtud-ecmp-problem-06] (9 pages)
 - IPv6 Router Advertisement Guard [draft-ietf-v6ops-ra-guard-08] (10 pages)
 - Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [draft-ietf-v6ops-ra-guard-implementation-07] (13 pages)
 - Reducing Energy Consumption of Router Advertisements [draft-ietf-v6ops-reducing-ra-energy-consumption-03] (6 pages)
 - Procedures for Renumbering an IPv6 Network without a Flag Day [draft-ietf-v6ops-renumbering-procedure-05] (22 pages)
 - IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts [draft-ietf-v6ops-rfc3316bis-06] (20 pages)
 - Special-Use IPv6 Addresses [draft-ietf-v6ops-rfc3330-for-ipv6-04] (7 pages)
 - Happy Eyeballs Version 2: Better Connectivity Using Concurrency [draft-ietf-v6ops-rfc6555bis-07] (15 pages)
 - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-rfc7084-bis-04] (31 pages)
 - Rogue IPv6 Router Advertisement Problem Statement [draft-ietf-v6ops-rogue-ra-02] (16 pages)
 - IPv6 Routing Policies Guidelines [draft-ietf-v6ops-routing-guidelines-01] (8 pages)
 - IPv6 Implications for Network Scanning [draft-ietf-v6ops-scanning-implications-04] (13 pages)
 - IPv6 Transition/Co-existence Security Considerations [draft-ietf-v6ops-security-overview-06] (41 pages)
 - SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments [draft-ietf-v6ops-siit-dc-03] (24 pages)
 - Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode [draft-ietf-v6ops-siit-dc-2xlat-02] (17 pages)
 - Explicit Address Mappings for Stateless IP/ICMP Translation [draft-ietf-v6ops-siit-eam-03] (19 pages)
 - Teredo Security Concerns [draft-ietf-v6ops-teredo-security-concerns-02] (20 pages)
 - Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations [draft-ietf-v6ops-tunnel-loops-07] (19 pages)
 - Security Concerns with IP Tunneling [draft-ietf-v6ops-tunnel-security-concerns-04] (20 pages)
 - Considerations For Using Unique Local Addresses [draft-ietf-v6ops-ula-usage-considerations-02] (13 pages)
 - Considerations For Using Unique Local Addresses [draft-ietf-v6ops-ula-usage-recommendations-05] (16 pages)
 - Unique IPv6 Prefix per Host [draft-ietf-v6ops-unique-ipv6-prefix-per-host-13] (10 pages)
 - Unmanaged Networks IPv6 Transition Scenarios [draft-ietf-v6ops-unman-scenarios-03] (20 pages)
 - Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks [draft-ietf-v6ops-unmaneval-03] (19 pages)
 - Local-Use IPv4/IPv6 Translation Prefix [draft-ietf-v6ops-v4v6-xlat-prefix-02] (7 pages)
 - Framework for IP Version Transition Scenarios [draft-ietf-v6ops-v4v6tran-framework-02] (7 pages)
 - Considerations for Transitioning Content to IPv6 [draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11] (27 pages)
 - Mobile Networks Considerations for IPv6 Deployment [draft-ietf-v6ops-v6-in-mobile-networks-05] (17 pages)
 - IPv6 Deployment in Internet Exchange Points (IXPs) [draft-ietf-v6ops-v6inixp-09] (10 pages)
 - Operational Neighbor Discovery Problems [draft-ietf-v6ops-v6nd-problems-05] (12 pages)
 - Issues with Dual Stack IPv6 on by Default [draft-ietf-v6ops-v6onbydefault-03] (14 pages)
 - Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks [draft-ietf-v6ops-vlan-usage-01] (11 pages)
 - Wireline Incremental IPv6 [draft-ietf-v6ops-wireline-incremental-ipv6-06] (29 pages)

Requests for Comments:
 BCP157: IPv6 Address Assignment to End Sites (9 pages)
          * Obsoletes RFC3177
 BCP196: Deprecating the Anycast Prefix for 6to4 Relay Routers (10 pages)
          * Obsoletes RFC3068
          * Obsoletes RFC6732
 BCP198: IPv6 Prefix Length Recommendation for Forwarding (6 pages)
 BCP202: Reducing Energy Consumption of Router Advertisements (6 pages)
 BCP204: Host Address Availability Recommendations (15 pages)
 RFC3574: Transition Scenarios for 3GPP Networks (12 pages)
 RFC3750: Unmanaged Networks IPv6 Transition Scenarios (20 pages)
 RFC3789: Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents (10 pages)
 RFC3790: Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents (49 pages)
 RFC3791: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents (15 pages)
 RFC3792: Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents (25 pages)
 RFC3793: Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents (6 pages)
 RFC3794: Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents (31 pages)
 RFC3795: Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents (50 pages)
 RFC3796: Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents (43 pages)
 RFC3904: Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks (19 pages)
 RFC3964: Security Considerations for 6to4 (41 pages)
 RFC4029: Scenarios and Analysis for Introducing IPv6 into ISP Networks (28 pages)
 RFC4038: Application Aspects of IPv6 Transition (33 pages)
 RFC4057: IPv6 Enterprise Network Scenarios (17 pages)
 RFC4192: Procedures for Renumbering an IPv6 Network without a Flag Day (22 pages)
          * Updates RFC2072
 RFC4213: Basic Transition Mechanisms for IPv6 Hosts and Routers (27 pages)
          * Obsoletes RFC2893
 RFC4215: Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks (24 pages)
 RFC4554: Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks (11 pages)
 RFC4779: ISP IPv6 Deployment Scenarios in Broadband Access Networks (81 pages)
 RFC4852: IPv6 Enterprise Network Analysis - IP Layer 3 Focus (32 pages)
 RFC4864: Local Network Protection for IPv6 (36 pages)
 RFC4890: Recommendations for Filtering ICMPv6 Messages in Firewalls (38 pages)
 RFC4891: Using IPsec to Secure IPv6-in-IPv4 Tunnels (23 pages)
 RFC4942: IPv6 Transition/Co-existence Security Considerations (41 pages)
 RFC4943: IPv6 Neighbor Discovery On-Link Assumption Considered Harmful (8 pages)
 RFC4966: Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status (25 pages)
          * Obsoletes RFC2766
 RFC5156: Special-Use IPv6 Addresses (7 pages)
          * Obsoletes RFC6890
 RFC5157: IPv6 Implications for Network Scanning (13 pages)
          * Obsoletes RFC7707
 RFC5181: IPv6 Deployment Scenarios in 802.16 Networks (16 pages)
 RFC5220: Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules (17 pages)
 RFC5221: Requirements for Address Selection Mechanisms (7 pages)
 RFC5375: IPv6 Unicast Address Assignment Considerations (35 pages)
 RFC5963: IPv6 Deployment in Internet Exchange Points (IXPs) (10 pages)
 RFC6036: Emerging Service Provider Scenarios for IPv6 Deployment (23 pages)
 RFC6092: Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service (36 pages)
 RFC6104: Rogue IPv6 Router Advertisement Problem Statement (16 pages)
 RFC6105: IPv6 Router Advertisement Guard (10 pages)
          * Updates RFC7113
 RFC6169: Security Concerns with IP Tunneling (20 pages)
 RFC6177: IPv6 Address Assignment to End Sites (9 pages)
          * Obsoletes RFC3177
 RFC6204: Basic Requirements for IPv6 Customer Edge Routers (17 pages)
          * Obsoletes RFC7084
 RFC6264: An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition (13 pages)
 RFC6312: Mobile Networks Considerations for IPv6 Deployment (17 pages)
          * Obsoletes RFC6312
          * Obsoletes RFC6342
 RFC6324: Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations (19 pages)
 RFC6342: Mobile Networks Considerations for IPv6 Deployment (17 pages)
          * Obsoletes RFC6312
 RFC6343: Advisory Guidelines for 6to4 Deployment (20 pages)
 RFC6459: IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) (36 pages)
 RFC6555: Happy Eyeballs: Success with Dual-Stack Hosts (15 pages)
          * Obsoletes RFC8305
 RFC6583: Operational Neighbor Discovery Problems (12 pages)
 RFC6589: Considerations for Transitioning Content to IPv6 (27 pages)
 RFC6666: A Discard Prefix for IPv6 (6 pages)
 RFC6782: Wireline Incremental IPv6 (29 pages)
 RFC6791: Stateless Source Address Mapping for ICMPv6 Packets (6 pages)
          * Updates RFC6145
 RFC6877: 464XLAT: Combination of Stateful and Stateless Translation (14 pages)
 RFC6883: IPv6 Guidance for Internet Content Providers and Application Service Providers (24 pages)
 RFC7066: IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts (20 pages)
          * Obsoletes RFC3316
 RFC7084: Basic Requirements for IPv6 Customer Edge Routers (21 pages)
          * Obsoletes RFC6204
 RFC7113: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) (13 pages)
          * Updates RFC6105
 RFC7157: IPv6 Multihoming without Network Address Translation (22 pages)
 RFC7269: NAT64 Deployment Options and Experience (22 pages)
 RFC7278: Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link (10 pages)
 RFC7335: IPv4 Service Continuity Prefix (4 pages)
          * Updates RFC6333
 RFC7381: Enterprise IPv6 Deployment Guidelines (34 pages)
 RFC7445: Analysis of Failure Cases in IPv6 Roaming Scenarios (19 pages)
 RFC7526: Deprecating the Anycast Prefix for 6to4 Relay Routers (10 pages)
          * Obsoletes RFC3068
          * Obsoletes RFC6732
 RFC7608: IPv6 Prefix Length Recommendation for Forwarding (6 pages)
 RFC7690: Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) (9 pages)
 RFC7755: SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments (24 pages)
 RFC7756: Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode (17 pages)
 RFC7757: Explicit Address Mappings for Stateless IP/ICMP Translation (19 pages)
          * Updates RFC6145
 RFC7772: Reducing Energy Consumption of Router Advertisements (6 pages)
 RFC7872: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World (15 pages)
 RFC7934: Host Address Availability Recommendations (15 pages)
 RFC8215: Local-Use IPv4/IPv6 Translation Prefix (7 pages)
 RFC8273: Unique IPv6 Prefix per Host (10 pages)
 RFC8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency (15 pages)
          * Obsoletes RFC6555



L2VPN Service Model (l2sm)
--------------------------

Charter
Last Modified: 2016-11-04

Current Status: Active

Chairs:
    Adrian Farrel <[email protected]>
    Qin Wu <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Benoit Claise <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Large-Scale Measurement of Broadband Performance (lmap)
-------------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Dan Romascanu <[email protected]>
    Jason Weil <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Benoit Claise <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Layer Independent OAM Management in the Multi-Layer Environment (lime)
----------------------------------------------------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Carlos Pignataro <[email protected]>
    Ron Bonica <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Benoit Claise <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

MBONE Deployment (mboned)
-------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Greg Shepherd <[email protected]>
    Leonard Giuliano <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Warren Kumari <[email protected]>

Tech Advisor:
    Scott Bradner <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Network Configuration (netconf)
-------------------------------

Charter
Last Modified: 2017-07-27

Current Status: Active

Chairs:
    Kent Watsen <[email protected]>
    Mahesh Jethanandani <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Benoit Claise <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 <[email protected]>
    Kent Watsen <[email protected]>
    Lou Berger <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Benoit Claise <[email protected]>

Secretary:
    Zitao Wang <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Operational Security Capabilities for IP Network Infrastructure (opsec)
-----------------------------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Éric Vyncke <[email protected]>
    Gunter Van de Velde <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Warren Kumari <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/opsec
    Archive:            https://mailarchive.ietf.org/arch/browse/opsec/

Description of Working Group:

 Goals:

 The OPSEC WG will document operational issues and best current practices
 with regard to network security. In particular, the working group will
 clarify the rationale of supporting current operational practice,
 addressing gaps in currently understood best practices and clarifying
 liabilities inherent in security practices where they exist.

 Scope:

 The scope of the OPSEC WG includes the protection and secure operation
 of the forwarding, control and management planes. Documentation of
 operational issues, revision of existing operational security practices
 documents and proposals for new approaches to operational challenges
 related to network security are in scope.

 Method:

 The work will result in the publication of informational or BCP RFCs.
 Taxonomy or problem statement documents may provide a basis for such
 documents.

 Informational or Best Current Practices Documents

 For each topic addressed, the working group will produce a document that
 captures common practices related to secure network operation. This will
 be primarily based on operational experience. A document might convey:

 * a threat or threats to be addressed

 * current practices for addressing the threat

 * protocols, tools and technologies extant at the time of writing that
 are used to address the threat

 * the possibility that a solution does not exist within existing tools
 or technologies

 Taxonomy and Problem Statement Documents

 These are documents that describe the scope of particular operational
 security challenges or problem spaces without necessarily coming to
 conclusions or proposing solutions. Such a document might be the
 precursor to an informational or best current practices document.

 While the principal input of the working group is operational experience
 and needs, the output should be directed towards providing guidance to
 the operators community, other working groups that develop protocols or
 the protocol development community.

 Non-Goals:

 The OPSEC WG is will not write or modify protocols. New protocol work
 must be addressed through a working group chartered for that work, or
 via one of the individual submission processes. The OPSEC WG may take on
 documents related to the practices of using such work.

Goals and Milestones:
 Done     - Complete Charter
 Done     - First draft of Framework Document as Internet Draft
 Done     - First draft of Standards Survey Document as Internet Draft
 Done     - First draft of Packet Filtering Capabilities
 Done     - First draft of Event Logging Capabilities
 Done     - First draft of Network Operator Current Security Practices
 Done     - First draft of In-Band management capabilities
 Done     - First draft of Out-of-Band management capabilities
 Done     - First draft of Configuration and Management Interface Capabilities
 Done     - Submit Network Operator Current Security Practices to IESG
 Dec 2012 - WG Adoption of 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document
 Dec 2012 - WG Adoption of 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document
 Dec 2012 - WG Adoption of 'Network Reconnaissance in IPv6 Networks' document
 Dec 2012 - WG Adoption of 'BGP operations and security' document
 Jan 2013 - WG Last Call for 'Operational Security Considerations for IPv6 Networks' document
 Jan 2013 - WG Last Call for 'Recommendations for filtering ICMP messages' document
 Jan 2013 - WG Last Call for 'Recommendations on filtering of IPv4 packets containing IPv4 options' document
 Jan 2013 - WG Last Call for 'Security Implications of IPv6 on IPv4 networks' document
 Mar 2013 - WG Last Call for 'Using Only Link-Local Addressing Inside an IPv6 Network' document
 Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG
 Mar 2013 - Submit 'Recommendations on filtering of IPv4 packets containing IPv4 options' document to IESG
 Mar 2013 - Submit 'Operational Security Considerations for IPv6 Networks' document to IESG
 Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG
 May 2013 - Submit 'Using Only Link-Local Addressing Inside an IPv6 Network' document to IESG
 Jul 2013 - WG Last Call for 'BGP operations and security' document
 Jul 2013 - WG Last Call for 'Network Reconnaissance in IPv6 Networks' document
 Jul 2013 - WG Last Call for 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document
 Jul 2013 - WG Last Call for 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document
 Sep 2013 - Submit 'BGP operations and security' document to IESG
 Sep 2013 - Submit 'Network Reconnaissance in IPv6 Networks' document to IESG
 Sep 2013 - Submit 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document to IESG

Internet-Drafts:
 - BGP Operations and Security [draft-ietf-opsec-bgp-security-07] (26 pages)
 - Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) [draft-ietf-opsec-blackhole-urpf-04] (15 pages)
 - Operational Security Current Practices in Internet Service Provider Environments [draft-ietf-opsec-current-practices-07] (37 pages)
 - DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers [draft-ietf-opsec-dhcpv6-shield-08] (12 pages)
 - Security Best Practices Efforts and Documents [draft-ietf-opsec-efforts-20] (41 pages)
 - Filtering and Rate Limiting Capabilities for IP Network Infrastructure [draft-ietf-opsec-filter-caps-09] (30 pages)
 - Framework for Operational Security Capabilities for IP Network Infrastructure [draft-ietf-opsec-framework-05] (29 pages)
 - Recommendations for filtering ICMP messages [draft-ietf-opsec-icmp-filtering-04] (58 pages)
 - Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols [draft-ietf-opsec-igp-crypto-requirements-04] (11 pages)
 - Service Provider Infrastructure Security
[draft-ietf-opsec-infrastructure-security-01] (17 pages)
 - Recommendations on Filtering of IPv4 Packets Containing IPv4 Options [draft-ietf-opsec-ip-options-filtering-07] (36 pages)
 - Security Assessment of the Internet Protocol Version 4 [draft-ietf-opsec-ip-security-07] (75 pages)
 - Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers [draft-ietf-opsec-ipv6-eh-filtering-04] (35 pages)
 - Network Reconnaissance in IPv6 Networks [draft-ietf-opsec-ipv6-host-scanning-08] (38 pages)
 - Security Implications of IPv6 on IPv4 Networks [draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07] (19 pages)
 - Security Assessment of Neighbor Discovery (ND) for IPv6 [draft-ietf-opsec-ipv6-nd-security-00] (62 pages)
 - Using Only Link-Local Addressing inside an IPv6 Network [draft-ietf-opsec-lla-only-11] (10 pages)
 - Logging Capabilities for IP Network Infrastructure [draft-ietf-opsec-logging-caps-04] (35 pages)
 - Miscellaneous Capabilities for IP Network Infrastructure
[draft-ietf-opsec-misc-cap-00] (21 pages)
 - Network Management Access Security Capabilities [draft-ietf-opsec-nmasc-00] (13 pages)
 - Protecting the Router Control Plane [draft-ietf-opsec-protect-control-plane-06] (25 pages)
 - Routing Control Plane Security Capabilities [draft-ietf-opsec-routing-capabilities-03] (20 pages)
 - Issues with Existing Cryptographic Protection Methods for Routing Protocols [draft-ietf-opsec-routing-protocols-crypto-issues-07] (21 pages)
 - Operational Security Considerations for IPv6 Networks [draft-ietf-opsec-v6-12] (48 pages)
 - Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks [draft-ietf-opsec-vpn-leakages-06] (12 pages)

Requests for Comments:
 BCP186: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options (36 pages)
 BCP194: BGP Operations and Security (26 pages)
 BCP199: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers (12 pages)
 RFC4778: Operational Security Current Practices in Internet Service Provider Environments (37 pages)
 RFC5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) (15 pages)
 RFC6039: Issues with Existing Cryptographic Protection Methods for Routing Protocols (21 pages)
 RFC6094: Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols (11 pages)
 RFC6192: Protecting the Router Control Plane (25 pages)
 RFC6274: Security Assessment of the Internet Protocol Version 4 (75 pages)
 RFC7123: Security Implications of IPv6 on IPv4 Networks (19 pages)
 RFC7126: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options (36 pages)
 RFC7359: Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks (12 pages)
 RFC7404: Using Only Link-Local Addressing inside an IPv6 Network (10 pages)
 RFC7454: BGP Operations and Security (26 pages)
 RFC7610: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers (12 pages)
 RFC7707: Network Reconnaissance in IPv6 Networks (38 pages)
          * Obsoletes RFC5157



Operations and Management Area Working Group (opsawg)
-----------------------------------------------------

Charter
Last Modified: 2017-05-24

Current Status: Active

Chairs:
    Ignas Bagdonas <[email protected]>
    Joe Clarke <[email protected]>
    Tianran Zhou <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Warren Kumari <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/opsawg
    Archive:            https://mailarchive.ietf.org/arch/browse/opsawg/

Description of Working Group:

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

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

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

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

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

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

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

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

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

Goals and Milestones:
 Done     - Initial submission for the 'SNMP Engine ID Discovery' Internet-Draft
 Done     - Initial submission for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft
 Done     - Initial submission for the 'Template for Generic Management Data Models' Internet-Draft
 Done     - Initial submission for the 'Structured Data Elements (SDEs) for syslog' Internet-Draft
 Done     - WGLC for the 'SNMP Engine ID Discovery' Internet-Draft
 Done     - Submit the 'SNMP Engine ID Discovery' Internet-Draft to the IESG for consideration as Proposed Standard
 Done     - WGLC for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft
 Done     - Submit the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft to the IESG for consideration as BCP
 Done     - WGLC for the 'Structured Data Elements (SDEs) for syslog'
 Done     - Submit the 'Structured Data Elements (SDEs) for syslog' to the IESG for consideration as Proposed Standard
 Oct 2012 - Initial submission for the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft
 Done     - Initial submission for the 'IF-CAP-STACK-MIB MIB module' Internet-Draft
 Mar 2013 - Submit the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft to the IESG for consideration as Informational
 Done     - Submit the 'IF-CAP-STACK-MIB MIB module' Internet-Draft to the IESG for consideration as Proposed Standard

Internet-Drafts:
 - On Firewalls in Internet Security [draft-baker-opsawg-firewalls-00] (12 pages)
 - Survey of Possibilities for the Automated Configuration of Large IP Networks [draft-ietf-opsawg-automated-network-configuration-05] (23 pages)
 - Alternate Tunnel Encapsulation for Data Frames in CAPWAP [draft-ietf-opsawg-capwap-alt-tunnel-12] (28 pages)
 - CAPWAP Extension for 802.11n and Power/channel Autoconfiguration [draft-ietf-opsawg-capwap-extension-06] (17 pages)
 - IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) [draft-ietf-opsawg-capwap-hybridmac-08] (13 pages)
 - Management of Networks with Constrained Devices: Problem Statement and Requirements [draft-ietf-opsawg-coman-probstate-reqs-05] (44 pages)
 - Management of Networks with Constrained Devices: Use Cases [draft-ietf-opsawg-coman-use-cases-05] (26 pages)
 - A Template for Internet Drafts Containing Data Models [draft-ietf-opsawg-data-model-doc-template-00] (24 pages)
 - On Firewalls in Internet Security [draft-ietf-opsawg-firewalls-01] (10 pages)
 - HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 [draft-ietf-opsawg-hmac-sha-2-usm-snmp-06] (14 pages)
 - HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 [draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-05] (14 pages)
 - Export BGP community information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-bgp-community-04] (18 pages)
 - Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks [draft-ietf-opsawg-large-flow-load-balancing-15] (29 pages)
 - Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs [draft-ietf-opsawg-lsn-deployment-06] (20 pages)
 - An Overview of the IETF Network Management Standards [draft-ietf-opsawg-management-stds-07] (85 pages)
 - Textual Conventions for the Representation of Floating-Point Numbers [draft-ietf-opsawg-mib-floats-02] (7 pages)
 - MIB Transfer from the IETF to the IEEE 802.3 WG [draft-ietf-opsawg-mibs-to-ieee80231-01] (7 pages)
 - Guidelines for the Use of the "OAM" Acronym in the IETF [draft-ietf-opsawg-mpls-tp-oam-def-10] (9 pages)
 - Manufacturer Usage Description Specification [draft-ietf-opsawg-mud-15] (59 pages)
 - A YANG Data Model for Network Address Translation (NAT) and Network Prefix Translation (NPT) [draft-ietf-opsawg-nat-yang-10] (97 pages)
 - An Overview of Operations, Administration, and Maintenance (OAM) Tools [draft-ietf-opsawg-oam-overview-16] (53 pages)
 - Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions [draft-ietf-opsawg-operations-and-management-09] (35 pages)
 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB [draft-ietf-opsawg-rfc5066bis-07] (6 pages)
 - Service Models Explained [draft-ietf-opsawg-service-model-explained-05] (23 pages)
 - Expressing SNMP SMI Datatypes in XML Schema Definition Language [draft-ietf-opsawg-smi-datatypes-in-xsd-06] (14 pages)
 - Simple Network Management Protocol (SNMP) Context EngineID Discovery [draft-ietf-opsawg-snmp-engineid-discovery-03] (9 pages)
 - Survey of IETF Network Management Standards [draft-ietf-opsawg-survey-management-00] (21 pages)
 - Alarms in Syslog [draft-ietf-opsawg-syslog-alarm-02] (7 pages)
 - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications [draft-ietf-opsawg-syslog-msg-mib-06] (22 pages)
 - Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages [draft-ietf-opsawg-syslog-snmp-05] (15 pages)
 - The TACACS+ Protocol [draft-ietf-opsawg-tacacs-07] (42 pages)
 - Management Information Base for Virtual Machines Controlled by a Hypervisor [draft-ietf-opsawg-vmm-mib-04] (52 pages)
 - CGN Deployment with MPLS/VPNs [draft-kuarsingh-lsn-deployment-06] (18 pages)
 - Export BGP community information in IP Flow Information Export (IPFIX) [draft-li-opsawg-ipfix-bgp-community-02] (10 pages)

Requests for Comments:
 BCP161: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages)
 RFC5343: Simple Network Management Protocol (SNMP) Context EngineID Discovery (9 pages)
          * Updates RFC3411
 RFC5674: Alarms in Syslog (7 pages)
 RFC5675: Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages (15 pages)
 RFC5676: Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications (22 pages)
 RFC5706: Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions (35 pages)
 RFC5935: Expressing SNMP SMI Datatypes in XML Schema Definition Language (14 pages)
 RFC6291: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages)
 RFC6340: Textual Conventions for the Representation of Floating-Point Numbers (7 pages)
 RFC6632: An Overview of the IETF Network Management Standards (85 pages)
 RFC7124: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB (6 pages)
          * Updates RFC5066
 RFC7276: An Overview of Operations, Administration, and Maintenance (OAM) Tools (53 pages)
 RFC7289: Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs (20 pages)
 RFC7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks (29 pages)
 RFC7448: MIB Transfer from the IETF to the IEEE 802.3 WG (7 pages)
 RFC7494: IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) (13 pages)
 RFC7547: Management of Networks with Constrained Devices: Problem Statement and Requirements (44 pages)
 RFC7548: Management of Networks with Constrained Devices: Use Cases (26 pages)
 RFC7630: HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 (14 pages)
          * Obsoletes RFC7860
 RFC7666: Management Information Base for Virtual Machines Controlled by a Hypervisor (52 pages)
 RFC7860: HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 (14 pages)
          * Obsoletes RFC7630
 RFC8309: Service Models Explained (23 pages)
 STD78: Simple Network Management Protocol (SNMP) Context EngineID Discovery (9 pages)
          * Updates RFC3411



RADIUS EXTensions (radext)
--------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Lionel Morand <[email protected]>
    Stefan Winter <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Kathleen Moriarty <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/radext
    Archive:            https://mailarchive.ietf.org/arch/browse/radext/

Description of Working Group:

 The RADIUS Extensions Working Group will focus on extensions to the
 RADIUS protocol pending approval of the new work from the Area Director
 and clarify its usage and definition.

 Furthermore, to ensure backward compatibility with existing RADIUS
 implementations, as well as compatibility between RADIUS and Diameter,
 the following restriction is imposed on extensions considered by the
 RADEXT WG:
 All documents produced must specify means of interoperation with legacy
 RADIUS and, if possible, be backward compatible with existing RADIUS
 RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675,
 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be
 compatible with RFC 3539.

 The WG will review its existing RFCs' document track categories and
 where necessary or useful change document tracks, with minor changes in
 the documents if needed. Any changes to document tracks require approval
 by the responsible Area Director.

 Work Items

 The immediate goals of the RADEXT working group are to address the
 following issues:

 - CoA proxying.  RFC 5176 permits proxying of CoA and Disconnect
 messages, but makes no provisions for how that is done in a roaming
 environment.  This work item will provide descriptions of how to use
 the Operator-Name attribute in a roaming environment to proxy CoA
 packets in a way that ensures only authorized proxies can send these
 packets to the home CoA server.

 - Encoding Rules for EAP-Response/Identity packets over RADIUS. Neither
 EAP (RFC3748) nor EAP over RADIUS (RFC3579) demand specific character
 encoding and normalisation rules for EAP Identity responses. RADIUS
 (RFC2865) requires User-Name attributes to be encoded in UTF-8. When a NAS
 simply performs an exact copy of an EAP-Identity into a User-Name, invalid
 packets might be produced. This document will suggest restrictions on EAP
 Identities so that transport over AAA becomes correct under all circumstances
 (UTF-8) and deterministic (normalisation).

 - Data Types. RFC 2865 defines a number of data types, but later
 documents do not use those types in a consistent way.  This work item
 will define data types, and update the IANA RADIUS Attribute Type
 registry so that each attribute has a data type.  Where necessary, it
 will correct issues with previous specifications.

 - Larger Packets. Support RADIUS packets greater than 4096-octets over
 RADIUS transports with this capability.

 - RADIUS Attributes for IP Port Configuration and Reporting. These
 attributes are used by devices that implement IP port ranges to
 configure and report TCP/UDP ports and ICMP identifiers, as well as
 mapping behaviors. These attributes can be used in the context of
 address sharing (e.g., NAT44 [RFC3022], Dual-Stack Lite AFTR [RFC6333],
 CGN [RFC6888], NAT64 [RFC6146], Provider WLAN (e.g., [TR-146]), etc.).

Goals and Milestones:
 Done     - RFC 4282bis submitted as a Proposed Standard RFC
 Done     - Dynamic Discovery I-D submitted as a Proposed Standard RFC
 Done     - RADIUS packet fragmentation submitted as an Experimental RFC
 Nov 2015 - Larger Packets for RADIUS over TCP I-D submitted as an Experimental RFC
 Nov 2015 - Submit CoA Proxying as Standards Track RFC
 Mar 2016 - IP Port RADIUS Extensions as Standards Track RFC
 Nov 2016 - Submit Populating EAP Identity as BCP RFC
 Nov 2016 - Data Types as Informational RFC

Internet-Drafts:
 - Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) [draft-dekok-radext-coa-proxy-00] (10 pages)
 - Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) [draft-dekok-radext-datatypes-06] (32 pages)
 - The Network Access Identifier [draft-dekok-radext-nai-02] (19 pages)
 - Larger Packets for RADIUS over TCP [draft-ietf-radext-bigger-packets-07] (10 pages)
 - Chargeable User Identity [draft-ietf-radext-chargeable-user-id-06] (10 pages)
 - Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) [draft-ietf-radext-coa-proxy-02] (16 pages)
 - Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) [draft-ietf-radext-crypto-agility-requirements-07] (12 pages)
 - Data Types in RADIUS [draft-ietf-radext-datatypes-08] (35 pages)
 - RADIUS Delegated-IPv6-Prefix Attribute [draft-ietf-radext-delegated-prefix-05] (7 pages)
 - RADIUS Design Guidelines [draft-ietf-radext-design-19] (38 pages)
 - RADIUS Extension for Digest Authentication [draft-ietf-radext-digest-auth-09] (32 pages)
 - Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS [draft-ietf-radext-dtls-13] (27 pages)
 - Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) [draft-ietf-radext-dynamic-discovery-15] (32 pages)
 - RADIUS Dynamic Authorization Client MIB [draft-ietf-radext-dynauth-client-mib-06] (24 pages)
 - RADIUS Dynamic Authorization Server MIB [draft-ietf-radext-dynauth-server-mib-06] (24 pages)
 - Extended Remote Authentication Dial In User Service (RADIUS) Attributes [draft-ietf-radext-extended-attributes-09] (13 pages)
 - RADIUS Filter Rule Attribute [draft-ietf-radext-filter-08] (9 pages)
 - RADIUS Attributes for Filtering and Redirection [draft-ietf-radext-filter-rules-03] (30 pages)
 - Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes [draft-ietf-radext-fixes-08] (28 pages)
 - VLAN, Priority, and Filtering Attributes [draft-ietf-radext-ieee802-01] (32 pages)
 - RADIUS Attributes for IEEE 802 Networks [draft-ietf-radext-ieee802ext-12] (29 pages)
 - RADIUS Extensions for IP Port Configuration and Reporting [draft-ietf-radext-ip-port-radius-ext-17] (43 pages)
 - RADIUS Attributes for IPv6 Access Networks [draft-ietf-radext-ipv6-access-16] (15 pages)
 - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management [draft-ietf-radext-management-authorization-07] (25 pages)
 - The Network Access Identifier [draft-ietf-radext-nai-15] (30 pages)
 - Considerations regarding the correct use of EAP-Response/Identity [draft-ietf-radext-populating-eapidentity-01] (10 pages)
 - Remote Authentication Dial In User Service (RADIUS) Protocol Extensions [draft-ietf-radext-radius-extensions-13] (68 pages)
 - Support of Fragmentation of RADIUS Packets [draft-ietf-radext-radius-fragmentation-12] (38 pages)
 - Transport Layer Security (TLS) Encryption for RADIUS [draft-ietf-radext-radsec-12] (22 pages)
 - The Network Access Identifier [draft-ietf-radext-rfc2486bis-06] (16 pages)
 - RADIUS Authentication Client MIB for IPv6 [draft-ietf-radext-rfc2618bis-04] (24 pages)
 - RADIUS Authentication Server MIB for IPv6 [draft-ietf-radext-rfc2619bis-04] (25 pages)
 - RADIUS Accounting Client MIB for IPv6 [draft-ietf-radext-rfc2620bis-04] (23 pages)
 - RADIUS Accounting Server MIB for IPv6 [draft-ietf-radext-rfc2621bis-04] (24 pages)
 - Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) [draft-ietf-radext-rfc3576bis-13] (34 pages)
 - RADIUS Extension for Digest Authentication [draft-ietf-radext-rfc4590bis-02] (33 pages)
 - Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol [draft-ietf-radext-status-server-09] (24 pages)
 - RADIUS over TCP [draft-ietf-radext-tcp-transport-09] (16 pages)
 - New Tunnel-Type Values [draft-ietf-radext-tunnel-type-00] (6 pages)
 - RADIUS Attributes for Virtual LAN and Priority Support [draft-ietf-radext-vlan-06] (15 pages)
 - Considerations regarding the correct use of EAP-Response/Identity [draft-winter-radext-populating-eapidentity-01] (7 pages)

Requests for Comments:
 BCP158: RADIUS Design Guidelines (38 pages)
 RFC4282: The Network Access Identifier (16 pages)
          * Obsoletes RFC2486
          * Obsoletes RFC7542
 RFC4372: Chargeable User Identity (10 pages)
 RFC4590: RADIUS Extension for Digest Authentication (32 pages)
          * Obsoletes RFC5090
 RFC4668: RADIUS Authentication Client MIB for IPv6 (24 pages)
          * Obsoletes RFC2618
 RFC4669: RADIUS Authentication Server MIB for IPv6 (25 pages)
          * Obsoletes RFC2619
 RFC4670: RADIUS Accounting Client MIB for IPv6 (23 pages)
          * Obsoletes RFC2620
 RFC4671: RADIUS Accounting Server MIB for IPv6 (24 pages)
          * Obsoletes RFC2621
 RFC4672: RADIUS Dynamic Authorization Client MIB (24 pages)
 RFC4673: RADIUS Dynamic Authorization Server MIB (24 pages)
 RFC4675: RADIUS Attributes for Virtual LAN and Priority Support (15 pages)
 RFC4818: RADIUS Delegated-IPv6-Prefix Attribute (7 pages)
 RFC4849: RADIUS Filter Rule Attribute (9 pages)
 RFC5080: Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes (28 pages)
          * Updates RFC2865
          * Updates RFC2866
          * Updates RFC2869
          * Updates RFC3579
 RFC5090: RADIUS Extension for Digest Authentication (33 pages)
          * Obsoletes RFC4590
 RFC5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (34 pages)
          * Obsoletes RFC3576
 RFC5607: Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management (25 pages)
 RFC5997: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol (24 pages)
          * Updates RFC2866
 RFC6158: RADIUS Design Guidelines (38 pages)
          * Updates RFC6929
          * Updates RFC8044
 RFC6421: Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) (12 pages)
 RFC6613: RADIUS over TCP (16 pages)
          * Updates RFC7930
 RFC6614: Transport Layer Security (TLS) Encryption for RADIUS (22 pages)
 RFC6911: RADIUS Attributes for IPv6 Access Networks (15 pages)
 RFC6929: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions (68 pages)
          * Updates RFC2865
          * Updates RFC3575
          * Updates RFC6158
 RFC7268: RADIUS Attributes for IEEE 802 Networks (29 pages)
          * Updates RFC4072
          * Updates RFC3580
          * Updates RFC8044
 RFC7360: Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS (27 pages)
 RFC7499: Support of Fragmentation of RADIUS Packets (38 pages)
 RFC7542: The Network Access Identifier (30 pages)
          * Obsoletes RFC4282
 RFC7585: Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) (32 pages)
 RFC7930: Larger Packets for RADIUS over TCP (10 pages)
          * Updates RFC6613
 RFC8044: Data Types in RADIUS (35 pages)
          * Updates RFC2865
          * Updates RFC3162
          * Updates RFC4072
          * Updates RFC6158
          * Updates RFC6572
          * Updates RFC7268
 RFC8045: RADIUS Extensions for IP Port Configuration and Reporting (43 pages)



SIDR Operations (sidrops)
-------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Chris Morrow <[email protected]>
    Keyur Patel <[email protected]>

Operations and Management Area Directors:
    Benoit Claise <[email protected]>
    Warren Kumari <[email protected]>

Operations and Management Area Advisor:
    Warren Kumari <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/sidrops
    Archive:            https://mailarchive.ietf.org/arch/browse/sidrops/

Description of Working Group:

 The global deployment of SIDR, consisting of RPKI, Origin Validation of
 BGP announcements, and BGPSEC, is underway, creating an Internet
 Routing System consisting of SIDR-aware and non-SIDR-aware networks.
 This deployment must be properly handled to avoid the division of
 the Internet into separate networks. Sidrops is responsible for
 encouraging deployment of theSIDR technologies while ensuring as secure
 of a global routing system, as possible, during the transition.

 The SIDR Operations Working Group (sidrops) develops guidelines for
 the operation of SIDR-aware networks, and provides operational guidance
 on how to deploy and operate SIDR technologies in existing and new
 networks.

 In the space of sidrops, the term operators will encompass a range
 of operational experience: CA Operators, Regional/National and Local
 Internet Registries, Relying Party software developers as well as the
 research/measurement community all have relevant operational experience
 or insight that this working group will consider in its work.

 The sidrops working group is focused on deployment and operational
 issues and experiences with SIDR technologies that are part of the
 global routing system, as well as the repositories and CA systems that
 form part of the SIDR architecture.

 The goals of the sidrops working group are to:

 1. Solicit input from a range of operators to identify operational
 issues with a SIDR-aware Internet, and determine solutions or
 workarounds to those issues.

 2. Solicit input from all operators to identify
 issues with interaction with the non-SIDR-aware Internet,
 and to determine solutions or workarounds to those issues.

 3. Develop operational solutions for identified issues in sidrops and
 document them in informational or BCP documents.

 These documents should document SIDR operational experience, including
 interactions with non-SIDR-aware networks, the interfaces between SIDR-
 aware and non-SIDR-aware networks, and the continued operational/
 security impacts from non-SIDR-aware networks.

 SIDR operational and deployment issues with Interdomain Routing
 Protocols as well as BGPSEC maintenance and extension are the
 primary responsibility of the IDR working group. The sidrops Working
 Group may provide input to that group, as needed, and cooperate with
 that group in reviewing solutions to SIDR operational and deployment
 problems.

 Future work items within this scope will be adopted by the Working
 Group if there is a substantial expression of interest from
 the community and if the work (for example protocol maintenance)
 clearly does not fit elsewhere in the IETF.

 There must be a continuous expression of interest for the Working
 Group to work on a particular work item. If there is no longer
 sufficient interest in the Working Group in a work item, the item
 may be removed from the list of Working Group items.

Goals and Milestones:
 Jul 2017 -  draft-ietf-sidr-bgpsec-rollover
 Jul 2017 - draft-ietf-sidr-rtr-keying
 Jul 2017 -  draft-ietf-sidr-route-server-rpki-light
 Jul 2017 - draft-ietf-sidr-rpki-tree-validation
 Sep 2017 - BGPSEC Ops document finalized.

Internet-Drafts:
 - BGPsec Router Certificate Rollover [draft-ietf-sidr-bgpsec-rollover-06] (10 pages)
 - Use Cases for Localized Versions of the RPKI [draft-ietf-sidr-lta-use-cases-07] (5 pages)
 - Signaling Prefix Origin Validation Results from a Route-Server to Peers [draft-ietf-sidr-route-server-rpki-light-01] (6 pages)
 - RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator [draft-ietf-sidr-rpki-tree-validation-03] (15 pages)
 - BGPsec Router Certificate Rollover [draft-ietf-sidrops-bgpsec-rollover-04] (11 pages)
 - Use Cases for Localized Versions of the RPKI [draft-ietf-sidrops-lta-use-cases-02] (5 pages)
 - Origin Validation Clarifications [draft-ietf-sidrops-ov-clarify-00] (4 pages)
 - Signaling Prefix Origin Validation Results from a Route Server to Peers [draft-ietf-sidrops-route-server-rpki-light-02] (7 pages)
 - Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties [draft-ietf-sidrops-rp-00] (11 pages)
 - RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator [draft-ietf-sidrops-rpki-tree-validation-01] (15 pages)
 - RPKI signed object for TAL [draft-ietf-sidrops-signed-tal-00] (10 pages)
 - Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers [draft-ietf-sidrops-validating-bgp-speaker-00] (9 pages)

No Requests for Comments

Babel routing protocol (babel)
------------------------------

Charter
Last Modified: 2016-06-17

Current Status: Active

Chairs:
    Donald E. Eastlake 3rd <[email protected]>
    Russ White <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alia Atlas <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 <[email protected]>
    Stephane Litkowski <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alvaro Retana <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



Bidirectional Forwarding Detection (bfd)
----------------------------------------

Charter
Last Modified: 2015-10-26

Current Status: Active

Chairs:
    Jeffrey Haas <[email protected]>
    Reshad Rahman <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alvaro Retana <[email protected]>

Tech Advisors:
    Dave Katz <[email protected]>
    David Ward <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 <[email protected]>
    Tony Przygienda <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alia Atlas <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Common Control and Measurement Plane (ccamp)
--------------------------------------------

Charter
Last Modified: 2015-10-07

Current Status: Active

Chairs:
    Daniele Ceccarelli <[email protected]>
    Fatai Zhang <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Deborah Brungard <[email protected]>

Secretary:
    Oscar de Dios <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Deterministic Networking (detnet)
---------------------------------

Charter
Last Modified: 2017-12-01

Current Status: Active

Chairs:
    Janos Farkas <[email protected]>
    Lou Berger <[email protected]>
    Patricia Thaler <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Deborah Brungard <[email protected]>

Secretary:
    Jouni Korhonen <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Inter-Domain Routing (idr)
--------------------------

Charter
Last Modified: 2017-02-09

Current Status: Active

Chairs:
    John Scudder <[email protected]>
    Susan Hares <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alvaro Retana <[email protected]>

Secretary:
    Jie Dong <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



Interface to the Routing System (i2rs)
--------------------------------------

Charter
Last Modified: 2016-06-07

Current Status: Active

Chairs:
    Russ White <[email protected]>
    Susan Hares <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alia Atlas <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



IS-IS for IP Internets (isis)
-----------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Christian Hopps <[email protected]>
    Hannes Gredler <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alia Atlas <[email protected]>

Tech Advisor:
    David Ward <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



Layer Two Tunneling Protocol Extensions (l2tpext)
-------------------------------------------------

Charter
Last Modified: 2015-10-07

Current Status: Active

Chairs:
    Carlos Pignataro <[email protected]>
    Ignacio Goyret <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Deborah Brungard <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Locator/ID Separation Protocol (lisp)
-------------------------------------

Charter
Last Modified: 2017-03-15

Current Status: Active

Chairs:
    Joel M. Halpern <[email protected]>
    Luigi Iannone <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Deborah Brungard <[email protected]>

Secretaries:
    Padma Pillay-Esnault <[email protected]>
    Wassim Haddad <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



Mobile Ad-hoc Networks (manet)
------------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Justin Dean <[email protected]>
    Stan Ratliff <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alvaro Retana <[email protected]>

Secretary:
    Ulrich Herberg <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



Multiprotocol Label Switching (mpls)
------------------------------------

Charter
Last Modified: 2016-07-27

Current Status: Active

Chairs:
    George Swallow <[email protected]>
    Loa Andersson <[email protected]>
    Nicolai Leymann <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Deborah Brungard <[email protected]>

Secretary:
    Tarek Saad <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Network Virtualization Overlays (nvo3)
--------------------------------------

Charter
Last Modified: 2016-09-05

Current Status: Active

Chairs:
    Matthew Bocci <[email protected]>
    Sam Aldrin <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alia Atlas <[email protected]>

Tech Advisor:
    Ron Bonica <[email protected]>

Secretary:
    Ignas Bagdonas <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/nvo3
    Archive:            https://mailarchive.ietf.org/arch/browse/nvo3/

Description of Working Group:

 The purpose of the NVO3 WG is to develop a set of protocols and/or
 protocol extensions that enable network virtualization within a data
 center (DC) environment that assumes an IP-based underlay. An NVO3
 solution provides layer 2 and/or layer 3 services for virtual networks
 enabling multi-tenancy and workload mobility, addressing the issues
 described in the problem statement (including management and security),
 and consistent with the framework previously produced by the NVO3 WG.

 The NVO3 WG will develop solutions for network virtualization based on
 the following architectural tenets:
  - Support for an IP-based underlay data plane
  - A logically centralized authority for network virtualization
 Network virtualization approaches that do not adhere to these tenets are
 explicitly outside of the scope of the NVO3 WG.

 In pursuit of the solutions described above, the NVO3 WG will document
 an architecture for network virtualization within a data center
 environment.

 The NVO3 WG may produce requirements for a network virtualization
 control plane, and will select, extend, and/or develop one protocol
 for each of the functional interfaces identified to support the
 architecture. Such protocols are expected to fulfill the communication
 requirements between an End Device and a Network Virtualization Edge
 (NVE) in cases where the NVE is not co-resident with the End Device,
 and between an NVE and the Network Virtualization Authority (NVA).
 The internal mechanisms and protocols of a logically centralized NVA
 are explicitly out of scope of the NVO3 WG.  Architectural issues
 raised by coexistence of multiple logically centralized control planes
 in the same data center may be considered by the WG. Inter-DC
 mechanisms are not in scope of the NVO3 WG at this time.

 The NVO3 WG may produce requirements for network virtualization data
 planes based on encapsulation of virtual network traffic over an IP-
 based underlay data plane. Such requirements should consider OAM and
 security. Based on these requirements the WG will select, extend, and/or
 develop one or more data plane encapsulation format(s).

 Additionally, the WG may document common use-cases for NVO3 solutions.

 The working group may choose to adopt a protocol or data encapsulation
 that was previously worked on outside the IETF as the basis for the WG's
 work.  If the NVO3 WG anticipates the adoption of the technologies of
 another SDO as part of the selected protocols or data encapsulation, the
 NVO3 WG will first liaise with that SDO to ensure the compatibility of
 the approach.

 The NVO3 WG will not consider solutions to network virtualization
 within a data center environment based on extensions to BGP or LISP
 protocols.

Goals and Milestones:
 Done     - Problem Statement submitted for IESG review
 Done     - Framework document submitted for IESG review
 Done     - Architecture submitted for IESG review
 Done     - Use Cases submitted for IESG review
 Publication Requested for Split-NVE Requirements     - End Device - NVE Control Plane Solution submitted for IESG review
 May 2018 - Data Plane Requirements submitted for IESG review
 May 2018 - Data Plane Solution submitted for IESG review
 Jul 2018 - Control Plane Requirements submitted for IESG review
 Jul 2018 - NVE - NVA Control Plane Solution submitted for IESG review
 Aug 2018 - Recharter or close working group
 Aug 2018 - OAM Solution submitted for IESG Review

Internet-Drafts:
 - A Framework for Multicast in NVO3 [draft-ghanwani-nvo3-mcast-framework-00] (15 pages)
 - Geneve: Generic Network Virtualization Encapsulation [draft-gross-geneve-02] (24 pages)
 - Generic UDP Encapsulation [draft-herbert-gue-03] (24 pages)
 - An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) [draft-ietf-nvo3-arch-08] (35 pages)
 - NVO3 Data Plane Requirements [draft-ietf-nvo3-dataplane-requirements-03] (18 pages)
 - NVO3 Encapsulation Considerations [draft-ietf-nvo3-encap-01] (19 pages)
 - Framework for Data Center (DC) Network Virtualization [draft-ietf-nvo3-framework-09] (26 pages)
 - NVO3 Gap Analysis - Requirements Versus Available Technology Choices [draft-ietf-nvo3-gap-analysis-01] (21 pages)
 - Geneve: Generic Network Virtualization Encapsulation [draft-ietf-nvo3-geneve-05] (26 pages)
 - Generic UDP Encapsulation [draft-ietf-nvo3-gue-05] (37 pages)
 - Split Network Virtualization Edge (Split-NVE) Control Plane Requirements [draft-ietf-nvo3-hpvr2nve-cp-req-13] (24 pages)
 - A Framework for Multicast in Network Virtualization over Layer 3 [draft-ietf-nvo3-mcast-framework-11] (17 pages)
 - Network Virtualization NVE to NVA Control Protocol Requirements [draft-ietf-nvo3-nve-nva-cp-req-05] (12 pages)
 - Problem Statement: Overlays for Network Virtualization [draft-ietf-nvo3-overlay-problem-statement-04] (23 pages)
 - Security Requirements of NVO3 [draft-ietf-nvo3-security-requirements-07] (19 pages)
 - Use Cases for Data Center Network Virtualization Overlay Networks [draft-ietf-nvo3-use-case-17] (16 pages)
 - Network-related VM Mobility Issues [draft-ietf-nvo3-vm-mobility-issues-03] (11 pages)
 - Virtual Machine Mobility Protocol for L2 and L3 Overlay Networks [draft-ietf-nvo3-vmm-01] (12 pages)
 - Generic Protocol Extension for VXLAN [draft-ietf-nvo3-vxlan-gpe-05] (17 pages)
 - Framework for DC Network Virtualization [draft-lasserre-nvo3-framework-03] (22 pages)
 - Use Cases for DC Network Virtualization Overlays [draft-mity-nvo3-use-case-04] (17 pages)
 - Generic Protocol Extension for VXLAN [draft-quinn-vxlan-gpe-04] (22 pages)

Requests for Comments:
 RFC7364: Problem Statement: Overlays for Network Virtualization (23 pages)
 RFC7365: Framework for Data Center (DC) Network Virtualization (26 pages)
 RFC8014: An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) (35 pages)
 RFC8151: Use Cases for Data Center Network Virtualization Overlay Networks (16 pages)
 RFC8293: A Framework for Multicast in Network Virtualization over Layer 3 (17 pages)



Open Shortest Path First IGP (ospf)
-----------------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Abhay Roy <[email protected]>
    Acee Lindem <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alia Atlas <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/ospf
    Archive:            https://mailarchive.ietf.org/arch/browse/ospf/

Description of Working Group:


   The OSPF Working develops and documents extensions and bug fixes to the
   OSPF protocol, as well as documenting OSPF usage scenarios.
   The specific protocol work items area listed in the Goals and
   Milestones section below. Additional work items will require
   rechartering.




Goals and Milestones:
 Done     - Submit OSPF for IPv6 to IESG for consideration as a Standard.
 Done     - Update the OSPF NSSA option specified in RFC 1587 and submit to IESG for consideration as a Proposed Standard
 Done     - Develop Traffic Engineering extensions for OSPFv2 and submit it to the IESG as a Proposed Standard
 Done     - Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited.
 Done     - Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time
 Done     - Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard.
 Done     - Document Alternative ABR implementations and submit ti IESG as an Informational RFC
 Done     - Extend the hitless restart mechanism to OSPFv3 and submit it to the IESG as a Proposed Standard
 Done     - Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic.
 Done     - Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850
 Done     - Specify IPSEC usage with OSPFv3 and submit to IESG for consideration as a Proposed Standard
 Done     - Extend OSPF Demand Circuits to detect inactive neighbors and submit to IESG for consideration as a Proposed Standard
 Done     - Provide mechanisms to prevent looping in RFC 2547 OSPF networks and submit to IESG for consideration as a Proposed Standard
 Done     - Develop OSPFv2 Multiple Topology Routing (MTR) specification and submit to IESG for consideration as a Proposed Standard
 Done     - Develop OSPF Capabilities Advertisement specification and submit to IESG for consideration as a Proposed Standard
 Done     - Document IANA Considerations for OSPFv2 and OSPFv3 for consideration as a BCP
 Done     -  Standardize OSPF PCE Capabilities Advertisement
 Done     - Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard
 Done     - Reissue RFC 2370 with corrections and clarifications and submit to IESG for consideration as a Proposed Standard
 Done     - Reissue RFC 2740 with corrections and clarifications and submit to IESG for consideration as a Proposed Standard
 Done     - Develop mechanisms for support of multi-area adjacencies on a single link and submit to IESG for consideration as a Proposed Standard
 Done     - Advance Link Local Signaling (LLS) from experimental status and submit to IESG for consideration as a Proposed Standard
 Done     -  Standardize OSPFv2 Multi-Area Adjacency
 Done     -  Standardize OSPFv3 Graceful Restart
 Done     - Develop Traffic Engineering extensions for OSPFv3 and submit it to the IESG as a Proposed Standard
 Done     - Develop multiple instance OSPFv3 protocol mechanisms to support multiple address families and topologies
 Done     - Develop multiple OSPFv3 protocol alternatives to reduce flooding overhead and adjacencies in a MANET environment and submit to the IESG as experimental RFCs
 Done     -  Standardize OSPFv3 Graceful Restart
 Done     - Standardize OSPFv3 TE Extensions
 Done     - Update OSPFv3 (RFC 2740)
 Done     - Develop stronger authentication mechanisms for OSPFv2 and submit to IESG as a Proposed Standard
 Mar 2009 - Develop a single instance OSPFv3 Multiple Topology Routing (MTR) specification and submit to IESG for consideration as a Proposed Standard
 Done     - Standarize Dynamic Hostname Advertisement
 Done     - Standardize OSPFv3 MIB
 Done     -  Standardize OSPF Link Local Signalling (Experimental)
 Done     -  Standardize OSPFv2 HMAC-SHA Cryptographic Authentication
 Done     - Standardize OSPF TE Node Address Extensions
 Done     - Experimental OSPFv3 MANET Extensions
 Done     - Standardize OSPFv3 Address Family extensions
 Done     - Standardize OSPFv3 Authentication Trailer extensions
 Done     - Standardize OSPFv2 multi-instance extensions
 Done     - Standardize OSPFv3 as a Provider Edge Routing Protocol
 Done     - Standardize OSPF/OSPFv3 Prefix Hiding mechanisms
 Done     - Update OSPF Stub Router (RFC 3107) mechanisms supporting OSPFv3
 Done     - Publish experimental OSPF MANET extensions for Single-Hop Broadcast Networks
 Done     - Standardize protocol extensions for OSPFv3 authentication supporting KARP requirements
 Done     - Standardize TE Metric Extensions supporting delay, loss, and bandwith
 Done     -  Standardize protocol extensions for OSPFv2 authentication supporting KARP requirements
 Done     - Standardize protocol extensions for OSPFv3 autoconfiguration
 Dec 2015 - Standardize OSPFv2 Extensions to advertise Prefix/Link Attributes
 Dec 2015 - Re-issue RFC 4970 with multi-instance support
 Dec 2015 - Standardize OSPF Advertisement of Seamless-BFD Discriminators
 Dec 2015 - Standardize OSPF Advertisement of Node Admin Tags
 Jun 2016 - Standardize OSPFv2 Extensions for Segment Routing
 Jun 2016 - Standardize OSPF 2-Part Metric Extensions
 Jun 2016 - Standardize OSPF Entropy Label Capabity Advertisement Extensions
 Jun 2016 - Standardize OSPF Maximally Redundant Trees Advertisement Extensions
 Jun 2016 - Standardize OSPFv3 over IPv4 Extensions
 Jun 2016 -  Publish Experimental Draft on OSPF TTZ
 Dec 2016 - Standardize OSPF YANG Model
 Dec 2016 -  Standardize OSPFv3 LSA Extensions
 Jun 2017 - Standardize OSPF Flow Spec Extensions
 Jun 2017 - Standardize OSPFv3 Segment Routing Extensions

Internet-Drafts:
 - QoS Routing Mechanisms and OSPF Extensions [draft-guerin-qos-routing-ospf-05] (50 pages)
 - Multicast Extensions to OSPF [draft-ietf-mospf-mospf-01] (102 pages)
 - Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) [draft-ietf-ospf-2547-dnbit-04] (7 pages)
 - Type 5 to Type 7 Translation [draft-ietf-ospf-5to7-01] (10 pages)
 - Alternative Implementations of OSPF Area Border Routers [draft-ietf-ospf-abr-alt-05] (12 pages)
 - OSPF ABR Behavior [draft-ietf-ospf-abr-behavior-00] (15 pages)
 - Support of Address Families in OSPFv3 [draft-ietf-ospf-af-alt-10] (13 pages)
 - OSPF Protocol Analysis [draft-ietf-ospf-analysis-00] (12 pages)
 - The OSPF Address Resolution Advertisement Option [draft-ietf-ospf-ara-02] (40 pages)
 - OSPF over ATM and Proxy-PAR [draft-ietf-ospf-atm-03] (14 pages)
 - Supporting Authentication Trailer for OSPFv3 [draft-ietf-ospf-auth-trailer-ospfv3-11] (20 pages)
 - Extensions to OSPF for Advertising Optional Router Capabilities [draft-ietf-ospf-cap-11] (13 pages)
 - IP Forwarding Table MIB [draft-ietf-ospf-cidr-route-mib-05] (21 pages)
 - OSPF Database Exchange Summary List Optimization [draft-ietf-ospf-dbex-opt-02] (6 pages)
 - Detecting Inactive Neighbors over OSPF Demand Circuits (DC) [draft-ietf-ospf-dc-07] (6 pages)
 - Extending OSPF to Support Demand Circuits [draft-ietf-ospf-demand-01] (32 pages)
 - Techniques in OSPF-based Network [draft-ietf-ospf-deploy-00] (0 pages)
 - Extensions to OSPF for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-ospf-diff-te-00] (7 pages)
 - OSPFv2 Domain Of Interpretation (DOI) for ISAKMP [draft-ietf-ospf-doi-00] (11 pages)
 - Dynamic Hostname Exchange Mechanism for OSPF [draft-ietf-ospf-dynamic-hostname-05] (8 pages)
 - The Tunnel Encapsulations OSPF Router Information [draft-ietf-ospf-encapsulation-cap-09] (11 pages)
 - Experience with the OSPF Protocol [draft-ietf-ospf-experience-00] (31 pages)
 - The OSPF External Attributes LSA [draft-ietf-ospf-extattr-00] (18 pages)
 - OSPF Floodgates [draft-ietf-ospf-floodgates-01] (22 pages)
 - OSPF Extensions for Flow Specification [draft-ietf-ospf-flowspec-extensions-01] (19 pages)
 - Graceful OSPF Restart Implementation Report [draft-ietf-ospf-graceful-impl-report-05] (6 pages)
 - Guidelines for Running OSPF Over Frame Relay Networks [draft-ietf-ospf-guidelines-frn-00] (6 pages)
 - Graceful OSPF Restart [draft-ietf-ospf-hitless-restart-08] (18 pages)
 - OSPFv2 HMAC-SHA Cryptographic Authentication [draft-ietf-ospf-hmac-sha-07] (14 pages)
 - OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type [draft-ietf-ospf-hybrid-bcast-and-p2mp-06] (9 pages)
 - IANA Considerations for OSPF [draft-ietf-ospf-iana-03] (15 pages)
 - Routing for IPv4-Embedded IPv6 Packets [draft-ietf-ospf-ipv4-embedded-ipv6-routing-14] (15 pages)
 - OSPF IPv6 Extensions [draft-ietf-ospf-ipv6-ext-00] (9 pages)
 - Flooding optimizations in link-state routing protocols [draft-ietf-ospf-isis-flood-opt-01] (12 pages)
 - OSPF Graceful Link shutdown [draft-ietf-ospf-link-overload-16] (17 pages)
 - OSPF Link-Local Signaling [draft-ietf-ospf-lls-08] (12 pages)
 - OSPF LLS Extensions for Local Interface ID Advertisement [draft-ietf-ospf-lls-interface-id-01] (6 pages)
 - OSPFv2 LSA Extendibility [draft-ietf-ospf-lsa-extend-00] (14 pages)
 - Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding [draft-ietf-ospf-manet-mdr-05] (71 pages)
 - OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks [draft-ietf-ospf-manet-mpr-04] (31 pages)
 - Extensions to OSPF to Support Mobile Ad Hoc Networking [draft-ietf-ospf-manet-or-03] (41 pages)
 - Use of OSPF-MDR in Single-Hop Broadcast Networks [draft-ietf-ospf-manet-single-hop-mdr-04] (7 pages)
 - Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks [draft-ietf-ospf-manet-single-hop-or-04] (8 pages)
 - OSPF Cryptographic Authentication [draft-ietf-ospf-md5-02] (12 pages)
 - OSPF Version 2 Management Information Base [draft-ietf-ospf-mib-05] (80 pages)
 - OSPF Version 2 Management Information Base [draft-ietf-ospf-mib-update-11] (121 pages)
 - OSPF Multiple Area Links [draft-ietf-ospf-mlinks-03] (19 pages)
 - Signaling Entropy Label Capability and Readable Label-stack Depth Using OSPF [draft-ietf-ospf-mpls-elc-05] (6 pages)
 - OSPF Extensions to Support Maximally Redundant Trees [draft-ietf-ospf-mrt-03] (13 pages)
 - Multi-Topology (MT) Routing in OSPF [draft-ietf-ospf-mt-09] (20 pages)
 - OSPF Version 2 MIB for Multi-Topology (MT) Routing [draft-ietf-ospf-mt-mib-04] (29 pages)
 - Multi-topology routing in OSPFv3 (MT-OSPFv3) [draft-ietf-ospf-mt-ospfv3-03] (26 pages)
 - OSPF Multi-Area Adjacency [draft-ietf-ospf-multi-area-adj-09] (11 pages)
 - OSPFv2 Multi-Instance Extensions [draft-ietf-ospf-multi-instance-09] (9 pages)
 - Advertising Node Administrative Tags in OSPF [draft-ietf-ospf-node-admin-tag-09] (15 pages)
 - The OSPF NSSA Option [draft-ietf-ospf-nssa-option-00] (17 pages)
 - The OSPF Not-So-Stubby Area (NSSA) Option [draft-ietf-ospf-nssa-update-11] (33 pages)
 - OSPF Optimized Multipath (OSPF-OMP) [draft-ietf-ospf-omp-02] (38 pages)
 - OSPF Out-of-band LSDB resynchronization [draft-ietf-ospf-oob-resync-01] (7 pages)
 - The OSPF Opaque LSA Option [draft-ietf-ospf-opaque-05] (15 pages)
 - OSPF Version 2 [draft-ietf-ospf-ospf2-01] (189 pages)
 - OSPF Version 2 Management Information Base [draft-ietf-ospf-ospfmib-04] (42 pages)
 - H-bit Support for OSPFv2 [draft-ietf-ospf-ospfv2-hbit-04] (8 pages)
 - Authentication/Confidentiality for OSPFv3 [draft-ietf-ospf-ospfv3-auth-08] (15 pages)
 - OSPFv3 Autoconfiguration [draft-ietf-ospf-ospfv3-autoconfig-15] (15 pages)
 - OSPFv3 Graceful Restart [draft-ietf-ospf-ospfv3-graceful-restart-08] (7 pages)
 - OSPFv3 Instance ID Registry Update [draft-ietf-ospf-ospfv3-iid-registry-update-04] (4 pages)
 - OSPFv3 LSA Extendibility [draft-ietf-ospf-ospfv3-lsa-extend-23] (34 pages)
 - Management Information Base for OSPFv3 [draft-ietf-ospf-ospfv3-mib-16] (95 pages)
 - OSPFv3 Extensions for Segment Routing [draft-ietf-ospf-ospfv3-segment-routing-extensions-11] (28 pages)
 - OSPF for IPv6 Standardization Report [draft-ietf-ospf-ospfv3-stdreport-00] (7 pages)
 - Traffic Engineering Extensions to OSPF Version 3 [draft-ietf-ospf-ospfv3-traffic-13] (12 pages)
 - OSPF for IPv6 [draft-ietf-ospf-ospfv3-update-23] (94 pages)
 - OSPF for IPv6 [draft-ietf-ospf-ospfv6-08] (80 pages)
 - OSPF Database Overflow [draft-ietf-ospf-overflow-00] (9 pages)
 - OSPF Point-to-MultiPoint Interface [draft-ietf-ospf-pmp-if-00] (6 pages)
 - Flooding over parallel point-to-point links [draft-ietf-ospf-ppp-flood-01] (8 pages)
 - Hiding Transit-Only Networks in OSPF [draft-ietf-ospf-prefix-hiding-07] (13 pages)
 - OSPFv2 Prefix/Link Attribute Advertisement [draft-ietf-ospf-prefix-link-attr-13] (15 pages)
 - Guidelines for Efficient LSA Refreshment in OSPF [draft-ietf-ospf-refresh-guide-01] (11 pages)
 - OSPF Restart Signaling [draft-ietf-ospf-restart-01] (4 pages)
 - The OSPF Opaque LSA Option [draft-ietf-ospf-rfc2370bis-05] (17 pages)
 - OSPF Stub Router Advertisement [draft-ietf-ospf-rfc3137bis-04] (7 pages)
 - Extensions to OSPF for Advertising Optional Router Capabilities [draft-ietf-ospf-rfc4970bis-07] (15 pages)
 - Supporting Authentication Trailer for OSPFv3 [draft-ietf-ospf-rfc6506bis-05] (23 pages)
 - Carrying Routable IP Addresses in OSPF RI LSA [draft-ietf-ospf-routable-ip-address-02] (5 pages)
 - OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators [draft-ietf-ospf-sbfd-discriminator-06] (7 pages)
 - Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance [draft-ietf-ospf-scalability-09] (15 pages)
 - Security Extension for OSPFv2 When Using Manual Key Management [draft-ietf-ospf-security-extension-manual-keying-11] (14 pages)
 - OSPF Extensions for Segment Routing [draft-ietf-ospf-segment-routing-extensions-24] (29 pages)
 - Signaling  MSD (Maximum SID Depth) using OSPF [draft-ietf-ospf-segment-routing-msd-08] (8 pages)
 - OSPF Shortcut ABR Enhanced OSPF ABR Behavior [draft-ietf-ospf-shortcut-abr-02] (19 pages)
 - Yang Data Model for OSPF SR (Segment Routing) Protocol [draft-ietf-ospf-sr-yang-03] (24 pages)
 - OSPF Standardization Report [draft-ietf-ospf-stdreport-03] (9 pages)
 - OSPF Stub Router Advertisement [draft-ietf-ospf-stub-adv-02] (5 pages)
 - Flooding Over a Subset Topology [draft-ietf-ospf-subset-flood-00] (13 pages)
 - OSPFv2 Link Traffic Engineering (TE) Attribute Reuse [draft-ietf-ospf-te-link-attr-reuse-03] (16 pages)
 - OSPF Traffic Engineering (TE) Metric Extensions [draft-ietf-ospf-te-metric-extensions-11] (19 pages)
 - Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions [draft-ietf-ospf-te-node-addr-07] (7 pages)
 - OSPFv3 over IPv4 for IPv6 Transition [draft-ietf-ospf-transition-to-ospfv3-12] (11 pages)
 - OSPF Transport Instance Extensions [draft-ietf-ospf-transport-instance-11] (14 pages)
 - OSPF Version 2 Traps [draft-ietf-ospf-trapmib-02] (13 pages)
 - OSPF Topology-Transparent Zone [draft-ietf-ospf-ttz-06] (27 pages)
 - OSPF Two-Part Metric [draft-ietf-ospf-two-part-metric-10] (9 pages)
 - Proposed modifications to RFC 1247 [draft-ietf-ospf-v2update-00] (8 pages)
 - OSPF Version 2 [draft-ietf-ospf-vers2-02] (244 pages)
 - OSPF Version 2 [draft-ietf-ospf-version2-10] (211 pages)
 - OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunnels [draft-ietf-ospf-xaf-te-01] (8 pages)
 - Yang Data Model for OSPF Protocol [draft-ietf-ospf-yang-09] (105 pages)
 - Traffic Engineering (TE) Extensions to OSPF Version 2 [draft-katz-yeung-ospf-traffic-10] (14 pages)
 - OSPF Database Exchange Summary List Optimization [draft-ogier-ospf-dbex-opt-03] (5 pages)
 - OSPF Refresh and Flooding Reduction in Stable Topologies [draft-pillay-esnault-ospf-flooding-07] (5 pages)

Requests for Comments:
 BCP112: Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance (15 pages)
 BCP130: IANA Considerations for OSPF (15 pages)
 RFC1245: OSPF Protocol Analysis (12 pages)
 RFC1246: Experience with the OSPF Protocol (31 pages)
 RFC1247: OSPF Version 2 (189 pages)
          * Obsoletes RFC1131
          * Obsoletes RFC1583
          * Updates RFC1349
 RFC1252: OSPF Version 2 Management Information Base (42 pages)
          * Obsoletes RFC1248
          * Obsoletes RFC1253
 RFC1586: Guidelines for Running OSPF Over Frame Relay Networks (6 pages)
 RFC1587: The OSPF NSSA Option (17 pages)
          * Obsoletes RFC3101
 RFC1765: OSPF Database Overflow (9 pages)
 RFC1793: Extending OSPF to Support Demand Circuits (32 pages)
          * Updates RFC3883
 RFC1850: OSPF Version 2 Management Information Base (80 pages)
          * Obsoletes RFC1253
          * Obsoletes RFC4750
 RFC2096: IP Forwarding Table MIB (21 pages)
          * Obsoletes RFC1354
          * Obsoletes RFC4292
 RFC2178: OSPF Version 2 (211 pages)
          * Obsoletes RFC1583
          * Obsoletes RFC2328
 RFC2328: OSPF Version 2 (244 pages)
          * Obsoletes RFC2178
          * Updates RFC5709
          * Updates RFC6549
          * Updates RFC6845
          * Updates RFC6860
          * Updates RFC7474
          * Updates RFC8042
 RFC2329: OSPF Standardization Report (9 pages)
 RFC2370: The OSPF Opaque LSA Option (15 pages)
          * Obsoletes RFC5250
          * Updates RFC3630
 RFC2676: QoS Routing Mechanisms and OSPF Extensions (50 pages)
 RFC2740: OSPF for IPv6 (80 pages)
          * Obsoletes RFC5340
 RFC2844: OSPF over ATM and Proxy-PAR (14 pages)
 RFC3101: The OSPF Not-So-Stubby Area (NSSA) Option (33 pages)
          * Obsoletes RFC1587
 RFC3137: OSPF Stub Router Advertisement (5 pages)
          * Obsoletes RFC6987
 RFC3509: Alternative Implementations of OSPF Area Border Routers (12 pages)
 RFC3623: Graceful OSPF Restart (18 pages)
 RFC3630: Traffic Engineering (TE) Extensions to OSPF Version 2 (14 pages)
          * Updates RFC2370
          * Updates RFC4203
          * Updates RFC5786
 RFC3883: Detecting Inactive Neighbors over OSPF Demand Circuits (DC) (6 pages)
          * Updates RFC1793
 RFC4136: OSPF Refresh and Flooding Reduction in Stable Topologies (5 pages)
 RFC4167: Graceful OSPF Restart Implementation Report (6 pages)
 RFC4222: Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance (15 pages)
 RFC4552: Authentication/Confidentiality for OSPFv3 (15 pages)
 RFC4576: Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) (7 pages)
 RFC4750: OSPF Version 2 Management Information Base (121 pages)
          * Obsoletes RFC1850
 RFC4915: Multi-Topology (MT) Routing in OSPF (20 pages)
 RFC4940: IANA Considerations for OSPF (15 pages)
 RFC4970: Extensions to OSPF for Advertising Optional Router Capabilities (13 pages)
          * Obsoletes RFC7770
 RFC5185: OSPF Multi-Area Adjacency (11 pages)
 RFC5187: OSPFv3 Graceful Restart (7 pages)
 RFC5243: OSPF Database Exchange Summary List Optimization (5 pages)
 RFC5250: The OSPF Opaque LSA Option (17 pages)
          * Obsoletes RFC2370
 RFC5329: Traffic Engineering Extensions to OSPF Version 3 (12 pages)
 RFC5340: OSPF for IPv6 (94 pages)
          * Obsoletes RFC2740
          * Updates RFC6845
          * Updates RFC6860
          * Updates RFC7503
 RFC5449: OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks (31 pages)
 RFC5613: OSPF Link-Local Signaling (12 pages)
          * Obsoletes RFC4813
 RFC5614: Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding (71 pages)
          * Updates RFC7038
 RFC5642: Dynamic Hostname Exchange Mechanism for OSPF (8 pages)
 RFC5643: Management Information Base for OSPFv3 (95 pages)
 RFC5709: OSPFv2 HMAC-SHA Cryptographic Authentication (14 pages)
          * Updates RFC2328
          * Updates RFC7474
 RFC5786: Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions (7 pages)
          * Updates RFC3630
          * Updates RFC6827
 RFC5820: Extensions to OSPF to Support Mobile Ad Hoc Networking (41 pages)
          * Updates RFC7137
 RFC5838: Support of Address Families in OSPFv3 (13 pages)
          * Updates RFC6969
          * Updates RFC7949
 RFC6506: Supporting Authentication Trailer for OSPFv3 (20 pages)
          * Obsoletes RFC7166
 RFC6549: OSPFv2 Multi-Instance Extensions (9 pages)
          * Updates RFC2328
 RFC6845: OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type (9 pages)
          * Updates RFC2328
          * Updates RFC5340
 RFC6860: Hiding Transit-Only Networks in OSPF (13 pages)
          * Updates RFC2328
          * Updates RFC5340
 RFC6969: OSPFv3 Instance ID Registry Update (4 pages)
          * Updates RFC5838
 RFC6987: OSPF Stub Router Advertisement (7 pages)
          * Obsoletes RFC3137
 RFC6992: Routing for IPv4-Embedded IPv6 Packets (15 pages)
 RFC7038: Use of OSPF-MDR in Single-Hop Broadcast Networks (7 pages)
          * Updates RFC5614
 RFC7137: Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks (8 pages)
          * Updates RFC5820
 RFC7166: Supporting Authentication Trailer for OSPFv3 (23 pages)
          * Obsoletes RFC6506
 RFC7471: OSPF Traffic Engineering (TE) Metric Extensions (19 pages)
 RFC7474: Security Extension for OSPFv2 When Using Manual Key Management (14 pages)
          * Updates RFC2328
          * Updates RFC5709
 RFC7503: OSPFv3 Autoconfiguration (15 pages)
          * Updates RFC5340
 RFC7684: OSPFv2 Prefix/Link Attribute Advertisement (15 pages)
 RFC7770: Extensions to OSPF for Advertising Optional Router Capabilities (15 pages)
          * Obsoletes RFC4970
 RFC7777: Advertising Node Administrative Tags in OSPF (15 pages)
 RFC7884: OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators (7 pages)
 RFC7949: OSPFv3 over IPv4 for IPv6 Transition (11 pages)
          * Updates RFC5838
 RFC8042: OSPF Two-Part Metric (9 pages)
          * Updates RFC2328
 RFC8099: OSPF Topology-Transparent Zone (27 pages)
 STD54: OSPF Version 2 (244 pages)
          * Obsoletes RFC2178



Path Computation Element (pce)
------------------------------

Charter
Last Modified: 2017-08-22

Current Status: Active

Chairs:
    Jonathan Hardwick <[email protected]>
    Julien Meuric <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Deborah Brungard <[email protected]>

Secretary:
    Dhruv Dhody <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       http://www.ietf.org/mailman/listinfo/pce
    Archive:            https://mailarchive.ietf.org/arch/browse/pce/

Description of Working Group:

 The PCE Working Group is chartered to specify the required protocols
 so as to enable a Path Computation Element (PCE)-based architecture
 for the computation of paths for MPLS and GMPLS Point to Point and
 Point to Multi-point Traffic Engineered LSPs.

 In this architecture path computation does not necessarily occur on
 the head-end (ingress) LSR, but on some other path computation entity
 that may not be physically located on each head-end LSR. The TEAS
 Working Group is responsible for defining and extending architectures
 for Traffic Engineering (TE) and it is expected that the PCE and TEAS
 WGs will work closely together on elements of TE architectures that
 utilize PCE.

 The PCE WG works on the application of this model within a single
 domain or within a group of domains (where a domain is a layer, IGP
 area or Autonomous System with limited visibility from the head-end
 LSR). At this time, applying this model to large groups of domains such
 as the Internet is not thought to be possible, and the PCE WG will not
 spend energy on that topic.

 The WG specifies the PCE communication Protocol (PCEP) and needed
 extensions for communication between Path Computation Clients (PCCs)
 and PCEs, and between cooperating PCEs. Security mechanisms such as
 authentication and confidentiality are included.

 The WG determines requirements for extensions to existing routing and
 signaling protocols in support of the PCE architecture and the
 signaling of inter-domain paths (e.g., RSVP-TE and its GMPLS
 variations). Any necessary extensions will be produced in
 collaboration with the Working Groups responsible for the protocols.

 The WG also works on the mechanisms to for multi-layer path
 computation and PCEP extensions for communication between several
 network layers.

 The WG defines the required PCEP extensions for Wavelength Switched
 Optical Networks (WSON) while keeping consistency with the GMPLS
 protocols specified in the CCAMP and TEAS WGs.

 Work Items:

 - PCEP extensions to support MPLS and GMPLS Traffic Engineered LSP
   path computation models involving PCEs. This includes the case of
   computing the paths of intra- and inter-domain TE LSPs. Such path
   computation includes the generation of primary, protection and
   recovery paths, as well as computations for (local/global)
   reoptimization and load balancing. Both intra- and inter-domain
   applications are covered.

 - In cooperation with the TEAS Working Group, development of PCE-
   based architectures for Traffic Engineering.

 - In cooperation with protocol specific Working Group (e.g., MPLS,
   CCAMP), development of LSP signaling (RSVP-TE) extensions required
   to support PCE-based path computation models.

 - Specification of PCEP extensions for expressing path computation
   requests and responses in the various GMPLS-controlled networks,
   including WSON.

 - Definition of PCEP extensions for path computation in multi-layer
   networks.

 - Definition of the PCEP extensions used by a stateful PCE for
   recommending a new path for an existing or new LSP to the PCC/PCE.
   Further protocol extensions must cover the case where receiving
   PCC/PCE chooses to not follow the recommendation.


Goals and Milestones:
 Done     - Submit first draft of PCE architecture document
 Done     - Submit first draft of PCE discovery requirements and protocol extensions documents
 Done     - Submit first draft of the PCE communication protocol requirements
 Done     - Submit first draft of the definition of objective metrics
 Done     - Submit first draft of the PCE communication protocol specification
 Done     - Submit PCE architecture specification to the IESG to be considered as Informational RFC
 Done     - Submit first draft of the MIB module for the PCE protocol
 Done     - Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC
 Done     - Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard
 Done     - Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard
 Done     - Submit first draft of the PCE P2MP communication requirements
 Done     - Submit first draft of the PCE P2MP PCEP protocol extensions
 Done     - Submit PCE P2MP communication requirements to the IESG to be considered as an Informational RFC
 Done     - Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC
 Done     - Submit applicability and metrics documents to the IESG
 Done     - Submit the GMPLS requirements to the IESG to be considered as an Informational RFC
 Sep 2013 - Submit inter-area/AS applicability statement to the IESG as an informational RFC
 Sep 2013 - Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard
 Nov 2013 - Submit inter-layer extensions to the IESG to be considered as a Proposed Standard
 Nov 2013 - Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard
 Done     - Submit the PCEP MIB to the IESG to be considered as a Proposed Standard
 Apr 2014 - Submit the discovery MIB to the IESG to be considered as a Proposed Standard
 Apr 2014 - Submit P2MP MIB to the IESG to be considered as a Proposed Standard
 Sep 2014 - Submit the stateful PCE document(s) to the IESG
 Feb 2015 - Evaluate WG progress, recharter or close

Internet-Drafts:
 - Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup [draft-ali-pce-remote-initiated-gmpls-lsp-03] (9 pages)
 - Experimental Codepoint Allocation for Path Computation Element communication Protocol (PCEP) [draft-dhody-pce-pcep-exp-codepoints-03] (6 pages)
 - PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE [draft-dhody-pce-stateful-pce-auto-bandwidth-09] (25 pages)
 - Conveying Vendor-Specific Constraints in the Path Computation Element communication Protocol [draft-farrel-pce-rfc7150bis-01] (12 pages)
 - Unanswered Questions in the Path Computation Element Architecture [draft-farrkingel-pce-questions-03] (25 pages)
 - Applicability of Path Computation Element (PCE) for Abstraction and Control of TE Networks (ACTN) [draft-ietf-pce-applicability-actn-02] (18 pages)
 - A Path Computation Element (PCE)-Based Architecture [draft-ietf-pce-architecture-05] (40 pages)
 - Path Computation Element communication Protocol extension for signaling LSP diversity constraint [draft-ietf-pce-association-diversity-02] (17 pages)
 - PCEP Extensions for Establishing Relationships Between Sets of LSPs [draft-ietf-pce-association-group-04] (21 pages)
 - Path Computation Element communication Protocol extension for associating Policies and LSPs [draft-ietf-pce-association-policy-01] (11 pages)
 - A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths [draft-ietf-pce-brpc-09] (18 pages)
 - Path Computation Element (PCE) Communication Protocol Generic Requirements [draft-ietf-pce-comm-protocol-gen-reqs-07] (21 pages)
 - Definitions of Managed Objects for Path Computation Element Discovery [draft-ietf-pce-disc-mib-04] (24 pages)
 - IGP protocol extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-igp-02] (37 pages)
 - IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-isis-08] (17 pages)
 - OSPF Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-ospf-08] (20 pages)
 - Requirements for Path Computation Element (PCE) Discovery [draft-ietf-pce-discovery-reqs-05] (19 pages)
 - Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol [draft-ietf-pce-dste-02] (9 pages)
 - Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization [draft-ietf-pce-global-concurrent-optimization-10] (26 pages)
 - Requirements for GMPLS Applications of PCE [draft-ietf-pce-gmpls-aps-req-09] (12 pages)
 - PCEP extensions for GMPLS [draft-ietf-pce-gmpls-pcep-extensions-11] (38 pages)
 - Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE) [draft-ietf-pce-hierarchy-extensions-03] (25 pages)
 - The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS [draft-ietf-pce-hierarchy-fwk-05] (33 pages)
 - Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-area-as-applicability-06] (26 pages)
 - Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-layer-ext-12] (22 pages)
 - Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-layer-frwk-10] (34 pages)
 - PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering [draft-ietf-pce-inter-layer-req-15] (12 pages)
 - Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) [draft-ietf-pce-interas-pcecp-reqs-06] (14 pages)
 - Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-iro-update-07] (5 pages)
 - Conveying path setup type in PCEP messages [draft-ietf-pce-lsp-setup-type-08] (10 pages)
 - Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts [draft-ietf-pce-manageability-requirements-11] (13 pages)
 - A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture [draft-ietf-pce-monitoring-09] (26 pages)
 - Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-of-06] (23 pages)
 - Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) [draft-ietf-pce-p2mp-app-02] (15 pages)
 - Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE [draft-ietf-pce-p2mp-req-05] (11 pages)
 - Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism [draft-ietf-pce-path-key-06] (19 pages)
 - Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model [draft-ietf-pce-pce-initiated-lsp-11] (20 pages)
 - Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering [draft-ietf-pce-pcecp-interarea-reqs-05] (12 pages)
 - Path Computation Element (PCE) Communication Protocol (PCEP) [draft-ietf-pce-pcep-19] (87 pages)
 - Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-pcep-domain-sequence-12] (35 pages)
 - Experimental Codepoint Allocation for the Path Computation Element communication Protocol (PCEP) [draft-ietf-pce-pcep-exp-codepoints-05] (8 pages)
 - PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths [draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08] (25 pages)
 - Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module [draft-ietf-pce-pcep-mib-11] (65 pages)
 - Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-ietf-pce-pcep-p2mp-extensions-11] (33 pages)
 - Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) [draft-ietf-pce-pcep-service-aware-13] (31 pages)
 - Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks [draft-ietf-pce-pcep-stateful-pce-gmpls-06] (13 pages)
 - Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations [draft-ietf-pce-pcep-svec-list-05] (18 pages)
 - Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions [draft-ietf-pce-pcep-xro-06] (16 pages)
 - A YANG Data Model for Path Computation Element Communications Protocol (PCEP) [draft-ietf-pce-pcep-yang-06] (108 pages)
 - PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-pceps-18] (26 pages)
 - Policy-Enabled Path Computation Framework [draft-ietf-pce-policy-enabled-path-comp-04] (36 pages)
 - Unanswered Questions in the Path Computation Element Architecture [draft-ietf-pce-questions-08] (29 pages)
 - Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup [draft-ietf-pce-remote-initiated-gmpls-lsp-04] (9 pages)
 - Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-ietf-pce-rfc6006bis-04] (43 pages)
 - Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol [draft-ietf-pce-rfc7150bis-01] (14 pages)
 - PCEP Extensions for Segment Routing [draft-ietf-pce-segment-routing-11] (22 pages)
 - Hierarchical Stateful Path Computation Element (PCE). [draft-ietf-pce-stateful-hpce-02] (19 pages)
 - Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE [draft-ietf-pce-stateful-pce-21] (57 pages)
 - Applicability of a Stateful Path Computation Element (PCE) [draft-ietf-pce-stateful-pce-app-08] (24 pages)
 - PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE [draft-ietf-pce-stateful-pce-auto-bandwidth-06] (31 pages)
 - Cooperative Stateful Path Computation Element (PCE) for Inter-Domain Inter-Vendor PCE-initiated LSP Setup [draft-ietf-pce-stateful-pce-inter-domain-lsp-00] (12 pages)
 - PCEP Extensions for LSP scheduling with stateful PCE [draft-ietf-pce-stateful-pce-lsp-scheduling-01] (23 pages)
 - Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-ietf-pce-stateful-pce-p2mp-05] (32 pages)
 - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE [draft-ietf-pce-stateful-sync-optimizations-10] (26 pages)
 - Definitions of Textual Conventions for Path Computation Element [draft-ietf-pce-tc-mib-05] (6 pages)
 - Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol [draft-ietf-pce-vendor-constraints-11] (12 pages)
 - PCC-PCE Communication Requirements for VPNs [draft-ietf-pce-vpn-req-02] (16 pages)
 - Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment [draft-ietf-pce-wson-routing-wavelength-15] (12 pages)
 - PCEP Extension for WSON Routing and Wavelength Assignment [draft-ietf-pce-wson-rwa-ext-07] (25 pages)
 - Secure Transport for PCEP [draft-lopez-pce-pceps-02] (12 pages)
 - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE [draft-minei-pce-stateful-sync-optimizations-02] (19 pages)
 - Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-palle-pce-stateful-pce-p2mp-09] (32 pages)

Requests for Comments:
 RFC4655: A Path Computation Element (PCE)-Based Architecture (40 pages)
 RFC4657: Path Computation Element (PCE) Communication Protocol Generic Requirements (21 pages)
 RFC4674: Requirements for Path Computation Element (PCE) Discovery (19 pages)
 RFC4927: Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering (12 pages)
 RFC5088: OSPF Protocol Extensions for Path Computation Element (PCE) Discovery (20 pages)
 RFC5089: IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery (17 pages)
 RFC5376: Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) (14 pages)
 RFC5394: Policy-Enabled Path Computation Framework (36 pages)
 RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP) (87 pages)
          * Updates RFC7896
          * Updates RFC8253
 RFC5441: A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths (18 pages)
 RFC5455: Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol (9 pages)
 RFC5520: Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism (19 pages)
 RFC5521: Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions (16 pages)
 RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) (23 pages)
 RFC5557: Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization (26 pages)
 RFC5623: Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (34 pages)
 RFC5671: Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) (15 pages)
 RFC5862: Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE (11 pages)
 RFC5886: A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture (26 pages)
 RFC6006: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (33 pages)
          * Obsoletes RFC8306
 RFC6007: Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations (18 pages)
 RFC6123: Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts (13 pages)
 RFC6457: PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering (12 pages)
 RFC6805: The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS (33 pages)
 RFC7025: Requirements for GMPLS Applications of PCE (12 pages)
 RFC7150: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol (12 pages)
          * Obsoletes RFC7470
 RFC7334: PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths (25 pages)
 RFC7399: Unanswered Questions in the Path Computation Element Architecture (29 pages)
 RFC7420: Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module (65 pages)
 RFC7449: Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (12 pages)
 RFC7470: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol (14 pages)
          * Obsoletes RFC7150
 RFC7896: Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) (5 pages)
          * Updates RFC5440
 RFC7897: Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) (35 pages)
 RFC8051: Applicability of a Stateful Path Computation Element (PCE) (24 pages)
 RFC8231: Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE (57 pages)
 RFC8232: Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE (26 pages)
 RFC8233: Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) (31 pages)
 RFC8253: PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) (26 pages)
          * Updates RFC5440
 RFC8281: Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model (20 pages)
 RFC8282: Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering (22 pages)
 RFC8306: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (43 pages)
          * Obsoletes RFC6006



Protocols for IP Multicast (pim)
--------------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Mike McBride <[email protected]>
    Stig Venaas <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alvaro Retana <[email protected]>

Tech Advisor:
    Brian Haberman <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/pim/
    Archive:            https://mailarchive.ietf.org/arch/browse/pim/

Description of Working Group:

 The Protocols for IP Multicast (PIM) working group, is chartered to work on multiple IP multicast protocols.  The Working Group is responsible for the maintenance of PIM, IGMP, and MLD.

 The Working Group will work on the following specific items:

 1) Management:  YANG models for PIM, IGMP, and MLD will be developed, for both configuration and operational states.  If updates to existing MIB modules are necessary, the WG may work on those.

 2) Improve PIM authentication.

 3) Improve and Extend PIM Join Attributes to support different types of multicast applications.

 4) Optimization approaches for IGMP and MLD to adapt to link conditions in wireless and mobile networks and be more robust to packet loss.

 Additional work items may be added with a recharter.

 The WG should discuss and develop new ideas related to multicast protocols and distribution of multicast related information.

 The WG is expected to use its extensive multicast knowledge to actively review and participate in WG Last Calls with multicast work that occurs in other WGs, such as MBONED, LISP, MPLS, BESS, ROLL, and BIER. The WG should investigate any extensions needed to support other work and, if additional work is required, the WG may be rechartered to accomplish the specific extensions.

Goals and Milestones:
 Nov 2015 - igmp yang model submitted to iesg
 Nov 2015 - mld yang model submitted to iesg
 Nov 2015 - Resubmit explicit-rpf-vector draft to IESG
 Nov 2015 - Submit PIM Join Attributes for LISP Environments to IESG
 Apr 2016 - submit solutions for IGMP and MLD to adapt to wireless link conditions
 Apr 2016 - pim sm yang model submitted to iesg
 Jul 2016 - pim ssm yang model submitted to iesg
 Jul 2016 - Adopt a draft which provides improvements to pim authentication

Internet-Drafts:
 - Anycast-RP Using Protocol Independent Multicast (PIM) [draft-ietf-pim-anycast-rp-07] (12 pages)
 - Bidirectional Protocol Independent Multicast (BIDIR-PIM) [draft-ietf-pim-bidir-09] (43 pages)
 - Protocol Independent Multicast (PIM) Bootstrap Router MIB [draft-ietf-pim-bsr-mib-06] (23 pages)
 - Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) [draft-ietf-pim-dm-new-v2-05] (61 pages)
 - PIM DR Improvement [draft-ietf-pim-dr-improvement-04] (11 pages)
 - PIM Designated Router Load Balancing [draft-ietf-pim-drlb-07] (18 pages)
 - Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect [draft-ietf-pim-ecmp-05] (12 pages)
 - Explicit Reverse Path Forwarding (RPF) Vector [draft-ietf-pim-explicit-rpf-vector-09] (9 pages)
 - IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers [draft-ietf-pim-explicit-tracking-13] (11 pages)
 - PIM Group-to-Rendezvous-Point Mapping [draft-ietf-pim-group-rp-mapping-10] (11 pages)
 - PIM Neighbor Hello GenId Option [draft-ietf-pim-hello-genid-01] (3 pages)
 - An Interface Identifier (ID) Hello Option for PIM [draft-ietf-pim-hello-intid-01] (6 pages)
 - Hierarchical Join/Prune Attributes [draft-ietf-pim-hierarchicaljoinattr-08] (8 pages)
 - IGMP/MLD Optimizations in Wireless and Mobile Networks [draft-ietf-pim-igmp-mld-wireless-mobile-00] (13 pages)
 - A YANG data model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) [draft-ietf-pim-igmp-mld-yang-06] (35 pages)
 - Use of PIM Address List Hello across address families [draft-ietf-pim-ipv4-prefix-over-ipv6-nh-01] (5 pages)
 - Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6) [draft-ietf-pim-ipv6-04] (5 pages)
 - The Protocol Independent Multicast (PIM) Join Attribute Format [draft-ietf-pim-join-attributes-06] (10 pages)
 - PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments [draft-ietf-pim-join-attributes-for-lisp-06] (9 pages)
 - Host Threats to Protocol Independent Multicast (PIM) [draft-ietf-pim-lasthop-threats-04] (12 pages)
 - Protocol Independent Multicast MIB [draft-ietf-pim-mib-v2-10] (90 pages)
 - MSDP YANG Model [draft-ietf-pim-msdp-yang-01] (22 pages)
 - PIM Multi-Topology ID (MT-ID) Join Attribute [draft-ietf-pim-mtid-10] (13 pages)
 - Requirements for the extension of the IGMP/MLD proxy functionality to support multiple upstream interfaces [draft-ietf-pim-multiple-upstreams-reqs-06] (13 pages)
 - Population Count Extensions to Protocol Independent Multicast (PIM) [draft-ietf-pim-pop-count-07] (15 pages)
 - A Reliable Transport Mechanism for PIM [draft-ietf-pim-port-09] (29 pages)
 - Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis [draft-ietf-pim-proposed-req-02] (8 pages)
 - Format for using PIM proxies [draft-ietf-pim-proxy-00] (7 pages)
 - State Refresh in PIM-DM [draft-ietf-pim-refresh-02] (10 pages)
 - A Registry for PIM Message Types [draft-ietf-pim-registry-04] (4 pages)
 - Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments [draft-ietf-pim-rfc4601-update-survey-report-03] (12 pages)
 - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-rfc4601bis-06] (137 pages)
 - The Reverse Path Forwarding (RPF) Vector TLV [draft-ietf-pim-rpf-vector-08] (8 pages)
 - Simple Key Management Protocol for PIM [draft-ietf-pim-simplekmp-02] (8 pages)
 - Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) [draft-ietf-pim-sm-bsr-12] (42 pages)
 - Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages [draft-ietf-pim-sm-linklocal-10] (21 pages)
 - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-sm-v2-new-12] (150 pages)
 - PIM Flooding Mechanism and Source Discovery [draft-ietf-pim-source-discovery-bsr-12] (18 pages)
 - Authenticating PIM version 2 messages [draft-ietf-pim-v2-auth-01] (4 pages)
 - Protocol Independent Multicast Version 2 Dense Mode Specification [draft-ietf-pim-v2-dm-03] (18 pages)
 - Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification [draft-ietf-pim-v2-sm-01] (65 pages)
 - A YANG data model for Protocol-Independent Multicast (PIM) [draft-ietf-pim-yang-13] (72 pages)

Requests for Comments:
 RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (61 pages)
 RFC4601: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (150 pages)
          * Obsoletes RFC2362
          * Updates RFC5059
          * Updates RFC5796
          * Updates RFC6226
          * Obsoletes RFC7761
 RFC4602: Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis (8 pages)
 RFC4610: Anycast-RP Using Protocol Independent Multicast (PIM) (12 pages)
 RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM) (43 pages)
 RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) (42 pages)
          * Obsoletes RFC2362
          * Updates RFC4601
 RFC5060: Protocol Independent Multicast MIB (90 pages)
 RFC5240: Protocol Independent Multicast (PIM) Bootstrap Router MIB (23 pages)
 RFC5294: Host Threats to Protocol Independent Multicast (PIM) (12 pages)
 RFC5384: The Protocol Independent Multicast (PIM) Join Attribute Format (10 pages)
          * Updates RFC7887
 RFC5496: The Reverse Path Forwarding (RPF) Vector TLV (8 pages)
 RFC5796: Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages (21 pages)
          * Updates RFC4601
 RFC6166: A Registry for PIM Message Types (4 pages)
 RFC6226: PIM Group-to-Rendezvous-Point Mapping (11 pages)
          * Updates RFC4601
 RFC6395: An Interface Identifier (ID) Hello Option for PIM (6 pages)
 RFC6420: PIM Multi-Topology ID (MT-ID) Join Attribute (13 pages)
 RFC6559: A Reliable Transport Mechanism for PIM (29 pages)
 RFC6754: Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect (12 pages)
 RFC6807: Population Count Extensions to Protocol Independent Multicast (PIM) (15 pages)
 RFC7063: Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments (12 pages)
 RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (137 pages)
          * Obsoletes RFC4601
 RFC7887: Hierarchical Join/Prune Attributes (8 pages)
          * Updates RFC5384
 RFC7891: Explicit Reverse Path Forwarding (RPF) Vector (9 pages)
 RFC8059: PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments (9 pages)
 STD83: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (137 pages)
          * Obsoletes RFC4601



Pseudowire And LDP-enabled Services (pals)
------------------------------------------

Charter
Last Modified: 2015-10-07

Current Status: Active

Chairs:
    Andrew G. Malis <[email protected]>
    Stewart Bryant <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Deborah Brungard <[email protected]>

Secretary:
    David Sinicrope <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/pals
    Archive:            https://mailarchive.ietf.org/arch/browse/pals/

Description of Working Group:

 Many services that run in the Internet are facilitated in MPLS networks
 by the Label Distribution Protocol (LDP) and/or are established over
 pseudowires that emulate point-to-point or point-to-multipoint links and
 provide communication connectivity that is perceived by its users as an
 unshared link or circuit of an emulated Layer-1, Layer-2, or Layer-3
 service type.

 Layer-2 Virtual Private Networks (L2VPNs) are one such service that
 provides an emulation of a "native" service over a packet switched
 network that is adequately faithful to, but may not be entirely
 indistinguishable from, the native service itself.

 The Pseudowire And LDP-enabled Services (PALS) working group is
 chartered to define, specify, and extend network services based on
 pseudowires and/or signaled using LDP.

 In particular, the working group will work on the following services:

 - All types of MPLS-based and L2TPv3-based pseudowire services
   including point-to-point and point-to-multipoint pseudowires, single
   segment and multi-segment pseudowires, single and multi-domain
   pseudowires, and signaled and statically provisioned pseudowires.

 - All types of dynamic or static provider-provisioned L2VPNs that
   operate over pseudowires or that are enabled over MPLS networks
   using LDP as a control plane mechanism.

 - IP-only L2VPN solutions (for IP-only services over a packet switched
   network).

 The working group may also suggest new services to be supported by LDP
 or pseudowires and these may be added to the working group charter
 subject to re-chartering. The working group is also responsible for the
 maintenance and development of pseudowires formerly carried out by the
 PWE3 working group

 The PALS working group will not define any mechanisms that exert control
 over the underlying packet switched network. When necessary it may,
 however, recommend or require the use of existing QoS and path control
 mechanisms between the edge nodes that provide the connectivity to the
 services.

 The working group may work on:

 - New pseudowire encapsulations or types for services emulated over
   IETF-specified Packet Switched Networks.

 - Operations, Administration, and Management (OAM) for pseudowires
   including interworking of OAM for pseudowires and native services, and
   OAM for other services worked on by PALS (including L2VPNs). But new
   techniques should be shared with the BFD and MPLS working groups to
   ensure consistency with existing OAM techniques, and with the LIME
   working group to provide for consistency of operation.

 - Protocol extensions for LDP in support of new pseudowire function
   and new services, but all protocol extensions must be reviewed by the
   MPLS working group which is responsible for the consistency and
   stability of LDP.

 - Mechanisms to enhance pseudowire and L2VPN functionality by
   including security, protection and restoration, congestion avoidance,
   and load balancing across parallel packet switched tunnels.

 - Mechanisms to permit optimization of multicast data traffic within an
   L2VPN.

 - Enhancements to increase the scalability of the control plane and data
   plane of L2VPN solutions and application of L2VPN solutions in the
   data center, the latter in coordination with the NVO3 working group

 - L2VPN discovery and membership mechanisms that utilize pseudowire
   control and management procedures.

 - Data models for modeling, managing, and operating the services worked
   on by the PALS working group using SMI or YANG.

 The PALS working group will not work on L2VPNs enabled using BGP, and
 where L2VPNs that are within the scope of the PALS working group use
 BGP to add functionality (for example for discovery of membership of a
 VPN) this work will be coordinated with the BESS working group. This
 also includes work on particular types of L2VPNs that support both LDP
 and BGP signaling, such as VPLS. Any contention between these working
 groups on the placement of such work will be resolved by the chairs.

 The PALS working group will coordinate closely with the MPLS working
 group for all work involving LDP and the MPLS data plane. It will also
 coordinate with the MPLS working group in developing shared security,
 and with the BFD and MPLS working groups on OAM solutions.

 Where extensions to pseudowires are needed to support time or frequency
 transfer, this work will be done by the PALS working group in
 consultation with the TICTOC working group.

 L2TP specifics of L2TPv3-based pseudowires will continue to be the
 responsibility of the L2TPEXT working group.



Goals and Milestones:
 Done     - Submit PW Congestion Considerations to the IESG
 Done     - Submit STP Application of ICCP to the IESG
 Done     - Submit Pseudowire Redundancy on S-PE to the IESG
 Done     - Submit Unified Control Channel for PWs to the IESG
 Done     - Submit MAC Address Withdrawal over Static Pseudowire to the IESG
 Done     - Submit S-PE resilience for statically provisioned MS-PWs to the IESG
 Mar 2016 - Submit MPLS-TP PW OAM Configuration to the IESG
 Mar 2016 - Submit LDP extensions for PW Binding to LSP Tunnels to the IESG
 Jun 2016 - Submit PW Endpoint Fast Failure Protection to the IESG
 Jun 2016 - Submit LDP-VPLS for Ethernet Broadcast and Multicast to the IESG
 Jun 2016 - Submit P2MP PW Signaling (root initiated) to the IESG
 Jun 2016 - Submit MPLS LSP PW status refresh reduction for Static PWs to the IESG
 Jun 2016 - Submit PIM Snooping over VPLS to the IESG
 Jun 2016 - Submit E-Tree Support in VPLS to the IESG jointly with the BESS WG
 Jun 2017 - Submit L2VPN applicability statement for data center applications to the IESG
 Jun 2017 - Submit YANG data model for SS-PWs and MS-PWs to the IESG

Internet-Drafts:
 - Use of Ethernet Control Word RECOMMENDED [draft-bryant-pals-ethernet-cw-01] (8 pages)
 - Seamless BFD for VCCV [draft-gp-pals-seamless-vccv-01] (10 pages)
 - Extension to LDP-VPLS for Ethernet Broadcast and Multicast [draft-ietf-l2vpn-ldp-vpls-broadcast-exten-08] (19 pages)
 - MAC Address Withdrawal over Static Pseudowire [draft-ietf-l2vpn-mpls-tp-mac-wd-00] (8 pages)
 - Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) [draft-ietf-l2vpn-vpls-pe-etree-11] (26 pages)
 - Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) [draft-ietf-l2vpn-vpls-pim-snooping-07] (39 pages)
 - OAM Procedures for VPWS Interworking [draft-ietf-l2vpn-vpws-iw-oam-04] (13 pages)
 - Pseudowire Congestion Considerations [draft-ietf-pals-congcons-02] (27 pages)
 - Pseudowire (PW) Endpoint Fast Failure Protection [draft-ietf-pals-endpoint-fast-protection-05] (43 pages)
 - Use of Ethernet Control Word RECOMMENDED [draft-ietf-pals-ethernet-cw-00] (8 pages)
 - Extension to LDP-VPLS for Ethernet Broadcast and Multicast [draft-ietf-pals-ldp-vpls-broadcast-exten-01] (19 pages)
 - Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS [draft-ietf-pals-mc-pon-05] (16 pages)
 - Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection [draft-ietf-pals-mpls-tp-dual-homing-coordination-06] (17 pages)
 - Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires [draft-ietf-pals-mpls-tp-dual-homing-protection-06] (11 pages)
 - Media Access Control (MAC) Address Withdrawal over Static Pseudowire [draft-ietf-pals-mpls-tp-mac-wd-03] (10 pages)
 - LDP Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pals-mpls-tp-oam-config-03] (30 pages)
 - LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels [draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-09] (16 pages)
 - Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires [draft-ietf-pals-ms-pw-protection-04] (9 pages)
 - Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP [draft-ietf-pals-p2mp-pw-04] (17 pages)
 - Definition of P2MP PW TLV for LSP-Ping Mechanisms [draft-ietf-pals-p2mp-pw-lsp-ping-05] (9 pages)
 - Pseudowire Redundancy on the Switching Provider Edge (S-PE) [draft-ietf-pals-redundancy-spe-03] (9 pages)
 - Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) [draft-ietf-pals-rfc4447bis-05] (35 pages)
 - Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) [draft-ietf-pals-seamless-vccv-03] (11 pages)
 - MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs [draft-ietf-pals-status-reduction-05] (20 pages)
 - Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator [draft-ietf-pals-vccv-for-gal-06] (9 pages)
 - Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) [draft-ietf-pals-vpls-pim-snooping-06] (43 pages)
 - Pseudowire Congestion Considerations [draft-ietf-pwe3-congcons-02] (22 pages)
 - PW Endpoint Fast Failure Protection [draft-ietf-pwe3-endpoint-fast-protection-02] (29 pages)
 - Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) [draft-ietf-pwe3-iccp-stp-05] (25 pages)
 - Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pwe3-mpls-tp-oam-config-01] (23 pages)
 - LDP extensions for Pseudowire Binding to LSP Tunnels [draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-03] (15 pages)
 - Pseudowire Redundancy on S-PE [draft-ietf-pwe3-redundancy-spe-03] (8 pages)
 - Pseudowire Setup and Maintenance using the Label Distribution Protocol [draft-ietf-pwe3-rfc4447bis-03] (32 pages)
 - A Unified Control Channel for Pseudowires [draft-ietf-pwe3-vccv-for-gal-02] (9 pages)
 - Definition of P2MP PW TLV for LSP-Ping Mechanisms [draft-jain-pwe3-p2mp-pw-lsp-ping-03] (8 pages)

Requests for Comments:
 RFC7708: Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator (9 pages)
 RFC7727: Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) (25 pages)
 RFC7769: Media Access Control (MAC) Address Withdrawal over Static Pseudowire (10 pages)
 RFC7771: Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires (9 pages)
          * Updates RFC6870
 RFC7795: Pseudowire Redundancy on the Switching Provider Edge (S-PE) (9 pages)
 RFC7796: Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) (26 pages)
 RFC7885: Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) (11 pages)
          * Updates RFC5885
 RFC7893: Pseudowire Congestion Considerations (27 pages)
 RFC7965: LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels (16 pages)
 RFC8024: Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS (16 pages)
 RFC8077: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (35 pages)
          * Obsoletes RFC4447
          * Obsoletes RFC6723
 RFC8104: Pseudowire (PW) Endpoint Fast Failure Protection (43 pages)
 RFC8184: Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires (11 pages)
 RFC8185: Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection (17 pages)
 RFC8220: Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) (43 pages)
 RFC8237: MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs (20 pages)
 STD84: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (35 pages)
          * Obsoletes RFC4447
          * Obsoletes RFC6723



Routing Area Working Group (rtgwg)
----------------------------------

Charter
Last Modified: 2017-11-02

Current Status: Active

Chairs:
    Chris Bowers <[email protected]>
    Jeff Tantsura <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alia Atlas <[email protected]>

Secretary:
    Yingzhen Qu <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/rtgwg
    Archive:            https://mailarchive.ietf.org/arch/browse/rtgwg/

Description of Working Group:

 The Routing Area working group (RTGWG) is chartered to provide a
 venue to discuss, evaluate, support and develop proposals for
 new work in the Routing Area and may work on specific small topics
 that do not fit with an existing working group.

 Options for handling new work include:

 - Directing the work to an existing WG (including RTGWG)
 - Developing a proposal for a BoF.
 - Developing a charter and establishing consensus for a new WG.  This
 option will primarily be used with fairly mature and/or well-defined efforts.
 - Careful evaluation, leading to deferring or rejecting work.

 It is expected that the proposals for new work will only include items which
 are not aligned with the work of other WGs or that may span multiple WGs.
 The Area Directors and WG Chairs can provide guidance if there is any
 doubt whether a topic should be discussed in RTGWG.

 A major objective of the RTGWG is to provide timely, clear
 dispositions of new efforts. Where there is consensus to take
 on new work, the WG will strive to quickly find a home for it.
 Reconsideration of proposals which have failed to gather consensus
 will be prioritized behind proposals for new work which have not
 yet been considered. In general, requests for reconsideration
 should only be made once a proposal has been significantly
 revised.

 If RTGWG decides that a particular topic should be addressed by
 a new WG, the chairs will recommend the work to the Routing ADs
 with a summary of the evaluation.  The Routing ADs may then choose
 to follow the normal IETF chartering process (potential BoF, IETF-wide
 review of the proposed charter, etc.).

 Guiding principles for evaluation of new work by RTGWG will include:

    1. Providing a clear problem statement for proposed new work.

    2. Prioritizing new efforts to manage the trade-offs between urgency,
        interest, and available resources in the Routing Area.

    3. Looking for commonalities among ongoing efforts.
        Such commonalities may indicate the need to develop more
        general, reusable solutions.

    4. Ensuring appropriate cross-WG and cross-area review.

    5. Protecting the architectural integrity of the protocols developed
        in the Routing Area and ensuring that work has significant applicability.

 RTGWG may also work on specific small topics that do not fit with an existing working group. An example of a small topic is a draft that might otherwise be AD-sponsored but which could benefit from the review and consensus that RTGWG can provide.

 RTGWG may work on larger topics, but must be explicitly rechartered to add the topic.  The specific larger topics that RTGWG is currently chartered to work on:

   * Enhancements to hop-by-hop distributed
     routing (e.g., multicast, LDP-MPLS, unicast routing) related to
     fast-reroute and loop-free convergence. A specific goal of
     fast-reroute mechanisms is to provide up to complete coverage when
     the potential failure would not partition the network. All work in
     this area should be specifically evaluated by the WG in terms of
     practicality and applicability to deployed networks.

   * Routing-related YANG models that are not appropriate for other RTG working
     groups.

 The working group milestones will be updated as needed to reflect the
 proposals currently being worked on and the target dates for their
 completion.

Goals and Milestones:
 Nov 2014 - Submit Remote LFA (link protection) for publication as Proposed Standard
 Mar 2015 - Submit Composite-Link Requirements to IESG for publication as Informational
 Mar 2015 - Submit initial Internet Draft on Multicast IP Fast Reroute Architecture
 Mar 2015 - Submit Composite-Link Framework to IESG for publication as Informational
 Jul 2015 - Submit specification on Advanced IP Fast Reroute mechanism to IESG for publication as Proposed Standard
 Jul 2015 - Submit Document on Operational Experience of using BGP in a Data Center for publication as Informational
 Jul 2015 - Submit Operational Management for LFA for publication as Proposed Standard
 Jul 2015 - Submit Remote LFA (node protection) for publication as Proposed Standard
 Nov 2015 - Submit MIB for IP Fast-Reroute for publication as Proposed Standard

Internet-Drafts:
 - Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution [draft-bowbakova-rtgwg-enterprise-pa-multihoming-01] (45 pages)
 - Routing Timer Parameter Synchronization [draft-bryant-rtgwg-param-sync-03] (10 pages)
 - Calculating IGP routes over Traffic Engineering tunnels [draft-hsmit-mpls-igp-spf-01] (6 pages)
 - SPF Back-off algorithm for link state IGPs [draft-ietf-rtgwg-backoff-algo-07] (13 pages)
 - BGP Prefix Independent Convergence [draft-ietf-rtgwg-bgp-pic-06] (30 pages)
 - Use of BGP for Routing in Large-Scale Data Centers [draft-ietf-rtgwg-bgp-routing-large-dc-11] (35 pages)
 - Advanced Multipath Framework in MPLS [draft-ietf-rtgwg-cl-framework-04] (43 pages)
 - Requirements for Advanced Multipath in MPLS Networks [draft-ietf-rtgwg-cl-requirement-16] (17 pages)
 - Advanced Multipath Use Cases and Design Considerations [draft-ietf-rtgwg-cl-use-cases-06] (24 pages)
 - Network Device YANG Logical Organization [draft-ietf-rtgwg-device-model-02] (22 pages)
 - Destination/Source Routing [draft-ietf-rtgwg-dst-src-routing-06] (21 pages)
 - Encapsulation Considerations [draft-ietf-rtgwg-dt-encap-02] (42 pages)
 - Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution [draft-ietf-rtgwg-enterprise-pa-multihoming-02] (47 pages)
 - Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels [draft-ietf-rtgwg-igp-shortcut-01] (8 pages)
 - IP Fast Reroute Framework [draft-ietf-rtgwg-ipfrr-framework-13] (15 pages)
 - IP MIB for IP Fast-Reroute [draft-ietf-rtgwg-ipfrr-ip-mib-08] (28 pages)
 - A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses [draft-ietf-rtgwg-ipfrr-notvia-addresses-11] (34 pages)
 - Basic Specification for IP Fast Reroute: Loop-Free Alternates [draft-ietf-rtgwg-ipfrr-spec-base-12] (31 pages)
 - A Framework for Loop-Free Convergence [draft-ietf-rtgwg-lf-conv-frmwk-07] (22 pages)
 - Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks [draft-ietf-rtgwg-lfa-applicability-06] (35 pages)
 - Operational Management of Loop-Free Alternates [draft-ietf-rtgwg-lfa-manageability-11] (31 pages)
 - YANG Logical Network Elements [draft-ietf-rtgwg-lne-model-05] (49 pages)
 - Analysis and Minimization of Microloops in Link-state Routing Protocols [draft-ietf-rtgwg-microloop-analysis-01] (17 pages)
 - Multicast-Only Fast Reroute [draft-ietf-rtgwg-mofrr-08] (14 pages)
 - An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) [draft-ietf-rtgwg-mrt-frr-algorithm-09] (118 pages)
 - An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) [draft-ietf-rtgwg-mrt-frr-architecture-10] (44 pages)
 - LFA selection for Multi-Homed Prefixes [draft-ietf-rtgwg-multihomed-prefix-lfa-04] (17 pages)
 - YANG Network Instances [draft-ietf-rtgwg-ni-model-08] (32 pages)
 - Node Potential Oriented Multi-NextHop Routing Protocol [draft-ietf-rtgwg-npmnrp-00] (25 pages)
 - Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach [draft-ietf-rtgwg-ordered-fib-12] (28 pages)
 - Routing Policy Configuration Model for Service Provider Networks [draft-ietf-rtgwg-policy-model-01] (41 pages)
 - Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) [draft-ietf-rtgwg-remote-lfa-11] (29 pages)
 - The Generalized TTL Security Mechanism (GTSM) [draft-ietf-rtgwg-rfc3682bis-10] (16 pages)
 - Remote-LFA Node Protection and Manageability [draft-ietf-rtgwg-rlfa-node-protection-13] (22 pages)
 - Routing Timer Parameter Synchronization [draft-ietf-rtgwg-routing-timer-param-sync-00] (10 pages)
 - Common YANG Data Types for the Routing Area [draft-ietf-rtgwg-routing-types-17] (43 pages)
 - Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops [draft-ietf-rtgwg-spf-uloop-pb-statement-06] (14 pages)
 - Micro-loop prevention by introducing a local convergence delay [draft-ietf-rtgwg-uloop-delay-09] (27 pages)
 - Fast failure detection in VRRP with Point to Point BFD [draft-ietf-rtgwg-vrrp-bfd-p2p-00] (27 pages)
 - YANG Data Model for Key Chains [draft-ietf-rtgwg-yang-key-chain-24] (25 pages)
 - A YANG Data Model for Routing Information Protocol (RIP) [draft-ietf-rtgwg-yang-rip-10] (44 pages)
 - A YANG Data Model for Virtual Router Redundancy Protocol (VRRP) [draft-ietf-rtgwg-yang-vrrp-10] (43 pages)
 - Destination/Source Routing [draft-lamparter-rtgwg-dst-src-routing-01] (8 pages)
 - Microloop prevention by introducing a local convergence delay [draft-litkowski-rtgwg-uloop-delay-04] (15 pages)
 - A YANG Data Model for Routing Information Protocol (RIP) [draft-liu-rtgwg-yang-rip-01] (30 pages)
 - A YANG Data Model for Virtual Router Redundancy Protocol (VRRP) [draft-liu-rtgwg-yang-vrrp-04] (30 pages)
 - LFA selection for Multi-Homed Prefixes [draft-psarkar-rtgwg-multihomed-prefix-lfa-04] (16 pages)
 - Remote-LFA Node Protection and Manageability [draft-psarkar-rtgwg-rlfa-node-protection-05] (16 pages)
 - Encapsulation Considerations [draft-rtg-dt-encap-02] (41 pages)
 - Network Device YANG Organizational Models [draft-rtgyangdt-rtgwg-device-model-05] (22 pages)
 - Logical Network Element Model [draft-rtgyangdt-rtgwg-lne-model-00] (13 pages)
 - Network Instance Model [draft-rtgyangdt-rtgwg-ni-model-00] (15 pages)
 - Routing Area Common YANG Data Types [draft-rtgyangdt-rtgwg-routing-types-00] (16 pages)
 - Routing Policy Configuration Model for Service Provider Networks [draft-shaikh-rtgwg-policy-model-01] (30 pages)

Requests for Comments:
 RFC3906: Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels (8 pages)
 RFC5082: The Generalized TTL Security Mechanism (GTSM) (16 pages)
          * Obsoletes RFC3682
 RFC5286: Basic Specification for IP Fast Reroute: Loop-Free Alternates (31 pages)
 RFC5714: IP Fast Reroute Framework (15 pages)
 RFC5715: A Framework for Loop-Free Convergence (22 pages)
 RFC6571: Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks (35 pages)
 RFC6976: Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach (28 pages)
 RFC6981: A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses (34 pages)
 RFC7226: Requirements for Advanced Multipath in MPLS Networks (17 pages)
 RFC7431: Multicast-Only Fast Reroute (14 pages)
 RFC7490: Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) (29 pages)
 RFC7811: An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) (118 pages)
 RFC7812: An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) (44 pages)
 RFC7916: Operational Management of Loop-Free Alternates (31 pages)
 RFC7938: Use of BGP for Routing in Large-Scale Data Centers (35 pages)
 RFC8102: Remote-LFA Node Protection and Manageability (22 pages)
 RFC8177: YANG Data Model for Key Chains (25 pages)
 RFC8294: Common YANG Data Types for the Routing Area (43 pages)



Routing Over Low power and Lossy networks (roll)
------------------------------------------------

Charter
Last Modified: 2016-04-06

Current Status: Active

Chairs:
    Ines Robles <[email protected]>
    Peter Van der Stok <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alvaro Retana <[email protected]>

Secretary:
    Michael Richardson <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       http://www.ietf.org/mailman/listinfo/roll
    Archive:            https://mailarchive.ietf.org/arch/browse/roll/

Description of Working Group:

 Low power and Lossy Networks (LLNs ) are made up of many embedded
 devices with limited power, memory, and processing resources. They are
 interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
 Low Power WiFi, wired or other low power PLC (Powerline Communication)
 links. LLNs are transitioning to an end-to-end IP-based solution to
 avoid the problem of non-interoperable networks interconnected by
 protocol translation gateways and proxies.

 RFC7102 discusses ROLL specific aspects of LLNs, and RFC7228 provides
 additional terminology for constrained devices. RFC 5548, 5673, 5826,
 and 5876 describe the requirements for LLNs from several application
 perspectives.

 The Working Group has focused on routing solutions for the areas:
 connected home, building, and urban sensor networks. It has developed a
 Framework that takes into consideration various aspects including high
 reliability in the presence of time varying loss characteristics and
 connectivity while permitting low-power operation with very modest
 memory and CPU pressure in networks potentially comprising a very large
 number (several thousands) of nodes.

 The Working Group continues to focus on routing issues for LLN and to
 maintain, improve and streamline the protocols already developed,
 including RPL and MPL. The focus is on IPv6 work only. The Working Group
 will pay particular attention to routing security and manageability
 (e.g., self-configuration) issues. The working group will consider the
 transport characteristics that routing protocol messages will
 experience.

 ROLL will coordinate closely with the working groups in other areas that
 focus on constrained networks and/or constrained nodes, such as 6lo,
 6tisch, ipwave, lwig and CoRE. Other working groups such as pim, bier
 and manet will be consulted as needed. The Working group will align with
 the 6man WG when needed.

 Work Items are:

 - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.

 - Additional protocol elements to reduce packet size and the amount of
   required routing states

 - Automatic selection of MPL forwarders to reduce message replication.

 - Data models for RPL and MPL management.

 - Multicast enhancements algorithms.


Goals and Milestones:
 Jan 2017 - Initial Submission of a proposal with uses cases for RPI, RH3 and IPv6-in-IPv6 encapsulation to the IESG
 Mar 2017 - Initial submission of a YANG model for MPL to the IESG
 Mar 2017 - Initial submission of a root initiated routing state in RPL to the IESG
 Jul 2017 - Initial submission of a proposal for Source-Route Multicast for RPL to the IESG
 Jul 2017 - Initial submission of a Forwarder Selection Protocol for MPL to the IESG
 Nov 2017 - Initial submission of a reactive P2P route discovery mechanism based on AODV-RPL protocol to the  IESG
 Nov 2017 - Initial submission of a proposal to augment DIS flags and options to the IESG
 Jul 2018 - Initial submission of a solution to the problems due to the use of No-Path DAO Messages to the IESG
 Sep 2018 - Recharter WG or close

Internet-Drafts:
 - MPL Parameter Configuration Option for DHCPv6 [draft-doi-roll-mpl-parameter-configuration-05] (10 pages)
 - Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) [draft-ietf-roll-admin-local-policy-03] (15 pages)
 - Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) [draft-ietf-roll-aodv-rpl-02] (17 pages)
 - Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks [draft-ietf-roll-applicability-ami-15] (24 pages)
 - Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control [draft-ietf-roll-applicability-home-building-12] (38 pages)
 - ROLL Applicability Statement Template [draft-ietf-roll-applicability-template-09] (10 pages)
 - Building Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-building-routing-reqs-09] (26 pages)
 - Constrained-Cast: Source-Routed Multicast for RPL [draft-ietf-roll-ccast-01] (10 pages)
 - Root initiated routing state in RPL [draft-ietf-roll-dao-projection-02] (20 pages)
 - DIS Modifications [draft-ietf-roll-dis-modifications-00] (15 pages)
 - No-Path DAO modifications [draft-ietf-roll-efficient-npdao-01] (14 pages)
 - Home Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-home-routing-reqs-11] (17 pages)
 - Industrial Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-indus-routing-reqs-06] (27 pages)
 - The Minimum Rank with Hysteresis Objective Function [draft-ietf-roll-minrank-hysteresis-of-11] (13 pages)
 - MPL Forwarder Select (MPLFS) [draft-ietf-roll-mpl-forw-select-00] (10 pages)
 - Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 [draft-ietf-roll-mpl-parameter-configuration-08] (10 pages)
 - A YANG model for Multicast Protocol for Low power and lossy Networks (MPL) [draft-ietf-roll-mpl-yang-00] (21 pages)
 - Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) [draft-ietf-roll-of0-20] (14 pages)
 - A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network [draft-ietf-roll-p2p-measurement-10] (29 pages)
 - Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks [draft-ietf-roll-p2p-rpl-17] (40 pages)
 - Overview of Existing Routing Protocols for Low Power and Lossy Networks [draft-ietf-roll-protocols-survey-07] (26 pages)
 - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header [draft-ietf-roll-routing-dispatch-05] (37 pages)
 - Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks [draft-ietf-roll-routing-metrics-19] (30 pages)
 - RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [draft-ietf-roll-rpl-19] (157 pages)
 - RPL applicability in industrial networks [draft-ietf-roll-rpl-industrial-applicability-02] (31 pages)
 - A Security Framework for Routing over Low Power and Lossy Networks [draft-ietf-roll-security-framework-07] (49 pages)
 - A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) [draft-ietf-roll-security-threats-11] (40 pages)
 - Terms Used in Routing for Low-Power and Lossy Networks [draft-ietf-roll-terminology-13] (8 pages)
 - The Trickle Algorithm [draft-ietf-roll-trickle-08] (13 pages)
 - Multicast Protocol for Low-Power and Lossy Networks (MPL) [draft-ietf-roll-trickle-mcast-12] (29 pages)
 - Routing Requirements for Urban Low-Power and Lossy Networks [draft-ietf-roll-urban-routing-reqs-05] (21 pages)
 - When to use RFC 6553, 6554 and IPv6-in-IPv6 [draft-ietf-roll-useofrplinfo-20] (46 pages)
 - ROLL Applicability Statement Template [draft-richardson-roll-applicability-template-02] (15 pages)
 - MPL forwarder policy for multicast with admin-local scope [draft-vanderstok-roll-admin-local-policy-00] (8 pages)

Requests for Comments:
 RFC5548: Routing Requirements for Urban Low-Power and Lossy Networks (21 pages)
 RFC5673: Industrial Routing Requirements in Low-Power and Lossy Networks (27 pages)
 RFC5826: Home Automation Routing Requirements in Low-Power and Lossy Networks (17 pages)
 RFC5867: Building Automation Routing Requirements in Low-Power and Lossy Networks (26 pages)
 RFC6206: The Trickle Algorithm (13 pages)
 RFC6550: RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (157 pages)
 RFC6551: Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks (30 pages)
 RFC6552: Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) (14 pages)
 RFC6719: The Minimum Rank with Hysteresis Objective Function (13 pages)
 RFC6997: Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks (40 pages)
 RFC6998: A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network (29 pages)
 RFC7102: Terms Used in Routing for Low-Power and Lossy Networks (8 pages)
 RFC7416: A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) (40 pages)
 RFC7731: Multicast Protocol for Low-Power and Lossy Networks (MPL) (29 pages)
 RFC7732: Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) (15 pages)
 RFC7733: Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control (38 pages)
 RFC7774: Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 (10 pages)
 RFC8036: Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks (24 pages)
 RFC8138: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header (37 pages)



Secure Inter-Domain Routing (sidr)
----------------------------------

Charter
Last Modified: 2015-07-19

Current Status: Active

Chairs:
    Chris Morrow <[email protected]>
    Sandra L. Murphy <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alvaro Retana <[email protected]>

Tech Advisor:
    Steven Bellovin <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/sidr
    Archive:            https://mailarchive.ietf.org/arch/browse/sidr/

Description of Working Group:


   The purpose of the SIDR working group is to reduce vulnerabilities in
   the inter-domain routing system. The two vulnerabilities that will be
   addressed are:

    * Is an Autonomous System (AS) authorized to originate an IP prefix
    * Is the AS-Path represented in the route the same as the path through
       which the NLRI traveled

   The SIDR working group will take practical deployability into consideration.

   Building upon the already completed and implemented framework:

    * Resource Public Key Infrastructure (RPKI)
    * Distribution of RPKI data to routing devices and its use in
         operational networks
    * Document the use of certification objects within the secure
         routing architecture

   This working group will specify security enhancements for inter-domain
   routing protocols.



Goals and Milestones:
 Done     - Submit initial draft on inter-domain routing security within this architecture
 Done     - Submit initial draft on certificate objects to be used within this architecture
 Done     - Submit initial draft on securing origination of routing information
 Jan 2010 - I-D: draft-ietf-sidr-publication
 Jan 2010 - I-D: draft-ietf-sidr-keyroll
 Jan 2010 - I-D: draft-ietf-sidr-arch
 Jan 2010 - I-D: draft-ietf-sidr-cp
 Jan 2010 - I-D: draft-ietf-sidr-res-certs
 Jan 2010 - I-D: draft-ietf-sidr-roa-validation
 Jan 2010 - I-D: draft-ietf-sidr-signed-object
 Jan 2010 - I-D: draft-ietf-sidr-rpki-manifests
 Jan 2010 - I-D: draft-ietf-sidr-rpki-algs
 Jan 2010 - I-D: draft-ietf-sidr-rescerts-provisioning
 Jan 2010 - I-D: draft-ietf-sidr-ta
 Mar 2010 - I-D: draft-ietf-sidr-cps-irs
 Mar 2010 - I-D: draft-ietf-sidr-cps-isp
 Nov 2010 - I-D: draft-ietf-sidr-origin-ops
 Nov 2010 - I-D: draft-ietf-sidr-pfx-validate
 Nov 2010 - I-D: draft-ietf-sidr-repos-struct
 Nov 2010 - I-D: draft-ietf-sidr-roa-format
 Nov 2010 - I-D: draft-ietf-sidr-ltamgmt
 Dec 2010 - I-D: draft-rgaglian-sidr-algorithm-agility
 Jan 2011 - I-D: draft-ietf-sidr-ghostbusters
 Feb 2011 - I-D: draft-ietf-sidr-rpki-rtr
 Mar 2011 - I-D: Document the BGP protocol enhancements that meet the security requirements
 Mar 2011 - I-D: A requirements document that  addresses these threats
 Mar 2011 - I-D: A document describing threats to the routing system
 Mar 2011 - I-D: An overview of the RPKI and BGP Protocol changes required for origin and path validation
 Mar 2011 - I-D: Operational deployment guidance for network operators
 May 2011 - I-D: draft-ietf-sidr-usecases
 May 2011 - Publication: draft-ietf-sidr-arch
 May 2011 - Publication: draft-ietf-sidr-cp
 May 2011 - Publication: draft-ietf-sidr-res-certs
 Jun 2011 - I-D: System and architecture design choices made in the protocol and RPKI
 Jun 2011 - Publication: draft-ietf-sidr-publication
 Jun 2011 - Publication: draft-ietf-sidr-repos-struct
 Jun 2011 - Publication: draft-ietf-sidr-roa-format
 Jun 2011 - Publication: draft-ietf-sidr-rpki-rtr
 Jun 2011 - Publication: draft-ietf-sidr-roa-validation
 Jun 2011 - Publication: draft-ietf-sidr-signed-object
 Jun 2011 - Publication: draft-ietf-sidr-rpki-manifests
 Jul 2011 - Publication: draft-ietf-sidr-origin-ops
 Jul 2011 - Publication: draft-ietf-sidr-rpki-algs
 Jul 2011 - Publication: draft-ietf-sidr-rescerts-provisioning
 Aug 2011 - Publication: draft-ietf-sidr-ta
 Oct 2011 - Publication: draft-rgaglian-sidr-algorithm-agility
 Oct 2011 - Publication: draft-ietf-sidr-ghostbusters
 Nov 2011 - Publication: draft-ietf-sidr-ltamgmt
 Dec 2011 - Publication: System and architecture design choices made in the protocol and RPKI
 Dec 2011 - Publication: draft-ietf-sidr-usecases
 Dec 2011 - Publication: draft-ietf-sidr-keyroll
 Jan 2012 - Publication: An overview of the RPKI and BGP Protocol changes required for origin and path validation
 Jan 2012 - Publication: Document the BGP protocol enhancements that meet the security requirements
 Jan 2012 - Publication: draft-ietf-sidr-pfx-validate
 Mar 2012 - Publication: draft-ietf-sidr-cps-irs
 Mar 2012 - Publication: draft-ietf-sidr-cps-isp
 Jun 2012 - Publication: A document describing threats to the routing system
 Jun 2012 - Publication: A requirements document that  addresses these threats
 Jul 2012 - Publication: Operational deployment guidance for network operators

Internet-Drafts:
 - Simplified Local internet nUmber Resource Management with the RPKI [draft-dseomn-sidr-slurm-02] (11 pages)
 - BGPSec Considerations for AS Migration [draft-george-sidr-as-migration-01] (14 pages)
 - Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-adverse-actions-04] (26 pages)
 - Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-algorithm-agility-12] (20 pages)
 - An Infrastructure to Support Secure Internet Routing [draft-ietf-sidr-arch-13] (24 pages)
 - BGPsec Considerations for Autonomous System (AS) Migration [draft-ietf-sidr-as-migration-06] (16 pages)
 - BGPsec Algorithms, Key Formats, and Signature Formats [draft-ietf-sidr-bgpsec-algs-18] (19 pages)
 - BGPsec Operational Considerations [draft-ietf-sidr-bgpsec-ops-16] (10 pages)
 - An Overview of BGPsec [draft-ietf-sidr-bgpsec-overview-08] (10 pages)
 - A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests [draft-ietf-sidr-bgpsec-pki-profiles-21] (15 pages)
 - BGPsec Protocol Specification [draft-ietf-sidr-bgpsec-protocol-23] (45 pages)
 - Security Requirements for BGP Path Validation [draft-ietf-sidr-bgpsec-reqs-12] (9 pages)
 - Threat Model for BGP Path Security [draft-ietf-sidr-bgpsec-threats-09] (20 pages)
 - A Profile for Bogon Origin Attestations (BOAs) [draft-ietf-sidr-bogons-03] (14 pages)
 - Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-cp-17] (35 pages)
 - Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) [draft-ietf-sidr-cps-04] (38 pages)
 - Template for an Internet Registry's Certification Practice Statement (CPS) for the Resource PKI (RPKI) [draft-ietf-sidr-cps-irs-05] (42 pages)
 - Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Resource PKI (RPKI) [draft-ietf-sidr-cps-isp-04] (43 pages)
 - The RPKI Repository Delta Protocol (RRDP) [draft-ietf-sidr-delta-protocol-08] (24 pages)
 - The Resource Public Key Infrastructure (RPKI) Ghostbusters Record [draft-ietf-sidr-ghostbusters-16] (8 pages)
 - Resource Public Key Infrastructure (RPKI) Objects Issued by IANA [draft-ietf-sidr-iana-objects-03] (12 pages)
 - Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-keyroll-08] (10 pages)
 - Local Trust Anchor Management for the Resource Public Key Infrastructure [draft-ietf-sidr-ltamgmt-08] (28 pages)
 - Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-multiple-publication-points-01] (13 pages)
 - Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-origin-ops-23] (11 pages)
 - BGP Prefix Origin Validation State Extended Community [draft-ietf-sidr-origin-validation-signaling-11] (6 pages)
 - BGP Prefix Origin Validation [draft-ietf-sidr-pfx-validate-10] (10 pages)
 - Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates [draft-ietf-sidr-policy-qualifiers-02] (5 pages)
 - A Publication Protocol for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-publication-12] (21 pages)
 - A Profile for Resource Certificate Repository Structure [draft-ietf-sidr-repos-struct-09] (15 pages)
 - A Profile for X.509 PKIX Resource Certificates [draft-ietf-sidr-res-certs-22] (32 pages)
 - A Protocol for Provisioning Resource Certificates [draft-ietf-sidr-rescerts-provisioning-11] (32 pages)
 - The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure [draft-ietf-sidr-rfc6485bis-05] (9 pages)
 - Resource Public Key Infrastructure (RPKI) Trust Anchor Locator [draft-ietf-sidr-rfc6490-bis-05] (8 pages)
 - A Profile for Route Origin Authorizations (ROAs) [draft-ietf-sidr-roa-format-12] (9 pages)
 - Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) [draft-ietf-sidr-roa-validation-10] (8 pages)
 - The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-rpki-algs-05] (6 pages)
 - Responsible Grandparenting in the RPKI [draft-ietf-sidr-rpki-grandparenting-01] (4 pages)
 - Local Trust Anchor Management for the Resource Public Key Infrastructure [draft-ietf-sidr-rpki-ltamgmt-00] (27 pages)
 - Manifests for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-rpki-manifests-16] (19 pages)
 - An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services [draft-ietf-sidr-rpki-oob-setup-09] (23 pages)
 - The Resource Public Key Infrastructure (RPKI) to Router Protocol [draft-ietf-sidr-rpki-rtr-26] (27 pages)
 - Resource Public Key Infrastructure (RPKI) Router Implementation Report [draft-ietf-sidr-rpki-rtr-impl-05] (11 pages)
 - Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol [draft-ietf-sidr-rpki-rtr-protocol-mib-07] (25 pages)
 - The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 [draft-ietf-sidr-rpki-rtr-rfc6810-bis-09] (35 pages)
 - RPKI Validation Reconsidered [draft-ietf-sidr-rpki-validation-reconsidered-10] (27 pages)
 - Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures [draft-ietf-sidr-rpsl-sig-12] (14 pages)
 - Router Keying for BGPsec [draft-ietf-sidr-rtr-keying-14] (17 pages)
 - Signed Object Template for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-signed-object-04] (13 pages)
 - Simplified Local internet nUmber Resource Management with the RPKI [draft-ietf-sidr-slurm-05] (17 pages)
 - Resource Public Key Infrastructure (RPKI) Trust Anchor Locator [draft-ietf-sidr-ta-07] (7 pages)
 - Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties [draft-ietf-sidr-usecases-06] (31 pages)
 - Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) [draft-kent-sidr-adverse-actions-02] (24 pages)
 - Policy Qualifiers in RPKI Certificates [draft-newton-sidr-policy-qualifiers-01] (9 pages)
 - BGPSEC router key rollover as an alternative to beaconing [draft-rogaglia-sidr-bgpsec-rollover-01] (15 pages)
 - Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI) [draft-rogaglia-sidr-multiple-publication-points-02] (13 pages)
 - RPKI Repository Delta Protocol [draft-tbruijnzeels-sidr-delta-protocol-03] (18 pages)
 - RPKI Repository Validation Using Local Cache [draft-tbruijnzeels-sidr-validation-local-cache-02] (9 pages)
 - Router Keying for BGPsec [draft-ymbk-bgpsec-rtr-rekeying-00] (7 pages)
 - RPKI Router Implementation Report [draft-ymbk-rpki-rtr-impl-01] (11 pages)

Requests for Comments:
 BCP173: Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) (35 pages)
 BCP174: Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) (10 pages)
 BCP182: Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) (20 pages)
 BCP185: Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) (11 pages)
 BCP211: BGPsec Operational Considerations (10 pages)
 RFC6480: An Infrastructure to Support Secure Internet Routing (24 pages)
 RFC6481: A Profile for Resource Certificate Repository Structure (15 pages)
 RFC6482: A Profile for Route Origin Authorizations (ROAs) (9 pages)
 RFC6483: Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) (8 pages)
 RFC6484: Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) (35 pages)
 RFC6485: The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) (6 pages)
          * Obsoletes RFC7935
 RFC6486: Manifests for the Resource Public Key Infrastructure (RPKI) (19 pages)
 RFC6487: A Profile for X.509 PKIX Resource Certificates (32 pages)
          * Updates RFC7318
          * Updates RFC8209
 RFC6488: Signed Object Template for the Resource Public Key Infrastructure (RPKI) (13 pages)
 RFC6489: Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) (10 pages)
 RFC6490: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator (7 pages)
          * Obsoletes RFC7730
 RFC6491: Resource Public Key Infrastructure (RPKI) Objects Issued by IANA (12 pages)
 RFC6492: A Protocol for Provisioning Resource Certificates (32 pages)
 RFC6493: The Resource Public Key Infrastructure (RPKI) Ghostbusters Record (8 pages)
 RFC6810: The Resource Public Key Infrastructure (RPKI) to Router Protocol (27 pages)
          * Updates RFC8210
 RFC6811: BGP Prefix Origin Validation (10 pages)
 RFC6907: Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties (31 pages)
 RFC6916: Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) (20 pages)
 RFC6945: Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol (25 pages)
 RFC7115: Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) (11 pages)
 RFC7128: Resource Public Key Infrastructure (RPKI) Router Implementation Report (11 pages)
 RFC7132: Threat Model for BGP Path Security (20 pages)
 RFC7318: Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates (5 pages)
          * Updates RFC6487
 RFC7353: Security Requirements for BGP Path Validation (9 pages)
 RFC7382: Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) (38 pages)
 RFC7730: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator (8 pages)
          * Obsoletes RFC6490
 RFC7909: Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures (14 pages)
          * Updates RFC2622
          * Updates RFC4012
 RFC7935: The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (9 pages)
          * Obsoletes RFC6485
          * Updates RFC8208
 RFC8097: BGP Prefix Origin Validation State Extended Community (6 pages)
 RFC8181: A Publication Protocol for the Resource Public Key Infrastructure (RPKI) (21 pages)
 RFC8182: The RPKI Repository Delta Protocol (RRDP) (24 pages)
 RFC8183: An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services (23 pages)
 RFC8205: BGPsec Protocol Specification (45 pages)
          * Updates RFC8206
 RFC8206: BGPsec Considerations for Autonomous System (AS) Migration (16 pages)
          * Updates RFC8205
 RFC8207: BGPsec Operational Considerations (10 pages)
 RFC8208: BGPsec Algorithms, Key Formats, and Signature Formats (19 pages)
          * Updates RFC7935
 RFC8209: A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests (15 pages)
          * Updates RFC6487
 RFC8210: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 (35 pages)
          * Updates RFC6810
 RFC8211: Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) (26 pages)



Service Function Chaining (sfc)
-------------------------------

Charter
Last Modified: 2017-07-19

Current Status: Active

Chairs:
    Jim Guichard <[email protected]>
    Joel M. Halpern <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alia Atlas <[email protected]>

Secretary:
    Tal Mizrahi <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/sfc
    Archive:            https://mailarchive.ietf.org/arch/browse/sfc/

Description of Working Group:

 Network operators frequently utilize service functions such as packet
 filtering at firewalls, load-balancing and transactional proxies (for
 example spam filters) in the delivery of services to end users. Delivery
 of these types of services is undergoing significant change with the
 introduction of virtualization, network overlays, and orchestration.

 Deploying service functions to support service delivery is currently both
 a technical and an organizational challenge that involves significant
 modification to the network configuration, impacting the speed at which
 services can be deployed and increasing operational costs. Such
 services are typically implemented by the ordered combination of a
 number of service functions that are deployed at different points within
 a network.

 Today, common deployment models have service functions inserted on
 the data-forwarding path between communicating peers. Going forward,
 however, there is a need to move to a different model, where service
 functions, whether physical or virtualized, are not required to reside on
 the direct data path and traffic is instead steered through required
 service functions, wherever they are deployed.

 For a given service, the abstracted view of the required service
 functions and the order in which they are to be applied is called a
 Service Function Chain (SFC). An SFC is instantiated through selection
 of specific service function instances on specific network nodes to form
 a service graph: this is called a Service Function Path (SFP). The
 service functions may be applied at any layer within the network
 protocol stack (network layer, transport layer, application layer, etc.).

 The SFC working group will document a new approach to service delivery
 and operation. It will produce an architecture for service function
 chaining that includes the necessary protocols or protocol extensions to
 convey the Service Function Chain and Service Function Path information
 to nodes that are involved in the implementation of service functions
 and Service Function Chains, as well as mechanisms for steering traffic
 through service functions. The WG will examine existing identifier schemes,
 if there is a need for such identifiers in the context of the Generic SFC
 encapsulation, before defining any new identifier scheme.

 The working group will examine what information needs to be gathered
 from the network and service functions in support of Service Function
 Chaining and how that information may be made available to the
 components of the Service Function Chaining architecture. The SFC
 WG will closely consider and address the management and security
 implications when documenting these deliverables.

 Specifically, the SFC WG is chartered to deliver the following:

 1. Problem Statement: This document will provide a summary of the
    problem space to be addressed by the SFC working group including
    example high-level use cases. Additionally, the working group will
    normalize nomenclature and definitions for service function chaining.

 2. Architecture: This document will provide a description of the SFC
    architectural building blocks and their relationships including
    interconnection, placement of SFC specific capabilities, management,
    diagnostics, design analysis, and security models, as well as
    requirements on the protocol mechanisms.  The initial scope is
    restricted to a single administrative domain, keeping in mind that
    architectural decisions made for the intra-domain case may have
    implications for the inter-domain case.

 3. Generic SFC Encapsulation: This document will describe a single
    service-level data plane encapsulation format that:
    - indicates the sequence of service functions that make up the
      Service Function Chain
    - specifies the Service Function Path,
    - communicates context information between nodes that implement
      service functions and Service Function Chains.
    It is intended that the encapsulation format be agnostic to the
    layer at which it is applied and the service that is being
    constructed. That is, the same encapsulation may be used on a
    service function chain applied at the network layer or at any other
    layer, and the same encapsulation format will apply for the
    construction of Service Function Paths regardless of the actual
    service. The working group will consider using an existing
    encapsulation (with extensions as appropriate) if a suitable
    candidate is found.

 4. Control Plane Mechanisms: A document will be developed to describe
    requirements for conveying information between control or management
    elements and SFC implementation points. All protocol extension work
    resulting from these requirements should be carried out in the
    working group responsible for the protocol being modified in
    coordination with this working group, but may be done in this working
    group under a revised charter after agreement with all the relevant
    WG chairs and responsible ADs.

 5. Manageability: Work on the management and configuration of SFC
    components related to the support of Service Function Chaining will
    certainly be needed, but first needs to be better understood and
    scoped.

Goals and Milestones:
 Apr 2014 - Submit to IESG Information document defining the SFC problem statement and core use cases
 Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining
 Jan 2015 - Submit to IESG Informational document defining the architecture for SFC
 Jan 2015 - Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points
 Aug 2015 - Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation

Internet-Drafts:
 - Operating the Network Service Header (NSH) with Next Protocol "None" [draft-farrel-sfc-convent-05] (11 pages)
 - Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center) [draft-guichard-sfc-nsh-dc-allocation-07] (9 pages)
 - A Service Chain Aggregation Architecture [draft-ietf-sfc-aggregation-00] (5 pages)
 - Service Function Chaining (SFC) Architecture [draft-ietf-sfc-architecture-11] (32 pages)
 - Service Function Chaining (SFC) Control Plane Components & Requirements [draft-ietf-sfc-control-plane-08] (29 pages)
 - Service Function Chaining Use Cases In Data Centers [draft-ietf-sfc-dc-use-cases-06] (23 pages)
 - Hierarchical Service Function Chaining (hSFC) [draft-ietf-sfc-hierarchical-06] (26 pages)
 - SFC Long-lived Flow Use Cases [draft-ietf-sfc-long-lived-flow-use-cases-03] (10 pages)
 - Network Service Header (NSH) [draft-ietf-sfc-nsh-28] (40 pages)
 - NSH Context Header Allocation for Broadband [draft-ietf-sfc-nsh-broadband-allocation-00] (10 pages)
 - Network Service Header TLVs [draft-ietf-sfc-nsh-tlv-00] (8 pages)
 - Service Function Chaining (SFC) Operation, Administration and Maintenance (OAM) Framework [draft-ietf-sfc-oam-framework-03] (18 pages)
 - Service Function Simple Offloads [draft-ietf-sfc-offloads-00] (17 pages)
 - Problem Statement for Service Function Chaining [draft-ietf-sfc-problem-statement-13] (13 pages)
 - Service Function Chaining Use Cases in Mobile Networks [draft-ietf-sfc-use-case-mobility-07] (26 pages)
 - NSH Context Header Allocation -- Broadband [draft-napper-sfc-nsh-broadband-allocation-04] (9 pages)
 - Network Service Header TLVs [draft-quinn-sfc-nsh-tlv-04] (8 pages)

Requests for Comments:
 RFC7498: Problem Statement for Service Function Chaining (13 pages)
 RFC7665: Service Function Chaining (SFC) Architecture (32 pages)
 RFC8300: Network Service Header (NSH) (40 pages)



Source Packet Routing in Networking (spring)
--------------------------------------------

Charter
Last Modified: 2016-07-27

Current Status: Active

Chairs:
    Bruno Decraene <[email protected]>
    Martin Vigoureux <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alvaro Retana <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/spring
    Archive:            https://mailarchive.ietf.org/arch/browse/spring/

Description of Working Group:

 The ability for a node to specify a forwarding path, other
 than the normal shortest path, that a particular packet
 will traverse, benefits a number of network functions,
 for example:

 o    Some types of network virtualization, including multi-
      topology networks and the partitioning of network
      resources for VPNs
 o    Network path and node protection such as fast re-route
 o    Network programmability
 o    New OAM techniques
 o    Simplification and reduction of network signalling
      components
 o    Load balancing and traffic engineering

 Source-based routing mechanisms have previously been
 specified for network protocols, but have not seen
 widespread adoption other than in MPLS traffic engineering.
 These network functions may require greater flexibility and
 per packet source imposed routing than can be achieved
 through the use of the previously defined methods. In the
 context of this charter, 'source' means 'the point at
 which the explicit route is imposed'.

 The SPRING working group will define procedures that
 will allow a node to steer a packet along an explicit
 route using information attached to the packet and
 without the need for per-path state information to be
 held at transit nodes. Full explicit control (through loose
 or strict path specification) can be achieved in a network
 comprising only SPRING nodes, however SPRING must
 inter-operate through loose routing in existing networks
 and may find it advantageous to use loose routing for
 for other network applications.

 The initial data planes that will be considered are MPLS
 and IPv6.

 There is an assumed trust model such that any node
 imposing an explicit route on a packet is assumed to
 be allowed to do so, however administrative and trust
 boundaries may strip explicit routes from a packet.
 For each data plane technology that SPRING specifies,
 a security analysis must be provided showing how protection
 is provided against an attacker disrupting the network by
 for example, maliciously injecting SPRING packets.
 There are a number of serious security concerns with
 source routing at the IP layer [RFC 5095].  As a part
 of its work, the working group will define the new
 IPv6-based routing header in way that blind attacks
 are never possible, i.e., attackers will be unable to
 send source routed packets that get successfully
 processed, without being part of the negotiation for
 setting up the source routes or being able to eavesdrop
 legitimate source routed packets. In some networks
 this base level security may be complemented with
 other mechanisms, such as packet filtering, cryptographic
 security, etc.

 Initial work will focus on SPRING within in a single AS,
 however design decisions must not preclude operation
 of SPRING across AS boundaries. In such multi-AS
 deployments, the previously-stated trust model would
 still apply.

 SPRING should support both centralised and distributed
 path computation.

 The SPRING WG should provide OAM and the
 management needed to manage SPRING enabled networks.
 The SPRING procedures may also be used as a tool for OAM
 in SPRING enabled networks.

 SPRING should avoid modification to existing data
 planes that would make them incompatible with
 existing deployments. Where possible, existing control
 and management plane protocols must be used within existing
 architectures to implement the SPRING function. Any
 modification of or extension to existing architectures,
 data planes, or control or management plane protocols
 must be carried out in the working groups responsible
 for the architecture, data plane, or control or
 management plane protocol being modified and in
 co-ordination with this working group, but may be
 done in this working group after agreement with
 all the relevant WG chairs and responsible Area Directors.

 The SPRING working group is chartered for the following
 list of items:

 o Identification and evaluation of use cases for SPRING.
    These use cases must include a definition of the
    data plane for the environment in which they are to be
    deployed.

 o Definition of requirements for any new data plane
    encodings and procedures, required to implement
    the use cases. Such procedures must include the
    necessary security considerations.

 o Definition of requirements and if necessary any
    new control plane mechanism needed to enable
    the use cases.

 o Definition of requirements and if necessary management
    plane mechanisms needed to manage and operate a
    SPRING enabled network.

 The SPRING working group will not work on any
 mechanisms for use in networks that forward IPv4 packets.



Goals and Milestones:
 Done     - One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data planes.
 Done     - One or more documents describing SPRING use cases.
 Done     - Specification of a high-level abstract architecture for SPRING.
 Done     - One or more control protocol extensions requirements documents.
 Jan 2016 - Inter-operability reports pertaining to the implementation of extensions supporting SPRING.
 Apr 2016 - Requirements for modifications if any to MPLS architecture to support SPRING use cases.
 Apr 2016 - Requirements for modifications if any to IPv6 architecture to support SPRING use cases.
 Done     - Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols.
 Aug 2016 - Specify the OAM mechanisms needed to support SPRING.
 Aug 2016 - SPRING YANG model submitted to IESG
 Nov 2016 - Recharter or close WG.

Internet-Drafts:
 - Interconnecting Millions Of Endpoints With Segment Routing [draft-filsfils-spring-large-scale-interconnect-08] (11 pages)
 - Segment Routing Architecture [draft-filsfils-spring-segment-routing-04] (18 pages)
 - Segment Routing with MPLS data plane [draft-filsfils-spring-segment-routing-mpls-03] (14 pages)
 - Segment Routing Recursive Information [draft-filsfils-spring-sr-recursing-info-05] (8 pages)
 - Use-cases for Resiliency in SPRING [draft-francois-spring-resiliency-use-case-02] (8 pages)
 - Segment Routing Conflict Resolution [draft-ginsberg-spring-conflict-resolution-01] (15 pages)
 - Segment Routing MPLS Conflict Resolution [draft-ietf-spring-conflict-resolution-05] (22 pages)
 - IPv6 SPRING Use Cases [draft-ietf-spring-ipv6-use-cases-12] (9 pages)
 - Anycast Segments in MPLS based Segment Routing [draft-ietf-spring-mpls-anycast-segments-02] (19 pages)
 - A Scalable and Topology-Aware MPLS Dataplane Monitoring System [draft-ietf-spring-oam-usecase-10] (19 pages)
 - Source Packet Routing in Networking (SPRING) Problem Statement and Requirements [draft-ietf-spring-problem-statement-08] (19 pages)
 - Resiliency use cases in SPRING networks [draft-ietf-spring-resiliency-use-cases-12] (11 pages)
 - Segment Routing Architecture [draft-ietf-spring-segment-routing-15] (31 pages)
 - Segment Routing Centralized BGP Egress Peer Engineering [draft-ietf-spring-segment-routing-central-epe-10] (19 pages)
 - Segment Routing interworking with LDP [draft-ietf-spring-segment-routing-ldp-interop-09] (20 pages)
 - Segment Routing with MPLS data plane [draft-ietf-spring-segment-routing-mpls-11] (19 pages)
 - BGP-Prefix Segment in large-scale data centers [draft-ietf-spring-segment-routing-msdc-08] (24 pages)
 - OAM Requirements for Segment Routing Network [draft-ietf-spring-sr-oam-requirement-03] (7 pages)
 - YANG Data Model for Segment Routing [draft-ietf-spring-sr-yang-08] (29 pages)
 - OAM Requirements for Segment Routing Network [draft-kumar-spring-sr-oam-requirement-03] (6 pages)
 - YANG Data Model for Segment Routing [draft-litkowski-spring-sr-yang-01] (21 pages)
 - IPv6 SPRING Use Cases [draft-martin-spring-segment-routing-ipv6-use-cases-01] (12 pages)
 - SPRING Problem Statement and Requirements [draft-previdi-spring-problem-statement-04] (18 pages)
 - Anycast Segments in MPLS based Segment Routing [draft-psarkar-spring-mpls-anycast-segments-02] (19 pages)

Requests for Comments:
 RFC7855: Source Packet Routing in Networking (SPRING) Problem Statement and Requirements (19 pages)



Traffic Engineering Architecture and Signaling (teas)
-----------------------------------------------------

Charter
Last Modified: 2015-10-07

Current Status: Active

Chairs:
    Lou Berger <[email protected]>
    Vishnu Pavan Beeram <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Deborah Brungard <[email protected]>

Tech Advisor:
    Adrian Farrel <[email protected]>

Secretary:
    Matt Hartley <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/teas
    Archive:            https://mailarchive.ietf.org/arch/browse/teas/

Description of Working Group:

 The Traffic Engineering Architecture and Signaling (TEAS) Working
 Group is responsible for defining MPLS and GMPLS traffic
 engineering architecture, standardizing the RSVP-TE signaling
 protocol, and identifying required related control-protocol
 functions, i.e., routing and path computation element functions.

 Traffic Engineering (TE) is the term used to refer to techniques
 that enable operators to control how specific traffic flows are
 treated within their networks. TE is applied to packet networks
 via MPLS TE tunnels and LSPs. The MPLS-TE control plane was
 generalized to additionally support non-packet technologies via
 GMPLS.  RSVP-TE is the signaling protocol used for both MPLS-TE
 and GMPLS.

 The TEAS WG is responsible for:

  a) Traffic-engineering architectures for generic applicability
     across packet and non-packet networks. This includes both
     networks that include the use of PCE and those that do not.
     The PCE architecture itself is out of the WG scope.

  b) Definition of protocol-independent metrics and parameters
     (measurement and/or service attributes) for describing
     links and tunnels/paths required for traffic engineering
     (and related routing, signaling and path computation).
     These will be developed in conjunction with requests and
     requirements from other WGs to ensure overall usefulness.

  c) Functional specification of extensions for routing (OSPF,
     ISIS) and for path computation (PCE) to provide general
     enablers of traffic-engineering systems that also use
     RSVP-TE. Protocol formats and procedures that embody these
     extensions will be done in coordination with the WGs
     supervising those protocols.

  d) Functional specification of generic (i.e., not data plane
     technology-specific) extensions for RSVP-TE, and the
     associated protocol formats and procedures that embody
     these extensions.

  e) Definition of control plane mechanisms and extensions to allow
     the setup and maintenance of TE paths and TE tunnels that span
     multiple domains and/or switching technologies, where a
     domain may be an IGP area, an Autonomous System, or any other
     region of topological visibility.

  f) Definition and extension of management and security techniques
     for RSVP-TE signaling. This includes configuring and monitoring
     RSVP-TE as well as mechanisms used to configure, control, and
     report OAM within TE networks. YANG and MIB modules may be
     considered.

 The TEAS working group is chartered to deliver the following:

  1. Definition of additional abstract service, link, and path
     properties such as jitter, delay, and diversity. Extensions
     to IGPs to advertise these properties, and extensions to
     RSVP-TE to request and to accumulate these properties. Work
     with PCE WG to include these properties in computation
     requests.

  2. Specification of terminology, architecture, and protocol
     requirements for abstraction and distribution of TE
     information between interconnected TE domains/layers.

  3. Specification and protocol extensions for a GMPLS External
     Network-to-Network Interface (E-NNI), i.e., multi-domain
     GMPLS support.

  4. Protocol mechanisms to signal associated LSPs in particular
     with different source nodes.

  5. Requirements and protocol extensions for additional protection
     mechanisms including end-point protection, protection of P2MP
     LSPs, and inter-domain protection.

  6. YANG models for a Traffic Engineering Database in coordination
     with working groups working on YANG models for network
     topology and for technology-specific network attributes.

 Requirements may be documented in stand-alone RFCs, may be
 folded into architecture or solutions RFCs, may be recorded on a
 wiki, or may be documented in an Internet-Draft that is not
 progressed to RFC.

 The TEAS WG will coordinate with the following working groups:

  - With the MPLS WG to maintain and extend MPLS-TE protocol
    mechanisms and to determine whether they should be generalized.

  - With the CCAMP WG to maintain and extend non-packet, data plane
    technology-specific TE protocol mechanisms and to determine
    whether they should be generalized.

  - With the OSPF and ISIS WGs to maintain or extend TE routing
    mechanisms for MPLS-TE and GMPLS.

  - With the PCE WG on uses of a PCE in the traffic-engineering
    architecture, on PCE extensions per the above, and on RSVP-TE
    extensions to support PCE WG identified requirements.

  - With the IDR WG on the use of BGP-LS in TE environments.

 In doing this work, the WG will cooperate with external SDOs (such
 as the ITU-T and the IEEE 802.1) as necessary.

Goals and Milestones:
 Done     - Transition in charter work from MPLS and CCAMP WGs
 Done     - Initiate TE Yang Model work via interim and Design Teams
 Done     - Adopt Requirements for Very Fast Setup
 Dec 2014 - Submit -mpls-tp-rsvpte-ext-associated-lsp to IESG for publication
 Jan 2015 - Submit -lsp-attribute-ro to IESG for publication
 Jan 2015 - Submit -rsvp-te-li-lb to IESG for publication
 Jan 2015 - Submit -ietf-ccamp-rsvp-te-srlg-collect to IESG for publication
 Done     - Initial TE LSP Yang Model WG document
 Done     - Initial TE Topology Yang Model WG document
 Done     - Close initial TE Yang Model Design Teams
 Apr 2015 - Submit loose path reoptimization to IESG for publication
 May 2015 - Submit metric recording to IESG for publication
 Jul 2015 - Submit XRO based LSP Diversity to IESG for publication
 Aug 2015 - Submit ingress/egress protection documents to IESG for publication
 Aug 2015 - Adopt interconnected TE network solution document
 Done     - Submit domain subobjects to IESG for publication
 Nov 2015 - Adopt Very Fast Setup informational document
 Dec 2015 - Submit network assigned upstream label to IESG for publication
 Dec 2015 - Submit Requirements for Very Fast Setup to IESG for publication
 Jan 2016 - Submit Resource sharing draft to IESG for publication
 Mar 2016 - Submit first interconnected TE network document to IESG for publication
 Jun 2016 - Submit TE LSP Yang Models to IESG for publication
 Jun 2016 - Submit TE Topology Yang Models to IESG for publication
 Sep 2016 - Submit interconnected TE network solution document to IESG for publication
 Nov 2016 - Submit Very Fast Setup informational document to IESG for publication
 Nov 2016 - Revisit WG status (close if no milestones/deliverables)

Internet-Drafts:
 - Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments [draft-beeram-teas-rsvp-te-scaling-rec-00] (11 pages)
 - TE Topology and Tunnel Modeling for Transport Networks [draft-bryskin-teas-te-topo-and-tunnel-modeling-01] (105 pages)
 - Yang model for requesting Path Computation [draft-busibel-teas-yang-path-computation-03] (44 pages)
 - RSVP-TE Signaling Procedure for GMPLS Restoration and Resource Sharing- based LSP Setup and Teardown [draft-ietf-ccamp-gmpls-resource-sharing-proc-00] (19 pages)
 - Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks [draft-ietf-ccamp-interconnected-te-info-exchange-01] (56 pages)
 - LSP Attribute in ERO [draft-ietf-ccamp-lsp-attribute-ro-05] (12 pages)
 - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route [draft-ietf-ccamp-lsp-diversity-05] (27 pages)
 - RSVP-TE Extensions for Associated Bidirectional LSPs [draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11] (18 pages)
 - Network Assigned Upstream-Label [draft-ietf-ccamp-network-assigned-upstream-label-00] (9 pages)
 - Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) [draft-ietf-ccamp-rsvp-te-domain-subobjects-02] (17 pages)
 - GMPLS RSVP-TE Extensions for Lock Instruct and Loopback [draft-ietf-ccamp-rsvp-te-li-lb-06] (9 pages)
 - RSVP-TE Extensions for Collecting SRLG Information [draft-ietf-ccamp-rsvp-te-srlg-collect-09] (13 pages)
 - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path [draft-ietf-ccamp-te-metric-recording-04] (15 pages)
 - Extensions to Resource Reservation Protocol For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs [draft-ietf-mpls-p2mp-loose-path-reopt-01] (15 pages)
 - Extensions to RSVP-TE for LSP Egress Local Protection [draft-ietf-mpls-rsvp-egress-protection-02] (16 pages)
 - Extensions to RSVP-TE for LSP Ingress Local Protection [draft-ietf-mpls-rsvp-ingress-protection-02] (23 pages)
 - Framework for Abstraction and Control of Traffic Engineered Networks [draft-ietf-teas-actn-framework-11] (37 pages)
 - Information Model for Abstraction and Control of TE Networks (ACTN) [draft-ietf-teas-actn-info-model-07] (24 pages)
 - Requirements for Abstraction and Control of TE Networks [draft-ietf-teas-actn-requirements-08] (12 pages)
 - Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks [draft-ietf-teas-actn-yang-00] (17 pages)
 - Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) [draft-ietf-teas-assoc-corouted-bidir-frr-02] (16 pages)
 - Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) [draft-ietf-teas-fast-lsps-requirements-02] (9 pages)
 - Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs) [draft-ietf-teas-gmpls-lsp-fastreroute-12] (24 pages)
 - RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing [draft-ietf-teas-gmpls-resource-sharing-proc-08] (15 pages)
 - Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) [draft-ietf-teas-gmpls-scsi-04] (7 pages)
 - Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks [draft-ietf-teas-interconnected-te-info-exchange-07] (67 pages)
 - Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) [draft-ietf-teas-lsp-attribute-ro-05] (15 pages)
 - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route [draft-ietf-teas-lsp-diversity-09] (25 pages)
 - RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) [draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07] (20 pages)
 - Network Assigned Upstream-Label [draft-ietf-teas-network-assigned-upstream-label-12] (9 pages)
 - RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) [draft-ietf-teas-p2mp-loose-path-reopt-09] (17 pages)
 - An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control [draft-ietf-teas-pce-central-control-05] (25 pages)
 - The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs [draft-ietf-teas-pcecc-use-cases-01] (23 pages)
 - Extensions to RSVP-TE for LSP Egress Local Protection [draft-ietf-teas-rsvp-egress-protection-09] (18 pages)
 - Extensions to RSVP-TE for LSP Ingress FRR Protection [draft-ietf-teas-rsvp-ingress-protection-12] (25 pages)
 - Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [draft-ietf-teas-rsvp-te-domain-subobjects-05] (18 pages)
 - GMPLS RSVP-TE Extensions for Lock Instruct and Loopback [draft-ietf-teas-rsvp-te-li-lb-05] (9 pages)
 - Techniques to Improve the Scalability of RSVP Traffic Engineering Deployments [draft-ietf-teas-rsvp-te-scaling-rec-08] (11 pages)
 - RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information [draft-ietf-teas-rsvp-te-srlg-collect-08] (16 pages)
 - Architecture for Scheduled Use of Resources [draft-ietf-teas-scheduled-resources-05] (19 pages)
 - Recommendations for RSVP-TE and Segment Routing LSP co-existence [draft-ietf-teas-sr-rsvp-coexistence-rec-01] (11 pages)
 - Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions [draft-ietf-teas-te-express-path-05] (10 pages)
 - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path [draft-ietf-teas-te-metric-recording-06] (17 pages)
 - Yang model for requesting Path Computation [draft-ietf-teas-yang-path-computation-00] (44 pages)
 - A YANG Data Model for Resource Reservation Protocol (RSVP) [draft-ietf-teas-yang-rsvp-08] (47 pages)
 - A YANG Data Model for RSVP-TE [draft-ietf-teas-yang-rsvp-te-02] (44 pages)
 - A YANG Data Model for Traffic Engineering Tunnels and Interfaces [draft-ietf-teas-yang-te-10] (151 pages)
 - YANG Data Model for Traffic Engineering (TE) Topologies [draft-ietf-teas-yang-te-topo-13] (134 pages)
 - Requirements for Abstraction and Control of Transport Networks [draft-lee-teas-actn-requirements-01] (22 pages)
 - YANG Data Model for Layer 3 TE Topologies [draft-liu-teas-yang-l3-te-topo-05] (37 pages)
 - YANG Data Model for SR and SR TE Topologies [draft-liu-teas-yang-sr-te-topo-04] (16 pages)
 - YANG Data Model for TE Topologies [draft-liu-teas-yang-te-topo-01] (50 pages)
 - A YANG Data Model for Resource Reservation Protocol (RSVP) [draft-saad-teas-yang-rsvp-02] (66 pages)
 - A YANG Data Model for Traffic Engineering Tunnels and Interfaces [draft-saad-teas-yang-te-02] (84 pages)
 - Recommendations for RSVP-TE and Segment Routing LSP co-existence [draft-sitaraman-sr-rsvp-coexistence-rec-02] (10 pages)
 - CCDR Scenario, Simulation and Suggestion [draft-wang-teas-ccdr-05] (12 pages)
 - PCE in Native IP Network [draft-wang-teas-pce-native-ip-07] (11 pages)
 - Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks [draft-zhang-teas-actn-yang-05] (17 pages)
 - An Architecture for Use of PCE and PCEP in a Network with Central Control [draft-zhao-teas-pce-control-function-01] (21 pages)

Requests for Comments:
 BCP206: Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks (67 pages)
 RFC7551: RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) (20 pages)
 RFC7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) (15 pages)
 RFC7571: GMPLS RSVP-TE Extensions for Lock Instruct and Loopback (9 pages)
 RFC7709: Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) (9 pages)
 RFC7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions (10 pages)
 RFC7898: Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) (18 pages)
 RFC7926: Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks (67 pages)
 RFC8001: RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information (16 pages)
 RFC8131: RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing (15 pages)
 RFC8149: RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) (17 pages)
 RFC8258: Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) (7 pages)
 RFC8271: Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs) (24 pages)
          * Updates RFC4090
 RFC8283: An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control (25 pages)



Transparent Interconnection of Lots of Links (trill)
----------------------------------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Jon Hudson <[email protected]>
    Susan Hares <[email protected]>

Routing Area Directors:
    Alia Atlas <[email protected]>
    Deborah Brungard <[email protected]>
    Alvaro Retana <[email protected]>

Routing Area Advisor:
    Alia Atlas <[email protected]>

Secretary:
    Donald Eastlake <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/trill
    Archive:            https://mailarchive.ietf.org/arch/browse/trill/

Description of Working Group:

 The TRILL WG has specified a solution for transparent unicast
 shortest-path and multi-destination frame routing in multi-hop
 networks with arbitrary topology. End stations, including Layer 3
 routers, connected to TRILL switches are assumed to be IEEE 802.1Q
 compliant end stations. TRILL switches may be interconnected with
 multi-access or point-to-point links of arbitrary technology.

 The current work of the working group is around operational support
 and additional extensions and optimizations of TRILL for the
 properties of the networks on which it is deployed. The TRILL WG may
 also produce corrections, clarifications, and updates of existing
 TRILL RFCs.

 The WG will work on the following items:

 (1) Following on from the TRILL OAM requirements (RFC 6905), specify a
 framework and specific protocols for the handling of Operations,
 Administration, and Maintenance (OAM) in networks using TRILL,
 focusing on fault management and performance and preferring existing
 OAM mechanisms that might apply to TRILL, such as SNMP, Netconf/Yang
 and mechanisms based on the IEEE 802.1 CFM framework.

 (2) Specify protocols to support "active-active" service to end
 stations that are multiply connected to a TRILL campus to provide them
 with flow level traffic spreading and rapid adaptation to link failure
 similar to that provided by TRILL for TRILL switches.

 (3) Develop, within the TRILL protocol context, protocol
 specifications for broadcast/multicast (multi-destination) frame
 reduction. Examples: protocol extensions supporting replacement of
 broadcast/multicast by unicast where appropriate; ARP/ND (Neighbor
 Discovery) reduction through extensions to the TRILL ESADI protocol.

 (4) Specify protocols for TRILL over pseudowires and TRILL over IP
 tunnels, for example to connect branch office TRILL switches to a
 central TRILL campus over the Internet.

 (5) Specify extensions to the TRILL protocol to support multi-level
 routing to improve scaling and multi-topology routing to provide
 different topologies for different classes or types of traffic, based
 existing IS-IS multi-level and multi-topology routing facilities.

 (6) Specify a reduced TRILL control plane protocol for
 interconnection, with improved error isolation, between TRILL campuses
 under coordinated management.

 (7) Analyze the use of IS-IS security (RFC 5310) in TRILL and
 determine if any work is needed to accommodate any specific TRILL
 control or data plane security leveraging IS-IS security.

 (8) Produce an interoperability / implementation report for TRILL.

 The TRILL WG will continue to work with other IETF working groups such
 as the ISIS WG, and SDO groups such as IEEE 802.1 through established
 inter-WG relationships and SDO liaison processes, including early and
 WG last call review by the ISIS WG of documents extending IS-IS
 routing.


Goals and Milestones:
 Done     - Accept base protocol specification as a WG document
 Done     - Accept problem statement and applicability as a WG work item
 Done     - Choose routing protocol(s) that can meet the requirements
 Done     - Submit problem statement and applicability to IESG for Informational RFC
 Done     - Submit base protocol specification to IEEE/IETF expert review
 Done     - Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC
 Done     - Initial WG draft on VLAN Mapping (draft-ietf-trill-rbridge-vlan-mapping)
 Done     - Initial WG draft on trill adjacency state machine (draft-ietf-trill-adj)
 Done     - Submit trill adjacency state machine to IESG for publication as Proposed Standard (draft-ietf-trill-adj)
 Done     - Submit RBridge MIB module to IESG for publication as Proposed Standard (draft-ietf-trill-rbridge-mib)
 Done     - Submit TRILL Header Options to IESG for publication as Proposed Standard (draft-ietf-trill-rbridge-options)
 Done     - Initial WG draft on RBridge OAM (draft-bond-trill-rbridge-oam)
 Done     - Initial WG draft on RBridge OAM (draft-bond-trill-rbridge-oam)
 Done     - Submit RBridge OAM requirements document to the IESG for publication
 Done     - Initial WG framework document on RBridge OAM
 Done     -  Initial WG document on RBridge OAM fault management
 Done     - Initial WG document on RBridge OAM performance management
 Done     - Initial WG draft on TRILL over IP
 Done     - Submit RBridge OAM framework document to the IESG for publication
 Done     - Submit OAM Fault Management to IESG for Proposed Standard
 Done     - Submit OAM Performance Management to IESG for Proposed Standard
 Dec 2014 - Submit Active-Active to IESG for Proposed Standard
 Done     - Initial WG draft on ARP/ND optimizations
 Dec 2015 - Submit TRILL-over-IP to IESG for Proposed Standard
 Dec 2015 - Submit Directory Assistance Mechanisms to IESG for Proposed Standard
 Jan 2016 -  Submit TRILL ARP/ND optimizations to IESG for publication as Proposed Standard
 Feb 2016 - Submit Multi-level TRILL to IESG for Proposed Standard
 Mar 2016 - Submit Multi-topology TRILL to IESG for Proposed Standard
 May 2016 - Initial WG draft on TRILL IS-IS Security
 Nov 2016 -  Submit RBridge support of Data Center Bridging to IESG for publication as Proposed Standard (draft-eastlake-trill-rbridge-dcb)
 Jul 2017 - Re-charter or shut down the WG

Internet-Drafts:
 - TRILL OAM MIB [draft-deepak-trill-oam-mib-01] (50 pages)
 - YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM) Performance Management [draft-deepak-trill-yang-pm-01] (38 pages)
 - Directory Assisted RBridge Edge [draft-dunbar-trill-directory-assisted-edge-05] (14 pages)
 - Directory Assisted TRILL Encapsulation [draft-dunbar-trill-directory-assisted-encap-08] (11 pages)
 - TRILL: Edge Directory Assistance Mechanisms [draft-dunbar-trill-scheme-for-directory-assist-06] (36 pages)
 - TRILL: RBridge Channel Tunnel Protocol [draft-eastlake-trill-channel-tunnel-00] (25 pages)
 - TRILL: ECN (Explicit Congestion Notification) Support [draft-eastlake-trill-ecn-support-01] (18 pages)
 - A Group Keying Protocol [draft-eastlake-trill-group-keying-02] (27 pages)
 - TRILL: Interface Addresses APPsub-TLV [draft-eastlake-trill-ia-appsubtlv-03] (24 pages)
 - TRILL: Multi-Topology [draft-eastlake-trill-multi-topology-02] (23 pages)
 - TRILL: Adjacency [draft-eastlake-trill-rfc6327bis-00] (39 pages)
 - TRILL: Appointed Forwarders [draft-eastlake-trill-rfc6439bis-01] (43 pages)
 - TRILL: Clarifications, Corrections, and Updates [draft-eastlake-trill-rfc7180bis-01] (52 pages)
 - TRILL: Vendor Specific TRILL Channel Protocol [draft-eastlake-trill-vendor-channel-04] (14 pages)
 - TRILL: Address Flush Message [draft-hao-trill-address-flush-01] (14 pages)
 - Centralized Replication for BUM traffic in active-active edge connection [draft-hao-trill-centralized-replication-02] (15 pages)
 - TRILL Distributed Layer 3 Gateway [draft-hao-trill-irb-05] (20 pages)
 - TRILL YANG Data Model [draft-hao-trill-yang-01] (27 pages)
 - TRILL: The ESADI Protocol [draft-hu-trill-rbridge-esadi-04] (19 pages)
 - PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol [draft-ietf-pppext-trill-protocol-08] (8 pages)
 - Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments [draft-ietf-trill-aa-multi-attach-06] (22 pages)
 - Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge [draft-ietf-trill-active-active-connection-prob-07] (13 pages)
 - TRILL: Address Flush Message [draft-ietf-trill-address-flush-05] (20 pages)
 - Routing Bridges (RBridges): Adjacency [draft-ietf-trill-adj-07] (26 pages)
 - Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization [draft-ietf-trill-arp-optimization-09] (18 pages)
 - Centralized Replication for Active-Active BUM Traffic [draft-ietf-trill-centralized-replication-13] (17 pages)
 - Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension [draft-ietf-trill-channel-tunnel-11] (25 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates [draft-ietf-trill-clear-correct-06] (24 pages)
 - Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL) [draft-ietf-trill-cmt-11] (16 pages)
 - Data Center Interconnect using TRILL [draft-ietf-trill-dci-02] (20 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms [draft-ietf-trill-directory-assist-mechanisms-12] (55 pages)
 - Directory Assisted TRILL Encapsulation [draft-ietf-trill-directory-assisted-encap-09] (15 pages)
 - TRILL Directory Extensions [draft-ietf-trill-directory-extensions-00] (10 pages)
 - Directory Assistance Problem and High-Level Design Proposal [draft-ietf-trill-directory-framework-07] (15 pages)
 - TRILL: ECN (Explicit Congestion Notification) Support [draft-ietf-trill-ecn-support-05] (20 pages)
 - Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol [draft-ietf-trill-esadi-09] (31 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling [draft-ietf-trill-fine-labeling-07] (27 pages)
 - Simple Group Keying Protocol (SGKP) [draft-ietf-trill-group-keying-01] (22 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV [draft-ietf-trill-ia-appsubtlv-09] (24 pages)
 - Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway [draft-ietf-trill-irb-14] (28 pages)
 - Simple Group Keying Protocol TRILL Use Protfiles [draft-ietf-trill-link-gk-profiles-00] (15 pages)
 - Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) [draft-ietf-trill-loss-delay-08] (32 pages)
 - Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation [draft-ietf-trill-mtu-negotiation-08] (15 pages)
 - TRILL: Multi-Topology [draft-ietf-trill-multi-topology-05] (25 pages)
 - Transparent Interconnection of Lots of Links (TRILL) Single Area Border RBridge Nickname for Multilevel [draft-ietf-trill-multilevel-single-nickname-05] (13 pages)
 - TRILL Multilevel Using Unique Nicknames [draft-ietf-trill-multilevel-unique-nickname-03] (16 pages)
 - Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires [draft-ietf-trill-o-pw-06] (11 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Fault Management [draft-ietf-trill-oam-fm-11] (63 pages)
 - Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework [draft-ietf-trill-oam-framework-04] (33 pages)
 - Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB [draft-ietf-trill-oam-mib-11] (50 pages)
 - Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) [draft-ietf-trill-oam-req-05] (13 pages)
 - TRILL (Transparent Interconnection of Lots of Links) over IP [draft-ietf-trill-over-ip-12] (46 pages)
 - TRILL Support of Point to Multipoint BFD [draft-ietf-trill-p2mp-bfd-08] (7 pages)
 - TRILL: Parent node Shifts in Tree Construction, Mitigation. [draft-ietf-trill-parent-selection-02] (9 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement [draft-ietf-trill-prob-06] (17 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access [draft-ietf-trill-pseudonode-nickname-07] (35 pages)
 - Routing Bridges (RBridges): Appointed Forwarders [draft-ietf-trill-rbridge-af-05] (15 pages)
 - The Architecture of an RBridge Solution to TRILL [draft-ietf-trill-rbridge-arch-05] (36 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support [draft-ietf-trill-rbridge-bfd-07] (12 pages)
 - Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support [draft-ietf-trill-rbridge-channel-08] (21 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Header Extension [draft-ietf-trill-rbridge-extension-05] (12 pages)
 - Definitions of Managed Objects for Routing Bridges (RBridges) [draft-ietf-trill-rbridge-mib-10] (59 pages)
 - Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL) [draft-ietf-trill-rbridge-multilevel-07] (29 pages)
 - Routing Bridges (RBridges): Operations, Administration, and Maintenance (OAM) Support [draft-ietf-trill-rbridge-oam-02] (33 pages)
 - RBridges: Further TRILL Header Extensions [draft-ietf-trill-rbridge-options-07] (19 pages)
 - Routing Bridges (RBridges): Base Protocol Specification [draft-ietf-trill-rbridge-protocol-16] (99 pages)
 - TRILL: Campus Label and Priority Regions [draft-ietf-trill-rbridge-vlan-mapping-10] (19 pages)
 - TRILL: Resilient Distribution Trees [draft-ietf-trill-resilient-trees-09] (22 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Adjacency [draft-ietf-trill-rfc6327bis-04] (35 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders [draft-ietf-trill-rfc6439bis-05] (41 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates [draft-ietf-trill-rfc7180bis-07] (57 pages)
 - TRILL Routing Requirements in Support of RBridges [draft-ietf-trill-routing-reqs-02] (11 pages)
 - TRILL Smart Endnodes [draft-ietf-trill-smart-endnodes-07] (15 pages)
 - TRILL Transparent Transport over MPLS [draft-ietf-trill-transport-over-mpls-07] (19 pages)
 - Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data [draft-ietf-trill-tree-selection-05] (22 pages)
 - TRILL: Vendor Specific TRILL Channel Protocol [draft-ietf-trill-vendor-channel-00] (14 pages)
 - TRILL YANG Data Model [draft-ietf-trill-yang-04] (26 pages)
 - YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM) [draft-ietf-trill-yang-oam-05] (21 pages)
 - YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM) Performance Management [draft-ietf-trill-yang-pm-02] (41 pages)
 - Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) [draft-mizrahi-trill-loss-delay-01] (34 pages)
 - Transparent Interconnection of Lots of Links (TRILL) over IP [draft-mrw-trill-over-ip-04] (15 pages)
 - Date Center Interconnect using TRILL [draft-muks-trill-dci-02] (20 pages)
 - TRILL Transparent Transport over MPLS [draft-muks-trill-transport-over-mpls-02] (17 pages)
 - Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links) [draft-perlman-trill-rbridge-multilevel-10] (30 pages)
 - TRILL Smart Endnodes [draft-perlman-trill-smart-endnodes-04] (10 pages)
 - TRILL: Parent node Shifts in Tree Construction, Mitigation. [draft-rp-trill-parent-selection-03] (11 pages)
 - TRILL Fault Management [draft-tissa-trill-oam-fm-02] (53 pages)
 - YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM) [draft-tissa-trill-yang-oam-00] (24 pages)
 - Problem Statement and Goals for Active-Active TRILL Edge [draft-yizhou-trill-active-active-connection-prob-02] (10 pages)
 - TRILL: ARP/ND Optimization [draft-yizhou-trill-arp-optimization-01] (10 pages)
 - TRILL Over Pseudowires [draft-yong-trill-o-pw-01] (10 pages)
 - TRILL IS-IS MTU Negotiation [draft-zhang-trill-mtu-negotiation-08] (12 pages)
 - Single Area Border RBridge Nickname for TRILL Multilevel [draft-zhang-trill-multilevel-single-nickname-01] (12 pages)
 - TRILL Multilevel Using Unique Nicknames [draft-zhang-trill-multilevel-unique-nickname-00] (14 pages)
 - TRILL Resilient Distribution Trees [draft-zhang-trill-resilient-trees-04] (19 pages)

Requests for Comments:
 RFC5556: Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement (17 pages)
 RFC6325: Routing Bridges (RBridges): Base Protocol Specification (99 pages)
          * Updates RFC6327
          * Updates RFC6439
          * Updates RFC7357
          * Updates RFC7180
          * Updates RFC7179
          * Updates RFC7177
          * Updates RFC7172
          * Updates RFC7455
          * Updates RFC7780
          * Updates RFC7783
          * Updates RFC8139
          * Updates RFC8249
 RFC6327: Routing Bridges (RBridges): Adjacency (26 pages)
          * Updates RFC6325
          * Updates RFC7180
          * Obsoletes RFC7177
 RFC6361: PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol (8 pages)
 RFC6439: Routing Bridges (RBridges): Appointed Forwarders (15 pages)
          * Updates RFC6325
          * Updates RFC7180
          * Obsoletes RFC8139
 RFC6850: Definitions of Managed Objects for Routing Bridges (RBridges) (59 pages)
 RFC6905: Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) (13 pages)
 RFC7067: Directory Assistance Problem and High-Level Design Proposal (15 pages)
 RFC7172: Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling (27 pages)
          * Updates RFC6325
 RFC7173: Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires (11 pages)
 RFC7174: Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework (33 pages)
 RFC7175: Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support (12 pages)
 RFC7177: Transparent Interconnection of Lots of Links (TRILL): Adjacency (35 pages)
          * Updates RFC6325
          * Obsoletes RFC6327
          * Updates RFC7780
          * Updates RFC8139
          * Updates RFC8249
 RFC7178: Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support (21 pages)
          * Updates RFC7978
 RFC7179: Transparent Interconnection of Lots of Links (TRILL): Header Extension (12 pages)
          * Updates RFC6325
          * Updates RFC7780
 RFC7180: Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates (24 pages)
          * Updates RFC6439
          * Updates RFC6327
          * Updates RFC6325
          * Obsoletes RFC7780
 RFC7357: Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol (31 pages)
          * Updates RFC6325
 RFC7379: Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge (13 pages)
 RFC7455: Transparent Interconnection of Lots of Links (TRILL): Fault Management (63 pages)
          * Updates RFC6325
 RFC7456: Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) (32 pages)
 RFC7780: Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates (57 pages)
          * Obsoletes RFC7180
          * Updates RFC6325
          * Updates RFC7177
          * Updates RFC7179
          * Updates RFC8249
 RFC7781: Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access (35 pages)
 RFC7782: Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments (22 pages)
 RFC7783: Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL) (16 pages)
          * Updates RFC6325
 RFC7784: Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB (50 pages)
 RFC7956: Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway (28 pages)
 RFC7961: Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV (24 pages)
 RFC7968: Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data (22 pages)
 RFC7978: Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension (25 pages)
          * Updates RFC7178
 RFC8139: Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders (41 pages)
          * Obsoletes RFC6439
          * Updates RFC6325
          * Updates RFC7177
 RFC8171: Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms (55 pages)
 RFC8243: Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL) (29 pages)
 RFC8249: Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation (15 pages)
          * Updates RFC6325
          * Updates RFC7177
          * Updates RFC7780
 RFC8302: Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization (18 pages)



Authentication and Authorization for Constrained Environments (ace)
-------------------------------------------------------------------

Charter
Last Modified: 2017-10-29

Current Status: Active

Chairs:
    Benjamin Kaduk <[email protected]>
    Jim Schaad <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Kathleen Moriarty <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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 <[email protected]>
    Yoav Nir <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Kathleen Moriarty <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Common Authentication Technology Next Generation (kitten)
---------------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Benjamin Kaduk <[email protected]>
    Matthew A. Miller <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Eric Rescorla <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



CURves, Deprecating and a Little more Encryption (curdle)
---------------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Daniel Migault <[email protected]>
    Rich Salz <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Eric Rescorla <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



DDoS Open Threat Signaling (dots)
---------------------------------

Charter
Last Modified: 2017-04-04

Current Status: Active

Chairs:
    Roman Danyliw <[email protected]>
    Tobias Gondrom <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Kathleen Moriarty <[email protected]>

Secretary:
    Liang Xia <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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
 <https://tools.ietf.org/html/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

Interface to Network Security Functions (i2nsf)
-----------------------------------------------

Charter
Last Modified: 2017-07-18

Current Status: Active

Chairs:
    Linda Dunbar <[email protected]>
    Yoav Nir <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Kathleen Moriarty <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



IP Security Maintenance and Extensions (ipsecme)
------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    David Waltermire <[email protected]>
    Tero Kivinen <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Eric Rescorla <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



Limited Additional Mechanisms for PKIX and SMIME (lamps)
--------------------------------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chair:
    Russ Housley <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Eric Rescorla <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

Managed Incident Lightweight Exchange (mile)
--------------------------------------------

Charter
Last Modified: 2016-04-20

Current Status: Active

Chairs:
    Nancy Cam-Winget <[email protected]>
    Takeshi Takahashi <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Kathleen Moriarty <[email protected]>

Secretary:
    David Waltermire <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Public Notary Transparency (trans)
----------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Melinda Shore <[email protected]>
    Paul Wouters <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Eric Rescorla <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/trans
    Archive:            https://mailarchive.ietf.org/arch/browse/trans/

Description of Working Group:

 Mitigating web site certificate mis-issuance is the initial problem of
 interest for this working group. Certificate Transparency (CT,
 RFC6962) allows such mis-issuance to be detected in interesting and
 useful cases, for example by an auditor acting for the web site, or
 one acting to check general CA behaviour. The working group will
 produce a standards-track version of the experimental RFC 6962
 for HTTP over TLS, reflecting implementation and deployment
 experience since that specification was completed.

 Many Internet protocols for example, SMTPS, IPsec, DNSSEC,
 OpenPGP and HTTPS, require  a mapping between some kind of
 identifier and some kind of public key. These protocols rely
 on either ad-hoc mappings, (as in a web of trust), or on authorities
 (such as CAs) that attest to the mappings. History shows that neither
 of these mechanisms is entirely satisfactory.  Ad-hoc mappings are
 difficult to discover and maintain, and authorities make mistakes or
 are subverted.

 Cryptographically verifiable logs can help to ameliorate these
 problems by making it possible to discover errors quickly, so that
 other mechanisms can be applied to rectify them. A cryptographically
 verifiable log is an append-only log of hashes of more-or-less anything
 that  is structured in such a way as to provide efficiently-accessible,
 cryptographically-supported evidence of correct log behaviour. For
 example, RFC 6962 says: "The append-only property of each log is
 technically achieved using Merkle Trees, which can be used to show
 that any particular version of the log is a superset of any particular
 previous version. Likewise, Merkle Trees avoid the need to blindly
 trust logs: if a log attempts to show different things to different
 people, this can be efficiently detected by comparing tree roots and
 consistency proofs. Similarly, other misbehaviors of any log (e.g.,
 issuing signed timestamps for certificates they then don't log) can be
 efficiently detected and proved to the world at large."

 These logs can potentially also assist with other interesting
 problems, such as how to assure end users that software they are
 running is, indeed, the software they intend to run.

 While the privacy issues related to use of RFC6962 for public
 web sites are minimal, the working group will consider privacy
 as it might impact on uses of CT e.g. within enterprises or
 for other uses of logs.

 Work items:

 - Publish an update to RFC 6962 as a standards-track mechanism to
 apply verifiable logs to HTTP over TLS.  As DANE (RFC6698) provides an
 alternative keying infrastructure to that used in the current web PKI,
 the working group should consider appropriate client behavior in the
 presence of both DANE-based keying and current web PKI when
 standardising CT.

 - Discuss mechanisms and techniques that allow cryptographically
 verifiable logs to be deployed to improve the security of protocols
 other than HTTP over TLS, for example SMTP/TLS or software
 distribution. Where such mechanisms appear sufficiently useful,
 the WG will re-charter to add relevant new work items.  Should
 no such items be chartered the WG will close when documents
 associated with the first work item are complete.



Goals and Milestones:
 Dec 2015 - 6962bis to IESG
 Jul 2016 - Threat analysis to working group last call
 Oct 2016 - Gossip draft to working group last call

Internet-Drafts:
 - Gossiping in CT [draft-ietf-trans-gossip-05] (57 pages)
 - Certificate Transparency Version 2.0 [draft-ietf-trans-rfc6962-bis-27] (55 pages)
 - Attack and Threat Model for Certificate Transparency [draft-ietf-trans-threat-analysis-12] (30 pages)

No Requests for Comments

Security Automation and Continuous Monitoring (sacm)
----------------------------------------------------

Charter
Last Modified: 2017-10-19

Current Status: Active

Chairs:
    Adam W. Montville <[email protected]>
    Christopher Inacio <[email protected]>
    Karen O'Donoghue <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Kathleen Moriarty <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/sacm
    Archive:            https://mailarchive.ietf.org/arch/browse/sacm/

Description of Working Group:

 Securing information and the systems that store, process, and transmit that information is a challenging task for enterprises of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols and models aiding collection and evaluation of endpoint elements enable automation, thus freeing practitioners to focus on high priority tasks.  Due to the breadth of this work, the working group will address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). In alignment with RFC 5209, a network device is an endpoint.

 Posture assessment entails the following five steps which the working will create solutions to automate:

 1. Identify and characterize target endpoints
 2. Determine specific endpoint elements to assess
 3. Collect and make available specified elements' actual values
 4. Compare actual element values to policy compliant element values
 5. Make results available

 This working group will focus on collection, evaluation, and orchestration and communication, as described herein.

 A. Collection. The WG will define a standardized way to provide two types of guidance to collectors over varying collection mechanisms:

 1) Which target endpoints to collect from, and
 2) What elements to collect from these target endpoints.

 A set of instructions (such as vulnerability description data, YANG filter expressions, Windows Management Instrumentation classes, etc.) can be brokered to the appropriate collectors using the control plane functions defined by "C. Orchestration and Communication" (below). Element collection from different sources may require orchestrating functions that go beyond the set of capabilities a collector can provide.  This will inform the requirements and characteristics for "C. Orchestration and Communication". The working group recognizes that manual configuration of targets and corresponding collection profiles will not scale and does not seem to be a viable option.

 B. Evaluation. The working group will standardize a criteria language enabling evaluation of actual endpoint posture information against desired endpoint posture information to produce a standardized result. This extensible language will support complex Boolean statements, comparison operators, logical flow statements, and functions for string manipulation. Additionally, the working group will seek to discover an approach that allows data from any posture collection mechanism to be generically evaluated.

 C. Orchestration and Communication. The working group will define a set of control plane functions to enable the orchestration between element collectors. These element collectors can then provide the requisite elements sought by posture collectors, posture evaluators, and data repositories.

 Specific work items may include the following:

 - Define a way to provide three types of guidance to the correct SACM collectors: 1) Which target endpoints to collect from and 2) what to collect from these target endpoints, and 3) how quickly after an attribute change information must be collected. When applied, a set of instructions, such as vulnerability description data or YANG expressions, can be brokered to the appropriate collectors.

 - Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html] to collect and deliver information about firmware, operating systems, and software installed on an endpoint.

 - Describe a criteria language capable of being evaluated against endpoint posture information to produce a standardized result. The language will support complex Boolean statements, comparison operators, and functions for string manipulation; and will be extensible enough to be applicable to the full range of collected posture attributes. Additionally, this document will describe an approach that allows data from any posture collection mechanism to be evaluated.

 - Define a control plane function to enable the discovery and orchestration between devices that can provide the requisite information sought by posture collectors, posture evaluators or both. For example, XMPP capable host/endpoint interactions may be defined through XMPP control plane and data transfer protocol extensions.  Likewise, the asynchronous push of selected attributes on switches and routers may be framed using YANG Push for periodic and on-change triggers.

 - Define a method of expressing software metadata that is suitable for use by constrained devices including a CBOR-based format derived from the ISO/IEC 19770-2 Software Identification (SWID) tag standard.

 - Define best practices for the collection of posture information from endpoints and its delivery to a collector, from which it can be distributed using the SACM messaging standards.

 - Extend existing standards for information exchange to support the sharing of software, configuration information, and other forms of guidance including extensions to the Resource-Oriented Lightweight Information Exchange (ROLIE).

 - Describe a SACM Information Model and a SACM Architecture including protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system.

Goals and Milestones:
 Dec 2017 - Submit SWIMA to IESG
 Jan 2018 - WGLC ROLIE software descriptor
 Jan 2018 - WGLC ROLIE configuration checklist information type
 Jan 2018 - WGLC CoSWID
 Jan 2018 - WGLC Endpoint Compliance Profile
 Jan 2018 - Initial Draft on SACM Architecture
 Mar 2018 - Submit ROLIE software descriptor to IESG
 Mar 2018 - Submit ROLIE configuration checklist information type to IESG
 Mar 2018 - Submit CoSWID to IESG
 May 2018 - Initial Draft on ECP over transfer mechanism
 May 2018 - Initial Draft on YANG-push over transfer mechanism

Internet-Drafts:
 - Definition of the ROLIE Software Descriptor Extension [draft-banghart-sacm-rolie-softwaredescriptor-01] (10 pages)
 - Concise Software Identifiers [draft-birkholz-sacm-coswid-01] (13 pages)
 - Software Inventory Message and Attributes (SWIMA) for PA-TNC [draft-coffin-sacm-nea-swid-patnc-03] (85 pages)
 - SACM Vulnerability Assessment Scenario [draft-coffin-sacm-vuln-scenario-01] (29 pages)
 - Endpoint Compliance Profile [draft-haynes-sacm-ecp-02] (36 pages)
 - Secure Automation and Continuous Monitoring (SACM) Architecture [draft-ietf-sacm-architecture-05] (20 pages)
 - Concise Software Identifiers [draft-ietf-sacm-coswid-03] (26 pages)
 - Endpoint Compliance Profile [draft-ietf-sacm-ecp-01] (42 pages)
 - Endpoint Compliance Standard [draft-ietf-sacm-fitzgeraldmckay-endpointcompliance-00] (6 pages)
 - SACM Information Model [draft-ietf-sacm-information-model-10] (158 pages)
 - Software Inventory Message and Attributes (SWIMA) for PA-TNC [draft-ietf-sacm-nea-swid-patnc-01] (91 pages)
 - Software Inventory Message and Attributes (SWIMA) for PA-TNC [draft-ietf-sacm-nea-swima-patnc-01] (92 pages)
 - Security Automation and Continuous Monitoring (SACM) Requirements [draft-ietf-sacm-requirements-18] (20 pages)
 - Definition of the ROLIE Software Descriptor Extension [draft-ietf-sacm-rolie-softwaredescriptor-00] (10 pages)
 - Security Automation and Continuous Monitoring (SACM) Terminology [draft-ietf-sacm-terminology-14] (28 pages)
 - Endpoint Security Posture Assessment: Enterprise Use Cases [draft-ietf-sacm-use-cases-10] (23 pages)
 - SACM Vulnerability Assessment Scenario [draft-ietf-sacm-vuln-scenario-02] (24 pages)

Requests for Comments:
 RFC7632: Endpoint Security Posture Assessment: Enterprise Use Cases (23 pages)
 RFC8248: Security Automation and Continuous Monitoring (SACM) Requirements (20 pages)



Security Events (secevent)
--------------------------

Charter
Last Modified: 2016-11-30

Current Status: Active

Chairs:
    Dick Hardt <[email protected]>
    Yaron Sheffer <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Kathleen Moriarty <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/id-event
    Archive:            https://mailarchive.ietf.org/arch/browse/id-event/

Description of Working Group:

 Many HTTP web services and APIs depend on a web security infrastructure that:
   * identifies security subjects and regulates their access to services
   * and provides profile and rights information to applications.

 Examples are systems that leverage user-agent session cookies
 (RFC6265), and OAuth2 (RFC6749). In order to prevent or mitigate
 security risks, or to provide out-of-band information as
 necessary, these systems need to share security event messages.
 For example, an OAuth authorization server, having received a
 token revocation request (RFC7009) may need to inform affected
 resource servers; a cloud provider may wish to inform another
 cloud provider of suspected fraudulent use of identity
 information; an identity provider may wish to signal a session
 logout to a relying party and does not wish to rely solely upon
 clearing a session cookie.

 It is expected that several identity and security working groups and
 organizations will use Identity Event Tokens to describe area-specific
 events such as: SCIM Provisioning Events, OpenID RISC Events, and
 OpenID Connect Backchannel Logout, among others.

 The Security Events working group will produce a standards-track Event
 Token specification that includes:
  - A JWT extension for expressing security events
  - A syntax that enables event-specific data to be conveyed
 This Event Token specification will be event transport independent.

 The working group will also develop a simple standards-track Event
 Delivery specification that includes:
  - A mechanism for delivering events using HTTP POST (push)
  - Metadata for describing event feeds
  - Methods for subscribing to and managing event feeds
  - Methods for validating event feed subscriptions


Goals and Milestones:
 Feb 2017 - Initial adoption of event token and event delivery drafts
 Jun 2017 - WG last call of event token draft
 Aug 2017 - Event token draft to IESG as a Proposed Standard
 Nov 2017 - WG last call of event delivery draft
 Jan 2018 - Event delivery draft to IESG as a Proposed Standard
 Mar 2018 - Recharter or Conclude

Internet-Drafts:
 - SET Token Distribution and Subscription Management Profile [draft-hunt-idevent-distribution-01] (30 pages)
 - Security Event Token (SET) [draft-hunt-idevent-token-08] (18 pages)
 - SET Token Delivery Using HTTP [draft-ietf-secevent-delivery-01] (26 pages)
 - Security Event Token (SET) [draft-ietf-secevent-token-05] (26 pages)

No Requests for Comments

Software Updates for Internet of Things (suit)
----------------------------------------------

Charter
Last Modified: 2017-12-15

Current Status: Active

Chairs:
    Dave Thaler <[email protected]>
    David Waltermire <[email protected]>
    Russ Housley <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Kathleen Moriarty <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/suit
    Archive:            https://mailarchive.ietf.org/arch/search/?email_list=suit

Description of Working Group:

 Vulnerabilities in Internet of Things (IoT) devices have raised the need
 for a secure firmware update mechanism that is also suitable for constrained
 devices.  Security experts, researchers, and regulators recommend that all IoT
 devices be equipped with such a mechanism.  While there are many proprietary
 firmware update mechanisms in use today, there is no modern interoperable
 approach allowing secure updates to firmware in IoT devices. In June of 2016
 the Internet Architecture Board organized a workshop on 'Internet
 of Things (IoT) Software Update (IOTSU)', and RFC 8240 documents various
 requirements and challenges that are specific to IoT devices.

 A firmware update solution consists of several components, including:
 * A mechanism to transport firmware images to compatible devices.
 * A manifest that provides meta-data about the firmware image (such as a
 firmware package identifier, the hardware the package needs to run, and
 dependencies on other firmware packages), as well as cryptographic information
 for protecting the firmware image in an end-to-end fashion.
 * The firmware image itself.

 This group will focus on defining a firmware update solution (taking into
 account past learnings from RFC 4108 and other firmware update solutions) that
 will be usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with
 ~10 KiB RAM and ~100 KiB flash.  The solution may apply to more capable devices
 as well.  This group will not define any new transport or discovery mechanisms,
 but may describe how to use existing mechanisms within the architecture.

 In particular this group aims to publish several documents, namely:
 * An IoT firmware update architecture that includes a description of the
 involved entities, security threats, and assumptions.
 * One or more manifest format specifications.

 To support specification of manifest format(s), this group will first develop the
 information model for the contents of a manifest. Once there is general agreement
 on the contents, the group will pick a small number of serialization formats such as
 CBOR and/or ASN.1 (and their associated cryptographic mechanisms) to encode the
 manifest. A small number of formats is preferred to reduce the complexity of a
 firmware management solution, where each IoT device would typically only
 support one format, but the same tool or service might support all such
 formats. To support a wide range of deployment scenarios, the formats are
 expected to be expressive enough to allow the use of different firmware sources
 and permission models.

 This group does not aim to create a standard for a generic application software
 update mechanism, but instead this group will focus on firmware development
 practices in the embedded industry. Software update solutions that target
 updating software other than the firmware binaries (e.g., applications) are
 also out of scope.

 This group will aim to maintain a close relationship with silicon vendors and
 OEMs that develop IoT operating systems.

Goals and Milestones:
 Jan 2018 - Adopt "Architecture" document as WG item.
 Mar 2018 - Adopt a manifest information model as a WG item.
 Mar 2018 - Calendar item: First interoperability event at IETF 101.
 Mar 2018 - Adopt initial manifest serialization format(s) as WG item(s).
 Jul 2018 - Calendar item: Second interoperability event at IETF 102.
 Jul 2018 - Submit manifest information model to the IESG for publication as Informational.
 Nov 2018 - Submit an initial manifest serialization format to the IESG for publication as a Proposed Standard.

Internet-Drafts:

No Requests for Comments

Token Binding (tokbind)
-----------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    John Bradley <[email protected]>
    Leif Johansson <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Eric Rescorla <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/unbearable
    Archive:            https://mailarchive.ietf.org/arch/browse/unbearable/

Description of Working Group:


 Web services generate various security tokens (e.g. HTTP cookies, OAuth tokens, etc.) for web applications to access protected resources. Currently these are bearer tokens, i.e. any party in possession of such token gains access to the protected resource. Attackers export bearer tokens from client machines or from compromised network connections, present these bearer tokens to Web services, and impersonate authenticated users. Token Binding enables defense against such attacks by  cryptographically binding security tokens to a secret held by the client.

 The tasks of this working group are as follows:

 1. Specify the Token Binding protocol v1.0.
 2. Specify the use of the Token Binding protocol in combination with HTTPS.

 It is a goal of this working group to enable defense against attacks that involve unauthorized replay of security tokens. Other issues associated with the use of security tokens are out of scope. Another goal of this working group is to design the Token Binding protocol such that it would be also useable with application protocols other than HTTPS. Specifying alternative application protocols is not a primary goal.

 The main design objectives for the Token Binding protocol, in no particular order:

 1. Allow applications and services to prevent unauthorized replay of security tokens.
 2. Allow strong key protection, e.g. using hardware-bound keys.
 3. Support both first-party (server generates a token for later use with this server) and federation (server generates a token for use with another server) scenarios.
 4. Preserve user privacy.
 5. Make the Token Binding protocol useable in combination with a variety of application protocols.
 6. Allow the negotiation of the Token Binding protocol without additional round-trips.
 7. Allow the use of multiple cryptographic algorithms, so that a variety of secure    hardware modules with different cryptographic capabilities could be used with Token Binding.
 8. Propose Token Binding specification that can be implemented in Web browsers (but is not limited to them). E.g. Web browsers require that the same bound security token must be presentable over multiple TLS sessions and connections.

 The working group will use the following documents as a starting point for its work:

 - draft-popov-token-binding-00;
 - draft-balfanz-https-token-binding-00.

 This WG will collaborate with other IETF WGs, in particular with the TLS, HTTPbis and Oauth WGs and with the W3C webappsec WG.


Goals and Milestones:
 Mar 2015 - WG document for the Token Binding Protocol v1.0.
 Mar 2015 - WG document for HTTPS Token Binding.
 May 2015 - TLS extension for Token Binding as WG document
 Dec 2017 - HTTPS Token Binding to IESG.
 Dec 2017 - Token Binding Protocol v1.0 to IESG.

Internet-Drafts:
 - Token Binding over HTTP [draft-balfanz-https-token-binding-00] (9 pages)
 - Token Binding over HTTP [draft-ietf-tokbind-https-12] (24 pages)
 - Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation [draft-ietf-tokbind-negotiation-10] (8 pages)
 - The Token Binding Protocol Version 1.0 [draft-ietf-tokbind-protocol-16] (17 pages)
 - Token Binding for Transport Layer Security (TLS) Version 1.3 Connections [draft-ietf-tokbind-tls13-00] (4 pages)
 - Token Binding for 0-RTT TLS 1.3 Connections [draft-ietf-tokbind-tls13-0rtt-02] (11 pages)
 - HTTPS Token Binding with TLS Terminating Reverse Proxies [draft-ietf-tokbind-ttrp-02] (11 pages)
 - The Token Binding Protocol Version 1.0 [draft-popov-token-binding-00] (13 pages)

No Requests for Comments

Transport Layer Security (tls)
------------------------------

Charter
Last Modified: 2017-03-29

Current Status: Active

Chairs:
    Joseph A. Salowey <[email protected]>
    Sean Turner <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Kathleen Moriarty <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/tls
    Archive:            https://mailarchive.ietf.org/arch/browse/tls/

Description of Working Group:

 The TLS (Transport Layer Security) working group was
 established in 1996 to standardize a 'transport layer'
 security protocol.  The basis for the work was SSL
 (Secure Socket Layer) v3.0 [RFC6101].  The TLS
 working group has completed a series of specifications
 that describe the TLS protocol v1.0 [RFC2246],
 v1.1 [RFC4346], and v1.2 [RFC5346] and DTLS
 (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347]
 as well as extensions to the protocols and ciphersuites.

 The primary purpose of the working group is to develop
 (D)TLS v1.3.  Some of the main design goals are as follows,
 in no particular order:

 o Develop a mode that encrypts as much of the handshake as
 is possible to reduce the amount of observable data to
 both passive and active attackers.

 o Develop modes to reduce handshake latency, which primarily
 support HTTP-based applications, aiming for one roundtrip
 for a full handshake and one or zero roundtrip for repeated
 handshakes.   The aim is also to maintain current security
 features.

 o Update record payload protection cryptographic
 mechanisms and algorithms to address known weaknesses
 in the CBC block cipher modes and to replace RC4.

 o Reevaluate handshake contents, e.g.,: Is time needed in
 client hello?  Should signature in server key exchange
 cover entire handshake?  Are bigger randoms required?
 Should there be distinct cipher list for each version?  Are
 additional mechanisms needed to prevent version rollback
 needed?

 o The WG will consider the privacy implications of
 TLS1.3 and where possible (balancing with other requirements)
 will aim to make TLS1.3 more privacy-friendly, e.g. via more
 consistent application traffic padding, more considered use
 of long term identifying values, etc.

 A secondary purpose is to maintain previous version of
 the (D)TLS protocols as well as to specify the use of
 (D)TLS, recommendations for use of (D)TLS, extensions to
 (D)TLS, and cipher suites.  However, changes or additions
 to older versions of (D)TLS whether via extensions or
 ciphersuites are discouraged and require significant
 justification to be taken on as work items.

 With these objectives in mind, the TLS WG will also place a priority
 in minimizing gratuitous changes to TLS.

Goals and Milestones:
 Done - See RFC 7525 & MTI AEAD algs in TLS1.3     - CBC Fixes to IESG
 Done - See RFC 7465 & RFC 7905     - RC4 replacement to IESG
 Feb 2017 - (D)TLS 1.3 to IESG
 Feb 2017 - Move ECC-based CS to Standards Track
 May 2017 - DANE Record and DNSSEC Authentication Chain Extension for TLS to IESG
 Aug 2017 - DTLS1.3 to IESG

Internet-Drafts:
 - Transport Layer Security (TLS) False Start [draft-bmoeller-tls-falsestart-01] (11 pages)
 - Applying GREASE to TLS Extensibility [draft-davidben-tls-grease-01] (8 pages)
 - Transport Layer Security (TLS) Certificate Compression [draft-ghedini-tls-certificate-compression-00] (6 pages)
 - SNI Encryption in TLS Through Tunneling [draft-huitema-tls-sni-encryption-02] (22 pages)
 - 56-bit Export Cipher Suites For TLS [draft-ietf-tls-56-bit-ciphersuites-01] (3 pages)
 - An Internet AttributeCertificate Profile for Authorization [draft-ietf-tls-ac509prof-00] (11 pages)
 - Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension [draft-ietf-tls-applayerprotoneg-05] (9 pages)
 - TLS extensions for AttributeCertificate based authorization [draft-ietf-tls-attr-cert-01] (11 pages)
 - Transport Layer Security (TLS) Cached Information Extension [draft-ietf-tls-cached-info-23] (19 pages)
 - Addition of Camellia Cipher Suites to Transport Layer Security (TLS) [draft-ietf-tls-camellia-06] (7 pages)
 - Transport Layer Security (TLS) Certificate Compression [draft-ietf-tls-certificate-compression-02] (7 pages)
 - ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-chacha20-poly1305-04] (8 pages)
 - Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) [draft-ietf-tls-ciphersuite-06] (7 pages)
 - Transport Layer Security Protocol Compression Methods [draft-ietf-tls-compression-07] (8 pages)
 - AES Counter Mode Cipher Suites for TLS and DTLS [draft-ietf-tls-ctr-01] (10 pages)
 - Curve25519 and Curve448 for Transport Layer Security (TLS) [draft-ietf-tls-curve25519-01] (11 pages)
 - TLS Delegation Protocol [draft-ietf-tls-delegation-01] (10 pages)
 - DES and IDEA Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-des-idea-02] (4 pages)
 - A DANE Record and DNSSEC Authentication Chain Extension for TLS [draft-ietf-tls-dnssec-chain-extension-06] (20 pages)
 - TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks [draft-ietf-tls-downgrade-scsv-05] (8 pages)
 - The Datagram Transport Layer Security (DTLS) Connection Identifier [draft-ietf-tls-dtls-connection-id-00] (12 pages)
 - Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension [draft-ietf-tls-dtls-heartbeat-04] (9 pages)
 - The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 [draft-ietf-tls-dtls13-22] (41 pages)
 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-ecc-12] (35 pages)
 - TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) [draft-ietf-tls-ecc-new-mac-07] (6 pages)
 - ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-ecdhe-psk-05] (7 pages)
 - ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2 [draft-ietf-tls-ecdhe-psk-aead-05] (7 pages)
 - Update to Transport Layer Security (TLS) Extensions [draft-ietf-tls-emailaddr-00] (4 pages)
 - Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-ietf-tls-encrypt-then-mac-03] (7 pages)
 - Exported Authenticators in TLS [draft-ietf-tls-exported-authenticator-05] (9 pages)
 - Transport Layer Security (TLS) Extensions [draft-ietf-tls-extensions-06] (29 pages)
 - Keying Material Exporters for Transport Layer Security (TLS) [draft-ietf-tls-extractor-07] (7 pages)
 - Transport Layer Security (TLS) False Start [draft-ietf-tls-falsestart-02] (11 pages)
 - Applying GREASE to TLS Extensibility [draft-ietf-tls-grease-00] (8 pages)
 - Upgrading to TLS Within HTTP/1.1 [draft-ietf-tls-http-upgrade-05] (13 pages)
 - HTTP Over TLS [draft-ietf-tls-https-03] (7 pages)
 - IANA Registry Updates for TLS and DTLS [draft-ietf-tls-iana-registry-updates-03] (16 pages)
 - Clientside interoperability experiences for the SSL and TLS protocols [draft-ietf-tls-interoperability-00] (30 pages)
 - Kerberos Cipher Suites in Transport Layer Security (TLS) [draft-ietf-tls-kerb-01] (0 pages)
 - Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) [draft-ietf-tls-kerb-cipher-suites-04] (7 pages)
 - Addition of MISTY1 to TLS [draft-ietf-tls-misty1-01] (3 pages)
 - The Transport Layer Security (TLS) Multiple Certificate Status Request Extension [draft-ietf-tls-multiple-cert-status-extension-08] (10 pages)
 - Negotiated Discrete Log Diffie-Hellman Ephemeral Parameters for TLS [draft-ietf-tls-negotiated-dl-dhe-00] (19 pages)
 - Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) [draft-ietf-tls-negotiated-ff-dhe-10] (29 pages)
 - NTRU Cipher Suites for TLS [draft-ietf-tls-ntru-00] (15 pages)
 - Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-ietf-tls-oob-pubkey-11] (18 pages)
 - Extensions to TLS for OpenPGP keys [draft-ietf-tls-openpgp-02] (4 pages)
 - Using OpenPGP Keys for Transport Layer Security (TLS) Authentication [draft-ietf-tls-openpgp-keys-11] (8 pages)
 - A Transport Layer Security (TLS) ClientHello Padding Extension [draft-ietf-tls-padding-04] (4 pages)
 - Addition of Shared Key Authentication to Transport Layer Security (TLS) [draft-ietf-tls-passauth-00] (5 pages)
 - TLS Pathsec Protocol
[draft-ietf-tls-pathsec-00] (50 pages)
 - Prohibiting RC4 Cipher Suites [draft-ietf-tls-prohibiting-rc4-01] (6 pages)
 - The TLS Protocol Version 1.0 [draft-ietf-tls-protocol-06] (80 pages)
 - Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) [draft-ietf-tls-psk-09] (15 pages)
 - Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode [draft-ietf-tls-psk-new-mac-aes-gcm-05] (7 pages)
 - Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) [draft-ietf-tls-psk-null-03] (5 pages)
 - Secure Password Ciphersuites for Transport Layer Security (TLS) [draft-ietf-tls-pwd-07] (36 pages)
 - Record Size Limit Extension for Transport Layer Security (TLS) [draft-ietf-tls-record-limit-01] (7 pages)
 - Transport Layer Security (TLS) Renegotiation Indication Extension [draft-ietf-tls-renegotiation-03] (15 pages)
 - The Transport Layer Security (TLS) Protocol Version 1.1 [draft-ietf-tls-rfc2246-bis-13] (87 pages)
 - Transport Layer Security (TLS) Extensions [draft-ietf-tls-rfc3546bis-02] (30 pages)
 - The Transport Layer Security (TLS) Protocol Version 1.2 [draft-ietf-tls-rfc4346-bis-10] (104 pages)
 - Datagram Transport Layer Security Version 1.2 [draft-ietf-tls-rfc4347-bis-06] (32 pages)
 - Transport Layer Security (TLS) Extensions: Extension Definitions [draft-ietf-tls-rfc4366-bis-12] (25 pages)
 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier [draft-ietf-tls-rfc4492bis-17] (32 pages)
 - The Transport Layer Security (TLS) Protocol Version 1.3 [draft-ietf-tls-rfc5246-bis-00] (102 pages)
 - AES Galois Counter Mode (GCM) Cipher Suites for TLS [draft-ietf-tls-rsa-aes-gcm-03] (8 pages)
 - TLS Extension for SEED and HAS-160 [draft-ietf-tls-seedhas-00] (4 pages)
 - Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension [draft-ietf-tls-session-hash-06] (15 pages)
 - Use of Shared Keys in the TLS Protocol [draft-ietf-tls-sharedkeys-02] (6 pages)
 - SNI Encryption in TLS Through Tunneling [draft-ietf-tls-sni-encryption-00] (22 pages)
 - Using the Secure Remote Password (SRP) Protocol for TLS Authentication [draft-ietf-tls-srp-14] (24 pages)
 - SSH Transport Layer Protocol [draft-ietf-tls-ssh-00] (19 pages)
 - Modifications to the SSL protocol for TLS [draft-ietf-tls-ssl-mods-00] (4 pages)
 - The SSL Protocol Version 3.0 [draft-ietf-tls-ssl-version3-00] (63 pages)
 - Prohibiting Secure Sockets Layer (SSL) Version 2.0 [draft-ietf-tls-ssl2-must-not-04] (4 pages)
 - Deprecating Secure Sockets Layer Version 3.0 [draft-ietf-tls-sslv3-diediedie-03] (7 pages)
 - Delegated Credentials for TLS [draft-ietf-tls-subcerts-00] (11 pages)
 - Suite B Cipher Suites for TLS [draft-ietf-tls-suiteb-00] (8 pages)
 - The Transport Layer Security (TLS) Protocol Version 1.3 [draft-ietf-tls-tls13-23] (154 pages)
 - Example Handshake Traces for TLS 1.3 [draft-ietf-tls-tls13-vectors-03] (43 pages)
 - Wireless Extensions to TLS
[draft-ietf-tls-wireless-00] (13 pages)
 - The ChaCha Stream Cipher for Transport Layer Security [draft-mavrogiannopoulos-chacha-tls-05] (8 pages)
 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier [draft-nir-tls-rfc4492bis-00] (32 pages)
 - Prohibiting RC4 Cipher Suites [draft-popov-tls-prohibiting-rc4-02] (4 pages)
 - The Datagram Transport Layer Security (DTLS) Connection Identifier [draft-rescorla-tls-dtls-connection-id-02] (12 pages)
 - The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 [draft-rescorla-tls-dtls13-01] (36 pages)
 - Delegated Credentials for TLS [draft-rescorla-tls-subcerts-02] (11 pages)
 - Exported Authenticators in TLS [draft-sullivan-tls-exported-authenticator-01] (6 pages)
 - Deprecating Secure Sockets Layer Version 3.0 [draft-thomson-sslv3-diediedie-00] (6 pages)
 - Record Size Limit Extension for Transport Layer Security (TLS) [draft-thomson-tls-record-limit-00] (6 pages)
 - Example Handshake Traces for TLS 1.3 [draft-thomson-tls-tls13-vectors-01] (28 pages)

Requests for Comments:
 RFC2246: The TLS Protocol Version 1.0 (80 pages)
          * Obsoletes RFC4346
          * Updates RFC3546
          * Updates RFC5746
          * Updates RFC6176
          * Updates RFC7465
          * Updates RFC7507
          * Updates RFC7919
 RFC2712: Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) (7 pages)
 RFC2817: Upgrading to TLS Within HTTP/1.1 (13 pages)
          * Updates RFC2616
          * Updates RFC7231
          * Updates RFC7230
 RFC2818: HTTP Over TLS (7 pages)
          * Updates RFC5785
          * Updates RFC7230
 RFC3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) (7 pages)
          * Obsoletes RFC5246
 RFC3546: Transport Layer Security (TLS) Extensions (29 pages)
          * Updates RFC2246
          * Obsoletes RFC4366
 RFC3749: Transport Layer Security Protocol Compression Methods (8 pages)
 RFC4132: Addition of Camellia Cipher Suites to Transport Layer Security (TLS) (7 pages)
          * Obsoletes RFC5932
 RFC4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) (15 pages)
 RFC4346: The Transport Layer Security (TLS) Protocol Version 1.1 (87 pages)
          * Obsoletes RFC2246
          * Obsoletes RFC5246
          * Updates RFC4366
          * Updates RFC4680
          * Updates RFC4681
          * Updates RFC5746
          * Updates RFC6176
          * Updates RFC7465
          * Updates RFC7507
          * Updates RFC7919
 RFC4366: Transport Layer Security (TLS) Extensions (30 pages)
          * Obsoletes RFC3546
          * Updates RFC4346
          * Obsoletes RFC5246
          * Obsoletes RFC6066
          * Updates RFC5746
 RFC4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) (35 pages)
          * Updates RFC5246
          * Updates RFC7027
          * Updates RFC7919
 RFC4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) (5 pages)
 RFC5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication (24 pages)
 RFC5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication (8 pages)
          * Obsoletes RFC6091
 RFC5246: The Transport Layer Security (TLS) Protocol Version 1.2 (104 pages)
          * Obsoletes RFC3268
          * Obsoletes RFC4346
          * Obsoletes RFC4366
          * Updates RFC4492
          * Updates RFC5746
          * Updates RFC5878
          * Updates RFC6176
          * Updates RFC7465
          * Updates RFC7507
          * Updates RFC7568
          * Updates RFC7627
          * Updates RFC7685
          * Updates RFC7905
          * Updates RFC7919
 RFC5288: AES Galois Counter Mode (GCM) Cipher Suites for TLS (8 pages)
 RFC5289: TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) (6 pages)
 RFC5469: DES and IDEA Cipher Suites for Transport Layer Security (TLS) (4 pages)
 RFC5487: Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode (7 pages)
 RFC5489: ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) (7 pages)
 RFC5705: Keying Material Exporters for Transport Layer Security (TLS) (7 pages)
 RFC5746: Transport Layer Security (TLS) Renegotiation Indication Extension (15 pages)
          * Updates RFC2246
          * Updates RFC4346
          * Updates RFC4347
          * Updates RFC4366
          * Updates RFC5246
 RFC6066: Transport Layer Security (TLS) Extensions: Extension Definitions (25 pages)
          * Obsoletes RFC4366
 RFC6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 (4 pages)
          * Updates RFC2246
          * Updates RFC4346
          * Updates RFC5246
 RFC6347: Datagram Transport Layer Security Version 1.2 (32 pages)
          * Obsoletes RFC4347
          * Updates RFC7507
          * Updates RFC7905
 RFC6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension (9 pages)
 RFC6961: The Transport Layer Security (TLS) Multiple Certificate Status Request Extension (10 pages)
 RFC7250: Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (18 pages)
 RFC7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension (9 pages)
 RFC7366: Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (7 pages)
 RFC7465: Prohibiting RC4 Cipher Suites (6 pages)
          * Updates RFC5246
          * Updates RFC4346
          * Updates RFC2246
 RFC7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks (8 pages)
          * Updates RFC2246
          * Updates RFC4346
          * Updates RFC4347
          * Updates RFC5246
          * Updates RFC6347
 RFC7568: Deprecating Secure Sockets Layer Version 3.0 (7 pages)
          * Updates RFC5246
 RFC7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension (15 pages)
          * Updates RFC5246
 RFC7685: A Transport Layer Security (TLS) ClientHello Padding Extension (4 pages)
          * Updates RFC5246
 RFC7905: ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) (8 pages)
          * Updates RFC5246
          * Updates RFC6347
 RFC7918: Transport Layer Security (TLS) False Start (11 pages)
 RFC7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) (29 pages)
          * Updates RFC2246
          * Updates RFC4346
          * Updates RFC4492
          * Updates RFC5246
 RFC7924: Transport Layer Security (TLS) Cached Information Extension (19 pages)



Web Authorization Protocol (oauth)
----------------------------------

Charter
Last Modified: 2017-04-05

Current Status: Active

Chairs:
    Hannes Tschofenig <[email protected]>
    Rifaat Shekh-Yusef <[email protected]>

Security Area Directors:
    Kathleen Moriarty <[email protected]>
    Eric Rescorla <[email protected]>

Security Area Advisor:
    Eric Rescorla <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/oauth
    Archive:            https://mailarchive.ietf.org/arch/browse/oauth/

Description of Working Group:

 The Web Authorization (OAuth) protocol allows a user to grant a
 third-party web site or application access to the user's protected
 resources, without necessarily revealing their long-term credentials,
 or even their identity. For example, a photo-sharing site that
 supports OAuth could allow its users to use a third-party printing web
 site to print their private pictures, without allowing the printing
 site to gain full control of the user's account and without having the
 user share his or her photo-sharing sites' long-term credential with
 the printing site.

 The OAuth 2.0 protocol suite already includes

 * a procedure for enabling a client to register with an authorization
   server,
 * a protocol for obtaining authorization tokens from an authorization
   server with the resource owner's consent, and
 * protocols for presenting these authorization tokens to protected
   resources for access to a resource.

 This protocol suite has been enhanced with functionality for
 interworking with legacy identity infrastructure (such as SAML), token
 revocation, token exchange, dynamic client registration, token
 introspection, a standardized token format with the JSON Web Token, and
 specifications that mitigate security attacks, such as Proof Key for
 Code Exchange.

 The ongoing standardization efforts within the OAuth working group
 focus on increasing interoperability of OAuth deployments and to
 improve security. More specifically, the working group is defining proof
 of possession tokens, developing a discovery mechanism, providing
 guidance for the use of OAuth with native apps, re-introducing
 the device flow used by devices with limited user interfaces, additional
 security enhancements for clients communicating with multiple service
 providers, definition of claims used with JSON Web Tokens, techniques to
 mitigate open redirector attacks, as well as guidance on encoding state
 information.

 For feedback and discussion about our specifications please
 subscribe to our public mailing list at <oauth AT ietf.org>.

 For security related bug reports that relate to our specifications
 please contact <oauth-security-reports AT ietf.org>. If the reported
 bug report turns out to be implementation-specific we will attempt
 to forward it to the appropriate developers.

Goals and Milestones:
 Done     - Submit 'OAuth 2.0 Proof-of-Possession (PoP) Security Architecture' to the IESG
 Done     - Submit 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' to the IESG
 Done     - Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG for consideration as a Proposed Standard
 Done     - Submit 'Authentication Method Reference Values' to the IESG
 Done     - Submit 'OAuth 2.0 for Native Apps' to the IESG
 Done     - Submit 'OAuth 2.0 Authorization Server Discovery Metadata' to the IESG
 Apr 2017 - Submit 'OAuth 2.0 Device Flow' to the IESG
 May 2017 - Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration as a Proposed Standard
 Jul 2017 - Submit 'OAuth 2.0 Mix-Up Mitigation'to the IESG
 Jul 2017 - Submit 'OAuth 2.0 Security: Closing Open Redirectors in OAuth' to the IESG
 Jul 2017 - Submit 'OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution' to the IESG
 Jul 2017 - Submit 'A Method for Signing HTTP Requests for OAuth' to IESG

Internet-Drafts:
 - Authentication Method Reference Values [draft-ietf-oauth-amr-values-08] (15 pages)
 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [draft-ietf-oauth-assertions-18] (20 pages)
 - The OAuth Protocol: Authentication [draft-ietf-oauth-authentication-01] (21 pages)
 - OAuth 2.0 Security: Closing Open Redirectors in OAuth [draft-ietf-oauth-closing-redirectors-00] (7 pages)
 - OAuth 2.0 Device Flow for Browserless and Input Constrained Devices [draft-ietf-oauth-device-flow-07] (17 pages)
 - OAuth 2.0 Authorization Server Metadata [draft-ietf-oauth-discovery-08] (23 pages)
 - OAuth 2.0 Dynamic Client Registration Protocol [draft-ietf-oauth-dyn-reg-30] (39 pages)
 - OAuth 2.0 Dynamic Client Registration Management Protocol [draft-ietf-oauth-dyn-reg-management-15] (18 pages)
 - OAuth 2.0 Dynamic Client Registration Metadata [draft-ietf-oauth-dyn-reg-metadata-01] (4 pages)
 - OAuth 2.0 Token Introspection [draft-ietf-oauth-introspection-11] (17 pages)
 - JSON Web Token (JWT) [draft-ietf-oauth-json-web-token-32] (30 pages)
 - The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) [draft-ietf-oauth-jwsreq-15] (26 pages)
 - JSON Web Token Best Current Practices [draft-ietf-oauth-jwt-bcp-00] (11 pages)
 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [draft-ietf-oauth-jwt-bearer-12] (12 pages)
 - OAuth 2.0 Mix-Up Mitigation [draft-ietf-oauth-mix-up-mitigation-01] (14 pages)
 - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [draft-ietf-oauth-mtls-07] (20 pages)
 - OAuth 2.0 for Native Apps [draft-ietf-oauth-native-apps-12] (21 pages)
 - OAuth 2.0 Proof-of-Possession (PoP) Security Architecture [draft-ietf-oauth-pop-architecture-08] (23 pages)
 - OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution [draft-ietf-oauth-pop-key-distribution-03] (18 pages)
 - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) [draft-ietf-oauth-proof-of-possession-11] (15 pages)
 - OAuth 2.0 Token Revocation [draft-ietf-oauth-revocation-11] (11 pages)
 - Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants [draft-ietf-oauth-saml2-bearer-23] (15 pages)
 - OAuth Security Topics [draft-ietf-oauth-security-topics-04] (26 pages)
 - A Method for Signing HTTP Requests for OAuth [draft-ietf-oauth-signed-http-request-03] (13 pages)
 - Proof Key for Code Exchange by OAuth Public Clients [draft-ietf-oauth-spop-15] (20 pages)
 - OAuth 2.0 Token Binding [draft-ietf-oauth-token-binding-05] (30 pages)
 - OAuth 2.0 Token Exchange [draft-ietf-oauth-token-exchange-12] (33 pages)
 - An IETF URN Sub-Namespace for OAuth [draft-ietf-oauth-urn-sub-ns-06] (5 pages)
 - OAuth Use Cases [draft-ietf-oauth-use-cases-03] (24 pages)
 - The OAuth 2.0 Authorization Framework [draft-ietf-oauth-v2-31] (76 pages)
 - The OAuth 2.0 Authorization Framework: Bearer Token Usage [draft-ietf-oauth-v2-bearer-23] (18 pages)
 - OAuth 2.0 Message Authentication Code (MAC) Tokens [draft-ietf-oauth-v2-http-mac-05] (37 pages)
 - OAuth 2.0 Threat Model and Security Considerations [draft-ietf-oauth-v2-threatmodel-08] (71 pages)
 - The OAuth Protocol: Web Delegation [draft-ietf-oauth-web-delegation-01] (18 pages)

Requests for Comments:
 BCP212: OAuth 2.0 for Native Apps (21 pages)
          * Updates RFC6749
 RFC6749: The OAuth 2.0 Authorization Framework (76 pages)
          * Obsoletes RFC5849
          * Updates RFC8252
 RFC6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (18 pages)
 RFC6755: An IETF URN Sub-Namespace for OAuth (5 pages)
 RFC6819: OAuth 2.0 Threat Model and Security Considerations (71 pages)
 RFC7009: OAuth 2.0 Token Revocation (11 pages)
 RFC7519: JSON Web Token (JWT) (30 pages)
          * Updates RFC7797
 RFC7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants (20 pages)
 RFC7522: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants (15 pages)
 RFC7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (12 pages)
 RFC7591: OAuth 2.0 Dynamic Client Registration Protocol (39 pages)
 RFC7592: OAuth 2.0 Dynamic Client Registration Management Protocol (18 pages)
 RFC7636: Proof Key for Code Exchange by OAuth Public Clients (20 pages)
 RFC7662: OAuth 2.0 Token Introspection (17 pages)
 RFC7800: Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) (15 pages)
 RFC8176: Authentication Method Reference Values (15 pages)
 RFC8252: OAuth 2.0 for Native Apps (21 pages)
          * Updates RFC6749



Application-Layer Traffic Optimization (alto)
---------------------------------------------

Charter
Last Modified: 2016-04-18

Current Status: Active

Chairs:
    Jan Seedorf <[email protected]>
    Vijay K. Gurbani <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Mirja Kühlewind <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Delay/Disruption Tolerant Networking (dtn)
------------------------------------------

Charter
Last Modified: 2016-06-06

Current Status: Active

Chairs:
    Marc Blanchet <[email protected]>
    Rick Taylor <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Spencer Dawkins <[email protected]>

Secretary:
    Edward Birrane <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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

IP Performance Measurement (ippm)
---------------------------------

Charter
Last Modified: 2017-08-29

Current Status: Active

Chairs:
    Bill Cerveny <[email protected]>
    Brian Trammell <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Spencer Dawkins <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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



Multipath TCP (mptcp)
---------------------

Charter
Last Modified: 2016-04-06

Current Status: Active

Chairs:
    Philip Eardley <[email protected]>
    Yoshifumi Nishida <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Mirja Kühlewind <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    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)



Network File System Version 4 (nfsv4)
-------------------------------------

Charter
Last Modified: 2016-04-06

Current Status: Active

Chairs:
    Brian Pawlowski <[email protected]>
    Spencer Shepler <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Spencer Dawkins <[email protected]>

Tech Advisor:
    Leif Johansson <[email protected]>

Secretary:
    Thomas Haynes <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/nfsv4
    Archive:            https://mailarchive.ietf.org/arch/browse/nfsv4/

Description of Working Group:

 Network File System version 4 (NFSv4) is the IETF standard for file
 sharing.

 To maintain NFS Version 4's utility and currency, the NFSv4 working
 group is chartered to maintain the existing NFSv4.0, NFSv4.1, and
 NFSv4.2 protocols and specifications of related ONC components, such as
 those defining RPC, XDR, and RPCSECGSS.

 In addition, extensions will be developed, as necessary, to correct
 problems with the protocols as currently specified, to accommodate
 needed file system semantics, and to respond to technological
 developments in the areas of networking and persistent storage/memory.

 Maintenance

 The working group's experience has been that, as NFSv4 implementations
 mature and deployments continue, clarifications and corrections to
 existing RFCs are needed.

 These specification updates help vendors in delivering high-quality and
 interoperable implementations.

 The NFSv4 working group is chartered with vetting reported issues and
 determining correctness of submitted errata.

 In addition, some areas may need more concentrated work to correct the
 specifications already published, to deal with unanticipated
 interactions between features, or to respond to evolving expectations
 with regard to areas such as security. Since necessary changes in such
 cases are generally not appropriate for the errata system, the working
 group will assist in publication of new RFCs that provide implementation
 guidance, editorial modification or technical updates to existing RFCs.

 Since the new NFSv4 versioning framework has been approved, these
 technical updates to NFSv4 minor versions could include limited XDR
 changes.

 Extensions

 The NFSv4 protocol is designed to allow extension by the definition of
 new operations, new attributes, and new Parallel NFS layout types, as
 well as the creation of minor versions.

 Similarly, associated ONC protocol components that have a versioning/
 extension framework can be incrementally extended, when necessary.

 The working group will discuss proposals for such extensions and assure
 that they have adequate technical review, including discussion of their
 interaction with existing features, before adopting them as working
 group items and helping to draft specification documents.

 Some likely motivations for such extensions would be to:

 Maximize NFS performance on advanced network fabrics.

 Accommodate new storage technologies.

 Provide facilities useful in management of NFS-accessed storage in
 large-scale virtualization environments.

 Provide more effective NFS response to security challenges.

 New milestones that fall within the scope specified in this charter can
 be added to the list below after working group consensus and upon
 approval by the responsible Area Director.


Goals and Milestones:
 Jun 2018 - WGLC for draft-ietf-nfsv4-migration-issues (Informational)
 Jun 2018 - Submit final document describing use of NVMe in accessing a pNFS SCSI Layout (as Proposed Standard)
 Nov 2018 - Submit final document describing NFSv4.0 trunking discovery (as Proposed Standard)
 Mar 2019 - Submit final document describing NFSv4.1 trunking discovery (as Proposed Standard)
 Mar 2019 - Submit final document describing Transparent State Migration in NFSv4.1 (as Proposed Standard)
 Jun 2019 - Submit final document describing CM private data convention for RPC-over-RDMA version 1 (Informational)
 Sep 2019 - Submit final document describing pNFS RDMA Layout (as Proposed Standard)
 Dec 2019 - Submit final document defining RPC-over-RDMA Version 2 (as Proposed Standard)

Internet-Drafts:
 - NFS version 4 Protocol [draft-ietf-nfsv4-07] (212 pages)
 - NFS version 4 Protocol [draft-ietf-nfsv4-03-00] (230 pages)
 - Mapping Between NFSv4 and Posix Draft ACLs [draft-ietf-nfsv4-acl-mapping-05] (20 pages)
 - NFS Version 4 ACLs
[draft-ietf-nfsv4-acls-00] (35 pages)
 - The Channel Conjunction Mechanism (CCM) for GSS [draft-ietf-nfsv4-ccm-03] (28 pages)
 - On the Use of Channel Bindings to Secure Channels [draft-ietf-nfsv4-channel-bindings-04] (17 pages)
 - NFS Version 4 Design Considerations [draft-ietf-nfsv4-designconsider-03] (22 pages)
 - NFSv4.1: Directory Delegations and Notifications [draft-ietf-nfsv4-directory-delegation-01] (24 pages)
 - A DNS RR for NFSv4 ID Domains [draft-ietf-nfsv4-dns-rr-00] (11 pages)
 - Administration Protocol for Federated File Systems [draft-ietf-nfsv4-federated-fs-admin-15] (37 pages)
 - Using DNS SRV to Specify a Global File Namespace with NFS Version 4 [draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13] (11 pages)
 - Namespace Database (NSDB) Protocol for Federated File Systems [draft-ietf-nfsv4-federated-fs-protocol-15] (65 pages)
 - Requirements for Federated File Systems [draft-ietf-nfsv4-federated-fs-reqts-06] (26 pages)
 - Parallel NFS (pNFS) Flexible File Layout [draft-ietf-nfsv4-flex-files-16] (42 pages)
 - NFS operation over IPv4 and IPv6 [draft-ietf-nfsv4-ipv4v6-00] (14 pages)
 - NFS operation over IPv6 [draft-ietf-nfsv4-ipv6-00] (8 pages)
 - Requirements for Labeled NFS [draft-ietf-nfsv4-labreqs-05] (18 pages)
 - Requirements for pNFS Layout Types [draft-ietf-nfsv4-layout-types-09] (16 pages)
 - Registry Specification for Mandatory Access Control (MAC) Security Label Formats [draft-ietf-nfsv4-lfs-registry-06] (10 pages)
 - NFSv4 Migration and Trunking: Implementation and Specification Issues [draft-ietf-nfsv4-migration-issues-14] (45 pages)
 - Requirements for NFSv4.2 [draft-ietf-nfsv4-minorversion-2-requirements-00] (10 pages)
 - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-ietf-nfsv4-minorversion1-29] (617 pages)
 - Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-minorversion1-dot-x-12] (73 pages)
 - Network File System (NFS) Version 4 Minor Version 2 Protocol [draft-ietf-nfsv4-minorversion2-41] (104 pages)
 - Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-minorversion2-dot-x-41] (87 pages)
 - Requirements for NFSv4 Multi-Domain Namespace Deployment [draft-ietf-nfsv4-multi-domain-fs-reqs-11] (17 pages)
 - NFS version 4.0 Trunking Update [draft-ietf-nfsv4-mv0-trunking-update-00] (17 pages)
 - NFSv4.1 Update for Multi-Server Namespace [draft-ietf-nfsv4-mv1-msns-update-00] (75 pages)
 - Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement [draft-ietf-nfsv4-nfs-rdma-problem-statement-08] (15 pages)
 - Network File System (NFS) Direct Data Placement [draft-ietf-nfsv4-nfsdirect-08] (10 pages)
 - NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 [draft-ietf-nfsv4-nfssec-03] (19 pages)
 - NFSv4 pNFS Extensions [draft-ietf-nfsv4-pnfs-00] (63 pages)
 - pNFS Access Permissions Check [draft-ietf-nfsv4-pnfs-access-permissions-check-00] (12 pages)
 - Parallel NFS (pNFS) Block/Volume Layout [draft-ietf-nfsv4-pnfs-block-12] (28 pages)
 - Parallel NFS (pNFS) Block Disk Protection [draft-ietf-nfsv4-pnfs-block-disk-protection-03] (6 pages)
 - Object-Based Parallel NFS (pNFS) Operations [draft-ietf-nfsv4-pnfs-obj-12] (35 pages)
 - Implementation Guide for Referrals in NFSv4 [draft-ietf-nfsv4-referrals-00] (24 pages)
 - Server-to-Server Replication/Migration Protocol Design Principles [draft-ietf-nfsv4-repl-mig-design-00] (12 pages)
 - A Server-to-Server Replication/Migration Protocol [draft-ietf-nfsv4-repl-mig-proto-01] (30 pages)
 - NFS Version 4 Requirements [draft-ietf-nfsv4-requirements-03] (19 pages)
 - RPC: Remote Procedure Call Protocol Specification Version 2 [draft-ietf-nfsv4-rfc1831bis-13] (63 pages)
 - XDR: External Data Representation Standard [draft-ietf-nfsv4-rfc1832bis-06] (27 pages)
 - Network File System (NFS) version 4 Protocol [draft-ietf-nfsv4-rfc3010bis-05] (275 pages)
 - NFSv4.0 Migration: Specification Update [draft-ietf-nfsv4-rfc3530-migration-update-08] (55 pages)
 - Network File System (NFS) Version 4 Protocol [draft-ietf-nfsv4-rfc3530bis-35] (323 pages)
 - Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-rfc3530bis-dot-x-24] (39 pages)
 - Object-Based Parallel NFS (pNFS) Operations [draft-ietf-nfsv4-rfc5664bis-03] (38 pages)
 - RPC-over-RDMA Version One Implementation Experience [draft-ietf-nfsv4-rfc5666-implementation-experience-03] (50 pages)
 - Remote Direct Memory Access Transport for Remote Procedure Call Version 1 [draft-ietf-nfsv4-rfc5666bis-11] (55 pages)
 - Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 [draft-ietf-nfsv4-rfc5667bis-13] (21 pages)
 - RPC Numbering Authority Transfer to IANA [draft-ietf-nfsv4-rpc-iana-03] (13 pages)
 - IPv6 extension to RPC [draft-ietf-nfsv4-rpc-ipv6-00] (13 pages)
 - IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats [draft-ietf-nfsv4-rpc-netid-06] (14 pages)
 - Remote Direct Memory Access Transport for Remote Procedure Call [draft-ietf-nfsv4-rpcrdma-09] (34 pages)
 - Bidirectional Remote Procedure Call on RPC-over-RDMA Transports [draft-ietf-nfsv4-rpcrdma-bidirection-08] (13 pages)
 - RPCSEC_GSS Version 2 [draft-ietf-nfsv4-rpcsec-gss-v2-06] (14 pages)
 - Remote Procedure Call (RPC) Security Version 3 [draft-ietf-nfsv4-rpcsec-gssv3-17] (26 pages)
 - Remote Procedure Call (RPC) Security Version 3 [draft-ietf-nfsv4-rpcsecgssv3-00] (23 pages)
 - Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout [draft-ietf-nfsv4-scsi-layout-10] (30 pages)
 - NFSv4.1: SECINFO Changes [draft-ietf-nfsv4-secinfo-02] (15 pages)
 - NFSv4 Session Extensions [draft-ietf-nfsv4-sess-02] (69 pages)
 - Allowing Inheritable NFSv4 Access Control Entries to Override the Umask [draft-ietf-nfsv4-umask-05] (7 pages)
 - Rules for NFSv4 Extensions and Minor Versions [draft-ietf-nfsv4-versioning-11] (26 pages)
 - File System Extended Attributes in NFSv4 [draft-ietf-nfsv4-xattrs-07] (28 pages)
 - NFS version 4 [draft-shepler-nfsv4-03] (133 pages)

Requests for Comments:
 RFC2623: NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 (19 pages)
 RFC2624: NFS Version 4 Design Considerations (22 pages)
 RFC3010: NFS version 4 Protocol (212 pages)
          * Obsoletes RFC3530
 RFC3530: Network File System (NFS) version 4 Protocol (275 pages)
          * Obsoletes RFC3010
          * Obsoletes RFC7530
 RFC4506: XDR: External Data Representation Standard (27 pages)
          * Obsoletes RFC1832
 RFC5403: RPCSEC_GSS Version 2 (14 pages)
          * Updates RFC2203
          * Updates RFC7861
 RFC5531: RPC: Remote Procedure Call Protocol Specification Version 2 (63 pages)
          * Obsoletes RFC1831
 RFC5532: Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement (15 pages)
 RFC5661: Network File System (NFS) Version 4 Minor Version 1 Protocol (617 pages)
          * Updates RFC8178
 RFC5662: Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description (73 pages)
 RFC5663: Parallel NFS (pNFS) Block/Volume Layout (28 pages)
          * Updates RFC6688
 RFC5664: Object-Based Parallel NFS (pNFS) Operations (35 pages)
 RFC5665: IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats (14 pages)
          * Updates RFC1833
 RFC5666: Remote Direct Memory Access Transport for Remote Procedure Call (34 pages)
          * Obsoletes RFC8166
 RFC5667: Network File System (NFS) Direct Data Placement (10 pages)
          * Obsoletes RFC8267
 RFC5716: Requirements for Federated File Systems (26 pages)
 RFC6641: Using DNS SRV to Specify a Global File Namespace with NFS Version 4 (11 pages)
 RFC6688: Parallel NFS (pNFS) Block Disk Protection (6 pages)
          * Updates RFC5663
 RFC7204: Requirements for Labeled NFS (18 pages)
 RFC7530: Network File System (NFS) Version 4 Protocol (323 pages)
          * Obsoletes RFC3530
          * Updates RFC7931
 RFC7531: Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description (39 pages)
 RFC7532: Namespace Database (NSDB) Protocol for Federated File Systems (65 pages)
 RFC7533: Administration Protocol for Federated File Systems (37 pages)
 RFC7569: Registry Specification for Mandatory Access Control (MAC) Security Label Formats (10 pages)
 RFC7861: Remote Procedure Call (RPC) Security Version 3 (26 pages)
          * Updates RFC5403
 RFC7862: Network File System (NFS) Version 4 Minor Version 2 Protocol (104 pages)
          * Updates RFC8178
 RFC7863: Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description (87 pages)
 RFC7931: NFSv4.0 Migration: Specification Update (55 pages)
          * Updates RFC7530
 RFC8000: Requirements for NFSv4 Multi-Domain Namespace Deployment (17 pages)
 RFC8154: Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout (30 pages)
 RFC8166: Remote Direct Memory Access Transport for Remote Procedure Call Version 1 (55 pages)
          * Obsoletes RFC5666
 RFC8167: Bidirectional Remote Procedure Call on RPC-over-RDMA Transports (13 pages)
 RFC8178: Rules for NFSv4 Extensions and Minor Versions (26 pages)
          * Updates RFC5661
          * Updates RFC7862
 RFC8267: Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 (21 pages)
          * Obsoletes RFC5667
 RFC8275: Allowing Inheritable NFSv4 Access Control Entries to Override the Umask (7 pages)
 RFC8276: File System Extended Attributes in NFSv4 (28 pages)
 STD67: XDR: External Data Representation Standard (27 pages)
          * Obsoletes RFC1832



QUIC (quic)
-----------

Charter
Last Modified: 2017-10-04

Current Status: Active

Chairs:
    Lars Eggert <[email protected]>
    Mark Nottingham <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Spencer Dawkins <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/quic
    Archive:            https://mailarchive.ietf.org/arch/browse/quic/

Description of Working Group:

 The QUIC working group will provide a standards-track specification for
 a UDP-based, stream-multiplexing, encrypted transport protocol, based
 on pre-standardization implementation and deployment experience, and
 generalizing the design described in
 draft-hamilton-quic-transport-protocol,
 draft-iyengar-quic-loss-recovery,
 draft-shade-quic-http2-mapping, and
 draft-thomson-quic-tls.

 Key goals for QUIC are:

 - Minimizing connection establishment and overall transport latency
   for applications, starting with HTTP/2;
 - Providing multiplexing without head-of-line blocking;
 - Requiring only changes to path endpoints to enable deployment;
 - Enabling multipath and forward error correction extensions; and
 - Providing always-secure transport, using TLS 1.3 by default.

 The work of the group will have five main focus areas, corresponding
 to five core deliverables.

 The first of these is the core transport work, which will describe
 the wire format, along with the mechanisms for connection
 establishment, stream multiplexing, data reliability, loss detection
 and recovery, congestion control, version negotiation, and options
 negotiation. Work on congestion control will describe use of a
 standardized congestion controller as a default scheme for
 QUIC. Defining new congestion control schemes is explicitly out of
 scope for this group. QUIC is expected to support rapid,
 distributed development and testing of features.

 The second of these focus areas is security. This work will describe
 how the protocol uses TLS 1.3 for key negotiation and will also
 describe how those keys are used to provide confidentiality and
 integrity protection of both application data and QUIC headers.
 This work will ensure that QUIC has security and privacy
 properties that are at least as good as a stack composed of TLS 1.3
 using TCP (or MPTCP when using multipath).

 The third focus area will describe mappings between specific
 application protocols and the transport facilities of QUIC. The first
 mapping will be a description of HTTP/2 semantics using QUIC,
 specifically with the goal of minimizing web latency using QUIC. This
 mapping will accommodate the extension mechanisms defined in the HTTP/2
 specification. Upon completion of that mapping, additional protocols
 may be added by updating this charter to include them.

 The fourth focus area will extend core protocol facilities to enable
 multipath capabilities for connection migration between paths and load
 sharing across multiple paths.

 The fifth focus area will provide an Applicability and Manageability
 Statement, describing how, and under what circumstances, QUIC may be
 safely used, and describing deployment and manageability implications
 of the protocol.

 Current practices for network management of transport protocols
 include the ability to apply access control lists (ACLs), hashing of
 flows for equal-cost multipath routing (ECMP), directional signaling
 of flows, signaling of flow setup and teardown, and the ability to
 export information about flows for accounting purposes. The QUIC
 protocol need not be defined to enable each of these abilities, or
 enable them in the same way as they are enabled by TCP when used
 with TLS 1.3, but the working group must consider the impact of the
 protocol on network management practices, reflecting the tensions
 described in RFC 7258.

 Extensions that will support partial reliability, and negotiation
 and use of Forward Error Correction schemes, are out of scope in
 this version of the working group charter.

 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.

 The QUIC working group will work closely with the HTTPbis working
 group, especially on the QUIC mapping for HTTP/2.

 In order to achieve the milestones set out below, the group expects
 to make extensive use of interim meetings, especially in its first year.

Goals and Milestones:
 Feb 2017 - Working group adoption of Core Protocol document
 Feb 2017 - Working group adoption of Loss detection and Congestion Control document
 Feb 2017 - Working group adoption of TLS 1.3 mapping document
 Feb 2017 - Working group adoption of HTTP/2 mapping document
 Feb 2017 - Working group adoption of QUIC Applicability and Manageability Statement
 Nov 2017 - Working group adoption of Multipath extension document
 Nov 2018 - Core Protocol document to IESG
 Nov 2018 - Loss detection and Congestion Control document to IESG
 Nov 2018 - TLS 1.3 Mapping document to IESG
 Nov 2018 - HTTP/2 mapping document to IESG
 Nov 2018 - QUIC Applicability and Manageability Statement to IESG
 May 2019 - Multipath extension document to IESG

Internet-Drafts:
 - QUIC: A UDP-Based Multiplexed and Secure Transport [draft-hamilton-quic-transport-protocol-01] (45 pages)
 - Applicability of the QUIC Transport Protocol [draft-ietf-quic-applicability-01] (10 pages)
 - Hypertext Transfer Protocol (HTTP) over QUIC [draft-ietf-quic-http-09] (37 pages)
 - Manageability of the QUIC Transport Protocol [draft-ietf-quic-manageability-01] (13 pages)
 - QUIC Loss Detection and Congestion Control [draft-ietf-quic-recovery-09] (27 pages)
 - Using Transport Layer Security (TLS) to Secure QUIC [draft-ietf-quic-tls-09] (38 pages)
 - QUIC: A UDP-Based Multiplexed and Secure Transport [draft-ietf-quic-transport-09] (97 pages)
 - QUIC Congestion Control And Loss Recovery [draft-iyengar-quic-loss-recovery-01] (10 pages)
 - Applicability of the QUIC Transport Protocol [draft-kuehlewind-quic-applicability-00] (7 pages)
 - Manageability of the QUIC Transport Protocol [draft-kuehlewind-quic-manageability-00] (10 pages)
 - HTTP/2 Semantics Using The QUIC Transport Protocol [draft-shade-quic-http2-mapping-00] (11 pages)
 - Using Transport Layer Security (TLS) to Secure QUIC [draft-thomson-quic-tls-01] (22 pages)

No Requests for Comments

RTP Media Congestion Avoidance Techniques (rmcat)
-------------------------------------------------

Charter
Last Modified: 2016-11-01

Current Status: Active

Chairs:
    Anna Brunstrom <[email protected]>
    Colin Perkins <[email protected]>
    Martin Stiemerling <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Mirja Kühlewind <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/rmcat
    Archive:            https://mailarchive.ietf.org/arch/browse/rmcat/

Description of Working Group:

 Today's Internet traffic includes interactive real-time media, which is often carried
 via sets of flows using RTP over UDP.  There is no generally accepted congestion
 control mechanism for this kind of data flow.  With the deployment of applications
 using the RTCWEB protocol suite, the number of such flows is likely to increase,
 especially non-fixed-rate flows such as video or adaptive audio. There is therefore
 some urgency in specifying one or more congestion control mechanisms that can
 find general acceptance.

 Congestion control algorithms for interactive real time media may need to be quite
 different from the congestion control of TCP: for example, some applications can be
 more tolerant to loss than delay and jitter. The set of requirements for such an
 algorithm includes, but is not limited to:
     - Low delay and low jitter for the case where there is no competing traffic using
       other algorithms
     - Reasonable share of bandwidth when competing with RMCAT traffic, other
       real-time media protocols, and ideally also TCP and other protocols. A
       'reasonable share' means that no flow has a significantly negative impact
       [RFC5033] on other flows and at minimum that no flow starves.
     - Effective use of signals like packet loss and ECN markings to adapt to
       congestion

 The working group will:
     - Develop a clear understanding of the congestion control requirements for RTP
       flows, and document deficiencies of existing mechanisms such as TFRC with
       regards to these requirements.  This must be completed prior to finishing any
       Experimental algorithm specifications.
     - Identify interactions between applications and RTP flows to enable conveying
       helpful cross-layer information such as per-packet priorities, flow elasticity, etc.
       This information might be used to populate an API, but the WG will not define a
       specific API itself.
     - Determine if extensions to RTP/RTCP are needed for carrying congestion
       control feedback, using DCCP as a model.  If so, provide the requirements
       for such extensions to the AVTCORE working group for standardization there.
     - Develop techniques to detect, instrument or diagnose failing to meet RT
       schedules due to failures of components outside of the charter scope, possibly
       in collaboration with IPPM.
     - Develop a mechanism for identifying shared bottlenecks between groups of
       flows, and means to flexibly allocate their rates within the aggregate hitting
       the shared bottleneck.
     - Define evaluation criteria for proposed congestion control mechanisms, and
       publish these as an Informational RFC.  This must be completed prior to
       finishing any Proposed Standard algorithm specifications.
     - Find or develop candidate congestion control algorithms, verify that these can be
       tested on the Internet without significant risk, and publish one or more of these
       as Experimental RFCs.
     - Publish evaluation criteria and the result of experimentation with these
       Experimental algorithms on the Internet.  This must be completed prior to
       finishing any Proposed Standard algorithm specifications.
     - Once an algorithm has been found or developed that meets the evaluation
       criteria, and has a satisfactory amount of documented experience on the
       Internet, publish this algorithm as a Standards Track RFC.  There may be
       more than one algorithm; in this case it will be one of the objects of the
       experimentation to determine the applicabilities and relative merits of the
       algorithms.
     - For each of the Experimental algorithms that have not been
       selected for the Standards Track, the working group will review
       the algorithm and determine whether there are significant flaws,
       such as ones that turn out to be harmful to flows using or
       competing with them. If so, the WG will write a document
       describing the issues encountered and recommending to the IESG
       to move the specification to Historic status.

 The work will be guided by the advice laid out in RFC 5405 (UDP Usage Guidelines),
 RFC 2914 (congestion control principles), and RFC5033 (Specifying New Congestion
 Control Algorithms).

 The following topics are out of scope of this working group, on the assumption that
 work on them will proceed elsewhere:
     - Circuit-breaker algorithms for stopping media flows when network conditions
       render them useless; this work is done in AVTCORE
     - Media flows for non-interactive purposes like stored video playback; those are not
       as delay sensitive as interactive traffic
     - Defining active queue management algorithms or modifications to TCP of any
       kind
     - Multicast congestion control; common control of multiple unicast flows is in
       scope
     - Topologies other than point-to-point connections; implications on multi-hop
       connections will be considered at a later stage

 The working group is expected to work closely with the RAI area, including the
 underlying technologies being worked on in the AVTCORE and AVTEXT WGs, and
 the applications/protocol suites being developed in the  CLUE and RTCWEB working
 groups.  It will also coordinate closely with other Transport area groups working on
 congestion control, and with the Internet Congestion Control Research Group of the
 IRTF.

 Deliverables:
     - Requirements for congestion control algorithms for interactive real time media as
       an Informational RFC
     - Evaluation criteria for congestion control algorithms for interactive real time media
       as an Informational RFC
     - Requirements for RTCP extensions for use with congestion control algorithms as
       an input to the AVTCORE WG.
     - Interactions between applications and RTP flows as an Informational RFC
     - Identifying and controlling groups of flows as a Proposed Standard RFC
     - Techniques to detect, instrument or diagnose failing to meet RT schedules as
       either an Informational RFC or on the Standards Track if needed for
       interoperability or other aspects that would justify it.
     - Candidate congestion control algorithm for interactive real time media as
       Experimental RFCs (likely more than one)
     - Experimentation and evaluation results for candidate congestion control
       algorithms as an Informational RFC
     - One or more recommended congestion control algorithms for interactive real time
       media as Proposed Standard RFCs

Goals and Milestones:
 Done     -  Adopt first WG draft on requirements
 Done     - Adopt first WG draft on evaluation criteria
 Done     - Adopt first WG draft of RTCP extensions for use with congestion control algorithms and interactions between applications and RTP flows (if needed)
 Done     - Adopt first congestion control candidate as WG draft
 Done     - Adopt first WG draft on identifying and controlling groups of flows
 Jul 2017 - Submit identifying and controlling groups of flows to IESG for Experimental publication
 Jul 2017 - Submit first congestion control candidate to IESG for Experimental publication
 Aug 2017 - Submit RTCP extension requirements for use with congestion control algorithms to AVTCORE (if needed)
 Aug 2017 - Submit requirements and evaluation criteria to IESG as Informational
 Mar 2018 - Submit interactions between applications and RTP flows to IESG as Informational
 Mar 2018 - Publish first draft of evaluation results
 Mar 2018 - Publish first draft of Standards Track congestion control algorithm
 Mar 2018 - Publish first draft of techniques to detect, instrument or diagnose failing to meet RT schedules
 Jul 2018 - Submit techniques to detect, instrument or diagnose failing to meet RT schedules to IESG as Informational
 Nov 2018 - Submit congestion control to IESG for Proposed Standard

Internet-Drafts:
 - A Google Congestion Control Algorithm for Real-Time Communication [draft-alvestrand-rmcat-congestion-03] (19 pages)
 - RTP Control Protocol (RTCP) Feedback for Congestion Control [draft-dt-rmcat-feedback-message-04] (10 pages)
 - Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. [draft-hayes-rmcat-sbd-02] (18 pages)
 - RTP Application Interaction with Congestion Control [draft-ietf-rmcat-app-interaction-01] (15 pages)
 - Congestion Control and Codec interactions in RTP Applications [draft-ietf-rmcat-cc-codec-interactions-02] (12 pages)
 - Congestion Control Requirements for Interactive Real-Time Media [draft-ietf-rmcat-cc-requirements-09] (12 pages)
 - Coupled congestion control for RTP media [draft-ietf-rmcat-coupled-cc-07] (26 pages)
 - Evaluating Congestion Control for Interactive Real-time Media [draft-ietf-rmcat-eval-criteria-06] (15 pages)
 - Test Cases for Evaluating RMCAT Proposals [draft-ietf-rmcat-eval-test-05] (32 pages)
 - A Google Congestion Control Algorithm for Real-Time Communication [draft-ietf-rmcat-gcc-02] (19 pages)
 - NADA: A Unified Congestion Control Scheme for Real-Time Media [draft-ietf-rmcat-nada-06] (26 pages)
 - RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences [draft-ietf-rmcat-rtp-cc-feedback-03] (12 pages)
 - Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. [draft-ietf-rmcat-sbd-09] (24 pages)
 - Self-Clocked Rate Adaptation for Multimedia [draft-ietf-rmcat-scream-cc-13] (36 pages)
 - Modeling Video Traffic Sources for RMCAT Evaluations [draft-ietf-rmcat-video-traffic-model-04] (17 pages)
 - Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks [draft-ietf-rmcat-wireless-tests-04] (21 pages)
 - Congestion Control Requirements For RMCAT [draft-jesup-rmcat-reqs-01] (9 pages)
 - Self-Clocked Rate Adaptation for Multimedia [draft-johansson-rmcat-scream-cc-05] (27 pages)
 - Test Cases for Evaluating RMCAT Proposals [draft-sarker-rmcat-eval-test-01] (36 pages)
 - Evaluating Congestion Control for Interactive Real-time Media [draft-singh-rmcat-cc-eval-04] (19 pages)
 - Coupled congestion control for RTP media [draft-welzl-rmcat-coupled-cc-05] (20 pages)
 - RTP Application Interaction with Congestion Control [draft-zanaty-rmcat-app-interaction-01] (14 pages)
 - Congestion Control and Codec interactions in RTP Applications [draft-zanaty-rmcat-cc-codec-interactions-00] (11 pages)
 - Framework for Real-time Media Congestion Avoidance Techniques [draft-zhu-rmcat-framework-00] (8 pages)
 - NADA: A Unified Congestion Control Scheme for Real-Time Media [draft-zhu-rmcat-nada-06] (18 pages)

Requests for Comments:
 RFC8298: Self-Clocked Rate Adaptation for Multimedia (36 pages)



TCP Increased Security (tcpinc)
-------------------------------

Charter
Last Modified: 2016-04-18

Current Status: Active

Chairs:
    David L. Black <[email protected]>
    Kyle Rose <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Mirja Kühlewind <[email protected]>

Tech Advisor:
    Stephen Farrell <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/tcpinc
    Archive:            https://mailarchive.ietf.org/arch/browse/tcpinc/

Description of Working Group:

 The TCPINC WG will develop the TCP extensions to provide unauthenticated
 encryption and integrity protection of TCP streams. The WG will define
 an unauthenticated key exchange mechanism. In addition, the WG will
 define the TCP extensions to utilize unauthenticated keys, resulting in
 encryption and integrity protection without authentication. This is
 better than plain-text because it thwarts passive eavesdropping, but is
 weaker than using authenticated keys, because it is vulnerable to man-
 in-the-middle attacks during the initial unauthenticated key exchange.
 This work is part of the IETF effort to evolve the Internet architecture
 given the latest events of pervasive monitoring (see BCP 188).

 The goal of this WG is to provide an additional security tool that
 complements existing protocols at other layers in the stack. The WG will
 be looking for the designs that find the right tradeoff spot between
 conflicting requirements: to provide reasonable security for the
 majority of connections.  This work will deal with unprotected
 connections, and therefore will focus more on improvements from a
 baseline of no security than on achieving the high standard of security
 that is already available to users of authenticated TLS.

 Providing unauthenticated encryption and integrity protection at the TCP
 layer will provide a set of features that cannot be achieved with
 existing tools.
 Those features include:
 - encryption and integrity protection without modifications to the upper
   layers (no API changes),
 - encryption and integrity protection with forward secrecy with a per-
   connection granularity,
 - simple NAT and firewall traversal capabilities,
 - key rollover without significant impact to the TCP connection,
 - lower overhead compared to solutions relying in stacking multiple
   protocols to achieve different features,
 - no manual configuration required.

 A more detailed description of the motivations for TCP-based solutions
 can be found in draft-bellovin-tcpsec-01 and in RFC5925.

 The working group will produce documents specifying the required TCP
 extensions and additional documents needed.

 The high-level requirements for the protocol for providing TCP
 unauthenticated encryption and integrity protection are:
 - It should work over the vast majority of paths that unmodified TCP
   works over, in particular it must be compatible with NATs (at the very
   minimum with the NATs that comply with BEHAVE requirements as
   documented in RFC4787, RFC5382 and RFC5508).

 - The protocol must be usable by unmodified applications.  This effort
   is complementary to other security protocols developed in the IETF
   (such as TLS) as it protects those applications and protocols that are
   difficult to change or may even not be able to be changed in a
   backward compatible way.  It also provides some protection in
   scenarios where application developers are unwilling to change their
   applications (e.g., by configuring encryption) solely for the sake of
   improving security.

 - The protocol must provide cryptographic algorithm agility.

 - The protocol must gracefully fall-back to TCP if the remote peer does
   not support the proposed extensions.

 - When encryption is enabled, it must at least provide protection
   against passive eavesdropping by default,

 - Any required TCP option should use a minimum amount of TCP option
   space, especially in SYN segments.

 - The protocol must not require any authentication or configuration from
   applications or users.  However, hooks for external authentication
   must be made available.  The WG will not work on new authentication
   mechanisms.

 - The protocol must have acceptable performance, including acceptable
   latency and  processing overheads.  For example, the protocol may try
   to re-use existing cryptographic material for future communication
   between the same endpoints to avoid expensive public key operations on
   connection set up.

 When encryption is enabled, then the protocol:

 - must always provide forward secrecy.

 - must always provide integrity protection of the payload data (it is
   open for discussion for the WG if the TCP header should or should not
   be protected).

 - must always provide payload encryption.

 - must not provide extra linkability: when encryption is enabled, the
   TCP traffic should not give a third party observer any extra way to
   associate those packets with the specific peers beyond information
   that would have been present in a cleartext session.

 - must allow the initiator of the connection to avoid being
   fingerprinted as a result of using the protocol: some initiators may
   want to avoid appearing as the same endpoint when connecting to a
   remote peer on subsequent occasions. This should either be the default
   or some mechanism should be available for initiators to drop or ignore
   shared state to avoid being fingerprintable any more than would be
   the case for a cleartext session.

 Security features at the TCP-level can benefit other TCP extensions.
 For example, both Multipath TCP and TCP Fast Open require proof that
 some connections are related.  Session resumption and Message
 Authentication Codes (MACs) can provide this evidence.  The working
 group should identify synergies and design the security protocol in such
 a way that other TCP efforts can benefit from it.  Of course, TCP
 extensions that break must be identified too, and kept to a minimum.

 The working group will produce the following documents:

 - A framework for unauthenticated encryption and integrity protection of
   TCP connections. This document will describe basic design
   considerations, including the motivation and the applicability of the
   proposed mechanism, the interaction with other security mechanisms in
   different layers of the stack, the interaction with external
   authentication mechanisms, the expected protection, privacy
   considerations and residual threats.

 - Definition of the unauthenticated key exchange mechanism and the
   extensions to current TCP to utilize unauthenticated key to provide
   encryption and integrity protection. This covers all the protocol
   changes required. This will be an experimental document.

 - An extended API describing how applications can obtain further
   benefits of the proposed extensions. In particular, the hooks for
   supporting external authentication will be defined in this document.
   This will be an informational document.

Goals and Milestones:
 Done     - Adopt first WG document on unauthenticated key exchange mechanism and extensions to current TCP
 Done     - Adpot first WG document on extended API
 Done     - Submit unauthenticated key exchange mechanism and extensions to current TCP to IESG for publication as Experimental
 Jan 2017 - Submit extended API to IESG as Informational

Internet-Drafts:
 - Interface Extensions for TCP-ENO and tcpcrypt [draft-ietf-tcpinc-api-05] (14 pages)
 - Cryptographic protection of TCP Streams (tcpcrypt) [draft-ietf-tcpinc-tcpcrypt-11] (31 pages)
 - TCP-ENO: Encryption Negotiation Option [draft-ietf-tcpinc-tcpeno-18] (30 pages)
 - Using TLS to Protect TCP Streams [draft-ietf-tcpinc-use-tls-01] (18 pages)

No Requests for Comments

TCP Maintenance and Minor Extensions (tcpm)
-------------------------------------------

Charter
Last Modified: 2016-08-17

Current Status: Active

Chairs:
    Michael Scharf <[email protected]>
    Michael Tüxen <[email protected]>
    Yoshifumi Nishida <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Mirja Kühlewind <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/tcpm
    Archive:            https://mailarchive.ietf.org/arch/browse/tcpm/

Description of Working Group:

 TCP is currently the Internet's predominant transport protocol. TCPM
 is the working group within the IETF that handles small TCP changes,
 i.e., minor extensions to TCP algorithms and protocol mechanisms.
 The TCPM WG serves several purposes:

 * The WG mostly focuses on maintenance issues (e.g., bug fixes) and
 modest changes to the protocol, algorithms, and interfaces that
 maintain TCP's utility.

 * The WG is a venue for moving current TCP specifications along the
 standards track (as community energy is available for such efforts).

 * The focus of the working group is TCP. In cases where small
 changes are directly applicable to other transports (e.g., SCTP or
 DCCP), the mappings to other transports may be specified alongside
 that for TCP, but other significant additions and changes to other
 transports are not in scope.

 TCPM also provides a venue for standardization of incremental
 enhancements of TCP's standard congestion control. In addition,
 TCPM may document alternative TCP congestion control algorithms
 that are known to be widely deployed, and that are considered
 safe for large-scale deployment in the Internet. Changes of algorithms
 may require additional review by the IRTF Congestion Control
 Research Group (ICCRG). Fundamental changes to TCP or its congestion
 control algorithms (e.g., departure from loss-based congestion
 control) will be handled by other working groups or will require
 rechartering.

 TCP's congestion control algorithms are the model followed by
 alternate transports (e.g., SCTP or DCCP), which are standardized in
 other working groups, such as the Transport Area WG (tsvwg). In the
 past, the IETF has worked on several documents about algorithms that
 are specified for multiple protocols (e.g., TCP and SCTP) in the
 same document. Which WG shepherds such documents will be determined
 on a case-by-case basis. In any case, the TCPM WG will remain in
 close contact with other relevant WGs working on these protocols to
 ensure openness and stringent review from all angles.

 New TCPM milestones that fall within the scope specified within the
 charter can be added after consensus on acceptance in the working
 group and approval by the responsible Area Director.

Goals and Milestones:
 Done     - Submit document on restarting the RTO timer to the IESG for publication as an Experimental RFC
 Done     - Submit document on TCP support for rate-limited traffic for publication (status decided as earlier milestone)
 Done     - Submit document on an analysis of more detailed ECN feedback in TCP to the IESG for publication as an Informational RFC
 Done     - Submit revision of TCP roadmap (RFC 4614) to the IESG for publication as an Informational RFC
 Done     - Submit document obsoleting undeployed TCP extensions to the IESG for publication as an Informational RFC
 Aug 2015 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC
 Done     - Submit document on Datacenter TCP (DCTCP) to the IESG for publication as Informational RFC
 Apr 2016 - Submit document on CUBIC congestion control to the IESG for publication as Informational RFC
 May 2016 - Submit document on Retransmission Timeout Considerations as Best Current Practice RFC
 Aug 2016 - Submit specification of more accurate ECN feedback in TCP to the IESG for publication as an Experimental RFC
 Sep 2017 - Submit document on a time-based fast loss detection algorithm for TCP to the IESG for publication as an Experimental RFC
 Nov 2017 - Submit RFC793bis document to the IESG for publication as Internet Standard
 Aug 2018 - Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC

Internet-Drafts:
 - Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status [draft-eggert-tcpm-historicize-02] (4 pages)
 - TCP Extensions for High Performance [draft-ietf-tcpm-1323bis-21] (49 pages)
 - A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP [draft-ietf-tcpm-3517bis-02] (15 pages)
 - Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback [draft-ietf-tcpm-accecn-reqs-08] (17 pages)
 - More Accurate ECN Feedback in TCP [draft-ietf-tcpm-accurate-ecn-05] (43 pages)
 - TCP Alternative Backoff with ECN (ABE) [draft-ietf-tcpm-alternativebackoff-ecn-05] (13 pages)
 - Support for Stronger Error Detection Codes in TCP for Jumbo Frames [draft-ietf-tcpm-anumita-tcp-stronger-checksum-00] (10 pages)
 - CUBIC for Fast Long-Distance Networks [draft-ietf-tcpm-cubic-07] (17 pages)
 - Data Center TCP (DCTCP): TCP Congestion Control for Data Centers [draft-ietf-tcpm-dctcp-10] (17 pages)
 - Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) [draft-ietf-tcpm-early-rexmt-04] (15 pages)
 - Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets [draft-ietf-tcpm-ecnsyn-10] (33 pages)
 - Shared Use of Experimental TCP Options [draft-ietf-tcpm-experimental-options-06] (11 pages)
 - TCP Fast Open [draft-ietf-tcpm-fastopen-10] (26 pages)
 - Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) [draft-ietf-tcpm-frto-02] (23 pages)
 - ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets [draft-ietf-tcpm-generalized-ecn-02] (37 pages)
 - ICMP Attacks against TCP [draft-ietf-tcpm-icmp-attacks-12] (36 pages)
 - Increasing TCP's Initial Window [draft-ietf-tcpm-initcwnd-08] (24 pages)
 - Updating TCP to Support Rate-Limited Traffic [draft-ietf-tcpm-newcwv-13] (21 pages)
 - TCP Sender Clarification for Persist Condition [draft-ietf-tcpm-persist-07] (7 pages)
 - Proportional Rate Reduction for TCP [draft-ietf-tcpm-proportional-rate-reduction-04] (16 pages)
 - RACK: a time-based fast loss detection algorithm for TCP [draft-ietf-tcpm-rack-02] (22 pages)
 - Defending against Sequence Number Attacks [draft-ietf-tcpm-rfc1948bis-02] (12 pages)
 - TCP Congestion Control [draft-ietf-tcpm-rfc2581bis-07] (18 pages)
 - The NewReno Modification to TCP's Fast Recovery Algorithm [draft-ietf-tcpm-rfc3782-bis-05] (16 pages)
 - Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP [draft-ietf-tcpm-rfc4138bis-04] (19 pages)
 - Transmission Control Protocol Specification [draft-ietf-tcpm-rfc793bis-07] (101 pages)
 - Retransmission Timeout Requirements [draft-ietf-tcpm-rto-consider-05] (9 pages)
 - TCP and Stream Control Transmission Protocol (SCTP) RTO Restart [draft-ietf-tcpm-rtorestart-10] (15 pages)
 - Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation [draft-ietf-tcpm-sack-recovery-entry-01] (18 pages)
 - TCP SYN Flooding Attacks and Common Mitigations [draft-ietf-tcpm-syn-flood-05] (19 pages)
 - Defending TCP Against Spoofing Attacks [draft-ietf-tcpm-tcp-antispoof-06] (28 pages)
 - Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) [draft-ietf-tcpm-tcp-ao-crypto-03] (15 pages)
 - The TCP Authentication Option [draft-ietf-tcpm-tcp-auth-opt-11] (48 pages)
 - Improving the Robustness of TCP to Non-Congestion Events [draft-ietf-tcpm-tcp-dcr-07] (18 pages)
 - TCP Extended Data Offset Option [draft-ietf-tcpm-tcp-edo-09] (23 pages)
 - Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) [draft-ietf-tcpm-tcp-lcd-03] (23 pages)
 - A Roadmap for Transmission Control Protocol (TCP) Specification Documents [draft-ietf-tcpm-tcp-rfc4614bis-08] (57 pages)
 - A Roadmap for Transmission Control Protocol (TCP) Specification Documents [draft-ietf-tcpm-tcp-roadmap-06] (33 pages)
 - Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations [draft-ietf-tcpm-tcp-security-03] (86 pages)
 - TCP's Reaction to Soft Errors [draft-ietf-tcpm-tcp-soft-errors-09] (13 pages)
 - Reducing the TIME-WAIT State Using TCP Timestamps [draft-ietf-tcpm-tcp-timestamps-04] (10 pages)
 - TCP User Timeout Option [draft-ietf-tcpm-tcp-uto-11] (14 pages)
 - TCP Options and Maximum Segment Size (MSS) [draft-ietf-tcpm-tcpmss-05] (9 pages)
 - Improving TCP's Robustness to Blind In-Window Attacks [draft-ietf-tcpm-tcpsecure-13] (19 pages)
 - Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status [draft-ietf-tcpm-undeployed-03] (8 pages)
 - On the Implementation of the TCP Urgent Mechanism [draft-ietf-tcpm-urgent-data-07] (12 pages)
 - Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option [draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02] (16 pages)
 - Computing TCP's Retransmission Timer [draft-paxson-tcpm-rfc2988bis-02] (11 pages)

Requests for Comments:
 BCP159: Reducing the TIME-WAIT State Using TCP Timestamps (10 pages)
 RFC4138: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) (23 pages)
          * Updates RFC5682
 RFC4614: A Roadmap for Transmission Control Protocol (TCP) Specification Documents (33 pages)
          * Updates RFC6247
          * Obsoletes RFC7414
 RFC4653: Improving the Robustness of TCP to Non-Congestion Events (18 pages)
 RFC4953: Defending TCP Against Spoofing Attacks (28 pages)
 RFC4987: TCP SYN Flooding Attacks and Common Mitigations (19 pages)
 RFC5461: TCP's Reaction to Soft Errors (13 pages)
 RFC5482: TCP User Timeout Option (14 pages)
 RFC5562: Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets (33 pages)
 RFC5681: TCP Congestion Control (18 pages)
          * Obsoletes RFC2581
 RFC5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP (19 pages)
          * Updates RFC4138
 RFC5827: Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) (15 pages)
 RFC5925: The TCP Authentication Option (48 pages)
          * Obsoletes RFC2385
 RFC5926: Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) (15 pages)
 RFC5927: ICMP Attacks against TCP (36 pages)
 RFC5961: Improving TCP's Robustness to Blind In-Window Attacks (19 pages)
 RFC6069: Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) (23 pages)
 RFC6093: On the Implementation of the TCP Urgent Mechanism (12 pages)
          * Updates RFC793
          * Updates RFC1011
          * Updates RFC1122
 RFC6191: Reducing the TIME-WAIT State Using TCP Timestamps (10 pages)
 RFC6247: Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status (4 pages)
          * Obsoletes RFC1072
          * Obsoletes RFC1106
          * Obsoletes RFC1110
          * Obsoletes RFC1145
          * Obsoletes RFC1146
          * Obsoletes RFC1379
          * Obsoletes RFC1644
          * Obsoletes RFC1693
          * Updates RFC4614
 RFC6298: Computing TCP's Retransmission Timer (11 pages)
          * Updates RFC1122
          * Obsoletes RFC2988
 RFC6429: TCP Sender Clarification for Persist Condition (7 pages)
 RFC6528: Defending against Sequence Number Attacks (12 pages)
          * Updates RFC793
          * Obsoletes RFC1948
 RFC6582: The NewReno Modification to TCP's Fast Recovery Algorithm (16 pages)
          * Obsoletes RFC3782
 RFC6675: A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP (15 pages)
          * Obsoletes RFC3517
 RFC6691: TCP Options and Maximum Segment Size (MSS) (9 pages)
          * Updates RFC2385
          * Updates RFC879
 RFC6928: Increasing TCP's Initial Window (24 pages)
 RFC6937: Proportional Rate Reduction for TCP (16 pages)
 RFC6994: Shared Use of Experimental TCP Options (11 pages)
 RFC7323: TCP Extensions for High Performance (49 pages)
          * Obsoletes RFC1323
 RFC7413: TCP Fast Open (26 pages)
 RFC7414: A Roadmap for Transmission Control Protocol (TCP) Specification Documents (57 pages)
          * Obsoletes RFC4614
          * Updates RFC7805
 RFC7560: Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback (17 pages)
 RFC7661: Updating TCP to Support Rate-Limited Traffic (21 pages)
          * Obsoletes RFC2861
 RFC7765: TCP and Stream Control Transmission Protocol (SCTP) RTO Restart (15 pages)
 RFC7805: Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status (8 pages)
          * Obsoletes RFC675
          * Obsoletes RFC721
          * Obsoletes RFC761
          * Obsoletes RFC813
          * Obsoletes RFC816
          * Obsoletes RFC879
          * Obsoletes RFC896
          * Obsoletes RFC1078
          * Obsoletes RFC6013
          * Updates RFC7414
 RFC8257: Data Center TCP (DCTCP): TCP Congestion Control for Data Centers (17 pages)



Transport Area Working Group (tsvwg)
------------------------------------

Charter
Last Modified: 2016-12-07

Current Status: Active

Chairs:
    David L. Black <[email protected]>
    Gorry Fairhurst <[email protected]>
    Wesley Eddy <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Spencer Dawkins <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/tsvwg
    Archive:            https://mailarchive.ietf.org/arch/browse/tsvwg/

Description of Working Group:


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

   The TSVWG mailing list is an open discussion forum for such work items,
   when they arise. The working group meets if there are active proposals
   that require discussion. The working group milestones are updated as
   needed to reflect the current work items and their associated
   milestones.

   The currently active TSVWG work items mostly fall under the
   Following topics:

   (A) Maintenance of the Stream Control Transmission Protocol
   (SCTP), which involves bug fixes to the SCTP specifications and their
   progression along the standards track. This work item also includes a
   small number of modular extensions to SCTP. In order to maintain stable
   specifications, additional work on SCTP in TSVWG requires Area Director
   approval.

   (B) Maintenance of the Resource Reservation Protocol (RSVP) which
   involves bug fixes to RSVP specifications and their progression along
   the standards track.  This work item may also include a small number
   of extensions to both RSVP and Integrated Services or advisory documents
   to address specific application scenarios. In order to maintain stable
   specifications, additional work on RSVP and/or Integrated Services in
   TSVWG requires Area Director approval.

   (C) Maintenance of IP Differentiated Services (DiffServ) mechanisms,
   which involves mostly advisory documents on the use of DiffServ in
   specific application scenarios. Other work items related to DiffServ
   require Area Director approval.

   (D) Selected other work items, which are mostly in TSVWG for historic
   reasons.

   Additional work that does not fall under one of the above topics in
   TSVWG must satisfy four conditions:
   (1) WG consensus on the suitability and projected quality of the
   proposed work item.
   (2) A core group of WG participants with sufficient energy and expertise
   to advance the work item according to the proposed schedule.
   (3) Commitment from the WG as a whole to provide sufficient and timely
   review of the proposed work item.
   (4) 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:
 Done     - Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard
 Done     - Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard
 Done     - Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard
 Done     - Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard.
 Done     - Submit revised ID for ECN to IESG for consideration as a proposed standard
 Done     - Submit ID on UDP-lite to IESG for consideration as a proposed standard
 Done     - TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard
 Done     - Submit ID for SCTP unreliable transport mode to IESG for consideration as a Proposed Standard
 Done     - Submit 'Alternate Semantics for the ECN Field' to IESG for consideration as BCP
 Done     - Submit 'Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels' to IESG for consideration as PS
 Done     - Submit Submit 'QoS Signaling in a Nested Virtual Private Network' to IESG for consideration as Informational
 Done     - Submit 'Generic Aggregate RSVP Reservations' to IESG for consideration as PS
 Done     - Submit 'Quick-Start for TCP and IP' to IESG for consideration as Experimental
 Done     - Submit 'TCP Extended Statistics MIB' to IESG for consideration as PS
 Done     - Submit 'Authenticated Chunks for Stream Control Transmission Protocol' to IESG as consideration as PS
 Done     - Submit 'Padding Chunk and Parameter for SCTP' to IESG for consideration as PS
 Done     - Submit 'SCTP Dynamic Address Reconfiguration' to IESG for consideration as Proposed Standard
 Done     - Submit revision of 'Stream Control Transmission Protocol' to IESG for consideration as Proposed Standard
 Done     - Submit 'Security Attacks Found Against SCTP and Current Countermeasures' to IESG for consideration as Informational
 Done     - Submit 'Specifying New Congestion Control Algorithms' to IESG for consideration as Best Current Practice
 Done     - Submit 'Aggregation of DiffServ Service Classes' to IESG for consideration as Informational
 Done     - Submit 'Explicit Congestion Marking in MPLS' to IESG for consideration as Proposed Standard
 Done     - Submit 'User-Defined Errors for RSVP' to IESG for consideration as Proposed Standard
 Done     - Submit 'RSVP Extensions for Emergency Services' to IESG for consideration as Proposed Standard
 Done     - Submit 'DSCPs for Capacity-Admitted Traffic' to IESG for consideration as Proposed Standard
 Done     - Submit 'RSVP Proxy Approaches' to IESG for consideration as Informational
 Done     - Submit 'RSVP Extensions for Path-Triggered RSVP Receiver Proxy' to IESG for consideration as Proposed Standard
 Done     - Submit 'UDP Usage Guidelines for Application Designers' to IESG for consideration as Best Current Practice
 Done     - Request publication of 'Support for RSVP in Layer 3 VPNs' as Proposed Standard RFC
 Done     - Submit 'Port Randomization for Transport Protocols' to the IESG for consideration as a Best Current Practice
 Done     - Submit 'Applicability of Keying Methods for RSVP Security' to IESG for consideration as Informational
 Done     - Request publication of 'IANA Procedures for the Transport Protocol Port Number Space' as BCP RFC
 Done     - Request publication of 'Datagram Transport Layer Security for Stream Control Transmission' as Proposed Standard
 Done     - Request publication of 'Layered Encapsulation of Congestion Notification' as Proposed Standard
 Done     - Submit 'SCTP Chunk Flags Registration' to IESG for consideration as a Proposed Standard
 Done     - Submit 'Sockets API Extensions for SCTP' to IESG for consideration as Informational
 Done     - Submit 'SCTP Stream Reconfiguration' to IESG for consideration as a Proposed Standard
 Done     - Submit 'Deprecation of ICMP Source Quench messages' to IESG for consideration as a Proposed Standard
 Done     - Submit 'Byte and Packet Congestion Notification' to IESG for consideration as a Best Current Practice RFC
 Done     - Submit 'UDP Encapsulation of SCTP Packets' to IESG for consideration as a Proposed Standard RFC
 Done     - Submit 'SCTP SACK Immediately' to IESG for consideration as a Proposed Standard RFC
 Done     - Submit 'Encoding and Transport of (Pre-) Congestion Information from the Domain Egress to the Ingress' to the IESG for consideration as an Experimental RFC
 Done     - Submit 'SCTP PR Polices' as a PS RFC
 Done     - Submit 'Recommendations for Transport Port Uses' to the IESG
 Done     - Submit 'DTLS Encapsulation of SCTP Packets for RTCWEB ' to IESG for consideration as a Proposed Standard RFC
 Done     - Submit 'Quick Failover Algorithm in SCTP' to the IESG for consideration as a Proposed Standard RFC
 Done     - Submit 'Behavioral Requirements Updates'’ as a BCP RFC
 Done     - Submit 'Network Transport Circuit Breakers' to IESG
 Done     - Submit 'UDP Usage Guidelines' as a BCP RFC
 Done     - Submit 'DiffServ interconnection classes and practice' as an Informational  RFC
 Done     - Submit 'DSCP packet markings for RTCWeb QoS' to IESG as a Proposed Standard RFC
 Done     - Submit 'Specification of GRE in UDP encapsulation' to IESG as a PS RFC
 Done     - Submit 'SCTP New Data Chunk' as a Proposed Standard RFC
 Done     - Submit ‘Explicit Congestion Notification (ECN) Experimentation’        as a Proposed Standard RFC
 Done     - Submit "Guidelines for DiffServ to IEEE 802.11 Mapping" as a Proposed Standard RFC
 Dec 2017 - Submit 'RFC 4960 Errata and Issues' (SCTP) as an Informational RFC
 Jan 2018 - Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC
 Jan 2018 - Submit 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' as a Proposed Standard RFC
 Apr 2018 - Submit 'A Lower Effort Per-Hop Behavior (LE PHB)' as a Proposed Standard RFC
 May 2018 - Submit 'SCTP NAT Support' to IESG for consideration as a PS RFC
 Jun 2018 - Submit "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes" as a Proposed Standard RFC
 Jun 2018 - Submit "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Scheme for FECFRAME" as a Proposed Standard RFC
 Sep 2018 - Submit "Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture" as an Informational RFC
 Sep 2018 - Submit "DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput" as an Experimental RFC
 Sep 2018 - Submit "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay" as an Experimental RFC
 Dec 2018 - Submit 'Tunnel Congestion Feedback' as an Informational RFC
 Dec 2018 - Submit " Transport Options for UDP" as a Proposed Standard RFC
 Dec 2018 - Submit 'Packetization Layer Path MTU Discovery for Datagram Transports' as a Proposed Standard RFC

Internet-Drafts:
 - A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP [draft-allman-tcp-sack-13] (13 pages)
 - Explicit Congestion Notification (ECN) Experimentation [draft-black-tsvwg-ecn-experimentation-04] (14 pages)
 - A Lower Effort Per-Hop Behavior (LE PHB) [draft-bless-tsvwg-le-phb-01] (7 pages)
 - DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput [draft-briscoe-tsvwg-aqm-dualq-coupled-00] (24 pages)
 - Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay [draft-briscoe-tsvwg-ecn-l4s-id-02] (25 pages)
 - Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture [draft-briscoe-tsvwg-l4s-arch-02] (34 pages)
 - Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim [draft-briscoe-tsvwg-rfc6040bis-01] (6 pages)
 - UDP Usage Guidelines [draft-eggert-tsvwg-rfc5405bis-01] (37 pages)
 - Packetization Layer Path MTU Discovery for Datagram Transports [draft-fairhurst-tsvwg-datagram-plpmtud-02] (26 pages)
 - An Extension to the Selective Acknowledgement (SACK) Option for TCP [draft-floyd-sack-00] (17 pages)
 - DiffServ interconnection classes and practice [draft-geib-tsvwg-diffserv-intercon-08] (22 pages)
 - TCP Congestion Window Validation [draft-handley-tcp-cwv-01] (11 pages)
 - Stream Control Transmission Protocol [draft-ietf-tsvwg-2960bis-05] (152 pages)
 - Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration [draft-ietf-tsvwg-addip-sctp-22] (41 pages)
 - A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic [draft-ietf-tsvwg-admitted-realtime-dscp-07] (14 pages)
 - DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) [draft-ietf-tsvwg-aqm-dualq-coupled-03] (36 pages)
 - Updates to Network Address Translation (NAT) Behavioral Requirements [draft-ietf-tsvwg-behave-requirements-update-08] (14 pages)
 - Byte and Packet Congestion Notification [draft-ietf-tsvwg-byte-pkt-congest-12] (41 pages)
 - Specifying New Congestion Control Algorithms [draft-ietf-tsvwg-cc-alt-04] (10 pages)
 - Network Transport Circuit Breakers [draft-ietf-tsvwg-circuit-breaker-15] (24 pages)
 - Packetization Layer Path MTU Discovery for Datagram Transports [draft-ietf-tsvwg-datagram-plpmtud-00] (27 pages)
 - Aggregation of Diffserv Service Classes [draft-ietf-tsvwg-diffserv-class-aggr-07] (19 pages)
 - Diffserv-Interconnection Classes and Practice [draft-ietf-tsvwg-diffserv-intercon-14] (21 pages)
 - Configuration Guidelines for DiffServ Service Classes [draft-ietf-tsvwg-diffserv-service-classes-02] (57 pages)
 - Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions [draft-ietf-tsvwg-dsack-use-02] (9 pages)
 - Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-dtls-for-sctp-06] (9 pages)
 - The Addition of Explicit Congestion Notification (ECN) to IP [draft-ietf-tsvwg-ecn-04] (63 pages)
 - Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field [draft-ietf-tsvwg-ecn-alternates-02] (15 pages)
 - Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP [draft-ietf-tsvwg-ecn-encap-guidelines-09] (35 pages)
 - Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation [draft-ietf-tsvwg-ecn-experimentation-08] (20 pages)
 - An Open ECN Service in the IP layer [draft-ietf-tsvwg-ecn-ip-00] (15 pages)
 - Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay [draft-ietf-tsvwg-ecn-l4s-id-01] (32 pages)
 - Explicit Congestion Marking in MPLS [draft-ietf-tsvwg-ecn-mpls-02] (21 pages)
 - Tunnelling of Explicit Congestion Notification [draft-ietf-tsvwg-ecn-tunnel-10] (35 pages)
 - ECN Interactions with IP Tunnels
[draft-ietf-tsvwg-ecn-tunnels-00] (13 pages)
 - Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets [draft-ietf-tsvwg-ecnsyn-00] (14 pages)
 - RSVP Extensions for Admission Priority [draft-ietf-tsvwg-emergency-rsvp-15] (32 pages)
 - Forward Error Correction (FEC) Framework Extension to Sliding Window Codes [draft-ietf-tsvwg-fecframe-ext-00] (20 pages)
 - GRE-in-UDP Encapsulation [draft-ietf-tsvwg-gre-in-udp-encap-19] (27 pages)
 - HighSpeed TCP for Large Congestion Windows [draft-ietf-tsvwg-highspeed-01] (34 pages)
 - IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC [draft-ietf-tsvwg-iana-dscp-registry-00] (7 pages)
 - Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry [draft-ietf-tsvwg-iana-ports-10] (33 pages)
 - Diffserv to IEEE 802.11 Mapping [draft-ietf-tsvwg-ieee-802-11-11] (36 pages)
 - Increasing TCP's Initial Window [draft-ietf-tsvwg-initwin-04] (15 pages)
 - Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1 [draft-ietf-tsvwg-intserv-multiple-tspec-02] (26 pages)
 - Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture [draft-ietf-tsvwg-l4s-arch-01] (31 pages)
 - A Lower Effort Per-Hop Behavior (LE PHB) [draft-ietf-tsvwg-le-phb-03] (13 pages)
 - Enhancing TCP's Loss Recovery Using Limited Transmit [draft-ietf-tsvwg-limited-xmit-00] (9 pages)
 - MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements [draft-ietf-tsvwg-mlef-concerns-00] (20 pages)
 - Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite [draft-ietf-tsvwg-mlpp-that-works-04] (42 pages)
 - Stream Control Transmission Protocol (SCTP) Network Address Translation Support [draft-ietf-tsvwg-natsupp-11] (44 pages)
 - The NewReno Modification to TCP's Fast Recovery Algorithm [draft-ietf-tsvwg-newreno-02] (19 pages)
 - Recommendations for Transport-Protocol Port Randomization [draft-ietf-tsvwg-port-randomization-09] (29 pages)
 - Recommendations on Using Assigned Transport Port Numbers [draft-ietf-tsvwg-port-use-11] (24 pages)
 - Stream Control Transmission Protocol (SCTP) Partial Reliability Extension [draft-ietf-tsvwg-prsctp-03] (22 pages)
 - Quick-Start for TCP and IP [draft-ietf-tsvwg-quickstart-07] (82 pages)
 - Stream Control Transmission Protocol [draft-ietf-tsvwg-rfc2960-bis-00] (116 pages)
 - RFC 4960 Errata and Issues [draft-ietf-tsvwg-rfc4960-errata-04] (87 pages)
 - UDP Usage Guidelines [draft-ietf-tsvwg-rfc5405bis-19] (55 pages)
 - Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim [draft-ietf-tsvwg-rfc6040update-shim-05] (20 pages)
 - Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME [draft-ietf-tsvwg-rlc-fec-scheme-01] (25 pages)
 - Resource Reservation Protocol (RSVP) Application-ID Profiles for Voice and Video Streams [draft-ietf-tsvwg-rsvp-app-id-vv-profiles-02] (15 pages)
 - A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow [draft-ietf-tsvwg-rsvp-bw-reduction-02] (21 pages)
 - Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels [draft-ietf-tsvwg-rsvp-dste-05] (31 pages)
 - Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations [draft-ietf-tsvwg-rsvp-ipsec-05] (32 pages)
 - Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs [draft-ietf-tsvwg-rsvp-l3vpn-07] (38 pages)
 - Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains [draft-ietf-tsvwg-rsvp-pcn-11] (36 pages)
 - Resource Reservation Protocol (RSVP) Proxy Approaches [draft-ietf-tsvwg-rsvp-proxy-approaches-09] (50 pages)
 - Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy [draft-ietf-tsvwg-rsvp-proxy-proto-11] (35 pages)
 - Applicability of Keying Methods for RSVP Security [draft-ietf-tsvwg-rsvp-security-groupkeying-11] (19 pages)
 - User-Defined Errors for RSVP [draft-ietf-tsvwg-rsvp-user-error-spec-08] (9 pages)
 - DSCP Packet Markings for WebRTC QoS [draft-ietf-tsvwg-rtcweb-qos-18] (11 pages)
 - Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctp-auth-08] (19 pages)
 - Stream Control Transmission Protocol (SCTP) Chunk Flags Registration [draft-ietf-tsvwg-sctp-chunk-flags-02] (8 pages)
 - Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets [draft-ietf-tsvwg-sctp-dtls-encaps-09] (10 pages)
 - SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol [draft-ietf-tsvwg-sctp-failover-16] (23 pages)
 - Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol [draft-ietf-tsvwg-sctp-ndata-13] (23 pages)
 - Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctp-padding-02] (6 pages)
 - Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension [draft-ietf-tsvwg-sctp-prpolicies-07] (11 pages)
 - SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol [draft-ietf-tsvwg-sctp-sack-immediately-04] (8 pages)
 - Stream Control Transmission Protocol (SCTP) Stream Reconfiguration [draft-ietf-tsvwg-sctp-strrst-13] (34 pages)
 - UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication [draft-ietf-tsvwg-sctp-udp-encaps-14] (12 pages)
 - Stream Control Transmission Protocol (SCTP) Checksum Change [draft-ietf-tsvwg-sctpcsum-07] (17 pages)
 - Stream Control Transmission Protocol (SCTP) Specification Errata and Issues [draft-ietf-tsvwg-sctpimpguide-16] (109 pages)
 - Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctpsocket-32] (115 pages)
 - Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures [draft-ietf-tsvwg-sctpthreat-05] (14 pages)
 - Limited Slow-Start for TCP with Large Congestion Windows [draft-ietf-tsvwg-slowstart-00] (7 pages)
 - Deprecation of ICMP Source Quench Messages [draft-ietf-tsvwg-source-quench-06] (8 pages)
 - TCP with ECN: The Treatment of Retransmitted Data Packets [draft-ietf-tsvwg-tcp-ecn-00] (9 pages)
 - The Eifel Detection Algorithm for TCP [draft-ietf-tsvwg-tcp-eifel-alg-07] (14 pages)
 - The Eifel Response Algorithm for TCP [draft-ietf-tsvwg-tcp-eifel-response-06] (13 pages)
 - F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP [draft-ietf-tsvwg-tcp-frto-01] (19 pages)
 - TCP Extended Statistics MIB [draft-ietf-tsvwg-tcp-mib-extension-15] (75 pages)
 - Robust Explicit Congestion Notification (ECN) Signaling with Nonces [draft-ietf-tsvwg-tcp-nonce-04] (13 pages)
 - ULP Framing for TCP [draft-ietf-tsvwg-tcp-ulp-frame-01] (30 pages)
 - TCP Friendly Rate Control (TFRC): Protocol Specification [draft-ietf-tsvwg-tfrc-05] (24 pages)
 - Transport Layer Security over Stream Control Transmission Protocol [draft-ietf-tsvwg-tls-over-sctp-00] (9 pages)
 - Tunnel Congestion Feedback [draft-ietf-tsvwg-tunnel-congestion-feedback-06] (19 pages)
 - Unicast UDP Usage Guidelines for Application Designers [draft-ietf-tsvwg-udp-guidelines-11] (27 pages)
 - The Lightweight User Datagram Protocol (UDP-Lite) [draft-ietf-tsvwg-udp-lite-02] (12 pages)
 - Transport Options for UDP [draft-ietf-tsvwg-udp-options-02] (27 pages)
 - MIB for the UDP-Lite protocol [draft-ietf-tsvwg-udplite-mib-03] (23 pages)
 - SCTP Unreliable Data Mode Extension [draft-ietf-tsvwg-usctp-00] (10 pages)
 - Quality of Service (QoS) Signaling in a Nested Virtual Private Network [draft-ietf-tsvwg-vpn-signaled-preemption-02] (38 pages)
 - Computing TCP's Retransmission Timer [draft-paxson-tcp-rto-01] (8 pages)
 - Guidelines for DiffServ to IEEE 802.11 Mapping [draft-szigeti-tsvwg-ieee-802-11-02] (27 pages)
 - Transport Options for UDP [draft-touch-tsvwg-udp-options-09] (27 pages)
 - RFC 4960 Errata and Issues [draft-tuexen-tsvwg-rfc4960-errata-04] (44 pages)
 - TCP Processing of the IPv4 Precedence Field [draft-xiao-tcp-prec-03] (8 pages)

Requests for Comments:
 BCP124: Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field (15 pages)
 BCP133: Specifying New Congestion Control Algorithms (10 pages)
 BCP145: Unicast UDP Usage Guidelines for Application Designers (27 pages)
 BCP156: Recommendations for Transport-Protocol Port Randomization (29 pages)
 BCP165: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (33 pages)
          * Updates RFC2780
          * Updates RFC2782
          * Updates RFC3828
          * Updates RFC4340
          * Updates RFC4960
          * Updates RFC5595
 BCP208: Network Transport Circuit Breakers (24 pages)
 RFC2861: TCP Congestion Window Validation (11 pages)
          * Obsoletes RFC7661
 RFC2873: TCP Processing of the IPv4 Precedence Field (8 pages)
 RFC2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP (17 pages)
 RFC2988: Computing TCP's Retransmission Timer (8 pages)
          * Obsoletes RFC6298
 RFC3042: Enhancing TCP's Loss Recovery Using Limited Transmit (9 pages)
 RFC3168: The Addition of Explicit Congestion Notification (ECN) to IP (63 pages)
          * Updates RFC793
          * Updates RFC2003
          * Updates RFC2401
          * Updates RFC2474
          * Obsoletes RFC2481
          * Updates RFC4301
          * Updates RFC6040
          * Updates RFC8311
 RFC3309: Stream Control Transmission Protocol (SCTP) Checksum Change (17 pages)
          * Updates RFC2960
          * Obsoletes RFC4960
 RFC3390: Increasing TCP's Initial Window (15 pages)
          * Obsoletes RFC2414
          * Updates RFC2581
 RFC3436: Transport Layer Security over Stream Control Transmission Protocol (9 pages)
 RFC3448: TCP Friendly Rate Control (TFRC): Protocol Specification (24 pages)
          * Obsoletes RFC5348
 RFC3517: A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP (13 pages)
          * Obsoletes RFC6675
 RFC3522: The Eifel Detection Algorithm for TCP (14 pages)
 RFC3540: Robust Explicit Congestion Notification (ECN) Signaling with Nonces (13 pages)
 RFC3649: HighSpeed TCP for Large Congestion Windows (34 pages)
 RFC3708: Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions (9 pages)
 RFC3742: Limited Slow-Start for TCP with Large Congestion Windows (7 pages)
 RFC3758: Stream Control Transmission Protocol (SCTP) Partial Reliability Extension (22 pages)
 RFC3782: The NewReno Modification to TCP's Fast Recovery Algorithm (19 pages)
          * Obsoletes RFC2582
          * Obsoletes RFC6582
 RFC3828: The Lightweight User Datagram Protocol (UDP-Lite) (12 pages)
          * Updates RFC6335
 RFC4015: The Eifel Response Algorithm for TCP (13 pages)
 RFC4460: Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (109 pages)
 RFC4495: A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow (21 pages)
          * Updates RFC2205
 RFC4542: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite (42 pages)
          * Updates RFC5865
 RFC4594: Configuration Guidelines for DiffServ Service Classes (57 pages)
          * Updates RFC5865
 RFC4774: Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field (15 pages)
          * Updates RFC6040
 RFC4782: Quick-Start for TCP and IP (82 pages)
 RFC4804: Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels (31 pages)
 RFC4820: Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) (6 pages)
 RFC4860: Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (32 pages)
 RFC4895: Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) (19 pages)
 RFC4898: TCP Extended Statistics MIB (75 pages)
 RFC4923: Quality of Service (QoS) Signaling in a Nested Virtual Private Network (38 pages)
 RFC4960: Stream Control Transmission Protocol (152 pages)
          * Obsoletes RFC2960
          * Obsoletes RFC3309
          * Updates RFC6096
          * Updates RFC6335
          * Updates RFC7053
 RFC5033: Specifying New Congestion Control Algorithms (10 pages)
 RFC5061: Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration (41 pages)
 RFC5062: Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures (14 pages)
 RFC5097: MIB for the UDP-Lite protocol (23 pages)
 RFC5127: Aggregation of Diffserv Service Classes (19 pages)
 RFC5129: Explicit Congestion Marking in MPLS (21 pages)
          * Updates RFC3032
          * Updates RFC5462
 RFC5284: User-Defined Errors for RSVP (9 pages)
 RFC5405: Unicast UDP Usage Guidelines for Application Designers (27 pages)
          * Obsoletes RFC8085
 RFC5865: A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic (14 pages)
          * Updates RFC4542
          * Updates RFC4594
 RFC5945: Resource Reservation Protocol (RSVP) Proxy Approaches (50 pages)
 RFC5946: Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy (35 pages)
          * Updates RFC2205
 RFC6016: Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs (38 pages)
 RFC6040: Tunnelling of Explicit Congestion Notification (35 pages)
          * Updates RFC3168
          * Updates RFC4301
          * Updates RFC4774
 RFC6056: Recommendations for Transport-Protocol Port Randomization (29 pages)
 RFC6083: Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) (9 pages)
 RFC6096: Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (8 pages)
          * Updates RFC4960
 RFC6335: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (33 pages)
          * Updates RFC2780
          * Updates RFC2782
          * Updates RFC3828
          * Updates RFC4340
          * Updates RFC4960
          * Updates RFC5595
 RFC6401: RSVP Extensions for Admission Priority (32 pages)
 RFC6411: Applicability of Keying Methods for RSVP Security (19 pages)
 RFC6458: Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) (115 pages)
 RFC6525: Stream Control Transmission Protocol (SCTP) Stream Reconfiguration (34 pages)
 RFC6633: Deprecation of ICMP Source Quench Messages (8 pages)
          * Updates RFC1122
          * Updates RFC1812
          * Updates RFC792
 RFC6951: UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication (12 pages)
 RFC7053: SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (8 pages)
          * Updates RFC4960
 RFC7141: Byte and Packet Congestion Notification (41 pages)
          * Updates RFC2914
          * Updates RFC2309
 RFC7417: Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains (36 pages)
 RFC7496: Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension (11 pages)
 RFC7605: Recommendations on Using Assigned Transport Port Numbers (24 pages)
 RFC7829: SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol (23 pages)
 RFC7857: Updates to Network Address Translation (NAT) Behavioral Requirements (14 pages)
          * Updates RFC4787
          * Updates RFC5382
          * Updates RFC5508
 RFC8084: Network Transport Circuit Breakers (24 pages)
 RFC8085: UDP Usage Guidelines (55 pages)
          * Obsoletes RFC5405
 RFC8086: GRE-in-UDP Encapsulation (27 pages)
 RFC8100: Diffserv-Interconnection Classes and Practice (21 pages)
 RFC8260: Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol (23 pages)
 RFC8261: Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets (10 pages)
 RFC8311: Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation (20 pages)
          * Updates RFC3168
          * Updates RFC4341
          * Updates RFC4342
          * Updates RFC5622
          * Updates RFC6679



Transport Services (taps)
-------------------------

Charter
Last Modified: 2016-04-03

Current Status: Active

Chairs:
    Aaron Falk <[email protected]>
    Zaheduzzaman Sarker <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Spencer Dawkins <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/taps
    Archive:            https://mailarchive.ietf.org/arch/browse/taps/

Description of Working Group:

 Most Internet applications make use of the Transport Services
 provided by TCP (a reliable, in-order stream protocol) or UDP
 (an unreliable datagram protocol).   We use the term "Transport
 Service" to mean an end-to-end facility provided by the
 transport layer. That service can only be provided correctly if
 information is supplied from the application. The application may
 determine the information to be supplied at design time,
 compile time, or run time and may include guidance on whether
 the facility  in question is required or simply a preference by the
 application. Four examples of Transport Services are reliable
 delivery, ordered delivery of data, content privacy to in-path
 devices, and minimal latency.

 Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and
 UDP-Lite and the LEDBAT congestion control mechanism extend the
 set of available Transport Services beyond those provided to
 applications by TCP and UDP. For example, SCTP provides potentially
 faster reliable delivery for applications than TCP because it can
 accept blocks of data out of order, and LEDBAT provides low-priority
 "scavenger" communication.

 However, application programmers face difficulty when they use
 protocols other than TCP or UDP. Most network stacks ship with only
 TCP and UDP as transport protocols.  Many firewalls only pass TCP
 and UDP and some  only allow TCP  when it carries HTTP as its payload.
 As a result, using other transport protocols or building a new protocol
 over raw sockets risks having an application not work in many
 environments. Applications, therefore, must always be able to fall back
 to TCP or UDP, or even to using HTTP as a transport substrate in some
 cases, and once the application programmer has committed
 to making an application work on TCP or UDP or HTTP, there is little
 incentive to try other transport protocols before falling back.
 Further, different protocols can provide the same services in different
 ways. Layering decisions must also be made (for example, whether a
 protocol is used natively or tunneled through UDP).

 Because of these complications, programmers often resort to either
 using TCP or HTTP or implementing their own customized "transport
 services" over UDP. When application developers re-implement transport
 features already available elsewhere they open the door to problems
 that simply using TCP would have avoided and ensure that the
 applications can't benefit from other transport protocols as they
 become available. And, since even TCP and UDP are not guaranteed to
 work in all environments today, some programmers simply give up on
 using TCP or UDP directly, relying instead on "HTTP as a Substrate".
 BCP 56 identified many issues with this strategy, but assuming that
 if "any protocol is available on a given network path and on the hosts
 that will be communicating, that protocol will be HTTP" is a reasonable
 strategy for today's Internet. The IESG has agreed with this viewpoint
 enough to publish the WebSocket protocol on the standards track.

 The goal of the TAPS working group is to help application and network
 stack programmers by describing an (abstract) interface for applications
 to make use of Transport Services. The Working Group deliverables
 emphasize defining Transport Services that are important to applications
 followed by experimental mechanisms to a) determine if the protocols to
 provide the requested services are available on the end points and
 supported along the path in the network and b) fall back, i.e., select
 alternate, possibly less-preferred, protocols when desired protocols
 are not available. The Working Group will not define a richer set of
 Transport Services for applications, although the TAPS deliverables
 could inform proposals for future chartered work on Transport Services.

 The Working Group will:

 1) Define a set of Transport Services, identifying the
    services provided by existing IETF protocols and congestion
    control mechanisms. As a starting point, the working group will
    consider services used
    between two endpoints.

 2) Specify the subset of those Transport Services, as identified
    in item 1, that end systems supporting TAPS will provide, and
    give guidance on choosing among available mechanisms and
    protocols.  Note that not all the capabilities of IETF Transport
    protocols need to be exposed as Transport Services.

 3) Specify experimental support mechanisms to provide the Transport
    Services identified in work item 2. This document will explain
    how to select and engage an appropriate protocol and how to
    discover which protocols are available for the selected service
    between a given pair of end points. Further, it will provide a
    basis for incremental deployment. Work on this document will
    begin when the TAPS Transport Services have been specified.

 The following topics are out of scope for this Working Group:

 - Signaling-based Quality-of-Service (QoS) mechanisms

 - Definition of new encapsulations and tunneling mechanisms

 - Extension, modification, or creation of transport protocols

 - Language-specific APIs

 TAPS is not chartered to perform detailed analysis of the security
 aspects of transport protocols. While security can be a transport
 service, TAPS is being chartered almost simultaneously with TCPINC,
 which is developing the TCP extensions to provide unauthenticated
 encryption and integrity protection of TCP streams, and TAPS will
 work with TCPINC to ensure that TAPS will be able to accommodate
 the protocol extensions that TCPINC defines.

Goals and Milestones:
 Nov 2016 - Submit an Informational document to the IESG defining a set of services provided by IETF transport protocols and congestion control mechanisms
 Mar 2017 - Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support
 Nov 2017 - Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG
 Mar 2018 - Recharter or conclude.

Internet-Drafts:
 - Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols [draft-fairhurst-taps-transports-usage-udp-03] (18 pages)
 - A Minimal Set of Transport Services for TAPS Systems [draft-gjessing-taps-minset-05] (44 pages)
 - A Minimal Set of Transport Services for TAPS Systems [draft-ietf-taps-minset-00] (53 pages)
 - Services Provided by IETF Transport Protocols and Congestion Control Mechanisms [draft-ietf-taps-transports-14] (54 pages)
 - On the Usage of Transport Features Provided by IETF Transport Protocols [draft-ietf-taps-transports-usage-09] (57 pages)
 - Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols [draft-ietf-taps-transports-usage-udp-07] (22 pages)

Requests for Comments:
 RFC8095: Services Provided by IETF Transport Protocols and Congestion Control Mechanisms (54 pages)



TURN Revised and Modernized (tram)
----------------------------------

Charter
Last Modified: 2015-06-15

Current Status: Active

Chairs:
    Gonzalo Camarillo <[email protected]>
    Simon Perreault <[email protected]>

Transport Area Directors:
    Spencer Dawkins <[email protected]>
    Mirja Kühlewind <[email protected]>

Transport Area Advisor:
    Spencer Dawkins <[email protected]>

Mailing Lists:
    General Discussion: [email protected]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/tram
    Archive:            https://mailarchive.ietf.org/arch/browse/tram/

Description of Working Group:

 Traversal Using Relays around NAT (TURN) was published as RFC 5766 in
 April 2010. For a few years, the protocol had seen rather limited
 deployment. This is largely because its primary use case is as one
 of the NAT traversal methods of the Interactive Connectivity
 Establishment (ICE) framework (RFC 5245), and ICE itself was slow
 to achieve widespread adoption, as other mechanisms were already
 being used by the VoIP industry. This situation has changed
 drastically as ICE, and consequently TURN, are mandatory to implement
 in WebRTC, a set of technologies developed at the IETF and W3C to
 standardize Real Time Communication on the Web.

 Together with the arrival of WebRTC, there is a renewed interest in
 TURN and ICE, as evidenced by recent work updating the ICE framework
 (still in progress), and standardizing the URIs used to access a STUN
 (RFC 7064) or TURN (RFC 7065) server.

 The goal of the TRAM Working Group is to consolidate the various
 initiatives to update TURN and STUN to make them more suitable for
 NAT traversal in a variety of environments, whether for realtime
 media establishment protocols such as the Offer-Answer Session
 Description Protocol (RFC 3264), XMPP (XEP-0176), RTSP
 (draft-ietf-mmusic-rtsp-nat), and RTCWeb (draft-ietf-rtcweb-jsep),
 or for non-realtime protocols such as HIP (RFC 5770) and RELOAD
 (RFC 6940). The work will include authentication mechanisms,
 a path MTU discovery mechanism, an IP address mobility solution for
 TURN, and extensions to TURN and STUN.  The Working Group will closely
 coordinate with the appropriate Working Groups, including ICE, RTCWEB,
 MMUSIC, and HTTPBIS.

 In developing upgrades to TURN, the group will consider the passive
 monitoring risks introduced by the centralization of call traffic
 through a TURN server. When such risks arise, they will recommend
 appropriate mitigations.  For example, a mechanism for directing traffic
 to a TURN server other than one configured by the application could be
 used to direct calls through a TURN server configured to do monitoring.
 When such a mechanism is used, it is important that the endpoints to the
 call apply end-to-end encryption and authentication to ensure that they
 are protected from the TURN server.

Goals and Milestones:
 Nov 2015 - Send new TURN server discovery mechanism for enterprises and ISPs to IESG for publication as Proposed Standard
 Nov 2015 - Send path characteristic measurement mechanism to IESG for publication as Proposed Standard
 Nov 2015 - Adopt TURN PMTUD draft
 Nov 2015 - Adopt TURN IP address mobility draft
 Jan 2016 - Send STUN-bis draft to IESG for publication as Proposed Standard
 Jan 2016 - Send TURN-bis draft to IESG for publication as Proposed Standard
 Mar 2016 - Send new authentication mechanism(s) to IESG for publication as Proposed Standard
 Mar 2016 - Submit TURN PMTUD draft to IESG
 Jul 2016 - Submit TURN IP address mobility draft to IESG

Internet-Drafts:
 - Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages [draft-ietf-tram-alpn-08] (5 pages)
 - Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) [draft-ietf-tram-auth-problems-05] (8 pages)
 - Measurement of Round Trip Time and Fractional Loss Using STUN [draft-ietf-tram-measurement-rtt-loss-00] (9 pages)
 - Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-stun-dtls-05] (16 pages)
 - An Origin Attribute for the STUN Protocol [draft-ietf-tram-stun-origin-06] (13 pages)
 - Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-stun-path-data-05] (10 pages)
 - Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-stun-pmtud-06] (17 pages)
 - Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-stunbis-15] (67 pages)
 - Mobility with Traversal Using Relays around NAT (TURN) [draft-ietf-tram-turn-mobility-09] (13 pages)
 - Traversal Using Relays around NAT (TURN) Server Auto Discovery [draft-ietf-tram-turn-server-discovery-12] (16 pages)
 - Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization [draft-ietf-tram-turn-third-party-authz-16] (24 pages)
 - Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) [draft-ietf-tram-turnbis-12] (83 pages)

Requests for Comments:
 RFC7350: Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) (16 pages)
          * Updates RFC5389
          * Updates RFC5928
 RFC7376: Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) (8 pages)
 RFC7443: Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages (5 pages)
 RFC7635: Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization (24 pages)
 RFC7982: Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN) (10 pages)
 RFC8016: Mobility with Traversal Using Relays around NAT (TURN) (13 pages)
 RFC8155: Traversal Using Relays around NAT (TURN) Server Auto Discovery (16 pages)
          * Updates RFC5766