Dave Thaler <dthaler=40microsoft.com@xxxxxxxxxxxxxx> wrote:
> 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.
agreed.
> 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.
That seems like a really good plan.
They won't have to be long documents either.
It would be nice if there could be sufficient template so that they don't
need a lot of cross-area review to publish.
There is also a thought that there is simply a "yearly" wrap up of all
allocations.
> 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?
I think it important to distinguish for the group between
experimental/private-use space and provisional.
I don't think you want to renumber an instruction when it goes to Permanent
status. I also think that you want to run this as Early Allocations, so that
they have a sunset clause, and the process for sunsetting such an allocation
should be clear.
You may also need to written policy (in the Linux kernel Documentation) about
back-patching of Provisional numbers into vendor branches and/or LTS
branches.
Can there be subtle semantic changes to Provisional allocations?
(Such as what happens when invalid data occurs? The divide-by-zero
equivalent)
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
-- Bpf mailing list Bpf@xxxxxxxx https://www.ietf.org/mailman/listinfo/bpf
