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
- Zone change related value for atportStatus Robert_Jeckell
- Re: Zone change related value for atportStatus Phil Budne