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