Re: [Bpf] Instruction set extension policy

[Michael Richardson <mcr+ietf@sandelman.ca>]

[-- Attachment #1.1: Type: text/plain, Size: 2307 bytes --]


Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org> 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@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide





[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

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