Application-Layer Traffic Optimization (alto) WG Virtual Meeting: 2023-02-23 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Application-Layer Traffic Optimization (alto) WG will hold a virtual interim meeting on 2023-02-23 from 10:00 to 12:00 Asia/Shanghai (02:00 to 04:00 UTC). Agenda: 1. Session Introduction and WG Status Update (5 minutes) 1. ALTO over New Transport (45 minutes) Richard 2. ALTO OAM Support (45 mintutes) Jensen Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=b774bb62-58c1-44a7-a7e7-dba0c725fae7 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
NomCom 2022 Announcement of IAB
As Chair of the 2022-2023 NomCom, I am pleased to announce the following appointments to the IAB: Dhruv Dhody Wes Hardakar Suresh Krishnan Alvaro Retana David Schinazi Christopher Wood The combined IAB for the upcoming year is: Dhruv Dhody, Huawei Lars Eggert, NetApp (as IETF Chair) Cullen Jennings, Cisco Wes Hardaker, USC/ISI Mallory Knodel, Center for Democracy and Technology Suresh Krishnan, Cisco Mirja Kühlewind, Ericsson Zhenbin Li, Huawei Alvaro Retana, Futurewei David Schinazi, Google Christopher Wood, Cloudflare Qin Wu, Huawei Jiankang Yao 姚健康, CNNIC China Internet Network Information Center Once again, I wish to thank all of the other nominees and the IETF community for the feedback they provided. -Rich Salz, 2022-2023 IETF NomCom Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (PIM Null-Register packing) to Proposed Standard
The IESG has received a request from the Protocols for IP Multicast WG (pim) to consider the following document: - 'PIM Null-Register packing' 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-02-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 In PIM-SM networks PIM Null-Register messages are sent by the Designated Router (DR) to the Rendezvous Point (RP) to signal the presence of Multicast sources in the network. There are periodic PIM Null-Registers sent from the DR to the RP to keep the state alive at the RP as long as the source is active. The PIM Null-Register message carries information about a single Multicast source and group. This document defines a standard to send multiple Multicast source and group information in a single PIM message. This document refers to the new messages as the PIM Packed Null-Register message and PIM Packed Register-Stop message. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pim-null-register-packing/ 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
Open Specification for Pretty Good Privacy (openpgp) WG Virtual Meeting: 2023-02-09 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Open Specification for Pretty Good Privacy (openpgp) WG will hold a virtual interim meeting on 2023-02-09 from 12:00 to 14:00 Europe/Dublin (12:00 to 14:00 UTC). Agenda: # OpenPGP Interim Feb 2023 - time: 2023-02-09 12:00 UTC - 14:00 UTC - location: [https://meet.jit.si/IETF-OpenPGP-WG-Interim-Feb-2023](https://meet.jit.si/IETF-OpenPGP-WG-Interim-Feb-2023) ## Signing - Should the new key and signature formats change codepoint designations from v5 to v6? (this avoids collision with the v5 codepoint which has seen some pre-specification deployment and could cause confusion in the wild) - Should the fingerprint and signing octet for the new form also move from 0x9a to 0x9b? (v4s comparable octet is 0x99) - MR that answers yes to both of the above: [!231](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/231) - Should hashed data for v5 signatures revert to a 4-octet length field? in -07 it is an 8-octet length field, which causes a risk of aliased data streams with v3 or v4 signatures, (see [#130](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130)) - MR that answers yes to the above: [!220](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/220) - Update signature salt size from 16 octets? (see [#150](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/150)) - Should this be a uniform increase to 32 octets? or should it be bound to the hash function used? - Should the size of the salt be indicated on the wire in the Signature packet? - MR that answers bound to the hash function used and indicated on the wire to the above questions: [!219](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/219) - Add Context parameter for signatures? Marcus Brinkmanns messages on this list provide examples of why a context parameter can be useful (see also [#145](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145)) - if so, how do we specify or register the context parameter for different use domains? - MR that says yes, add a context parameter and dont specify any specific context or set up a registry, and is also coupled to a context parameter for encryption: [!214](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/214) ## Encryption - Add Context parameter for encryption? (see [#145](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145)) - if so, how do we specify or register the context parameter for different use domains? - MR that says yes, add a context parameter and dont specify any specific context or set up a registry, and is also coupled to a context parameter for signatures: [!214](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/214) - Remove checksum and padding for v5 PKESK? This reduces the bytes on the wire at no loss of functionality as there is already a checksum in the key wrapping algorithm. - MR that does this: [!223](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/223) ## Overall - Guidance for Designated Expert? (see [mailing list discussion](https://mailarchive.ietf.org/arch/msg/openpgp/3w9bwStWx4NMjvMUiOkVgvNNJlI/) and [#146](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/146)). This doesnt have an MR yet, hopefully Stephen or i can make one before the interim. Do we want to suggest that Designated Experts be given substantial leeway, but advise that they follow the following guidance when considering a specification for the Specification Needed registrations: - avoid codepoint squatting and vanity registrations - require that the specification is concretely useful - require that any registered algorithms meet the security requirements of the community and the message structures for which they are proposed to be used. - Title of the specification? The current title (OpenPGP Message Format) is unclear and confusing (see [#144](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/144)). This is trivial, so lets not bikeshed too hard. Some possible options are: - OpenPGP - OpenPGP Protocol - OpenPGP Wire Format and Semantics - OpenPGP Messages, Signatures, Keys, and Certificates - OpenPGP Data Format ## Overflow (if we have time) - Other outstanding chartered work - Collect list of unchartered work for consideration of a re-charter Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=ba9363d0-0318-4c22-b3a7-f2037e345a02 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Application-Layer Traffic Optimization (alto) WG Virtual Meeting: 2023-02-23 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Application-Layer Traffic Optimization (alto) WG will hold a virtual interim meeting on 2023-02-23 from 09:00 to 11:00 Asia/Shanghai (01:00 to 03:00 UTC). Agenda: 1. Session Introduction and WG Status Update (5 minutes) 1. ALTO over New Transport (45 minutes) Richard 2. ALTO OAM Support (45 mintutes) Jensen 3. Deployment experience Update (25 minutes) LuisJordi Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=f9493b68-7068-47a2-a791-69d7448810ee ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
