All, Here are some questions / comments from the Broadband Forum on RFC 6087bis-05.
Thanks, William -------- 1. Potentially confusing use of the term "prefix" Section 5.1 (Module Naming Conventions) talks about prefixes but in this context means "strings at the beginning of module names" rather than YANG prefixes that are the topic of Section 5.2. This could (and did!) cause confusion. 2. Rules re changing submodule names Section 5.7 (Lifecycle Management) says that "The [...] submodule name MUST NOT be changed, once the document containing the module or submodule is published" but this might contradict RFC 6020 Section 11, which says "A module may be split into a set of submodules, or a submodule may be removed...". More specifically, 6020 doesn't mention renaming a submodule (so presumably that's not permitted), but the mention of both splitting modules into submodules AND removing submodules suggests that arbitrary module/submodule refactoring is permitted. And if I'm being pedantic, revision #1 could have submodule A1, revision #2 could remove it, and revision #3 could reintroduce it as submodule A2, so that's effectively a rename! 3. References to RPCs need also to mention actions In most (or all?) places that RPCs are mentioned, presumably actions need to be mentioned? 4. Implications of adding defaults Section 5.12 (Reusable Type Definitions) says that "If an appropriate default value can be associated with the desired semantics, then a default statement SHOULD be present". Is it correct that adding a default effectively adds a MANDATORY requirement for a server to support the default value for that node, and therefore to support the concept modelled by the node (albeit only with the default behaviour)? Whereas if there were no default then there would be no requirement at all to support the concept modelled by that node? If so, then adding a default seems like something that shouldn't be done lightly... or am I making too much of this? 5. Guidance re YANG features 6087 doesn't always refer to features consistently. For example Section 5.5 (Conditional Statements) says "If a data definition is optional, depending on server support for a NETCONF protocol capability, then a YANG 'feature' statement SHOULD be defined" (which seems to tie the "feature" concept to NETCONF protocol capabilities), whereas Section 5.17 (Feature Definitions) says "The YANG "feature" statement is used to define a label for a set of optional functionality within a module". The latter description seems more in keeping with the spirit of 6020, so perhaps the former text could be adjusted to align with it? 6. Guidance re YANG deviations The 6020 discussion of deviations is mostly about implementing LESS rather than MORE. Obviously the deviate statement's "add" argument is described (and there is an example) but there seems to be no discussion that use of deviate with "add" might be a GOOD thing. The 6087 discussion of deviations says that they can be useful for documenting server capabilities but again the emphasis seems to be on documenting implementing LESS rather than MORE. The result seems to be that deviations have a bad name. If indeed there are accepted good uses of deviations then it would be good if this was made clearer, both in 6020 and in 6087. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
