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

From: "Joan Cucchiara" <[email-masked]>
Date: Sun, 17 Oct 2010 22:30:28 -0400

Hello Prakash,

Thank you for providing this updated MIB document.

This MIB compiles cleanly with both smiLint and
smicngPRO MIB compilers.

Comments follow.  Please let me know if you 
have any questions.

Thanks,
  -Joan

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

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.

3) ifcpLclGtwyInstAddrTransMode     IfcpAddressMode,

The ifcpLclGtwyInstAddrTransMode object is the only
object which uses the (deprecated) IfcpAddressMode TC.

This object should also be deprecated.

A new read-only object could be added if this is thought to be
beneficial.. 

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.

A new StorageType object which excludes the ifcpLclGtwyInstAddrTransMode
should also probably be added.   

A related question on this object, why was ifcpLclGtwyInstFcBrdcstSupport
not included in this list of read-write objects?

5) ifcpLclGatewayGroup may need to be deprecated and replaced by another
group after 1-4  is done.

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.

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

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.

--End of comments--

---

From: "David Harrington" <[email-masked]>
Date: Tue, 19 Oct 2010 11:07:11 -0400

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.

> IfcpLTIorZero    UNITS: seconds

OK.

> TC is deprecated and why as the first statement(s) of the

The TC is not deprecated; its syntax is refined in a manner permitted
by RFC2578.
No change needed.

> 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

not needed.

> is permanent, as such this object should be deprecated.

ifcpLclGtwyInstAddrTransMode is not deprecated, so the storagetype
doesn't need deprecation.

> should also probably be added.   

not needed.
> 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 

the list of objects is not changed, 
no change to the group is needed

> first sentence of the DESCRIPTION clause.

OK.

> 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

> 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.

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 19 Oct 2010 15:31:21 -0400

----- Original Message ----- 
From: "David Harrington" <[email-masked]>
To: "'Joan Cucchiara'" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: "'Romascanu, Dan (Dan)'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 19, 2010 11:07 AM
Subject: RE: MIB Dr. review of draft-ietf-storm-ifcpmib-05

> The TC is not deprecated; its syntax is refined in a manner permitted

Dave,

I struggled with this, but suggested what I did because of 4 reasons:

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?

*) What is the error code the ifcpLclGtwyInstAddrTransMode object will 
return if it is
set to addressTranslation(2) when it is not supported?  (inconsistentValue?)

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.

> 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

as a name.

Thanks,
   -Joan

---

From: "Prakash Venkatesen, ERS-HCLTech" <[email-masked]>
Date: Fri, 22 Oct 2010 22:13:55 +0530

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:[email-masked]]
> Sent: Wednesday, October 20, 2010 1:01 AM

[Prakash] Agreed. I will fix this

> >> IfcpLTIorZero    UNITS: seconds

[Prakash] Agreed. I will fix this

> 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.

> 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.

> set to addressTranslation(2) when it is not supported?
[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.

> > We are only deprecating one enumeration value for this object, not

[Prakash] Deprecating or obsoleting this will be more disruptive to managers written against the current MIB. So no change is needed.

> > doesn't need deprecation.

[Prakash] Since ifcpLclGtwyInstAddrTransMode is not deprecated, the storagetype does not need to be deprecated

> >> first sentence of the DESCRIPTION clause.

[Prakash] Agreed

> ifcpLclGatewaySessionGroupNoTranslationMode

[Prakash] Thanks. ifcpLclGatewaySessionGroupNoTranslation will be good, I think.

> > Changing the value from (1) to (2) could still disrupt storage

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.

-----------------------------------------------------------------------------------------------------------------------

---

From: "David Harrington" <[email-masked]>
Date: Sat, 23 Oct 2010 02:04:52 +0800

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

> From: Prakash Venkatesen, ERS-HCLTech [mailto:[email-masked]] 
> Sent: Saturday, October 23, 2010 12:44 AM
> To: Joan Cucchiara; David Harrington; [email-masked]
> Cc: 'Romascanu, Dan (Dan)'; [email-masked]
> 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.
> 
> [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.
> > 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.
> > 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.
> > 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.
> [Prakash] Address translation mode was originally the 
> default: that is why it is marked as deprecated and not 
> obsolete. Eventually, it could become obsolete.
> 
> > 
> [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
> > > 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.
> 
> > >
> > >>
> [Prakash] Since ifcpLclGtwyInstAddrTransMode is not 
> deprecated, the storagetype does not need to be deprecated
> 
> > >
> > >>
> > > recommend using Transparent rather than NoTranslation in the
group
> > and
> --------------------------------------------------------------
> ---------------------------------------------------------
> 
> 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 
> --------------------------------------------------------------
> ---------------------------------------------------------