On Mon, 10 Apr 2006, Romascanu, Dan (Dan) wrote:
> The
author of draft-orly-atommib-rfc3895bis-00.txt required that this
>
document be processed as an independent submission sponsored by the AD
>
to become a standards track document.
>
> I believe that there is a
need for a couple of expert reviews in order
> to ensure that the document
is at the proper quality level for
> standards track. C.M. Heard
volunteered to perform a MIB Doctor
> Review, and Kam Lam volunteered to
help with the transport Protocols review.
>
> The reviewers and all
other parties interested in this work are
> invited to send their comments
to ietfmibs@ops.ietf.org until May 2nd,
> 2006 the
latest.
Dan,
Here is the promised MIB Doctor review of Orly's
recently-submitted document draft-orly-atommib-rfc3895bis-00.txt. Since
RFC 3895 itself went through a MIB Doctor review, I believe that it is
sufficient to review just the things that have changed since RFC 3895. And
since I did a reasonably thorough job of that on the pre-submission version of
Orly's document, I think it suffices this time just to go over the things that I
flagged before plus new issues introduced in the latest round of
edits.
Before I do that, however, I'd like to make some general comments
about the changes relative to RFC 3895. As noted in Section 2.1 of the
draft, the important ones are:
(1) Values were added to dsx1LineType to
support J1 types.
(2) The object dsx1LineImpedance was added.
(3) All DM
(degraded minutes) related objects were deprecated
following their removal from ITU and ANSI performance
monitoring standards.
(4) Relevant text and reference section were
updated.
(5) Changes in Compliance Statements to include new values.
I
audited the smidiff report (a copy of which is attached), and I agree that the
above list is a reasonably accurate summary of what was changed.
The new object dsx1LineImpedance is writeable and is mentioned in the
Security Considerations section, as required. One point that
should be noted about the new compliance statements is that in addition to
removing the requirement to implement DM-related objects, they add a requirement
to implement dsx1LineImpedance.
Thus, existing implementations will need to
be updated in order to claim compliance to the 3895bis spec. That
should probably be noted when the document is last-called. Note
that the same approach was taken for RFC 3895 itself, that is, the objects
dsx1LineMode and dsx1LineBuildOut that were added in that rev of the spec were
made mandatory-to-implement.
Now for the re-check off items flagged in
the pre-submission review.
On Saturday, March 11, 2006 C. M. Heard
wrote:
> 1.) Sections 1.1 through 1.3 of RFC 3895 have been removed.
These
> cover the revisions back to RFC 1406 and the list of
companion
> documents. I would recommend that these sections be
reinstated.
> They should probably be Sections 1.2 through 1.4 in your
draft.
Sections 1.1 and 1.2 of RFC 3895 have been reinstated as
Sections
2.2 and 2.3 of the 3895bis draft. Section 1.3 of RFC 3895 has not been reinstated. I have no
objections to dropping that section, but its absence does result in some uncited
informative references (more on this below).done
> 2.) I notice that the references to G.704
Table 4a/4b have been
> changed -- in most places -- to G.704 Table 5a/5b,
even though the
> underlying reference is the same. If this was
intended, then no
> action is necessary; I am just checking to make
sure that no error
> was introduced. (If the change is NOT backed
out, then presumably the
> reference to Table 4a in the
ds1MibE1PriCompliance OBJECT clause for
> dsx1Fdl needs to be
corrected).
This was left unchanged, so I assume that no change was
required. I notice that the reference to Table 4a in the
ds1MibE1PriCompliance is for something different so I withdraw the
parenthetical comment.
> 3.) The date on the REVISION clause
for RFC 3985 is "200409190000Z"
> in your draft but is "200409090000Z" in
RFC 3895 itself. The date
> that you need to use is "200409090000Z",
i.e., the one in RFC 3895.
> Doing so would obviate the following smilint
messages:
>
> /usr/local/share/mibs/ietf/DS1-MIB:48 [3]
{revision-removed} revision
> `2004-09-09 00:00' removed
>
DS1-MIB.x:66 [5] {revision-added} warning: revision `2004-09-19 00:00'
>
added
This has been fixed and is no longer an
issue.
> 4.) A typo has crept into the DESCRIPTION clause of
dsx1LineCoding:
> s/specifed/specified/ in the last paragraph of the
clause.
This has been fixed and is no longer an
issue.
> 5.) The DESCRIPTION clause for the new object is a
bit thin, and the
> named-number labels could be improved. Suggested
change:
>
>
OLD:
>
dsx1LineImpedance
OBJECT-TYPE
>
SYNTAX INTEGER
{
>
notApplicable
(1),
>
unbalance75ohms
(2),
>
i100ohms
(3),
>
balance120ohms
(4)
>
}
>
MAX-ACCESS
read-write
>
STATUS
current
>
DESCRIPTION
>
"Impedance setting for E1
lines."
>
::= { dsx1ConfigEntry 23 }
>
NEW:
>
dsx1LineImpedance
OBJECT-TYPE
>
SYNTAX INTEGER
{
>
notApplicable
(1),
>
unbalanced75ohms
(2),
>
balanced100ohms
(3),
>
balanced120ohms
(4)
>
}
>
MAX-ACCESS
read-write
>
STATUS
current
>
DESCRIPTION
>
"Nominal line impedance. For T1 and J1
lines
>
the value is typically
balanced100ohms(3).
>
For E1 lines the value is
typically
>
unbalanced75ohms(2) and
balanced120ohms(4).
>
When this object does not apply, or
when
>
the appropriate value is not know,
the
>
value should be set to notApplicable
(1)."
>
::= { dsx1ConfigEntry 23 }
The suggested
DESCRIPTION text was adopted but the enum labels were not changed to match
it:done
dsx1LineImpedance
OBJECT-TYPE
SYNTAX INTEGER
{
notApplicable
(1),
unbalance75ohms
(2),
balance100ohms
(3),
balance120ohms
(4)
}
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"Nominal line impedance. For T1 and J1 lines
the
value is typically balanced100ohms(3). For
E1
lines the value is typically
unbalanced75ohms(2)
and balanced120ohms(4). When this object does
not
apply, or when the appropriate value is not
known,
the value should be set to notApplicable
(1)."
::= { dsx1ConfigEntry 23 }
Either the enum labels should be changed to
match the DESCRIPTION text or the DESCRIPTION text should be changed to match
the labels. I would prefer changing the labels
(s/balance/balanced/), but can live with either option.done
> 6.) I suggest the following formatting
change at the end of the MIB
> module:
>
>
OLD:
>
::= { ds1Groups 13 } END
>
NEW:
>
::= { ds1Groups 13
}
>
END
This has been fixed and is no longer an
issue.
> 7.) In Appendix A, which explains the historical
usage of dsx1IfIndex
> and dsx1LineIndex in RFC 1406, the reference to RFC
1213 was changed
> to RFC 2863. This is not appropriate in this
context, since the text
> is being quoted from RFC 1406, and the version
of the Interfaces Group
> applicable to RFC 1406 was RFC 1213 (RFC 2863
did not show up until
> much later). The following rollback is
therefore
> recommended:
>
> Text in
draft-ietf-orly-rfc3895bis-00-5-3-06.txt:
> The
dsx1IfIndex column of the DS1 Configuration table relates
each
> DS1 interface to its corresponding interface
(ifIndex) in the
> Internet-standard MIB
[RFC2863].
>
> Please re-instate to text in RFC
3895:
> The dsx1IfIndex column of the DS1 Configuration
table relates each
> DS1 interface to its corresponding
interface (ifIndex) in the
> Internet-standard MIB
(MIB-II STD 17, RFC 1213) [RFC1213].
>
> and re-instate RFC 1213 as
an informative reference.
This has been fixed and is no longer an
issue.
> 8.) There are two typos in the Security
Considerations section:
>
> - at the end of the list of writable
objects, please change
> "dsx1LineImpedant" to
"dsx1LineImpedance";
>
> - in the paragraph on readable objects,
please change "DS1/E1/DS2/E2"
> to
"DS1/J1/E1/DS2/E2".
These have been fixed and are no longer
issues.
> 9.) The Informative References section needs to be
fixed. Based on
> the discussion above, this is what I would
recommend:
>
> 6.2. Informative
References
>
>
[RFC3410] Case, J., Mundy, R., Partain, D.,
and B.
Stewart,
>
"Introduction and Applicability Statements
for
>
Internet-Standard Management Framework", RFC
3410,
>
December 2002.
>
>
[RFC3895] Nicklass, O., Ed., "Definitions of
Managed
Objects
>
for the DS1, E1, DS2, and E2 Interface Types",
RFC
>
3895, September 2004.
>
>
[RFC2495] Fowler, D., Ed., "Definitions of
Managed Objects
for
>
the DS1, E1, DS2 and E1 Interface Types", RFC
2495,
>
January 1999.
>
>
[RFC1406] Baker, F. and J. Watt, Eds.,
"Definitions of
Managed
>
Objects for the DS1 and E1 Interface Types",
RFC
>
1406, January 1993.
>
>
[RFC2494] Fowler, D., "Definitions of
Managed Objects for
the
>
DS0 and DS0 Bundle Interface Type", RFC 2494,
January
>
1999.
>
>
[RFC3896] Nicklass, O., Ed., "Definitions of
Managed
Objects
>
for the DS3/E3 Interface Types", RFC 3896,
September
>
2004.
> [RFC3592]
Tesink, K., "Definitions of Managed Objects for
the
>
Synchronous Optical Network/Synchronous
Digital
>
Hierarchy (SONET/SDH) Interface Type", RFC
3592,
>
September 2003.
>
> [AT&T-UM-305]
AT&T Information Systems, AT&T ESF DS1
Channel
>
Service Unit User's Manual, 999-100-305,
February
>
1988.
>
>
[RFC1213] McCloghrie, K. and M. Rose,
"Management
Information
>
Base for Network Management of
TCP/IP-based
>
internets: MIB-II", STD 17, RFC 1213, March
1991.
Done; however, [RFC3592], [RFC2494], and
[ANSI-T1.102] are not cited in the text (see above), and the RFC Editor will
probably remove them.
All the issues I have raised here are minor, and I
see no reason to hold up IETF Last Call on their
account.
Regards,
Mike