On 12/05/2017 10:06 PM, Eric Voit (evoit) wrote:
Hi Martin,
Several comments on the YANG model within rfc7223bis.
list interface {
key "name";
description
"The list of interfaces on the device. The status of an interface
is available in this list in the
operational state...
A few questions on this.
(a) The description of the list defines behaviors of various list nodes which
might or might not exist in different NMDA datastores. It also suggests when
certain elements should be populated in various datastores. Is the precedence
being set that datastore specific behaviors may be placed into descriptions?
Is this type of documentation guidance something which explored in
draft-dsdt-nmda-guidelines?
(b) Does status mean 'admin-status', 'oper-status' or both? (I think
'oper-status'.)
(c) should quotes be used around status?
leaf name {, leaf type { ....
There are NETCONF specific behaviors in the definition of these two leaves.
It would be great to have this transport agnostic. I realize that such a
transport segmentation dissociates transport error handling from the nodes
being handled.
leaf admin-status {...
incorrectly marked as config false;
I think config false; is correct. The 'admin-status' leaf is a pre-NMDA
workaround for IF-MIB implementations that coexist with the
ietf-interfaces implementation e.g. reflect the value of ifAdminStatus
independently configurable of the /interfaces/interface/enabled value.
This is described in the description statement of
/interfaces/interface/enabled.
This potentially could also be accomplished by using NMDA origin meta
notation in operational showing /interfaces/interface/enabled is
overwritten by origin that is not 'intended' e.g. or:origin=or:system or
maybe custom origin or:origin=or-snmp:snmp?
IMO 'admin-status' is a too broad name for something that is only if-mib
relevant. This is an example of something that can be solved with NMDA
in a more general way without clogging the model with additional leaf
but for backward compatibility and to avoid unnecessary confusion should
be kept the way it is in draft-ietf-netmod-rfc7223bis-00.
Vladimir
Thanks,
Eric
-----邮件原件-----
发件人: netmod [mailto:[email protected]] 代表 Kent Watsen
发送时间: 2017年11月29日 3:29
收件人: [email protected]
抄送: [email protected]
主题: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00
All,
This starts a two-week working group last call on draft-ietf-netmod-
rfc7223bis-00.
Please recall that this update's intention is to modify the YANG module to
be in line with the NMDA guidelines [1]. Reviewing the diff between the
two drafts [2] should reveal just this.
The working group last call ends on December 12.
Please send your comments to the netmod mailing list.
Positive comments, e.g., "I've reviewed this document and believe it is
ready for publication", are welcome!
This is useful and important, even from authors.
[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2]
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.tx
t
Thank you,
Netmod Chairs
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
