Dispute over the future of ENUM telephone domains
Introduced as a bridge between telephony and the internet, ENUM now faces an uncertain future. German and Dutch operators are fighting back.
#DeNIC #IETF #InternationalTelecommunicationUnionITU #Netzpolitik #VoIP #news
Streit über Zukunft von ENUM-Telefon-Domains
Als Brücke zwischen Telefonie und Internet eingeführt, steht ENUM nun vor einer ungewissen Zukunft. Deutsche und niederländische Betreiber wehren sich.
#DeNIC #IETF #InternationalTelecommunicationUnionITU #Netzpolitik #VoIP #news
It feels like BS wiring standards were specified by people from the companies that make the fuses...
Some things never change...
日刊IETF (2026-05-06): Part 2 — ルーティング改善とIETF自身の問い直し
https://qiita.com/tetsuko_room/items/78b9e918aae6f09d84e5?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items
An mir ist es ja etwas vorbeigegangen, dass #AtProto nun allmählich von der #IETF standardisiert wird. Und so im Vergleich der Protokolle finde ich den Ansatz durchaus spannend:
https://fediview.com/articles/activitypub-vs-atproto-understanding-protocols/
Ich werde nun also auch mal #bluesky und andere Dienste in der #Atmosphere (so heißt bei denen das #Fediverse ) ausprobieren.
https://datatracker.ietf.org/doc/charter-ietf-atp/01/
Keine Sorge, das mache ich dann natürlich unter meinem Atmosphere-Account: @esche.eurosky.social
On security.txt:
I understand that staleness may exist in companies and a security contact should be reachable. but why is the solution an EXPIRES field that has to be updated once a year?
- https://datatracker.ietf.org/doc/html/rfc9116#name-expires
People will just automate the task of changing the date of the EXPIRES field instead of changing the contact in their aliases file.
It does not change anything if the date did not expire but nobody is reading [email protected].
When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.
The IDR Working Group, which standardizes BGP in the IETF, is doing last call for the linklocal capability feature.
IPv6-linklocal-only peering is a popular mechanism for some operators who want to avoid uniquely numbering links in network scenarios where the number is irrelevant. This is especially the case for things that are otherwise point to point links. Some people like these in data center use cases!
However, linklocal-only peering has been underspecified and buggy between implementations. This draft fixes that.
Please consider reviewing the draft and providing feedback to the working group mailing list.[1] This can be "yeah, it's ready to go" or "I see a problem here"...
https://datatracker.ietf.org/doc/draft-ietf-idr-linklocal-capability/
To support IPv6 [RFC4291] reachability, BGP [RFC4271] relies on the Multiprotocol Extensions as defined in [RFC4760]. [RFC2545] defines the structure of IPv6 next hops. These IPv6 next hops may contain a Global IPv6 address, and optionally can contain an IPv6 Link-Local address when the BGP peer is directly attached and shares a common subnet with the IPv6 Global address. This document updates [RFC2545] to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 Link-Local address is available. A new BGP Capability [RFC5492] is defined to signal support for this updated encoding. This clarification applies specifically to IPv6 Link-Local addresses and does not pertain to IPv4 Link-Local addresses as defined in [RFC3927].
I'm increasingly convinced the IAB/IESG needs to define a special process before having any consideration or publication of "IPvN" drafts, in the same way that the patent office needed to special-case perpetual motion machines. There's been a disproportionate amount of time and effort from single-author proposals (eg, "IPv8", "IPv10") that has gone into discussing them, including lots of thrash from lots of non-technical folks asking if they need to care about them. The Register article on IPv8 is likely not helping either.
While there should be a path to innovation in the future, any change to the neck of the internet's hourglass is a massive multi-stakeholder undertaking.
heise online English
heise online
Paul Wouters 🇪🇺🇨🇦
Network == Abstraction Layer
Qiita - 人気の記事
Esche
momo
Jeffrey Haas
Erik Nygren 