The RFC number will be provided upon submission.
A short, descriptive title of what is being proposed.
A brief description of the proposed change.
Provide at least one of the following labels:
- [MODIFICATION] - modifies an existing PMIx definition (API, key string, etc.)
- [EXTENSION] - adds a new PMIx definition
- [BEHAVIOR] - modifies the underlying behavior of an existing PMIx function
- [ORGANIZATION] - changes the organization of the existing files, perhaps moving files across directories
- [CLIENT-API] - modifies/extends the client-side API
- [SERVER-API] - modifies/extends the server-side API
- [RM-INTERFACE] - modifies/extends the interface to the host resource manager
While it is permissible to combine these labels in a single RFC, best practices are to separate such operations into individual RFCs. For example, it is requested that authors separate modifications from extensions to avoid confusion. Where this is not logically possible (e.g., an extension that requires an accompanying change in the behavior of an existing PMIx function), then all applicable labels shall be provided.
The RFC administrators will mark the RFC with one of the following labels, along with the date of the indicated action:
- [APPROVED] - upon final approval of the RFC. This will include the date the RFC was accepted, the date the code PR was committed to the master, and the commit SHA.
- [WITHDRAWN] - proposal has been withdrawn from consideration. This typically will be done when alternative proposals yield a preferred solution.
- [REJECTED] - community decided not to commit the proposed changes.
This document is subject to all provisions relating to code contributions to the PMIx community as defined in the community's LICENSE file. Code Components extracted from this document must include the License text as described in that file.
A detailed description of the proposed change. The length and degree of detail should be commensurate with the magnitude of the change. This is not intended to be burdensome, nor are there any awards for verbosity - but clear communication will avoid repeated requests for alterations. The description should indicate what is being modified, both functionally and by file name.
Provide a reference link to the accompanying Pull Request (PR) against the PMIx master repository. If the prototype implementation has been tested against an appropriately modified resource manager and/or client program, then references to those prototypes should be provided. Note that approval of any RFC will be far more likely to happen if such validation has been performed!
Provide a list of authors, including contact info. This can be in the form of email address or Github ID.