On Thu, Nov 7, 2024 at 6:30 PM Dave Thaler <dthaler1968@xxxxxxxxxxxxxx> wrote: > > > 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). It's a part of bpf wg. It's not a new document. > 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. This patch is effectively a fix to the standard. It's a standard git development process when fixes are applied to the existing document. Forking the whole doc into a different file just to apply fixes makes no sense to me. The formal delta-s for IETF can be created out of git. We only need to tag the current version and then git diff rfc9669_tag..HEAD will give us that delta. That will satisfy IETF process and won't mess up normal git style kernel development. btw do we still need to do any minor edit/fixes to instruction-set.rst before tagging it as RFC9669 ?
