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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
