7 and 8 are exact opposites. 7, i.e. {C, O, N}, says any registrar subject to this policy may choose to require the distinction, may make it optional for the registrant to provide it, or may choose not to ask the registrant at all. Thus, this puts no constraint on the registrar.
8, i.e. {}, is a red flag. It says no matter what the registrar does, it does not conform to this policy. The registrar is prohibited from collecting the data, is prohibited from making it optional, and is prohibited from not collecting it. This combination is included for logical completeness, but would not be an acceptable policy. See below for the reason for including this combination.
This set of possibilities exists within a larger context. Here are four aspects of the larger context.
- We presume the data element is defined. The existence of the data element in the data dictionary is distinct from any policy about whether it is or is not collected, whether it is or is not used in any decisions, and whether it or any other piece of data is disclosed. (We further expect the data dictionary is a publicly available structure available to and used by essentially all registration systems, i.e. throughout the address, ccTLD and gTLD communities.)
- A separate part of the model is the level of validation applied to the data. In SSAC report SAC 058, there are three levels defined, but there is also an implicit fourth level at the bottom of the scale. The four levels are:
- V0 = Accept whatever the registrant provides
- V1 = Check the registrant's input for syntactic conformance
- V2 = Check the registrant's input for plausible correctness
- V3 = Apply very strong checks to ensure the registrant's input is verifiably correct
In parallel with what I've described for collection, each registrar will have its own rule for the degree of validation, and GNSO will have its rule for what possibilities are permitted for registrars subject to its policy. For example, if the GNSO policy is V3, then every registrar would have to apply very strong checks on the data. On the other hand, if the GNSO policy is {V0, V1, V2, V3}, each registrar would be free to set its own rule for the degree of validation. (This aspect addresses part of what Stephanie has been talking about, though I think she is saying that without a uniform level of validation, it's inappropriate to use the data.)
- A given registrar will usually be subject to multiple rules. In addition to whatever ICANN imposes, the registry may have a rule, and one or more governments may have a rule. Thus, a registrar's rule will have to conform to all of these.
If the rules are presented in the form I've suggested, it's easy to see how they all interact. And it's possible for these multiple rules to be inconsistent with each other. For example, if ICANN says it's ok to offer to the registrant the option of providing the data but it is not ok to require it, i.e. Optional, but the government says it's mandatory to collect the data, then the registrar is stuck. If the registrar requires it, they would not be compliant with ICANN, and if they don't require it, they would not be compliant with the government.
If you take two rules and compute the set intersection, i.e. the list that is common to both, you'll get the maximum set of possibilities. In the example above, the result will be the empty set, i.e. the eighth possibility I listed, and this would indicate an impossible position for the registrar.
- All of the above is distinct from whether this data is used for decisions and whether it or any other data is disclosed. That's a separate part of the model and requires a bit more explanation. I'll leave this for another time.