RFC Template

[marcastel]

RFC #(number)	(RFC title goes here)
Category	Experimental/_Informational
Status	Draft
Maintainers	Primary persons of contact for this RFCs lifecycle management

1. Summary
   • Glossary
   • See also
2. Motivation
3. Detailed design
   • Technical Background
   • Implementation
4. How we teach this
5. Drawbacks
6. Alternatives
7. Unresolved questions

Summary

One paragraph explanation of the feature.

Glossary

Please provide a glossary of all specialised or non-commonly used terms such that readers of all origins and culture will have
a common understanding of the RFC's content.

See also

Provide here all necessary bookmarks that pertain to the topic(s) discussed in this RFC. In particular direct access to online
source code, issues, wikis, related discussions, and so on.

Motivation

Why are we doing this? What use cases does it support?

Please provide specific examples. If you say «\ this would be more flexible\ » then give an example of something that
becomes easier. If you say «\ this would be make it easier to do X\ » then give an example of what that looks like today and
what's hard about it.

Don't assume that others recognise the problem is one that needs to be solved. Is there some concrete issue you cannot
accomplish without this? What does it look like to accomplish some set of goals today and how could that be improved? Are there
any workarounds that are necessary today? Are there open issues on Github where people would be helped by this? Will the change
> have performance impacts? Can you quantify them?

Please focus on explaining the motivation for this RFC. Should it not be accepted, the motivation could be used to develop
alternative solutions. In other words, > enumerate the constraints you are trying to solve without coupling them too closely to
the solution you have in mind..

Detailed design

Technical Background

There are a lot of ways AIT is used. It is essentiall a secured environment to do what you please with your servers. Further,
it's was originally conceived, back in the late 80s, to work on all flavours of UNIX. No one person knows everything about all
the ways AIT is used. What does someone who knows about AIT but hasn't necessarily used anything outside of it need to know? Are
there docs you can share?

How does this RFC's proposal impact the AIT ecosystem? We can take design inspiration from others who have done this well and
improve upon the designs or make them better fit AIT.

Implementation

Explain the design in enough detail for somebody familiar with the AIT framework to understand, and for somebody familiar with
the implementation to implement. Remember that any new terminology should have beend defined earlier in the glossary.

Explain not just the final design, but also how you arrived at it. What constraints did you face? Are there corner cases you've
come up with solutions for?

Explain how your design fits into the larger picture. Are the other open problems in this area you're familiar with? How does
this design fit with potential solutions for those issues?

Connect your design to the motivations you listed above. When describing a part of the design, it can be useful to share an
example of what it would look like to utilize the implementation as solution to the problem.

How we teach this

What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing
AIT patterns, or as a wholly new one?

Would the acceptance of this proposal mean the AIT guides must be re-organized or altered? Does it change how AIT is taught to
new users at any level?

How should this feature be introduced and taught to existing AIT users?

Drawbacks

Why should we not do this? Please consider the impact on teaching AIT, on the integration of this feature with other existing
and planned features, on the impact of the API churn on existing apps, etc.

There are tradeoffs to choosing any path, please attempt to identify them here.

Alternatives

What other designs have been considered? What is the impact of not doing this?

This section could also include prior art, that is, how other frameworks in the same domain have solved this problem
differently.

Unresolved questions

Optional, but suggested for first drafts. What parts of the design are still TBD?