Subject: [OPS-AREA] comments on draft-harrington-operations-and-management-00.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Apr 2007 09:05:15 +0200

David,
 
here are comments about draft-harrington-operations-and-management-00.txt
which I wanted to pass on to you in Prague (but since I failed to do
so, I wrote them down and so more people can see them easily).

a) I did not understand the next to last paragraph in section 2
   above 2.1:

     Considering the operational and manageability aspects related to a
     new protocol provides guidance to the editor of a document specifying
     management functionality, weighs the management options, and allows
     the editor to start actually editing earlier than if they need to
     research requirements before writing a management specification.

   This sounds like somehow things get faster, but I am not sure why.

b) p6: s/contrain/constrain/ (BTW, there is a spell checking service
   on the IETF's tool page.)

c) p11: s/shoul/should

d) p12: I would mention SVN in addition to RCS and CVS (which are both
   being gradually replaced by SVN it seems)

e) p12/13:

     [...] It is desirable to
     extract, document, and standardize the common parts of these network
     wide configuration database schemas.  A working group should consider
     how to standardize the common parts of configuring the new protocol,
     while recognizing the vendors will likely have proprietary aspects of
     their configurations.

   I do not think this belongs here. Yes, standards or even just
   guidelines for building network wide configuration databases would
   really help to advance the state of art but I believe this
   constitutes a problem the IETF can't really handle. The only way to
   tackle this problem is actually to fund open source initiatives in
   this space. (ISPs who have such systems have no interest to share
   them, those who don't have them typically do not have the resources
   to build them.)

f) p13:

     Given configuration A and configuration B, it should be possible to
     generate the operations necessary to get from A to B with minimal
     state changes and effects on network and systems.  It is important to
     minimize the impact caused by configuration changes.

   This has been said in section 3.5 already.

g) p13: I am not sure section 4.3.1 belongs into the section on
   configuration. Section 4.3.2 seems to be repetition and again I am
   not sure it belongs into 4.3.

h) p14: 

     Consider the expected behaviors when counters reach their maximum
     value - should they be reset to zero, or should they latch at the
     maximum value?

   From an SNMP perspective this is rather confusing; I would prefer
   to avoid the phrase "reset to zero" and instead use "roll-over" and
   I doubt counters that latch are a good thing.

     Consider whether counters should be persistent across reboots of the
     device, or restarts of the management system.

   It might be important to explain what counter discontinuities are,
   that is which events can cause counter delta computations to become
   irrelevant.

i) p15: s/application swill/ applications will/

j) p15: remove duplicate paragraph

     For performance monitoring, it is important to report counters and
     not gauges as it is important to report the time spent in a state
     rather than the actual state.  In other words, objects that report
     snapshots are of less value for performance monitoring.

k) p15: I suggest to add text to section 4.6 that people should think
   about how ACLs are maintained and updated.

l) p16: s/deployment/deployment.

m) p18:

     A key aspect of NETCONF is that it allows the functionality of the
     management protocol to closely mirror the native functionality of the
     device.  

   I believe this is confusing. The truth is that NETCONF aims at
   closely mirroring the native CLI of the device.

n) p18: I like to see strong warnings attached to COPS-PR, like that
   it did not side wide support/deployment and that its binary BER
   encoding of management data puts it close to SNMP in terms of the
   efforts it takes to script a simple solution in whatever automation
   language an operator prefers.

o) p19: I suggest to explain more about the differences between RADIUS
   and DIAMETER and how to make a choice between them. How is actually
   using DIAMETER?? (I do not care about other bodies refering to it;
   I mean deployed systems.)

p) p19: I think it is essential to get EPP included in the list of
   management protocols and also perhaps XCAP.

q) p19: I am not sure structuring section 6 along FCAPS is a good
   idea.  I am also not sure that IETF status of a specification is a
   useful selection criteria.

r) p20:

     Protocol designers should always build in basic testing features
     (e.g.  ICMP echo, UDP/TCP echo service, NULL RPC calls) that can be
     used to test for liveness, with an option to enable and disable them.

   While I agree with the statement, I doubt it belongs into section 6.

s) p20:

     A command line interface (CLI) might be used to provide initial
     configuration of the target functionality.  Command line interfaces
     are usually proprietary, but working groups could suggest specific
     commands and command parameters that would be useful in configuring
     the new protocol, so implementers could have similarities in their
     proprietary CLI implementations.

   This has been said already in section 5.8 and I do not think this
   belongs into section 6.2.

t) p21: s/PIBs During/PIBs. During/

u) p21: s/capabilities New/capabilities. New/

v) p21: I am not sure the following sections talk about configuration
   (but then I already suggested to not structure this section along
   FCAPS):

     RFC 3418 [RFC3418], part of STD 62 SNMPv3, contains objects in the
     system group that are often polled to determine if a device is still
     operating, and sysUpTime can be used to detect if a system has
     rebooted and caused potential discontinuity in other counters.  Other
     objects in the system MIB are useful for identifying the type of
     device, the location of the device, the person responsible for the
     device, etc.

     Draft Standard RFC2863 [RFC2863], the Interfaces MIB is used for
     managing Network Interfaces.  This includes the 'interfaces' group of
     MIB-II and discusses the experience gained from the definition of
     numerous media-specific MIB modules for use in conjunction with the
     'interfaces' group for managing various sub-layers beneath the
     internetwork-layer.

     Proposed Standard RFC4133 [RFC4133] the Entity MIB is used for
     managing multiple logical and physical entities managed by a single
     SNMP agent.

w) p21: is the following really relevant? are there any
   implementations and deployments?

     Proposed Standard RFC4011 [RFC4011] defines objects that enable
     policy-based monitoring and management of SNMP infrastructures, a
     scripting language, and a script execution environment.

x) p22:

     RFC3159 discusses the Proposed Standard Structure of Policy
     Provisioning Information (SPPI), an extension to the SMI standard for
     purposes of policy-based provisioning, for use with the COPS-PR
     protocol defined in RFC3084.  Informational RFC3317 defines a
     DiffServ QoS PIB, and Informational RFC3571 defines policy classes
     for monitoring and reporting policy usage feedback, as well as policy
     classes for controlling reporting intervals, suspension, resumption
     and solicitation.  At the time of this writing, there are no
     standards-track PIBs During the IAB Workshop on Network Management,
     the workshop had rough consensus from the protocol developers that
     the IETF should not spend resources on SPPI PIB definitions, and the
     operators had rough consensus that they do not care about SPPI PIBs.

   Why is this text here and not in the COPS-PR description?

y) After reading section 6, I asked myself whether it is possible to
   mention somehow that different "technologies" in the various layers
   tend to prefer different management interfaces. Layer two stuff
   seems to like SNMP much more than higher layers in the stack. It
   might be useful to explain integration with CLIs; there are boxes
   that layer CLI and Web interfaces over a common SNMP interface,
   there are boxes that layer CLI and Web interfaces over a common
   NETCONF interface, there are boxes where management interfaces are
   pretty much separate, which is known to be problematic. Sure, we
   get to discuss implementation choices but at the end, this is
   actually important to understand when making design decisions.

   I also found the end of section 6 a rather unstructured collection
   of things and it remains unclear what to learn from this. 

z) Just to complete the alphabet. ;-)

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area