Hi all,
Section 4.3.1 of draft-ietf-netmod-rfc8407bis-24 says:
List identifiers SHOULD be singular with the surrounding container name plural.
Similarly, "leaf-list" identifiers SHOULD be singular.
This guideline seems valuable and reasonable in most of the cases but I have
see a couple of similar exceptions which, IMHO, are worth considering
The issue is about cases where the list entry represents a set of parameters.
For example in draft-ietf-ccamp-optical-impairment-topology-yang-18 we have the
following list:
+--ro roadm-path-impairments
| +--ro roadm-path-impairment* [roadm-path-impairments-id]
| +--ro roadm-path-impairments-id string
The singular name for the list is a bit misleading since each entry represents
a set of optical impairments parameters (e.g., CD, PMD, PDL).
The authors of this I-D have just spotted this issue when discussing how to
address a YANG doctor review comment on the plural name used to reference an
entry in this list:
+--ro roadm-path-impairments? leafref
While checking, I have noted that a similar issue applies to
draft-ietf-teas-yang-te-37 and draft-ietf-teas-yang-path-computation-24:
+--ro computed-paths-properties
| +--ro computed-path-properties* [k-index]
What is the suggestion from Netmod WG?
I can see few options:
1. Keep the models as they are as corner-case exceptions to the SHOULD rules
in draft-ietf-netmod-rfc8407bis
2. Align the approach used by the two models to comply with the SHOULD rules
in draft-ietf-netmod-rfc8407bis on the "path" part of the identifiers (rename
as roadm-paths-impairments/ roadm-path-impairments, following the same approach
used for computed-paths-properties/computed-path-properties convention)
3. Rename as impairments-of-roadm-paths/impairments-of-roadm-path and
properties-of-computed-paths/properties-of-computed-path
4. Use a -sets/-set suffix (rename as
roadm-path-impairments-sets/roadm-path-impairments-set and
computed-path-properties-sets/computed-path-properties-set)
5. Others?
Do you think it is worthwhile updating the text in draft-ietf-netmod-rfc8407bis
to cover these corner cases or address them as special and motivated exceptions?
Thanks, Italo
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
