Re: [imss] MIB doctor review for T11-FC-SP-ZONING-MIB
Keith McCloghrie <kzm@cisco.com> Fri, 04 January 2008 18:02 UTC
Return-path: <imss-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqrt-0008Rb-Kz; Fri, 04 Jan 2008 13:02:05 -0500
Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JAqrs-0008RP-2P for imss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 13:02:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqrr-0008RG-Ox for imss@ietf.org; Fri, 04 Jan 2008 13:02:03 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAqrq-0000Ur-4T for imss@ietf.org; Fri, 04 Jan 2008 13:02:03 -0500
X-IronPort-AV: E=Sophos;i="4.24,246,1196668800"; d="scan'208";a="9841297"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 04 Jan 2008 10:02:01 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m04I21Z7003717; Fri, 4 Jan 2008 10:02:01 -0800
Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m04I21HA010755; Fri, 4 Jan 2008 18:02:01 GMT
Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA04384; Fri, 4 Jan 2008 10:00:03 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200801041800.KAA04384@cisco.com>
Subject: Re: [imss] MIB doctor review for T11-FC-SP-ZONING-MIB
To: bertietf@bwijnen.net
Date: Fri, 04 Jan 2008 10:00:03 -0800
In-Reply-To: <NIEJLKBACMDODCGLGOCNMELDEEAA.bertietf@bwijnen.net> from "Bert Wijnen - IETF" at Jan 04, 2008 06:23:15 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3452; t=1199469721; x=1200333721; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:=20Keith=20McCloghrie=20<kzm@cisco.com> |Subject:=20Re=3A=20[imss]=20MIB=20doctor=20review=20for=20 T11-FC-SP-ZONING-MIB |Sender:=20; bh=fKBO/g/bZKCyLVJkZO28p77rbVG8ccHk8ImM0nBsDKo=; b=WP7oWy8Uv6JP/lPijOaYOlIKPiApKVKsr2fW0bHhQav3Quxa22ZLoU18/X y5x4Q53vBwiZ3gP6VM0552aQiRVoKJAY9UyBiqoGCd6RQzpaBH4P7NvKvs/9 U61Ge0/aNC;
Authentication-Results: sj-dkim-2; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: imss@ietf.org, Dan Romascanu <dromasca@avaya.com>, Keith McCloghrie <kzm@cisco.com>, Black_David <Black_David@emc.com>
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org
Extracting the one issue out of your response: > > > t11FcSpZoneSetHashStatus OBJECT-TYPE > > > SYNTAX INTEGER { > > > calculate(1), > > > correct(2), > > > stale(3) > > > } > > > > > > That SYNTAX a number of times in the set of MIB modules. > > > Candidate for a TC? > > > > Done. > > > > > - FOr that same object, I wonder how a re-calculate can be done > > > for a permanent row, since the storage type states: > > > > > > If an instance of this object has the value > > > 'permanent(4)', the Zone Set database for the given > > > fabric on the given switch is not required to be > > > writeable." > > > > Assuming that I've correctly understood your question, I'll add: > > a sentence in the DESCRIPTION of t11FcSpZoneSetHashStatus to say: > > > > If and when the corresponding instance of > > t11ZsServerDatabaseStorageType (defined in RFC 4936) has the value > > 'permanent(4)', then if any the instance of an object in if any row > > "if any the instance" ?? do you mean "if any instance" > "in if any row" ?? maybe remove the last "if" ?? Sorry for the confusion, let me try again: If and when the corresponding instance of t11ZsServerDatabaseStorageType (defined in RFC 4936) has the value 'permanent(4)', then if write access is supported to any instance of a read-write object in any row of any table governed by the 'permanent' value of t11ZsServerDatabaseStorageType, then write acces to the corresponding instance of this object must also be supported. > > of any table governed by t11ZsServerDatabaseStorageType has an > > object that is writable, then so too must be the corresponding > > instance of this object. > > > > OK? > > Not sure I underatand, so you say this one only needs to be writable > if any other wrietable object is writable? > I am confused? Doubtful -- it's probably that I've interpreted your comment wrongly. Here's the conclusion that I "jumped" to: RFC 2579 says (for StorageType): Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable." but t11ZsServerDatabaseStorageType is aleady defined in RFC 4936 and we aren't modifying RFC 4936, and so you want the specification of "must at a minimum allow to be writable" to be updated in the DESCRIPTION of t11FcSpZoneSetHashStatus. Now, one instance of t11ZsServerDatabaseStorageType covers all the associated rows of many tables, including rows in this new table which AUGMENTS t11ZsServerEntry. If t11ZsServerDatabaseStorageType is 'permanent', then some of the instances in the identified set of rows might be writeable -- if any are, then the Hash value is likely to change when such modifying such instances, and so the corresponding instance of t11FcSpZoneSetHashStatus needs to be writable. In contrast, if none of the instances of objects in the identified set of rows are writable, then that instance of t11FcSpZoneSetHashStatus doesn't need to be writable either. Is that what you meant ?? If so, did I capture it in my proposed addition to t11FcSpZoneSetHashStatus ? Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss
- [imss] MIB doctor review for T11-FC-SP-ZONING-MIB Bert Wijnen - IETF
- Re: [imss] MIB doctor review for T11-FC-SP-ZONING… Keith McCloghrie
- RE: [imss] MIB doctor review for T11-FC-SP-ZONING… Bert Wijnen - IETF
- Re: [imss] MIB doctor review for T11-FC-SP-ZONING… Keith McCloghrie
- RE: [imss] MIB doctor review for T11-FC-SP-ZONING… Bert Wijnen - IETF