20/api/v1/group/group/?limit=20&offset=2001603tsvareaNo description available1679https://mailarchive.ietf.org/arch/browse/tsv-area/TrueTransport Area Open Meeting/api/v1/group/group/1324//api/v1/group/group/1679//api/v1/name/groupstatename/conclude//api/v1/name/grouptypename/ag/[]FalsetmforumNo description available2420liaisons@tmforum.orgFalseTMForum/api/v1/group/group/2420//api/v1/name/groupstatename/active//api/v1/name/grouptypename/sdo/[]TruemoderatorsThe IETF Chair appoints Moderators for the IETF Discussion list that are empowered to restrict posting by a person, or to an email thread, when the content is inappropriate and represents a pattern of abuse. Moderation of the IETF discussion list, including the handling of any appeals, is guided by BCP 45 (RFC 9245). Inappropriate postings to the IETF discussion list include: * Advertising and other unsolicited bulk e-mail * Discussion of subjects unrelated to IETF policy, meetings, activities, or technical topics * Uncivil commentary, regardless of the general subject * Announcements of conferences, events, or activities that are not sponsored or endorsed by the IETF, IRTF, IAB, or the Internet Society2345moderators@ietf.orgFalseIETF discussion list moderators/api/v1/group/group/1008//api/v1/group/group/2345//api/v1/name/groupstatename/active//api/v1/name/grouptypename/team/[]Truespring/api/v1/doc/document/charter-ietf-spring/The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as a forum to discuss SPRING networks operations, define new applications of, and specify extensions of Segment Routing technologies.1905https://mailarchive.ietf.org/arch/browse/spring/spring@ietf.orghttps://www.ietf.org/mailman/listinfo/springFalseSource Packet Routing in Networking/api/v1/group/group/1249//api/v1/group/group/1905//api/v1/name/groupstatename/active//api/v1/name/grouptypename/wg/[]TruegopherNo description available1010FalseGOPHER/api/v1/group/group/1346//api/v1/group/group/1010//api/v1/name/groupstatename/bof-conc//api/v1/name/grouptypename/wg/[]Truel3vpn/api/v1/doc/document/charter-ietf-l3vpn/ This working group is responsible for defining, specifying and extending BGP/MPLS IP VPNs solutions (based on RFC4364 and RFC4659) for supporting provider-provisioned Layer-3 (routed) Virtual Private Networks (L3VPNs).1594https://mailarchive.ietf.org/arch/browse/l3vpnl3vpn@ietf.orghttps://www.ietf.org/mailman/listinfo/l3vpnFalseLayer 3 Virtual Private Networks/api/v1/group/group/1249//api/v1/group/group/1594//api/v1/name/groupstatename/conclude//api/v1/name/grouptypename/wg/[]Truemsp1st meeting at Los Angeles IETF, 35th IETF, March 1996No description available1122FalseMessage Security Protocol/api/v1/group/group/1122//api/v1/name/groupstatename/bof-conc//api/v1/name/grouptypename/wg/[]TruesconeproNo description available2416https://mailarchive.ietf.org/arch/browse/sadcdn/sadcdn@ietf.orghttps://www.ietf.org/mailman/listinfo/sadcdnFalseSecure Communication of Network Properties/api/v1/group/group/2412//api/v1/group/group/2416//api/v1/name/groupstatename/bof-conc//api/v1/name/grouptypename/wg/[]TruenasrNo description available2423https://mailarchive.ietf.org/arch/browse/nasrnasr@ietf.orghttps://mailman3.ietf.org/mailman3/lists/nasr.ietf.org/FalseNetwork Attestation for Secured foRwarding/api/v1/group/group/1260//api/v1/group/group/2423//api/v1/name/groupstatename/bof-conc//api/v1/name/grouptypename/wg/[]TruealldispatchNo description available2417https://mailarchive.ietf.org/arch/browse/alldispatch/alldispatch@ietf.orghttps://www.ietf.org/mailman/listinfo/alldispatchFalseIETF-Wide "Dispatch" Session/api/v1/group/group/1008//api/v1/group/group/2417//api/v1/name/groupstatename/bof-conc//api/v1/name/grouptypename/wg/[]Truemanet/api/v1/doc/document/charter-ietf-manet/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. 1132https://mailarchive.ietf.org/arch/browse/manet/manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manetFalseMobile Ad-hoc Networks/api/v1/group/group/1249//api/v1/group/group/1132//api/v1/name/groupstatename/active//api/v1/name/grouptypename/wg/[]Truesrv6ops/api/v1/doc/document/charter-ietf-srv6ops/# Charter for SRv6 Operations (SRv6OPS) The Segment Routing (SR) instantiation on the IPv6 data plane is known as SRv6.2415https://mailarchive.ietf.org/arch/browse/srv6ops/srv6ops@ietf.orghttps://mailman3.ietf.org/mailman3/lists/srv6ops.ietf.org/FalseSRv6 Operations/api/v1/group/group/1193//api/v1/group/group/2415//api/v1/name/groupstatename/active//api/v1/name/grouptypename/wg/[]Truemip6/api/v1/doc/document/charter-ietf-mip6/1st meeting at the 57th IETF in Vienna, Austria Mobile IPv6 (MIP6) specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. The base specifications for Mobile IPv6 consist of:1597https://mailarchive.ietf.org/arch/browse/mip6mip6@ietf.orghttps://www.ietf.org/mailman/listinfo/mip6FalseMobility for IPv6/api/v1/group/group/1052//api/v1/group/group/1597//api/v1/name/groupstatename/conclude//api/v1/name/grouptypename/wg/[]Truemipshop/api/v1/doc/document/charter-ietf-mipshop/1st meeting at the 57th IETF in Vienna, Austria Mobile IPv6 enables IPv6 mobile nodes to continue a session using a given "home address" in spite of changes in its point of attachment to the network. These changes may cause delay, packet loss, and also represent signaling overhead traffic on the network. The MIPSHOP WG has so far worked on two technologies to address these issues. Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency of signaling between a MN, its Home Agent and one or more correspondent nodes. Mobile IPv6 Fast Handovers (FMIPv6) reduces packet loss by providing fast IP connectivity as soon as the mobile node establishes a new point of attachment at a new link.1598https://mailarchive.ietf.org/arch/browse/mipshopmipshop@ietf.orgmipshop-request@ietf.orgFalseMobility for IP: Performance, Signaling and Handoff Optimization/api/v1/group/group/1052//api/v1/group/group/1598//api/v1/name/groupstatename/conclude//api/v1/name/grouptypename/wg/[]Truetictoc/api/v1/doc/document/charter-ietf-tictoc/1st meeting 68th IETF - Prague, Czech Republic 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:1709https://mailarchive.ietf.org/arch/browse/tictoc/tictoc@ietf.orghttps://www.ietf.org/mailman/listinfo/tictocFalseTiming over IP Connection and Transfer of Clock/api/v1/group/group/1052//api/v1/group/group/1709//api/v1/name/groupstatename/conclude//api/v1/name/grouptypename/wg/[]TruehpwanNo description available2435https://mailarchive.ietf.org/arch/browse/hp-wanhp-wan@ietf.orghttps://mailman3.ietf.org/mailman3/lists/hp-wan.ietf.org/FalseHigh Performance Wide Area Network/api/v1/group/group/2412//api/v1/group/group/2435//api/v1/name/groupstatename/bof-conc//api/v1/name/grouptypename/wg/[]Truemailmaint/api/v1/doc/document/charter-ietf-mailmaint/Internet Messaging (“email”) is one of the oldest applications still supported by the IETF. It consists of numerous layers and extensions that support the robust construction, transport, retrieval, and interpretation of messages.2418https://mailarchive.ietf.org/arch/browse/mailmaint/mailmaint@ietf.orghttps://www.ietf.org/mailman/listinfo/mailmaintFalseMail Maintenance/api/v1/group/group/2010//api/v1/group/group/2418//api/v1/name/groupstatename/active//api/v1/name/grouptypename/wg/[]Truescone/api/v1/doc/document/charter-ietf-scone/## Background2433https://mailarchive.ietf.org/arch/browse/sconescone@ietf.orghttps://mailman3.ietf.org/mailman3/lists/scone.ietf.org/FalseStandard Communication with Network Elements/api/v1/group/group/2412//api/v1/group/group/2433//api/v1/name/groupstatename/active//api/v1/name/grouptypename/wg/[]Trueianabis/api/v1/doc/document/charter-ietf-ianabis/RFC 8126/BCP 26, "Guidelines for Writing an IANA Considerations Section in RFCs", defines a framework to ensure that the IANA Considerations section in a document is clear and addresses the various issues that are likely in the operation of a registry.2437https://mailarchive.ietf.org/arch/browse/ianabis/ianabis@ietf.orghttps://mailman3.ietf.org/mailman3/lists/ianabis.ietf.org/FalseUpdate to IANA Considerations/api/v1/group/group/1008//api/v1/group/group/2437//api/v1/name/groupstatename/active//api/v1/name/grouptypename/wg/[]TruesystersIETF Systers is a community of women and non-binary IETF participants who gather to network, share advice and experiences, and collaborate on various projects. We welcome women† and non-binary participants of all ages and at any stage of their studies or careers, and we encourage our members to utilize the Systers group as an informal mentoring and information gathering network. We are here to support and encourage each other. The purpose of the present charter is to outline priorities and lines of action for the Systers group for the period ranging from IETF 119 to IETF 124. The proposal is to revisit the charter after two years (6 events) of implementation. Diversity at IETF has emerged as a central area of concern among the IETF community. For example, during the plenary session in IETF 117, multiple community members voiced their concerns before IETF leadership and the IETF secretariat about what actions to adopt to enhance diversity at IETF, including the participation of women and non binary participants. Systers is a natural space within IETF that can support broader efforts to facilitate the participation and improve the experience at IETF of women and non-binary participants. This text seeks to outline the scope of those efforts. 1. Systers proposes to engage directly with current IETF participants. This means women and non-binary individuals who have signed up to attend IETF either in person or remotely. 2. Systers will make it a top priority to contribute to retention of women who join IETF. This will be done by: * **Newcomer Support.** Identifying concrete mechanisms for Systers members to engage in IETF’s existing Guides program with the goal of engaging more actively as a group in the mentoring of new women and non-binary participants. * **Guidance on becoming an active IETF-er.** Supporting women and non-binary participants aiming to contribute to the IETF. This could include informal mentoring by Systers participants, putting participants in touch with WG Chairs and experienced participants to support them in developing contributions and workshops on how to write an Internet Draft or give an IETF presentation. * **Promoting the engagement of women and non-binary participants in leadership roles.** Actively promoting available leadership roles within the Systers group and endeavouring to support those who wish to explore such roles e.g., through mentorship or sharing advice. * **Networking.** Facilitating networking among women and non-binary participants through the organisation of two in-person sessions at each IETF meeting. Systers will innovate with different formats and activities to facilitate that networking, for example, speed networking and other forms of structured/facilitated networking. For remote participants the Systers mailing list provides a space for sharing information and making connections. 3. For women and non binary participants who have been at IETF for longer, Systers offers a space to network with incoming talent and actively support diversity efforts within IETF. While this charter lays out the initiatives that Systers will prioritise, it does not preclude the engagement of Systers members in other IETF diversity and inclusion initiatives, for example outreach or advocacy for women and non-binary people in the IETF as a whole. Systers encourages use of the meetings and mailing list to advertise and find support for such efforts. †By women we mean anyone self identifying as women, whether cis or trans. Systers are on Slack! If you are a woman or non-binary IETF participant and you'd like to join us please sign up to the IETF slack instance(https://join.slack.com/t/ietf/shared_invite/zt-31wsmp7rn-dtXQNZZIABiO7nohi9j~Ng) and then message the systers chairs who can add you to our channel.2320systers@ietf.orghttps://www.ietf.org/mailman/listinfo/systersFalseSysters/api/v1/group/group/1008//api/v1/group/group/2320//api/v1/name/groupstatename/active//api/v1/name/grouptypename/team/[]True