Subject: Re: (ION) IPOA-MIB last call comments

From: [email-masked]
Date: Mon, 9 Feb 98 05:17:18 EST

Gary,

>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:

I had already fixed this after the last draft was submitted. The
change will be in the 07 version that I will post after the review
is completed on the 11th.

>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.

I'm not convinced that this is necessary. Does anyone else have
an opinion?

>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.

I think that it is possible that a system have both a client and server
configured for the same subnet.

>   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?

I agree with Albert's comment on this:

   "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."

The client and server in this case should be considered separate
entities. ipoaSrvrGroup and ipoaClientGroup OBJECT-GROUP definitions
indicate when each set of objects are to be implement. Don't
try and combine them. When a server receives a InATMARP request
it increments its counter.

>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.

Read paragraphs 3 and 4 in section 3.1.3 on page 7.

>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.

There is not consensus that this needs to be done.

I have revised the internet draft and will post a new version
latter this week.

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

---

From: Paul Koning <[email-masked]>
Date: Mon, 9 Feb 1998 09:59:02 -0500

>>>>> "kennethw" == kennethw  <[email-masked]> writes:

 >> 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.

 kennethw> I'm not convinced that this is necessary. Does anyone else
 kennethw> have an opinion?

I'm not about to implement SVC-related objects in a PVC-only
implementation.  (Didn't we have some discussion about that a few
months ago?)  The MIB should support us in that, so we don't have to
explain to people that the objects are missing because they don't
apply even though the MIB doesn't say so.  That's just not acceptable.

	paul

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 09 Feb 1998 18:17:13 -0500

Ken,

>I have revised the internet draft and will post a new version

Gary is sitting right next to me at the moment and we went over your
message.  He is happy with all of the changes, and he says "ship it!".

Thanks,
Andy

________________________________________________________________________
Andrew G. Malis  [email-masked]  phone:978 952-7414   fax:978 392-1484
Ascend Communications, Inc.        1 Robbins Road     Westford, MA 01886