Subject: IP Tunnel MIB updated

From: Dave Thaler <[email-masked]>
Date: Wed, 28 Apr 1999 18:32:15 -0400 (EDT)

I just submitted an updated draft of the tunnel MIB in response to
recent comments as a result of the IETF last call.

Keith McCloghrie wrote:
> 1. Dave's email address in the MODULE-IDENTITY is "[email-masked]"
>   which I suspect has a typo :-), and

Fixed.

> 2. I think it would be good if the DESCRIPTION of tunnelConfigIfIndex
>    could have additional information about when the object is
>    instanciated.  For example, it could specify that the agent does
>    not instanciate this object until the row is set to 'active' and the
>    agent has assigned the ifIndex value.

Changed tunnelConfigIfIndex SYNTAX to InterfaceIndexOrZero and
added more text to DESCRIPTION of this and the row status object.
Specifically, if the status is active, then tunnelConfigIfIndex
contains an ifIndex.

John Shriver wrote:
> SST tunneling is over a particular UDP socket.  Would you
> have tunnelIfEncapsMethod be "other" in that case?  
[...]
> I don't plan to implement ATMP (RFC 2107), but how would
> that be coded? 

Added values of tunnelIfEncapsMethod and tunnelConfigEncapsMethod
for AMTP (RFC 2107), and UDP (e.g. RFC 1234, draft-finlayson-umtp-*.txt
which isn't referencable, etc).

Bert Wijnen wrote:
> - The SNMP boiler plate should talk about "SNMP Management Framework"
>   and not about "SNMPv2 Management Framework". Title of sect 3 to be
>   fixed.
> - I think section 3.1 is redundant and should be removed.
>   The text is part of the Boilerplate you picked up.
> - I think that the organization in the MODULE-IDENTITY should be
>   the IFMIB WG, no?
> - If I understand your intentions, then an SNMP management station cannot
>   create entries in the tunnelIfTable. So I think that the few read-create
>   columns you have defined in that table should be read-write instead?
> - You should specify a positive range, probably (1..2147483647) for the
>   Integer32 SYNTAX of tunnelConfigID.
> - I would also like to see a revision clause in the MODULE-IDENTITY with
>      "Initial version, Published as RFCxxxx" -- to be filled in by RFC-Editor
>   in the REVISION DESCRIPTION CLAUSE, so that we get the RFC number
>   listed right away when we come out as RFC.
> - there are quite a few references to work in progress documents.
>   are they normative? Then advancement of this mib would be held
>   up till they become RFCs I think.
> - fix up to new SMI RFC numbers

All fixed.

> - Section 4.1.2 talks about the ifTestTable. That table is being obsoleted
>   by the new ifmib2-00.txt doc that is heading for Draft Standard.
>   The ifmib WG does has a new testmib document out. I am not sure your text
>   is fully inline with the latest test MIB. Maybe the testType is the
>   thing that is defined by the encapsulation document.
>   Seems to me you want to adapt the text abit, or maybe this section is not
>   needed, because the testMIB is now no longer part of the IF-MIB.

Removed paragraph on ifTestTable usage since it's no longer required
by the ifmib for media-specific extension MIBs.

> - You are using IpAddress as an index. This is very IPv4 specific, and
>   certainly using an IPv4 address as an index is problematic when you
>   want to run in an IPv6 environment. You do talk about IPv6 at various
>   places, so it seems to me you want this MIb to be used in IPv6 environments
>   so you must fix this problem and not us IpAddress.

Removed language implying that this MIB was applicable to tunnels over
IPv6.  Clarified in introduction that this MIB is for tunnels over IPv4
only.

>   For [tunnelConfigIfIndex] I actually wonder if it should be of SYNTAX 
> InterfaceIndex
>   as defined in IF-MIB. I would also like to see some elaboration on how
>   the agent determines the proper index value? Or is this obvious for
>   people who are knowledgeable in the field?

Covered by change to InterfaceIndexOrZero as discussed above.

> - For tunnelConfigStatus, I think you need to add some more text describing
>   under which circumstances a row can become active and if other columns
>   can be changed if the row is active. See RFC2578 for RowStatus
>   DESCRIPTION requirements.

Added text to make the following clarifications:
*  A row in the config table is active as soon as the interface index
   has been assigned, regardless of whether the interface is operationally up.
*  Pointed out that no other writable columns exist in this table,
   but that corresponding objects in other tables are writable while
   the config table row is active.
*  Specified that the agent need not support setting tunnelConfigStatus
   to createAndWait or notInService (again, since there's no other
   writable objects in this table).

> - I wonder why anyone would implement the tunnelConfigStatus as read-only
>   (which you allow in th compliance statement). I thought that this table
>   is meant to allow an SNMP management app to create/configure tunnels.
>   So if there is no read-create access, then there would never be any
>   entries in this table, right? Or am I misunderstanding something here?

Clarified in initial text listing the tables that the config table also
provides an efficient way to map from the endpoint addresses to an 
ifIndex value.  Hence, it's still useful even as a read-only table.
Also clarified this in the DESCRIPTION clause of tunnelConfigTable.

The updated draft should appear as an I-D shortly, but in the meantime
you can find it at 
   http://www.eecs.umich.edu/~thalerd/draft-ietf-ifmib-tunnel-mib-03.txt

Ted, I don't know whether we need another WG last call, but if so
consider this a request for it to begin.

-Dave Thaler