AT MIBS--NBP fields r/w??
"Wayne F. Tackabury" <wayne@cayman.com> Wed, 23 June 1993 21:56 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15518; 23 Jun 93 17:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15514; 23 Jun 93 17:56 EDT
Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa00198; 23 Jun 93 17:56 EDT
Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA02107; Wed, 23 Jun 93 17:00:49 EDT
Return-Path: <wayne@Cayman.COM>
Received: from cuba.Cayman.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA02103; Wed, 23 Jun 93 17:00:48 EDT
Received: from [143.137.54.4] by cuba.Cayman.COM (4.1/SMI-4.1) id AA10213; Wed, 23 Jun 93 17:00:44 EDT
Date: Wed, 23 Jun 1993 17:00:36 -0400
Message-Id: <9306232100.AA10213@cuba.Cayman.COM>
To: apple-ip@cayman.com
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Wayne F. Tackabury" <wayne@cayman.com>
X-Sender: wayne@cuba
Subject: AT MIBS--NBP fields r/w??
In RFC1243 and the AppleTalk MIB II, why did we set the fields of the nbpTable, and particularly object, type, and zone, as read-write?? Did anyone ever actually implement this?!? If so, did you have to change your internal interfaces for deregister to allow the calling service to refer to the name by handle or index, and not by name, in your deregister API? Did you run into any other service synchronization problems with registered names now tweakable by outside administrative action? Just curious. ------------------------------------------------------------------------- Wayne F. Tackabury Internet: wayne@cayman.com Cayman Systems, Inc. CompuServe: 73207,3650 26 Landsdowne St., Cambridge, MA 02139 AppleLink: D0523 Voice: (617) 494-1999 Fax: (617) 494-5167
- AT MIBS--NBP fields r/w?? Wayne F. Tackabury
- Re: AT MIBS--NBP fields r/w?? Ritter, Mike