Subject: IPOA-MIB last call comments

From: Gary Hanson <[email-masked]>
Date: Thu, 5 Feb 1998 14:03:30 -0800 (PST)

In general, I think that the IPOA-MIB design is sound and reasonably
complete, and it is also well documented.

I have a small number of substantive comments on the latest IPOA-MIB draft
(in draft-ietf-ion-mib-06.txt):

1.  A number of objects are listed in both the ipoaGeneralGroup and in the
    ipoaLisTableGroup.  They should only be listed in the latter, since
    they only need to be mandatory only for entities that support IP over
    ATM SVCs.  These objects include the following:
    - ipoaLisTrapEnable
    - ipoaLisSubnetAddr
    - ipoaLisDefaultMtu
    - ipoaLisDefaultEncapsType
    - ipoaLisInactivityTimer
    - ipoaLisMinHoldingTime
    - ipoaLisQDepth
    - ipoaLisMaxCalls
    - ipoaLisCacheEntryAge
    - ipoaLisRetries
    - ipoaLisTimeout
    - ipoaLisDefaultPeakCellRate
    - ipoaLisActiveVcs
    - ipoaLisRowStatus
    - ipoaLisIfMappingRowStatus
    - ipoaArpRemoteSrvrRowStatus
    - ipoaArpRemoteSrvrIpAddr
    - ipoaArpRemoteSrvrAdminStatus
    - ipoaArpRemoteSrvrOperStatus

    In other words, the only objects that to keep in the ipoaGeneralGroup
    include the following:
    - ipoaVcType
    - ipoaVcNegotiatedEncapsType
    - ipoaVcNegotiatedMtu
    - ipoaConfigPvcDefaultMtu
    - ipoaConfigPvcRowStatus

2.  I anticipate that some client agent writers may squawk at having to
    implement control objects and counter objects that apply to SVCs
    (i.e., objects to configure ATM addresses and to report ATMARP events)
    when they are building a PVC-only client.  Similarly, squawking may
    come from writers that are building an SVC-only client that have to
    implement counter objects relating to InATMARP events.  Perhaps it
    wouldn't be unwise to consider further dividing the compliance groups
    into finer categories, depending upon whether PVCs, SVCs, or both are
    supported.

    The objects I am referring to include those in the ipoaClientGroup.
    Splitting the objects into the following groups might be useful:
    
    ipoaClientMinGroup
    - ipoaArpClientRowStatus

    ipoaClientPvcGroup
    - ipoaArpClientInArpInReqs ... ipoaArpClientInArpInvalidOutReqs

    ipoaClientSvcGroup
    - ipoaArpClientAtmAddr
    - ipoaArpClientSrvrInUse
    - ipoaArpClientArpInReqs ... ipoaArpClientArpNoSrvrResps

    NOTE: I assume that ATMARP servers have to support InATMARP, anyway.
    Thus, there would be no benefit to split the objects that are in
    the ipoaSrvrGroup.

3.  It is not clear to me whether an agent implementation that includes
    both ATMARP server and client capabilities (for the same IP subnet)
    needs to increment the counters in both the ipoaArpSrvrTable and the
    ipoaArpClientTable or just the former table.  Or is it a genuine
    misconfiguration to have the same system configured with a client on
    subnet X and also to act as a server on subnet X?  I would imagine
    that this should be allowed, so I question how the MIB objects would
    be handled.

    For example, if an InATMARP request is received by such an ATMARP
    server, should the agent increment both the ipoaArpSrvrInArpInReqs
    object and the ipoaArpClientInArpInReqs object?

    Or should only the former object be incremented, in recognition of
    its role as an ATMARP server?

    Or should only the latter object be incremented, in recognition of
    its role as an IP over ATM client entity?

4.  Change "ARP PDU" to "ATMARP request" in DEFINITION of ipoaLisTimeout,
    since this only applies to ATMARP requests as far as I can tell from
    reading the DESCRIPTIONs of the ipoaArpClientArpNoSrvrResps and the
    ipoaLisRetries objects.

5.  What is the meaning of the parenthetical comment in the DESCRIPTION
    of up(1) under ipoaArpRemoteSrvrOperStatus?  It says:

           up(1)  - A VC exists to Remote ATMARP Server
                    whose IP Address is stored in
                    ipoaArpRemoteSrvrIpAddr.  This VC can
                    be determined by searching the
                    ipoaVcTable using
                    ipoaArpRemoteSrvrIfIndex (if not 0,      <-- ???
                    otherwise ignore ipNetToMediaIfIndex     <-- ???
                    index) and ipoaArpRemoteSrvrIpAddr.      <-- ???
                    An ipoaArpClientEntry should exist
                    with its ipoaArpClientSrvrInUse
                    object having the same value as
                    ipoaArpRemoteSrvrAtmAddr.

    How is the ipoNetToMediaIfIndex index to be ignored?  It is always
    included as an INDEX into an ipoaVcEntry.  I find this confusing.

6.  A number of objects have DESCRIPTIONs that use the terminology of
    "Virtual Circuit" or "circuit".  Elsewhere, the acronym "VC" is
    spelled out as "Virtual Connection".  The same conflict of terms
    occurs in the draft-ietf-ion-ipatm-classic2-03.txt text, where the
    usage of "Virtual Connection" from RFC 1577 clashes with the usage
    of "Virtual Circuit" from RFC 1626.  Kenneth White said he would
    only resolve this discrepancy if the same discrepancies were also
    resolved in the classic2 draft.

    Perhaps the best way to appease the two religious factions that
    prefer one term over the other would be to include both terms in
    equal amounts, as is probably the current case.  On the other hand,
    if there is an intended movement towards one term over the other,
    I would suggest picking one and sticking with it throughout, so
    that a document could at least be consistent with itself and its
    companion document(s).

    Perhaps as the first shot in the next round of what is probably a
    never-ending battle, let me state my preference for using the term
    "Virtual Connection" to denote what is intended by the acronym
    element "VC" (in the present context).  It would at least conform
    to the majority of terminology currently in use by the ATM Forum
    (as far as I can tell).

    The affected objects would include the following:
    - ipoaVcVpi
    - ipoaVcVci
    - ipoaVcType
    - ipoaVcNegotiatedEncapsType
    - ipoaVcNegotiatedMtu
    - ipoaConfigPvcVpi
    - ipoaConfigPvcVci

I also have a number of typographical errors to report, too.  You can stop
reading now if you do not plan on editing the document yourself, or if
you don't enjoy seeing the fallout of other people's hobbies (i.e., doing
nit-picks on MIBs :-).

1.  Remove extra space in "defines  transport" in 4th bullet in section 2.
2.  Change "exists to control and relect" to "exist to control and reflect"
    in 2nd sentence of last paragraph of section 3.1.3.
3.  Change "an PVC" to "a PVC" in first sentence after the diagram in
    section 3.1.4.
4.  Change "a ipoaConfigPvcRowStatus" to "an ipoaConfigPvcRowStatus" in
    3rd sentence of 2nd paragraph of section 3.1.5.
5.  Change "detects" to "detected" in first sentence of 4th paragraph
    after the diagram in section 3.2.1, to match object's DESCRIPTION.
6.  Change "an PVC" to "a PVC" in 2nd sentence of last paragraph of
    section 3.2.1.
7.  Change "a ATM" to "an ATM" in last sentence of section 3.3.2.

The next four items relate to indentation style, always a contentious
topic.  I just appears to me that a mixture of styles are in use, so I
am simply suggesting sticking with one style, and giving a recipe to
accomplish that as best as I can tell.

8.  Decrease indentation of MIN-ACCESS lines, DESCRIPTION lines, and the
    actual DESCRIPTION text for object ipoaLisDefaultMtu through object
    ipoaLisDefaultPeakCellRate (pgs. 41 through 43) by 4 columns.
9.  Increase indentation of all of the OBJECT lines for objects
    ipoaLisIfMappingRowStatus through ipoaArpClientArpOutNaks (pgs. 43
    through 45) by 1 column.
10. Decrease indentation of MIN-ACCESS lines, DESCRIPTION lines, and the
    actual DESCRIPTION text for the objects named in item 9 by 4 columns.
11. Decrease indentation of DESCRIPTION text for ipoaSrvrNotificationsGroup
    and ipoaLisNotificationsGroup by 4 columns, to match above groups.

Thanks for considering these comments.

Regards,
Gary

---

From: Albert Manfredi <[email-masked]>
Date: Thu, 05 Feb 1998 17:46:44 -0500

Gary Hanson wrote:

[ ... ]

>     that this should be allowed, so I question how the MIB objects would

If a box is running both ATMARP client and server modules, would
this not entail a different set of MIB objects for each module? Not
sure how this would work, but that was my impression.

[ ... ]

>     resolved in the classic2 draft.

[ ... ]

>     to the majority of terminology currently in use by the ATM Forum

Boo hiss.

A "virtual connection" describes a TCP/IP session. ATM is more than
just a TCP/IP session. Or different, anyway, so we don't sound like
we're making a value judgment!

Bert
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.