From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29575 invoked from network); 25 Nov 2023 20:47:34 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 25 Nov 2023 20:47:34 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 9front; Sat Nov 25 15:46:20 -0500 2023 Message-ID: Date: Sat, 25 Nov 2023 21:46:09 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <1375031432.2686734.1700936861177@comcenter.netcologne.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: rich-client-aware AJAX over XML template element backend Subject: Re: [9front] [PATCH] ipv6 flow label support Reply-To: 9front@9front.org Precedence: bulk hey man, this looks pretty wild and i cant wrap my head around why the hell would the *SENDER* put the hash instead of the receiveriver calculating it... currently, the user can set the tos field for its connection using a ctl message... that should go into the flow label field so its up to the user making the connection. is here any RFC suggesting the flowlabel should be a hash that could easilly be calculated by the receiver on the existing ip header fields? i really need more context to convince me that this is the right thing todo. a rfc would do. -- cinap