Re: [storm] MIB Dr. review of draft-ietf-storm-ifcpmib-05
"David Harrington" <ietfdbh@comcast.net> Tue, 19 October 2010 15:05 UTC
Return-Path: <ietfdbh@comcast.net>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9CDD3A6837 for <storm@core3.amsl.com>; Tue, 19 Oct 2010 08:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.17
X-Spam-Level:
X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NTrbLM2quYL for <storm@core3.amsl.com>; Tue, 19 Oct 2010 08:05:44 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by core3.amsl.com (Postfix) with ESMTP id 4536D3A6831 for <storm@ietf.org>; Tue, 19 Oct 2010 08:05:44 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id LaNT1f0011c6gX85Ff7GZv; Tue, 19 Oct 2010 15:07:16 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta23.westchester.pa.mail.comcast.net with comcast id Lf7F1f0022JQnJT3jf7Fyu; Tue, 19 Oct 2010 15:07:16 +0000
From: David Harrington <ietfdbh@comcast.net>
To: 'Joan Cucchiara' <jcucchiara@mindspring.com>, storm@ietf.org, prakashvn@hcl.com
References: <002401cb6e6c$6def3e30$6501a8c0@JoanPC>
Date: Tue, 19 Oct 2010 11:07:11 -0400
Message-ID: <CB6D85622CB6470FB3BC2D1C9BCA1BE5@23FX1C1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <002401cb6e6c$6def3e30$6501a8c0@JoanPC>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Thread-Index: ActubJ7NjYzetc8GQA+gn4yOPzNrmwBIG2/w
Cc: "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>, mib-doctors@ietf.org
Subject: Re: [storm] MIB Dr. review of draft-ietf-storm-ifcpmib-05
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Oct 2010 15:05:47 -0000
Hi Joan, I think you might have misread the intention of the changes here. In IfcpAddressMode TEXTUAL-CONVENTION, we are only deprecating one enumeration value, not the whole TEXTUAL-CONVENTION. We are only deprecating the addressTranslation(2) value; the addressTransparent(1) value is still current, and the IfcpAddressMode TEXTUAL-CONVENTION is still current. Comments inline. > COMMENTS > --------- > > GENERAL Comment: When an object, or Conformance Group > is deprecated, the DESCRIPTION clause needs to be updated > to state this and the reason for the deprecation. > > Almost all the DESCRIPTION clauses do mention the deprecation but > this is at the very end of the DESCRIPTION clause, Please > start the DESCRIPTION clause with this information, such as: > > DESCRIPTION: > "This object is deprecated. It has been deprecated because ... > Then include the original description. > > Specific examples are included in the comments below. > > > > 1) NIT: Please put a UNITS clause on the objects > that use these TCs: > IfcpIpTOVorZero UNITS: seconds > IfcpLTIorZero UNITS: seconds OK. > > > > 2) * IfcpAddressMode TEXTUAL-CONVENTION > > Why was the STATUS not changed to "deprecated"? > Please do so. > > Also, as discussed above, please change the DESCRIPTION to > state that the > TC is deprecated and why as the first statement(s) of the > DESCRIPTION clause. The TC is not deprecated; its syntax is refined in a manner permitted by RFC2578. No change needed. > > > 3) ifcpLclGtwyInstAddrTransMode IfcpAddressMode, > > The ifcpLclGtwyInstAddrTransMode object is the only > object which uses the (deprecated) IfcpAddressMode TC. > > This object should also be deprecated. We are only deprecating one enumeration value for this object, not the whole object. No change needed. > > A new read-only object could be added if this is thought to be > beneficial.. not needed. > > > 4) ifcpLclGtwyInstStorageType should be deprecated also. > > ifcpLclGtwyInstStorageType OBJECT-TYPE > SYNTAX StorageType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The storage type for this row. Parameter values defined > for a gateway are usually non-volatile, but may be volatile > or permanent in some configurations. If permanent, then > the following parameters must have read-write access: > ifcpLclGtwyInstAddrTransMode, ifcpLclGtwyInstDefaultIpTOV, > and ifcpLclGtwyInstDefaultLTInterval." > DEFVAL { nonVolatile } > ::= {ifcpLclGtwyInstEntry 11} > > > The DESCRIPTION clause specifies ifcpLclGtwyInstAddrTransMode > as one of > the values to provide read-write access for when the value of > this object > is permanent, as such this object should be deprecated. ifcpLclGtwyInstAddrTransMode is not deprecated, so the storagetype doesn't need deprecation. > > A new StorageType object which excludes the > ifcpLclGtwyInstAddrTransMode > should also probably be added. not needed. > > A related question on this object, why was > ifcpLclGtwyInstFcBrdcstSupport > not included in this list of read-write objects? This object has a DEFVAL, so an NMS does not need to specify a value to instantiate a row. no change needed. > > > > 5) ifcpLclGatewayGroup may need to be deprecated and replaced > by another > group after 1-4 is done. the list of objects is not changed, no change to the group is needed > > > 6) According to rfc2580, Section 7.1 > > If changing a STATUS to "deprecated" > the DESCRIPTION clause should be updated > to explain. > > *ifcpLclGatewaySessionGroup STATUS was > changed to "deprecated" but the DESCRIPTION > has not been changed. Again, please state > that the group has been deprecated and why as the > first sentence of the DESCRIPTION clause. > OK. > > 7). Naming of the new Compliance Group > > ifcpLclGatewaySessionGroupNoTrans > > (original name: ifcpLlGatewaySessionGroup) > > The "NoTrans" suffix is not specific enough because this > could stand for No Translation Mode or No Transparent Mode, > in other words, please replace the "NoTrans" with > something definitive such as: > > NoTranslationMode or NoTranslation I recommend modifying the way the names are constructed, to keep Group and Compliance as the suffixes. if "Support is only required for address Transparent mode", I recommend using Transparent rather than NoTranslation in the group and Compliance names. change ifcpLclGatewaySessionGroupNoTrans to ifcpLclGatewaySessionTransparentGroup or ifcpLclGatewayTransparentSessionGroup change ifcpGatewayComplianceNoTrans to ifcpGatewayTransparentCompliance > > > 8) Security Considerations > > This section needs to be updated to reflect the deprecation of > the Translation Mode. For example, the ifcpLclGtwyInstAddrTransMode > is mentioned and this is now deprecated. ifcpLclGtwyInstAddrTransMode is not deprecated. I think the security consideration is still valid as written. If a future modification adds an enumeration value, then changing the value could disrupt traffic. The enumeration value is deprecated, and an implementation can still choose to support the value. Changing the value from (1) to (2) could still disrupt storage traffic. no change needed. > > --End of comments-- >
- Re: [storm] MIB Dr. review of draft-ietf-storm-if… David Harrington
- Re: [storm] MIB Dr. review of draft-ietf-storm-if… Joan Cucchiara
- [storm] MIB Dr. review of draft-ietf-storm-ifcpmi… Joan Cucchiara
- Re: [storm] MIB Dr. review of draft-ietf-storm-if… Prakash Venkatesen, ERS-HCLTech
- Re: [storm] MIB Dr. review of draft-ietf-storm-if… David Harrington