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

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 13 Nov 2001 13:27:50 -0500

Sorry to take so long to answer this.  I've just come off a particularly
grueling road trip.

I've deleted the parts where I have no further issue.

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Wednesday, October 24, 2001 3:38 PM
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Review of draft-ietf-sip-mib-03.txt Part 1

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
 [snip]

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

[PTT] My basic intent was that it be possible to retrieve through the MIB
the same information that would be presented in each of these headers.

 > 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)

[PTT] Yes, that's what I intended.

[snip]

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

[PTT] Actually, as soon as I sent that E-mail, I came to Kevin's note
raising the same question.  I still wonder whether retransmission timers
need to be configured per method or just on the simpler basis suggested by
the RFC.

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

[PTT] Are you sure?

[snip]

 > Nits and editorial
 > ==================
 > Need an IANA Considerations section.
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.

[PTT] I was speaking from a generic point of view.  Looking through the SMI
registrations, I note that you need to register the MIB names, so that
should be mentioned.  Beyond that I don't see anything at the moment which
isn't registered by other means.

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

[PTT] Yes, I would think it applies to the comments inside the MIB.  Maybe
this isn't the practice?

[snip]

 > Section 5.2:
 > -----------
 > sipCommonMIB DESCRIPTION: don't repeat the definitions of the
 > different
 > entities -- just refer back to the 2543 definitions section.
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.

[PTT] Just make sure that your definitions agree with the original
documentation, then.  I wasn't sure they did, but I didn't check.

[snip]