[ipcdn] Comments to CableHome MIB drafts

[Elena Vengerova <[e-mail]>]

Hi Kevin,

here are my comments to CableHome MIB drafts. Possibly
in future I'll provide more comments about QoS MIB.

Generic:
~~~~~~~

1. Usuallyy SYNTAX is not specified in MODULE-COMPLIANCE.
Some MIB compilers consider this like an error.

2. Glossary:

    From on hand it's specified that all terms are defined in
CH specification. From other hand some terms are explicitly
defined. For example, Configuration MIB draft defins WAN-Man Address,
WAN Data Address, etc. (public and private address space
terms used in their definitions are not defined).
IMHO it's better to include to the RFC all CH terms used in this RFC.
    Another solution is create a separate draft with CH terminology used
in all MIB drafts.

3. RowStatus

   For tables with static and dynamic entries it's useful to mention,
if it's allowed to delete dynamic entries using RowStatus or not.

   It's not clear, why in many tables it's prohibited to assign
notInService value to RowStatus. If it's allowed to delete entry
and create it with changed parameters it should be allowed as well to set
RowStatus to notInService, change parameters and then set RowStatus to active.

Addressing MIB (draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt)
~~~~~~~~~~~~~~
1. Reference to RFC describing NAT is necessary.

2. It's also useful to clarify explicitly difference between basic NAT and
NAPT - many people think that NAPT is basic...

3. Overview: "which we call ..." is not quite appropriate for RFC document.

4. CabhCapPacketMode: description is not quite clear (binding/mapping of what?)

5. cabhCapPrimaryMode: the name is slightly confusing - it's not obvious why
it is called "primary". Clarifications are useful.

6. The question with ICMP sequence numbers issue is not clear.
It shouldn't be allowed to create static ICMP NATP entries.

7. It should be specified, what happens with static and dynamic
entries of cabhCapMappingTable when packet processing mode is changed.
Should NAPT entries be showed when NAT mode is enabled? Should
they be deleted? May be it's useful to add field "Inactive" to
mark entries which are really used at the moment?

8. It should be specified how the situation should be handled when
mapping Lan Address X -> Wan Address Y exists and after reboot
Y address is not assigned to the device.

9. It's necessary to ether rename cabhCapIcmpTimeWait to
cabhCapOtherTimeWait (i.e. all except UDP and TCP) or
create separate cabhCapOtherTimeWait object to control, for example,
IGMP entries timing out.

10. cabhCapMappingRowStatus:  cabhCapMappingWanAddrType
and cabhCapMappingLanAddrType have default values, so it's not
be required to set them before making of the entry active.

11. It's useful to define objects like cabhCapMappingIndexNext and
cabhCapPassthroughIndexNext for obteining of three indices
(see ATM MIB for example).

Configuration MIB (draft-ietf-ipcdn-cable-gateway-config-mib-00.txt)
~~~~~~~~~~~~~~~~~
1. This is MIB document - is it really necessary to duplicate there
text from the CH specification? It's a bad practice - you'll need
to synchronize the text between RFC and CH specification.

2. cabhCdpWanDataIpAddrCount: the behaivour of CDC after change of
this value should be described. Is it true that CDC should immediately
obtain additional addresses if the object value is increased?
Is it true that CDC should return some of its addresses (which ones)
if the object value is decreased?

3. cabhCdpLanAddrIp: it's not clear what should be done with table
entries if cabhCdpLanPoolStart or cabhCdpLanPoolEnd are changed
(for example, after reboot) and cabhCdpLanAddrIp does not fit to
the interval. Typo in description ("fom").

5. cabhCdpWanDnsServerOrder: Assume that we have three addresses:
A(1), B(2), C(3). Assume that we received two addresses
D and E , which are not equal to A, B and C. What should be in the
table" (D, E, A),  (D, E, C) or (D, E)? This should be explicitly
specified in the description.

6. Why different cabhCdpLanPoolStartType and cabhCdpLanPoolEndType
are necessary? How can these values be different?
Moreover, I think that it should be specified that it cannot be dns.
   The same is for cabhCdpServerRouterType, cabhCdpServerDnsAddressType,
cabhCdpServerDhcpAddressType and cabhCdpServerSubnetMaskType
(they shouldn't be dns and should be equal to type of the pool addresses).
Only address of SYSLOG server may be specified as a domain name.

7. cabhCdpServerTTL: I think that (1..255) is better.

Security MIB (draft-ietf-ipcdn-cable-gateway-security-mib-00.txt)
~~~~~~~~~~~~
1. The term "factory default policy" should be described in details.
It should be explicitly noted that rules of factory default policy are
necer showed via SNMP (do they).

2. cabhSec2FwPolicySelection: description is not clear. Moreover in fact
there may be four possibilities:
    a. No rules (no default rules, SNMP tables are empty).
    b. Only default rules (SNMP tables are empty).
    c. Only configured rules (no default rules, rules from SNMP tables are used).
    d. Default rules + SNMP rules.

    What happens when I set cabhSec2FwClearPreviousRuleset to increment?
Does agent need to populate SNMP table by default rules? The same question
is for incrementDefault.

    IMHO dependencies between cabhSec2FwPolicySelection and
cabhSec2FwClearPreviousRuleset should be described very carefully
in the introduction.

3. cabhSec2FwLogIpDestPort: typo in the description.

Tools MIB (draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt)
~~~~~~~~~
1. TCP connectivity testing: size and number of frames cannot be specified
using standard socket interface.

2. cabhCtpConnPktSize - size of which frames? UDP payload? IP packets?
Ethernet packets?

3. cabhCtpConnStatus: DEFVAL should be removed.

4. May be it's useful to specify that parameters like destination IP address
and number of packets shouldn't be changed while test is in progress?

Device MIB (draft-ietf-ipcdn-device-mibv2-05.txt)
~~~~~~~~~~
1. docsDevFilterInetProtocol: it should be specified how the protocol
should be extracted from the packet. It's not obvious for IPv6
(I mean, first "nextHeader" or last one should be used).

QoS MIB (draft-ietf-ipcdn-qos-mib-08.txt)
~~~~~~~
I'm not quite prepared for review of this MIB, however I have two notes
about packets classification:

1. docsQosPktClassIpProtocol - the same note as for docsDevFilterInetProtocol
in Device MIB.

2. Why IPv6 flow identifier is not used for packet classification?

Best regards,
    Elena

-- 
Elena A. Vengerova
OKTET Ltd.
Office: [phone]  Mobile: [phone]  Home: [phone]
E-mail: [e-mail]


_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn