Subject: [MIB-DOCTORS] MIB doctor review of draft-ietf-softwire-dslite-mib-12

From: Dave Thaler <[email-masked]>
Date: Tue, 1 Dec 2015 19:54:38 +0000

I was assigned to do the MIB doctor review of this document, since I previously
did an early review of -03.  My full comments are in the marked up copy at
http://research.microsoft.com/~dthaler/draft-ietf-softwire-dslite-mib-12.pdf
Below is a summary of the issues called out therein.

Substantive issues:

1)      RFC 4001 requires each InetAddress object to explicitly state

which other InetAddressType object indicates the type.  None of the objects

in this document do so.  RFC 7659 (the NATv2 MIB) does, and can be used as

an example.

2)      dsliteNATBindEntry includes dsliteTunnelStartAddPreLen in the INDEX.

To confirm this was intended: Can you really have 2 entries that have all

other INDEX values the same and differ only in the prefix length?

3)      dsliteNATBindTable states that it extends natv2PortMapTable in RFC 7659,
but rather than reusing the not-accessible objects from that table in its own

INDEX clause, it defines its own.  That's fine, but it is then not clear whether

each such object in the dsliteNATBindTable INDEX needs to match

a corresponding value in the natv2PortMapTable INDEX,

or whether there can be additional entries that do not

appear in the natv2PortMapTable.   This should be clarified.

4)      Many objects in that table, such as dsliteNATBindMappingIntRealm,

have very terse DESCRIPTIONs, whereas the DESCRIPTION of

the corresponding object in the natv2PortMapTable is quite

detailed.  Hence this draft is far less clear than RFC 7659,

since this draft has no such language.

5)      Objects of type InetAddress incorrectly have a REFERENCE

clause pointing to the definition of the InetAddress TC.

REFERENCE clauses should be used to point to the spec defining

the semantics, rather than the syntax.  For example,

dsliteNATBindMappingIntAddress is incorrect, whereas the

corresponding object in RFC 7659 (natv2AddressMapInternalAddressType)

is correct and points into the DS-Lite RFC (RFC 6333).

6)      I didn't understand DsliteNATBindEntry at all.  Its

dsliteNATBindMappingMapBehavior object has a value

addressAndPortDependent(2) which "maps to a separate external

address and port combination for each different

                destination address and port combination reached
                through the same external realm".   However, the external port
                is in the INDEX clause and the destination address does not appear to be
in the table at all.  Since the 0 value for the external port already has a different
special meaning, it can't be 0 either.   So I don't understand how this table
can work.

7)      dsliteAFTRAlarmProtocolType is underspecified.  It's a string,

but the description is very confusing as to what the legal string

values are, making it sound more like an INTEGER was intended.

("This object indicate the protocol type of alarm,
                0:tcp,1:udp,2:icmp,3:total")

E.g., does that mean the string is "0:tcp" or "0" or "tcp" or what?

8)      The dsliteStatisticTransmitted object seems to combine sent + received

packets into a single counter with a name that implies only one direction.

This is confusing, especially since most other MIB modules separate sent

vs received into different counters.

9)      dsliteAFTRUserSessionNumAlarm and dsliteAFTRPortUsageOfSpecificIpAlarm

both refer to "the threshold" without stating what threshold that is.

There doesn't seem to be any such threshold object in this MIB module or

elsewhere that I could find.

10)   dsliteAFTRAlarmScalarGroup is mandatory and requires read-write access.

But a lesson learned from the NAT MIB (and many other MIBs) is that many

people don't want write support in their MIB modules.  Does the WG really

feel that write support is required in all implementations?  I'd recommend

also having a read-only compliance statement, as is done in many other

MIB modules.

11)   The security considerations section uses the correct boilerplate for

sensitive read-only objects, which includes "These are the tables and

objects and their sensitivity/vulnerability".  However it then only

lists the tables/objects and contains no discussion of their sensitivity/vulnerability.

This is required in order to comply with MIB review guidelines in RFC 4181.

12)   Per discussion on MIB Doctors, the root OID should probably not be

{ transmission xxx }, since that space usually implies that xxx is an ifType

(not tunnel type) value.

13)   A number of undefined terms are used that I could not find in the DS-Lite

RFC (6333) either, e.g., connection, session, etc.  As such, I couldn't tell what

was meant, and whether there were issues with the meaning.  At minimum,

REFERENCE clauses should be added to point to a specific section of a document

that defines the terms.

Editorial issues:

14)   The title, abstract, MIB module name, etc. all say the MIB module is for

managing DS-Lite, but DS-Lite has two roles: AFTR and B4, and this document

only instruments the AFTR.   Hence I would really recommend putting AFTR

in the title, abstract, and name.

15)   There are a bunch of editorial issues (grammar, typos) that should be

cleaned up before publication.

16)   In a number of places, it seems to refer to some objects in some MIB module,

whether this document or RFC 7659, without stating the name of the object

so it is not clear which object was meant.

17)   The document still refers to draft-perrault-behave-natv2-mib

and should be RFC 7659.

Dave