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

[Margaret Wasserman <mrw@windriver.com>]

Hi Bert and Dan,

At 03:24 PM 9/18/2003 +0200, Wijnen, Bert (Bert) wrote:
> I agree with you here. Following Margaret's suggestion would be useful, 
> but the limits of 'how much is enough' and 'how little is too little' are 
> relative. The guidelines document says just this:
>
> .  The narrative part SHOULD include one or more
>    sections that briefly describes the structure of the MIB modules
>    defined in the specification.
>
> I agree that the authors approach scratches the minimal threshold, but 
> there are precedents when we let documents go with as little. . I do not 
> consider this comment being worth to belong in the 'Substantive' category, 
> and I do not think it is a show-stopper.

As I already said in a reply to Bert:

I'm not pleased with the level of textual explanation in this
document, but if this is typical of MIBs that go to PS, I can
accept it in the interest of consistency.

> > Interesting... In other cases we have received comments that "other"
> > should be removed cause it does not specify anything specific.
> > Oh well...
> > The WG should decide. But I think that they would rather have the doc
> > go through a review than have "other" added. Jon?
>
> Actually I think that there are good reasons. TRIP is defined to support 
> certain formats of numbers ('addresstypes' ) and work with certain IP 
> telephony protocol stacks. This may change in future versions of the 
> protocol, but the MIB will change as well, won't it?

Here is my response to Bert:

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

Your response seems to indicate that expansion is likely...

Is there a reason to believe that an updated MIB won't lag
behind any protocol expansion?

> > > >> 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.
>
> We deal here with software applications that have a good control of what 
> can be enabled or disabled, and a good understanding of the operational 
> status without the need for a supplementary vague value. 'Other' does not 
> make sense. Maybe Margaret has in mind a discussion in the Entity State 
> MIB, which takes the model from ITU Recommendation X.731 and defines the 
> value 'notSupported' for the AdminState and OperState TCs. What applies 
> for a generic MIB like Entity MIB, which may deal with subagents of 
> different flavor does not necessarily apply for these objects.

I can accept your and Bert's opinion.

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

Here is my response to Bert:

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?

In other words, will this application be considered "faulty" if it
isn't sending/receiving requests and responses?  Or only if the
application itself has been set to a state where it isn't
trying to send/receive requests and responses?

I'm not suggesting that this object _should_ encompass the status
of the stack, just that the description could be clearer about
what this object does encompass.

> > > >> 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.
>
> Pay attention - my understanding is that this object is NOT about 
> management address. I am not sure that the SNMP example is necessarily 
> relevant. I think that the authors made some assumptions about 
> reachability of the TRIP instances, that would benefit of some extra 
> explanatory text.

Yes, I think it would be good to get an explanation from the authors.

> > 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.
>
> Your interpretation is correct. It is is acknowledged by the authors, some 
> more text can help.

This might have been helped by text that described the structure
and purpose of this MIB.  I am probably just misunderstanding the
relationship between the peer table and the route table...  but
that's pretty easy to do, given that the relationship isn't
really documented at all.

Thanks for the quick feedback, Dan!

Margaret