All, I didn't see any follow-up to these questions / comments. Any thoughts?
Thanks, William > On 11 Dec 2015, at 12:54, William Lupton <wlup...@broadband-forum.org> wrote: > > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
