Protocol Action: 'One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG' to Proposed Standard (draft-ietf-ippm-otwamp-on-lag-08.txt)
The IESG has approved the following document: - 'One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG' (draft-ietf-ippm-otwamp-on-lag-08.txt) as Proposed Standard This document is the product of the IP Performance Measurement Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-otwamp-on-lag/ Technical Summary This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. Working Group Summary The one point of controversy was around the applicability or rather the wording of this draft. Micro-sessions could be useful in more cases than measuring LAG groups and to be able to measure LAG groups you need a very specific deployment. There were suggestions to remove all mentions of LAG from the document and generalize the concept. Document Quality The protocol defined in the document has been implemented by Huawei, ZTE and New H3C. China Mobile has wide field deployment. Personnel The Document Shepherd for this document is Marcus Ihlar. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Locator/ID Separation Protocol (lisp)
The Locator/ID Separation Protocol (lisp) WG in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-21. Locator/ID Separation Protocol (lisp) --- Current status: Active WG Chairs: Padma Pillay-Esnault Luigi Iannone Secretaries: Alberto Rodriguez-Natal Assigned Area Director: Jim Guichard Routing Area Directors: John Scudder Jim Guichard Andrew Alston Mailing list: Address: l...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: https://mailarchive.ietf.org/arch/browse/lisp/ Group page: https://datatracker.ietf.org/group/lisp/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lisp/ LISP supports an overlay routing architecture that decouples the routing locators and endpoint identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the endpoint space. LISP requires no changes to endpoints or routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol, so new features and services can be added easily and quickly to the network using overlays. The LISP WG is chartered to continue work on the LISP protocol, including minor extensions for which the working group has consensus on deeming them necessary for the use cases identified by the working as main LISP applications. Such use cases have to be documented in an applicability document providing rationale for the work done. The working group will work on the following items: - Moving to Standard Track: The core specifications of LISP have been published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue the work of moving select specifications to “Standard Track” (e.g., LISP Canonical Address Format [RFC8060], LISP Multicast [RFC6831][RFC8378], etc). - Map Server Reliable Transport: LISP control plane messages are transported over UDP, however, in some cases, the use of a reliable transport protocol is a better fit, since it actually helps reduce periodic signaling. - YANG Models: The management of LISP protocol and deployments include data models, OAM, as well as allowing for programmable management interfaces. - LISP for Traffic Engineering: Specifics on how to do traffic engineering on LISP deployments could be useful. For instance, encode in a mapping not only the routing locators associated to EIDs, but also an ordered set of re-encapsulating tunnel routers (RTRs) used to specify a path. - NAT-Traversal: Support for a NAT-traversal solution in deployments where LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node). - Privacy and Security: The WG will work on EID anonymity, VPN segmentation leveraging on the Instance ID, and traffic anonymization. The reuse of existing mechanisms will be prioritized. - LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be used to connect LISP sites with non-LISP sites. However, LISP deployments could benefit from more advanced internet-working, for instance by defining mechanisms to discover such external connectivity. - Mobility: Some LISP deployment scenarios include endpoints that move across different LISP xTRs and/or LISP xTRs that are themselves mobile. Support needs to be provided to achieve seamless connectivity. - LISP Applicability: LISP has proved to be a very flexible protocol that can be used in various use cases not considered during its design phase. [RFC7215], while remaining a good source of information, covers one single use case, which is no longer the main LISP application scenario. The LISP WG will document LISP deployments for the most recent and relevant use cases, so as to update and complement [RFC7215] as needed. Milestones: Nov 2023 - Submit LISP Name Encoding document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Reliable Transport document to the IESG for consideration (Map Server Reliable Transport) [STANDARDS TRACK] Mar 2024 - Submit LISP YANG model document to the IESG for consideration (YANG Models) [EXPERIMENTAL] Mar 2024 - Submit LISP Traffic Engineering document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Geo-Coordinates document to the IESG for consideration (Mobility) [EXPERIMENTAL] Nov 2024 - Submit LISP NAT Traversal document to the IESG for consideration (NAT Traversal) [STANDARDS TRACK] Nov 2024 - Submit LISP DDT bis document to the IESG for consideration [STANDARDS TRACK] Nov 2024 - Submit LISP LCAF bis document to the IESG for consideration [STANDARDS TRACK] Mar 2025 - Submit LISP Privacy and Security document(s) to the IESG
Last Call: (DTN Management Architecture) to Informational RFC
The IESG has received a request from the Delay/Disruption Tolerant Networking WG (dtn) to consider the following document: - 'DTN Management Architecture' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. The unique characteristics of this environment require a unique approach to network management that supports asynchronous transport, autonomous local control, and a small footprint (in both resources and dependencies) so as to deploy on constrained devices. This document describes a DTN management architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP). Operating over BP requires an architecture that neither presumes synchronized transport behavior nor relies on query-response mechanisms. Implementations compliant with this DTNMA should expect to successfully operate in extremely challenging conditions, such as over uni-directional links and other places where BP is the preferred transport. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dtn-dtnma/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'CDNI delegation using Automated Certificate Management Environment' to Proposed Standard (draft-ietf-cdni-delegation-acme-04.txt)
The IESG has approved the following document: - 'CDNI delegation using Automated Certificate Management Environment' (draft-ietf-cdni-delegation-acme-04.txt) as Proposed Standard This document is the product of the Content Delivery Networks Interconnection Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-delegation-acme/ Technical Summary This document defines metadata to support delegating the delivery of HTTPS content between two or more interconnected CDNs. Specifically, this document defines a CDNI Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC9115. RFC9115 allows delegating entities to remain in full control of the delegation and be able to revoke it any time and this avoids the need to share private cryptographic key material between the involved entities. Working Group Summary There were no major controversies or discontent. Discussions were primarily around scope, specifically, minimizing the contents of the draft to only what is needed for CDNI to support delegation and avoiding any implementation of security protocols. CDNI supports configuration and capability negotiation between CDNs; it does not implement security protocols. Document Quality The draft specifically provides for configuring ACME across CDNs and so relates to the work of the ACME WG. The draft was reviewed by Thomas Fossati, one of the co-authors of RFC8739 and RFC9115, prior to WGLC and all his comments were addressed. Personnel The Document Shepherd for this document is Kevin J. Ma. The Responsible Area Director is Francesca Palombini. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
The Tools Team (tools) TEAM Virtual Meeting: 2024-02-13
The The Tools Team (tools) Team will hold a virtual interim meeting on 2024-02-13 from 13:00 to 14:00 America/Chicago (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=25d8575d-cc7a-4719-b1a5-b7ba1569d581 -- A calendar subscription for all tools meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=tools ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
The Tools Team (tools) TEAM Virtual Meeting: 2024-01-09
The The Tools Team (tools) Team will hold a virtual interim meeting on 2024-01-09 from 13:00 to 14:00 America/Chicago (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3b360796-363f-4c35-9f11-37f61e7afed6 -- A calendar subscription for all tools meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=tools ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Call for nominations: IESG appointment to the IETF Trust
The purpose of the IETF Trust is to acquire, hold, maintain, and license certain existing and future intellectual property and other property used in connection with the administration of the IETF. More information about the IETF Trust can be found at https://trustee.ietf.org/. According to RFC 8714, the IESG is required to appoint one person to the IETF Trust, for a term of two years. The IESG is hence asking for volunteers to serve as the IESG appointee to the IETF Trust for the term beginning in March 2024 and ending in March 2026. DESIRABLE QUALIFICATIONS AND SELECTION CRITERIA The Trust is mostly a quiet organization, and being a trustee generally involves little work beyond monthly online meetings. Trustees ideally should be: • Familiar with copyright and trademark law. • Familiar with the RFC publication process as described in RFC 9280 and related documents. • Familiar with the Trust's copyright licenses and with RFCs 8721 and 5378. • Willing to serve multiple terms as a trustee to provide continuity of oversight. NOMINATIONS AND ELIGIBILITY The IESG is making a public call for nominations. Self-nominations are permitted. All IETF participants, including working group chairs, IETF NomCom members, IAB members, IESG members, and candidates for the IETF LLC Board are eligible for nomination. Of course, IESG members who accept nomination will recuse themselves from selection discussions. Persons who are under consideration by the NomCom in the 2023-2024 cycle for the open IETF Trust position are also welcome to apply. Please send nominations to i...@ietf.org. Please include the following with each nomination: • Name • Contact information • Candidate background and qualifications SELECTION The IESG will publish the list of nominated persons prior to making a decision, allowing time for the community to provide any relevant comments to the IESG. The IESG will review the nomination material, any comments provided by the community, and may decide to interview the candidates before making a selection. CARE OF PERSONAL INFORMATION The following procedures will be used in managing candidates' personal information: The list of candidate names will be published at the close of the nominations period. A candidate that refuses the nomination will not be included on the list. Except as noted above, all information provided to the IESG during this process will be kept as confidential to the IESG. TIMEFRAME The nominations period will opens today, Friday, 2023-12-08, and closes on Friday, 2024-01-19 at 23:59 UTC. The list of candidates will be posted shortly after the close of nominations, and the community will then have four weeks to provide comments on the candidates to the IESG. The IESG will consider the community feedback and make its decision. If the candidate pool overlaps with the NomCom's IETF Trust candidate pool, the IESG will wait to announce a selection until the NomCom announces its selections for the IETF Trust, to avoid a race condition. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Area Proxy for IS-IS) to Experimental RFC
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Area Proxy for IS-IS' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4016/ https://datatracker.ietf.org/ipr/3357/ https://datatracker.ietf.org/ipr/3221/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP) to Informational RFC
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for DetNet MPLS Data Plane and the mechanisms defined by MPLS-over-UDP technology. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-ip-preof/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Formal IESG Teleconference Webex and Dial-in Information: 14 December 2023
All members of the community are welcome to attend formal IESG telechats as observers. Observers are not invited to participate in the discussion. The next formal IESG telechat will be held on Thursday, December 14, 2023 at 07:00 US/Canada Pacific (15:00 UTC). The meeting is scheduled for two hours (07:00-09:00 US/Canada Pacific). Webex and Dial-in information is at the bottom of this message. The agenda for the upcoming telechat can be found at <https://datatracker.ietf.org/iesg/agenda/> A calendar of upcoming public telechats can be downloaded or subscribed to at: https://calendar.google.com/calendar/ical/ietf.org_egdabaf39ch5v8a13dt39mvee4%40group.calendar.google.com/public/basic.ics Topic: IESG Formal Telechat Date: December 14, 2023 Time: 07:00 US/Canada Pacific 09:00 US/Canada Central 10:00 US/Canada Eastern 15:00 UTC 15:00 United Kingdom 16:00 Germany, France, Belgium, Sweden 17:00 Finland 18:00 Kenya 20:30 India --- JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m3cc48bcbd48465d4da48d0197a6e7bb2 Meeting number: 2427 431 7054 Meeting password: 12345 JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 2427 431 7054 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' to Best Current Practice (draft-ietf-tsvwg-ecn-encap-guidelines-22.txt)
The IESG has approved the following document: - 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' (draft-ietf-tsvwg-ecn-encap-guidelines-22.txt) as Best Current Practice This document is the product of the Transport and Services Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Technical Summary The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking among IP layer and lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. This document is included in BCP 89 and updates the advice to subnetwork designers about ECN in RFC 3819. Working Group Summary Sebastian Moeller repeatedly questioned on the mailing list the use of recommendations that were based on an earlier BCP, i.e. RFC 7141, saying that some of the earlier concepts recommended in RFC 7141 were yet to be implemented. The chairs and editors are content that the current revision has considered this feedback and looked into these topics, and that citing RFC 7141 is consistent with good practice. Document Quality This is a BCP that is not directly implementable, but 4 RFCs and 3 I-Ds reference it. Personnel The Document Shepherd for this document is Gorry Fairhurst. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' to Proposed Standard (draft-ietf-tsvwg-rfc6040update-shim-23.txt)
The IESG has approved the following document: - 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' (draft-ietf-tsvwg-rfc6040update-shim-23.txt) as Proposed Standard This document is the product of the Transport and Services Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ Technical Summary RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim header(s) and updates the specifications of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. Working Group Summary The WG reached consensus following a WGLC that concluded on 25th April 2021, and rev 14 was thought to resolve the WG comments. This document has a dependency on ietf-tsvwg-ecn-encap-guidelines, and that document has stalled publication of this draft. Since rev-14, the author has continued to correct text and respond to Shepherd comments. Document Quality There are a wide variety of tunnel specifications and implementations, some of these are thought to follow the design described in this document. Personnel The Document Shepherd for this document is Gorry Fairhurst. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Constrained RESTful Environments (core) WG Interim Meeting Cancelled (was 2023-12-06)
The Constrained RESTful Environments (core) virtual interim meeting for 2023-12-06 from 16:00 to 17:30 Europe/Stockholm has been cancelled. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Javascript Object Signing and Encryption (jose)
The Javascript Object Signing and Encryption (jose) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-12. Javascript Object Signing and Encryption (jose) --- Current status: Active WG Chairs: John Bradley John Preuß Mattsson Karen O'Donoghue Assigned Area Director: Roman Danyliw Security Area Directors: Roman Danyliw Paul Wouters Mailing list: Address: j...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jose Archive: https://mailarchive.ietf.org/arch/browse/jose/ Group page: https://datatracker.ietf.org/group/jose/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jose/ The original [JSON Object Signing and Encryption (JOSE) working group][1] standardized JSON-based representations for: Integrity-protected objects (JSON Web Signatures/JWS, RFC 7515), Encrypted objects (JSON Web Encryption/JWE, RFC7516), Key representations (JSON Web Key/JWK, RFC 7517), Algorithm definitions (JSON Web Algorithms/JWA, RFC 7518), and Test vectors for the above (Examples of Protecting Content Using JSON Object Signing and Encryption, RFC 7520). These were used to define the JSON Web Token (JWT) (RFC 7519), which in turn, has seen widespread deployment in areas as diverse as [digital identity][2] and [secure telephony][3]. As adoption of these standards to express and communicate sensitive data has grown, so too has an increasing societal focus on privacy. User consent, minimal disclosure, and unlinkability are common privacy themes in identity solutions. A multi-decade research activity for a sizeable academic and applied cryptography community has focused on these privacy and knowledge mechanisms (often referred to as anonymous credentials). Certain cryptographic techniques developed in this space involve pairing-friendly curves and zero-knowledge proofs (ZKPs) (to name just a few). Some of the benefits of ZKP algorithms include unlinkability, selective disclosure, and the ability to use predicate proofs. The current container formats defined by JOSE and JWT are not able to represent data using ZKP algorithms. Among the reasons are that most require an additional transform or finalize step, many are designed to operate on sets and not single messages, and the interface to ZKP algorithms has more inputs than conventional signing algorithms. The reconstituted JOSE working group will address these new needs, while reusing aspects of JOSE and JWT, where applicable. This group is chartered to work on the following goals: - An Informational document detailing Use Cases and Requirements for new specifications enabling JSON-based selective disclosure and zero-knowledge proofs. - Standards Track document(s) specifying representation(s) of independently-disclosable integrity-protected sets of data and/or proofs using JSON-based data structures, which also aims to prevent the ability to correlate by different verifiers. - Standards Track document(s) specifying representation(s) of JSON-based claims and/or proofs enabling selective disclosure of these claims and/or proofs, and that also aims to prevent the ability to correlate by different verifiers. - Standards Track document(s) specifying how to use existing cryptographic algorithms and defining their algorithm identifiers. The working group will not invent new cryptographic algorithms. - Standards Track document(s) specifying how to represent keys for these new algorithms as JSON Web Keys (JWKs). - Informational document(s) defining test vectors for these new specifications. - Standards Track document(s) defining CBOR-based representations corresponding to all the above, building upon the COSE and CWT specifications in the same way that the above build on JOSE and JWT. One or more of these goals may be combined into a single document, in which case the concrete milestones for these goals will be satisfied by the consolidated document(s). The JOSE working group will also maintain the JOSE standard and facilitate discussion of clarifications, improvements, and extensions to JWS, JWE, JWA, and JWK. The WG will evaluate, and potentially adopt, proposed standard documents dealing with algorithms that would fit the criteria of being IETF consensus algorithms. Potential candidates would include those algorithms that have been evaluated by the CFRG and algorithms which have gone through a public review and evaluation process such as was done for the NIST SHA-3 algorithms. Potential candidates would not include national-standards-based algorithms that have not gone through a similar public review process. The WG may also publish informational and BCP documents describing the proper use of these algorithms in JOSE. An informal goal
Results of IETF-conflict review for draft-irtf-qirg-quantum-internet-use-cases-19
The IESG has completed a review of draft-irtf-qirg-quantum-internet-use-cases-19 consistent with RFC5742. The IESG has no problem with the publication of 'Application Scenarios for the Quantum Internet' as an Informational RFC. The IESG has concluded that this work is related to IETF work done in the PQUIP WG, but this relationship does not prevent publishing. The IESG would also like the IRTF to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-irtf-qirg-quantum-internet-use-cases/ A URL of the reviewed Internet-Draft is: https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/ The process for such documents is described in RFC 5743 Thank you, The IESG Secretary ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Results of IETF-conflict review for draft-irtf-cfrg-frost-15
The IESG has completed a review of draft-irtf-cfrg-frost-15 consistent with RFC5742. The IESG has no problem with the publication of 'Two-Round Threshold Schnorr Signatures with FROST' as an Informational RFC. The IESG has concluded that there is no conflict between this document and IETF work. The IESG would also like the IRTF to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-frost/ A URL of the reviewed Internet-Draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/ The process for such documents is described in RFC 5743 Thank you, The IESG Secretary ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Results of IETF-conflict review for draft-pkcs12-gost-06
The IESG has completed a review of draft-pkcs12-gost-06 consistent with RFC5742. The IESG has no problem with the publication of 'Generating the Transport Key Containers Using the GOST Algorithms' as an Informational RFC. The IESG has concluded that there is no conflict between this document and IETF work. The IESG would also like the Independent Submissions Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-pkcs12-gost/ A URL of the reviewed Internet-Draft is: https://datatracker.ietf.org/doc/draft-pkcs12-gost/ The process for such documents is described at https://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Updates for PCEPS: TLS Connection Establishment Restrictions) to Proposed Standard
The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Updates for PCEPS: TLS Connection Establishment Restrictions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for PCEP (Path Computation Element Communication Protocol). This document adds restrictions to specify what PCEPS implementations do if a PCEPS supports more than one version of the TLS protocol and to restrict the use of TLS 1.3’s early data. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-tls-rfc8446bis: The Transport Layer Security (TLS) Protocol Version 1.3 (None - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane) to Proposed Standard
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines format and usage principles of the Deterministic Network (DetNet) service Associated Channel (ACH) over a DetNet network with the MPLS data plane. The DetNet service ACH can be used to carry test packets of active Operations, Administration, and Maintenance protocols that are used to detect DetNet failures and measure performance metrics. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7799: Active and Passive Metrics and Methods (with Hybrid Types In-Between) (Informational - Internet Engineering Task Force (IETF)) rfc9055: Deterministic Networking (DetNet) Security Considerations (Informational - Internet Engineering Task Force (IETF)) rfc9037: Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN) (Informational - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)) to Informational RFC
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operation, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective, such as packet delay, delay variation, and packet loss ratio, assigned to each DetNet flow. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-oam-framework/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Deterministic Networking (DetNet) YANG Model) to Proposed Standard
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Deterministic Networking (DetNet) YANG Model' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document contains the specification for the Deterministic Networking YANG Model for configuration and operational data of DetNet Flows. The model allows for provisioning of end-to-end DetNet service on devices along the path without dependency on any signaling protocol. It also specifies operational status for flows. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-yang/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8938: Deterministic Networking (DetNet) Data Plane Framework (Informational - Internet Engineering Task Force (IETF)) rfc9016: Flow and Service Information Model for Deterministic Networking (DetNet) (Informational - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Open Specification for Pretty Good Privacy (openpgp)
The Open Specification for Pretty Good Privacy (openpgp) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-14. Open Specification for Pretty Good Privacy (openpgp) --- Current status: Active WG Chairs: Stephen Farrell Daniel Gillmor Assigned Area Director: Roman Danyliw Security Area Directors: Roman Danyliw Paul Wouters Mailing list: Address: open...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/openpgp Archive: https://mailarchive.ietf.org/arch/browse/openpgp/ Group page: https://datatracker.ietf.org/group/openpgp/ Charter: https://datatracker.ietf.org/doc/charter-ietf-openpgp/ OpenPGP standardized mechanisms for object encryption, object signing, and identity certification. The working group is chartered to work on improvements and additions to the OpenPGP format and ecosystem to address certain issues that have been identified by the community, as set out in the list of "in scope" topics below. Due to the WG having been dormant for a number of years, there is somewhat of a "backlog" of topics, and as addressing all of these topics at once seems difficult, the WG will follow the process defined below to prioritize current lists of milestones, selected from this long list of "in-scope" topics. # In-scope Topics The working group will produce a number of specifications that are adjacent to the OpenPGP specification and provide guidance to OpenPGP libraries and/or applications. These improvements may include: ## Security improvements - **Post-Quantum Cryptography (PQC)**: The addition and facilitation of post-quantum algorithms for encryption and signing (using [draft-wussler-openpgp-pqc](https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/) as initial input). - **Forward secrecy**: enable encrypted OpenPGP communication that cannot be decrypted when long-term keys are compromised. - **Context binding**: facilitate [domain separation for signing and/or encryption](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145). ## New functionality - **Automatic Forwarding**: using proxy re-encryption (using [draft-wussler-openpgp-forwarding](https://datatracker.ietf.org/doc/draft-wussler-openpgp-forwarding/) as initial input). - **Persistent Symmetric Keys**: for long-term storage of symmetric key material, symmetrically encrypted messages, and symmetric attestations (using [draft-huigens-openpgp-persistent-symmetric-keys](https://datatracker.ietf.org/doc/draft-huigens-openpgp-persistent-symmetric-keys/) as initial input). - **First-Party Approval of Third-Party Certifications (1PA3PC)**: to mitigate certificate flooding attacks (using [draft-dkg-openpgp-1pa3pc](https://datatracker.ietf.org/doc/draft-dkg-openpgp-1pa3pc) as initial input). - **Superseded Keys**: to facilitate [transition to new keys without revoking the old ones](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/222). - **Stateless OpenPGP Interface (SOP)**: using [draft-dkg-openpgp-stateless-cli](https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/) as initial input. - **PGP/MIME Separate Encrypted Parts**: Extending [RFC 3156](https://datatracker.ietf.org/doc/rfc3156/) to describe [messages composed of multiple encrypted parts](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/171). - **cert-d**: A common certificate storage mechanism (using [draft-nwjw-openpgp-cert-d/](https://datatracker.ietf.org/doc/draft-nwjw-openpgp-cert-d) as initial input). ## Network-based Key Discovery Mechanisms - **HTTP Keyserver Protocol (HKP)**: using [draft-gallagher-openpgp-hkp](https://datatracker.ietf.org/doc/draft-gallagher-openpgp-hkp/) as initial input. - **Web Key Directory (WKD)**: using [draft-koch-openpgp-webkey-service](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) as initial input. ## Key Verification Mechanisms - **Web-of-Trust (WoT)**: Specifying semantics for the WoT calculus (using [the OpenPGP Web of Trust draft](https://sequoia-pgp.gitlab.io/sequoia-wot/) as initial input). - **Key Transparency**: in collaboration with the [Key Transparency Working Group](https://datatracker.ietf.org/wg/keytrans/about/), e.g., integrating its outputs. - **Key Verification**: Improved manual key verification, for example using a QR code. ## Miscellaneous Cleanup Work - **Semantics**: Define semantics of mechanisms provided by OpenPGP. This includes, but is not limited to, defining validity of signatures, acceptance and placement of signature subpackets, as well as structure and meaning of certificates and messages. - **User ID Conventions**: Properly document User ID conventions (using [draft-dkg-ope
WG Review: Network Management Operations (nmop)
A new IETF WG has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-14. Network Management Operations (nmop) --- Current status: Proposed WG Chairs: TBD Assigned Area Director: Robert Wilton Operations and Management Area Directors: Warren Kumari Robert Wilton Mailing list: Address: ne...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/netmo Archive: https://mailarchive.ietf.org/arch/browse/netmo/ Group page: https://datatracker.ietf.org/group/nmop/ Charter: https://datatracker.ietf.org/doc/charter-ietf-nmop/ The increased drive by operators for integration and deployment of network management protocols and YANG data models highlights new issues and problems with the individual protocols and models, or the wider integration of those. Some of these problems are only witnessed when trying to manage large scale networks, e.g., due to the increased complexity and handling large volumes of data exported in frequent updates. At the same time, simplifying the network management and operations, with increased automation, is a high priority. The goals of the Network Management Operations working group are to solicit input from network operators to identify anticipated operational issues arising from the near term deployment of network management technologies, and to determine potential solutions or workarounds for those issues. Those operational issues may relate to deployments of existing network management technologies or the integration of related technologies for network management and telemetry. Solving those operational issues require discussion, investigation, and potentially some experiments, which may take some time, however the working group will focus on pragmatic items achievable in a short timeframe over long term architectural visions. Since the focus is on helping solve problems faced by operators, discussion and experiments are not solely limited to network management technologies standardized within the IETF but cover the wider ecosystem – however the working group will not work on improvements to protocols or data models developed and maintained outside the IETF. The Network Management Operations working group is scoped, in order of highest priority, to: * Present and discuss operational issues faced by deployment of network management technologies. * Incubate ideas and short term experiments on improving network management operations. Any experiments should focus on incremental improvements that can be achieved within 1-2 years. * Discuss network operator use cases and requirements for solving anticipated network management problems. * Liaise, informally, with developers of open-source software to help drive adoption of IETF network management standards and to improve protocol maturity. * Document operational experience and best practice for network management and telemetry deployment as BCPs or Informational RFCs. The WG charter does not currently include any IETF protocol or data model work, but the WG may decide to work on such items in future, subject to the following constraints: * Protocol extensions for protocols in scope for existing working groups must be taken to those working groups unless there is an agreement by the area director responsible for the working group and the Operations/Management area director to progress the enhancement within this working group. * OPSAWG remains the default working group to take small maintenance work for orphan network management specifications produced by concluded working groups unless there is particular operator interest and explicit agreement of the Operations/Management area director to progress the work here. * More significant protocol work (on existing or new protocols) should be taken to an existing or new working group. I.e., protocol work is not the core focus of this working group. * The working group charter and milestones must be updated beforehand to cover any protocol or data model work to be undertaken here. Agenda time is expected to be balanced between presentations and discussions of operator issues and experience, and other potential work within scope for the working group. The working group chairs will agree the topics and agenda time with the responsible area director, with an expectation that priority will be given to operator presentations. If there is consensus for the working group to focus on particular problems or issues, then those topics must be agreed with the responsible area director, and either the charter (potentially with updated milestones) or a working group wiki updated to document the current topics of focus. Like many of the “ops
Supply Chain Integrity, Transparency, and Trust (scitt) WG Virtual Meeting: 2024-02-12
The Supply Chain Integrity, Transparency, and Trust (scitt) WG will hold a virtual interim meeting on 2024-02-12 from 16:00 to 17:00 Europe/London (16:00 to 17:00 UTC). Agenda: Interim catch up on status of work since -118, review issues. Specifics: * Status of architecture doc, recent PRs and open issues * Status of SCRAPI, recent PRs and open issues. * Readiness for submission for -119 (one month away). Do we need another interim in 2 weeks? * Hackathon planning for -119 Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=fc07d7e9-38c3-47ff-a996-1b056fc067ca -- A calendar subscription for all scitt meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=scitt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Supply Chain Integrity, Transparency, and Trust (scitt) WG Virtual Meeting: 2024-01-08
The Supply Chain Integrity, Transparency, and Trust (scitt) WG will hold a virtual interim meeting on 2024-01-08 from 16:00 to 17:00 Europe/London (16:00 to 17:00 UTC). Agenda: Interim catch up on status of work since -118, review issues. Specifics: * Status of architecture doc, recent PRs and open issues * Status of SCRAPI, recent PRs and open issues. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=91e9f846-b051-4095-9d7a-ceb7b83a14d0 -- A calendar subscription for all scitt meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=scitt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Supply Chain Integrity, Transparency, and Trust (scitt) WG Virtual Meeting: 2023-12-11
The Supply Chain Integrity, Transparency, and Trust (scitt) WG will hold a virtual interim meeting on 2023-12-11 from 16:00 to 17:00 Europe/London (16:00 to 17:00 UTC). Agenda: Interim catch up on status of work since -118, review issues. Specifics: * Status of WGLC for use cases document (ends 7th Dec) and follow-up actions * Status of architecture doc, recent PRs and open issues * Status of SCRAPI, recent PRs and open issues. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=51d57ddd-774e-4168-82a9-75ad6fdec243 -- A calendar subscription for all scitt meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=scitt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Formed vCon (vcon)
to address these concerns directly, as that is intended to be handled by metadata in the layers above VCON itself. However, the documents produced by this working group will discuss such considerations, and will not preclude support for conveying important notions such as user consent. Milestones * Specification for a JSON based container for conversation data * Recommendations or analysis of missing (not defined) data containers and media types for components of the conversation data Milestones: Dec 2023 - Adopt a draft to provide a specification for a JSON based container for conversation data (Proposed Standard) Dec 2023 - Adopt a draft containing recommendations or analysis of undefined data containers and media types for components of conversation data (Informational) Jun 2024 - Submit draft to provide a specification for a JSON based container for conversation data to the IESG (Proposed Standard) Jun 2024 - Submit draft containing recommendations or analysis of undefined data containers and media types for components of conversation data to the IESG (Informational) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Precision Availability Metrics for Services Governed by Service Level Objectives (SLOs)' to Informational RFC (draft-ietf-ippm-pam-09.txt)
The IESG has approved the following document: - 'Precision Availability Metrics for Services Governed by Service Level Objectives (SLOs)' (draft-ietf-ippm-pam-09.txt) as Informational RFC This document is the product of the IP Performance Measurement Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-pam/ Technical Summary This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives (SLO). These metrics, referred to as Precision Availability Metrics (PAM), are useful for defining and monitoring SLOs. For example, PAM can be used by providers and/or customers of an IETF Network Slice Service to assess whether the service is provided in compliance with its defined SLOs. Working Group Summary This document got good review across the WG, with positive input from WG members who work in various areas. I believe that this had around the normal amount of engagement for IPPM, and we reached good consensus on the document. Document Quality We believe there is one implementation that uses the concepts in this informational draft, but it is not confirmed. Personnel The Document Shepherd for this document is Tommy Pauly. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered Deterministic Networking (detnet)
The Deterministic Networking (detnet) WG in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Deterministic Networking (detnet) --- Current status: Active WG Chairs: Lou Berger János Farkas Secretaries: Eve Schooler Assigned Area Director: John Scudder Routing Area Directors: John Scudder Jim Guichard Andrew Alston Technical advisors: David Black Mailing list: Address: det...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/detnet Archive: https://mailarchive.ietf.org/arch/browse/detnet/ Group page: https://datatracker.ietf.org/group/detnet/ Charter: https://datatracker.ietf.org/doc/charter-ietf-detnet/ The Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on reordering, latency, loss, and packet delay variation (jitter), and high reliability. DetNet solutions apply to both wireless and wired networks. The Working Group addresses Layer 3 aspects in support of applications requiring deterministic networking. The Working Group collaborates with IEEE802.1 Time-Sensitive Networking (TSN), which is responsible for Layer 2 operations, to define a common architecture for both Layer 2 and Layer 3. Example applications for deterministic networks include professional and home audio/video, multimedia in transportation, engine control systems, and other general industrial and vehicular applications being considered by the IEEE 802.1 TSN Task Group. The Working Group will initially focus on solutions for networks that are under a single administrative control or within a closed group of administrative control; these include not only campus-wide networks but also private WANs. The DetNet WG will not spend energy on solutions for large groups of domains such as the Internet. The Working Group is responsible for the overall DetNet architecture and DetNet-specific specifications that encompass the data plane, OAM (Operations, Administration, and Maintenance), time synchronization, management, control, and security aspects which are required to enable a multi-hop path, and forwarding along the path, with the deterministic properties of controlled latency, low packet loss, low packet delay variation, and high reliability. The work applies to point-to-point (unicast) and point-to-multipoint (multicast) flows which can be characterized in a manner that allows the network to 1) reserve the appropriate resources for the flows in advance, and 2) release/reuse the resources when they are no longer required. The work covers the characterization of flows, the encapsulation of frames, the required forwarding behaviors, as well as the state that may need to be established in intermediate nodes. Layer 3 data plane technologies that can be used include: IP and MPLS, and Layer 2 encapsulations that run over IP and/or MPLS, such as pseudowires and GRE. The Working Group will document which deployment environments and types of topologies are within (or outside) the scope of the DetNet architecture. This work focuses on the data plane aspects and is independent of any path setup protocol or mechanism. The Working Group will also document DetNet Controller Plane approaches that reuse existing IETF solutions, such as Path Computation Element (PCE), and identify the Working Group responsible for any extensions needed to support DetNet. Documents produced by the Working Group will be compatible with the work done in IEEE802.1 TSN and other IETF Working Groups. The Working Group's scope generally excludes modifications of transport protocols, OAM, Layer 3 forwarding, and encapsulations, but it may discuss requirements for such modifications and the work will be coordinated with the Working Group responsible for the technology. DetNet is chartered to work in the following areas: Overall architecture: This work encompasses the data plane, OAM, time synchronization, management, control, and security aspects. Data plane: This work will specify how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet treatment over Layer 3. Other IETF-defined data plane technologies may also be used. Controller Plane: The DetNet Controller Plane is defined in RFC 8655 as "the aggregation of the Control and Management Planes". This work will document how to use IETF control plane solutions to support DetNet, including the identification of any gaps in existing solutions. Any modification to Controller Plane protocols to address identified gaps should be carried out in their associated Working Groups, but may be done in DetNet if agreed to by the relevant Working Group chairs and responsible Area Directors. Data flow information model: This work will identify the information
WG Review: Transport and Services Working Group (tsvwg)
The Transport and Services Working Group (tsvwg) WG in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-11. Transport and Services Working Group (tsvwg) --- Current status: Active WG Chairs: Gorry Fairhurst Marten Seemann Assigned Area Director: Martin Duke Transport Area Directors: Martin Duke Zaheduzzaman Sarker Mailing list: Address: ts...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tsvwg Archive: https://mailarchive.ietf.org/arch/browse/tsvwg/ Group page: https://datatracker.ietf.org/group/tsvwg/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tsvwg/ The Transport and Services Working Group (TSVWG) is the forum for development and publication of RFCs dealing with transport layer topics that are not in scope of an existing working group or do not justify the formation of a new working group. A non-exhaustive list of transport topics includes mechanisms that deal with packetization and reassembly, ports, maximum transmission unit discovery, reordering, congestion control, loss detection and recovery, queue management, explicit congestion notification, multihoming, stream multiplexing, and quality of service (including DSCP and RSVP). Transport-layer protocols include TCP, QUIC, SCTP, UDP, and DCCP. TSVWG maintains these protocols and mechanisms in the absence of a specialized working group. 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, with the approval of the responsible AD. The currently active TSVWG work items mostly fall under the following topics: (A) Maintenance and extension of the Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Datagram Congestion Control Protocol (DCCP), as these do not have dedicated working groups. (B) Explicit Congestion Notification (ECN), as the working group improves existing directives for tunnelling and observes the recently launched experiment with Low Latency, Low Loss, and Scalable Throughput (L4S). (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. Work 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 AD, who, depending on the scope of the proposed work item, may decide that an IESG review of adoption is needed first. Milestones: Done - Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC Done - Submit 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' as a Proposed Standard RFC Dec 2023 - Submit " Transport Options for UDP" as a Proposed Standard RFC Dec 2023 - Submit "Datagram PLPMTUD for UDP Options" for publication as a Proposed Standard RFC. Dec 2023 - Submit "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services" as a Proposed Standard RFC Dec 2023 - Submit "User Ports for Experiments " for publication as a Proposed Standard RFC. Dec 2023 - Submit " DCCP Extensions for Multipath Operation with Multiple Addresses" as an Proposed Standard RFC Mar 2024 - Submit "DTLS over SCTP" as a Proposed Standard RFC Jul 2024 - Submit "Careful convergence of congestion control from retained state" for publication as a Proposed Standard RFC. Nov 2024 - Submit "Operational Guidance for Deployment of L4S in the Internet" as an Informational RFC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: TCP Maintenance and Minor Extensions (tcpm)
The TCP Maintenance and Minor Extensions (tcpm) WG in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-11. TCP Maintenance and Minor Extensions (tcpm) --- Current status: Active WG Chairs: Yoshifumi Nishida Michael Tüxen Ian Swett Assigned Area Director: Martin Duke Transport Area Directors: Martin Duke Zaheduzzaman Sarker Mailing list: Address: t...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: https://mailarchive.ietf.org/arch/browse/tcpm/ Group page: https://datatracker.ietf.org/group/tcpm/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tcpm/ 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 WG maintains Multipath TCP (MPTCP) and is a home for minor MPTCP enhancements including updates to the existing multipath congestion control. The preferred venue for Congestion control work is generally CCWG or ICCRG. However, TCPM can take on such work in coordination with those groups, especially if it relies on TCP-specific protocol elements. 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. Milestones: Nov 2022 - Submit RFC6937bis document to the IESG for publication as a Proposed Standard RFC Dec 2022 - Submit specification of more accurate ECN feedback in TCP to the IESG for publication as a Proposed Standard RFC Jan 2023 - Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC Dec 2023 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC Oct 2024 - Submit document on adding acknowledgement rate handling for TCP to the IESG for publication as Experimental RFC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: WebRTC Ingest Signaling over HTTPS (wish)
The WebRTC Ingest Signaling over HTTPS (wish) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-11. WebRTC Ingest Signaling over HTTPS (wish) --- Current status: Active WG Chairs: Sean Turner Nils Ohlmeier Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Mailing list: Address: w...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/wish Archive: https://mailarchive.ietf.org/arch/browse/wish/ Group page: https://datatracker.ietf.org/group/wish/ Charter: https://datatracker.ietf.org/doc/charter-ietf-wish/ The WISH working group is chartered to specify a simple, extensible, HTTPS-based set of signaling protocols to establish one-way WebRTC-based audiovisual sessions between broadcasting tools, media players and real-time media broadcast networks. Background: WebRTC defines a set of wire protocols for real-time media transmission, as well as a profile of the Session Description Protocol (SDP) for setting up and controlling the associated media streams. Because of its typical use cases, and to increase overall flexibility, WebRTC did not specify a wire protocol for exchanging SDP messages, leaving the creation of such protocols up to the applications that use WebRTC. This works well when WebRTC clients are vertically integrated with the servers they communicate with, as it allows for rapid iteration of new features. At the same time, the use of WebRTC as a mechanism for large-scale media broadcast is gaining popularity, and unlike more vertically integrated uses of WebRTC, WebRTC-based media distribution networks would benefit immensely from being able to re-use the several broadcasting tools that have been developed over time. To date, these media distribution networks have employed their own proprietary signaling protocols to establish the connection between broadcasting tools and the network, generally requiring either bespoke software or customized modifications to existing tools. With the large number of available tools and the growing number of real-time media distribution networks, this ad-hoc approach to creating custom protocols for establishing sessions clearly does not scale. The real-time broadcasting ecosystem would benefit immensely from a set of common protocols to meet this goal. Deliverables: The product of this working group will be a specification for a simple, extensible, HTTPS-based signaling protocol set to establish one-way WebRTC-based audiovisual sessions between broadcasting tools and real-time media broadcast networks, and between those networks and the media players. This working group will use existing HTTPS, WebRTC, and SDP mechanisms to the extent possible. While no extensions to those core protocols is expected, the working group may consider such extensions if they are necessary to meet the requirements of broadcasting tools and networks. Any such work will be coordinated with the HTTPBIS, MMUSIC, and/or MOPS working groups, as appropriate. Additionally, this working group will coordinate with HTTPBIS and HTTPAPI to assure that the HTTP protocol is being used according to current best practice. While there may be other problems that the proposed mechanism may solve or nearly solve, such as general purpose bidirectional realtime communication (telephony, video conferencing etc), adding explicit protocol support for those use cases is not in scope for the WISH working group. Milestones: Dec 2024 - Submit WebRTC-HTTP egress protocol to IESG for publication ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Path Computation Element (pce)
The Path Computation Element (pce) WG in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-11. Path Computation Element (pce) --- Current status: Active WG Chairs: Julien Meuric Dhruv Dhody Secretaries: Andrew Stone Assigned Area Director: John Scudder Routing Area Directors: John Scudder Jim Guichard Andrew Alston Mailing list: Address: p...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/pce Archive: https://mailarchive.ietf.org/arch/browse/pce/ Group page: https://datatracker.ietf.org/group/pce/ Charter: https://datatracker.ietf.org/doc/charter-ietf-pce/ 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. Further, the PCE WG also handles protocol extensions for new path setup types of Segment Routing (SR), BIER, and Detnet. In this architecture path computation does not necessarily occur on the head-end (ingress) 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 works on the mechanisms for inter-domain as well as multi-layer path computation and PCEP extensions for communication between several domains or network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) and Flexible Grid while keeping consistency with the GMPLS protocols specified in the CCAMP and TEAS WGs. Work Items: - PCEP extensions to support MPLS and GMPLS Traffic Engineered LSP path computation models involving PCEs. This includes the case of computing the paths of intra- and inter-domain TE LSPs. Such path computation includes the generation of primary, protection, and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with the TEAS Working Group, development of PCE- based architectures for Traffic Engineering including PCE as a Central Controller (PCECC) and Centralized Control Dynamic Routing (CCDR). The PCEP extensions are developed in the PCE Working Group. - In cooperation with protocol-specific Working Groups (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for expressing path computation requests and responses in the various GMPLS-controlled networks, including WSON and Flexible Grid. - Definition of PCEP extensions for path computation in multi-layer and inter-domain 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 the receiving PCC/PCE chooses not to follow the recommendation. The PCEP extensions for state synchronization are also in scope. - Definition of the PCEP extensions for SR-MPLS and SRv6 paths as per the SR Policy architecture in cooperation with SPRING Working Group. - Definition of the PCEP extensions for new path setup types (such as BIER and DETNET) in close cooperation with the respective Working Groups. Milestones: Nov 2023 - Submit PCEP YANG Model as a Proposed Standard Nov 2023 - Submit PCEP Native-IP extensions as a Proposed Standard Mar 2024 - Submit PCEP extensions for SR Policy as Proposed Standard Mar 2024 - Submit PCEP extensions for Multipath as Proposed Standard Dec 2024 - Submit Enhancements to Stateful PCE Mar 2025 - Evaluate WG progress, recharter or close ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman
Protocol Action: 'Path Segment Identifier in MPLS Based Segment Routing Network' to Proposed Standard (draft-ietf-spring-mpls-path-segment-22.txt)
The IESG has approved the following document: - 'Path Segment Identifier in MPLS Based Segment Routing Network' (draft-ietf-spring-mpls-path-segment-22.txt) as Proposed Standard This document is the product of the Source Packet Routing in Networking Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ Technical Summary This document defines Path Segment to identify an SR path on the egress node of the path. Document Quality There are implementations and they are reported in the document (as RFC 7942 recommends). Personnel Document Shepherd: Bruno Decraene Responsible AD: Jim Guichard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The Privacy Pass Architecture' to Informational RFC (draft-ietf-privacypass-architecture-16.txt)
The IESG has approved the following document: - 'The Privacy Pass Architecture' (draft-ietf-privacypass-architecture-16.txt) as Informational RFC This document is the product of the Privacy Pass Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-privacypass-architecture/ Technical Summary This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for constructing privacy-preserving authentication mechanisms. It provides recommendations on how the architecture should be deployed to ensure the privacy of clients and the security of all participating entities. Working Group Summary No controversies and participation with external parties (eg W3C) happened as well. A number of issues came up in the directorate reviews which were addressed. Document Quality There are deployed examples of the privacy pass architecture. References to these implementations are included in the document. This includes two open source implementations that implement pieces of the architecture and vendor products including private access tokens implemented by Apple, Cloudflare and Fastly. Personnel The Document Shepherd for this document is Joseph A. Salowey. The Responsible Area Director is Paul Wouters. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Inventory YANG (ivy) WG Virtual Meeting: 2023-12-05 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Network Inventory YANG (ivy) WG will hold a virtual interim meeting on 2023-12-05 from 16:00 to 17:00 Europe/Rome (15:00 to 16:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=76bbb9c7-0f2d-4253-a899-a27a9ccf23a6 -- A calendar subscription for all ivy meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=ivy ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Time Protocols (ntp) WG Virtual Meeting: 2023-12-14
The Network Time Protocols (ntp) WG will hold a virtual interim meeting on 2023-12-14 from 11:00 to 12:30 America/New_York (16:00 to 17:30 UTC). Agenda: Draft Agenda: 1. Administrative and Agenda Bashing (Chairs) 2. NTP/TICTOC WG Document Status Review/Update (Chairs) https://datatracker.ietf.org/doc/draft-ietf-ntp-update-registries/ https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/ 3. NTP over PTP - WGLC Results https://datatracker.ietf.org/doc/draft-ietf-ntp-over-ptp/ 4. NTPv5 Requirements - WGLC Results https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/ 5. Ongoing working group efforts (any updates?) NTPv5 Protocol Specification https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5/ Roughtime https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/ https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime-ecosystem/ NTS for PTP https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp-05 6. AOB and Way Forward Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=99b2d950-7af1-41ee-9ad9-af24e7e0a6d0 -- A calendar subscription for all ntp meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=ntp ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Configuration (netconf) WG Virtual Meeting: 2023-12-04
The Network Configuration (netconf) WG will hold a virtual interim meeting on 2023-12-04 from 09:00 to 11:00 America/Los_Angeles (17:00 to 19:00 UTC). Agenda: Discussion on netconf-next and restconf-next issues. https://github.com/netconf-wg/netconf-next/issues https://github.com/netconf-wg/restconf-next/issues Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=83304530-5ca3-4de7-9941-dc2ea550af4d -- A calendar subscription for all netconf meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=netconf ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Interim Meeting Cancelled (was 2023-11-29)
The Concise Binary Object Representation Maintenance and Extensions (cbor) virtual interim meeting for 2023-11-29 from 16:00 to 17:00 Europe/Berlin has been cancelled. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Redacted Fields in the Registration Data Access Protocol (RDAP) Response' to Proposed Standard (draft-ietf-regext-rdap-redacted-16.txt)
The IESG has approved the following document: - 'Redacted Fields in the Registration Data Access Protocol (RDAP) Response' (draft-ietf-regext-rdap-redacted-16.txt) as Proposed Standard This document is the product of the Registration Protocols Extensions Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/ Technical Summary This document describes an RDAP extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. Working Group Summary This document reached broad agreement with many reviews by working group participants. Consensus for this document was NOT particularly rough. Many reviewers did find technical errors with examples, but these have all been corrected. Working group discussions on other topics which were much more controversial did become intertwined with this document, but those other issues are not directly related to RDAP redaction. Such discussions did demonstrate the working groups attention to how this document fits into the larger architecture of RDAP. No appeal is threatened. Document Quality This document has one known, non-production server implementation, and no known client implementations. Many gTLD registries and registrars will be implementing servers with this specification for servers under a forth-coming ICANN policy, and ICANN has indicated its intention to implement this specification for its ICANN command line client (https://github.com/icann/icann-rdap) and web-based lookup tool (https://lookup.icann.org/en). Personnel The Document Shepherd for this document is Andy Newton. The Responsible Area Director is Murray Kucherawy. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Static Context Header Compression (schc) WG Virtual Meeting: 2024-03-05
The Static Context Header Compression (schc) WG will hold a virtual interim meeting on 2024-03-05 from 16:00 to 17:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: Note that this meeting is after the draft submission cutoff. The agenda will be announced a week before the meeting. General topics are the ongoing WGLC, work on WG items and new submissions. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=54a5b7b5-5c7a-4e6f-bc7a-03099dc2883b -- A calendar subscription for all schc meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=schc ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Static Context Header Compression (schc) WG Virtual Meeting: 2024-02-20
The Static Context Header Compression (schc) WG will hold a virtual interim meeting on 2024-02-20 from 16:00 to 17:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: The agenda will be announced a week before the meeting. General topics are the ongoing WGLC, work on WG items and new submissions. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=8d8b13c5-f017-41dc-9b87-a14345594345 -- A calendar subscription for all schc meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=schc ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Static Context Header Compression (schc) WG Virtual Meeting: 2024-02-06
The Static Context Header Compression (schc) WG will hold a virtual interim meeting on 2024-02-06 from 16:00 to 17:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: The agenda will be announced a week before the meeting. General topics are the ongoing WGLC, work on WG items and new submissions. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=50aa2348-28b7-4f85-818c-3a2a79a41f40 -- A calendar subscription for all schc meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=schc ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Static Context Header Compression (schc) WG Virtual Meeting: 2024-01-23
The Static Context Header Compression (schc) WG will hold a virtual interim meeting on 2024-01-23 from 16:00 to 17:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: The agenda will be announced a week before the meeting. General topics are the ongoing WGLC, work on WG items and new submissions. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=9d720379-dde9-47e1-b72b-5da297be7ebd -- A calendar subscription for all schc meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=schc ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Static Context Header Compression (schc) WG Virtual Meeting: 2024-01-09
The Static Context Header Compression (schc) WG will hold a virtual interim meeting on 2024-01-09 from 16:00 to 17:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: The agenda will be announced a week before the meeting. General topics are the ongoing WGLC, work on WG items and new submissions. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=25ed8478-0540-4d49-83f3-9171e5b3d795 -- A calendar subscription for all schc meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=schc ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Static Context Header Compression (schc) WG Virtual Meeting: 2023-12-12
The Static Context Header Compression (schc) WG will hold a virtual interim meeting on 2023-12-12 from 16:00 to 17:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: The agenda will be announced a week before the meeting. General topics are the ongoing WGLC, work on WG items and new submissions. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3a2937fb-6381-4bdc-b69c-5c6f866574ad -- A calendar subscription for all schc meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=schc ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6) to Proposed Standard
The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6", and obsoletes the prevision specification of this version documented in RFC 5798. VRRP specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets sent to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. The VRRP terminology has been updated to conform to inclusive language guidelines for IETF technologies. The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Formal IESG Teleconference Webex and Dial-in Information: 30 November 2023
All members of the community are welcome to attend formal IESG telechats as observers. Observers are not invited to participate in the discussion. The next formal IESG telechat will be held on Thursday, September 7, 2023 at 07:00 US/Canada Pacific (15:00 UTC). The meeting is scheduled for two hours (07:00-09:00 US/Canada Pacific). Webex and Dial-in information is at the bottom of this message. The agenda for the upcoming telechat can be found at <https://datatracker.ietf.org/iesg/agenda/> A calendar of upcoming public telechats can be downloaded or subscribed to at: https://calendar.google.com/calendar/ical/ietf.org_egdabaf39ch5v8a13dt39mvee4%40group.calendar.google.com/public/basic.ics Topic: IESG Formal Telechat Date: November 30, 2023 Time: 07:00 US/Canada Pacific 09:00 US/Canada Central 10:00 US/Canada Eastern 15:00 UTC 15:00 United Kingdom 16:00 Germany, France, Belgium, Sweden 17:00 Finland 18:00 Kenya 20:30 India --- JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m3cc48bcbd48465d4da48d0197a6e7bb2 Meeting number: 2427 431 7054 Meeting password: 12345 JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 2427 431 7054 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-03-06 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-03-06 from 16:00 to 17:00 Europe/Berlin (15:00 to 16:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-05-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=cc6fec51-aa51-46d7-9d9b-ac5bec286bf2 -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-02-21 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-02-21 from 16:00 to 17:00 Europe/Berlin (15:00 to 16:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-04-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=850007b6-efbb-4aba-9591-d3b99ec8666d -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-02-07 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-02-07 from 16:00 to 17:00 Europe/Berlin (15:00 to 16:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-03-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=475afc1f-43e9-4f9c-9a92-debbe1904def -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-01-24 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-01-24 from 16:00 to 17:00 Europe/Berlin (15:00 to 16:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-02-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=bf314fea-c6b7-4675-a169-991dbf5f60b1 -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-01-10 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-01-10 from 16:00 to 17:00 Europe/Berlin (15:00 to 16:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-01-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=9cce4c41-debd-4956-92ef-6a4d6ec7ebad -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2023-12-13 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2023-12-13 from 16:00 to 17:00 Europe/Berlin (15:00 to 16:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2023-cbor-18-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=04c6286d-c456-4406-bbec-90442baa5164 -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2023-11-29 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2023-11-29 from 16:00 to 17:00 Europe/Berlin (15:00 to 16:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2023-cbor-17-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3d8ca2bd-a5b0-4c0e-b576-8ca627174668 -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Inventory YANG (ivy) WG Virtual Meeting: 2024-02-07
The Network Inventory YANG (ivy) WG will hold a virtual interim meeting on 2024-02-07 from 16:00 to 17:00 Europe/Rome (15:00 to 16:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=11f63348-e0f3-4c50-a026-154c56692ee4 -- A calendar subscription for all ivy meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=ivy ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Inventory YANG (ivy) WG Virtual Meeting: 2024-01-10
The Network Inventory YANG (ivy) WG will hold a virtual interim meeting on 2024-01-10 from 16:00 to 17:00 Europe/Rome (15:00 to 16:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=6aba3789-2de0-4895-9451-ed443f592d40 -- A calendar subscription for all ivy meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=ivy ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Inventory YANG (ivy) WG Virtual Meeting: 2023-12-06
The Network Inventory YANG (ivy) WG will hold a virtual interim meeting on 2023-12-06 from 16:00 to 17:00 Europe/Rome (15:00 to 16:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=11dd7318-bb08-4d57-8c7b-822fe8ca74d5 -- A calendar subscription for all ivy meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=ivy ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-03-06
The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-03-06 from 14:00 to 15:00 Europe/Berlin (13:00 to 14:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-05-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=b8e86a03-54d1-4a06-9ffa-4f7978024b2e -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-02-21
The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-02-21 from 14:00 to 15:00 Europe/Berlin (13:00 to 14:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-04-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=79cd0805-edca-4555-95f5-ae3feb4a4c82 -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-02-07
The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-02-07 from 14:00 to 15:00 Europe/Berlin (13:00 to 14:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-03-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=17b62e40-2995-4d44-b41a-346af51de342 -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-01-24
The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-01-24 from 14:00 to 15:00 Europe/Berlin (13:00 to 14:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-02-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=b20263ad-1ff9-4cfd-927e-940cc9cdb4ce -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2024-01-10
The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2024-01-10 from 14:00 to 15:00 Europe/Berlin (13:00 to 14:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2024-cbor-01-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=f4b7f408-22d7-4c1b-aaa8-998938a9970e -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2023-12-13
The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2023-12-13 from 14:00 to 15:00 Europe/Berlin (13:00 to 14:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2023-cbor-18-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=ae447258-a127-4e3e-b21a-16ef0d4ad0c2 -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2023-11-29
The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2023-11-29 from 14:00 to 15:00 Europe/Berlin (13:00 to 14:00 UTC). Agenda: General agenda is to address currently open issues and in-progress documents. Specific agenda will be available the day before the meeting at: https://notes.ietf.org/notes-ietf-interim-2023-cbor-17-cbor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=6a60e259-c349-4161-9377-a77285afbc9a -- A calendar subscription for all cbor meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cbor ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Secure Asset Transfer Protocol (satp) WG Virtual Meeting: 2023-12-05
The Secure Asset Transfer Protocol (satp) WG will hold a virtual interim meeting on 2023-12-05 from 15:00 to 16:00 Europe/London (15:00 to 16:00 UTC). Agenda: - review actions from IETF118 - discuss readiness of documents to progress to peer review - updates from Network Identity group Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=646fcd78-f4ae-4f22-96f0-aa41f9f62f1d Most suitable date and time as per doodlepoll sent to the working group -- A calendar subscription for all satp meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=satp ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic
The IESG has received a request from an individual participant to make the following status changes: - RFC5933 from Proposed Standard to Historic (Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC) The supporting document for this request can be found here: https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/ The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The affected document can be obtained via https://datatracker.ietf.org/doc/rfc5933/ IESG discussion of this request can be tracked via https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/ballot/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Messaging Layer Security (mls) WG Virtual Meeting: 2024-01-25
The Messaging Layer Security (mls) WG will hold a virtual interim meeting on 2024-01-25 from 10:00 to 12:00 America/New_York (15:00 to 17:00 UTC). Agenda: Extensions: draft-ietf-mls-extensions draft-barnes-mls-addl-creds draft-mahy-mls-x25519kyber768draft00 draft-mahy-mls-kp-context ... Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=f6897167-addb-42c1-8be8-7a0c7d120552 -- A calendar subscription for all mls meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=mls ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Deterministic Networking (detnet) WG Virtual Meeting: 2023-12-12
The Deterministic Networking (detnet) WG will hold a virtual interim meeting on 2023-12-12 from 08:00 to 10:00 America/New_York (13:00 to 15:00 UTC). Agenda: https://datatracker.ietf.org/doc/agenda-interim-2023-detnet-13-detnet-01/ Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=b4c60a10-3026-422e-a9f2-65affb467bd0 -- A calendar subscription for all detnet meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=detnet ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (A Simple Control Protocol for MPLS SFLs) to Proposed Standard
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Simple Control Protocol for MPLS SFLs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-11-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In RFC 8957 the concept of MPLS synonymos flow labels (SFL) was introduced. This document describes a simple control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of such labels. It is not the only control protocol that might be used to support SFL, but it has the benefit of being able to be used without modification of the existing MPLS control protocols. The existence of this design is not intended to restrict the ability to enhance an existing MPLS control protocol to add a similar capability. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-sfl-control/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5015/ https://datatracker.ietf.org/ipr/2606/ https://datatracker.ietf.org/ipr/2847/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Privacy Pass HTTP Authentication Scheme' to Proposed Standard (draft-ietf-privacypass-auth-scheme-15.txt)
The IESG has approved the following document: - 'The Privacy Pass HTTP Authentication Scheme' (draft-ietf-privacypass-auth-scheme-15.txt) as Proposed Standard This document is the product of the Privacy Pass Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-privacypass-auth-scheme/ Technical Summary This document defines an HTTP authentication scheme that can be used by clients to redeem Privacy Pass tokens with an origin. It can also be used by origins to challenge clients to present an acceptable Privacy Pass token. Working Group Summary The document is intended to address a specific charter point for the PRIVACYPASS working group: to "specify a HTTP-layer API for the protocol". Initial proposals defined a REST API, but the proposal was ultimately streamlined to this form. The working group has a clear consensus that this is the right approach and adequately addresses the need for an "HTTP-layer API". The AD was consulted to see if this was considered in charter. Document Quality A number of vendors are implementing or planning to implement. Personnel The Document Shepherd for this document is Benjamin M. Schwartz. The Responsible Area Director is Paul Wouters. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-07-02
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-07-02 from 15:00 to 16:00 America/New_York (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-06-18
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-06-18 from 15:00 to 16:00 America/New_York (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-06-04
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-06-04 from 15:00 to 16:00 America/New_York (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-05-21
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-05-21 from 15:00 to 16:00 America/New_York (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-04-23
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-04-23 from 15:00 to 16:00 America/New_York (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-04-09
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-04-09 from 15:00 to 16:00 America/New_York (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-02-27
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-02-27 from 15:00 to 16:00 America/New_York (20:00 to 21:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-02-13
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-02-13 from 15:00 to 16:00 America/New_York (20:00 to 21:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-01-30
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-01-30 from 15:00 to 16:00 America/New_York (20:00 to 21:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2024-01-16
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2024-01-16 from 15:00 to 16:00 America/New_York (20:00 to 21:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2023-12-19
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2023-12-19 from 15:00 to 16:00 America/New_York (20:00 to 21:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2023-12-05
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2023-12-05 from 15:00 to 16:00 America/New_York (20:00 to 21:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2023-11-21 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2023-11-21 from 15:00 to 16:00 America/New_York (20:00 to 21:00 UTC). Agenda: * Draft status and progress * Security considerations * Internationalization considerations * RFC5661bis/RFC5662bis Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=8f713b5b-91b3-42dc-9aa7-a43bb3a9c00f -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2023-11-21 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2023-11-21 from 10:00 to 11:00 America/New_York (15:00 to 16:00 UTC). Agenda: * Draft status and progress * Security considerations * Internationalization considerations * RFC5661bis/RFC5662bis Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Deterministic Networking (DetNet): Packet Ordering Function) to Informational RFC
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Deterministic Networking (DetNet): Packet Ordering Function' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-11-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Replication and Elimination functions of DetNet Architecture can result in out-of-order packets, which is not acceptable for some time-sensitive applications. The Packet Ordering Function (POF) algorithm described herein enables to restore the correct packet order when replication and elimination functions are used in DetNet networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-pof/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5032/ https://datatracker.ietf.org/ipr/5092/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Universally Unique IDentifiers (UUID)' to Proposed Standard (draft-ietf-uuidrev-rfc4122bis-14.txt)
The IESG has approved the following document: - 'Universally Unique IDentifiers (UUID)' (draft-ietf-uuidrev-rfc4122bis-14.txt) as Proposed Standard This document is the product of the Revise Universally Unique Identifier Definitions Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/ Technical Summary This specification defines the UUIDs (Universally Unique IDentifiers) and the UUID Uniform Resource Name (URN) namespace. UUIDs are also known as GUIDs (Globally Unique IDentifiers). A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. This document obsoletes RFC4122. Working Group Summary The document represents a strong concurrence of a many individuals, including many from outside the IETF community who maintain running code. Document Quality Yes there are a number of implementators involved, and many have implemented the changes. The ITU-T and the ISO published documents similiar to RFC4122 at the time, but they have not responded to this BIS process. Personnel The Document Shepherd for this document is Michael Richardson. The Responsible Area Director is Murray Kucherawy. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period' to Proposed Standard (draft-ietf-cbor-time-tag-12.txt)
The IESG has approved the following document: - 'Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period' (draft-ietf-cbor-time-tag-12.txt) as Proposed Standard This document is the product of the Concise Binary Object Representation Maintenance and Extensions Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/ Technical Summary The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949 defines two tags for time: CBOR tag 0 (RFC3339 time as a string) and tag 1 (Posix time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. It is intended as the reference document for the IANA registration of the CBOR tags defined. Working Group Summary The document has broad agreement from the active working group. There was no particular controversy or points were the consensus was particularly rough. Document Quality There are early implementations, though they are not listed. The document is expected to get wide adoption. There has been coordination with the SEDATE working group and its document draft-ietf-sedate-datetime-extended. As a product of the CBOR working group, the document has been reviewed by the CBOR experts. There is some simple ABNF in it, which does not need expert review. Personnel The Document Shepherd for this document is Barry Leiba. The Responsible Area Director is Francesca Palombini. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The LIMITS SMTP Service Extension' to Proposed Standard (draft-freed-smtp-limits-07.txt)
The IESG has approved the following document: - 'The LIMITS SMTP Service Extension' (draft-freed-smtp-limits-07.txt) as Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Murray Kucherawy. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-freed-smtp-limits/ Technical Summary This document defines a "Limits" extension for the Simple Mail Transfer Protocol (SMTP), including submission, as well as the Local Mail Transfer Protocol (LMTP). It also defines an associated limit registry. This extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol during the current session. The client is then able to adapt its behavior in order to conform to those limits. Working Group Summary It was considered in EMAILCORE, which chose not to process it. As there is no other appropriate home for it in the ART area at this time, it is now a sponsored document. The work otherwise got good discussion followed by general supportive grumbling from the appropriate community. Document Quality Though consensus appears to concur that there is a need for this and its appearance would be beneficial, there are no expressly committed parties. Personnel Murray Kucherawy is both the responsible Area Director and the Document Shepherd. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect' to Proposed Standard (draft-ietf-regext-rdap-openid-27.txt)
The IESG has approved the following document: - 'Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect' (draft-ietf-regext-rdap-openid-27.txt) as Proposed Standard This document is the product of the Registration Protocols Extensions Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/ Technical Summary The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect. Working Group Summary Broad agreement was reached. There have been 7 expressions of support (not counting the editors or document shepherd) and no objections. No appeal has been threatened. Document Quality Section 10 contains implementation status. IANA Considerations appear to be correct and clear. Personnel The Document Shepherd for this document is Zaid AlBanna. The Responsible Area Director is Murray Kucherawy. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (RTP Payload Format for Essential Video Coding (EVC)) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'RTP Payload Format for Essential Video Coding (EVC)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-11-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an RTP payload format for the Essential Video Coding (EVC) standard, published as ISO/IEC International Standard 23094-1. EVC was developed by the Moving Picture Experts Group (MPEG). The RTP payload format allows for the packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload and the fragmentation of a NAL unit into multiple RTP packets. The payload format has broad applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-evc/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5999/ The document contains these normative downward references. See RFC 3967 for additional information: rfc7656: A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (Informational - Internet Engineering Task Force (IETF)) rfc7667: RTP Topologies (Informational - Internet Engineering Task Force (IETF)) rfc2974: Session Announcement Protocol (Experimental - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
The Tools Team (tools) TEAM Interim Meeting Cancelled (was 2023-11-14)
The The Tools Team (tools) virtual interim meeting for 2023-11-14 from 13:00 to 14:00 America/Chicago has been cancelled. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network File System Version 4 (nfsv4) WG Virtual Meeting: 2023-11-21
The Network File System Version 4 (nfsv4) WG will hold a virtual interim meeting on 2023-11-21 from 15:00 to 16:00 UTC. Agenda: * Draft status and progress * Security considerations * Internationalization considerations * RFC5661bis/RFC5662bis Information about remote participation: https://cmu.zoom.us/j/91373252686?pwd=WHFWSXBuVVo3RWh5aDZsZXF6NHBYQT09 -- A calendar subscription for all nfsv4 meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nfsv4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' to Best Current Practice (draft-ietf-intarea-rfc7042bis-11.txt)
The IESG has approved the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' (draft-ietf-intarea-rfc7042bis-11.txt) as Best Current Practice This document is the product of the Internet Area Working Group. The IESG contact persons are Erik Kline and Éric Vyncke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-rfc7042bis/ Technical Summary Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 7042. Working Group Summary The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward. During the meetings there was a general support for this document and the need to update RFC 7042 (which this document actually obsoletes). The responsible AD, Eric Vyncke, was (and still is) not comfortable of having a CBOR encoding section in this document describing mainly code points. But, there was no opposition on this inclusion even after an email sent to INTAREA & CBOR WG and ADs, so let it be. See https://mailarchive.ietf.org/arch/msg/cbor/sPQtY45DCla9y2K6VTdy-LCfLIM/ Document Quality The document does not specify a protocol. Therefore, no implementation exists. There have been extensive reviews (including CBOR WG and by IEEE via the IEEE-IETF coordination list and liaison statement: https://datatracker.ietf.org/liaison/1849/ Personnel The Document Shepherd for this document is Luigi Iannone. The Responsible Area Director is Éric Vyncke. IANA Note (copied from the shepherd's write-up) The whole document is an IANA Consideration. The content is consistent. The document does not request the creation of new registries neither any new assignment. However, a few updates are requested to IANA, namely: - The IANA "Ethernet Numbers" web page is re-named the "IANA OUI Ethernet Numbers" web page. - References to [RFC7042] in IANA registries on both the IANA IEEE 802 Numbers web page and the IANA IETF OUI Ethernet Numbers web pages will be replaced by references to this document. - IANA is requested to move the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" Registry from the IANA IEEE 802 Numbers web page to the IANA OUI Ethernet Numbers web page, and to add this document as an additional reference for that registry. IANA is requested to update three entries in that Registry as follows: | Value | Description | Reference | |---|--|-| | 0 | Reserved | [this document] | |42 | Example for use in documentation | [this document] | | 255 | Reserved | [this document] | - IANA is requested to assign two CBOR Tags: | Tag | Data Item | Semantics| Reference | |--|-|--|-| | TBD1 | byte string | IEEE MAC Address | [this document] | | TBD2 | byte string | IEEE OUI/CID | [this document] | ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Updated: IETF Chair and IESG Report to the Community for IETF 118
Hello, Please see below for an updated link to the IETF Chair and IESG Report for IETF 118: https://datatracker.ietf.org/meeting/118/materials/slides-118-ietf-sessb-ietf-chair-and-iesg-report-ietf-118-01 Best regards, IESG Secretary on behalf of the IETF Chair and the IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF Chair and IESG Report to the Community for IETF 118
Hello, The IETF Chair and the IESG has uploaded their report to the community for IETF 118 to the datatracker. To access the full report: https://datatracker.ietf.org/meeting/118/materials/slides-118-ietf-sessb-ietf-chair-and-iesg-report-ietf-118-00 Hope to see you at IETF 118 either in person or online! Best regards, IESG Secretary on behalf of the IETF Chair and the IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Routing Over Low power and Lossy networks (roll) WG Virtual Meeting: 2024-01-25
The Routing Over Low power and Lossy networks (roll) WG will hold a virtual interim meeting on 2024-01-25 from 13:00 to 14:00 UTC. Agenda: Draft Agenda: - WG Introduction - Active Draft Status - Open Floor Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=025a2104-3160-4a62-8905-489015dae0f6 -- A calendar subscription for all roll meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=roll ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Network Virtualization Overlays (NVO3) Encapsulation Considerations) to Informational RFC
The IESG has received a request from the Network Virtualization Overlays WG (nvo3) to consider the following document: - 'Network Virtualization Overlays (NVO3) Encapsulation Considerations' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-11-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF Network Virtualization Overlays (NVO3) Working Group Chairs and Routing Area Director chartered a design team to take forward the encapsulation discussion and see if there was potential to design a common encapsulation that addresses the various technical concerns. This document provides a record, for the benefit of the IETF community, of the considerations arrived at by the NVO3 encapsulation design team, which may be helpful with future deliberations by working groups over the choice of encapsulation formats. There are implications of having different encapsulations in real environments consisting of both software and hardware implementations and within and spanning multiple data centers. For example, OAM functions such as path MTU discovery become challenging with multiple encapsulations along the data path. The design team recommended Geneve with a few modifications as the common encapsulation. This document provides more details, particularly in Section 7. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-nvo3-encap/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Constrained RESTful Environments (core) WG Virtual Meeting: 2024-02-28
The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2024-02-28 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=b99f9f8c-f049-494f-ab0e-b8b9f25e66c4 -- A calendar subscription for all core meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=core ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Constrained RESTful Environments (core) WG Virtual Meeting: 2024-02-14
The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2024-02-14 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=619ea18b-5710-409a-acae-b17da1ed638c -- A calendar subscription for all core meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=core ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
