Comments on draft-kchapman-perfhist-sup-TC-00.txt

["C. M. Heard/VVNET, Inc." <[e-mail]>]

Greetings,

Thanks to Ken Chapman for producing <draft-kchapman-perfhist-sup-TC-00.txt>.
My comments are listed below, in decreasing order of importance.  I have
cross-posted them to the atommib and trunk-mib lists because the TCs in this
draft are relevant both to the SONET supplemental MIB and to the DS1 and DS3
supplemental MIBs.

1.) PerfDayCount should have a syntax of Gauge32 (not Unsigned32),
    and its description needs to take into account the fact that
    its value _may decrease_ if the counts are adjusted retroactively
    upon entering or exiting unavailable time.

    Discussion:  the description clause now states that "unlike a
    Counter32, this counter shall not wrap; it shall latch if it
    reached its maximum value (4294967295 decimal) and it shall not
    change until it is reset (e.g. at the beginning of a new interval)."
    It is agreed that the a PerfDayCount must not wrap;  however, if
    the underlying value subsequently decreases below 4294967295 owing
    to a retroactive adjustment, then its value _should_ subsequently
    decrease;  it should not remain latched at 4294967295.  This is
    precisely what RFC 1902 says that a Gauge32 object will do:

        The Gauge32 type represents a non-negative integer, which may
        increase or decrease, but shall never exceed a maximum value.  The
        maximum value can not be greater than 2^32-1 (4294967295 decimal).
        The value of a Gauge has its maximum value whenever the information
        being modeled is greater or equal to that maximum value; if the
        information being modeled subsequently decreases below the maximum
        value, the Gauge also decreases.

    In conjunction with this change to the SYNTAX clause, the portion of
    the description clause quoted above should be changed to read "unlike
    a Counter32, this object shall not wrap;  whenever the underlying count
    exceeds 4294967295, this object shall return the value 4294967295."
    [Other changes are covered under (3) below.]

2.) The definition of xyzInvalidDays given here is not consistent with
    the definition of xyzInvalidIntervals in PerfHist-TC-MIB.  For
    consistency, it should be the number of recent 1-day intervals with
    interval numbers in the range 1..xyzValidDays which are unavailable.

3.) There are various typos which are noted in the marked-up ID which
    I have attached below my signature.

4.) The boilerplate should be updated to the latest version agreed to
    by the SNMPv3 WG.

5.) The acknowledgments section should probably state that the document
    has been reviewed by an IETF working group.

6.) The security section will need to be re-written, if only to state
    that MIB objects defined using the TCs in this MIB module are
    not likely to pose create security hazards because they are read-only
    and the information they contain is not sensitive.

Mike
--
C. M. Heard/VVNET, Inc.
[e-mail]

--marked up I-D follows

INTERNET-DRAFT    Supplemental Performance History TC          July 1998


     Textual Conventions for MIB Modules Using Performance History
                       Based on 24 Hour Intervals

                               July 1998


                <draft-kchapman-perfhist-sup-TC-00.txt>

                              Ken Chapman
                          Argon Networks, Inc.
                             25 Porter Road
                          Littleton, MA 01460

                           [e-mail]







1.  Status of this Memo

This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups.  Note that other groups may also distribute working
documents as Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet Drafts as reference material
or to cite them other than as a "work in progress".

To learn the current status of any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).


2.  Abstract

This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community.  In particular, it describes tectual conventions used to
                                        ^^^^^^^
                                        textual

define 24 hour inteval counters which supplement the interval counters
               ^^^^^^^
               interval

defined in the 15 Minute Based Performance History TCs MIB <draft-ietf-
atommib-perfhistTC-01.txt> [1].  See for example the DS1/E1, DS2/E2,





Expires January 1999                                            [Page 1]

INTERNET-DRAFT    Supplemental Performance History TC          July 1998


DS3/E3 and SONET/SDH supplemental MIBs [2][3][4]. This MIB is designed
to provide support for ASNI T1.231-1997 [6] 1-day registers.
                       ^^^^
                       ANSI

This memo does not specify a standard for the Internet community.


3.  Overview

This document supplements <draft-ietf-atommib-perfhistTC-01.txt>.  In
particular, it provides support for MIB objects that support the
                                                     ^^^^^^^
                                                    implement

previous 1-day register and recent 1-day registers as defined in ASNI
                                                                 ^^^^
                                                                 ANSI
T1.231-1997, clause 9.1.2.1.


4.  Definitions

PerfHistSup-TC DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY
        FROM SNMPv2-SMI
    mib-2, Unsigned32
        FROM SNMPv2C-SMI

[should be:
    MODULE-IDENTITY, mib-2, Unsigned32
        FROM SNMPv2C-SMI
or if PerfDayCount SYNTAX clause is changed as recommended:
    MODULE-IDENTITY, mib-2, Gauge32
        FROM SNMPv2C-SMI
]
    TEXTUAL-CONVENTION
        FROM SNMPv2-TC;

perfHistSupTC MODULE-IDENTITY
    LAST-UPDATED  "9806252237Z"  -- 25-Jun-98 6:37 PM EDT
    ORGANIZATION  "Argon Networks, Inc."
    CONTACT-INFO
       "        Ken Chapman
        Postal: Argon Networks, Inc.
                25 Porter Road
                Littleton, MA  01460
                USA
        Phone:  [phone]
        Fax:    [phone]
        Email:  [e-mail]"
    DESCRIPTION
       "This MIB module provides Textual Conventions to be used by
        systems supporting 1-day (24 hour) based performance history
        counts."
    ::= { mib-2 xx }

-- *********************************************************************
-- Note to RFC editor:  Assign a number for xx from IANA when publishing
--                      this MIB as an RFC.



Expires January 1999                                            [Page 2]

INTERNET-DRAFT    Supplemental Performance History TC          July 1998


-- *********************************************************************

-- Use of the Textual Conventions defined in this MIB module assumes the
-- following:
--
-- *  The agent supports 1-day based history counters.
-- *  The agent is capable of keeping a history of n intervals of 1-day
--    performance data.  The value of n may be limited by the media-
--    specific MIB module but shall be 1 < n =< 32, where n = 1
                                                  ^^^^^^^^^^^^^
--    represents the current 1-day interval, n = 2 represents the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--    previous 1-day interval, n = 3 represents the newest recent 1-day
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--    interval and n = 32 represents the oldest recent 1-day interval.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[ the marked text is broken and should be deleted. ]

-- *  The agent will keep the following objects per interface:
--
-- xyzDayTimeElapsed OBJECT-TYPE
--     SYNTAX      INTEGER (0..86409)
--     MAX-ACCESS  read-only
--     STATUS      current
--     DESCRIPTION
--        "The number of seconds that have elapsed since the beginning
--         of the current 1-day perfromance history interval."
                                ^^^^^^^^^^^
                                performance
--     ::= { xxx }
--
-- xyzValidDays OBJECT-TYPE
--     SYNTAX      INTEGER (0..<n>)
--     MAX-ACCESS  read-only
--     STATUS      current
--     DESCRIPTION
--        "The oldest interval number for which data is available.  The
--         value will normally be n, where n is the number of 1-day
--         intervals supported by the agent.  However, some intervals
--         will not be available if the interface was brought online
--         within the last n days, in which case the value will be the
--         number of 1-day intervals since the interface has been online
--         (including the current interval).  It is also possible that
--         some intervals are unavailable in the case where the agent is
--         a proxy."
--    ::= { xxx }
--
-- xyzInvalidDays OBJECT-TYPE
--     SYNTAX      INTEGER (0..<n>)
--     MAX-ACCESS  read-only
--     STATUS      current
--     DESCRIPTION
--        "The number of intervals supported by the agent for which no
--         data is available for the interface."
--    ::= { xxx }

[The definition of xyzInvalidDays given here is not consistent with
 the definition of xyzInvalidIntervals in PerfHist-TC-MIB.  For
 consistency, it should be the number of recent 1-day intervals with
 interval numbers in the range 1..xyzValidDays which are unavailable. ]


Expires January 1999                                            [Page 3]

INTERNET-DRAFT    Supplemental Performance History TC          July 1998


HourOfDay ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d1a1d:1d"
    STATUS       current
    DESCRIPTION
       "A time-of-day specification at an hour boundary.  This is used
        to specify an event that is to occure at precisely the same time
        each day, on the hour; for example, the time to save an
        interface's current 1-day counter as the previous 1-day counter
        and reset the current 1-day counter to zero.

             octet  contents                  range
             -----  --------                  -----
               1    hour                      0..23
               2    direction from UTC        '+' | '-'
               3    hours from UTC            0..11
               4    minutes from UTC          0..59

        For example, 1 PM EDT would be displayed as:

             13-4:0

        Note that if only local time is known, then timezone information
        (octes 2-4) is not present."
         ^^^^^
         octets

    SYNTAX       OCTET STRING (SIZE (1 | 4))

PerfDayCount ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
       "A counter associated with interface performance measurements in
        a 1-day (24 hour) measurement interval.  This data type can be
        used for either a current interval or a pervious or recent 1-day
                                 ^              ^^^^^^^^
                                day             previous
        interval.

        For a current interval, the value of this counter starts at zero
             ^
            day

        and is increased when associated events occur, until the end of
        the 1-day interval.  At that time the value of the counter is
        stored in the first 1-day history interval (if supported), and
        the current interval counter is restarted at zero.  Unlike a
        counter32, this counter shall not wrap; it shall latch if it
                                                         ^^^^^
                                                        [see discussion]
                                                          vvvvvvvvvvvv
        reachs its maximum value (4294967295 decimal) and it shall not
        ^^^^^^
        reaches

        change until it is reset (e.g. at the beginning of a new
        interval).

        In a system supporting a history of n intervals, where
        DayCount(1) and DayCount(n) contain the most and least recent
        historic intervals respectively, the following applies at the
        end of a 24 hour interval:





Expires January 1999                                            [Page 4]

INTERNET-DRAFT    Supplemental Performance History TC          July 1998


        - discard the value of DayCount(n)
        - the value of DayCount(i) becomes that of
          DayCount(i-1) for n >= i > 1

[no, the value of DayCount(i-1) becomes the value of DayCount(i)]

        - the value of DayCount(1) becomes the value of the current
          interval count

[no, the value of the current one day count becomes the value of DayCount(1)]

        - the current interval count is restarted at zero.

        In the case where the agent has no data available for a
        particular interval the corresponding object instance is not
        available and upon a retrieval request a corresponding error
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        message (noSuch*) shall be returned."
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[ reword:  upon a retrieval request a (noSuch*) error shall be returned ]

    REFERENCE   "ANSI T1.231-1997 clauses 9.1.2.1 and 9.1.2.3."
    SYNTAX  Unsigned32
            ^^^^^^^^^^
            Gauge32
          [see discussion]

END



5.  Acknowledgments

This document is not a product of an IETF Working Group.

6.  References

[1]  Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2
     and E2 Interface Types", <draft-ietf-trunkmib-ds1-mib-08.txt>,
     Newbridge Networks, Wed Feb 11 19:26:27 EST 1998.

[2]  Greene, M., "Definitions of Supplemental Managed Objects for the
     DS1, E1, DS2 and E2 Interface Types", <draft-ietf-trunkmib-ds1-
     supp-00.txt>, Ascom Nexion, May 31, 1996.

[3]  Fowler, D., "Definitions of Managed Objects for the DS3/E3
     Interface Type", <draft-ietf-trunkmib-ds3-mib-08.txt>, Newbridge
     Networks, Tue Feb 24 09:53:17 EST 1998.

[4]  Gonda, R., "Definitions of Supplemental Managed Objects for the
     DS3/E3 Interface Type", <draft-ietf-trunkmib-ds3SuppMIB-00.txt>,
     Cascade Communication Corporation, Thu Oct 17 14:05:52 EDT 1996.

[5]  Tesink, K., "Definitions of Managed Objects for the SONET/SDH
     Interface Type", <draft-ietf-atommib-sonetng-02.txt>, Bell
     Communications Research, August 26, 1996.

[6]  ANSI Standards Committee T1 - Telecommunications, "American
     National Standard for Telecommunications -- Digital Hierarchy --





Expires January 1999                                            [Page 5]

INTERNET-DRAFT    Supplemental Performance History TC          July 1998


     Layer 1 In-Service Digital Transmission Performance Monitoring",
     ANSI T1.231-1997, October 20, 1997.

[7]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Structure of Management Information for Version 2
     of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP
     Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
     International Network Services, January 1996.

[8]  McCloghrie, K., and M. Rose, Editors, "Management Information Base
     for Network Management of TCP/IP-based internets: MIB-II", STD 17,
     RFC 1213, Hughes LAN Systems, Performance Systems International,
     March 1991.

[9]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
     Management Protocol", RFC 1157, SNMP Research, Performance Systems
     International, Performance Systems International, MIT Laboratory
     for Computer Science, May 1990.

[10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc.,
     Cisco Systems, Inc., Dover Beach Consulting, Inc., International
     Network Services, January 1996.


7.  Security Considerations

Security issues are not discussed in this memo.


8.  Author's Address

             Ken Chapman
             Argon Networks, Inc.
             25 Porter Road
             Littleton, MA 01460
             Phone: [phone] x146
             EMail: [e-mail]












Expires January 1999                                            [Page 6]

INTERNET-DRAFT    Supplemental Performance History TC          July 1998


Table of Contents


1 Status of this Memo .............................................    1
2 Abstract ........................................................    1
3 Overview ........................................................    2
4 Definitions .....................................................    2
5 Acknowledgments .................................................    5
6 References ......................................................    5
7 Security Considerations .........................................    6
8 Author's Address ................................................    6








































Expires January 1999                                            [Page 7]