]> Sandelman Software Works

mcr+ietf@sandelman.ca

Internet Internet-Draft This document allocates an IPv6 /64 prefix from the IANA Special Use registry. This prefix is to be used to provide memorials for key contributors to the IETF that have passed way. About This Document Status information for this document may be found at . Discussion of this document takes place on the ietf Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction At the time of this writing, the RFC series has been around for 55 years, and the IETF itself will celegrate 40 years in 2026. Given a typical minimum age of 30 for a first contribution, it is not surprising that many IETF contributors have retired, and each year a few people pass away of a variety of causes. When Jon Postel, the original RFC-editor, passed away in 1998, the Internet Society (ISOC) established the Jon Postel award, which is awarded approximately annualy. Another key contributor, Jun-ichiro Hagino, better known as Itojun, passed away in 2007, and a similar award was established by ISOC. These are key and important processes, but it is not scalable to establish such a memorial for everyone who has contributed. This document proposes a smaller mechanism for recognizing contributors after their death: a permanent PTR and TXT record in the ip6.arpa zone.

Protocol Description As described in IANA Considerations, a /64 prefix shall be allocated from the Special Use Registry, named the IN-MEMORIUM prefix. An entry shall be made in the reverse map for the IN-MEMORIUM prefix consisting of a number of TXT records.

1. A TXT record would list the persons name, and their years. For instance, it could say "Frederick J. Baker (February 28, 1952 - June 18, 2025)"
2. A second TXT record would provide a URL to an obituary, such as: "https://en.wikipedia.org/wiki/Fred_Baker_%28engineer%29" or "https://datatracker.ietf.org/person/Fred%20Baker"

The IPv6 address allocated may make use of all 64-lower bits. The recommended way to allocate this is to recognize that it consists of 4 units of 16-bits, and each of these groupings can be used to present RFC numbers up to 9999 easily. For instance, Fred Baker, is the author of RFC1220, RFC2804, RFC4595, and RFC8028 (and 60 other RFCs). Fred's address could be given as 2001:TBD:1220:2804:4595:8028.

Privacy Considerations The families the deceased should be consulted prior to approved the record as the record may be intrusive, or might include information the family would prefer to be private.

Security Considerations The Internet often includes hoaxes about the death of people, who have not in fact died. It is recommended that the IESG seek multiple sources of corrobration, and to react slowly to new proposals to allow the facts to be properly evaluated.

IANA Considerations IANA is asked to allocate a /64 prefix from the IANA Special Use pool (2001::/23). A new sub-registry is to be created for this prefix called the "IETF In-Memorium prefix". This new sub-registry will be maintained using the IESG Approval process. No Internet-Draft or RFC is expected. In some cases, the deceased may have left unfinished documents that are published posthumously, and it is appropriate for the IANA Considerations of that document to include the request. The IESG is otherwise asked to consider requests on an approximately twice yearly basis, reporting to the IETF plenary in March and November about such activity about any such allocations made. It is common for the deceased to be remembered during the plenaries. IANA hosts a number of reverse zones already, and this zone would be hosted by IANA. The IESG is considered the "Designated Experts" for this registry. Memorials are only for people who have died, and may not be used for memorials for those not yet medically dead. (In particular, someone in a coma even if they are not expected to recover)

Acknowledgements The people who said this wasn't the worst idea ever.

Changelog

Normative References This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry. This memo provides information for the Internet community.