@mconley yeah, I worked on one of those solutions back in my day :-). Even though it does not look like something difficult, it's a pretty complex thing to design. Multiplexing audio and video can be often very resource intensive task not talking about supported/unsupported codecs. Signalization is another story. #SIP being utilized everywhere brings another challenge because every company creates their own standards and ignores/extends existing #RFC .. it's a hell :-)
Just wanted to share some thoughts on #RFC9715 - an #RFC that defines standards on reducing the #DNS issue of IP fragmentation over #UDP. It's not a long read, but a good one for everyone who understands the issues of large UDP responses on the #Internet. A great leap forward to (hopefully) reduce the reflection/amplification #DDoS potential of DNS.
Just today I learned that #Google 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 #TCP.
#RFC Token Yatırımcısı 20 Kat Getiri Elde Etti
Yatırımcı, 12 milyon adet RFC token ile büyük bir pozisyon koruyor. Küçük satışlar yaparak yükseliş beklentisini sürdürdüğünü gösteriyor.
RFC 9752: Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE, C. Li, et al., https://www.rfc-editor.org/info/rfc9752 #RFC 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
RFC 9764: Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets, J. Haas, et al., https://www.rfc-editor.org/info/rfc9764 #RFC 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
RFC 9719: YANG Data Model for Routing in Fat Trees (RIFT), Z. Zhang, et al., https://www.rfc-editor.org/info/rfc9719 #RFC 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
RFC 9696: Routing in Fat Trees (RIFT) Applicability and Operational Considerations, Y. Wei, Ed., et al., https://www.rfc-editor.org/info/rfc9696 #RFC 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
RFC 9692: RIFT: Routing in Fat Trees, T. Przygienda, Ed., et al., https://www.rfc-editor.org/info/rfc9692 #RFC 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
@ffhl @videolan die technische Hintergrund der neuen Streams:
Statt #IPv6 / UDP / #RTP / #Opus. Ist es jetzt: IPv6 / UDP / #MPEG2TS / RTP / Opus.
Es ist also noch ein gaaanz toller (Sarkasmus), proprietärer, unnötiger Protokollheader dazwischen gekommen, der nur das Paket aufbläht. VLC v3 kann aber noch nicht das #IETF #RFC standardisierte, native RTP-Opus, das kann erst der nightly/v4.
Sobald VLC endlich mal releasen sollte, schmeiß ich das MPEG-TS auch ganz schnell wieder weg.
Ahhhh this year we have a new RFC! This year, time management!
Ahh, here it is. Maybe the IETF should publish a list or something including the publication date, so they can be found more easily.
RFC 9759, Unified Time Scaling for Temporal Coordination Frameworks
RFC 9759: Unified Time Scaling for Temporal Coordination Frameworks, K. Kuhns, https://www.rfc-editor.org/info/rfc9759 #RFC 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
Was really looking forward to an April 1 IETF RFC this year - but it appears i will be disappointed this year.
Instead - I guess I'll have to share some of my favorites from years past
RFC 3514 "The Security Flag in the IPv4 Header"
https://datatracker.ietf.org/doc/html/rfc3514
RFC 1149 "A Standard for the Transmission of IP Datagrams on Avian Carriers"
RFC 9726: Operational Considerations for Use of DNS in IoT Devices
Les objets connectés sont une source de risques de sécurité. Pour les limiter, le RFC 8250 normalisait le format #MUD, 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 #DNS a quelques subtilités, décrites dans ce #RFC.
RFC 9726: Operational Considerations for Use of DNS in Internet of Things (IoT) Devices, M. Richardson, et al., https://www.rfc-editor.org/info/rfc9726 #RFC 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
RFC 9778: IANA Considerations for Internet Group Management Protocols, B. Haberman, Ed., https://www.rfc-editor.org/info/rfc9778 #RFC 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
RFC 9777: Multicast Listener Discovery Version 2 (MLDv2) for IPv6, B. Haberman, Ed., https://www.rfc-editor.org/info/rfc9777 #RFC 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
RFC 9776: Internet Group Management Protocol, Version 3, B. Haberman, Ed., https://www.rfc-editor.org/info/rfc9776 #RFC 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
