On 07/09/2017 22:23, Juergen Schoenwaelder wrote:
On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote:
I suggested the naming guideline because the NMDA design team decided to
add semantics to certain naming patterns, so authors have to be warned.
But this is a really bad idea (and slippery slope).
I agree.
I think that there are really a few aspects to this:
1)I think that it is a good goal to try and achieve a consistent style
across the IETF YANG modules. This helps both readers and
implementors. E.g. sticking child "config" and "state" containers in
the tree in a similar style to OpenConfig may be in-congruent with how
with how most IETF YANG modules are written.
2) I think that is also some common sense guidance here, which is to
avoid using node names that may prevent a module for being sensibly
updated in future. Hence I think that names that related to the scope
of the data (e.g. "state", "*-state", "config", and "*-config") should
generally be avoided, because it is possible that the scope of that data
may change. Something that is only operational state in a standard
model may become configurable by a future revision, or perhaps via
vendor deviation.
3) The top level "*-state" containers seems to be an undocumented
historical rule in the context of the pre NMDA IETF YANG modules. Hence,
advising people not to create top level containers called "-state" also
seems to help avoid a potential source of confusion.
I don't know if these are necessarily rules, or just common sense. I
don't know whether this guidance needs to be documented in rfc6087bis.
My view is that it would probably be helpful.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
