Subject: Re: [Adslmib] persistance in vdsl i-d

From: "Faye Ly" <[email-masked]>
Date: Wed, 01 May 2002 09:23:03 -0700

Randy,

Can you please clarify the purpose of stating
the persistency of the MIB objects?  I thought
all configurable objects have to be perserved
through reboot??  Does this say some objects
don't?  Like a test object or something?

Best,

-faye

>From: Randy Presuhn <[email-masked]>
>To: [email-masked]
>Subject: [Adslmib] persistance in vdsl i-d
>Date: Tue, 30 Apr 2002 16:01:40 -0700 (PDT)
>
>Hi -
>
>I'm glad that draft-ietf-adslmib-vdsl-02.txt includes some
>thought about the need for persistance of configuration
>information, but I think it doesn't go far enough.  I'd like
>to see explicit identification of all objects that must
>survive reboots.
>
>On a related item, on page 27 when it says "the system will
>always provide a default", I assume this should be a "MUST".
>
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  1-3141
>  [email-masked]  2141 North First Street
>  Tel: +1 408 546-1006   San José, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------
>
>_______________________________________________
>Adslmib mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/adslmib

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

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

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 1 May 2002 11:39:20 -0700 (PDT)

Hi -

> From: "Faye Ly" <[email-masked]>
> To: [email-masked], [email-masked]
> Subject: Re: [Adslmib] persistance in vdsl i-d
> Date: Wed, 01 May 2002 09:23:03 -0700
> Message-ID: <[email-masked]>
...
> don't?  Like a test object or something?
...

If there is a requirement for all configurable objects in
this MIB to survive reboots, then the document should clearly
and explicitly state this requirement.  In particular, does
this apply to things that are read-write as well as the read-
create items?

The practice in the SNMP community is that if there is no
explicit language about persistance, either in the DESCRIPTION
clause or through the use of some kind of StorageType-like
TC, then one cannot assume that configuration would survive
a reboot.  Even when one uses StorageType, it's advisable
to specify precisely which columns are the ones to which
it pertains.

There are also some ugly corner cases to think about.
For example, consider the case where there has been an upgrade
of interface hardware, so that an interface that had been SCM
becomes MCM.  What happens to the "persistent" configuration
that is now inappropriate for that line type?  What happens
when an interface is removed?  Temporarily removed?