[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 1
inline.
Kevin,
Great idea to combine tripRouteTypeTable and tripPeerRouteTypeTable.
I wish I had seen that.
DZ
----- Original Message -----
From: "Kevin Lingle" <klingle@cisco.com>
To: <iptel@lists.bell-labs.com>; <iptel@ietf.org>
Sent: Tuesday, November 19, 2002 3:38 PM
Subject: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 1
> hi,
>
> i have some comments on the latest version of this I-D.
>
> Section 6.1 - TRIP-TC module
> ----------------------------
> 1) TC TripApplProtocol DESCRIPTION...
> change "document" to "MIB module"
Done
>
> 2) TC TripSendReceiveMode...
> can you explain each enumerated value w/in the DESCRIPTION?
> eg,
> "The operational mode of the TRIP applications.
>
> sendReceive(1) : <description here>
> sendOnly(2) : <description here>
> receiveOnly(3) : <description here>"
>
I've added the text to the DESCRIPTION clause, but I'm not sure there
is anything left to add as far as descriptions, they are pretty self-
explanatory.
>
> Section 6.2 - TRIP-MIB module
> -----------------------------
> 1) tripCfgTable...
> Thee table DESCRIPTION says..
> "The objects in this table should be nonVolatile and
> survive reboot."
>
> - why don't you have a object of type StorageType in
> this table as you do for others? seems it should
> for consistency since you mention it in the descr
> here. such an object would only need r/o access.
done, made this object with r/w access.
> - what if a platform cannot provide NV storage of
> the info in this table across reboots? is this
> a requirment formalized by TRIP or more "desired"
> behavior? ie, is it really SHOULD or MUST?
The "desired" behavior of this object is stated by the
defval nonVolatile. I think this should be enough.
> 2) tripCfgProtocolVersion...
> consider moving "RFC3219" to a REFERENCE clause.
> (i made a similar comment before wrt referencing
> I-D for this object)
done
> 3) tripOperStatus...
> we discussed this a bit in a previous version of
> the mib. i asked you to consider another operstatus
> value to reflect when there was a fault in the system.
> you asked whether we really needed that because faults
> will be covered by notifications. i responded with
> reasons why that answer wasn't sufficient. of course
> i left it as your call, so i guess i should just shut up.
> reading the mib again, though, the same thing struck me.
> it wasn't until i reviewed my email archive did i discover
> we'd already been over this issue.
>
> exactly how is this handled by notifications? which
> notification reflects a general fault with the trip LS?
I think you mean tripCfgOperStatus. I'm not sure what happened here,
this issue may have fallen through the cracks. Sorry. I will add
a 'faulty' state.
>
>
> 4) tripCfgAddrInetAddrType...
> "tripAddr" -> "tripCfgAddr"
>
> 5) tripCfgAddr...
> i'd generalize "IP address" to just "address" and
> add words referring back to the InetAddrType object
> as the indicator of what type of address this object is.
done
> 6) tripCfgPort...
> why is port configurable (r/w) while address object
> isn't?
I've lost much of my email since these were written, but
I seem to remember talking about this with Dave W. I believe
that the consesus was to allow the user the flexibility to
use whatever port was needed, but allowing a change of
inet addr would impact too much on the TRIP network. Any
TRIP experts to set me straight on this?
> 7) tripCfgMinItadOriginationInterval...
> "report" -> "reports"
>
> 8) tripCfgSendReceiveMode...
> "trip" -> "TRIP"
>
> 9) tripRouteTypeProtocolId...
> this object contains the following in the DESCRIPTION:
> "The size value of 116 has been assigned due to the
> sub identifier of object types length limitation as
> defined in SMIv2."
>
> what does that statement mean wrt this object?
> the SYNTAX TripApplProtocol doesn't shed any light.
>
> i'm confused. maybe the next comment will make
> this all a moot point... read on.
I changed the type of TripApplProtocol to integer.
I missed fixing that comment.
> 10) tripRouteTypeTable vs. tripPeerRouteTypeTable
> can't these tables be combined? add one additional
> object to differentiate "remote" from "local" and
> then you'd no longer need the address family objects
> form both tables to be both read-only AND part of
> the INDEX clause... it could truely be the more
> "correct" not-accessible ;)
>
> see the attached file for a stab at what a combined
> table might look like.
That's a great idea. My only concern is that much of the
info for the local entry is redundant, but.... it's better
than a redundant table.
Thanks, I'll make the change.
> 11) tripSupportedCommunityTable...
> is "The TRIP Communities attribute" the same as
> the tripSupportedCommunityId object used to index
> this table? is so, make is clearer that the
> indexing object of this table is that attribute.
Made the description clearer.
> 12) tripSupportedCommunityEntry...
> need a period at the end of the DESCRIPTION.
done
> 13) tripSupportedCommunityStorage...
> is it a TRIP requirement (in a protocol sense) for
> such information to be NV? will a platform that can't
> meet such requirements be considered non-compliant?
it is not a requirement. Fixed in description.
> 14) tripPeerTable...
> presumably entries in this table are remote peers only, right?
yes
> 15) tripPeerState...
> a) be more clear on local vs. remote references.
> when you say "to the peer" or "from the peer"
> are you referring to the "remote peer"? if
> so please be explicit in the description.
I think I've made the description clearer now.
> b) how do you have a entry in 'idle' state?
> what types of "resources" are you referring to
> as not being allocated to the peer? obviously,
> it wouldn't include resources used to represent
> the mib table entry ;)
> c) how long does 'idle' state usually persist? is
> is generally so transient as to not be a useful
> state to represent in the mib??
True, the idle state should not persist for very long at
all unless the TRIP admin status was set to down. Then
the idle state should be constant.
> d) add a space in description of 'established' value.
> "NOTIFICATION,and" -> "NOTIFICATION, and"
done
> 16) tripPeerAdminStatus...
> a) is there a valid DEFVAL for this object or must
> it be given for row creation to succeed? if the
> latter is the case, mention that in RowStatus object.
Gave it a defval of up(1)
> b) what is the relationship between values of
> tripPeerAdminStatus and the values of tripPeerState?
> down -> idle??
>
> ( i believe i asked about this before and david was
> going to look into it. )
Fixed in comments. If tripPeerAdminStatus is down, then the state
would be idle(1).
> 17) tripPeerConnectRetryInterval...
> DESCRIPTION says...
> "Attempt to set this value higher than the max
> retry should not be allowed."
> state more strongly... "will not be allowed".
done
> 18) tripPeerDisableTimer...
> should "of the peer" be "of the remote peer"?
done
> 19) tripPeerStorage...
> again, the issue of what about platforms that may
> not be able to do nonVolatile? seems this needs
> to be generally addressed throughout the mib.
done. It is not a requirement that this storage be non volatile.
> 20) tripPeerRowStatus...
> the presense of this object would indicate that this
> table can be provisioned. must it be or can some
> of these entries be learned via the workings of the
> protocol?
Some entries can be learned. I will make this clear in the
description.
> 21) tripPeerStatsTable...
> a) "stats" -> "statistics"
> b) qualify when "this peer" or "the peer" is
> referring to "remote" peer. total messages
> counter objects are explicit while the other
> objects in the table aren't.
done
> 22) tripPeerFsmEstablishedTime...
> say "entered 'established' tripPeerState."
done
> 23) tripRouteAddress...
> can you explain to me exactly how the 105 size limit
> was reached? i presume it has something to do with
> the size of each index component and the overall object
> identifier length for objects in this table. i
> didn't attempt to do the math, so could you summerize?
> you say "prefix"... it this then some limited form
> of the address - limited due to SMI issues?
Here is what the RFC says:
Address:
This is an address (prefix) of the family type given by Address
Family. The octet length of the address is variable and is
determined by the length field of the route.
It is limited because of SMI issues. Although I understand
that this limitation might go away soon.
> 24) tripRouteTRIBMask...
> please expand TRIB acronym on first use.
> any rfc 3219 reference for these type bits?
> what does each type mean - more than just
> "adj-TRIBs-ins".
made the description clearer.
> 25) tripRouteLocalPref....
> any REFERENCE for this?
yes, fixed.
> 26) tripRouteAdvertisementPath & tripRouteRoutedPath...
> a) any REFERENCE for this?
yes
> b) say "sequence of TripItads" rather than integers.
> that will establish what per itad boundaries are
> w/in the octet string (ie, ever 4 octets).
> c) i presume you mean each itad is in network byte order,
> right? but what is the ordering of the entire sequence
> of itads? which end of the overall octet string do you
> start reading the path from?
>
I believe it a sequence from local to remote.
> 27) tripRouteAtomicAggregation...
> not specific to this route table object, but in
> general does the capability represented by this
> object need to be made configurable somewhere?
This is not a configurable item. It is a boolean based on the
decision of an LS selection of a route.
> 28) tripRouteWithdrawn...
> how is this removal of a route accomplished?
The transmitting LS has determined that a route should
no longer be advertised, and is propagating this information
to its peers.
> 29) how many route table entries can there be in a system?
I think it virtually unlimited depending on available resources.
Should this be stated somewhere?
> 30) how many communities can be associated with a route?
Again I think it is resource dependent.
>
> i probably have other comments on remaining portions of
> the mib and draft doc, but i have to stop now. i'll
> email more tomorrow.
>
> kevin
>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Kevin R. Lingle 919.392.2029
> checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/
> Sometimes I think I understand everything, then I regain consciousness.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel