MIB for Fibre-Channel Security Protocols (FC-SP)
draft-ietf-imss-fc-fcsp-mib-03

[Ballot comment]
I'm currently not able to review this 246-page document (plus the 300+
page FC Security Protocols document) in depth that would be likely to
find real problems (if any exist). However, the document does look
very well-written, and it's clear that security issues were considered
carefully in its design.

[Ballot discuss]
Section 3.4.2:
> Two mechanisms are available to protect specific classes of traffic:
> ESP_Header is used to protect FC-2 frames (see [FC-FS-2] and
> [RFC4303]),
>
This text would benefit from some clarifications; the "ESP_Header"
mechanism is *not* the same as IPsec ESP (and it's not IPsec at all);
so citing RFC4303 is confusing or even misleading.

Section 3.4.2 should also explicitly say that while it's talking
about IKEv2, Security Associations, SPIs, etc., none of this
is IPsec.

The REFERENCE clauses for t11FcSpSaIfReplayPrevention and
t11FcSpSaIfReplayWindowSize should probably reference FC-FS-2
instead of RFC4303, since they're not related to IPsec ESP.

Section 4.6:
> The management of certificates, Certification Authorities and
> Certificate Revocation Lists is the same in Fibre Channel networks
> as it is in other networks.  Therefore, this document does not
> define any MIB objects for such management.  Instead, this document
> assumes that appropriate MIB objects are defined elsewhere, e.g., in
> [IPSP-IPSEC-ACTION] and [IPSP-IKE-ACTION].
>
Making an assumption that involves the IPSP documents probably isn't
very realistic; I'd suggest just saying "that appropriate MIB objects
are defined elsewhere, or they are managed by mechanisms other than
MIB modules".

Reference [FC-SP], and numerous REFERENCE clauses in the MIB, should
probably point to ANSI/INCITS 426-2007 instead of the draft
version (and I hope the section/table numbers haven't changed
between).

The SecDir review by Shawn Emery identified couple of places that
would benefit from clarification; changes suggested by David Black
(the document shepherd) look fine to me. I'd prefer RFC editor notes
(or revised ID) to make sure these aren't forgotten during AUTH48.

[Ballot discuss]
The PROTO shepherd and the document editor asked to allow for a revised ID to be submitted in order to address issues raised in the SECDIR and GenART reviews.

Gen-ART review by Francis Dupont

I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-imss-fc-fcsp-mib-02.txt
Reviewer: Francis Dupont
Review Date: 2008-06-19
IETF LC End Date: 2008-06-19
IESG Telechat date: unknown

Summary: Ready

Comments: I've found only a low number of editorial (i.e., to be handled by the RFC Editor) problems (spelling errors, typos, raw abbrevs, ...):
(I've put a '?' after suggestions/questionable items, MIB names are for  their descriptions)

- ToC page 2: Acknowledgements -> Acknowledgments
  (i.e., US spelling, same in 7 page 232)

- 1 page 3: IETF's -> IETF? (same in t11FcTcMIB page 27,
  t11FcSpAuthenticationMIB page 43, t11FcSpZoningMIB page 64,
  t11FcSpPolicyMIB page 77, t11FcSpSaMIB page 176, 7 page 232)

- 3.2 page 11: HBAs -> Host Bus Adapters
  (usually abbrevs, including this one, should be introduced by it is
  the only use)

- 3.4.7 page 17: introduce abbrevs: SSB (Server Session Begin), SSE
  (Server Session End), SW_ILS (Switch Fabric Internal Link Services);
  or extend them when they are used once in the introduction part:
  EACA -> Enhanced Acquire Change Authorization Request, ERCA ->
  Enhanced Release Change Authorization, SFC -> Stage Fabric Configuration

- 4.9 page 25: the the -> the (and in t11FcSpAuRejDirection page 58,
  don't believe you can get >240 pages without a typo :-)

- 5 page 26: focussed -> focused?

- t11FcSpAuIfStatOutAcceptedMsgs page 55: neighbouring -> neighboring?

- t11FcSpPoSwMembAuthBehaviour page 89: neighbour -> neighbor?
  (same in t11FcSpPoNaSwMembAuthBehaviour page 129

- t11FcSpPoSwConnAllowedNameType page 99: portname -> portName

- t11FcSpSaIfTerminateAllSas page 183: outsanding -> outstanding

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Network Management Parameters" registry at
http://www.iana.org/assignments/smi-numbers
sub-registry "iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)"

Decimal Name Description References
------- ---- ----------- ----------
[tbd] t11FcTcMIB T11-FC-SP-TC-MIB [RFC-imss-fc-fcsp-mib-02]
[tbd] t11FcSpAuthenticationMIB T11-FC-SP-AUTHENTICATION-MIB
[RFC-imss-fc-fcsp-mib-02]
[tbd] t11FcSpZoningMIB T11-FC-SP-ZONING-MIB [RFC-imss-fc-fcsp-mib-02]
[tbd] t11FcSpPolicyMIB T11-FC-SP-POLICY-MIB [RFC-imss-fc-fcsp-mib-02]
[tbd] t11FcSpSaMIB T11-FC-SP-SA-MIB [RFC-imss-fc-fcsp-mib-02]

We understand the above to be the only IANA Action for this
document.

AD Review by Dan Romascanu

The document is mature and seems stable. As the comments in these review are relatively minor or editorial, I recommend sending the document to IETF Last Call, and consider these comments as LC comments, to be processed and fixed (if necessary) together with other LC comments.


T1. Should not the arrows for Get Policy Summary and Get Policy Objects in the diagram in 3.4.4 be bi-directional?

T2. The DESCRIPTION clause of the T11FcSpHashCalculationStatus TC - 'Writing a value of 'correct' or 'stale' to this object is an error ('wrongValue')." As a MIB module could in theory be used with other protocols than SNMP a better formulation is 'Writing a value of 'correct' or 'stale' to this object is an error (SNMP 'wrongValue' or the equivalent in other protocols)."

T3. Why is not T11FcSpAlphaNumName an SnmpAdminName with the appropriate size limitation?

T4. I do not see storage defined for t11FcSpPoOperTable and no storageType object either


E1. Running idnits results in the following references warnings:

-- Obsolete informational reference (is this intentional?): RFC 2837
    (Obsoleted by RFC 4044)

  -- No information found for draft-ietf-ipsp-ikeaction-mib-nn - is the name
    correct?

  -- No information found for draft-ietf-ipsp-ipsecaction-mib-nn - is the
    name correct?

E2. Please expand the following acronyms at first occurrence: HBA, ESP, SAID

E3. Delete the comment on the SYNTAX line of the T11FcSpPrecedence definition

E4.  Does the notation INCITS xxx/200x mean that the x values need to be filled in? In this case these values should be filled in until the time the document is submitted for approval to the IESG, or appropriate RFC Editor notes should be created to instruct the RFC Editor what to do.

AD Review by Dan Romascanu

The document is mature and seems stable. As the comments in these review are relatively minor or editorial, I recommend sending the document to IETF Last Call, and consider these comments as LC comments, to be processed and fixed (if necessary) together with other LC comments.


T1. Should not the arrows for Get Policy Summary and Get Policy Objects in the diagram in 3.4.4 be bi-directional?

T2. The DESCRIPTION clause of the T11FcSpHashCalculationStatus TC - 'Writing a value of 'correct' or 'stale' to this object is an error ('wrongValue')." As a MIB module could in theory be used with other protocols than SNMP a better formulation is 'Writing a value of 'correct' or 'stale' to this object is an error (SNMP 'wrongValue' or the equivalent in other protocols)."

T3. Why is not T11FcSpAlphaNumName an SnmpAdminName with the appropriate size limitation?

T4. I do not see storage defined for t11FcSpPoOperTable and no storageType object either


E1. Running idnits results in the following references warnings:

-- Obsolete informational reference (is this intentional?): RFC 2837
    (Obsoleted by RFC 4044)

  -- No information found for draft-ietf-ipsp-ikeaction-mib-nn - is the name
    correct?

  -- No information found for draft-ietf-ipsp-ipsecaction-mib-nn - is the
    name correct?

E2. Please expand the following acronyms at first occurrence: HBA, ESP, SAID

E3. Delete the comment on the SYNTAX line of the T11FcSpPrecedence definition

E4.  Does the notation INCITS xxx/200x mean that the x values need to be filled in? In this case these values should be filled in until the time the document is submitted for approval to the IESG, or appropriate RFC Editor notes should be created to instruct the RFC Editor what to do.

Document Shepherd write-up by David Black:

Document Shepherd writeup:

            MIB for Fibre-Channel Security Protocols (FC-SP)
                  draft-ietf-imss-fc-fcsp-mib-02.txt

Requested Publication Status: Proposed Standard
------------------------------------------------------------------------

  (1.a)  Who is the Document Shepherd for this document?

David L. Black (imss WG Chair)

          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?

Yes.  An RFC Editor Note needs to be used to correct nits in one of the
references and numerous REFERENCE clauses:

[1] In Normative References
OLD
[FC-SP]
    "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS xxx-200x,
    http://www.t11.org/t11/stat.nsf/upnum/1570-d, T11/Project
    1570-D/Rev 1.8, 13 June 2003.

NEW
[FC-SP]
    "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS 426-2007,
    http://www.t11.org/t11/stat.nsf/upnum/1570-d, T11/Project
    1570-D, February 2007.

[2] In numerous REFERENCE clauses throughout the MIB modules
OLD
    REFERENCE
          "INCITS xxx/200x, T11/Project 1570-D/Rev 1.8,
          Fibre Channel - Security Protocols (FC-SP),
          13 June 2006, Appendix A.3.1, tables A.23, A.25."
NEW
    REFERENCE
          "ANSI INCITS 426-2007, T11/Project 1570-D,
          Fibre Channel - Security Protocols (FC-SP),
          February 2007, Appendix A.3.1, tables A.23, A.25."
NOTE
The section references (Appendix A.3.1, ...) are different
for each REFERENCE clause, and need to be preserved.

[3] In a couple of REFERENCE clauses in the MIB modules
OLD
          " - Fibre Channel - Framing and Signaling-2 (FC-FS-2),
          INCITS xxx/200x, Project T11/1619-D Rev 1.01,
          8 August 2006, section 9.3.
NEW
          " - Fibre Channel - Framing and Signaling-2 (FC-FS-2),
          ANSI INCITS 424-2007, Project T11/1619-D,
          February 2007, section 9.3.
NOTE
The section references (section 9.3) are different
for each REFERENCE clause, and need to be preserved.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?

Yes.  This document has been reviewed by Fibre Channel experts in
Technical Committee T11 (Fibre Channel standards organization)
in addition to members of the IMSS WG, and the IMSS WG's MIB expert.

          Does the Document Shepherd have any concerns about the depth
          or breadth of the reviews that have been performed?

No.

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

An OPS Area MIB Doctor review was performed during WG Last Call.  There
does not appear to be a need for additional external reviews.

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

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?

It's hard to distinguish the two cases due to somewhat thin WG membership.
There is solid support for this document both in the WG and from T11.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise 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.

Yes.  The idnits checker (2.08.04) finds 2 lines with "non-RFC3330-compliant
IPv4 addresses" - this is not an actual problem because these strings are
actually section references into other standards.

          Has the document met all formal review criteria it needs to,
          such as the MIB Doctor, media type and URI type reviews?

Yes, a MIB Doctor review occurred during WG Last Call, and the MIB
Doctor (Bert Wijnen) is satisfied with this version of the draft.

  (1.h)  Has the document split its references into normative and
          informative?

Yes.

          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?

No.  The RFC Editor Note requested under (1.a) above corrects what
appear to be normative references to in-progress documents.

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

No.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?

Yes.

          If the document specifies protocol extensions, are reservations
          requested in appropriate IANA registries?  Are the IANA
          registries clearly identified?

N/A.

          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 suggested a
          reasonable name for the new registry?  See
          [I-D.narten-iana-considerations-rfc2434bis].

N/A.

          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 the IESG Evaluation?

N/A.

  (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 relied on MIB Doctor review for the MIB
checks.

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

          Technical Summary

  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  In particular, it describes managed objects for information related
  to FC-SP, the Security Protocols defined for Fibre Channel.


          Working Group Summary

  This document was reviewed in the IMSS WG and in Technical Committee
  T11 (the official Fibre Channel standards body).  T11 voted to
  recommend a prior version of this document to the IETF.

          Document Quality

  The protocol has been reviewed for the IMSS WG by Keith McCloghrie.

  The protocol has been reviewed for the IESG by David L. Black (imss WG Chair).

  The MIB Doctor Review performed by Bert Wijnen found a number of
  issues in MIB structure, SMI syntax and documentation.

          Personnel
            Document Shepherd: David L. Black
            Responsible Area Director: Dan Romascanu

MIB for Fibre-Channel Security Protocols (FC-SP)
                  draft-ietf-imss-fc-fcsp-mib-02.txt

Requested Publication Status: Proposed Standard
------------------------------------------------------------------------

  (1.a)  Who is the Document Shepherd for this document?

David L. Black (imss WG Chair)

          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?

Yes.  An RFC Editor Note needs to be used to correct nits in one of the
references and numerous REFERENCE clauses:

[1] In Normative References
OLD
[FC-SP]
    "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS xxx-200x,
    http://www.t11.org/t11/stat.nsf/upnum/1570-d, T11/Project
    1570-D/Rev 1.8, 13 June 2003.

NEW
[FC-SP]
    "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS 426-2007,
    http://www.t11.org/t11/stat.nsf/upnum/1570-d, T11/Project
    1570-D, February 2007.

[2] In numerous REFERENCE clauses throughout the MIB modules
OLD
    REFERENCE
          "INCITS xxx/200x, T11/Project 1570-D/Rev 1.8,
          Fibre Channel - Security Protocols (FC-SP),
          13 June 2006, Appendix A.3.1, tables A.23, A.25."
NEW
    REFERENCE
          "ANSI INCITS 426-2007, T11/Project 1570-D,
          Fibre Channel - Security Protocols (FC-SP),
          February 2007, Appendix A.3.1, tables A.23, A.25."
NOTE
The section references (Appendix A.3.1, ...) are different
for each REFERENCE clause, and need to be preserved.

[3] In a couple of REFERENCE clauses in the MIB modules
OLD
          " - Fibre Channel - Framing and Signaling-2 (FC-FS-2),
          INCITS xxx/200x, Project T11/1619-D Rev 1.01,
          8 August 2006, section 9.3.
NEW
          " - Fibre Channel - Framing and Signaling-2 (FC-FS-2),
          ANSI INCITS 424-2007, Project T11/1619-D,
          February 2007, section 9.3.
NOTE
The section references (section 9.3) are different
for each REFERENCE clause, and need to be preserved.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?

Yes.  This document has been reviewed by Fibre Channel experts in
Technical Committee T11 (Fibre Channel standards organization)
in addition to members of the IMSS WG, and the IMSS WG's MIB expert.

          Does the Document Shepherd have any concerns about the depth
          or breadth of the reviews that have been performed?

No.

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

An OPS Area MIB Doctor review was performed during WG Last Call.  There
does not appear to be a need for additional external reviews.

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

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?

It's hard to distinguish the two cases due to somewhat thin WG membership.
There is solid support for this document both in the WG and from T11.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise 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.

Yes.  The idnits checker (2.08.04) finds 2 lines with "non-RFC3330-compliant
IPv4 addresses" - this is not an actual problem because these strings are
actually section references into other standards.

          Has the document met all formal review criteria it needs to,
          such as the MIB Doctor, media type and URI type reviews?

Yes, a MIB Doctor review occurred during WG Last Call, and the MIB
Doctor (Bert Wijnen) is satisfied with this version of the draft.

  (1.h)  Has the document split its references into normative and
          informative?

Yes.

          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?

No.  The RFC Editor Note requested under (1.a) above corrects what
appear to be normative references to in-progress documents.

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

No.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?

Yes.

          If the document specifies protocol extensions, are reservations
          requested in appropriate IANA registries?  Are the IANA
          registries clearly identified?

N/A.

          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 suggested a
          reasonable name for the new registry?  See
          [I-D.narten-iana-considerations-rfc2434bis].

N/A.

          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 the IESG Evaluation?

N/A.

  (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 relied on MIB Doctor review for the MIB
checks.

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

          Technical Summary

  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  In particular, it describes managed objects for information related
  to FC-SP, the Security Protocols defined for Fibre Channel.


          Working Group Summary

  This document was reviewed in the IMSS WG and in Technical Committee
  T11 (the official Fibre Channel standards body).  T11 voted to
  recommend a prior version of this document to the IETF.

          Document Quality

  The protocol has been reviewed for the IMSS WG by Keith McCloghrie.

  The protocol has been reviewed for the IESG by David L. Black (imss WG Chair).

  The MIB Doctor Review performed by Bert Wijnen found a number of
  issues in MIB structure, SMI syntax and documentation.

          Personnel
            Document Shepherd: David L. Black
            Responsible Area Director: Dan Romascanu