Change:
This rephrases the "Evaluating an Identifier" section (3.3) to refer to identifier types, rather than identifiers. We now draw the distinction between the type of an identifier, and an identifier itself, to avoid ambiguity. Fixes Issue
I'd appreciate it if a reviewer could go over the surrounding text to make sure the distinction is obvious, and we're not misusing the 'type' term.
A reviewer writes, I think we should rewrite this section to be about evaluating types of identifiers or sources of identifiers.
Agreed. It's ambiguous as to whether we're describe how to evaluate equals , or whether we're talking about the types (ip vs ethernet)
Not yet sure this is is all that's needed, but on its own it's clarifying I think.

Discussion:
3.3. <del> To evaluate whether an identifier is appropriate, one should consider every recommended property from the perspective of interactions among the components in the architecture.  When comparing identifiers, choose the one which best satisfies all of the recommended properties.  The architecture does not provide an exact measure of how well an identifier satisfies a given property; care should be taken in performing the evaluation. </del> <ins> To evaluate whether a type of identifier is appropriate, one should consider every recommended property from the perspective of interactions among the components in the architecture.  When comparing identifier types, choose the one which best satisfies all of the recommended properties.  The architecture does not provide an exact measure of how well an identifier type satisfies a given property; care should be taken in performing the evaluation. </ins> 3.4. <del> This section provides some examples of identifiers, along with some evaluation of whether they are good identifiers.  The list of identifiers is not exhaustive.  Other identifiers may be used.  An important point to note is that whether the identifiers are good depends heavily on the capabilities of the components and where in the network the components exist. </del> <ins> This section provides some example identifier types, along with some evaluation of whether they are suitable types.  The list of identifier types is not exhaustive.  Other types may be used.  An important point to note is that whether a given identifier type is suitable depends heavily on the capabilities of the components and where in the network the components exist. </ins> 3.4.1. The physical interface by which the User Equipment is attached to the network can be used to identify the User Equipment.  This identifier <del> has the property of being extremely difficult to spoof: the User </del> <ins> type has the property of being extremely difficult to spoof: the User </ins> Equipment is unaware of the property; one User Equipment cannot manipulate its interactions to appear as though it is another. Further, if only a single User Equipment is attached to a given physical interface, then the identifier will be unique.  If multiple User Equipment is attached to the network on the same physical <del> interface, then this property is not appropriate. </del> <ins> interface, then this type is not appropriate. </ins> Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and

3.4.2. <del> A natural identifier to consider is the IP address of the User </del> <ins> A natural identifier type to consider is the IP address of the User </ins> Equipment.  At any given time, no device on the network can have the same IP address without causing the network to malfunction, so it is appropriate from the perspective of uniqueness.