One concern raised is the assignment of values for types and feature bits. To reduce collisions in the wild, Laolu suggests announcing on the list before running an experiment with a new feature bit. He also notes that the authors of "RGB" have never posted about their experimental feature bit on the list. The issue of requiring centralized number assignment can be avoided by using a unique identifier for the feature, such as a hash of the feature name.To address these concerns, a rough draft of the idea for experimental features protocol has been shared. This protocol is intended for testing protocol features that are not necessarily intended to become standard BOLTs. By moving all experimental features to a new message where they are wrapped in a unique feature name, this eradicates the chance of conflicting implementations. The proposed experimental features protocol includes Lightning base protocol messages, general experiment messages, and an overview. The experiment message has a unique ID for each feature supported. A sending node must send the init_experiments message before any other experiment message for each connection. The receiving node should enable the feature for communication with this peer. The email thread also discusses the proposal for having LIPs (Lightning Network Improvement proposals) placed on github.com/lightning account in a repo called lips until they can be moved into the lightning rfc repo, which is similar to Bitcoin Improvement Proposals (BIPs). René Pickhardt created a draft for LIP-0001, describing the process and influenced by BIP-0002 on his Github repo. The purpose of this proposal is to provide a central place to collect future enhancements for BOLT 1.1, as many ideas are distributed within the community. However, Olaoluwa Osuntokun questions the need for another repository, stating that we already have the equivalent of improvement proposals in BOLTs. Historically, new standardization documents are proposed initially as issues or PRs when ultimately accepted.Lastly, the context includes some TODOs, including defining gossip/query messages related to nodes/channels that support features by experiment_hash_name. Overall, the email thread discusses various concerns and proposals for improving the process of creating/modifying/drafting BOLT documents, including addressing collisions in feature bit assignments, proposing an experimental features protocol, and suggesting a central repository for collecting future enhancements for BOLT 1.1.