Subject: Re: APS MIB

From: Jim Kuhfeld <[email-masked]>
Date: Sun, 23 Jan 2000 16:01:40 -0800

On Sat, Jan 08, 2000 at 02:54:05AM +0000, [email-masked] wrote:
> To you all,
> 
> with the above address I am not sure who is getting my mail but I hope it will reach the 
> relevant people. Jeff, Michael or Jim.
> 
> I have read your draft_ietf-atommib-sonetaps-mib-00.txt and I have few comments. I'll appreciate 
> 
> 
> 
> if you respond to them.
> 
> All in all I like the MIB, it is very similar to the one I saw from Ken Chapman, just that it 
> has a more tables, and I guess either way are ok. 
> 
> 1.I like to use the MIB but before I do that, if it is going to become an official working group
> document I think you have to remove the "rbn" prefix everywhere in the MIB.
> 
> 2.in relation to issue #1, the root should be "experimental XX", it will make it all a lot 
> easier for external users.
> 
> 3.in the dynamic tables with the ROW-STATUS, I like to see the RowStatus OBJECT placed right 
> after the index of the table. This mechanism allows for easier growth of the tables in the 
> future. The way it is now, any new OBJECT will be added to the end of the table, and the 
> ROW-STATUS will become in the middle of the table. For consistency purpose, please put it right 
> after the index in all relevant tables.

Items 1-3 have been adopted.

> 
> 4.I am not sure what way is easier to implement the tables, one way is as you have them with the 
> 
> 
> 
> 
> group name as string being the index, the other is as Ken had them with group as an integer 
> being the index. If you have experience with the string, then I guess it is fine, but usually it 
> 
> 
> 
> is more complicated than simple integer and not always user friendly via MIB browser. Have you 
> given it enough thought and practice?

There is a division of opinion on this subject. This would be a worthwhile topic for working
group debate.

> 
> 5. in aspConfigTable, can we add additional OBJECT:
> apsConfigOperDelay --- it describes the time delay that is required between the actual switch 
> operation and  the event that triggered the switching.
> The object should be an integer and it's values are: 1 - 100ms, 5 - 500ms, 10 - 1 Sec, 20 - 2 
> Sec, 30 - 3 Sec, 40 - 4 Sec and 50 - 5 Sec.
> 
> 6. can we add more values in apsConfigMode? we think there should be a different values for 1+1 
> optimised vs 1+1 compatible to 1+n (annex B and annex A respectively). Also we thought about 
> adding path-protection and Y-cable-protection.
> 

An architecture type for 1:1 could be added resulting in three architecture type bits:
onePlusOne, oneToOne and oneToN. Additional discussion on the other suggestions made in items 5 
and 6 is requested. 
 
> 7.in the apsSwitchCommand TC, we  can add a value of noCmd. This value can be used when reading 
> apsCommandSwitch after no command was initiated. It is easier that way rather than not being 
> sure if the return value is really in effect.

This suggestion has been adopted.

> 
> 8.can we define the notification as follows:
>              apsNotifications           OBJECT IDENTIFIER
>                                           ::= { apsMIB 3 }
>              apsNotificationsPrefix     OBJECT IDENTIFIER
>                                           ::= { apsNotifications 0 }
> and then use the specific notification as the "child " of the prefix. This is more common 
> practice in other MIB and I think it is the right way. Also, I rather use value other than 0 as 
> the child of apsMIB.
> 

A modified version of this request has been adopted. The notifications now fall under apsMIB 2.
At Michael Thatcher's suggestion the use of 0 has been eliminated:

"The reason for the OID in a notification branch having a "0" in the next
to last subid stems from conversion of traps defined in v1 smi to v2
smi  for backword compatability.  That is for sending a notification
defined in a v2 SMI to a v1 manager and the TRAP pdu contains the same
values as would have been sent when the trap was defined in a v1 SMI.
There is no reason to define new notifications with this next to last
subid of 0 since there was no previous definition of the notification in
a V1 SMI."

> 
> 
> Last....do you plan on having a session in Adelaide? how do you plan on pushing it forward, if 
> at all?
> 
> regards
> Orly
> --------------------------------------------------------
> Orly Nicklass,,Ph.D
> Associate VP, R&D
> RAD Data Communications, Ltd.
>  
> E-mail: [email-masked]
> Tel: 9723-765-9969
> Date: 01/07/00
> Time: 16:53:22
> 
> This message was sent by Z-Mail Pro - from NetManage
> NetManage - delivers Standards Based IntraNet Solutions
> --------------------------------------------------------
> 
> 
> 
> 
>

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Sun, 23 Jan 2000 16:38:47 -0800 (PST)

On Sun, 23 Jan 2000, Jim Kuhfeld wrote:

> A modified version of this request has been adopted. The notifications
> now fall under apsMIB 2.  At Michael Thatcher's suggestion the use of
> 0 has been eliminated:
> 

That is wrong.  The trailing 0 needs to be there, not for the SMI
conversions, but to ensure that the SNMPv2 notification to SNMPv1
trap conversion is reversible (in other words, it is a protocols
issue not an SMI issue).  I think it can be reasonably expected
that this MIB will be used by SNMPv1 managers and agents.  The
trailing 0 should therefore be reinstated.

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: Michael Thatcher <[email-masked]>
Date: Mon, 24 Jan 2000 07:50:48 -0800

> trailing 0 should therefore be reinstated.

From draft-ietf-snmpv3-coex-06.txt section 3.2 Translating SNMPv2 Notification
Parameters to SNMPv1 Notification
Parameters

  -  If the next-to-last sub-identifier of the snmpTrapOID is
              zero, then the SMIv1 enterprise SHALL be the SNMPv2
              snmpTrapOID with the last 2 sub-identifiers removed,
              otherwise

           -  If the next-to-last sub-identifier of the snmpTrapOID is
              non-zero, then the SMIv1 enterprise SHALL be the SNMPv2
              snmpTrapOID with the last sub-identifier removed.

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Mon, 24 Jan 2000 10:17:25 -0800 (PST)

> > > now fall under apsMIB 2.  At Michael Thatcher's suggestion the use of
[ ... ]
> Can you show me in what doc this stated?

In <draft-ietf-snmpv3-coex-07.txt>.  The problem becomes evident when you
consider both the v2-to-v1 and v1-to-v2 translation.  First, consider the
v2-to-v1 direction:

3.1.  Translating SNMPv1 Notification Parameters to SNMPv2 Notification
Parameters

   The following procedure describes how to translate SNMPv1
   notification parameters into SNMPv2 notification parameters:

(1)  The SNMPv2 sysUpTime parameter SHALL be taken directly from the
     SNMPv1 time-stamp parameter.

(2)  If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)',
     the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of the
     SNMPv1 enterprise parameter and two additional sub-identifiers,
     '0', and the SNMPv1 specific-trap parameter.

Notice that two additional identifiers are added when translation from
v1 to v2, so that the next-to-last sub-id in the snmpTrapOID parameter
is always zero in a notification that has been translated from a v1 trap.

The rule in the other direction, as you correctly noted, is to strip off
the last one or last two sub-ids, depending on whether or not the
next-to-last sub-id is zero:

3.2.  Translating SNMPv2 Notification Parameters to SNMPv1 Notification
Parameters

   The following procedure describes how to translate SNMPv2
   notification parameters into SNMPv1 notification parameters:

(1)  The SNMPv1 enterprise parameter SHALL be determined as follows:

       [ ... ]

       -  If the SNMPv2 snmpTrapOID parameter is not one of the standard
          traps as defined in RFC1907 [12], then the SNMPv1 enterprise
          parameter SHALL be determined from the SNMPv2 snmpTrapOID
          parameter as follows:

           -  If the next-to-last sub-identifier of the snmpTrapOID is
              zero, then the SNMPv1 enterprise SHALL be the SNMPv2
              snmpTrapOID with the last 2 sub-identifiers removed,
              otherwise

           -  If the next-to-last sub-identifier of the snmpTrapOID is
              non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
              snmpTrapOID with the last sub-identifier removed.

This same translation applies in a bilingual or v1-only agent.
So, if you don't define the notifications as having a next-to-last
sub-id of zero, then the result of translating a trap from a v1 agent
into v2 format will not be that same as a notification generated by
a v2c agent or a v3 notification originator!

That is why the next-to-last sub-id should be zero in _all_ notifications
defined in IETF MIBs.  This is one of the things I look for when I am
asked to perform a MIB review.  If SNMPv1 were really obsolete this would
not matter.  But the fact is that SNMPv1 is still widely deployed and will
likely remain so for the forseeable future.

Regards,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: Lauren Heintz <[email-masked]>
Date: Mon, 24 Jan 2000 10:02:13 -0800

FYI: my mib compiler (from a well-known vendor) won't allow me to create
notification defs in a mib unless the next to last subid is 0.

Also, from rfc1902:

8.5.  Mapping of the NOTIFICATION-TYPE value

   The value of an invocation of the NOTIFICATION-TYPE macro is the name
   of the notification, which is an OBJECT IDENTIFIER, an
   administratively assigned name.  In order to achieve compatibility
   with the procedures employed by proxy agents (see Section 3.1.2 of
   [7]), the next to last sub-identifier in the name of any newly-
   defined notification must have the value zero.

Lauren

---

From: Michael Thatcher <[email-masked]>
Date: Mon, 24 Jan 2000 11:11:11 -0800

>    defined notification must have the value zero.

Thanks for pointing this text out.  I stand corrected.

miket