Subject: [Sip] Comments on draft-ietf-sip-mib-06.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 6 Jul 2003 16:00:29 +0300

Here are my comments concerning the latest version of the SIP MIB. I congratulate the authors for a much better document, and I thank them for taking into account and including fixes to most of the problems that were included in the review I did on the previous version. 

There are still a few problems that need to be fixed:

A1) smilint complains about the following:

SIP-COMMON.txt:2014: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2 -- for sipStatusCodeValue --
SIP-COMMON.txt:2940: [5] {group-unref} warning: current group `sipCommonNotifObjectsGroup' is not referenced in this module

A2) You would like to re-consider the OID place holders that you created for sipRedirCfg, sipRedirStats, sipRegCfg, sipRegStats.
This is not an SMI violation, but it creates for the time being a hole in a MIB walk. If you need to add the definition of the respective objects in the future, you will not be able to do it in the same document, without the need to re-cycle the document at Proposed Standard level. 

A3) DESCRIPTION Clause of sipServiceNotifEnable -  Saying that in case notifications are not implemented, the value has 'no meaning and MUST be 0', seems contradictory and inaccurate. The respective sentence should read - 'The notifications are OPTIONAL, and if they are not implemented, this object's value MUST be all 0s.'

A4) How does sipNotifSequenceNumber work? It should probably be increased once for each notification defined in the SIP MIBs, but not for each notification target (in the case of multiple managers). I suggest this to be detailed in the DESCRIPTION clause for clarity.

Minor editorial issues:

B1) English syntax in section 4.1. It should probably read 'The data type SipTransportProtocol is used as Textual Convention in this document. Textual conventions have...'
B2) Eliminate the commented text in the SIP compliance module of the UA MIB.  

Regards,

Dan

---

From: Kevin Lingle <[email-masked]>
Date: Wed, 30 Jul 2003 17:37:24 -0400

dan,

thanks for the comments.  see responses/questions inline...

Romascanu, Dan (Dan) wrote:
> Here are my comments concerning the latest version of the SIP MIB. I 
> congratulate the authors for a much better document, and I thank them 
> for taking into account and including fixes to most of the problems that 
> were included in the review I did on the previous version.
> 
> SIP-COMMON.txt:2014: [5] {integer-misuse} warning: use Integer32 instead 
> of INTEGER in SMIv2 -- for sipStatusCodeValue --

done.  used Unsigned32 actually as the range is postive.

> 
> SIP-COMMON.txt:2940: [5] {group-unref} warning: current group 
> `sipCommonNotifObjectsGroup' is not referenced in this module

i presume adding a GROUP clause to the module-compliance will
fix this.   i can do that.   however, my understanding is that
if a group is not mentioned, it's considered optional.
at any rate, i'll add the GROUP clause - as there's one for
each other optional group.

> 
> A2) You would like to re-consider the OID place holders that you created 
> for sipRedirCfg, sipRedirStats, sipRegCfg, sipRegStats.
> 
> This is not an SMI violation, but it creates for the time being a hole 
> in a MIB walk. If you need to add the definition of the respective 
> objects in the future, you will not be able to do it in the same 
> document, without the need to re-cycle the document at Proposed Standard 
> level.

ok.  as this has come up at least a couple of times now, i'll remove them.

> 
> A3) DESCRIPTION Clause of sipServiceNotifEnable -  Saying that in case 
> notifications are not implemented, the value has 'no meaning and MUST be 
> 0', seems contradictory and inaccurate. The respective sentence should 
> read - 'The notifications are OPTIONAL, and if they are not implemented, 
> this object's value MUST be all 0s.'
> 
> A4) How does sipNotifSequenceNumber work? It should probably be 
> increased once for each notification defined in the SIP MIBs, but not 
> for each notification target (in the case of multiple managers). I 
> suggest this to be detailed in the DESCRIPTION clause for clarity.
> 
>  
> 
> Minor editorial issues:
> 
> B1) English syntax in section 4.1. It should probably read 'The data 
> type SipTransportProtocol is used as Textual Convention in this 
> document. Textual conventions have...'

done.

> B2) Eliminate the commented text in the SIP compliance module of the UA 

you mean where it says "SMIC compiler problems"?

realize that OBJECT refinement was added in response to one of your
previous comments on rev -05...

    "B9 - If only a subset of the values of a TC is supported, like in
     the case of sipUACfgSipServerAddrStatus, this needs to be reflected
     in the compliance clauses. See Section 4.8 of 
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt
for an example"

so remove it completely??

kevin

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Kevin R. Lingle       919.392.2029
  http://www.klove.com                               http://www.air1.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

_______________________________________________
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: Kevin Lingle <[email-masked]>
Date: Wed, 30 Jul 2003 17:51:20 -0400

one mistake...

<snip>
> for sipRedirCfg, sipRedirStats, sipRegCfg, sipRegStats.

sipRegCfg and sipRegStats aren't placeholders.  they have actual
objects defined under them.

i'll remove the redirect related placeholders though.

kevin

---

From: Kevin Lingle <[email-masked]>
Date: Wed, 30 Jul 2003 18:45:38 -0400

dan, other question...

> you mean where it says "SMIC compiler problems"?

if you do mean this... there is an occurrence in the SIP-COMMON-MIB
as well.   remove it as well??

kevin