Re: [storm] MIB Dr. review of draft-ietf-storm-ifcpmib-05

"David Harrington" <ietfdbh@comcast.net> Fri, 22 October 2010 18:03 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 C7E7D3A693E for <storm@core3.amsl.com>; Fri, 22 Oct 2010 11:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.501
X-Spam-Level:
X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 QkzOoe4hzeoC for <storm@core3.amsl.com>; Fri, 22 Oct 2010 11:03:41 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id B71073A6948 for <storm@ietf.org>; Fri, 22 Oct 2010 11:03:40 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id MsKA1f00A0mv7h059u5KpW; Fri, 22 Oct 2010 18:05:19 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta11.westchester.pa.mail.comcast.net with comcast id Mu561f00K2JQnJT3Xu57d8; Fri, 22 Oct 2010 18:05:19 +0000
From: "David Harrington" <ietfdbh@comcast.net>
To: "'Prakash Venkatesen, ERS-HCLTech'" <prakashvn@hcl.com>, "'Joan Cucchiara'" <jcucchiara@mindspring.com>, <storm@ietf.org>
References: <002401cb6e6c$6def3e30$6501a8c0@JoanPC> <CB6D85622CB6470FB3BC2D1C9BCA1BE5@23FX1C1> <003c01cb6fc4$3644e8f0$6501a8c0@JoanPC> <0FB8687322BDB44381952C8B5066CE2F20F3B4E6D7@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN>
Date: Sat, 23 Oct 2010 02:04:52 +0800
Message-ID: <F45BA8C563914F278146DBD587727826@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: <0FB8687322BDB44381952C8B5066CE2F20F3B4E6D7@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Thread-Index: ActvxIRBIKKu8VRhQSmw1LEYYmfYKQCPd1WQAARCmRA=
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: Fri, 22 Oct 2010 18:03:42 -0000

Prakash,

The MIB Doctors are discussing this MIB module to decide how it should
be modified.
let me finish that discussion, and then I'll advise you.
Then we can have Joan re-review the draft.

dbh

> -----Original Message-----
> From: Prakash Venkatesen, ERS-HCLTech [mailto:prakashvn@hcl.com] 
> Sent: Saturday, October 23, 2010 12:44 AM
> To: Joan Cucchiara; David Harrington; storm@ietf.org
> Cc: 'Romascanu, Dan (Dan)'; mib-doctors@ietf.org
> Subject: RE: MIB Dr. review of draft-ietf-storm-ifcpmib-05
> 
> Hi Joan,
> We discussed several of your points earlier before arriving 
> at this current draft. As David Harrington has pointed out, I 
> need to include a couple of your suggestions. Others may not 
> be necessary. A key point to note is that address translation 
> mode was originally the default one. We are just deprecating 
> the relevant objects and leaving the others untouched so that 
> the impact on existing implementations is minimal.
> 
> Please find my response inline. Take a look and let me know 
> what you think.
> 
> regards
> Prakash
> 
> 
> > -----Original Message-----
> > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com]
> > Sent: Wednesday, October 20, 2010 1:01 AM
> > > 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.
> 
> [Prakash] Agreed. I will fix this
> 
> > >>
> > >> 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.
> 
> [Prakash] Agreed. I will fix this
> 
> > >
> > >>
> > >>
> > >>
> > >> 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.
> > 
> > Dave,
> > 
> > I struggled with this, but suggested what I did because of 
> 4 reasons:
> 
> [Prakash] The TC need not be deprecated. The rules for SMI 
> changes are in RFC2578, and if this TC is an enumeration or 
> BITS type, then section 9 (2) seems to cover the case.
> Deprecating one value from the TC enumeration
> could be done by changing the description clause to say that the
> particular enumeration is deprecated; The description of what
> it means should still be there in case anybody anywhere implemented
> that case (or implements it in the future) so the NMS can interpret
> the received value, and the enumeration value doesn't get reused for
a
> different mode.
> 
> > 
> > a) When a TC has enums and one of them is "deprecated", 
> then my opinion
> > is
> > the TC should be
> > changed to have the STATUS clause of "deprecated"  because 
> this change
> > seems
> > like a semantic change.
> >  (Thus, my suggestion of changing the STATUS to "deprecated".)
> > rfc2578 and rfc2579 do discuss updating DESCRIPTION clauses
> > but updating cannot change the semantics object/TC.
> > 
> > b) tools - marking the TC and associated object as deprecated will
> > result in
> > tools (hopefully) generating code that is #ifdef'd 
> appropriately, such
> > that
> > a developer can continue to support translation mode or not 
> by changing
> > a
> > #define or #ifdef.
> > (Still work involved, but code-wise, tools should generate
something
> > reasonable (hopefully).)
> > 
> > c) (related to tools) propagation of this TC - currently this TC
is
> > only
> > used in this one MIB and
> > only by one object in this MIB.  So in my opinion, changing 
> the STATUS
> > might
> > have an advantage
> > over adding to the DESCRIPTION clause.  Granted, this may be a
moot
> > point,
> > depending on the
> > future of this TC, but the unknown is if Enterprize MIBs will
IMPORT
> > the TC.
> > 
> > d) (related to tools) migrating to STATUS of "obsolete" - if tools
> > generate
> > the code based on the
> > STATUS, then the migration from deprecated to obsolete should be
> > minimal
> > code-wise.
> > Changes going from "deprecated" to "obsolete" should also be less
> > impactful
> > mib-wise.
> > Granted, this may also be a moot point.
> > 
> > 
> > So, that is where I'm coming from.   I did have a couple of 
> additional
> > questions:
> > 
> > *) Do you have an opinion as to whether or not the
> > address translation mode will migrate to "obsolete" in the future?
> 
> [Prakash] Address translation mode was originally the 
> default: that is why it is marked as deprecated and not 
> obsolete. Eventually, it could become obsolete.
> 
> > 
> > *) What is the error code the ifcpLclGtwyInstAddrTransMode 
> object will
> > return if it is
> > set to addressTranslation(2) when it is not supported?
> > (inconsistentValue?)
> > 
> [Prakash] None of the existing implementations use 
> addressTranslation. But deprecating or obsoleting it will be 
> more disruptive to managers written against the current MIB. 
> That is why we have left it as is.
> 
> > As you pointed out, most of the points raised  are related 
> to changing
> > the
> > TC's status to deprecated, although,  I did comment below 
> on (the name
> > change) #7,
> > so please review that.
> > 
> > 
> > 
> > >
> > >>
> > >>
> > >> 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.
> 
> [Prakash] Deprecating or obsoleting this will be more 
> disruptive to managers written against the current MIB. So no 
> change is 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.
> 
> [Prakash] Since ifcpLclGtwyInstAddrTransMode is not 
> deprecated, the storagetype does not need to be deprecated
> 
> > >
> > >>
> > >> 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.
> 
> [Prakash] Agreed
> 
> > >
> > >>
> > >> 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
> > >
> > 
> > Sorry, I think I was not very clear.  I did actually like 
> the suffix of
> > "NoTrans", but wanted to see
> > this expanded because the beginnings of both:
> > 
> > NoTranslation  and
> > NoTransparent
> > 
> > Both words start with "NoTrans", so to clarify, was suggesting:
> > 
> > ifcpLclGatewaySessionGroupNoTranslation  or
> > ifcpLclGatewaySessionGroupNoTranslationMode
> 
> [Prakash] Thanks. ifcpLclGatewaySessionGroupNoTranslation 
> will be good, I think.
> 
> > 
> > as a name.
> > 
> > 
> > Thanks,
> >    -Joan
> > 
> > 
> > 
> > 
> > >>
> > >>
> > >> 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--
> > >>
> > >
> 
> 
> DISCLAIMER:
> --------------------------------------------------------------
> ---------------------------------------------------------
> 
> The contents of this e-mail and any attachment(s) are 
> confidential and intended for the named recipient(s) only. 
> It shall not attach any liability on the originator or HCL or 
> its affiliates. Any views or opinions presented in 
> this email are solely those of the author and may not 
> necessarily reflect the opinions of HCL or its affiliates. 
> Any form of reproduction, dissemination, copying, disclosure, 
> modification, distribution and / or publication of 
> this message without the prior written consent of the author 
> of this e-mail is strictly prohibited. If you have 
> received this email in error please delete it and notify the 
> sender immediately. Before opening any mail and 
> attachments please check them for viruses and defect.
> 
> --------------------------------------------------------------
> ---------------------------------------------------------