Subject: Re: I-D ACTION:draft-ietf-atommib-rfc2495bis-03.txt

From: "C. M. Heard" <[email-masked]>
Date: Thu, 10 Jul 2003 15:20:24 -0700 (PDT)

On Wed, 2 Jul 2003 [email-masked] wrote:
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories. This draft is a work item of the
> AToM MIB Working Group of the IETF.
> 
> 	Title		: Definitions of Managed Objects for the DS1, E1, DS2
>                           and E2 Interface Types
> 	Author(s)	: O. Nicklass
> 	Filename	: draft-ietf-atommib-rfc2495bis-03.txt
> 	Pages		: 92
> 	Date		: 2003-7-1

AToM MIB folks,

I have just finished reviewing draft-ietf-atommib-rfc2495bis-03.txt
to see if all the review comments previously sent to the list have
been properly addressed.  Most have, but there are still a few minor
editorial issues that need to be addressed.  I'll go back through
the MIB review checklist and list the unaddressed comments along
with proposed fixes.

1.) I-D Boilerplate -- OK

2.) Abstract -- OK

3.) MIB Boilerplate -- OK

4.) IPR Notices -- OK

5.) References -- the following things require attention:
...
% [RFC2493]           referenced in MIB module IMPORTS statement
%                     (PerfHist-TC-MIB).  Note: this reference should
%                     point to the forthcoming update of RFC 2493
%                     (the RFC number is TBD, the approved draft
%                     is <draft-ietf-atommib-rfc2493bis-01.txt>;
%                     suggest to change the tag to [RFC2493bis] and
%                     list the I-D name;  the RFC Editor will fill
%                     in the RFC number when it is assigned).
...
% (e) the following informative references should probably point to
% the forthcoming updates:
% 
% [RFC2496]           the RFC number is TBD, the unapproved draft
%                     is <draft-ietf-atommib-rfc2496bis-02.txt>
% 
% [RFC2558]           the RFC number is TBD, the approved draft
%                     is <draft-ietf-atommib-rfc2558bis-01.txt>
% 
% You may want to handle these with an RFC Editor note at the end of
% the document, as was done in <draft-ietf-atommib-rfc2493bis-01.txt>

Here are the proposed fixes: on page 88, Section 8.1, "Normative
References", change:

[RFC2493]
     Tesink, K., "Textual Conventions for MIB Modules Using Performance
     History Based on 15 Minute Intervals", Work in Progress, RFC number
     is TBD.

to:

[RFC2493bis]
     Tesink, K., "Textual Conventions for MIB Modules Using
     Performance History Based on 15 Minute Intervals",
     draft-ietf-atommib-rfc2493bis-01.txt, work in progress.

     ************************************************************
     * NOTE TO RFC Editor (to be removed prior to publication): *
     * Please update this reference to point to the forthcoming *
     * RFC based on draft-ietf-atommib-rfc2493bis-01.txt that   *
     * will replace RFC 2493, and replace all occurrences of    *
     * "2493bis" with the number of that RFC.                   *
     ************************************************************

(the exact form of the RFC editor note is at author's discretion),
and on page 89, Section 8.2, "Informative References", change:

[RFC2496]
     Fowler, D., "Definitions of Managed Objects for the DS3/E3
     Interface Types", Work in Progress, RFC number is TBD.

[RFC2558]
     Tesink, K., "Definitions of Managed Objects for the SONET/SDH
     Interface Type", Work in Progress, RFC number is TBD.

to:

[RFC2496]
     Fowler, D., "Definitions of Managed Objects for the DS3/E3
     Interface Type", RFC 2496, January 1999.

     ************************************************************
     * NOTE TO RFC Editor (to be removed prior to publication): *
     * If <draft-ietf-atommib-rfc2496bis-04.txt> (or its        *
     * successor) is to be published as an RFC concurrently     *
     * with this document, please update this reference to      *
     * to point to that RFC, instead of RFC 2496, and change    *
     * the reference tag [RFC2496] to match.                    *
     ************************************************************

[RFC2558]
     Tesink, K., "Definitions of Managed Objects for the SONET/SDH
     Interface Type", RFC 2558, March 1999.

     ************************************************************
     * NOTE TO RFC Editor (to be removed prior to publication): *
     * If <draft-ietf-atommib-rfc2558bis-01.txt> (or its        *
     * successor) is to be published as an RFC concurrently     *
     * with this document, please update this reference to      *
     * to point to that RFC, instead of RFC 2558, and change    *
     * the reference tag [RFC2558] to match.                    *
     ************************************************************

(the exact form of the RFC editor notes is at author's discretion;
please update 2496bis I-D name if another version will be current).

6.) Security Considerations Section -- there is a typographical
error in the revised text.  The proposed fix is to change:

   Setting the following object can cause an increase in the number of
   traps received by the network management station:

      dsx1LineStatusChangeTrabEnable
-----------------------------^
to:

   Setting the following object can cause an increase in the number of
   traps received by the network management station:

      dsx1LineStatusChangeTrapEnable
-----------------------------^

7.) IANA Considerations Section -- OK

8.) Copyright notices -- there is at yet no full copyright notice
as required by RFC 2026 sec 10.4(C).  Cut & paste from RFC 2026
or better still from a recent RFC (there are some typos in the
version in RFC 2026).

9.) MIB compilation -- all outstanding issues are resolved:  the only
diagnostics that remain are those that are inherited from previous
versions of the MIB module (e.g., as a result of translation from
SMIv1) or that concern revisions which are acceptable.

10.) Other issues (e.g., stuff in http://www.ietf.org/ID-nits.html
that is not covered above) -- there are some lines that exceed 72
characters in Sections 1.1, 2.2.5 and in the MIB module itself
(although the latter will go away, once the RFC Editor notes are
removed, if the module indentation is reduced from 10 spaces down
to 3 and if the edits proposed in #11 are incorporated).  Also,
readability would be improved if a page break was inserted before
the start of the first table in Appendix A.  I think that the RFC
Editor can handle this stuff, so fixes for these things are at the
author's discretion.

There are also some remaining minor things that must be corrected;
proposed fixes are as follows.

On page 2, 2nd paragraph of Section 2, change:

   The definitions contained herein are based on the AT&T T-1 Superframe
   (a.k.a., D4) and Extended Superframe (ESF) formats [AT&T-UM-305],
   [AT&T-TR-54016], the latter of which conforms to ANSI specifications
   [ANSI T1.403], and the CCITT Recommendations [ CCITT-G.703, ITU-T-
   G.704], referred to as E1 for the rest of this memo.

to:

   The definitions contained herein are based on the AT&T T-1 Superframe
   (a.k.a., D4) and Extended Superframe (ESF) formats [AT&T-UM-305],
   [AT&T-TR-54016], the latter of which conforms to ANSI specifications
   [ANSI-T1.403], and the CCITT Recommendations [CCITT-G.703],
   [ITU-T-G.704], referred to as E1 for the rest of this memo.

On page 32, remove the non-ascii escape sequences (esc-9), i.e.:
s/9// (two occurrences)

11.) Technical content -- there are still some minor issues with
the MIB module.

On Wed, 21 May 2003, Kaj Tesink wrote:
> add to dsx1LineType OBJECT-TYPE:
> 
> REFERENCE
>      "American National Standard for telecommunications - digital hierarchy -
>           formats specification, ANSI T1.107- 1988.
>      CCITT Specifications Volume III, Recommendation G.703,
>            Physical/Electrical Characteristics of Hierarchical Digital
>           Interfaces, April 1991.
>      ITU-T G.704: Synchronous frame structures used at 1544, 6312, 2048, 8488
>           and 44 736 kbit/s Hierarchical Levels, July 1995."

The dsx1LineType definition in the -03 draft does indeed contain
this reference clause, but the descriptions of the enumerations were
(by mistake I believe) eliminated from the DESCRIPTION clause.  So I
suggest that the dsx1LineType definition (pp. 25-26) be changed from:

   dsx1LineType OBJECT-TYPE
        SYNTAX  INTEGER {
                   other(1),
                   dsx1ESF(2),
                   dsx1D4(3),
                   dsx1E1(4),
                   dsx1E1CRC(5),
                   dsx1E1MF(6),
                   dsx1E1CRCMF(7),
                   dsx1Unframed(8),
                   dsx1E1Unframed(9),
                   dsx1DS2M12(10),
                   dsx2E2(11),
                   dsx1E1Q50(12),
                   dsx1E1Q50CRC(13)
               }
        MAX-ACCESS  read-write
        STATUS  current
        DESCRIPTION
               "This variable indicates  the  variety  of  DS1
               Line  implementing  this  circuit.  The type of
               circuit affects the number of bits  per  second
               that  the circuit can reasonably carry, as well
               as the interpretation of the  usage  and  error
               statistics.

               For clarification, the capacity for each E1 type
               is as listed below:
               dsx1E1Unframed - E1, no framing = 32 x 64k = 2048k
               dsx1E1 or dsx1E1CRC - E1, with framing,
                  no signalling = 31 x 64k = 1984k
               dsx1E1MF or dsx1E1CRCMF - E1, with framing,
                  signalling = 30 x 64k = 1920k"
        REFERENCE
               "American National Standard for telecommunications -
                   digital hierarchy - formats specification,
                   ANSI T1.107- 1988.
                CCITT Specifications Volume III, Recommendation G.703,
                   Physical/Electrical Characteristics of Hierarchical
                   Digital Interfaces, April 1991.
                ITU-T G.704: Synchronous frame structures used at 1544,
                   6312, 2048, 8488 and 44 736 kbit/s Hierarchical Levels,
                   July 1995."
        ::= { dsx1ConfigEntry 5 }

to:

   dsx1LineType OBJECT-TYPE
        SYNTAX  INTEGER {
                   other(1),
                   dsx1ESF(2),
                   dsx1D4(3),
                   dsx1E1(4),
                   dsx1E1CRC(5),
                   dsx1E1MF(6),
                   dsx1E1CRCMF(7),
                   dsx1Unframed(8),
                   dsx1E1Unframed(9),
                   dsx1DS2M12(10),
                   dsx2E2(11),
                   dsx1E1Q50(12),
                   dsx1E1Q50CRC(13)
               }
        MAX-ACCESS  read-write
        STATUS  current
        DESCRIPTION
               "This variable indicates  the  variety  of  DS1
               Line  implementing  this  circuit.  The type of
               circuit affects the number of bits  per  second
               that  the circuit can reasonably carry, as well
               as the interpretation of the  usage  and  error
               statistics.  The values, in sequence, describe:

               TITLE:         SPECIFICATION:
               dsx1ESF         Extended SuperFrame DS1 (T1.107)
               dsx1D4          AT&T D4 format DS1 (T1.107)
               dsx1E1          ITU-T Recommendation G.704
                                (Table 4a)
               dsx1E1-CRC      ITU-T Recommendation G.704
                                (Table 4b)
               dsxE1-MF        G.704 (Table 4a) with TS16
                                multiframing enabled
               dsx1E1-CRC-MF   G.704 (Table 4b) with TS16
                                multiframing enabled
               dsx1Unframed    DS1 with No Framing
               dsx1E1Unframed  E1 with No Framing (G.703)
               dsx1DS2M12      DS2 frame format (T1.107)
               dsx1E2          E2 frame format (G.704)
               dsx1E1Q50       TS16 bits 5,7,8 set to 101, in
                                all other cases it is set to 111.
                                (ITU-T G.704, table 14)
               dsx1E1Q50CRC    E1Q50 with CRC.

               For clarification, the capacity for each E1 type
               is as listed below:
               dsx1E1Unframed - E1, no framing = 32 x 64k = 2048k
               dsx1E1 or dsx1E1CRC - E1, with framing,
                  no signalling = 31 x 64k = 1984k
               dsx1E1MF or dsx1E1CRCMF - E1, with framing,
                  signalling = 30 x 64k = 1920k"
        REFERENCE
               "American National Standard for telecommunications -
                   digital hierarchy - formats specification,
                   ANSI T1.107-1988.
                CCITT Specifications Volume III, Recommendation G.703,
                   Physical/Electrical Characteristics of Hierarchical
                   Digital Interfaces, April 1991.
                ITU-T G.704: Synchronous frame structures used at 1544,
                   6312, 2048, 8488 and 44 736 kbit/s Hierarchical
                   Levels, July 1995."
        ::= { dsx1ConfigEntry 5 }

This will re-instate the (very useful) enumeration descriptions
and will fix a 72-column spillover problem in the REVISION clause.

% (f) Although the new "general" DS1 compliance statement
% ds1NCompliance has OBJECT clauses to allow read-only
% implementations of the new configuration objects
% dsx1LineMode and dsx1LineBuildOut, the new T1 PRI and
% E1 PRI compliance statements ds1MibT1PriNCompliance
% and ds1MibE1PriNCompliance (respectively) do not.  That
% means that read-write implementation of the objects is
% required for an implementation to satisfy those compliance
% statements.  This appears to be an oversight.  If so, then
% the OBJECT clauses for those two objects should be copied
% from ds1NCompliance into ds1MibT1PriNCompliance and
% ds1MibE1PriNCompliance (with typo correction (e)), as
% shown in the attached context diff.

The newly-added OBJECT clauses in ds1MibE1PriNCompliance for
dsx1Channelization and dsx1LineBuildOut (pp. 75-76) have some
72-column spillover problems (even after reduced indenting),
so it it suggested to change them from:

           OBJECT dsx1Channelization
               MIN-ACCESS read-only
               DESCRIPTION
                   "The ability to set the channelization is not required."

           OBJECT dsx1LineMode
               MIN-ACCESS read-only
               DESCRIPTION
                   "The ability to set the Line Mode is not required."

           OBJECT dsx1LineBuildOut
               MIN-ACCESS read-only
               DESCRIPTION
                   "The ability to set the Line build out is not required."

to:

           OBJECT dsx1Channelization
               MIN-ACCESS read-only
               DESCRIPTION
                   "The ability to set the channelization is not
                    required."

           OBJECT dsx1LineMode
               MIN-ACCESS read-only
               DESCRIPTION
                   "The ability to set the Line Mode is not required."

           OBJECT dsx1LineBuildOut
               MIN-ACCESS read-only
               DESCRIPTION
                   "The ability to set the Line build out is not
                    required."

The dsx1LineBuildOut OBJECT clause for ds1MibT1PriNCompliance (p. 74)
needs the same change.

As far as I can tell, everything else is OK.

Have a productive discussion in Vienna.

Regards & thanks,

Mike Heard