@sergio-mena , maybe I have not a clear understanding, but let's say a chain is just starting and wants to have vote extensions, but the default value here is 0. Should we not say something like - we have to set this to at least 1? Because someone starting from scratch with a version of the software having extensions enabled, might assume they are enabled by default?

Good point.
First, I realize we're not mentioning that the ConsensusParam can be set at genesis. So, typically, for chains starting from scratch and having vote extensions from their app's first version, they just need to set VoteExtensionsEnableHeight to 1 at genesis and forget about the upgrade path. We need to say this somewhere in the spec.
Second, to your question. We (our team) discussed about the default value at genesis last spring in some PR (I'll try to pull it up). I remember thinking default value at genesis should be 1, but then people convincing me that 0 is better. Now, when I think of it, it makes total sense to me that the default value is zero, for compatibility with existing genesis docs.
Let me know if you're still unclear in some aspect.

they just need to set VoteExtensionsEnableHeight to 1

actually, to be precise, they need to set it to their InitialHeight parameter

Yes, I know and agree it should be 0 by default. But as you said, I think we should state it that, if they do want vote extensions they have to change it, they will not magically be turned on. Of course, it can be deducted from the spec, but I think it's better to be clear on this as people might just skim through some parts of the spec.

I'll try to pull it up

Here it is (took some time :-) )

Agreed.

Just make sure it's clear that there are two ways of enabling vote extensions for new chains:

• Via app's logic at InitChain, by changing the ConsensusParam
• Via setting it to InitialHeight in the genesis. This way, the app does not need to do anything to have extensions enabled from the very beginning.

BTW, this distinction also applies to other parts of CometBFT's state, such as validator updates.

Good point.
First, I realize we're not mentioning that the ConsensusParam can be set at genesis. So, typically, for chains starting from scratch and having vote extensions from their app's first version, they just need to set VoteExtensionsEnableHeight to 1 at genesis and forget about the upgrade path. We need to say this somewhere in the spec.
Second, to your question. We (our team) discussed about the default value at genesis last spring in some PR (I'll try to pull it up). I remember thinking default value at genesis should be 1, but then people convincing me that 0 is better. Now, when I think of it, it makes total sense to me that the default value is zero, for compatibility with existing genesis docs.
Let me know if you're still unclear in some aspect.

This helps navigating he document, but for anyone reading on GitHub, which I expect to be the norm, you can now see an auto generated outline. Just something to think about going forward when writing specs, RFC and ADR.

I suggested to add a TOC, because I didn't realize GH has one. I managed to find it in the left-hand side of the view:

Thanks for highlighting that Lasaro! I still think having the TOC directly in the file does not hurt.

something to think about going forward when writing specs, RFC and ADR.

Agree. We might want to have a consistent approach. Good discussion to have internally another time.