Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Tue, Oct 1, 2024 at 12:54 PM Dave Thaler <dthaler1968@xxxxxxxxxxxxxx> > wrote: [...] > > I'm adding bpf@xxxxxxxx to the To line since all changes in the > > standardization directory should include that mailing list. > > > > The WG should discuss whether any changes should be done via a new RFC > > that obsoletes the first one, or as RFCs that Update and just describe > > deltas (additions, etc.). > > > > There are precedents both ways and I don't have a strong preference, > > but I have a weak preference for delta-based ones since they're > > shorter and are less likely to re-open discussion on previously > > resolved issues, thus often saving the WG time. > > Delta-based additions make sense to me. > > > Also FYI to Linux kernel folks: > > With WG and AD approval, it's also possible (but not ideal) to take > > changes at AUTH48. That'd be up to the chairs and AD to decide > > though, and normally that's just for purely editorial clarifications, > > e.g., to confusion called out by the RFC editor pass. > > Also agree. We should keep AUTH going its course as-is. > All ISA additions can be in the future delta RFC. > > As far as file logistics... my preference is to keep > Documentation/bpf/standardization/instruction-set.rst > up to date. > Right now it's effectively frozen while awaiting changes (if any) necessary for AUTH. > After official RFC is issued we can start landing patches into instruction-set.rst and > git diff 04efaebd72d1..whatever_future_sha instruction-set.rst will automatically > generate the future delta RFC. > Once RFC number is issued we can add a git tag for the particular sha that was the > base for RFC as a documentation step and to simplify future 'git diff'. My concern is that index.rst says: > This directory contains documents that are being iterated on as part of the BPF > standardization effort with the IETF. See the `IETF BPF Working Group`_ page > for the working group charter, documents, and more. So having a document that is NOT part of the IETF BPF Working Group would seem out of place and, in my view, better located up a level (outside standardization). Here’s some examples of delta-based RFCs which explain the gap and provide the addition or clarification, and formally Update (not replace/obsolete) the original RFC: * https://www.rfc-editor.org/rfc/rfc6585.html: Additional HTTP Status Codes * https://www.rfc-editor.org/rfc/rfc6840.html: Clarifications and Implementation Notes for DNS Security (DNSSEC) * https://www.rfc-editor.org/rfc/rfc9295.html: Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers * https://www.rfc-editor.org/rfc/rfc5756.html: Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters Having a full document too is valuable but unless the IETF BPF WG decides to take on a -bis document, I'd suggest keeping it out of the "standardization" (say up 1 level) to avoid confusion, and just have one or more delta-based rst files in the standardization directory. Dave