RE: [PATCH bpf-next] docs/bpf: Document some special sdiv/smod operations

[Dave Thaler <dthaler1968@googlemail.com>]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Tue, Oct 1, 2024 at 12:54 PM Dave Thaler <dthaler1968@googlemail.com>
> wrote:
[...]
> > I'm adding bpf@ietf.org 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