Open mamali68 opened 1 month ago
In the first example the identity qam-256 is the base for tow values and therefore it (the base) should not act as a value itself. Call it "best practice" in case this is not explicit mention in RFC7950. There are examples like ietf-alarms.
Question: Is the identity "qam-256-base" really needed - if not:
[...]
identity qam-256 {
base coding-modulation;
description
"256 QAM coding and modulation scheme.";
}
identity qam-256-strong {
base coding-modulation;
description
"256 QAM strong coding and modulation scheme.";
}
identity qam-256-light {
base coding-modulation;
description
"256 QAM light coding and modulation scheme.";
}
[...]
When an identityref is defined, any identity derived from the specified base is valid (and the derivation of identities is transitive, as described in RFC 7950)
Considering your example:
identity coding-modulation {
description
"The coding and modulation schemes.";
}
[...]
identity qam-256 {
base coding-modulation;
description
"256 QAM coding and modulation scheme.";
}
identity qam-256-strong {
base qam-256;
description
"256 QAM strong coding and modulation scheme.";
}
identity qam-256-light {
base qam-256;
description
"256 QAM light coding and modulation scheme.";
}
The values qam-256, qam-256-strong and qam-256-light are valid for the following identityref:
type identityref {
base "coding-modulation";
}
However, only the values qam-256-strong and qam-256-light (and not the value qam-256) are valid for the following identityref:
type identityref {
base "qam-256";
}
it is unclear based on definition and syntax restrictions of base statement (RFC7950 Chapter 9.10.2 and RFC6020 Chapter 7.16) if an identity that is based on another identity and which is base of other derived identities is a valid value.
Example: in module ietf-microwave-types
in this case is identity qam-256 a valid value? If not the proposal is to add a base identity to each modulation and have the generic and variation modulations derived from this. example: