> -----Original Message----- > From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> > Sent: Friday, November 8, 2024 10:38 AM > To: Dave Thaler <dthaler1968@xxxxxxxxxxxxxx> > Cc: Yonghong Song <yonghong.song@xxxxxxxxx>; bpf@xxxxxxxx; bpf > <bpf@xxxxxxxxxxxxxxx>; Alexei Starovoitov <ast@xxxxxxxxxx>; Andrii Nakryiko > <andrii@xxxxxxxxxx>; Daniel Borkmann <daniel@xxxxxxxxxxxxx>; Martin KaFai Lau > <martin.lau@xxxxxxxxxx> > Subject: Re: [PATCH bpf-next] docs/bpf: Document some special sdiv/smod > operations > > 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. RFC 9669 is immutable. Any additions require a new document, in IETF terminology, since would result in a new RFC number. > > 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. Two of the examples I provided above fit into that category. Two are examples of adding new codepoints. > 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. Welcome to the IETF and immutable RFCs 😊 > The formal delta-s for IETF can be created out of git. Not in the IETF per se, since a new document needs new boilerplate, with a new abstract, introduction, etc. At most, part of the document could be created out of git, but I'm not convinced that git diffs alone (as opposed to some English prose too for each, as in the examples I cited) make for good content in an IETF document. > 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. I am not convinced it is sufficient. Can you point to any precedents in the IETF for such an approach? I can't offhand... See the RFC 5756 reference above for what I mean by English prose for each diff. > btw do we still need to do any minor edit/fixes to instruction-set.rst before tagging it > as RFC9669 ? Yes, we need to backport the formatting/nits from the RFC editor pass. Dave
