Subject: Actiuon items from ARC discussion

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Tue, 6 Aug 2002 11:57:31 -0400

Hi,

During the ARC discussion, I was assigned several action items.
(See the Consolidated disman WG minutes from Yokohama from Randy on August 1.)
Here are the status of those action items.

(1) Security 
> Action Item - For security section, Kam to list the objects
> that are read-create or read-write and if they contain any
> privacy information.

In version -03 of the ARC mib, the following text was added 
as the 2nd paragraph of section 6.

   In particular, the ARC setting feature defined in the MIB affects 
   alarm notification generation. Unauthorized access to the write-able 
   objects could cause omission of alarm notifications or flooding 
   of unwanted alarm notifications from the netowrk. These write-able
   objects (defined with a MAX-ACCESS clause of read-create) are:
   arcMIBTITimeInterval, arcMIBCDTimeInterval, arcState,
   arcNalmTimeRemaining, and arcRowStatus.

(2) Persistency 
> Shall we add a storage type to this table or save all entries?
> David Perkins pointed out that for CLI you cannot say if
> a particular instance be saved while others are not but it
> could be SNMP specific.  Bert mentioned that either storage
> type or all entries saved is fine but it should be the same
> as we have been doing.
> 
> Action Item - Kam to raise this question on mailing list if
> all entries should be persistent or only some.

Discussion on "persistency" has already occurred in this mailing 
list since July 20 right after the Yokohama meeting and also occurred
recently in the mibs mailing list. 

In version -03 of the ARC mib, the following sentence was added to
the arcEntry to describe persistence across agent restarts.

     Instances of this conceptual row SHOULD persist across agent 
     restarts.

Any comments?

(3) IANAItuProbableCauseOrZero
> Action Item - Kam to define a IANAItuProbableCauseOrZero TC
> in this MIB with Unsigned32 syntax that can take any value
> of IANAItuProbableCause or 0. IANA should also be informed
> not to assign 0, in future, for IANAItuProbableCause.

In version -03 of the ARC mib, a IANAItuProbableCauseOrZero TC
is defined. The syntax of arcAlarmType is thus changed from 
IANAItuProbableCause to IANAItuProbableCauseOrZero.

I think it is more appropriate for the Alarm MIB document to 
note that IANA should reserve 0 for the IANAItuProbableCause
TC. In fact the meeting minute has the following note for the
Alarm MIB discussion.
> 
> Alarm n+2: Reserve 0 in TC and point IANA to this TC so they
> know to not allocate 0.
> 

(4) Version -03 of the ARC MIB
> ARC MIB update next week and will go WG last call then.
> 
Version -03 has been submitted and available at
http://www.ietf.org/internet-drafts/draft-ietf-disman-conditionmib-03.txt

Regards,
Kam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Aug 2002 18:50:52 +0200

>>>>> Lam, Hing-Kam (Kam) writes:

Lam> In version -03 of the ARC mib, the following sentence was added
Lam> to the arcEntry to describe persistence across agent restarts.

Lam>      Instances of this conceptual row SHOULD persist across agent
Lam>      restarts.

Lam> Any comments?

What does that tell me as a management application writer? Can I
assume that all rows have an implicit storage type of nonVolatile or
stronger? Moreover, can I rely on the rows being persistent?  (In
other words, when does the SHOULD apply?)

Note that without a storage type, there is no way to distinguish
between permanent,readOnly and nonVolatile rows which makes it harder
to grab and replay configurations...

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>