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

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 1 Oct 2001 13:45:32 -0400

Time I got this out, just to get discussion going.  The rest will follow
soon.

Substantive Issues
==================

Section 5.2:
-----------
sipServiceOperStatus: since the status values are supposed to be mapped to
applOperStatus, why not just use the values of the latter, adding values
above them where they are lacking?
Currently:
    applOperStatus: up(1), down(2), halted(3), congested(4), restarting(5),
quiescing(6)
    sipServiceOperStatus: up(1), down(2), testing(3), unknown(4), halted(5),
restarting(6)

sipServiceAdminStatus: 
- What value would be read when the entity is operating normally?
- The descriptions of the values should indicate what operational status
transitions they bring about.

sipServiceStartTime, sipServiceLastChange DESCRIPTION: sysUpTime is not
defined -- should there be a reference?

sipMaxSessions: is "session" equivalent to call-leg in a UA, transaction in
any other entity?  Should the description say so?  What value is put in for
a stateless proxy?

sipInviteTimeOut: appears to apply only to UAs, hence may belong in the
SIP-UA-MIB.  We need a corresponding entry for default registration
timeouts, at both the UAC and the Registrar ends.

General comment: should it be possible to retrieve on a read-only basis the
capabilities of  the SIP entity as expressed in the Allow, Supported, and
Accept headers respectively?  Supported has its equivalent in the
sipFtrSupportedTable, but the other items also need definition.

Might want a read-write object corresponding to Accept-Language.

sipFtrSupported: should this have provision for feature version?  Or will
new versions mean new option tags?

sipCommonCfgTimerxxx: Do we really need timer settings per method?  The RFC
2543bis description of behaviour distinguishes between two transmission
timing situations: regular requests (not INVITE or ACK) vs. INVITE.  For the
former we actually need two timer settings: for the initial value T1 and the
upper bound T2.  For INVITE we need just T1, which could differ from the T1
for other methods.  We also, absolutely, need the application-level timer
defined as sipCfgTimerProv.

sipCfgRetryxxx: are these meant to control the number of times a transaction
of the given type will be reinitiated when the previous attempt has met with
4xx or 5xx failure or has died due to reaching the retransmission limit?
This would be like the automatic retries done by a FAX machine, but I
suspect it wouldn't be generally useful -- better to rely on user
reinitiation except perhaps for REGISTER requests.  Or do they set the
maximum number of retransmissions?  The latter control is not needed: the
maximum number of retransmissions is set unequivocally by the RFC.

sipCfgRetryNonFinalResponse: clearly meant for retransmissions, and useless
unless the 100rel feature is being used.
 
Nits and editorial
==================
Need an IANA Considerations section.

General: capitalize MUST, SHOULD, SHOULD NOT, MAY.

Section 4:
-----------
first para (top of p. 4): slight redundancy, slightly garbled.  I suggest
that the fourth and fifth sentences be replaced by:
"SIP-COMMON-MIB contains common objects used in all the SIP entities.
SIP-SERVER-MIB contains objects for Registrars, Proxies, and Redirect
servers, and SIP-UA-MIB contains objects for User Agents."

Next para: change "Each MIB Module contain following.." to "The MIB Modules
contain the following.."

The final para, after the list of MIB contents, might more clearly read:

"To conform with this specification, an SNMP agent MUST implement
SIP-MIB-SMI, SIP-TC, plus one instance of SIP-COMMON-MIB and one instance of
the SIP entity-type-specific MIB (SIP-SERVER-MIB or SIP-UA-MIB) as
applicable for each instance of a SIP entity being managed.  Section 4.2
describes handling of multiple instances in detail."

Section 4.2:
-----------
First para: I suggest this sentence be inserted after the first sentence, to
capture your thought:
" ...SNMP agent. This can happen because the same system supports multiple
SIP entity types."

Second para is really unclear and somewhat redundant with section 4.  I
suggest it be rewritten as follows (if I have understood correctly what you
meant to say):

"In either case, the operator may choose to represent the system as an
aggregate entity, requiring one copy of the SIP-COMMON-MIB and a copy of the
SIP-SERVER-MIB and/or the SIP-UA-MIB as required.  Alternatively, each SIP
entity instance may be associated with its own copy of the SIP-COMMON-MIB
and its own copy of the SIP entity-type-specific MIB.  This latter mode of
operation provides the requirement for supporting multiple instances of a
particular MIB module in one system."

I suggest you add this sentence at the end of the third para to make clear
what applIndex is being used for:
"The applIndex is then used to distinguish SIP entity instances in the
SIP-COMMON-MIB and the SIP entity-type-specific MIBs."

Description of how to populate applName, final bullet beginning "for a SIP
entity acting in...": suggest it begin as follows:
" o  For any combination of Proxy, Registrar, or Redirect Server being
managed as a single aggregate entity, the applName ... "

Next para, beginning "Additionally, the following objects ..." can be
rewritten to reduce redundancy and at the same time eliminate the note
following the specific object mappings if it is written as follows:

"The SNMP agent MAY support any combination of the other attributes in
applTable.  If the following objects are supported, the object values SHOULD
..."

In the bullets for applUptime and applLastChange, SIP-COMMON should be
SIP-COMMON-MIB.

Example 1: suggest the first sentence be modified slightly to read:
"The tables below illustrate how a system acting as both Proxy and Registrar
server might be configured to maintain separate SIP-COMMON-MIB instances."
In the rest of the example, change "would be populated" and "is populated"
to "might be populated".

Example 2: modify the first sentence to read:
This example illustrates how to represent a system acting as both Proxy and
Registrar server, where the two entities share a single instance of
SIP-COMMON-MIB.

Section 5.2:
-----------
sipCommonMIB DESCRIPTION: don't repeat the definitions of the different
entities -- just refer back to the 2543 definitions section.

sipCommonCfgEntry DESCRIPTION: insert the word "instance" after the word
"entity" at the beginning of the second line.  (The word "those" is not
needed in the first line.)

sipOrganization DESCRIPTION: suggest the description (which currently quotes
the definition of the Organization header) be modified to read:
"This object contains the organization name which the SIP entity inserts
into Organization headers which it adds to SIP messages processed by it.  If
the string is empty no Organization header is to be generated."

sipPortStatus: description should say whether elements of the row can be
modified when RowStatus is Active.

sipFtrSupported: the description should indicate whether the complete path
(i.e. org.ietf.sip.xxx) has to be entered for IETF-standardized features.

sipCfgInitialTimerInvite: description should specify that this is the
initial value T1 for the retransmission timer.

References:
----------
[18]: misprinted name, quotation marks.  Should be:
   N. Freed, S. Kille, "Network Services Monitoring MIB", ...

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

---

From: Jean-Francois Mule <[email-masked]>
Date: Wed, 24 Oct 2001 12:38:22 -0700

Tom,

This email summarizes our responses to Tom Taylor's comments Part 1 
received on 10/01/2001. Please review & comment as we need more 
clarifications on some of the comments you submitted.

Thank you for your comments on ietf-sip-mib-draft03.
Jean-Francois.

 > -----Original Message-----
 > From: Tom-PT Taylor [mailto:[email-masked]]
 > Sent: Monday, October 01, 2001 10:46 AM
 > To: [email-masked]'
 > Cc: [email-masked]'; [email-masked]'; [email-masked]';
 > [email-masked]'
 > Subject: Review of draft-ietf-sip-mib-03.txt Part 1
 >
 >
 > Time I got this out, just to get discussion going.  The rest
 > will follow soon.
 >
 > Substantive Issues
 > ==================
 >
 > Section 5.2:
 > -----------

 > sipServiceOperStatus: since the status values are supposed to
 > be mapped
 > to applOperStatus, why not just use the values of the latter, adding
 > values above them where they are lacking?
 >
 > Currently:
 >     applOperStatus: up(1), down(2), halted(3), congested(4),
 > restarting(5), quiescing(6)
 >     sipServiceOperStatus: up(1), down(2), testing(3), unknown(4),
 > halted(5), restarting(6)
agreed, we need the 2 to converge; see the rewrite proposal sent on the
mailing list on 10/12- jfm, fixed.

 > - What value would be read when the entity is operating normally?
see new proposal;
when this object is queried, get a noop value return.
" Setting this object to a value of noop(1) has no effect.
   When read, this object always has a value of noop(1)."

 > - The descriptions of the values should indicate what
 > operational status transitions they bring about.
the correlation is now clear based on the rewrite - jfm, fixed.

 > defined -- should there be a reference?
no need to reference the def of sysUpTime (rfc1213, mib 2)
this is too common, kevin, done.

 > sipMaxSessions: is "session" equivalent to call-leg in a UA,
 > transaction
 > in any other entity?  Should the description say so?  What
 > value is put in for a stateless proxy?

sipMaxSessions:
In the beginning, we had sipMaxCalls.
Based on rfc2543bis04, we propose to rename this object back
to sipMaxCalls as the notion of call is defined.  It seems
that the term session is only defined in SIP in the context of
SDP session.
It seems you can have multiple call-legs per session.

 > timeouts, at both the UAC and the Registrar ends.
1/ we think the object sipInviteTimeOut could be used by call stateful 
proxies as
well.
2/ We agree we have an issue for the default registration timeouts in uac.
We propose to add sipRegContactDfltExpiryDuration object to sipuamib as we had
before in server mib draft-02 w/ some description changes.
=> kevin to take first stab at the objects.

 > General comment: should it be possible to retrieve on a
 > read-only basis
 > the capabilities of  the SIP entity as expressed in the Allow,
 > Supported, and Accept headers respectively?  Supported has its
 > equivalent in the sipFtrSupportedTable, but the other items also need
 > definition.

More clarification is requested.
1. do you suggest to add a table reflecting the headers an implementation
supports?
2. do you suggest to add another object in that table that
give more details per header of what capabilties are there?
=> any comments from the group on that topic?  useful, not useful...

 > Might want a read-write object corresponding to Accept-Language.
RFC2543 section 6.9, uses a string to indicate preference for language.  Are
you asking for an additional object of type string to configure this?
(=> Kevin, to insert sip common config table upon confirmation)

 > sipFtrSupported: should this have provision for feature version?  Or
 > will new versions mean new option tags?
no, it's a string for non-std features, vendors can
include their own version info in the string if desired.

 > sipCommonCfgTimerxxx: Do we really need timer settings per
 > method?  The
 > RFC 2543bis description of behaviour distinguishes between two
 > transmission timing situations: regular requests (not INVITE
 > or ACK) vs.
 > INVITE.  For the former we actually need two timer settings: for the
 > initial value T1 and the upper bound T2.  For INVITE we need just T1,
 > which could differ from the T1 for other methods.  We also,
 > absolutely,
 > need the application-level timer defined as sipCfgTimerProv.
based on your second email, issues resolved or moot.

 > sipCfgRetryxxx: are these meant to control the number of times a
 > transaction of the given type will be reinitiated when the previous
 > attempt has met with 4xx or 5xx failure or has died due to
 > reaching the
 > retransmission limit?  This would be like the automatic
 > retries done by
 > a FAX machine, but I suspect it wouldn't be generally useful -- better
 > to rely on user reinitiation except perhaps for REGISTER requests.  Or
 > do they set the maximum number of retransmissions?  The latter control
 > is not needed: the maximum number of retransmissions is set
 > unequivocally by the RFC.
based on your second email, issues resolved or moot.

 > sipCfgRetryNonFinalResponse: clearly meant for retransmissions, and
 > useless unless the 100rel feature is being used.
yes, true, this was added in the context of 183 with SDP
discussions which led to the 100rel discussion and draft.
This object is still be useful in that context, we suggest to
keep it.

 > Nits and editorial
What do you mean exactly?
Do you mean we need to add a generic IANA consideration
section about the oid registration for e.g.
Do you have any specific items in mind like for example the
applName values for sip entities? any other object
values??? ... just want to make sure we get the full comment
here.

 > General: capitalize MUST, SHOULD, SHOULD NOT, MAY.
yes.  Updated front/backmatter sections - jfm, done.
question: do you mean inside the mib too?
=> kevin

 > Section 4:
 > -----------
 > first para (top of p. 4): slight redundancy, slightly garbled.  I
 > suggest that the fourth and fifth sentences be replaced by:
 >
Updated 04alpha revision doc, done. kept tom's first sentence
as-is, modified second sentence as follows:
"SIP-SERVER-MIB contains objects specific to Registrars, Proxies and 
Redirect servers, and SIP-UA-MIB includes objects specific to User Agents."

 > Next para: change "Each MIB Module contain following.." to "The MIB
 > Modules contain the following.."
agreed; done.

 > SIP-MIB-SMI, SIP-TC, plus one instance of SIP-COMMON-MIB and one
 > instance of the SIP entity-type-specific MIB (SIP-SERVER-MIB or
 > SIP-UA-MIB) as applicable for each instance of a SIP entity being
 > managed.  Section 4.2 describes handling of multiple instances in
 > detail."

ok, changed to
"To conform with this specification, an SNMP agent MUST
implement SIP-TC, plus one instance of SIP-COMMON-MIB and one
instance of the SIP entity-type-specific MIB (SIP-SERVER-MIB
or SIP-UA-MIB) as applicable for each instance of a SIP entity
being managed.  If a device has more than one sip entity or
multiple instances of the same entity, it SHOULD implement
multiple SIP modules. Section 4.2 describes handling of
multiple instances in detail."

 > Section 4.2:
 > -----------
 > First para: I suggest this sentence be inserted after the first
 > sentence, to capture your thought:
 > " ...SNMP agent. This can happen because the same system supports
 > multiple SIP entity types."
ok, added - jfm.

 > suggest it be rewritten as follows (if I have understood
 > correctly what
 > you meant to say):
 >
 > aggregate entity, requiring one copy of the SIP-COMMON-MIB
 > and a copy of
 > the SIP-SERVER-MIB and/or the SIP-UA-MIB as required.  Alternatively,
 > each SIP entity instance may be associated with its own copy of the
 > SIP-COMMON-MIB and its own copy of the SIP entity-type-specific MIB.
 > This latter mode of operation provides the requirement for supporting
 > multiple instances of a particular MIB module in one system."
we agree this need to be looked at. We will rewrite the text.
=> kevin to work on cleaning up the paragraph.

 > I suggest you add this sentence at the end of the third para to make
 > clear what applIndex is being used for:
ok, jfm, done

 > Description of how to populate applName, final bullet beginning "for a
 > SIP entity acting in...": suggest it begin as follows:
 >
ok, jfm, done

 > applTable.  If the following objects are supported, the object values
 > SHOULD ..."
ok, jfm, done

 > In the bullets for applUptime and applLastChange, SIP-COMMON should be
ok, jfm, fixed.

 > "The tables below illustrate how a system acting as both Proxy and
 > Registrar server might be configured to maintain separate
 > SIP-COMMON-MIB
 > instances."
jfm, ok, done.

 > In the rest of the example, change "would be populated" and "is
 > populated" to "might be populated".
jfm, ok, done.

 > This example illustrates how to represent a system acting as
 > both Proxy
 > and Registrar server, where the two entities share a single
 > instance of SIP-COMMON-MIB.
jfm, ok, done.

 > Section 5.2:
we (Kevin and jean-francois) disagree. It is good to have them right in the 
mib for nm
admins and it is not that long.

 > "entity" at the beginning of the second line.  (The word
 > "those" is not needed in the first line.)
ok, done.

 > sipOrganization DESCRIPTION: suggest the description (which currently
 > quotes the definition of the Organization header) be modified to read:
 >
 > into Organization headers which it adds to SIP messages
 > processed by it.
 > If the string is empty no Organization header is to be generated."
ok
=> KEVIN - udpate to mib modules
    jfm to update to doc, done.

 > modified when RowStatus is Active.
we agree some txt should be added.
=> kevin to propose text.

 > sipFtrSupported: the description should indicate whether the complete
 > path (i.e. org.ietf.sip.xxx) has to be entered for IETF-standardized
 > features.
We will add the following
"For IETF standardized features, the complete path (eg,
org.ietf.sip.xxx) should be reflected in this table.
=>  kevin - add this after last sentence in 3rd para (starting
w/ Similarly,..), kevin to update the mib
   jfm - updated the doc, done.

 > initial value T1 for the retransmission timer.
based on later email received from you, we assume this comment is no longer 
valid.

 > References:
ok, fixed.

Thanks a lot for all the comments.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

_______________________________________________
Sip mailing list  http://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