Subject: Issues & comments on APS draft MIB

From: Ron Carmona <[email-masked]>
Date: Wed, 12 Jul 2000 20:44:57 -0700

To all,

Hi.  I'm Ron Carmona with Accelerated Networks in So. California.  I have
been reviewing the INTERNET-DRAFT Definitions of Managed Objects for SONET
Linear APS architectures document (draft-ietf-atommib-sonetaps-mib-01.txt).
More specifically, the MIB.

I have come up with the following MIB issues that I would like to get
feedback on:

1.	The IMPORTS clause is a bit thin for some compilers.  I suggest that
it be modified with something like the following:
MODULE-IDENTITY, TimeTicks,	Counter32, Integer32,
OBJECT-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE,
experimental
	FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus
	FROM SNMPv2-TC
SnmpAdminString
	FROM SNMP-FRAMEWORK-MIB
InterfaceIndex
	FROM IF-MIB
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
	FROM SNMPv2-CONF;
2.	I was a bit concerned regarding the format of the UTC time in the
LAST-UPDATED and REVISION fields.  It has been specified with a 4 character
year designation (YYYY) as opposed to the "old" 2 character method (YY).  I
discussed this with Mike Thatcher (Redback), and he informed me that this is
now the recommended format as per RFC2578.  I can't argue with that logic,
but I still mention it here since it caused a problem with the MIB
compilation.
3.	For the MIB object apsConfigMode, I would have preferred breaking
this up into 4 separate objects; perhaps apsConfigMode (with 4 enums instead
of BITS definitions for bits 0-3), apsConfigRevertive (with enums 'enable'
and 'disable'), apsConfigDirection (with enums 'bi-directional' and
'unidirectional'), and apsConfigExtraTraffic (with enums 'allowed' and
'not-allowed'; with this object only applicable to 1:n mode).  I didn't
evaluate the BITS definition as appropriate for all these separate concepts
and felt that the APS mode is really only one of the first four bit
definitions...also, OID leafs are cheap.
4.	Another comment for the MIB object apsConfigMode is that assuming
the definition remains as a BITS pseudotype object, the DEFVAL = '80'h was
confusing to me.  After discussing it with Mike Thatcher and reviewing the
BITS definitions in "Understanding MIBs" (D. Perkins, E. McGinnis), I think
it may be clearer to represent the default value clause as follows:
	DEFVAL { {onePlusOne} } 
5.	For the MIB object apsConfigWaitToRestore, I am concerned about the
units being defined as 'seconds'.  I was told (by my APS software developer)
that the Telcordia GR-253 spec calls for units of 'minutes' instead.  If we
stick with the units=seconds, then I will need to somehow notify the user
for our own proposed implementation that the value must be integer multiples
of 60 (since that is what my developer tells me that we will support).
6.	Another comment that I received from my APS software developer was a
concern regarding the need for APS groups to have APS channels starting with
channel 0.  He told me that in an ITU spec for 1+1 optimized architecture
(Annex B of this spec), the group is defined with working channels 1 & 2,
without a channel 0.  If the MIB requirement remains as is, then I don't
believe we will really have too much trouble doing an internal mapping from
channels 0 & 1 (supplied by the user's configuration) to channels 1 & 2
(supported by our internal implementation of this mode)...but I would still
appreciate any feedback on this issue.

That's it.  I look forward to getting some feedback from the working group. 
Nice to meet you all.
Thanx,
Ron Carmona
(805) 553-9680 x350
[email-masked] <mailto:[email-masked]> 
1.3.6.1.4.1.5059

---

From: Jim Kuhfeld <[email-masked]>
Date: Sun, 16 Jul 2000 16:11:23 -0700

> MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP

This will be corrected.

> but I still mention it here since it caused a problem with the MIB

Following Mike Thatcher's recommendation, this has not been changed.

> definitions...also, OID leafs are cheap.

This will be broken up into 4 objects.

> it may be clearer to represent the default value clause as follows:

This will be corrected in an apsConfigMode INTEGER object as mentioned in 3.

> of 60 (since that is what my developer tells me that we will support).

Footnote 10 to R5-57 in GR-253-CORE states, "It is sufficient to provide
provisionable WTR times from 5 to 12 minutes in 1-minute increments."

The WTR issue came up in the past in reference to Ken Chapman's draft.
At that time Laruen Heintz stated:
"- apsGroupWaitToRestoreTime - gr1500 says it is "sufficient" to specify
this in minute increments, however, I believe implementations are free to specify
more refined values (i.e. partial minutes or seconds).  So, either allow these
values to be specified in seconds, or indicate whether an agent should round up
or down (i.e. is 5.X minutes reported as 5 or 6?)."

> appreciate any feedback on this issue.

This error will be corrected to indicate that the set of channel numbers begins
with 1 if the architecture is onePlusOneOptimized.