Re: Zone change related value for atportStatus

Phil Budne <phil@shiva.com> Fri, 30 April 1993 18:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10540; 30 Apr 93 14:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10536; 30 Apr 93 14:46 EDT
Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa20410; 30 Apr 93 14:46 EDT
Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA12606; Fri, 30 Apr 93 14:21:10 EDT
Return-Path: <phil@Shiva.COM>
Received: from Shiva.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA12602; Fri, 30 Apr 93 14:21:08 EDT
Received: by Shiva.COM (1.34b) Fri, 30 Apr 93 14:21:03 EDT
Date: Fri, 30 Apr 1993 14:21:03 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Phil Budne <phil@shiva.com>
Message-Id: <9304301821.AA28976@Shiva.COM>
To: Robert_Jeckell@3mail.3com.com, apple-ip@cayman.com
Subject: Re: Zone change related value for atportStatus
Cc: phil@shiva.com

	Date: Fri, 30 Apr 93 09:36 PDT
	From: Robert_Jeckell@3mail.3com.com
	To: apple-ip@Cayman.COM

	Maybe the value ought to be more generic, like
	zonelistChangeInProgress, with further state information
	relevant to the process kept in the optional zonelist change
	group (or other MIB).

	/bob

I concur; If new states might be of use to a zone change MIB, then
they should be reserved WITHOUT any defined semantics.

Maybe there should be a new "atPortInfo" member which is defined as an
OID, so that additional state information can be added at a later
date?

"onHold" was never well enough defined for my tastes, and putting it
back in without enough time to clearly define the semantics is asking
for lots of interpretations!!

-p