Re: [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt

["David B Harrington" <dbharrington at comcast.net>]

> -----Original Message-----
> From: mib-doctors-bounces at ietf.org 
> [mailto:mib-doctors-bounces at ietf.org] On Behalf Of Romascanu, 
> Dan (Dan)
> Sent: Sunday, September 28, 2008 1:26 PM
> To: adslmib at ietf.org
> Cc: MIB Doctors (E-mail)
> Subject: [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt
> 
This document has lots of textual conventions. 
One suggestion would be to put the VDSL2-LINE-TC-MIB in a separate
document.  

However, are each of these TCs used multiple times? Do we plan to ue
them multiple times in different modules? Do we really need a
typedef-equivalent for each of these? If a TC is used only once, and
is only applicable to a single MIB module, then it might be better to
define the object using the base type and list the enumeration choices
in the object DESCRIPTION clause. You don't really need a TC if it
isn't going to be reused by multiple objects. That could reduce a lot
of duplicate text.

I decided to check and picked one randomly (Xdsl2ChInpReport) and
there is only one object that uses it. The object DESCRIPTION clause
contains all the information that the TC DESCRIPTION clause does,
albeit with slightly different wording. There is also a text section
that contains the same information. This is potentially bad if the
object DESCRIPTION clause and the TC DESCRIPTION clause (and possibly
the text description) could ever end up be interpreted differently; it
could be unclear which was normative.

I checked a few more: Xdsl2ChPtmStatus, Xdsl2ChAtmStatus, Xdsl2UpboKLF
all are done in triplicate; they are each actually used in an object
definition only once. In at least the case of Xdsl2UpboKLF, the object
DESCRIPTION lists the three enumeration values, but has the least
description of their meaning of the three copies - but the object
description is probably the most important place for the full
description (if the TC is not reused). 

I strongly support Dan's request to eliminate some of the redundancy
in this document, and I recommend starting with the textual convention
triplication. You can probably save 30% of the document length getting
rid of unnecessary textual convention definitions.

> 
> My comments are divided in Technical and Editorial. 
> 
> Technical Comments
> 
[...]
> 
> T2 - I have strong reservations about indexing tables that describe
> profiles and templates by names objects with a Syntax of 
> SnmpAdminString
> as described in Section 2.8.3. Such an indexation is very resource
> consuming, as each object in the table must carry the name in 
> the index
> for each MIB operation. What is the reason these tables cannot be
> indexed by a running index, and the name objects be just columns? 

In SNMPv2, we had tables that referenced other integer-indexed tables.
As a result, operators got to manually configure things like vacm
tables with rows that looked like:
1, 4, 18, 1, 5, 12, 8  
rather than
"dbh", "usm", "authPriv", "internet" "write-view", "allow"
(I know this is a bogus example; I am just making a point)

The SNMPv3 WG decided that, where the index would be referenced in
other tables, operator-usability was more important than
implementation efficiency. (Unfortunately, the SnmpAdminsString
definition is so full of international character set discussion, it
doesn't really discuss the motivation for the TC.)

Implementers can implement in a manner that improves internal resource
consumption by using tables indexed by integers in the internal
instrumentation layer (or other more-efficient mechanisms); they would
need to provide a translation layer from the SnmpAdminString indices
sent on the wire to the integer indices used internally.

The impact of snmpAdminStrings on resource-constrained systems can be
controlled by implementers (for read-only tables) and operators (for
read-write tables) by using short strings, such as "t1", "vp2", "at3",
etc.

In
Xdsl2LineConfTemplateTable/xdsl2ChConfProfileTable/xdsl2LineAlarmConfT
emplateTable, forcing operators to look up the number for a
template/profile/alarmtemplate rather than using the human-friendly
name of the template/profile/alarmtemplate makes it harder for
operators. In my opinion, using SnmpAdminStrings seems appropriate
here.

It might be good to have a manageability considerations section that
discusses using short strings and internal choices to minimize the
resource impact.

> 
> 
[..]

> Editorial Comments
> 
> 
> E7. The text in the DESCRIPTION clause of the MIB module 
> duplicates text
> in the Overview section. No need for both, actually here I think
that
> the better place is in the overview, but the main thing in my 
> view is to
> eliminate one of them to reduce the length of the text 
> 
I hesitate to see a blanket one-or-the-other decision.

In deciding which text is better in the Intro or the MIB module, keep
in mind that text in the MIB module might be presented as
mib-parsing-tool-generated help screens by an NMS. Text in the Intro
section almost certainly will not be used to tool-generate help
screens. So if the information would be useful to an operator when
actually using the MIB module, that information might be best in the
MIB module DESCRIPTION. If it is just background info that will not be
useful for runtime help screens, then the Intro should be fine.

dbh


_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS at ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors