Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
helvede.net is one of the many independent Mastodon servers you can use to participate in the fediverse.
Velkommen til Helvede, fediversets hotteste instance! Vi er en queerfeministisk server, der shitposter i den 9. cirkel. Welcome to Hell, We’re a DK-based queerfeminist server. Read our server rules!

Administered by:

Server stats:

159
active users

helvede.net: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#rfc

7 posts4 participants0 posts today
RFC Editor<p>RFC 9766: Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout, T. Haynes, et al., <a href="https://www.rfc-editor.org/info/rfc9766" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9766</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document specifies extensions to NFSv4.2 for improving Weak Cache Consistency (WCC). These extensions introduce mechanisms that ensure partial writes performed under a Parallel NFS (pNFS) layout remain coherent and correctly tracked. The 1/3</p>
RFC Editor<p>RFC 9728: OAuth 2.0 Protected Resource Metadata, M.B. Jones, et al., <a href="https://www.rfc-editor.org/info/rfc9728" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9728</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. This document is a product of the Web Authorization Protocol Working Group of the IETF.</p>
Stéphane Bortzmeyer<p><a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a><br>On le sait, un des problèmes stratégiques de l'Internet est l'absence d'un protocole de messagerie instantanée standard et largement répandu. Il n'y a pas de solution simple à ce problème mais le système <a href="https://mastodon.gougere.fr/tags/MLS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>MLS</span></a> (Messaging Layer Security) vise à au moins fournir un mécanisme de sécurité pour les groupes, mécanisme qui peut ensuite être utilisé par un protocole complet, comme XMPP.</p><p><a href="https://www.bortzmeyer.org/9750.html" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9750.html</span><span class="invisible"></span></a></p>
RFC Editor<p>RFC 9767: Grant Negotiation and Authorization Protocol Resource Server Connections, J. Richer, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9767" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9767</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software (the client) and conveying the results and artifacts of that delegation to the software. This extension defines 1/2</p>
RFC Editor<p>RFC 9765: RADIUS/1.1: Leveraging Application-Layer Protocol Negotiation (ALPN) to Remove MD5, A. DeKok, <a href="https://www.rfc-editor.org/info/rfc9765" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9765</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document defines Application-Layer Protocol Negotiation (ALPN) extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an application protocol variant of RADIUS called "RADIUS/1.1". No changes are 1/2</p>
RFC Editor<p>RFC 9750: The Messaging Layer Security (MLS) Architecture, B. Beurdouche, et al., <a href="https://www.rfc-editor.org/info/rfc9750" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9750</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> The Messaging Layer Security (MLS) protocol (RFC 9420) provides a group key agreement protocol for messaging applications. MLS is designed to protect against eavesdropping, tampering, and message forgery, and to provide forward secrecy (FS) and post-compromise 1/4</p>
RFC Editor<p>RFC 9753: Extension for Stateful PCE to Allow Optional Processing of Path Computation Element Communication Protocol (PCEP) Objects, C. Li, et al., <a href="https://www.rfc-editor.org/info/rfc9753" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9753</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document introduces a mechanism to mark some of the Path Computation Element Communication Protocol (PCEP) objects as optional during PCEP message exchange, so the stateful Path Computation Element 1/2</p>
RFC Editor<p>RFC 9761: Manufacturer Usage Description (MUD) for TLS and DTLS Profiles for Internet of Things (IoT) Devices, T. Reddy.K, et al., <a href="https://www.rfc-editor.org/info/rfc9761" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9761</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This memo extends the Manufacturer Usage Description (MUD) specification to allow manufacturers to define TLS and DTLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, 1/2</p>
Max Resing<p>Just wanted to share some thoughts on <a href="https://infosec.exchange/tags/RFC9715" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC9715</span></a> - an <a href="https://infosec.exchange/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> that defines standards on reducing the <a href="https://infosec.exchange/tags/DNS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DNS</span></a> issue of IP fragmentation over <a href="https://infosec.exchange/tags/UDP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>UDP</span></a>. It's not a long read, but a good one for everyone who understands the issues of large UDP responses on the <a href="https://infosec.exchange/tags/Internet" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Internet</span></a>. A great leap forward to (hopefully) reduce the reflection/amplification <a href="https://infosec.exchange/tags/DDoS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DDoS</span></a> potential of DNS.</p><p>Just today I learned that <a href="https://infosec.exchange/tags/Google" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Google</span></a> will configure their public DNS resolvers to limit to ~1400 bytes (smaller adjustments expected while figuring out the sweet spot in production). From now on, DNS responses which exceed this limit will have the truncated flag set instructing the client to resolve back to <a href="https://infosec.exchange/tags/TCP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>TCP</span></a>. </p><p><a href="https://infosec.exchange/tags/ipv4" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ipv4</span></a> <a href="https://infosec.exchange/tags/ipv6" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ipv6</span></a> <a href="https://infosec.exchange/tags/ietf" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ietf</span></a></p>
RFC Editor<p>RFC 9752: Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE, C. Li, et al., <a href="https://www.rfc-editor.org/info/rfc9752" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9752</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that enable the inclusion of vendor-specific information in stateful Path Computation Element (PCE) 1/3</p>
RFC Editor<p>RFC 9764: Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets, J. Haas, et al., <a href="https://www.rfc-editor.org/info/rfc9764" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9764</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know not only that the path between two systems is 1/3</p>
RFC Editor<p>RFC 9719: YANG Data Model for Routing in Fat Trees (RIFT), Z. Zhang, et al., <a href="https://www.rfc-editor.org/info/rfc9719" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9719</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document defines a YANG data model for the configuration and management of the Routing in Fat Trees (RIFT) Protocol. The model is based on YANG 1.1, which is defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 1/2</p>
RFC Editor<p>RFC 9696: Routing in Fat Trees (RIFT) Applicability and Operational Considerations, Y. Wei, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9696" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9696</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document discusses the properties, applicability, and operational considerations of Routing in Fat Trees (RIFT) in different network scenarios with the intention of providing a rough guide on how RIFT can be deployed to simplify routing 1/2</p>
RFC Editor<p>RFC 9692: RIFT: Routing in Fat Trees, T. Przygienda, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9692" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9692</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document defines a specialized, dynamic routing protocol for Clos, fat tree, and variants thereof. These topologies were initially used within crossbar interconnects and consequently router and switch backplanes, but their characteristics make them ideal for constructing IP 1/2</p>
RFC Editor<p>RFC 9759: Unified Time Scaling for Temporal Coordination Frameworks, K. Kuhns, <a href="https://www.rfc-editor.org/info/rfc9759" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9759</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication. Existing models fail due to inherent unpredictability and inconsistencies in human estimation. This document introduces the 1/2</p>
Stéphane Bortzmeyer<p>RFC 9726: Operational Considerations for Use of DNS in IoT Devices</p><p>Les objets connectés sont une source de risques de sécurité. Pour les limiter, le RFC 8250 normalisait le format <a href="https://mastodon.gougere.fr/tags/MUD" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>MUD</span></a>, pour que le fournisseur du machin connecté documente les accès au réseau de l'objet. Dans un fichier MUD, les services avec lesquels l'objet communique sont indiqués par un nom de domaine. Le <a href="https://mastodon.gougere.fr/tags/DNS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DNS</span></a> a quelques subtilités, décrites dans ce <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a>.</p><p><a href="https://www.bortzmeyer.org/9726.html" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9726.html</span><span class="invisible"></span></a></p>
RFC Editor<p>RFC 9726: Operational Considerations for Use of DNS in Internet of Things (IoT) Devices, M. Richardson, et al., <a href="https://www.rfc-editor.org/info/rfc9726" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9726</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document details considerations about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying Manufacturer Usage Descriptions (MUD), as specified in RFC 1/2</p>
RFC Editor<p>RFC 9778: IANA Considerations for Internet Group Management Protocols, B. Haberman, Ed., <a href="https://www.rfc-editor.org/info/rfc9778" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9778</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document specifies revised IANA considerations for the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. This document specifies the guidance provided to IANA to manage values associated with various fields 1/2</p>
RFC Editor<p>RFC 9777: Multicast Listener Discovery Version 2 (MLDv2) for IPv6, B. Haberman, Ed., <a href="https://www.rfc-editor.org/info/rfc9777" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9777</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document specifies the Multicast Listener Discovery version 2 (MLDv2) protocol. MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links and to discover which multicast addresses are of interest to those 1/3</p>
RFC Editor<p>RFC 9776: Internet Group Management Protocol, Version 3, B. Haberman, Ed., <a href="https://www.rfc-editor.org/info/rfc9776" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9776</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> The Internet Group Management Protocol (IGMP) is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report 1/3</p>
ExploreLive feeds
About