The IESG has approved the following document: - 'Definitions of Managed Objects for iFCP ' <draft-ietf-ips-ifcp-mib-07.txt> as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-mib-07.txt Technical Summary The iFCP protocol can be used by FC to IP based storage gateways for FCP storage interconnects. The iFCP MIB Module is designed to allow SNMP to be used to monitor and manage local iFCP gateway instances, including the configuration of iFCP sessions between gateways. Working Group Summary The working group and the FC standards organization supported this MIB development, as well as the revisions under review. Protocol Quality Keith McLoghrie is the MIB Advisor for the IPS working group and gave guidance in the document's development. Bert Wijnen was the MIB Doctor and gave intensive reviews. The FC industry makes use of this technology, so there has been interim implementation. The Responsible Area Director was Allison Mankin. David Black was the WG Chair shepherd. Notes to RFC Editor Please make the following two changes to: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-mib-07.txt 1) On page 11, Section 4, change FROM: "An entry in the session table." INDEX { ifcpLclGtwyInstIndex, ifcpSessionIndex } ::= {ifcpSessionAttributesTable 1} TO: "Each entry contains information about one iFCP session consisting of a pair of N_PORTs joined by a single TCP/IP connection. This table's INDEX includes ifcpLclGtwyInstIndex which identifies the local iFCP Gateway instance which created the session for the entry. Soon after an entry is created in this table for an iFCP session, it will correspond to an entry in the tcpConnectionTable of the TCP-MIB (RFC 4022). The corresponding entry might represent a pre-existing TCP connection, or it might be a newly-created entry. (Note that if IPv4 is being used, an entry in RFC 2012's tcpConnTable may also correspond.) The values of ifcpSessionLclPrtlAddrType and ifcpSessionRmtPrtlIfAddrType in this table and the values of tcpConnectionLocalAddressType and tcpConnectionRemAddressType used as INDEX values for the corresponding entry in the tcpConnectionTable should be the same; this makes it simpler to locate a session's TCP connection in the TCP-MIB. (Of course, all four values need to be 'ipv4' if there's a corresponding entry in the tcpConnTable.) If an entry is created in this table for a session, prior to knowing which local and/or remote port numbers will be used for the TCP connection, then ifcpSessionLclPrtlTcpPort and/or ifcpSessionRmtPrtlTcpPort have the value zero until such time as they can be updated to the port numbers (to be) used for the connection. (Thus, a port value of zero should not be used to locate a session's TCP connection in the TCP-MIB.) When the TCP connection terminates, the entry in the tcpConnectionTable and the entry in this table both get deleted (and, if applicable, so does the entry in the tcpConnTable)." INDEX { ifcpLclGtwyInstIndex, ifcpSessionIndex } ::= {ifcpSessionAttributesTable 1} 2) On page 21, Section 4, change FROM: } ::= {ifcpCompliances 1} TO: } OBJECT ifcpSessionLclPrtlAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "Support is only required for global IPv4 and IPv6 address types." OBJECT ifcpSessionRmtPrtlIfAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "Support is only required for global IPv4 and IPv6 address types." ::= {ifcpCompliances 1} _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
