[Bpf] Instruction set extension policy

[Dave Thaler <dthaler=40microsoft.com@xxxxxxxxxxxxxx>]

The charter for the newly formed IETF BPF WG includes:

“The BPF working group is initially tasked with … creating a clear process for extensions, …”

 

I wanted to kick off a discussion of this topic in preparation for discussion
at IETF 117.

 

Once the BPF ISA is published in an RFC, we expect more instructions may be
added over time.  It seems undesirable to delay use such additions until

another RFC can be published, although having them appear in an RFC
would be a good thing in my view.

 

Personally, I envision such additions to appear in an RFC per extension

(i.e., set of additions) rather than obsoleting the original ISA RFC.  So
I would propose the ability to reference another document (e.g., one
in the Linux kernel tree) in the meantime.

 

For comparison, the IANA registry for URI schemes at
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
defines status values for “Permanent” and “Provisional” with different
registration policies for each of those two statuses.

 

Similarly, I would propose as a strawman using an IANA registry (as most
IETF standards do) that requires say an IETF Standards Track RFC for

“Permanent” status, and “Specification required” (a public specification
reviewed by a designated expert) for “Provisional” registrations.
So updating a document in say the Linux kernel tree would be sufficient
for Provisional registration, and the status of an instruction would change
to Permanent once it appears in an RFC.

 

Thoughts?

 

Dave

-- 
Bpf mailing list
Bpf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/bpf