Hi Martin, I'm fine with your answers and proposed changes.
> 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? I think that's the main point, but RFC6762 does say this: "The ".local." suffix could appear in the search list because the user manually configured it, or because it was received via DHCP [RFC2132] or via any other mechanism for configuring the DNS search list." That means it would be quite legitimate to configure it with NETMOD. So probably you can ignore my comment ;-). (There's also a more general question: what does the host do if it receives conflicting config via DHCP and NETMOD? I guess you have a general answer to that.) > Or are you suggesting that this model should support configuration of > mDNS as well? As far as I know, mDNS is intended to be a zero-configuration mechanism, so I think the answer is "No". It might be worth checking with somebody in the DNSSD WG though. Regards Brian On 13/01/2014 00:16, Martin Bjorklund wrote: > 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
