Re: [imss] imss WG Last Call: Fibre Channel RSCN, Fabric Config S

Keith McCloghrie <kzm@cisco.com> Mon, 04 September 2006 10:53 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKC5F-0003KJ-8j; Mon, 04 Sep 2006 06:53:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKC5D-0003Jm-SO for imss@ietf.org; Mon, 04 Sep 2006 06:53:39 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKC5C-0003xk-HN for imss@ietf.org; Mon, 04 Sep 2006 06:53:39 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2006 03:53:38 -0700
X-IronPort-AV: i="4.08,208,1154934000"; d="scan'208"; a="442334778:sNHT31903142"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k84ArbEA028755; Mon, 4 Sep 2006 03:53:37 -0700
Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k84ArbQV028954; Mon, 4 Sep 2006 03:53:37 -0700 (PDT)
Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA09039; Mon, 4 Sep 2006 03:52:33 -0700 (PDT)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200609041052.DAA09039@cisco.com>
Subject: Re: [imss] imss WG Last Call: Fibre Channel RSCN, Fabric Config S
To: bwijnen@lucent.com
Date: Mon, 04 Sep 2006 03:52:33 -0700
In-Reply-To: <no.id> from "Wijnen, Bert (Bert)" at Sep 04, 2006 11:48:31 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2516; t=1157367217; x=1158231217; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:Keith=20McCloghrie=20<kzm@cisco.com> |Subject:Re=3A=20[imss]=20imss=20WG=20Last=20Call=3A=20Fibre=20Channel=20RSCN, =20 Fabric=20Config=20S; X=v=3Dcisco.com=3B=20h=3DlaAriIoH+ywm80asOo8mxlBfKuo=3D; b=q96pRAzUVvQhIxgXF4m9dPUB/hD7H9EGFfuMG6/qIttTYKR5LXYt/W7Z5DW+zS0qffT3gCsr ezKmh/3U3i/oJTTbUuG7f0Aq38UB40JVtB3YieIB6koJJ7s9DBgbnNVA;
Authentication-Results: sj-dkim-3.cisco.com; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: imss@ietf.org
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

See my earlier response for most of the issues.

The one new issue is the use of ifIndex in a notification's OBJECTS
clause.  This is another case where SMIC is providing an individual's
personal interpretation of the SMI, rather than being based on what
the SMI actually says, which is (from section 8.1 of RFC 2578):
								An
   object type specified in this clause must not have an MAX-ACCESS
   clause of "not-accessible".

whereas ifIndex has always had a MAX-ACCESS clause of "read-only".  

Note also the linkUp and linkDown notiifcations also have ifIndex in
their OBJECTS clause.  My experience is that customers prefer the use
of auxiliary objects in notifications, and so, in places where the SMI
allows it, I define them so intentionally.

Keith.


> SMIC strict checking reveals the following:
> 
>   C:\bwijnen\smicng\work>smicstrict
> 
>   C:\bwijnen\smicng\work>smicng T11-FC-ZONE-SERVER-MIB.inc
>   W: f(T11-FC-ZONE-SERVER-MIB.mi2), (959,15) Row "t11ZsSetZoneEntry"
>   does not have a consistent indexing scheme - cannot specify an
>   index item from additional "base row" t11ZsSetEntry, since can
>   have only one "base row" which is t11ZsZoneEntry
> 
> Keith, what is your comments on this one?
>
>   W: f(T11-FC-ZONE-SERVER-MIB.mi2), (2254,20) Variable "ifIndex"
>   in notification "t11ZsMergeFailureNotify" is an index for a table
>   W: f(T11-FC-ZONE-SERVER-MIB.mi2), (2269,20) Variable "ifIndex" in
>   notification "t11ZsMergeSuccessNotify" is an index for a table
> 
> I do not see the above two as fatal flaws. We could pass ifAlias,
> or some other columnar-object of the ifTable I guess. That would make
> the warning go away, and we would be sending extra information in
> the notification.
> 
>   C:\bwijnen\smicng\work>smicng T11-FC-RSCN-MIB.inc
>   E: f(T11-FC-RSCN-MIB.mi2), (198,5) Missing comma between sequence
>   items
> 
> Just add the comma (as stated earlier).
> 
>   C:\bwijnen\smicng\work>smicng T11-FC-FABRIC-LOCK-MIB.inc
> 
> is OK
> 
>   C:\bwijnen\smicng\work>smicng T11-FC-FABRIC-CONFIG-SERVER-MIB.inc
>   W: f(T11-FC-FABRIC-CONFIG-SERVER-MIB.mi2), (716,15) Row
>   "t11FcsPortListEntry" does not have a consistent indexing scheme
>   - index items from current table must come after index items from
>   other tables
> 
> Keith, can you comment?
> 
> Bert
> 
> _______________________________________________
> imss mailing list
> imss@ietf.org
> https://www1.ietf.org/mailman/listinfo/imss
> 

_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss