Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP)
RFC 6173

Received changes through RFC Editor sync (changed abstract to 'This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.

This document obsoletes RFC 4369. [STANDARDS-TRACK]')

[Ballot comment]
I am not sure that the IANA considerations section is needed taking into account that this is not a new MIB root allocation. If it stays I would suggest that it explicitely mentions that this is not a new allocation but a reuse of the allocation made at the publication of 4360.

[Ballot discuss]
1. The MIB Doctor review and the mail discussions that foloowed pointed to the need to modify the DESCRIPTION clauses of the compliance clauses to clarify the change in the compliance requirements. I do not see these change made in a new version or in a RFC Editor note.

[Note]: changed to 'Tom Talpey (ttalpey@microsoft.com) is the document shepherd.

A new revision will be published with minor editorial changes to the description clauses of a group clause and a conpliance clause.' by David Harrington

Resolution following MIB Doctor review:
(dbh advice to editor)

There was a debate amongst the MIB Doctors about the legality of
deprecating an enumeration value.
The rules seem to support adding or renaming enumerations, but not
deprecating.
Apparently it has been done in the past, so we could get by with it.
But we can actually reduce the amount of change and that might be
clearer for implementers.

We do not need to modify the enumeration, the addrtype object, and the
alias object.
All we really need to do is write a new conformance clause that drops
the requirement for implementing the enumeration and alias.
"OK, then I think the old MODULE-COMPLIANCE should have the objects
that use this
TC be explicit and list all the values that were valid earlier.
I would think that that MODULE-COMPLIANCE then gets deprecated,  and a
new one
gets defined as current that enumerates the values without the
deprecated one."

I recommend taking this simple route.

So this is all we need to do:
- revert the TC and the modified objects to what they were in the old
MIB.
  (remove the statements about deprecation)
  add the ipn133 draft as a reference to the TC
- ifcpgatewayCompliance
  add an object clause for IfcpAddressMode that says this object must
support transparent(1) and translation(2)
  change the status of the compliance clause to deprecated.
- deprecate the session group
- define sessionGroupNoTranslation (with no alias object)
- ifcpGatewayComplianceNoTranslation
  use the group with no alias.
  in the object clause for ifcpLclGtwyInstAddrTransMode, say "Support
is only required for   
  addressTransparent(1)."
  in the Description clause, say "Address translation mode has been
deprecated in the FC standards."

(make sure you never say the enumeration has been deprecated. Just say
the address mode has been deprecated in the FC standards, and you can
give the ipc133 RFC as a reference.)

(part of the MIB Doctor discussion is below, if you want to read it.
While Joan is OK with saying the enumeration is deprecated, doing so
actually has implications on backwards compatibility; just specifying
a new compliance is cleaner.)

dbh

-----Original Message-----
From: Joan Cucchiara [mailto:jcucchiara@mindspring.com]
Sent: Saturday, October 23, 2010 9:12 AM
To: David Harrington; 'Bert (IETF) Wijnen'; 'Romascanu, Dan (Dan)'
Cc: mib-doctors@ietf.org
Subject: Re: [MIB-DOCTORS] MIB Dr. review of
draft-ietf-storm-ifcpmib-05


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

Hi Dave,

Wanted to thoroughly go through your comments.  I do believe we are in
agreement.  Please see inline below.

Thanks,
  -Joan




> Hi,
>
> Here's the charter description of the mib update:
> (4) iFCP: The Address Translation mode of iFCP needs to be
deprecated
> (SHOULD NOT implement or use), as there are significant technical
> problems with its specification, and moreover, only the Address
> Transparent mode of iFCP is in use. This will be done via a short
> draft
> that updates RFC 4172, and not via a complete rewrite of RFC 4172. A
> combined draft is expected that encompasses items (3) and (4); this
> draft should also update the iFCP MIB (RFC 4369) to deprecate
support
> for iFCP Address Translation mode.
>
> The INCITS working group for fibre channel (T11) has deprecated the
> translation addressing mode in the protocol. FCP translation mode is
> equivalent to a NAT for FC. The MIB module models the addressing
mode,
> and the update reflects the deprecation and the no-longer-needed
> alias.
>
> In thinking about this, if deprecating is problematic, then I agree
> with Bert.
>

Agreed.


> From an NMS point of view, if translation mode is implemented in
> legacy devices, the NMS will need to model both modes in case a
> deployment includes devices that practice translation. So
> realistically, it doesn't much matter if we declare the enumeration
> and the alias deprecated; if the mode exists in the real world, the
> NMS should implement the enumeration and the alias object.
>
> From an agent point of view, if the agent doesn't support
translation,
> it can choose to not implement the alias object, and if it will
never
> use translation, it really doesn't need to implement the enumeration
> value.
>
> From a compliance point of view, the pre-update module requires
> support for the enumeration and alias. So it would make sense to
write
> a new compliance clause as Bert suggests. The new compliance clause
in
> the update should work just fine (with an expanded description).
>

Agreed.

> So we could probably get by without deprecating anything in the MIB
> module? We just need an updated compliance clause, and the
compliance
> clause could explain that deprecation occurred in the FC standard,
and
> reference the other STORM document that discusses this. right?
>
> So let's see what we need.
> - The description clause of the TC and objects could be modified to
> say don't use (2), but without saying it is deprecated, I am
concerned
> how that might get implemented. So I think I'd prefer to not modify
> the original TC and AddrMode and Alias objects at all (but add
UNITS).

As Jeurgen pointed out, there is precedence in deprecating an enum in
the IANAifType-MIB.  So I won't object further if you do want to
use the word, deprecate, as long as a new compliance is written as
Bert suggested.


> - the ifcpgatewayCompliance clause should be deprecated, so it is
> clear we don't not want people to use that compliance level any
more.
> Describe the deprecation in the underlying protocol here?
> - deprecate the session group
> - define sessionGroupNoTranslation
> - the new GatewayComplianceNoTranslation compliance clause with
> exception for the transmode (translation enumeration not required)
> using the group with no alias.
>
> does that sound right?
>

Yes.

-Joan

AD response to MIB Doctor review:

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

IANA understands that, upon approval of this document, there is a single
IANA Action that must be completed.

In the SMI Network Management MGMT Codes registry located in the Network
Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers

a single, new registration is to be made:

Decimal Name Description Reference
------- ------------ --------------------------------- --------------
ifcpMgmtMIB internet Fibre Channel Protocol (iFCP)
gateway objects RFC-to-be

The authors suggest a value of 200 for .

IANA understands that this is the only action required upon approval of
this document.

Hi,

I have done my AD Evaluation of this document. There are some changes that need to be made.

1) This document copies a great deal of text from RFC 4369. I think you need to include the copyright disclaimer that this document contains some pre-rfc5378 text. (check the current IPR rules on how this is specified).

2) I recommend including the original authors' contact information in the acknowledgement section.

3) The label
  "INTERNET-DRAFT" should appear in the upper left hand corner of the
  first page.  If the I-D is associated with an IETF working group, the
  name of the working group should appear on the line below the
  "INTERNET-DRAFT" label.

4) Please include the working group contact information in the MIB module's CONTACT-INFO field.
  - If the module was developed by an IETF working group, then the
    ORGANIZATION clause MUST provide the full name of the working
    group, and the CONTACT-INFO clause MUST include working group
    mailing list information.  The CONTACT-INFO clause SHOULD also
    provide a pointer to the working group's web page.

5) MIB modules cannot contains reference citations of the form "[storm-iFCP]"
use the format
REFERENCE      "RFC 4172, iFCP Protocol Specification"
The extracted MIB module might be used separately from the surrounding text, e.g., used in a help file. 

6) see RFC4181 section 4.5
The LAST-UPDATED and REVISION field dates seem out of date, and are missing the comment with the date.
In the revision description, please identify the RFC, not an Internet Draft.
          REVISION    "200212132358Z"  -- December 13, 2002
          DESCRIPTION "This MIB module published as RFC yyyy."
  -- RFC Ed.: replace yyyy with actual RFC number & remove this note

please include a description of the changes between revisions in the DESCRIPTION clause.


David Harrington
Director, IETF Transport Area
ietfdbh@comcast.net (preferred for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 (cell)

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Tom Talpey (STORM WG co-chair), yes, yes.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, no.

The document has been reviewed by numerous WG members and by other
experienced MIB contributors. Additionally, the document is an update to, and
at publication will obsolete, RFC4369.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document raised only constructive suggestions and no dissent during
its WG review. It enjoys full consensus.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews.

The document passes all current full id-nit checks with no warnings at full "verbose"
level, and a detailed reading by the shepherd yields no questions or comments.

The document requires formal MIB Doctor review, and such a review is hereby
requested to be initiated by the Area Director.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are appropriately split. All normative references except one
are currently-published RFCs. There is one internet-draft normative reference,
draft-ietf-storm-ifcp-ipn133-updates, which is being contemporaneously
submitted for Document Shepherd review and publication as a Proposed
Standard RFC.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during IESG Evaluation?

Yes. The document lists a single IANA consideration, to add one object identifier
to the existing SMI numbers registry.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes. The Document Shepherd has verified the MIB module defined in the
document passes the online libsmi checker with no warnings or errors.

The Document Shepherd has additionally reviewed the document in conformance to
the requirements of RFC4181 Guidelines for Authors and Reviewers of MIB Documents.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document defines Management Information Base (MIB) objects to
allow a network management protocol to be used to monitor and manage
local iFCP gateway instances, including the configuration of iFCP sessions
between gateways.

This document updates, and obsoletes, RFC4369.

Working Group Summary
The WG process to create this document went very smoothly, in large part
owing to the existing publication of RFC4369. Comments were constructive
and were easily addressed with minor changes to the draft version. The
document was well-received and Working Group consensus was easily
reached.

Document Quality
The document is of high quality, and while written to support iFCP, has
architectural relevance to other current Internet protocols supporting the
SCSI family. The iFCP protocol, now largely historical, is deployed in
numerous products. The MIB objects in the document are therefore
expected to be relevant to iFCP management, as well as to provide a basis
for additional related efforts.