Subject: DS1 and DS3 drafts have expired

From: "C. M. Heard" <[email-masked]>
Date: Thu, 1 May 2003 12:17:04 -0700 (PDT)

Orly,

The DS1 and DS3 MIB documents draft-ietf-atommib-rfc2495bis-01.txt
and draft-ietf-atommib-rfc2496bis-01.txt have expired.  The have
been replaced by -02 versions which are just expiration notices.

I think if we wish to pursue further work on those MIB modules then
it will be necessary to submit updated drafts.  Some time ago I
pointed out a few changes that I thought were needed in the -01
versions of these documents;  those e-mails are attached below.

Thanks,

Mike

Subject: Wrong object changed in draft-ietf-atommib-rfc2496bis-01.txt (dsx3FracIndex instead of dsx3FracIfIndex)
From: "C. M. Heard" <[email-masked]>
To: Orly Nicklass <[email-masked]>
Cc: [email-masked]
Date: Wed, 11 Sep 2002 12:21:56 -0700 (PDT)

Orly,

I just ran an smidiff check on the DS3 MIB and the following message
caught my eye:

DS3-MIB.my:1504 [3] range of type used in `dsx3FracIndex' changed from
`(1..2147483647)' to `(0..2147483647)'

I believe that you changed the wrong object.  According to the
mailing list archive, dsx3FracIfIndex was supposed to have
zero included in its range in order to make its SYNTAX
consistent with its description, and I agree with that.
dsx3FracIndex, on the other hand, is a table index and
should not be allowed to have the value zero.

Regards,

Mike

Subject: Conformance group problem in draft-ietf-atommib-rfc2495bis-01.txt
From: "C. M. Heard" <[email-masked]>
To: Orly Nicklass <[email-masked]>
Cc: [email-masked]
Date: Wed, 11 Sep 2002 13:05:16 -0700 (PDT)

Orly,

I just ran an smidiff check on the DS1 MIB and the following messages
caught my eye:

DS1-MIB.my:2142 [2] member `dsx1LineMode' added to group `ds1NearEndConfigGroup'
DS1-MIB.my:2142 [2] member `dsx1LineBuildOut' added to group `ds1NearEndConfigGroup'

These changes are not legal (it is not allowed to add members to a
conformance group), and so will need to be fixed.

The reason why it is not allowed to add members to a conformance group
is because it silently changes the meaning of any compliance statement
that refers to it.  The affected compliance statements in this case are
ds1Compliance, ds1MibT1PriCompliance, and ds1MibE1PriCompliance.  What
one needs to do is to define a new conformance group and new compliance
statements, and to deprecate (but not change) the existing compliance
statements.  See Sections 7.1 and 7.2 of RFC 2580 for more details.
[I might note in passing that adding enumerations can cause problems
too; see issue #4 in http://www.ibr.cs.tu-bs.de/ietf/smi-errata/
We are OK in the present case because the objects for which enum
values have been added all have a MIN-ACCESS of read-only].

Mike