Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Jan 17, 2012 at 12:44:57AM -0800, Christopher LILJENSTOLPE wrote:
> Greetings all,
> 
> 	This is a WGLC for  WGLC draft-ietf-opsawg-management-stds-03.  The call will be open until 00:01 UTC on 24 January.  Please register your support or disagreement as soon as possible.
> 

I have reviewed <draft-ietf-opsawg-management-stds-03> and below are
my technical comments. (There are a number of editorial issues like
missing articles, or singular/plural mismatches, or stylistic things
like sentences starting with [RFCxxxx] that I am too lazy to write
down.) Below, I am quoting parts of the document and I am providing
concrete suggestions in order to make my points hopefully clear enough
and actionable.

a) The definition of MIB can probably be improved. Note that there is
   a separate definition of a MIB module - so the second sentence can
   be moved.

   OLD:

   o  Management Information Base (MIB): An information repository with
      related collection of objects that represent an aggregation of
      resources to be managed.  MIB modules are defined by using the
      modeling language SMI.

   NEW:

   o  Management Information Base (MIB): An information repository with
      a collection of related objects that represent the resources to 
      be managed.

b) The definition of MIB module can probably be improved. I suggest to align
   with the definition found in RFC 3410 section 6.2.

   OLD:

   o  MIB module: A MIB definition, typically for a particular network
      technology feature, that constitutes a subtree in an object
      identifier tree.  A MIB that is provided by a management agent is
      typically composed of multiple instantiated MIB modules.

   NEW:

   o  MIB module: MIB modules usually contain object definitions, may
      contain definitions of event notifications, and sometimes include
      compliance statements in terms of appropriate object and event
      notification groups.  MIB modules are defined by using the
      data modeling language SMI. A MIB that is provided by a management
      agent is typically composed of multiple instantiated MIB modules.

c) I suggest to remove this definition:

   o  Trap: An unsolicited message sent by an agent to a management
      station to notify an unusual event.

   The reason is that we generally talk about notifications and the
   term does not show up many times in the document (and in some cases
   this should really be notification or it is text specific to SNMP
   protocol operations. Or replace it with this:

   o  Notification: An unsolicited message sent by an agent to a
      management station to notify an unusual event.

d) Use [STD58]? The old text is inconsistent in the way it refers to
   STDs or RFCs. Note also that STD58 comprises three RFCs not two.

   OLD:

   As such following standards build up the basis of the current SNMP
   Management Framework:

   o  SNMPv3 protocol [STD62],

   o  the modeling language SMIv2 [RFC2578][RFC2579], and

   NEW:

   As such following standards build up the basis of the current SNMP
   Management Framework:

   o  SNMPv3 protocol [STD62],

   o  the modeling language SMIv2 [STD58], and

e) This text can probably go without loosing anything important for
   the target audience (but if people believe this is important...)

   OLD:

   The SNMPv3 Framework extends the architectural principles of SNMPv1
   and SNMPv2 by:

   o  building on these three basic architectural components, in some
      cases incorporating them from the SNMPv2 Framework by reference,
      and

   o  by using the same layering principles in the definition of new
      capabilities in the security and administration portion of the
      architecture.

   NEW:

f) This is technically wrong: The Trap PDU has been in SNMPv1 and the
   Inform is another PDU, not another message.

   OLD:

   SNMPv2 enhances this basic functionality with a Trap PDU, an Inform
   message, [...]

   NEW:

   SNMPv2 enhances this basic functionality with an Inform PDU, [...]

g) SNMPv3 is STD since a looong time. And a STD reference to refer to
   a Proposed Standard also sounds wrong.

   OLD:

   offers sufficient security features.  To address the security
   deficiencies of SNMPv1/v2, SNMPv3 was issued as a set of Proposed
   Standards (see [STD62]).


   NEW:

   offers sufficient security features.  To address the security
   deficiencies of SNMPv1/v2, SNMPv3 was issued (see [STD62]).

h) This is wrong:

   OLD:

   is often used to poll basic parameter of a device (e.g. sysUpTime,
   which reports the time since the last reinitialization of the device)

   NEW:

   is often used to poll basic parameter of a device (e.g. sysUpTime,
   which reports the time since the last reinitialization of the
   network management portion of the device)

i) Terminology clarification. Note that YANG has statements, SMIv2 has
   macros.

   OLD:

   o  [STD58][RFC2579] defines common MIB "Textual Conventions",

   NEW:

   o  [STD58][RFC2579] defines the "Textual Conventions" macro for
      defining new types and it provides a core set of generally
      useful "Textual Convention" definitions

j) Remove unclear and unneeded reference to "this architecture".

   OLD

   Secondary threats against which SNMP Security Models within this
   architecture can provide protection are "message stream

   NEW: 

   Secondary threats against which SNMP Security Models 
   can provide protection are "message stream

   OLD: 

   There are two threats against which a Security Model within this
   architecture does not protect, since they are deemed to be of lesser

   NEW:

   There are two threats against which a Security Model 
   does not protect, since they are deemed to be of lesser


k) I fail to see why these are two different things. In particular,
   the example given in the first bullet seems to be a perfect fit for
   the second bullet. Here is a proposal for a shorter version:

   OLD:

   [...] An agent
   entity can restrict access to its MIB for a particular manager entity
   in two ways:

   o  The agent entity can restrict access to a certain portion of its
      MIB, e.g., an agent may restrict most manager principals to
      viewing performance-related statistics and allow only a single
      designated manager principal to view and update configuration
      parameters.

   o  The agent can limit the operations that a principal can use on
      that portion of the MIB.  E.g., a particular manager principal
      could be limited to read-only access to a portion of an agent's
      MIB.

   NEW:

   [...] An agent
   entity can restrict access to a certain portion of its MIB for a
   particular manager principal, an agent may restrict some manager
   principals to viewing performance-related statistics and allow only
   a single designated manager principal to view and update
   configuration parameters. Some other manager principals may not
   even be allowed to read the performance-related statistics.

l) I think this is wrong because my understanding is that there is a
   single community-based security model that is used by both SNMPv1
   and SNMPv2.

   OLD:

   The SNMP Transport Security Model [RFC5591] is an alternative to the
   existing SNMPv1 Security Model [RFC3584], the SNMPv2c Security Model
   [RFC3584], and the User-based Security Model [RFC3414].

   NEW:

   The SNMP Transport Security Model [RFC5591] is an alternative to the
   existing SNMPv1/SNMPv2 Community-based Security Model [RFC3584] and
   the User-based Security Model [RFC3414].

m) Why is this note here? Is it necessary to keep? Given that the SNMP
   text is long anyway, I suggest to remove the note.

   OLD:

   Note: Different IETF standards use security layers to address
   security threads (e.g.  TLS [RFC5246], Simple Authentication and
   Security Layer (SASL) [RFC4422], and SSH [RFC4251]).  Diverse
   management interfaces from IETF use a secure transport layer to
   provide secure information and message exchange to build management
   applications, e.g.  SYSLOG [RFC5424], IPFIX [RFC5101] and NETCONF
   [RFC4741].

   NEW:

n) I suggest to put the following text into a more consistent order.
   This idea is to first say what SYSLOG is and then start talking
   about the BSD origin instead of switching focus every other
   paragraph.

   OLD:

   The body of an BSD SYSLOG message has traditionally been unstructured
   text.  This content is human-friendly, but difficult to parse for
   applications.  The content of BSD SYSLOG messages correlate across
   vendors and with other event reporting such as SNMP traps.

   The SYSLOG protocol enables a machine to send system log messages
   across networks to event message collectors.  The protocol is simply
   designed to transport and distribute these event messages.  By
   default, no acknowledgements of the receipt are made, except the
   reliable delivery extensions specified in [RFC3195] are used.  The
   SYSLOG protocol and process does not require a stringent coordination
   between the transport sender and the receiver.  Indeed, the
   transmission of SYSLOG messages may be started on a device without a
   receiver being configured, or even actually physically present.
   Conversely, many devices will most likely be able to receive messages
   without explicit configuration or definitions.

   BSD SYSLOG had little uniformity for the message format and the
   content of SYSLOG messages.  The IETF has standardized a new message
   header format, including timestamp, hostname, application, and
   message ID, to improve filtering, interoperability and correlation
   between compliant implementations.

   NEW:

   The SYSLOG protocol enables a machine to send system log messages
   across networks to event message collectors.  The protocol is simply
   designed to transport and distribute these event messages.  By
   default, no acknowledgements of the receipt are made, except the
   reliable delivery extensions specified in [RFC3195] are used.  The
   SYSLOG protocol and process does not require a stringent coordination
   between the transport sender and the receiver.  Indeed, the
   transmission of SYSLOG messages may be started on a device without a
   receiver being configured, or even actually physically present.
   Conversely, many devices will most likely be able to receive messages
   without explicit configuration or definitions.

   BSD SYSLOG had little uniformity for the message format and the
   content of SYSLOG messages.  The body of an BSD SYSLOG message has
   traditionally been unstructured text.  This content is
   human-friendly, but difficult to parse for applications. The IETF
   has standardized a new message header format, including timestamp,
   hostname, application, and message ID, to improve filtering,
   interoperability and correlation between compliant implementations.

o) This seems to be wrong: RFC 5426 says "TLS transport [7] is
   REQUIRED to implement and RECOMMENDED for general use." Sure, it
   would be kind of stupid to implement SYSLOG without UDP support but
   the standard clearly says TLS.

   OLD:

   number of transport mappings.  However, for interoperability
   purposes, SYSLOG protocol implementers are required to support the
   transmission of SYSLOG Messages over UDP as defined in [RFC5426].

   NEW:

   number of transport mappings.  However, for interoperability
   purposes, SYSLOG protocol implementers are required to support the
   transmission of SYSLOG Messages over TLS as defined in [RFC5426].

p) I suggest to replace references to RFC4741 with RFC6241 and RFC4742
   with RFC6242 since these newer documents obsolete the former (and
   we generally can't cover the history of all protocols). This
   affects multiple places, please to a query replace. Similarly, I
   think this can go:

   OLD:

   The NETCONF working group updated the NETCONF base protocol standard
   as [RFC6241] and the SSH transport protocol mapping as [RFC6242].

   NEW:

q) Text can be updated since NACM meanwhile is in the RFC editor queue.

   OLD:

   At the time of this writing NETCONF Access Control Model (NACM) is
   being specified.  NACM proposes standard mechanisms to restrict
   protocol access to particular users with a pre-configured subset of
   operations and content.

   NEW:

   The NETCONF Access Control Model (NACM) [I-D.NACM] provides a
   standard mechanisms to restrict protocol access to particular users
   with a pre-configured subset of operations and content.

r) Fixing an editorial accident.

   OLD:

   DHCPv6 includes Prefix Delegation [RFC3633], which is used to
   provision a router with an IPv6 prefix for use in the DHCPv6 includes
   Prefix Delegation [RFC3633], which is used to provision a router with
   an IPv6 prefix for use in the subnetwork supported by the router.

   NEW:

   DHCPv6 includes Prefix Delegation [RFC3633], which is used to
   provision a router with an IPv6 prefix for use in the subnetwork
   supported by the router.

s) Wrong section reference

   OLD:

   IETF for the realization of management tasks and applications.  This
   subsection provides an overview of IETF data models with an FCAPS

   NEW:

   IETF for the realization of management tasks and applications.  
   Section 4.2 provides an overview of IETF data models with an FCAPS
 
t) Section 4.2 puts an emphasis on the standardization status since
   the text is structured into "Draft Standards" and "Proposed
   Standards" and sometimes "Full Standards". This leads to an odd
   structure since often various parts of a certain technology are at
   different levels and thus either can't be discussed together or we
   happen to see references to Proposed Standards in sections labeled
   Draft of Full Standard. Furthermore, given RFC 6410, some of the
   Draft Standards may change into Internet Standards or Proposed
   Standards within two years. So my recommendation would be to remove
   the structure and to mention the maturity level where it is useful,
   this is how the text is done for the rest of the document as well.
   On the other hand, if people insist on keeping the structure, you
   will have move around a number of things.

u) Be explicit since we had sysUpTime wrong already (it seems a fairly
   common misunderstanding).

   OLD:

   device is still operating, and sysUpTime can be used to detect if a
   system has rebooted, and counters have been reinitialized.

   NEW:

   device is still operating, and sysUpTime can be used to detect if 
   the network management portion of the system has restarted, and
   counters have been reinitialized.

v) Is this history of any use for the target audience? Note that RFC
   1229 was obsoleted in 1994, 18 years ago. I suggest to shrink this
   as follows:

   OLD:

   The Interfaces Group MIB [RFC2863] builds on MIB II [RFC1229] and is
   used as a primary MIB for managing and monitoring the status of
   network interfaces (e.g.  SNMP linkdown and linkup notifications).
   The 'interfaces' group in MIB II [RFC1229] defines a generic set of
   managed objects and provides the means for additional managed objects
   specific to particular types of network interfaces, such as Ethernet.
   Extensions to the 'interfaces' group for media-specific management
   can be defined based on these managed objects.  Experience with
   media-specific MIB modules has shown that the model defined by MIB-II
   is too simplistic and static for some types of media-specific
   management.  The Interfaces Group MIB incorporates the interfaces
   group extensions documented in MIB II and standardizes an evolution
   to this model as well as fills in the detected gaps.

   NEW:

   The Interfaces Group MIB [RFC2863] defines a generic set of managed
   objects for network interfaces and it provides the infrastructure
   for additional managed objects specific to particular types of
   network interfaces, such as Ethernet.

w) There are more SNMP configuration MIB modules. Why do you pick
   these and not the others? This is also an example where the
   maturity level classification went wrong.

   OLD:

   Draft standards:

   [RFC3418] contains objects in the system group useful e.g. for
   identifying the type of device, the location of the device, the
   person responsible for the device.  [RFC3413], part of STD 62 SNMPv3,
   includes objects designed for configuring notification destinations,
   and for configuring proxy- forwarding SNMP agents, which can be used
   to forward messages through firewalls and Network Address Translation
   (NAT) devices.

   NEW:

   RFC 3418, part of [STD62], contains objects in the system group
   useful e.g. for identifying the type of device, the location of the
   device, the person responsible for the device. The SNMPv3 standard
   [STD62] includes objects designed for configuring principals,
   access control rules, notification destinations, and for
   configuring proxy- forwarding SNMP agents, which can be used to
   forward messages through firewalls and Network Address Translation
   (NAT) devices.

x) I doubt these are in any way practically relevant nor am I sure
   about the support agreement argument. This neither RFC3165 nor
   RFC4011 seem to be used in practice, I would rather drop these
   three paragraphs.

   OLD:

   [RFC3165] supports the use of user-written scripts to delegate
   management functionality.

   Policy Based Management MIB [RFC4011] defines objects that enable
   policy-based monitoring using SNMP, using a scripting language, and a
   script execution environment.

   Few vendors have implemented MIB modules that support scripting.
   Some vendors consider running user-developed scripts within the
   managed device as a violation of support agreements.

   NEW:

y) This text should probably be made more precise by saying monitoring
   instead of broadly management. The standard status becomes clear
   through the STD reference.

   OLD:

   RMON (Remote Network Monitoring) MIB [RFC2819] has the Full Standard
   status [STD59] and defines objects for managing remote network
   devices and collecting data related to network performance and
   traffic.  An organization may employ many remote management probes,
   one per network segment, to manage its internet.  These devices may
   be used by a network service provider to access a client network,
   often geographically remote.  Most of the objects in the RMON MIB
   module are suitable for the management of any type of network, where
   some of them are specific to management of Ethernet networks.

   NEW:

   The RMON (Remote Network Monitoring) MIB [RFC2819] [STD59] defines
   objects for collecting data related to network performance and
   traffic from remote monitoring devices. An organization may employ
   many remote monitoring probes, one per network segment, to monitor
   its network.  These devices may be used by a network service
   provider to access a client network, often geographically remote.
   Most of the objects in the RMON MIB module are suitable for the
   monitoring of any type of network, while some of them are specific
   to the monitoring of Ethernet networks.

z) Why do we have text for something that according to RFC 6248 has
   seen no usage?

   OLD:

   The IPPM working group has defined [BCP108][RFC4148] "IP Performance
   Metrics (IPPM) Metrics Registry".  The IANA-assigned registry
   contains an initial set of OBJECT IDENTITIES to currently defined
   metrics in the IETF as well as defines the rules for adding IP
   Performance Metrics that are defined in the future.  However, the
   current registry structure has been found to be insufficiently
   detailed to uniquely identify IPPM metrics.  Due to the ambiguities
   between the current metrics registrations and the metrics used, and
   the apparent non-adoption of the registry in practice, it has been
   proposed to reclassify [RFC4148] as Obsolete.

   Note: With the publication of [RFC6248] the latest IANA registry for
   IPPM metrics and [RFC4148] have been declared Obsolete and IANA
   prevents registering new metrics.  Actual users can continue using
   the current registry and its contents.

   NEW:

A) Should NACM be mentioned in 4.2.5 right before the text on RADIUS
   starts?

B) Something went wrong here...

   OLD:

   [STD58]       McCloghrie, K., David, D., and J. Juergen, "Structure
                 of Management Information Version 2 (SMIv2)",
                 April 1999.

   NEW:

   [STD58]       McCloghrie, K., Perkins, D., and J. Schoenwaelder, 
                 "Structure of Management Information Version 2 (SMIv2)",
                 April 1999.

C) The previous item B) made me look into std-index.txt and it seems
   standards made up of multiple RFCs happen to have their own name.
   STD62 for example is called "Simple Network Management Protocol
   Version 3 (SNMPv3)." and the authors are all the authors of the
   RFCs that are part of the standard. I assume the RFC editor knows
   how to properly cite a [STD]. (This comment likely also applies to
   BCPs, but we likely have fewer multi-document BCPs.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>