Subject: RE: [ipcdn] Editorial Changes - NCS MIB

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 30 Mar 2004 10:35:34 -0800

All these seem to be reasonable changes.

Any feedback on outstanding issue of "pktcSigDevToneDbLevel" ?

Eugene Nechamkin,
Broadcom Corp,
ph: (604) 233-8500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Beacham Gordon-CGB005
Sent: Tuesday, March 30, 2004 8:35 AM
To: [email-masked]
Subject: [ipcdn] Editorial Changes - NCS MIB

The following editorial changes have been suggested for the NCS MIB:

1. Remove the pktcSigEndPntConfigObjects defintion. All endpoint configuration objects are located under
   pktcNcsEndPntConfigObjects, while pktcSigEndPntConfigObjects has no objects.

2. Reorder the R0, R6 and R7 objects so that R0, R1, R2, R3, R4, R5, R6, R7, Rg and Rs form a sequential series.

3. Change pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } to:
   pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 2 }

Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
[email-masked]

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 30 Mar 2004 15:20:35 -0500

I agree with Azlina about not moving pktcSigNotification.

In fact,
<http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02
.txt> goes further in section 4.7:

4.7.  Notification Definitions

   RFC 2578 Section 8 specifies the rules for notification definitions.
   In particular:

   - Inaccessible objects MUST NOT appear in the OBJECTS clause.

   - For each object type mentioned in the OBJECTS clause, the
     DESCRIPTION clause MUST specify which object instance is to be
     present in the transmitted notification and MUST specify the
     information/meaning conveyed.

   - The OBJECT IDENTIFIER (OID) value assigned to each notification
     type MUST have a next-to-last sub-identifier of zero, so that it is
     possible to convert an SMIv2 notification definition into an SMIv1
     trap definition and back again without information loss (see
     [RFC2576] Section 2.1.2) and possible for a multilingual proxy
     chain to translate an SNMPv2 trap into an SNMPv1 trap and back
     again without information loss (see [RFC2576] Section 3).  In
     addition, the OID assigned to a notification definition MUST NOT
     also be assigned to another definition that results in OID
     registration.  RFC 2578 Section 3.6 lists the constructs that
     create OID registrations.
...

The key requirement above is that the "OBJECT IDENTIFIER (OID) value
assigned to each notification type MUST have a next-to-last sub-identifier
of zero".

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Azlina Ahmad
Sent: Tuesday, March 30, 2004 3:15 PM
To: Beacham Gordon-CGB005
Cc: [email-masked]
Subject: Re: [ipcdn] Editorial Changes - NCS MIB

>    pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 2 }

Recommend keeping the notification as it is per Appendix D
of the draft-ietf-ops-mib-review-guidelines-02.txt.

Thanks,
Azlina