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

["Joan Cucchiara" <[e-mail]>]

Bert,

I would agree with the approach you suggest, but the DESCRIPTION clause 
specifies that one of the
enums is deprecated, and using the word 'deprecated' is a sticking point for 
me  because the word
"deprecated" has implications in a MIB Module.

 IfcpAddressMode ::= TEXTUAL-CONVENTION
       STATUS         current
       DESCRIPTION    "The values for iFCP Address Translation
                       Mode. The value addressTranslation(2) is
                       deprecated."
       REFERENCE      "RFC yyyy, Updates to the iFCP Protocol and
                       Internet Protocol Number 133 "
-- RFC Ed.: replace yyyy with the RFC number assigned to
-- draft-ietf-storm-ifcp-ipn133-updates & remove this note
       SYNTAX         INTEGER {addressTransparent(1),
                               addressTranslation(2)}


Perhaps restating (i.e. softening) the DESCRIPTION
without using the word "deprecated' would be a solution, but then I'm not
sure if that is the true intention of the WG.

As a little more background info,  I do think the WG intends to no longer 
support
the addressTranslation(2) because there is currently a
WG specification  (draft-ietf-storm-ifcp-ipn133-updates) about
how the AdressTranslation Mode  is  incorect and "deprecated".
Here is part of the specification's abstract:

"Abstract

   Changes to Fibre Channel have caused the specification of iFCP
   address translation mode to become incorrect.  Due to the absence of
   usage of iFCP address translation mode, it is deprecated by this
   document.  iFCP address transparent mode remains correctly specified. 
...."

Thanks,
  -Joan


----- Original Message ----- 
From: "Bert (IETF) Wijnen" <[e-mail]>
To: "Romascanu, Dan (Dan)" <[e-mail]>
Cc: "Joan Cucchiara" <[e-mail]>; "David Harrington" 
<[e-mail]>; <[e-mail]>
Sent: Wednesday, October 20, 2010 7:32 AM
Subject: Re: [MIB-DOCTORS] MIB Dr. review of draft-ietf-storm-ifcpmib-05


>  So why would you want to deprecate?
>
> If you just do a new MODULE-COMPLIANCE that lists the enumerations except
> teh one you no longer want, then you are all set, no?
>
> Bert
>
> On 10/20/10 1:09 PM, Romascanu, Dan (Dan) wrote:
>> (restricting the circulation to MIB-Doctors)
>>
>>   I would like to hear the opinion of other MIB-Doctors here.
>>
>> My opinion is similar to Joan's comment on the issue. David seems to say
>> that deprecating one enumerated value in a TC is a backwards compatible
>> change allowed by RFC 2578 and I am not sure that this is true.
>>
>> RFC 2579 (and not 2578) says:
>>
>> (1)  A SYNTAX clause containing an enumerated INTEGER may have new
>>       enumerations added or existing labels changed.
>>
>> So new enumerations may be added, existing labels changed, but
>> deprecating a label is not listed as an allowed operation.
>>
>> Am I (and Joan) missing anything?
>>
>> Dan
>>
>>
>>> -----Original Message-----
>>> From: Joan Cucchiara [mailto:[e-mail]]
>>> Sent: Tuesday, October 19, 2010 9:31 PM
>>> To: David Harrington; [e-mail]; [e-mail]
>>> Cc: Romascanu, Dan (Dan); [e-mail]
>>> Subject: Re: MIB Dr. review of draft-ietf-storm-ifcpmib-05
>>>
>>>
>>> ----- Original Message -----
>>> From: "David Harrington"<[e-mail]>
>>> To: "'Joan Cucchiara'"<[e-mail]>;
>>> <[e-mail]>;<[e-mail]>
>>> Cc: "'Romascanu, Dan (Dan)'"<[e-mail]>;
>>> <[e-mail]>
>>> Sent: Tuesday, October 19, 2010 11:07 AM
>>> Subject: RE: MIB Dr. review of draft-ietf-storm-ifcpmib-05
>>>
>>>
>>>> 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.
>>> 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.
>>>
>>>
>>>
>>>>>
>>>>> 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
>>>>
>>> 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
>>>
>>>
>>>
>>>
>>>>>
>>>>> 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--
>>>>>
>>>
>> _______________________________________________
>> MIB-DOCTORS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>
>