Subject: [Gen-art] Gen-ART LC review of draft-ietf-netmod-system-mgmt-10.txt

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Jan 2014 14:02:25 +1300

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?

"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.

"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.

"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?
(And I wonder what happens if the device is running mDNS?)

"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. 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.

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 12 Jan 2014 12:16:47 +0100 (CET)

Hi,

Thank you for this review.  Comments inline.

> I haven't checked the yang syntax in detail. At first glance,

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.

> the first time the document mentions clients.

See above.

> 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.

> 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?

> 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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jan 2014 07:51:43 +1300

Hi Martin,

I'm fine with your answers and proposed changes.

> 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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 12 Jan 2014 21:26:59 +0100 (CET)

> That means it would be quite legitimate to configure it with NETMOD.

Yes that is my understanding as well.

> receives conflicting config via DHCP and NETMOD? I guess you have a

Yes; so the YANG configuration data models is the "static" or "manual"
configuration.  Then there are all kinds of other mechanism that can
influence what the device is actually using, i.e., influence its
operational state.  DHCP is one example.  RA is another.  Exactly how
this dynamic influence of the operational state is done depends on the
mechanism, on the different parmeters, and maybe on local policy.
Sometimes the manually configured value has higher precedence,
sometimes the value received over DHCP, and sometimes the values may
be both be used.

> with somebody in the DNSSD WG though.

Ok.

/martin