Subject: [Sip] Re: Review of draft-ietf-sip-mib-03.txt Part 2

From: Kevin Lingle <[email-masked]>
Date: Mon, 28 Jan 2002 19:34:04 -0500

tom,

below please find our responses to this second round of 
comments.  sorry for the delay.

if you are satisfied with the answers, we'd like to produce
a new revision of the draft (-04) and wish you to give it
one final look.  we are seeking your final approval so we
can consider sip wg last call on this draft complete and
proceed with the next step: rfc-editor.

thanks for your time and insight in reviewing this draft!

> Tom-PT Taylor wrote:
> 
> Further comments
> ================
> SIP-COMMON-MIB (cont'd)
> 
> A further remark on sipInviteTimeout: in principle we need an
> application-level timeout value for each method, not just INVITE.  We
> might possibly get away with one for initial INVITE and one for all
> other requests.  Clearly the expected turnaround for a REGISTER will
> be different from that for a PRACK, but both of them should finish in
> a few seconds at most rather than the minutes an initial INVITE could
> take.  I will again question whether application-level timers belong
> in SIP-COMMON-MIB or in SIP-UA-MIB.

we removed sipInviteTimeout and created sipCommonCfgExpiresMethodTable
to deal with the Expires header values more generally with app-level
expiration timer.

> 
> sipMethodStatsEntry: INFO method should be treated like all other
> extensions, rather than appear explicitly in this table.

we made a conscious decision to include INFO related object back in
rev -02 of the draft.  INFO was formalized by RFC 2976 in 10/2000,
so we felt comfortable including.  therefore, we've retained INFO
related object in the draft mibs.

> 
> sipSummaryTotalTransactions: description should indicate what a
> transaction stateless proxy does with this counter (probably leaves it
> at 0).

ok. we added...
 "For a transaction stateless proxy, this counter is always 0."   
to the description.

> 
> sipStatsInfoIns, Outs: shouldn't be given special treatment -- belong
> in the sipStatsExtMethodTable with all the other method extensions.

see the answer regarding sipMethodStatsEntry above.

> 
> SipStatusCodesEntry: should "other" class entries be defined, for
> status codes 700 and up?

ok. we added two new object to the sipStatusCodesTable:
  sipStatsOtherClassesIns
  sipStatsOtherClassesOuts

> 
> sipStatsRedirClassIns, Outs: 3xx responses don't necessarily come from
> Redirect Servers -- UAs could be set up to forward calls, for
> instance.  Hence the phrase "taken by a Redirect Server" in the
> description is inappropriate.

ok. we removed the phrase.

> 
> sipStatsServerFailClassIns, Outs: final sentence of description
> defines SIP protocol behaviour, not SNMP Agent behaviour, hence should
> be omitted.

ok.  we removed the final sentence from the descriptions.

> 
> sipStatsGlobalFailClassIns, Outs: ditto

ok.  we removed the final sentence from the descriptions.

> 
> sipStatsExtMethodStatus: description is a bit sparse.  Would something
> more along the lines of the description for sipCommonStatusCodeStatus
> not be desirable here too?

yes, we fleshed out the description with the same text you reference.

> 
> sipStatusCodeNotifTo, From, CallId, CSeq: do the reported values
> include the header keywords themselves, or only the part following the
> colon? (e.g.) "From:xx..x" vs. "xx..x"

ok.  we added to the descriptions saying "header name" is part
of the value and examples were given.

> 
> sipCurrentTransTable: need something be said about transaction
> stateless proxies?

ok.  we added words that this table and sipTransactionTable do not
apply to transaction stateless proxies.

> 
> sipCurrentTransEntry: typo in description -- should be "entity's"
> rather than "entities'".

fixed typo.

> 
> SipTransactionEntry: need an object identifying the method which
> initiated the transaction.

ok.  we added a new object ... sipTransMethod (SnmpAdminString)...
to the table.

> 
> sipTransTo, From, CallId, CSeq: do the reported values include the
> header keywords themselves, or only the part following the colon?
> (e.g.) "From:xx..x" vs. "xx..x"

ok. we added to the descriptions saying "header name" is part
of the value and examples were given.
 
> 
> sipTransState: most of these states apply only to INVITE transactions,
> and  some of them (null, completed, confirmed) do not apply to
> transactions currently in process.  I would suggest instead capturing
> the latest activity in the transaction.  This has two parts: direction
> (received/sent) and status code value or request (the latter being
> either the initiating request or ACK).

we attempted to align the states with bis05, but it proved difficult
to reconcile the differences between rfc2543 and bis05.  some states
match for INVITES while not for other methods and vice versa.
therefore, we did not change any state values in the mib.  
we adding text to the description noting that not all values of the 
object are applicable to all transaction types.   is that ok, tom?

we did add one new string object to deal with the "latest activity"
issue you raised.  we gave examples of what that string value might
look like for both direction and requests vs. responses.
(see sipTransActivityInfo object in next revision)

> 
> sipTransExpiry: behaviour will be affected by the outcome of my
> initial remark on sipInviteTimeout.

<<< J-F, please check... this is suppose to match up w/ or be in
    line with the answer to the first comment>>>

> 
> sipTransCallingPartyContentType, sipTransCalledPartyContentType: nice
> try, but it doesn't work.  Content type varies from message to message
> within a transaction.  Perhaps these objects could record the
> aggregation of content types over all messages so far passed in the
> transaction -- that would reflect your intent.

not sure we understood your suggestion, but it sounded like too
much information and too complicated, so we punted ;)... removed
the objects from the mib.

> 
> 
> SipCommonStatsRetryEntry: as with sipMethodStatsEntry, the INFO method
> should be treated like all other extensions, rather than appear
> explicitly in this table.

same answer as given above wrt why we included and wish to retain
INFO related objects.

> 
> sipOtherStatsEntry: typo in description -- should be "entity's" rather
> than "entities'".

fixed typo.

> 
> sipNotifApplIndex: doesn't point to the actual status code being
> monitored.  Shouldn't it be the same structure as the index of
> sipCommonStatusCodeTable?

we had already discovered this.  we fixed it by including in/out
counter objects from sipCommonStatusCodeTable.  the applIndex
will be implicitly conveyed by these objects' OIDs.

> 
> SIP-UA-MIB
> ==========
> 
> General comment on configuration: should there be a requirement to
> populate the SIP-COMMON-MIB data for each entity before populating
> this MIB?  How is this expressed?

we don't believe we need (should) provide this level of detailed
guidance in the MIB.  it ventures too far into the realm of
implementation.

> sipUAMIBNotifs is empty.

it was a placeholder for the future.  not notifs were identified so
we've removed it.

> 
> Where is the definition of sipUAStats??

another placeholder.  none were ever identified.  we've removed it.

> 
> sipUACfgSipServerEntry: should say that applIndex for each entity
> instance has the same value as used for that instance in the tables of
> SIP-COMMON-MIB.

ok.  we added...
"The same value of applIndex used in the corresponding 
SIP-COMMON-MIB is used here." 
to the description.

> 
> Might it be desirable to configure the UA's Contact address?

providing this turned out to be more complicated than initially
thought.  we first thought the contact address could only be
present in a limited set of request and responses.  it turns out
to be a larger set than expected.  moreover, we don't think people
will really want to use the mib to configure this because the 
contact field is very user dependent and is likely to be better
controlled in the context of a application on top of sip.
that can take us away from pure sip protocol mgmt - which should
be the focus of these mibs.   therefore, we've not done anything
in the mibs regarding this comment.

> 
> SIP-SERVER-MIB
> ==============
> 
> General comment on configuration: should there be a requirement to
> populate the SIP-COMMON-MIB data for each entity before populating
> this MIB?  How is this expressed?

again, we don't believe we need (should) provide this level of detailed
guidance in the MIB.  it ventures too far into the realm of
implementation.

> 
> sipServerMIB: description has definitions of the different server
> types.  Would it be safer to refer to the RFC instead?  In any event,
> a Proxy does not initiate requests (as indicated in the definition of
> a Redirect Server).  It does propagate them.

it's useful to have explicit text in the mib for the implementor.  
we wish to leave it as-is. 
except we have removed the statement in redirect server section.

> 
> sipServerCfgEntry: should say that applIndex for each instance has the
> same value as in SIP-COMMON-MIB.  Question: should there be a
> RowStatus object?  Can values be changed on the fly?

part one:  ok.  added...
           "The same value of applIndex used in the corresponding 
            SIP-COMMON-MIB is used here." to the description.

part two: we do not wish to add a RowStatus object.  we're not sure 
          of a requirement to create/delete server entities in a system.

wrt "changing on the fly"... it would be implementation specific.

> 
> SipProxyCfgEntry: should there be a RowStatus object?

we do not wish to add a RowStatus object.  we're not sure 
of a requirement to create/delete server entities in a system.

> SipRegCfgEntry: ditto

ditto ;)

> 
> sipContactPreference: typed as an OCTET STRING.  Couldn't that be an
> IA5String, or is that not allowed in SNMP?

we changed the object to be a SnmpAdminString.

please let us know if you have and concerns/doubts about how we've
addressed your questions/issues.   once we've pulled together the
rev -04 of the draft, we'll pass it along to you for a final review.

thank you, tom!
SIP MIB Team

Kevin Lingle, Cisco
Joon Maeng, ipDialog
David Walker, SS8 Networks
Jean-Francios Mule

> 
> 
> 
> Tom Taylor
> [email-masked]
> Ph. +1 613 736 0961 (ESN 396 1490)
> 

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 28 Jan 2002 22:09:21 -0500

I'm happy with everything.

-----Original Message-----
From: Kevin Lingle [mailto:[email-masked]]
Sent: Monday, January 28, 2002 7:34 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]; Jean-Francois Mule; Dave Walker; Joon Maeng
Subject: Re: Review of draft-ietf-sip-mib-03.txt Part 2

tom,

ok. we added...

fixed typo.

 

fixed typo.

ok.  we added...

part one:  ok.  added...

ditto ;)

thank you, tom!
SIP MIB Team

Kevin Lingle, Cisco
Joon Maeng, ipDialog