The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---> On Mar 23, 2022, at 12:23 PM, Bjørn Mork <bj...@mork.no> wrote: > > Christoph Paasch <cpaa...@apple.com> writes: > >> Hello Bjorn, >> >> Thanks for taking a look at this! Please see inline: >> >>> On Mar 23, 2022, at 5:34 AM, Bjørn Mork via Rpm >>> <r...@lists.bufferbloat.net> wrote: >>> >>> Paul Spooren <m...@aparcar.org> writes: >>> >>>> The spec wants a 8GB file which seems a bit much for common home >>>> routers. We could look into reading from /dev/zero since the body >>>> content isn’t relevant but still the device is likely slower at >>>> offering the content than your laptop can chew. A dedicated device >>>> could be required. >>> >>> There is no need to read anything from a file or device. You can just >>> serve the same memory buffer in a loop. >> >> That's right! It does not really need to be a file. Some webserver >> implementations have such a capability to generate random content in >> memory. (e.g., >> https://docs.trafficserver.apache.org/en/9.0.x/admin-guide/plugins/generator.en.html >> <https://docs.trafficserver.apache.org/en/9.0.x/admin-guide/plugins/generator.en.html>) >> >>> I did a quick look at the document and it seems under-specified. Page >>> after page with blah-blah, but >>> - not defining Content-Type for any of the URLs >> >> In what way is the content-type relevant for the responsiveness measurement ? > > It becomes relevant once one of the client or server implementations > start making assumptions about it. Worst case is that you have two > implementations making different assumptions. So you specify strict > requirments to avoid that. We could add a line saying that the content-type does not matter and must be ignored. > This is pretty basic for any API. Maybe use OpenAPI or similar to > for clarity instead of the home-grown API spec? I feel like OpenAPI is quite a different beast compared to what we are doing here. >>> - not defining ciphers or any other TLS options, despite the rather >>> restrictive TLSv1.3 requirment >> >> I'm not sure in what way the cipher-suites are relevant to the >> responsiveness measurement itself. In terms of deployment, it is the >> same as for any other webservice. It is something that is usually not >> specified in an IETF-draft as cipher-suites come and go. > > They're relevant the same way the Content-Type is. If you don't say > anything then you might end up with all sorts of incompatible > configurations. This is a deployment problem, not a specification-problem for the particular purpose of measuring responsiveness. For example, we don't specify whether IPv4 or IPv6 should be used. Also, if we list cipher-suites and one of them gets deprecated our RFC would need to be updated as well. >> The TLSv1.3 requirement comes from the fact that we want to measure >> TLS handshake latency, and by requiring TLSv1.3 we know that the >> handshake is exactly 1 round-trip. Probably something to clarify in >> the draft! I filed >> https://github.com/network-quality/draft-ietf-ippm-responsiveness/issues/37 >> <https://github.com/network-quality/draft-ietf-ippm-responsiveness/issues/37>. > > Yes, that makes sense. Thanks for explaining. And I believe you should > include the explanation in the draft as well. > >>> - no config examples for common web servers >> >> It is uncommon for an IETF-draft to provide such kind of >> configurations, because IETF-drafts are aiming to be implementation >> independent as implementations change, but standards don't. We have >> several configurations (and two implementations - one in Go and one in >> Swift) available at https://github.com/network-quality/server/ >> <https://github.com/network-quality/server/>. > > I believe it's common to include a reference implementation if it's > semi-trivial, like the server side of this spec is. > > And it's not unheard of that this reference implementation is given as > configuration examples, in cases where the documenent can be implemented > by configuring existing software. For example: > https://datatracker.ietf.org/doc/html/rfc8806 Yeah, it could make sense to put something in the appendix (https://github.com/network-quality/draft-ietf-ippm-responsiveness/issues/39) > > Now I must admit that I haven't actually tried. But I assume it's > possible to use most web servers for this purpose. Or a pretty simple > python script, maybe. > >>> - no actual client algorithm >> >> Section 4 of the draft tries to explain the client algorithm. With >> specifically Section 4.1.4 formalizing the "working conditions" >> generation. Can you explain a bit more what parts are unclear to you? > > Re-reading this, I realize that I went out to harsh here. Sorry. > > I think it can be improved by replacing things like > > "It is left to the implementation what to do when saturation is not > reached within that time-frame." > > with a precise description of what to do. There are two approaches here: Either, the implementation aborts and errors out. Or, the implementation nevertheless measures the responsiveness and either presents the result as a valid result or as a result with a low confidence score. We can probably outline the options that an implementation has. (https://github.com/network-quality/draft-ietf-ippm-responsiveness/issues/40) Thanks for your feedback, Christoph
--- End Message ---
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
