Formalize ID Format

[eddie-knight]

A suggestion from @TheFoxAtWork is to consider incorporating the category into the ID.

overall this looks fine and it makes sense to reorganize. Perhaps it may be beneficial to alter the numbering scheme to reflect the category?
OSPS-AC-1.1
OSPS-AC-1.2
OSPS-AC-1.3
OSPS-AC-2.1
OSPS-AC-2.2

in doing this method, it allows for sorting by category. the numerical value also indicates the level and component under that level we're referring to. further, we can continue to add criteria for any we miss without having to rework criteria numbering and reorganization. this means in the event new categories need added, we have a schema for them.

#34 (review)

[TheFoxAtWork]

I would like to upvote this suggestion to save our future selves a lot of headache.

[david-a-wheeler]

I recommend NOT using numbers for ids at ALL. Instead, use short names. Numbers have no intrinsic meaning, and using number ranges will mess up everything if a category overflows. Using simple names makes everything MUCH MUCH easier to follow.

E.g., instead of OSPS-01 use OSPS-MFA or similar.

[TheFoxAtWork]

Also perfectly acceptable so long as we don't have to recategorize these if we need to add or remove them.

[eddie-knight]

@david-a-wheeler and @SecurityCRob have agreed to suggest some alternative formats.

[funnelfiasco]

Another reason to go with descriptive IDs instead of numerical: we've changed the level of some requirements without renumbering them (e.g. #51). So if we don't switch to descriptive IDs (which I think is probably better, but may be challenging), we may just want to have the numerical IDs be sequential like RFCs or PEPs.

[drusso-rh]

(Redirected from PR 72)
FWIW I agree that there is value in having a unique ID for each requirement. Many frameworks and guidance docs do this, and it is invaluable when mapping/cross-walking these artifacts with an organization's internal requirements.