Hi, Thank you for this review. Comments inline.
Brian E Carpenter <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-netmod-system-mgmt-10.txt > Reviewer: Brian Carpenter > Review Date: 2014-01-12 > IETF LC End Date: 2014-01-22 > IESG Telechat date: > > Summary: Almost ready > -------- > > Comments: > --------- > > I haven't checked the yang syntax in detail. At first glance, > it looks good. > > Minor Issues: > ------------ > > "2.1. System Identification > > There are many common properties used to identify devices, operating > systems, software versions, etc. that need to be supported in the > system data module. These objects are defined as operational state > data and the information returned by the server is intended to be > specific to the device vendor." > > Does "server" mean the NETCONF server? Yes. We usually include the text below in the Terminology section, and we should do that in this document as well. We missed it. The following terms are defined in [RFC6241] and are not redefined here: o client o configuration data o server o state data I will add this text. > "2.2. System Time Management > > The management of the date and time used by the system need to be > supported. Use of one or more NTP servers to automatically set the > system date and time need to be possible. Utilization of the > Timezone database [RFC6557] also need to be supported. It should be > possible for the server, as well as clients, to configure the system > to use NTP." > > Again, does this mean the NETCONF server? Also, which clients? This is > the first time the document mentions clients. See above. > "2.3. User Authentication > > ...It should be possible for the server, as well as > clients, to configure the system authentication properties." > > Same comment as for 2.2. Also, how does the network administrator enforce > a specific strength of authentication? It seems as though the clients can > choose to downgrade security. I agree that this sounds a bit weird - servers do not configure anything spontaneously. Clients can not in general choose to downgrade security. It simply means that the data model should make it possible to configure user authentication. Access control must be used to control which clients are authorized to do so. NEW: It should be possible for clients to configure the system authentication properties. > "2.4. DNS Resolver > > The configuration of the DNS resolver within the system containing > the NETCONF server is required to control how domain names are > resolved." > > This is very hard to parse and could mean several things. Does it > mean that it MUST be possible to configure the DNS resolver? Note that this is the "Objectives" section. It means that an objective is that the data model should allow for dns resolver configuration. Would it be more clear to say The configuration of the DNS resolver within the system containing the NETCONF server is required in order to control how domain names are resolved. > (And I wonder what happens if the device is running mDNS?) Hmm, AFAICT, no special config is needed for mDNS to work? So if the device supports mDNS, it will be used for .local. names, right? Or are you suggesting that this model should support configuration of mDNS as well? > "3.6. System Control > > The following operations are defined: > > set-current-datetime > system-restart > system-shutdown" > > My reaction is that this is a very limited set of operations. Yes. We tried to come up with a useful limited set of operations (and config / oper data) that can be implemented on almost all devices. > For example > how about system standby (enter power-saving mode)? Yes, I know that > creates the problem of how to wake the system up again, but there are > solutions to that problem (e.g. polling). I can imagine many vendor-specific > extensions in this area, too. There are probably lots of other operations that can be useful. However, we need to start somewhere, and more operations can be added over time. In general, we expect vendor-specific extensions to both the supported set of operations, and the config and oper data. /martin _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
