On Fri, Nov 8, 2024 at 10:53 AM Dave Thaler <dthaler1968@xxxxxxxxxxxxxx> wrote: > > > > > > > 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. Sure. It's an IETF process. Not arguing about that. > > > 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. git diff might need another script :) Just like you did earlier with an old script that took this .rst and converted it to IETF suitable format. Now we'd need a new script that will take git diff with new header/footer and whatever extra words necessary. > > 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. It's all a matter of additional scripting. We're not going to ask every kernel developer to learn IETF process. People will be sending patches for instruction-set.rst and this file will keep evolving. As soon as we land Yonghong's patch it won't be 1-1 with RFC9669 and it's fine. Even today it's not 1-1 either. It needs to go through your existing script to fit IETF rules. The new patches will keep landing and the file will become a working document towards the next delta RFC. > > 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. Ok. Please send the patch. Will wait for that first.
