Subject: [midcom] NAT-MIB review

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Sep 2003 18:05:10 +0200

Bert asked me to play the MIB doctor for the NAT-MIB and so I have
reviewed <draft-ietf-nat-natmib-06.txt>. The document needs further
editorial work in order to comply with the MIB guidelines as
documented in <draft-ietf-ops-mib-review-guidelines-02.txt> and there
are several technical questions that need to be discussed and resolved
before the document is ready to go.

 1) The abstract should not contain references, see also the guidelines
    document.

 2) I suggest to add definitions of key terms into section 3. In
    particular, I would like to see a definition for concepts such
    as sessions, groups and probably owners. Also the relationship
    to other MIDCOM work needs to be explained since the MIB module
    talks about "MIDCOM compliance" and I have no clue what that
    means (see also below).

 3) In the overview section, you should say that this MIB module
    depends in some parts on the IF-MIB.

 4) In the overview section, please introduce the names of the tables
    and use these names where appropriate to reduce any risk for
    confusion. Some phrases I think are a bit confusing, e.g.

   o two scalars used to monitor address thresholds and generate 
     notifications when the thresholds are crossed.
    
    I do not think you monitor thresholds. In fact, these thresholds
    define when notifications are generated. (And my later reading of
    the MIB makes me wonder whether the second one is ever used.)

 5) typo "... the currently exist ..." -> "... that currently exist ..."

 6) Section 4.1 says:

   The association between the various configuration tables can be
   represented as follows:

     per interface config   (global config parameters)
        |                            |
        |                            |  
        |                            |
        |----------------------------|                       
        |                       
        |                      
     address map     
 
    My understanding is that the global config parameters are just
    a few scalars and not a table.

 7) Section 4.3 says that binds which point to non-existing address
    maps are not allowed. In the MIB definitions, it would be very
    useful to say precisely what happens if one tries to violate the
    rule (that is, which error code is actually generated when I try
    to delete an address map with pending binds or try to create a
    bind which points to a non-existing address map).

 8) You seem to use the RowStatus for two purposes -
    creating/destroying rows as well as enabling/disabling them. The
    compliance allows implementations that do only one-shot row
    creation and deletion, which means that those implementations
    do not have the capability to disable a row. Also note that a
    row in the notInService state has a timer attached so the row
    cannot be in that state for longer periods of time.

    Perhaps you want to introduce explicit enabled/disabled states for
    the rows in question in case it makes sense.

 9) The start of the module needs editorial work so that it conforms
    to section 4.5 in the MIB review guidelines document.

10) I suggest to also make the bit set representation of the protocol
    types an explicit TC so that both TCs are close together which
    reduces any maintenance issues.

11) What does an idle timeout of 0 seconds actually mean? (This
    question affects natConfUdpDefIdleTimeout,
    natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout,
    natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout.

12) I suggest to reword the description of the TCP idle timeout
    objects:

    natConfTcpDefIdleTimeout:

    The default time interval a NAT session (or is it a binding or
    both?) for an established TCP connection is allowed to remain
    valid without any activity on the TCP connection.

    natConfTcpDefNegTimeout:

    The default time interval a NAT session (or is it a binding or
    both?) for a TCP connection which is not in the established state
    is allowed to remain valid without any activity on the TCP
    connection.

    The point here is that the phrase "TCP protocol session" confuses
    me - do you refer to a NAT session for a TCP connection or
    something else?

13) I fail to see how the notification thresholds actually work. It
    seems to me that actually only the natConfAddrRiseThreshold is
    used. If my reading is wrong, the text probably has to be
    improved.

14) typo "... Groupn" -> "... Group"

15) The description of the natConfInterfaceTable should probably say
    that this is per interface configuration (and then you can remove
    the comment above ;-).

16) Why do you introduce natConfInterfaceIndex and not just import and
    use ifIndex?

17) What are the semantics of zero-length natConfAddrMapConfigName
    values? Can I actually have multiple natConfAddrMapConfigName
    objects with the same value? If not, what happens if I try to
    create them? And why do you identify address maps by name when all
    the other entities are identified by numbers?

    Also, I find the description confusing since this does not
    according to my understanding select a set of address maps but
    rather a single address map.

18) The StorageType TC requires you to specify which objects are
    writable if the storage type is permanent - see also section 4.6.4
    in the MIB review guidelines document. This is missing in all
    places where StorageType is being used.

19) I fail to understand the concept of the OwnerId and GoupId. What
    does the value 42 tell a management station? I think this concept
    is important to introduce in the beginning of the document.

20) What precisely happens if I write a value != 0 to
    natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom,
    natConfGlobalPortTo on a basic NAT?

21) I think the number space for address binds (e.g. natAddrBindId,
    natAddrPortBindId) should exclude the value 0. Perhaps it actually
    makes sense to introduce TCs doe NatAddrBindId and
    NatAddrBindIdOrZero so things will be consistent.

22) The description of natAddrBindDirection says:

            "This object represents the direction of the BIND.
             A BIND may be either uni-directional or bi-directional,
             same as the orientation of the address map, based on
             which this bind is formed."

    Where in the address map is the direction specified?

23) Please say precisely which error is to be generated if you set
    natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non
    existent addrMapName.

24) Should natAddrBindMaxIdleTime natAddrPortBindMaxIdleTime and
    natSessionMaxIdleTime not use syntax TimeInterval instead of
    TimeTicks?

25) You may want to rename all counters ending in *Translate to
    *Translates to follow the old rules that counters are in plural.

26) The natAddrBindTable, natAddrPortBindTable and natSessionTable
    have no StorageType, see the MIB review guidelines document.

    (In general, one can also ask why these tables are not part of the
    configuration branch since I can do row creation here. Also there
    are counters in the translation tables which are actually
    statistics. Personally, I would just drop the branches since they
    serve no real value and only increase the length of the OIDs.)

27) What is the "query id" you refer to in the description of
    natAddrPortBindLocalPort and natAddrPortBindGlobalPort? If you
    mean the ICMP type code, then please say ICMP type code.

28) In the number space for session, you really want to exclude the
    value 0. Again, it might help to introduce specific TC(s).

29) What is the relationship between binds and sessions? Your MIB
    is modelled as if it is 1:n, that is you can have n sessions
    for one bind. Is that the case?

30) Is there redundant information? Can a session have a different
    protocol type than the associated binds? Or why are
    natSessionProtocolType and friends needed?

31) Looking at this description:

    natStatsAddrMapAddrUsed OBJECT-TYPE
        SYNTAX     Gauge32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION
                "The number of addresses, pertaining to this address map,
                 that are currently being used from the nat pool. The
                 value of this object is irrelevant if the address map in
                 question is a static address map." 
        ::= { natStatsAddrMapEntry 6 }
    
    What does it mean that the object is irrelevant? Should it still
    be implemented (if not clarify in the compliance definition). If
    implemented, should it still report the correct value or can it
    contain arbitrary garbage?

32) I propose to rename the following objects for consistency:

    natStatsInterfacePktsIn  -> natStatsInterfaceInTranslates
    natStatsInterfacePktsOut -> natStatsInterfaceOutTranslates

33) I suggest to change the notification registration as follows:

    natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 }

    natAddressUseRising NOTIFICATION-TYPE
        -- yada yada
        ::= { natMIBNotifications 1 }

    natPacketDiscard NOTIFICATION-TYPE
        -- yada yada
        ::= { natMIBNotifications 2 }

    This again saves a sub-identifier and makes things more compact.

34) The description of natAddressUseRising makes me beliefe that the
    falling threshold is actually never being used.

35) Why can you not use natConfAddrMapName instead of natAddrMapName
    in the natPacketDiscard notification? And since you only
    distinguish two discard reasons, why do you not simply use two
    different notifications? This would avoid the introduction of
    natPktDiscardReason. (In general, accessible-for-notify is kind of
    a strange construction and this is why I wonder about these
    objects.)

36) In the compliance section, you always talk about "MIDCOM
    compliance" and I have no clue what that means.

37) I think there are dependencies between the natMIBNotif*Groups and
    you probably want to spell them out since it does not make sense
    to implement the natMIBNotificationGroup without the other
    natMIBNotif*Groups.

38) I think section 9 is not really needed since this OID assignment
    will happen automatically when this document is being processed.

39) In the security considerations, you simply state that "some of
    these objects could contain sensitive information, e.g. bind
    information". For someone deploying this, it might be useful to
    have a more explicit discussion of the security implications.

40) Remove the leading quote character in teh Full Copyright Statement
    section.

That's it.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: [email-masked]
Date: Sun, 28 Sep 2003 21:12:06 -0500

Hi Juergen,

   I have started working on the comments and you should expect the new
draft and communitcation
   to the midcom related to the changes on or before 10/19.

  Thanks
  Rohit

Juergen Schoenwaelder <[email-masked]> on 09/17/2003 01:24:10
AM

Please respond to [email-masked]

To:    Rohit Mehendiratta/C/UTStarcom@UTStarcom
cc:    [email-masked], [email-masked], [email-masked],
       [email-masked], [email-masked], [email-masked],
       [email-masked]
Subject:    Re: [midcom] Re: Fwd: RE: NAT-MIB review

On Mon, Sep 15, 2003 at 01:02:56AM -0500, [email-masked]
wrote:

>   1.  As Suresh also mentioned that Midcom MIB is not published yet;
thats
>       why MIDCOM Compliance/Owner Id/Group Id  may not make much sense.
>       What should we do in this case ?

As I wrote in another email: Either wait until the MIDCOM MIB is ready
to go as well or put these objects in place at a later point in time by
using AUGMENTS or whatever is a good choice to handle things.

>  2.  > > >
>    In the last revision, i had mentioned snmp error code as
>    inconsistentErrorValue but there were comments that this error code
>    is only specific to some snmp version and hence
>    we shouldn't mention it. I would like to know your opinion on the
same.

The formal argument would be that inconsistentValue is part of the
official SNMP standard and everything else is historic. The more useful
response is that there is a well-defined mapping of SNMPv3 error codes
to SNMPv1 error codes, see RFC 3584 section 4.4.

> 3. I will remove storageType objects on the next version as i don't see
>    much use of them in this MIB.
>    Let me know your opinion about the same.

The MIB review guidelines say that you should have StorageType columns
on tables that have RowStatus columns. Why do you think a storage type
is not of much use? Do you assume that all the rows created by a manager
are volatile on all implementations?

> 4. It is my undretstaning that in most of the customer scenarios, the
binds
>    and sessions are generated dynamically while addrmaps are configured.
>    Thats why we have separate branches for config and translation.
>    Even if the bind and session have the rowStatus, i don't anticipate
>    it to be used widely.

I am not sure whether it helps anyone to have different branches for
things that are configured and things that are not (or unlikely to be
configured). But despite this debatable view of the world, I am
wondering why some tables have RowStatus columns which you do not
consider to be used for configuration...

> 5. Related to notification changes, we will simplify it a lot in the next
>    version.

OK. But it would be good to get the WG involved in the changes and to
have the WG agree to the changes.

/js

--
Juergen Schoenwaelder             International University Bremen
 <http://www.eecs.iu-bremen.de/>        P.O. Box 750 561, 28725 Bremen,
 Germany