[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Discuss on draft-ietf-iptel-trip-mib-08.txt

At 12:03 PM 9/18/2003 +0200, Wijnen, Bert (Bert) wrote: 
Often we can/could state "much more text would be helpfull".
Is it mandatory before we accept this as a PS? We have quite a few
MIB documents that take similar approach. Ideal? No!
Acceptable? I'd say: yes, certainly for PS level.


Hmmm.  In the interest of consistency, I will accept your
opinion, but...

It did take me about 1/2 hour to determine the high level
structure of this MIB from looking at the ASN.1.  I also
had to flip back and forth between the MIB and the TRIP
spec just to understand that purpose of some of the tables
and objects, and I'm still not sure that I understand
the relationship between the tripPeerTable and the
tripRouteTable well enough to know if the way that the
two tables are indexed will be adequate when trying to
manage the TRIP protocol using this MIB.

There is basically no textual description of the structure
of this MIB, but if this level of description has been
considered acceptable in the past, I guess we should be
consistent now.

>     TripAddressFamily ::= TEXTUAL-CONVENTION
>         SYNTAX INTEGER { decimal(1), pentadecimal(2), e164(3) }
>
>     TripAppProtocol ::= TEXTUAL-CONVENTION
>         SYNTAX INTEGER { sip(1), q931(2), ras(3), annexG(4) }
>
> >> Is there a reason not to include an "other(x)" option in the two
> >> enumerations above?  An "other(x) option might be useful in the
> >> future, if additional application protocols or address families are
> >> defined.
>
Interesting... In other cases we have received comments that "other"
should be removed cause it does not specify anything specific.
Oh well...


There are times when I think that "other(x)" is useful and times
when I think it isn't...  In this case, it seemed likely to me
that the WG might later specify new address families or application
protocols for TRIP.  If/when that happens, the updated MIB will
probably lag...  So, it would be good to add an "other(x)" clause,
so that the MIB will be useful during that expansion period.

If I'm misunderstanding, and there is not likely that additional
address families or application protocols will be added later,
then I withdraw my comment.

> >> These objects might also benefit from an "other(x)" and/or
> >> "unknown(x)" option.

I do not think that "other" or "unknown" make sense for the xxxAdminStatus.
I also think that "faulty" is generic enough that it can encompass any
"other" or "unknown" states.

I can accept this.

> >>  Also, are you expecting these objects to
> >> reflect the state of the whole system, or only of the TRIP
> >> application.  For instance, if TRIP is running properly and ready
> >> to service messages, but the IP stack has (temporarily or
> >> permanently) lost its network connectivity, would you expect the
> >> tripOperStatus to be up or down?
>

Mmm... since this MIB Module is NOT layered on top of the interface stack,
I do not think we need to worry about that. It is like all application
level MIB modules. One might also wonder... so what if IPstack is in shambles?
In that case, there will be no way to read these objects anyway?

Seriously... I think these represent the status at the application layer
and so I do not think they should take into account all the lower layers.

The description in the MIB is less clear about this...

The description for tripCfgOperStatus says:

"up(1):  The application is operating normally, and is processing
        (receiving and possibly issuing) TRIP requests and responses."

Would it leave this state (and go to faulty) if the application
wasn't receiving periodic TRIP requests and/or if it was
receiving errors when trying to send TRIP responses?

>     tripCfgAddr OBJECT-TYPE
>         SYNTAX      InetAddress
>         MAX-ACCESS  read-only
>         STATUS      current
>         DESCRIPTION
>             "The network address of the local LS that the peer c
>             onnects to. The type of address depends on the object
>             tripCfgAddrIAddrType."
>
> >> Is there a trip protocol restriction that all instance of
> >> TRIP that run on a single box must be reached at the same
> >> IP address?  If not, then this variable (and its associated
> >> type) should probably move to the tripRouteTypeTable).
>
A question for the WG to answer.

But even if the answer is YES, then I am still not sure that we need
a table. Maybe the answer could be: s/The network addres/A network address/

Anyway, if the SNMP agent is listening to port 161 on all IP addresses
on the box, then an SNMP manager will be able to read this (and other)
objects via all IP addresses.


My concern wasn't about what IP addresses could be used for the SNMP
connection.  This variable indicates what IP address is used for the
peer connection, and it clear (from the fact that we have a peer
table if nowhere else) that there may be many peers.  Do all of
those peers connect to the same address?  If not, then it probably
makes sense to have an address per peer.

BTW, can there be more than one peer for a single instance of TRIP?
Or is there only one peer per instance of the protocol?  That's
something else I'm having trouble understanding from the structure
of the MIB.

> >> How is one expected to locate the correct tripPeerTable entry for
> >> the peer identified in the tripRouteTable?  Why not just use the
> >> tripPeerIdentifier to reference the tripPeerTable?
>
The tripRouteTable also has an object tripRoutePeer (which is part of
the tripRouteTable index) that can be used to find the peer. This
of course means reading the tripPeerTable till you find the proper
entry. Is that the best perfomance wise? probably not.
But if you go the other way, namely how to find the entry in the
tripRouteTable, then using tripId is part of the index and can
be used to do fast/direct retrieval. So it seems as if that is
the sort of look ups that the WG expects to see most.
Of course WG should answer if that is true.


This is what I was trying to figure out...  Since there isn't
any description of how these tables relate to each other and/or
how this MIB is likely to be used, I am having trouble
understanding if the current indexing will work well.

Do we usually just assume that the WG has considered these
issues and made good design decisions in these areas?

> >> There doesn't seem to be a way to specify read-only compliance.
> >> Is it intended to require that all TRIP MIB implementations are
> >> read-write?
>
If there is no specific xxxReadOnlyCompliance, then the WG apparently
has decided (either consciously or by default) that all implementations
MUST indeed support both read-only AND read-write access. Many WGs
do so and in general we (as MIB doctors are OK with that).

Okay.

>    [RFC1657] Willis, S., Burruss, J., and Chu, J., "Definitions of
>              Managed Objects for the Fourth Version of the Border
>                Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
>                1994.
>
> >> Why is this a normative reference?  I don't think it should be
> >> required to understand the BGP MIB in order to read this MIB.
>
I think I agree here... In fact, looking at 1657 once more... I even
wonder if their claim "managed objects for TRIP are also modeled after
RFC1657 ..." is true. I do not see that much resemblence.


It didn't look all that familiar to me, and I've done some work
on a BGP MIB...  If they started with the BGP text, I think it is
okay to give credit, but it shouldn't be normative.

Margaret