[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Discuss on draft-ietf-iptel-trip-mib-08.txt
Since Dan ROmascanu played the MIB Doctor role at my request,
I have checked with hime for additional comments (if any).
Below is his reponse. Thanks Dan.
So it seems some of Margaret's comment may need some checking
with WG, but some do not seem to make much sense to us (MIB
dcotors). We hope we have explained to Margaret why we think so
and hope she will/can agree
Thanks,
Bert
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: donderdag 18 september 2003 15:04
To: Wijnen, Bert (Bert)
Subject: RE: Discuss on draft-ietf-iptel-trip-mib-08.txt
See in line. Regards, Dan
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: 18 September, 2003 3:00 PM
> To: Romascanu, Dan (Dan)
> Subject: FW: Discuss on draft-ietf-iptel-trip-mib-08.txt
>
>
> Dan, here is comments from one IESG member, and my responses
> to it. If you have time today (my IESG telechat is in 3.5 hours)
> to send any additional comments/answers, that would be appreciated.
>
> Thanks,
> Bert
>
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: donderdag 18 september 2003 12:03
> To: 'Margaret Wasserman'; iesg@ietf.org
> Subject: RE: Discuss on draft-ietf-iptel-trip-mib-08.txt
>
>
> Let me make some comments on your review.
> The Editorial comments are good and I assume Jon will
> handle them.
>
> > I have both substantive and editorial comments on this MIB. The
> > substantive comments are the subject of my DISCUSS, and the
> > editorial comments are merely suggestions for things that should
> > be fixed if/when the draft is updated.
> >
> > SUBSTANTIVE COMMENTS:
> >
> > The TRIP MIB module contains the following groups of objects:
> > o The tripConfigGroup contains the common configuration objects
> > applicable to all TRIP applications referenced by the
> applIndex.
> > [...]
> >
> > >> Much more text would be helpful that describes the purpose of
> > >> the tables within this MIB and their relationship to each
> > >> other. This list seems only to list the compliance groups,
> > >> without giving any real insight into the structure of the
> > >> MIB.
> >
> 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.
>
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.
> > TripAddressFamily ::= TEXTUAL-CONVENTION
> > STATUS current
> > DESCRIPTION
> > "A type of address for a TRIP route. Address families
> > defined within this MIB module are:
> >
> > Code Address Family
> > 1 Decimal Routing Numbers
> > 2 PentaDecimal Routing Numbers
> > 3 E.164 Numbers"
> >
> > SYNTAX INTEGER { decimal(1), pentadecimal(2), e164(3) }
> >
> > TripAppProtocol ::= TEXTUAL-CONVENTION
> > STATUS current
> > DESCRIPTION
> > "The application protocol used for
> communication with TRIP
> > Location Servers. Protocols defined in this MIB Module
> > are:
> >
> > Code Protocol
> > 1 SIP
> > 2 H.323-H.225.0-Q.931
> > 3 H.323-H.225.0-RAS
> > 4 H.323-H.225.0-Annex-G"
> >
> > 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...
> 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?
>
> > tripCfgAdminStatus OBJECT-TYPE
> > SYNTAX INTEGER {
> > up(1),
> > down(2)
> > }
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION
> > "The desired TRIP state.
> >
> > up(1) : Set the application to normal operation.
> >
> > down(2): Set the application to a state where it will
> > not process TRIP messages."
> > ::= { tripCfgEntry 4 }
> >
> > tripCfgOperStatus OBJECT-TYPE
> > SYNTAX INTEGER {
> > up(1),
> > down(2),
> > faulty(3)
> > }
> > MAX-ACCESS read-only
> > STATUS current
> > DESCRIPTION
> > "The current operational state of the TRIP protocol.
> >
> > up(1): The application is operating normally, and
> > is processing (receiving and possibly
> > issuing) TRIP requests and responses.
> >
> > down(2): The application is currently not processing
> > TRIP messages. This occurs if the TRIP
> > application is in an initialization state or
> > if tripCfgAdminStatus is set to down(2).
> >
> > faulty(3): The application is not operating
> normally due
> > to a fault in the system.
> >
> > If tripCfgAdminStatus is down(2) then
> > tripOperStatus SHOULD
> > be down(2). If tripAdminStatus is changed to up(1) then
> > tripOperStatus SHOULD change to up(1) if there is no
> > fault that prevents the TRIP protocol from moving to the
> > up(1) state."
> > ::= { tripCfgEntry 5 }
> >
> > >> 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.
>
> > >> 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.
> > 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.
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.
>
> > tripPeerState OBJECT-TYPE
> > SYNTAX INTEGER {
> > idle(1),
> > connect(2),
> > active(3),
> > openSent(4),
> > openConfirm(5),
> > established(6)
> > }
> >
> > >> Are there really no error or closing states possible for
> > >> the connection to the peer?
> >
> WG should answer this one.
Agreed.
>
> > tripRoutePeer OBJECT-TYPE
> > SYNTAX TripId
> > MAX-ACCESS not-accessible
> > STATUS current
> > DESCRIPTION
> > "The identifier of the peer where the route information
> > was learned."
> > ::= { tripRouteEntry 4 }
> >
> > >> Why is this object used to identify a peer in the tripRouteTable,
> > >> but the tripPeerTable uses:
> > >> INDEX { applIndex,
> > >> tripPeerRemoteAddrInetType,
> > >> tripPeerRemoteAddr,
> > >> tripPeerRemotePort }
> > >> as an INDEX?
> >
> > >> 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.
Your interpretation is correct. It is is acknowledged by the authors, some more text can help.
>
> > >> 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).
>
> What the MIB doctors do not like is that there is only one compliance
> statement that allows for read-only implementations to claim
> compliance. In that case we want to see a specific xxxReadOnly and
> an xxxFull complaince where the "Full" compliance includes the
> read-write. And even that is only a "want to see", not a "MUST".
>
> > EDITORIAL COMMENTS:
> >
> > Abstract
> >
> > This memo defines a portion of the MIB (Management
> > Information Base)
> > module for use with network management protocols in the Internet
> > community. In particular, it describes a set of managed
> > objects that
> > are used to manage for TRIP (Telephony Routing over IP) devices.
> >
> > >> s/used to manage for TRIP/used to manage TRIP/
> >
> > >> The word "referenced" is misspelled "referened" in a couple
> > >> of places.
> >
> > >> It would be more helpful to define acronyms (TRIB, ITAD...) when
> > >> they are first used, instead of later.
> >
> > 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."
> >
> > >> Formatting error in first line of description.
> > >>
> > >> Also, is it acceptable for this address to be a DNS name? If
> > >> not, then that restriction should be included in the
> > >> description.
> >
> > [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.
>
> Bert
> >
> >