Subject: RE: "Sonet Linear APS MIB"

From: Silman Lionel <[email-masked]>
Date: Mon, 3 Apr 2000 16:13:13 +0200

We are working on SONET Linear APS and have some comments on the proposed
MIB.

1) We concur with Orly Nicklass in not liking the use of apsConfigName as an
index into the apsConfigTable. It would be better to use an integer
apsConfigIndex variable to index this table. In this case, an
apsConfigIndexNext variable is also required.

2) We also do not like the proposal that the Group entry be created as a
side-effect of creating a apsChanConfigEntry with a new apsChanGroupnName.

Instead, we propose that:-

*	apsConfigTable has an additional variable apsConfigAdminStatus with
default as 'down'. 

*	Groups are created and updated with apsConfigAdminStatus as 'down'.
For operation, this variable is then set to 'up'. Channels can be added to a
Group with AdminStatus down but not with AdminStatus 'up'.

*	apsChanConfigTable entries are indexed by apsConfigIndex and
apsChanNumber. An apsConfigEntry with the same apsConfigIndex must exist.

3) In your Email of 7 March, you refer to acceptance of corrections to
draft-ietf-atomib-sonetaps-mib-00. I cannot find any updated draft. Please
inform where to find this updated draft.

Lionel Silman Ph.D, Systems Engineering
Yuval Lorian, Software Systems Engineering
Transport Networks SBU, ECI Telecom
16 Martin Gehl Street, Petach-Tikva 49104, Israel
EMail: [email-masked]
Tel:+972 (3) 9261537  Fax:+972 (3) 9261630  Home Tel: +972 (3) 6417464

---

From: Jim Kuhfeld <[email-masked]>
Date: Mon, 3 Apr 2000 16:44:53 -0700

I have provided my opinions on the two issues inline below. 
Regarding item 3, I will begin preparing a new draft that includes 
the latest corrections. 

> apsConfigIndexNext variable is also required.

The intent of using SnmpAdminString indexing was to allow the selection
of a meaningful group identifier that can be associated with an APS
group and used across reboots. 

> apsChanNumber. An apsConfigEntry with the same apsConfigIndex must exist.

When configuring a new group the draft allows  channel row creation to 
precede the creation of the corresponding group entry in order to permit 
the use of createAndGo in the group RowStatus object. This was thought 
to be a worthwhile objective, eliminating the need for a separate set 
operation to activate the group. My concern with your proposal is 
that it necessitates that group row creation precedes channel row creation, 
which  enforces the need for a separate group enable set operation after 
channel creation is complete. 

Also, group entries are only added as a result of row creation in the
apsConfigTable not as a side-effect of row creation in the apsChanConfigTable.