From owner-ipfc@standards.gadzoox.com Thu Jun 3 13:34:11 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09678 for ; Thu, 3 Jun 1999 13:34:10 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA29113 for ipfc-list; Thu, 3 Jun 1999 10:29:16 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id KAA29110 for ; Thu, 3 Jun 1999 10:29:15 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 3 Jun 1999 10:34:07 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A15D29B@gordan.pl.gadzoox.com> From: Rajeev Atluri To: "'ipfc@standards.gadzoox.com'" Cc: "'jpallen@austin.ibm.com'" Subject: IPv6 & FC Date: Thu, 3 Jun 1999 10:34:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk From: Jim Allen Message-Id: <199906022004.PAA22224@scallop.austin.ibm.com> Subject: IPv6 & FC To: ipfc@standards.gadzoox.com Date: Wed, 2 Jun 1999 15:04:41 -0500 (CDT) Cc: bkovacs@austin.ibm.com We're (IBM AIX) interested in doing IPV6 over FC. All of the documentation I have seen is primarily IPv4 with some support for 128 bit addresses (i.e. FARP ELS). The main issues, that I'm interested in are the extensions of FARP for IPV6 as well as how neighbor discovery would work. Is anyone currently discussing this? The main document I have been reviewing is IETFs "IP and ARP over Fibre Channel Working Group Internet Draft" Rev 5.0. Are the other IP over FC documents I should be reviewing. Thanks. -- ============================================================================ == Jim Allen IBM RS/6000 Division, AIX Base Device Drivers Austin, TX Internet: jpallen@austin.ibm.com Vnet : Get real! (JPALLEN at AUSTIN) Office : 5G-015/905, ZIP 9551 Phone : (512)-838-3346 T/L: 678-3346 FAX : (512)-838-3509 T/L: 678-3509 ============================================================================ == From owner-ipfc@standards.gadzoox.com Fri Jun 4 17:38:29 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11504 for ; Fri, 4 Jun 1999 17:38:28 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id OAA29606 for ipfc-list; Fri, 4 Jun 1999 14:33:09 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id OAA29603 for ; Fri, 4 Jun 1999 14:33:08 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Jun 1999 14:38:01 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A116FA2@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: FW: 45th IETF: AGENDA Date: Fri, 4 Jun 1999 14:37:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk -----Original Message----- From: agenda@ietf.org [mailto:agenda@ietf.org] Sent: Friday, June 04, 1999 1:50 PM Subject: 45th IETF: AGENDA Draft Agenda of the Forty-fifth IETF July 12-16, 1999 As of June 4, 1999 SUNDAY, July 11, 1999 1200-1900 Registration (Pre-paid Packet Pick-up) - Ballroom Foyer 1500-1900 Registration (Pre-registered and On-site) - Ballroom Foyer 1530-1630 Newcomer's Orientation - Olympia Room 1700-1900 Welcome Reception - Sonia Henie Ballroom MONDAY, July 12, 1999 0730-1930 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions APP appsarea Applications Open Area Meeting INT dhc Dynamnic Host Configuration WG RTG mpls Multiprotocol label Switching WG SEC cat Common Authentication Technology WG TSV rap RSVP Admission Policy WG 1130-1300 Break 1300-1500 Afternoon Sessions I OPS ngtrans Next Generation Transition WG RTG mpls Multiprotocol label Switching WG SEC xmldsig XML Digital Signatures WG TSV nfsv4 Network File System Version 4 WG USV uswg User Services WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer 1530-1730 Afternoon Sessions II APP calsch Calendaring and Scheduling WG INT dnsind DNS IXFR, Notification, and Dynamic Update WG INT ipcdn IP over Cable Data Network WG OPS adslmib ADSL MIB WG RTG msdp Multicast Source Discovery Protocol WG TSV diffserv Differentiated Services WG 1730-1930 Break 1930-2200 Evening Sessions GEN policy Policy Framework WG INT dhc Dynamnic Host Configuration WG RTG udlr UniDirectional Link Routing WG TUESDAY, July 13, 1999 0800-1700 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions I APP fax Internet Fax WG OPS ngtrans Next Generation Transition WG RTG pim Protocol Independent Multicast WG SEC xmldsig XML Digital Signatures WG TSV rsvp Resource Rservation Setup Protocol WG 1300-1400 Afternoon Sessions I OPS rps Routing Policy System WG RTG vrrp Virtual Router Redendancy Protocol WG SEC ipsec IP Security Protocol WG 1415-1515 Afternoon Sessions II INT netwklr Network Layer BOF OPS rps Routing Policy System WG SEC ipsec IP Security Protocol WG 1515-1545 Break (Refreshments provided) - Ballroom Foyer 1545-1645 Afternoon Sessions III GEN policy Policy Framework WG RTG idmr Inter-Domain Multicast Routing WG SEC otp One Time Password Authentication WG TSV nat Network Address Translators WG 1700-1800 Afternoon Sessions IV APP calsch Calendaring and Scheduling WG GEN policy Policy Framework WG INT frnetmib Frame Relay Service MIB WG TSV nat Network Address Translators WG WEDNESDAY, July 14, 1999 0800-1700 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions INT ipngwg IPNG WG GEN poisson Process for Organization of Internet Standards WG OPS disman Distributed Management WG RTG manet Mobile Ad-hoc Networks WG SEC pkix Public-Key Infrastructure (X.509) WG TSV avt Audio/Visual Transport WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP trade Internet Open Trading Protocol WG INT ipfc IP Over Fibre Channel WG OPS mboned MBONE Deployment WG RTG manet Mobile Ad-hoc Networks WG SEC pkix Public-Key Infrastructure (X.509) WG TSV sigtran Signaling Transport WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer 1530-1730 Afternoon Sessions II APP deltav Web Versioning and Configuration Management WG INT pppext Point-to-Point Protocol Extensions WG OPS rmonmib Remote Network Monitoring WG RTG rtgarea Routing Open Area Meeting TSV decides Deployment Considerations of Implementing Differentiated BOF 1730-1930 Break 1930-2200 Open Plenary - Sonia Henie Ballroom o Welcome - Fred Baker, IETF Chair o Dr. Houlin Zhou, General Secretary of the ITU o IAB Plenary o IESG Plenary o ICANN/PSO MoU Discussion 2230 Late Night Session PGP Key Signing THURSDAY, July 15, 1999 0800-1700 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions APP webdav WWW Distributed Authoring and Versioning WG OPS opsarea Operations & Management Open Area Meeting SEC idwg Intrusion Detection Exchange Format WG TSV megaco Media Gateway Control WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP ldapext LDAP Extension WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC saag Open Security Area Directorate Meeting TSV iptel IP Telephony WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer 1530-1730 Afternoon Sessions II OPS bmwg Benchmarking Methodology WG RTG gsmp General Switch Management Protocol WG SEC smime S/MIME Mail Security WG TSV avt Audio/Visual Transport WG 1730-1930 Break 1930-2200 Evening Sessions APP impp Instant Messaging and Presence Protocol WG OPS dnsop Domain Name Server Operations WG RTG gsmp General Switch Management Protocol WG TSV malloc Multicast-Address Allocation WG FRIDAY, July 16, 1999 0800-1000 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions APP ldup LDAP Duplication/Replication/Update Protocols WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC idwg Intrusion Detection Exchange Format WG TSV sigtran Signaling Transport WG ======================================================================= Area Directors APP Applications Keith Moore/UTK and Patrik Faltstrom/Tele2/Swipnet GEN General Interest Fred Baker/Cisco Systems INT Internet Thomas Narten/IBM Corporation and Erik Nordmark/Sun Microsystems OPS Operations & Management Randy Bush/Verio, Inc. and Bert Wijnen/IBM Netherlands RTG Routing Rob Coltun/Lightera Networks and Dave Oran/Cisco Systems SEC Security Marcus Leech/Nortel and Jeff Schiller/MIT TSV Transport Scott Bradner/Harvard Univ. and Vern Paxson/ACIRI/LBNL USV User Services April Marine/Internet Engines, Inc. From owner-ipfc@standards.gadzoox.com Mon Jun 14 23:39:43 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29259 for ; Mon, 14 Jun 1999 23:39:42 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id UAA01804 for ipfc-list; Mon, 14 Jun 1999 20:34:03 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from ausmail2.austin.ibm.com (ausmail2.austin.ibm.com [192.35.232.11]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id UAA01801 for ; Mon, 14 Jun 1999 20:34:01 -0700 Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by ausmail2.austin.ibm.com (8.9.1/8.8.5) with ESMTP id WAA52792 for ; Mon, 14 Jun 1999 22:22:31 -0500 Received: from scallop.austin.ibm.com (scallop.austin.ibm.com [9.53.150.156]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id WAA33484 for ; Mon, 14 Jun 1999 22:26:32 -0500 Received: (from jpallen@localhost) by scallop.austin.ibm.com (AIX4.3/UCB 8.8.8/8.7-client1.01) id WAA05050 for ipfc@standards.gadzoox.com; Mon, 14 Jun 1999 22:26:31 -0500 From: Jim Allen Message-Id: <199906150326.WAA05050@scallop.austin.ibm.com> Subject: IPv6 extension for FARP To: ipfc@standards.gadzoox.com Date: Mon, 14 Jun 1999 22:26:31 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit I was wondering if it would be possible to extend the Match Address Code Points defined in section 5.4 and in Appendix A to explicity deal with IPv6 Addresses in FARP. Currently FARP can handle 128 bit IP addresses, but there is now match address code point explicitily for IPv6. At some point Neighbor Discovery on FC will need addressed, but in the interim extending FARP to explicitly handle IPv6 address may be be useful. A possible approach follows. Please send me feedback on this proposal. An alternate approach to what follows is to generalize the existing IPv4 match address code points to be used for either IPv4 or IPv6. Thanks. -------------------- In Section 5.4 (page 20), update the table for "Match Address Code Points" for IPv6. Here is a possible implementation: +------------------------------------------------------------------+ | Match Address Code Points | +------------------------------------------------------------------+ | LSBits | Bit name | Action | +-----------+--------------------+---------------------------------+ | 0000 | Reserved | | +-----------+--------------------+---------------------------------+ | 0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-----------+--------------------+---------------------------------+ | 0010 | MATCH_WW_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0100 | MATCH_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1000 | MATCH_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1001 | MATCH_WW_PN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1010 | MATCH_WW_NN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1011 | MATCH_WW_PN_NN_IPv6| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ In Appendix A, these changes would also be described. So that it would look something like: Section 5 described the FC Layer mapping between the WW_PN and the Port_ID using the FARP Protocol. This appendix describes other optional criteria for address matching and includes: - WW_NN - WW_PN & WW_NN at the same time - IPv4 - IPv4 & WW_PN at the same time - IPv4 & WW_NN at the same time - IPv4 & WW_PN & WW_NN at the same time - IPv6 - IPv6 & WW_PN at the same time - IPv6 & WW_NN at the same time - IPv6 & WW_PN & WW_NN at the same time Depending on the Match Address Code Points, the FARP protocol fundamentally resolves five main types of addresses to Port_IDs and is described in table below. - For Match Address Code Point b'0001': WW_PN Names fields are used to resolve the WW_PN names to Port_IDs. WW_NN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0010': WW_NN Names fields are used to resolve the WW_NN names to Port_IDs. WW_PN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0100': IPv4 fields are used to resolve the IPv4 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'1000': IPv6 fields are used to resolve the IPv6 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For all other Match Address Code Points b'0011', b'0101',b'0110', b'0111' ,b'1001' ,b'1010' ,b'1011, depending on set bits one or more addresses are jointly resolved to a Port_ID. See table below. If fields are not used, then they are set either to '0' or valid addresses. +--------------------------------------------------------------------+ | Match Address Code Points | +--------------------------------------------------------------------+ | LSBits| Bit name | Action | +-------+--------------------+---------------------------------------+ |0000 | Reserved | | +-------+--------------------+---------------------------------------+ |0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-------+--------------------+---------------------------------------+ |0010 | MATCH_WW_NN | If 'WW_NN of Responder' = | | | | Node's WW_NN then respond | +-------+--------------------+---------------------------------------+ |0011 | MATCH_WW_PN_NN | If both 'WW_PN of Responder' & | | | | 'WW_NN of Responder' = | | | | Node's WW_PN & WW_NN then respond | +-------+--------------------+---------------------------------------+ |0100 | MATCH_IPv4 | If 'IPv4 Address of Responder' = | | | | Node's IPv4 Address then respond | +-------+--------------------+---------------------------------------+ |0101 | MATCH_WW_PN_IPv4 | If 'WW_PN & IPv4 of Responder' = | | | | Node's WW_PN and IPv4 then respond | +-------+--------------------+---------------------------------------+ |0110 | MATCH_WW_NN_IPv4 | If both 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Node's WW_NN & IPv4 then respond | +-------+--------------------+---------------------------------------+ |0111 |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv4 | | | | then respond | +-------+--------------------+---------------------------------------+ |1000 | MATCH_IPv6 | If 'IPv6 Address of Responder' = | | | | Node's IPv6 Address then respond | +-------+--------------------+---------------------------------------+ |1001 | MATCH_WW_PN_IPv6 | If 'WW_PN & IPv6 of Responder' = | | | | Node's WW_PN and IPv6 then respond | +-------+--------------------+---------------------------------------+ |1010 | MATCH_WW_NN_IPv6 | If both 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Node's WW_NN & IPv6 then respond | +-------+--------------------+---------------------------------------+ |1011 |MATCH_WW_PN_NN_IPv6 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv6 | | | | then respond | +-------+--------------------+---------------------------------------+ For the FARP-REQUEST/REPLY command the "IP Add." fields would be updated something like: +-------------------------------+---------+---------------------------+ |IP Add. of Requester | 16 |OPTIONAL; Supplied by | | | |Requester | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ |IP Address of Responder | 16 |OPTIONAL; Supplied by | | | |Requester or Responder | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ -- ============================================================================== Jim Allen IBM RS/6000 Division, AIX Base Device Drivers Austin, TX Internet: jpallen@austin.ibm.com Vnet : Get real! (JPALLEN at AUSTIN) Office : 5G-015/905, ZIP 9551 Phone : (512)-838-3346 T/L: 678-3346 FAX : (512)-838-3509 T/L: 678-3509 ============================================================================== From owner-ipfc@standards.gadzoox.com Tue Jun 15 11:52:49 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21715 for ; Tue, 15 Jun 1999 11:52:48 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA02109 for ipfc-list; Tue, 15 Jun 1999 08:47:24 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id IAA02106 for ; Tue, 15 Jun 1999 08:47:23 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Jun 1999 08:52:19 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A116FC2@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'Jim Allen'" , ipfc@standards.gadzoox.com Subject: RE: IPv6 extension for FARP Date: Tue, 15 Jun 1999 08:51:43 -0700 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Folks: A clarification for those who may be wondering how Jim's proposed extension fits with the current draft. The extension is for a completely new draft proposal "IPv6 Over FC" that is yet to be discussed and adopted as a new work item if sufficient interest prevails. I like to hear your comments about adopting this as a new work item. Regards, Murali Rajagopal IPFC WG Chair -----Original Message----- From: Jim Allen [mailto:jpallen@austin.ibm.com] Sent: Monday, June 14, 1999 8:27 PM To: ipfc@standards.gadzoox.com Subject: IPv6 extension for FARP I was wondering if it would be possible to extend the Match Address Code Points defined in section 5.4 and in Appendix A to explicity deal with IPv6 Addresses in FARP. Currently FARP can handle 128 bit IP addresses, but there is now match address code point explicitily for IPv6. At some point Neighbor Discovery on FC will need addressed, but in the interim extending FARP to explicitly handle IPv6 address may be be useful. A possible approach follows. Please send me feedback on this proposal. An alternate approach to what follows is to generalize the existing IPv4 match address code points to be used for either IPv4 or IPv6. Thanks. -------------------- In Section 5.4 (page 20), update the table for "Match Address Code Points" for IPv6. Here is a possible implementation: +------------------------------------------------------------------+ | Match Address Code Points | +------------------------------------------------------------------+ | LSBits | Bit name | Action | +-----------+--------------------+---------------------------------+ | 0000 | Reserved | | +-----------+--------------------+---------------------------------+ | 0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-----------+--------------------+---------------------------------+ | 0010 | MATCH_WW_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0100 | MATCH_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1000 | MATCH_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1001 | MATCH_WW_PN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1010 | MATCH_WW_NN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1011 | MATCH_WW_PN_NN_IPv6| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ In Appendix A, these changes would also be described. So that it would look something like: Section 5 described the FC Layer mapping between the WW_PN and the Port_ID using the FARP Protocol. This appendix describes other optional criteria for address matching and includes: - WW_NN - WW_PN & WW_NN at the same time - IPv4 - IPv4 & WW_PN at the same time - IPv4 & WW_NN at the same time - IPv4 & WW_PN & WW_NN at the same time - IPv6 - IPv6 & WW_PN at the same time - IPv6 & WW_NN at the same time - IPv6 & WW_PN & WW_NN at the same time Depending on the Match Address Code Points, the FARP protocol fundamentally resolves five main types of addresses to Port_IDs and is described in table below. - For Match Address Code Point b'0001': WW_PN Names fields are used to resolve the WW_PN names to Port_IDs. WW_NN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0010': WW_NN Names fields are used to resolve the WW_NN names to Port_IDs. WW_PN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0100': IPv4 fields are used to resolve the IPv4 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'1000': IPv6 fields are used to resolve the IPv6 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For all other Match Address Code Points b'0011', b'0101',b'0110', b'0111' ,b'1001' ,b'1010' ,b'1011, depending on set bits one or more addresses are jointly resolved to a Port_ID. See table below. If fields are not used, then they are set either to '0' or valid addresses. +--------------------------------------------------------------------+ | Match Address Code Points | +--------------------------------------------------------------------+ | LSBits| Bit name | Action | +-------+--------------------+---------------------------------------+ |0000 | Reserved | | +-------+--------------------+---------------------------------------+ |0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-------+--------------------+---------------------------------------+ |0010 | MATCH_WW_NN | If 'WW_NN of Responder' = | | | | Node's WW_NN then respond | +-------+--------------------+---------------------------------------+ |0011 | MATCH_WW_PN_NN | If both 'WW_PN of Responder' & | | | | 'WW_NN of Responder' = | | | | Node's WW_PN & WW_NN then respond | +-------+--------------------+---------------------------------------+ |0100 | MATCH_IPv4 | If 'IPv4 Address of Responder' = | | | | Node's IPv4 Address then respond | +-------+--------------------+---------------------------------------+ |0101 | MATCH_WW_PN_IPv4 | If 'WW_PN & IPv4 of Responder' = | | | | Node's WW_PN and IPv4 then respond | +-------+--------------------+---------------------------------------+ |0110 | MATCH_WW_NN_IPv4 | If both 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Node's WW_NN & IPv4 then respond | +-------+--------------------+---------------------------------------+ |0111 |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv4 | | | | then respond | +-------+--------------------+---------------------------------------+ |1000 | MATCH_IPv6 | If 'IPv6 Address of Responder' = | | | | Node's IPv6 Address then respond | +-------+--------------------+---------------------------------------+ |1001 | MATCH_WW_PN_IPv6 | If 'WW_PN & IPv6 of Responder' = | | | | Node's WW_PN and IPv6 then respond | +-------+--------------------+---------------------------------------+ |1010 | MATCH_WW_NN_IPv6 | If both 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Node's WW_NN & IPv6 then respond | +-------+--------------------+---------------------------------------+ |1011 |MATCH_WW_PN_NN_IPv6 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv6 | | | | then respond | +-------+--------------------+---------------------------------------+ For the FARP-REQUEST/REPLY command the "IP Add." fields would be updated something like: +-------------------------------+---------+---------------------------+ |IP Add. of Requester | 16 |OPTIONAL; Supplied by | | | |Requester | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ |IP Address of Responder | 16 |OPTIONAL; Supplied by | | | |Requester or Responder | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ -- ============================================================================ == Jim Allen IBM RS/6000 Division, AIX Base Device Drivers Austin, TX Internet: jpallen@austin.ibm.com Vnet : Get real! (JPALLEN at AUSTIN) Office : 5G-015/905, ZIP 9551 Phone : (512)-838-3346 T/L: 678-3346 FAX : (512)-838-3509 T/L: 678-3509 ============================================================================ == From owner-ipfc@standards.gadzoox.com Tue Jun 15 12:25:52 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22631 for ; Tue, 15 Jun 1999 12:25:51 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id JAA02152 for ipfc-list; Tue, 15 Jun 1999 09:20:44 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id JAA02149 for ; Tue, 15 Jun 1999 09:20:42 -0700 Received: from emuweb.emulex.com (emuweb.emulex.com [138.239.112.10]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id JAA04006; Tue, 15 Jun 1999 09:23:44 -0700 (PDT) Received: from jinfantepc.emulex.com (localhost [127.0.0.1]) by emuweb.emulex.com (8.9.1/8.9.1) with SMTP id JAA23908; Tue, 15 Jun 1999 09:23:43 -0700 (PDT) Received: by jinfantepc.emulex.com with Microsoft Mail id <01BEB710.B7B1DFC0@jinfantepc.emulex.com>; Tue, 15 Jun 1999 09:23:24 -0700 Message-ID: <01BEB710.B7B1DFC0@jinfantepc.emulex.com> From: "Infante, Jon" To: "'Jim Allen'" , "ipfc@standards.gadzoox.com" , "'Murali Rajagopal'" Subject: RE: IPv6 extension for FARP Date: Tue, 15 Jun 1999 09:23:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Are there currently any IPv6 over XXXXX Drafts that we could look at for reference? Jon ---------- From: Murali Rajagopal Sent: Tuesday, June 15, 1999 8:51 AM To: 'Jim Allen'; ipfc@standards.gadzoox.com Subject: RE: IPv6 extension for FARP Folks: A clarification for those who may be wondering how Jim's proposed extension fits with the current draft. The extension is for a completely new draft proposal "IPv6 Over FC" that is yet to be discussed and adopted as a new work item if sufficient interest prevails. I like to hear your comments about adopting this as a new work item. Regards, Murali Rajagopal IPFC WG Chair -----Original Message----- From: Jim Allen [mailto:jpallen@austin.ibm.com] Sent: Monday, June 14, 1999 8:27 PM To: ipfc@standards.gadzoox.com Subject: IPv6 extension for FARP I was wondering if it would be possible to extend the Match Address Code Points defined in section 5.4 and in Appendix A to explicity deal with IPv6 Addresses in FARP. Currently FARP can handle 128 bit IP addresses, but there is now match address code point explicitily for IPv6. At some point Neighbor Discovery on FC will need addressed, but in the interim extending FARP to explicitly handle IPv6 address may be be useful. A possible approach follows. Please send me feedback on this proposal. An alternate approach to what follows is to generalize the existing IPv4 match address code points to be used for either IPv4 or IPv6. Thanks. -------------------- In Section 5.4 (page 20), update the table for "Match Address Code Points" for IPv6. Here is a possible implementation: +------------------------------------------------------------------+ | Match Address Code Points | +------------------------------------------------------------------+ | LSBits | Bit name | Action | +-----------+--------------------+---------------------------------+ | 0000 | Reserved | | +-----------+--------------------+---------------------------------+ | 0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-----------+--------------------+---------------------------------+ | 0010 | MATCH_WW_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0100 | MATCH_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1000 | MATCH_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1001 | MATCH_WW_PN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1010 | MATCH_WW_NN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1011 | MATCH_WW_PN_NN_IPv6| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ In Appendix A, these changes would also be described. So that it would look something like: Section 5 described the FC Layer mapping between the WW_PN and the Port_ID using the FARP Protocol. This appendix describes other optional criteria for address matching and includes: - WW_NN - WW_PN & WW_NN at the same time - IPv4 - IPv4 & WW_PN at the same time - IPv4 & WW_NN at the same time - IPv4 & WW_PN & WW_NN at the same time - IPv6 - IPv6 & WW_PN at the same time - IPv6 & WW_NN at the same time - IPv6 & WW_PN & WW_NN at the same time Depending on the Match Address Code Points, the FARP protocol fundamentally resolves five main types of addresses to Port_IDs and is described in table below. - For Match Address Code Point b'0001': WW_PN Names fields are used to resolve the WW_PN names to Port_IDs. WW_NN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0010': WW_NN Names fields are used to resolve the WW_NN names to Port_IDs. WW_PN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0100': IPv4 fields are used to resolve the IPv4 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'1000': IPv6 fields are used to resolve the IPv6 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For all other Match Address Code Points b'0011', b'0101',b'0110', b'0111' ,b'1001' ,b'1010' ,b'1011, depending on set bits one or more addresses are jointly resolved to a Port_ID. See table below. If fields are not used, then they are set either to '0' or valid addresses. +--------------------------------------------------------------------+ | Match Address Code Points | +--------------------------------------------------------------------+ | LSBits| Bit name | Action | +-------+--------------------+---------------------------------------+ |0000 | Reserved | | +-------+--------------------+---------------------------------------+ |0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-------+--------------------+---------------------------------------+ |0010 | MATCH_WW_NN | If 'WW_NN of Responder' = | | | | Node's WW_NN then respond | +-------+--------------------+---------------------------------------+ |0011 | MATCH_WW_PN_NN | If both 'WW_PN of Responder' & | | | | 'WW_NN of Responder' = | | | | Node's WW_PN & WW_NN then respond | +-------+--------------------+---------------------------------------+ |0100 | MATCH_IPv4 | If 'IPv4 Address of Responder' = | | | | Node's IPv4 Address then respond | +-------+--------------------+---------------------------------------+ |0101 | MATCH_WW_PN_IPv4 | If 'WW_PN & IPv4 of Responder' = | | | | Node's WW_PN and IPv4 then respond | +-------+--------------------+---------------------------------------+ |0110 | MATCH_WW_NN_IPv4 | If both 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Node's WW_NN & IPv4 then respond | +-------+--------------------+---------------------------------------+ |0111 |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv4 | | | | then respond | +-------+--------------------+---------------------------------------+ |1000 | MATCH_IPv6 | If 'IPv6 Address of Responder' = | | | | Node's IPv6 Address then respond | +-------+--------------------+---------------------------------------+ |1001 | MATCH_WW_PN_IPv6 | If 'WW_PN & IPv6 of Responder' = | | | | Node's WW_PN and IPv6 then respond | +-------+--------------------+---------------------------------------+ |1010 | MATCH_WW_NN_IPv6 | If both 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Node's WW_NN & IPv6 then respond | +-------+--------------------+---------------------------------------+ |1011 |MATCH_WW_PN_NN_IPv6 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv6 | | | | then respond | +-------+--------------------+---------------------------------------+ For the FARP-REQUEST/REPLY command the "IP Add." fields would be updated something like: +-------------------------------+---------+---------------------------+ |IP Add. of Requester | 16 |OPTIONAL; Supplied by | | | |Requester | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ |IP Address of Responder | 16 |OPTIONAL; Supplied by | | | |Requester or Responder | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ -- ============================================================================ == Jim Allen IBM RS/6000 Division, AIX Base Device Drivers Austin, TX Internet: jpallen@austin.ibm.com Vnet : Get real! (JPALLEN at AUSTIN) Office : 5G-015/905, ZIP 9551 Phone : (512)-838-3346 T/L: 678-3346 FAX : (512)-838-3509 T/L: 678-3509 ============================================================================ == From owner-ipfc@standards.gadzoox.com Tue Jun 15 12:33:01 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22836 for ; Tue, 15 Jun 1999 12:33:00 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id JAA02160 for ipfc-list; Tue, 15 Jun 1999 09:28:24 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id JAA02157 for ; Tue, 15 Jun 1999 09:28:23 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Jun 1999 09:33:19 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A116FC8@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'Infante, Jon'" , "'Jim Allen'" , ipfc@standards.gadzoox.com, Murali Rajagopal Subject: RE: IPv6 extension for FARP Date: Tue, 15 Jun 1999 09:32:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Some IPv6 over xxx drafts: http URL:draft-ietf-ip1394-ipv6-00.txt Summary Title: Transmission of IPv6 Packets over IEEE 1394 Networks http URL:draft-yamamoto-ipv6-over-p2p-atm-01.txt Summary Title: IPv6 over Point-to-Point ATM Link Other applicable drafts: http URL:draft-ietf-ngtrans-introduction-to-ipv6-transition-00.txt Summary Title: A Guide to the Introduction of IPv6 in the IPv4 World 16. http URL:draft-ietf-ipngwg-site-prefixes-02.txt Summary Title: Site prefixes in Neighbor Discovery 17. -----Original Message----- From: Infante, Jon [mailto:Jon.Infante@emulex.com] Sent: Tuesday, June 15, 1999 9:23 AM To: 'Jim Allen'; ipfc@standards.gadzoox.com; 'Murali Rajagopal' Subject: RE: IPv6 extension for FARP Are there currently any IPv6 over XXXXX Drafts that we could look at for reference? Jon ---------- From: Murali Rajagopal Sent: Tuesday, June 15, 1999 8:51 AM To: 'Jim Allen'; ipfc@standards.gadzoox.com Subject: RE: IPv6 extension for FARP Folks: A clarification for those who may be wondering how Jim's proposed extension fits with the current draft. The extension is for a completely new draft proposal "IPv6 Over FC" that is yet to be discussed and adopted as a new work item if sufficient interest prevails. I like to hear your comments about adopting this as a new work item. Regards, Murali Rajagopal IPFC WG Chair -----Original Message----- From: Jim Allen [mailto:jpallen@austin.ibm.com] Sent: Monday, June 14, 1999 8:27 PM To: ipfc@standards.gadzoox.com Subject: IPv6 extension for FARP I was wondering if it would be possible to extend the Match Address Code Points defined in section 5.4 and in Appendix A to explicity deal with IPv6 Addresses in FARP. Currently FARP can handle 128 bit IP addresses, but there is now match address code point explicitily for IPv6. At some point Neighbor Discovery on FC will need addressed, but in the interim extending FARP to explicitly handle IPv6 address may be be useful. A possible approach follows. Please send me feedback on this proposal. An alternate approach to what follows is to generalize the existing IPv4 match address code points to be used for either IPv4 or IPv6. Thanks. -------------------- In Section 5.4 (page 20), update the table for "Match Address Code Points" for IPv6. Here is a possible implementation: +------------------------------------------------------------------+ | Match Address Code Points | +------------------------------------------------------------------+ | LSBits | Bit name | Action | +-----------+--------------------+---------------------------------+ | 0000 | Reserved | | +-----------+--------------------+---------------------------------+ | 0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-----------+--------------------+---------------------------------+ | 0010 | MATCH_WW_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0100 | MATCH_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1000 | MATCH_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1001 | MATCH_WW_PN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1010 | MATCH_WW_NN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1011 | MATCH_WW_PN_NN_IPv6| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ In Appendix A, these changes would also be described. So that it would look something like: Section 5 described the FC Layer mapping between the WW_PN and the Port_ID using the FARP Protocol. This appendix describes other optional criteria for address matching and includes: - WW_NN - WW_PN & WW_NN at the same time - IPv4 - IPv4 & WW_PN at the same time - IPv4 & WW_NN at the same time - IPv4 & WW_PN & WW_NN at the same time - IPv6 - IPv6 & WW_PN at the same time - IPv6 & WW_NN at the same time - IPv6 & WW_PN & WW_NN at the same time Depending on the Match Address Code Points, the FARP protocol fundamentally resolves five main types of addresses to Port_IDs and is described in table below. - For Match Address Code Point b'0001': WW_PN Names fields are used to resolve the WW_PN names to Port_IDs. WW_NN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0010': WW_NN Names fields are used to resolve the WW_NN names to Port_IDs. WW_PN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0100': IPv4 fields are used to resolve the IPv4 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'1000': IPv6 fields are used to resolve the IPv6 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For all other Match Address Code Points b'0011', b'0101',b'0110', b'0111' ,b'1001' ,b'1010' ,b'1011, depending on set bits one or more addresses are jointly resolved to a Port_ID. See table below. If fields are not used, then they are set either to '0' or valid addresses. +--------------------------------------------------------------------+ | Match Address Code Points | +--------------------------------------------------------------------+ | LSBits| Bit name | Action | +-------+--------------------+---------------------------------------+ |0000 | Reserved | | +-------+--------------------+---------------------------------------+ |0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-------+--------------------+---------------------------------------+ |0010 | MATCH_WW_NN | If 'WW_NN of Responder' = | | | | Node's WW_NN then respond | +-------+--------------------+---------------------------------------+ |0011 | MATCH_WW_PN_NN | If both 'WW_PN of Responder' & | | | | 'WW_NN of Responder' = | | | | Node's WW_PN & WW_NN then respond | +-------+--------------------+---------------------------------------+ |0100 | MATCH_IPv4 | If 'IPv4 Address of Responder' = | | | | Node's IPv4 Address then respond | +-------+--------------------+---------------------------------------+ |0101 | MATCH_WW_PN_IPv4 | If 'WW_PN & IPv4 of Responder' = | | | | Node's WW_PN and IPv4 then respond | +-------+--------------------+---------------------------------------+ |0110 | MATCH_WW_NN_IPv4 | If both 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Node's WW_NN & IPv4 then respond | +-------+--------------------+---------------------------------------+ |0111 |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv4 | | | | then respond | +-------+--------------------+---------------------------------------+ |1000 | MATCH_IPv6 | If 'IPv6 Address of Responder' = | | | | Node's IPv6 Address then respond | +-------+--------------------+---------------------------------------+ |1001 | MATCH_WW_PN_IPv6 | If 'WW_PN & IPv6 of Responder' = | | | | Node's WW_PN and IPv6 then respond | +-------+--------------------+---------------------------------------+ |1010 | MATCH_WW_NN_IPv6 | If both 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Node's WW_NN & IPv6 then respond | +-------+--------------------+---------------------------------------+ |1011 |MATCH_WW_PN_NN_IPv6 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv6 | | | | then respond | +-------+--------------------+---------------------------------------+ For the FARP-REQUEST/REPLY command the "IP Add." fields would be updated something like: +-------------------------------+---------+---------------------------+ |IP Add. of Requester | 16 |OPTIONAL; Supplied by | | | |Requester | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ |IP Address of Responder | 16 |OPTIONAL; Supplied by | | | |Requester or Responder | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ -- ============================================================================ == Jim Allen IBM RS/6000 Division, AIX Base Device Drivers Austin, TX Internet: jpallen@austin.ibm.com Vnet : Get real! (JPALLEN at AUSTIN) Office : 5G-015/905, ZIP 9551 Phone : (512)-838-3346 T/L: 678-3346 FAX : (512)-838-3509 T/L: 678-3509 ============================================================================ == From owner-ipfc@standards.gadzoox.com Tue Jun 15 13:27:44 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24021 for ; Tue, 15 Jun 1999 13:27:39 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA02191 for ipfc-list; Tue, 15 Jun 1999 10:22:48 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id KAA02188 for ; Tue, 15 Jun 1999 10:22:42 -0700 Received: from fishbowl02.emc.com (fishbowl02 [168.159.48.62]) by emcmail.lss.emc.com (8.9.3/8.9.3) with SMTP id NAA04334 for ; Tue, 15 Jun 1999 13:25:30 -0400 (EDT) Received: by fishbowl02.emc.com with VINES-ISMTP; Tue, 15 Jun 1999 13:25:45 -0400 Date: Tue, 15 Jun 1999 13:25:43 -0400 Message-ID: X-Priority: 3 (Normal) To: From: "steven blumenau" Reply-To: Subject: New draft announcement X-Incognito-SN: 1467 X-Incognito-Version: 5.0.1.47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk I have gotten a number of emails asking where this was. Steven Blumenau EMC Corp I-D ACTION:draft-blumenau-fcmgmt-int-mib-01.txt -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: I-D ACTION:draft-blumenau-fcmgmt-int-mib-01.txt From: Internet-Drafts@optimus.ietf.org Date: Fri, 04 Jun 1999 07:19:14 -0400 Reply-to: Internet-Drafts@optimus.ietf.org Sender: nsyracus@ns.cnri.reston.va.us -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Fibre Channel Management Framework Integration MIB Author(s) : S. Blumenau Filename : draft-blumenau-fcmgmt-int-mib-01.txt Pages : 35 Date : 03-Jun-99 The goal of this document is to fill in missing pieces necessary to enable an enterprise class storage network. One of the more important features of an enterprise class storage network is management; this document gives a framework MIB that will provide an integrated management environment for the enterprise customer. An enterprise class storage network is comprised of elements (i.e., hubs, switches, converters, gateways, and HBAs) that are developed by many different vendors. The large number of vendors that can exist in a storage network makes mangement a very hard and complicated problem. The main goal of this document's MIB is to enable interoperability among the various vendors involved in the Fibre Channel marketplace. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-blumenau-fcmgmt-int-mib-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-blumenau-fcmgmt-int-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-blumenau-fcmgmt-int-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. From owner-ipfc@standards.gadzoox.com Tue Jun 15 13:39:55 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24352 for ; Tue, 15 Jun 1999 13:39:54 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA02203 for ipfc-list; Tue, 15 Jun 1999 10:35:07 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id KAA02200 for ; Tue, 15 Jun 1999 10:35:05 -0700 Received: from emuweb.emulex.com (emuweb.emulex.com [138.239.112.10]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id KAA00944; Tue, 15 Jun 1999 10:14:58 -0700 (PDT) Received: from bobnpc.emulex.com (localhost [127.0.0.1]) by emuweb.emulex.com (8.9.1/8.9.1) with SMTP id KAA25695; Tue, 15 Jun 1999 10:14:56 -0700 (PDT) Received: by bobnpc.emulex.com with Microsoft Mail id <01BEB717.E88DA3C0@bobnpc.emulex.com>; Tue, 15 Jun 1999 10:14:52 -0700 Message-ID: <01BEB717.E88DA3C0@bobnpc.emulex.com> From: "Nixon, Bob" To: "'Infante, Jon'" , "'Jim Allen'" , "ipfc@standards.gadzoox.com" , "'Murali Rajagopal'" Subject: RE: IPv6 extension for FARP Date: Tue, 15 Jun 1999 10:14:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit See also RFC2464 Transmission of IPv6 Packets over Ethernet Networks RFC2467 Transmission of IPv6 Packets over FDDI Networks RFC2470 Transmission of IPv6 Packets over Token Ring Networks These all have status "PROPOSED STANDARD" so they have reached wide acceptance / implementation. ---------- From: Murali Rajagopal Sent: Tuesday, June 15, 1999 9:32 AM To: 'Infante, Jon'; 'Jim Allen'; ipfc@standards.gadzoox.com; Murali Rajagopal Subject: RE: IPv6 extension for FARP Some IPv6 over xxx drafts: http URL:draft-ietf-ip1394-ipv6-00.txt Summary Title: Transmission of IPv6 Packets over IEEE 1394 Networks http URL:draft-yamamoto-ipv6-over-p2p-atm-01.txt Summary Title: IPv6 over Point-to-Point ATM Link Other applicable drafts: http URL:draft-ietf-ngtrans-introduction-to-ipv6-transition-00.txt Summary Title: A Guide to the Introduction of IPv6 in the IPv4 World 16. http URL:draft-ietf-ipngwg-site-prefixes-02.txt Summary Title: Site prefixes in Neighbor Discovery 17. -----Original Message----- From: Infante, Jon [mailto:Jon.Infante@emulex.com] Sent: Tuesday, June 15, 1999 9:23 AM To: 'Jim Allen'; ipfc@standards.gadzoox.com; 'Murali Rajagopal' Subject: RE: IPv6 extension for FARP Are there currently any IPv6 over XXXXX Drafts that we could look at for reference? Jon ---------- From: Murali Rajagopal Sent: Tuesday, June 15, 1999 8:51 AM To: 'Jim Allen'; ipfc@standards.gadzoox.com Subject: RE: IPv6 extension for FARP Folks: A clarification for those who may be wondering how Jim's proposed extension fits with the current draft. The extension is for a completely new draft proposal "IPv6 Over FC" that is yet to be discussed and adopted as a new work item if sufficient interest prevails. I like to hear your comments about adopting this as a new work item. Regards, Murali Rajagopal IPFC WG Chair -----Original Message----- From: Jim Allen [mailto:jpallen@austin.ibm.com] Sent: Monday, June 14, 1999 8:27 PM To: ipfc@standards.gadzoox.com Subject: IPv6 extension for FARP I was wondering if it would be possible to extend the Match Address Code Points defined in section 5.4 and in Appendix A to explicity deal with IPv6 Addresses in FARP. Currently FARP can handle 128 bit IP addresses, but there is now match address code point explicitily for IPv6. At some point Neighbor Discovery on FC will need addressed, but in the interim extending FARP to explicitly handle IPv6 address may be be useful. A possible approach follows. Please send me feedback on this proposal. An alternate approach to what follows is to generalize the existing IPv4 match address code points to be used for either IPv4 or IPv6. Thanks. -------------------- In Section 5.4 (page 20), update the table for "Match Address Code Points" for IPv6. Here is a possible implementation: +------------------------------------------------------------------+ | Match Address Code Points | +------------------------------------------------------------------+ | LSBits | Bit name | Action | +-----------+--------------------+---------------------------------+ | 0000 | Reserved | | +-----------+--------------------+---------------------------------+ | 0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-----------+--------------------+---------------------------------+ | 0010 | MATCH_WW_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0100 | MATCH_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 0111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1000 | MATCH_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1001 | MATCH_WW_PN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1010 | MATCH_WW_NN_IPv6 | OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ | 1011 | MATCH_WW_PN_NN_IPv6| OPTIONAL; see Appendix A | +-----------+--------------------+---------------------------------+ In Appendix A, these changes would also be described. So that it would look something like: Section 5 described the FC Layer mapping between the WW_PN and the Port_ID using the FARP Protocol. This appendix describes other optional criteria for address matching and includes: - WW_NN - WW_PN & WW_NN at the same time - IPv4 - IPv4 & WW_PN at the same time - IPv4 & WW_NN at the same time - IPv4 & WW_PN & WW_NN at the same time - IPv6 - IPv6 & WW_PN at the same time - IPv6 & WW_NN at the same time - IPv6 & WW_PN & WW_NN at the same time Depending on the Match Address Code Points, the FARP protocol fundamentally resolves five main types of addresses to Port_IDs and is described in table below. - For Match Address Code Point b'0001': WW_PN Names fields are used to resolve the WW_PN names to Port_IDs. WW_NN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0010': WW_NN Names fields are used to resolve the WW_NN names to Port_IDs. WW_PN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'0100': IPv4 fields are used to resolve the IPv4 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For Match Address Code Point b'1000': IPv6 fields are used to resolve the IPv6 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder. - For all other Match Address Code Points b'0011', b'0101',b'0110', b'0111' ,b'1001' ,b'1010' ,b'1011, depending on set bits one or more addresses are jointly resolved to a Port_ID. See table below. If fields are not used, then they are set either to '0' or valid addresses. +--------------------------------------------------------------------+ | Match Address Code Points | +--------------------------------------------------------------------+ | LSBits| Bit name | Action | +-------+--------------------+---------------------------------------+ |0000 | Reserved | | +-------+--------------------+---------------------------------------+ |0001 | MATCH_WW_PN | If 'WW_PN of Responder' = | | | | Node's WW_PN then respond | +-------+--------------------+---------------------------------------+ |0010 | MATCH_WW_NN | If 'WW_NN of Responder' = | | | | Node's WW_NN then respond | +-------+--------------------+---------------------------------------+ |0011 | MATCH_WW_PN_NN | If both 'WW_PN of Responder' & | | | | 'WW_NN of Responder' = | | | | Node's WW_PN & WW_NN then respond | +-------+--------------------+---------------------------------------+ |0100 | MATCH_IPv4 | If 'IPv4 Address of Responder' = | | | | Node's IPv4 Address then respond | +-------+--------------------+---------------------------------------+ |0101 | MATCH_WW_PN_IPv4 | If 'WW_PN & IPv4 of Responder' = | | | | Node's WW_PN and IPv4 then respond | +-------+--------------------+---------------------------------------+ |0110 | MATCH_WW_NN_IPv4 | If both 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Node's WW_NN & IPv4 then respond | +-------+--------------------+---------------------------------------+ |0111 |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv4 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv4 | | | | then respond | +-------+--------------------+---------------------------------------+ |1000 | MATCH_IPv6 | If 'IPv6 Address of Responder' = | | | | Node's IPv6 Address then respond | +-------+--------------------+---------------------------------------+ |1001 | MATCH_WW_PN_IPv6 | If 'WW_PN & IPv6 of Responder' = | | | | Node's WW_PN and IPv6 then respond | +-------+--------------------+---------------------------------------+ |1010 | MATCH_WW_NN_IPv6 | If both 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Node's WW_NN & IPv6 then respond | +-------+--------------------+---------------------------------------+ |1011 |MATCH_WW_PN_NN_IPv6 | If 'WW_PN of Responder' & | | | | 'WW_NN of Responder' & | | | | 'IPv6 Address of Responder' = | | | | Nodes' WW_PN & WW_NN & IPv6 | | | | then respond | +-------+--------------------+---------------------------------------+ For the FARP-REQUEST/REPLY command the "IP Add." fields would be updated something like: +-------------------------------+---------+---------------------------+ |IP Add. of Requester | 16 |OPTIONAL; Supplied by | | | |Requester | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ |IP Address of Responder | 16 |OPTIONAL; Supplied by | | | |Requester or Responder | | | |IPv4 Add.=low 32 bits | | | |IPv6 Add.=all 128bits | +-------------------------------+---------+---------------------------+ -- ============================================================================ == Jim Allen IBM RS/6000 Division, AIX Base Device Drivers Austin, TX Internet: jpallen@austin.ibm.com Vnet : Get real! (JPALLEN at AUSTIN) Office : 5G-015/905, ZIP 9551 Phone : (512)-838-3346 T/L: 678-3346 FAX : (512)-838-3509 T/L: 678-3509 ============================================================================ == From owner-ipfc@standards.gadzoox.com Tue Jun 15 13:58:28 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24876 for ; Tue, 15 Jun 1999 13:58:27 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA02211 for ipfc-list; Tue, 15 Jun 1999 10:53:55 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id KAA02208 for ; Tue, 15 Jun 1999 10:53:53 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Jun 1999 10:58:49 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A116FCD@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: 45th IETF: AGENDA Date: Tue, 15 Jun 1999 10:58:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Draft Agenda of the Forty-fifth IETF July 12-16, 1999 As of June 4, 1999 SUNDAY, July 11, 1999 1200-1900 Registration (Pre-paid Packet Pick-up) - Ballroom Foyer 1500-1900 Registration (Pre-registered and On-site) - Ballroom Foyer 1530-1630 Newcomer's Orientation - Olympia Room 1700-1900 Welcome Reception - Sonia Henie Ballroom MONDAY, July 12, 1999 0730-1930 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions APP appsarea Applications Open Area Meeting INT dhc Dynamnic Host Configuration WG RTG mpls Multiprotocol label Switching WG SEC cat Common Authentication Technology WG TSV rap RSVP Admission Policy WG 1130-1300 Break 1300-1500 Afternoon Sessions I OPS ngtrans Next Generation Transition WG RTG mpls Multiprotocol label Switching WG SEC xmldsig XML Digital Signatures WG TSV nfsv4 Network File System Version 4 WG USV uswg User Services WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer 1530-1730 Afternoon Sessions II APP calsch Calendaring and Scheduling WG INT dnsind DNS IXFR, Notification, and Dynamic Update WG INT ipcdn IP over Cable Data Network WG OPS adslmib ADSL MIB WG RTG msdp Multicast Source Discovery Protocol WG TSV diffserv Differentiated Services WG 1730-1930 Break 1930-2200 Evening Sessions GEN policy Policy Framework WG INT dhc Dynamnic Host Configuration WG RTG udlr UniDirectional Link Routing WG TUESDAY, July 13, 1999 0800-1700 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions I APP fax Internet Fax WG OPS ngtrans Next Generation Transition WG RTG pim Protocol Independent Multicast WG SEC xmldsig XML Digital Signatures WG TSV rsvp Resource Rservation Setup Protocol WG 1300-1400 Afternoon Sessions I OPS rps Routing Policy System WG RTG vrrp Virtual Router Redendancy Protocol WG SEC ipsec IP Security Protocol WG 1415-1515 Afternoon Sessions II INT netwklr Network Layer BOF OPS rps Routing Policy System WG SEC ipsec IP Security Protocol WG 1515-1545 Break (Refreshments provided) - Ballroom Foyer 1545-1645 Afternoon Sessions III GEN policy Policy Framework WG RTG idmr Inter-Domain Multicast Routing WG SEC otp One Time Password Authentication WG TSV nat Network Address Translators WG 1700-1800 Afternoon Sessions IV APP calsch Calendaring and Scheduling WG GEN policy Policy Framework WG INT frnetmib Frame Relay Service MIB WG TSV nat Network Address Translators WG WEDNESDAY, July 14, 1999 0800-1700 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions INT ipngwg IPNG WG GEN poisson Process for Organization of Internet Standards WG OPS disman Distributed Management WG RTG manet Mobile Ad-hoc Networks WG SEC pkix Public-Key Infrastructure (X.509) WG TSV avt Audio/Visual Transport WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP trade Internet Open Trading Protocol WG INT ipfc IP Over Fibre Channel WG OPS mboned MBONE Deployment WG RTG manet Mobile Ad-hoc Networks WG SEC pkix Public-Key Infrastructure (X.509) WG TSV sigtran Signaling Transport WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer 1530-1730 Afternoon Sessions II APP deltav Web Versioning and Configuration Management WG INT pppext Point-to-Point Protocol Extensions WG OPS rmonmib Remote Network Monitoring WG RTG rtgarea Routing Open Area Meeting TSV decides Deployment Considerations of Implementing Differentiated BOF 1730-1930 Break 1930-2200 Open Plenary - Sonia Henie Ballroom o Welcome - Fred Baker, IETF Chair o Dr. Houlin Zhou, General Secretary of the ITU o IAB Plenary o IESG Plenary o ICANN/PSO MoU Discussion 2230 Late Night Session PGP Key Signing THURSDAY, July 15, 1999 0800-1700 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions APP webdav WWW Distributed Authoring and Versioning WG OPS opsarea Operations & Management Open Area Meeting SEC idwg Intrusion Detection Exchange Format WG TSV megaco Media Gateway Control WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP ldapext LDAP Extension WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC saag Open Security Area Directorate Meeting TSV iptel IP Telephony WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer 1530-1730 Afternoon Sessions II OPS bmwg Benchmarking Methodology WG RTG gsmp General Switch Management Protocol WG SEC smime S/MIME Mail Security WG TSV avt Audio/Visual Transport WG 1730-1930 Break 1930-2200 Evening Sessions APP impp Instant Messaging and Presence Protocol WG OPS dnsop Domain Name Server Operations WG RTG gsmp General Switch Management Protocol WG TSV malloc Multicast-Address Allocation WG FRIDAY, July 16, 1999 0800-1000 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions APP ldup LDAP Duplication/Replication/Update Protocols WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC idwg Intrusion Detection Exchange Format WG TSV sigtran Signaling Transport WG ======================================================================= Area Directors APP Applications Keith Moore/UTK and Patrik Faltstrom/Tele2/Swipnet GEN General Interest Fred Baker/Cisco Systems INT Internet Thomas Narten/IBM Corporation and Erik Nordmark/Sun Microsystems OPS Operations & Management Randy Bush/Verio, Inc. and Bert Wijnen/IBM Netherlands RTG Routing Rob Coltun/Lightera Networks and Dave Oran/Cisco Systems SEC Security Marcus Leech/Nortel and Jeff Schiller/MIT TSV Transport Scott Bradner/Harvard Univ. and Vern Paxson/ACIRI/LBNL USV User Services April Marine/Internet Engines, Inc. From owner-ipfc@standards.gadzoox.com Tue Jun 15 13:58:35 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24887 for ; Tue, 15 Jun 1999 13:58:34 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA02216 for ipfc-list; Tue, 15 Jun 1999 10:54:09 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id KAA02213 for ; Tue, 15 Jun 1999 10:54:09 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Jun 1999 10:59:04 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A116FCE@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: 45th IETF-OSLO, NORWAY: REGISTRATION ANNOUNCEMENT Date: Tue, 15 Jun 1999 10:58:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk On-line Registration & On-line Payment Procedure Now Available To register for the upcoming IETF meeting, please fill out the On-line Registration form and click on the Submit button. Following receipt at the server, your browser will display your registration ID, total amount due and payment options. At this point, you may choose the New On-line Payment Option using CyberCash, available directly from your browser on your registration confirmation page. We accept VISA, MasterCard and American Express. Note: Diners Club is no longer accepted. An e-mail message will also be sent to you confirming your registration information and listing other payment options - 1) reply e-mail using PGP, 2) print & fax, 3) print & snail-mail. You may choose whichever option is most convenient for you. Please contact IETF Registrar if you have any questions concerning registration, payments, etc.: ietf-registrar@ietf.org The registration fee is US$375.00 if RECEIVED by the cut-off of Noon ET, MONDAY, 28 JUNE 1999. After this date/time, a fee of US$475.00 must be paid on-site whether or not you have pre-registered. Full-time students with proper ID will receive US$100 off the registration fee. Failure to provide proper ID on-site will revoke the US$100 credit. CD-ROM (US$10) and Hard Copy (US$65) versions of the meeting Proceedings will be available approximately 8-10 weeks following the meeting. If you would like to receive either or both, check YES in the respective boxes on the registration form. The appropriate amount will be added to the total amount due. Your registration fee includes admission to all working group sessions and plenaries, Sunday evening reception (cash bar), and afternoon coffee breaks each day. CANCELLATION/REFUND POLICY: Refunds are subject to a US$50.00 service charge. Cancellations and requests for refunds must be received by 1700ET, Thursday, 1 July 1999. Refund requests will not be honored beyond this point. To cancel and request a refund, contact the IETF Registrar: ietf-registrar@ietf.org If you are unable to access our Home Page on the Web, you will find the same registration form in the ftp/ietf directory (ftp.ietf.org) . The name of the file is: 0mtg-rsvp-form.txt. If you are also unable to access the registration form via ftp, please send e-mail To: mailserv@ietf.org and in the body of the message request FILE /ietf/0mtg-rsvp-form.txt PATH your-email-address@domain The registration form will come to you via e-mail. You can view the Oslo, Norway Meeting home page at: http://www.ietf.org/meetings/IETF-45.html The URL for the on-line registration form is: http://www.ietf.org/meetings/reg_form.html ---------------------------------------------------------------------------- Please report problems or send comments to ietf-web@ietf.org . From owner-ipfc@standards.gadzoox.com Tue Jun 15 14:01:05 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25099 for ; Tue, 15 Jun 1999 14:01:04 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA02226 for ipfc-list; Tue, 15 Jun 1999 10:56:39 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id KAA02223 for ; Tue, 15 Jun 1999 10:56:39 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Jun 1999 11:01:34 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A116FCF@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Cc: Gavin Bowlby , "Lee Hu (E-mail)" Subject: Internet-Draft Cut-off Date for Oslo IETF Date: Tue, 15 Jun 1999 10:59:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk The cut-off for Internet-Draft submissions prior to the Oslo IETF meeting is Friday, June 25, 1999 at 5pm ET. Internet-Drafts received after this time will not be announced nor made available in the Internet-drafts Directories. We will begin processing Internet-Draft submissions the week following the IETF meeting. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concerns. From owner-ipfc@standards.gadzoox.com Tue Jun 15 14:57:04 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26633 for ; Tue, 15 Jun 1999 14:57:02 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id LAA02316 for ipfc-list; Tue, 15 Jun 1999 11:50:54 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id LAA02313 for ; Tue, 15 Jun 1999 11:50:54 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Jun 1999 11:55:49 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A116FD2@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: New Draft Announcement Date: Tue, 15 Jun 1999 11:55:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk ---------------------------------------------------------------------------- ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Fibre Channel Management Framework Integration MIB Author(s) : S. Blumenau Filename : draft-blumenau-fcmgmt-int-mib-01.txt Pages : 35 Date : 03-Jun-99 The goal of this document is to fill in missing pieces necessary to enable an enterprise class storage network. One of the more important features of an enterprise class storage network is management; this document gives a framework MIB that will provide an integrated management environment for the enterprise customer. An enterprise class storage network is comprised of elements (i.e., hubs, switches, converters, gateways, and HBAs) that are developed by many different vendors. The large number of vendors that can exist in a storage network makes mangement a very hard and complicated problem. The main goal of this document's MIB is to enable interoperability among the various vendors involved in the Fibre Channel marketplace. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-blumenau-fcmgmt-int-mib-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-blumenau-fcmgmt-int-mib-01.txt". From owner-ipfc@standards.gadzoox.com Tue Jun 15 19:17:27 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03012 for ; Tue, 15 Jun 1999 19:17:26 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id QAA02415 for ipfc-list; Tue, 15 Jun 1999 16:12:58 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from ntmail.qlc.com (ntmail.qlc.com [192.215.217.150]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id QAA02412 for ; Tue, 15 Jun 1999 16:12:58 -0700 Received: by ntmail.qlc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Jun 1999 16:13:23 -0700 Message-ID: From: Jeff Stai To: "'Murali Rajagopal'" , "'Jim Allen'" , ipfc@standards.gadzoox.com Cc: Shishir Shah Subject: RE: IPv6 extension for FARP Date: Tue, 15 Jun 1999 16:13:23 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk > -----Original Message----- > From: Murali Rajagopal [mailto:murali@gadzoox.com] ... > > Folks: > > A clarification for those who may be wondering how Jim's > proposed extension > fits with the current draft. > > The extension is for a completely new draft proposal "IPv6 > Over FC" that is > yet to be discussed and adopted > as a new work item if sufficient interest prevails. > > I like to hear your comments about adopting this as a new work item. > hi - Without commenting on the specifics of the proposal, it seems obvious that an agreement on how to do IPv6 over FC can only be in everyone's best interest. Also, note that in the case of FARP, if we act quickly we can get the IPv6 extensions for FARP-REQ and FARP-REPLY into the FC-FS draft. (Note that T11.3 is not constrained to wait for IPv6 to be approved prior to approving FC-FS.) This would also seem like a Good Thing. thanks! - jeff stai (T11.3 chair) jeff stai, QLogic corp. 3545 harbor blvd, costa mesa, ca 92626 714-668-5425vm, 714-668-5095fx j_stai@qlc.com http://www.qlc.com/ From owner-ipfc@standards.gadzoox.com Wed Jun 16 18:56:57 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03579 for ; Wed, 16 Jun 1999 18:56:56 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id PAA02869 for ipfc-list; Wed, 16 Jun 1999 15:52:05 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gw.vixel.com (gw.vixel.com [207.115.190.195]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id PAA02866 for ; Wed, 16 Jun 1999 15:52:03 -0700 Message-ID: <37682B7F.BC7F1C1E@vixel.com> Date: Wed, 16 Jun 1999 15:55:59 -0700 From: "Lee Hu" X-Mailer: 11911 NorthCreek Parkway South - Bothell - WA - 98011 X-Accept-Language: en MIME-Version: 1.0 To: Murali Rajagopal CC: "'ipfc@standards.gadzoox.com'" , Gavin Bowlby , lhu@vixel.com Subject: Re: Internet-Draft Cut-off Date for Oslo IETF References: <312419998E3CD211A52900A0C991A47A116FCF@gordan.pl.gadzoox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit I'm working on it right now. I'll have the draft version in a couple of days. I'd like Gavin to be available next week for discussion/ modifications. Lee Murali Rajagopal wrote: > The cut-off for Internet-Draft submissions prior to the Oslo IETF > meeting is Friday, June 25, 1999 at 5pm ET. Internet-Drafts received > after this time will not be announced nor made available in the > Internet-drafts Directories. > > We will begin processing Internet-Draft submissions the week > following the IETF meeting. > > Thank you for your understanding and cooperation. Please do not > hesitate to contact us if you have any questions or concerns. From owner-ipfc@standards.gadzoox.com Fri Jun 18 19:07:15 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02306 for ; Fri, 18 Jun 1999 19:07:14 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id QAA03728 for ipfc-list; Fri, 18 Jun 1999 16:01:17 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id QAA03725 for ; Fri, 18 Jun 1999 16:01:16 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Jun 1999 16:06:13 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A116FF6@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: FW: 45th IETF: SOCIAL EVENT Date: Fri, 18 Jun 1999 16:05:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk -----Original Message----- From: Ingrid Melve [mailto:Ingrid.Melve@uninett.no] Sent: Friday, June 18, 1999 5:41 AM Subject: 45th IETF: SOCIAL EVENT Ericsson Summer Party Tuesday July 13th, from 6.00 p.m. in Oslo: Party, food, drink, friends A short boat trip will show you Oslo from the seaside and bring you to the Norwegian Maritime Museum, where the Ericsson Summer Party will take place. The museum is beautifully situated directly on the waterfront where you will see rich collections related to all aspects of shipping. You can also see a breathtaking film about the Norwegian fjords in a wide-screen cinema. In these maritime surroundings we will provide various buffets and beverages for you to choose from. Norwegian musicians will entertain you with different types of music. The Ericsson Summer Party will be a perfect opportunity to meet new and old friends. During the evening you are also welcome to visit two other museums situated in the area of the Ericsson Summer Party. In the Kon-Tiki Museum you can see Thor Heyerdahl's original balsa wood raft. The Fram Museum is on board the vessel Fram, which has advanced further north and further south than any other surface vessel. Registration http://www.uninett.no/ietf45/social/ From owner-ipfc@standards.gadzoox.com Thu Jun 24 17:59:14 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23444 for ; Thu, 24 Jun 1999 17:59:12 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id OAA06424 for ipfc-list; Thu, 24 Jun 1999 14:53:40 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id OAA06421 for ; Thu, 24 Jun 1999 14:53:39 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 24 Jun 1999 14:58:36 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A117030@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: FW: 45th IETF: PRE-REGISTRATION CLOSES JUNE 28 Date: Thu, 24 Jun 1999 14:58:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk -----Original Message----- From: ietf-registrar@ietf.org [mailto:ietf-registrar@ietf.org] Sent: Thursday, June 24, 1999 2:24 PM Subject: 45th IETF: PRE-REGISTRATION CLOSES JUNE 28 REMINDER: Pre-registration for the 45th IETF in Oslo, Norway closes at 12:00 Noon ET on Monday, June 28, 1999. After June 28, you will have to register on-site at the Oslo Radisson Plaza. ====================================================================== On-line Registration & On-line Payment Procedure To register for the upcoming IETF meeting, please fill out the On-line Registration form and click on the Submit button. Following receipt at the server, your browser will display your registration ID, total amount due and payment options. At this point, you may choose the New On-line Payment Option using CyberCash, available directly from your browser on your registration confirmation page. We accept VISA, MasterCard and American Express. Note: Diners Club is no longer accepted. An e-mail message will also be sent to you confirming your registration information and listing other payment options - 1) reply e-mail using PGP, 2) print & fax, 3) print & snail-mail. You may choose whichever option is most convenient for you. Please contact IETF Registrar if you have any questions concerning registration, payments, etc.: ietf-registrar@ietf.org The registration fee is US$375.00 if RECEIVED by the cut-off of Noon ET, MONDAY, 28 JUNE 1999. After this date/time, a fee of US$475.00 must be paid on-site whether or not you have pre-registered. Full-time students with proper ID will receive US$100 off the registration fee. Failure to provide proper ID on-site will revoke the US$100 credit. CD-ROM (US$10) and Hard Copy (US$65) versions of the meeting Proceedings will be available approximately 8-10 weeks following the meeting. If you would like to receive either or both, check YES in the respective boxes on the registration form. The appropriate amount will be added to the total amount due. Your registration fee includes admission to all working group sessions and plenaries, Sunday evening reception (cash bar), and afternoon coffee breaks each day. CANCELLATION/REFUND POLICY: Refunds are subject to a US$50.00 service charge. Cancellations and requests for refunds must be received by 1700ET, Thursday, 1 July 1999. Refund requests will not be honored beyond this point. To cancel and request a refund, contact the IETF Registrar: ietf-registrar@ietf.org If you are unable to access our Home Page on the Web, you will find the same registration form in the ftp/ietf directory (ftp.ietf.org) . The name of the file is: 0mtg-rsvp-form.txt. If you are also unable to access the registration form via ftp, please send e-mail To: mailserv@ietf.org and in the body of the message request FILE /ietf/0mtg-rsvp-form.txt PATH your-email-address@domain The registration form will come to you via e-mail. You can view the Oslo, Norway Meeting home page at: http://www.ietf.org/meetings/IETF-45.html The URL for the on-line registration form is: http://www.ietf.org/meetings/reg_form.html ---------------------------------------------------------------------------- Please report problems or send comments to ietf-web@ietf.org . From owner-ipfc@standards.gadzoox.com Thu Jun 24 18:12:24 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23679 for ; Thu, 24 Jun 1999 18:12:22 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id PAA06438 for ipfc-list; Thu, 24 Jun 1999 15:07:29 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id PAA06435 for ; Thu, 24 Jun 1999 15:07:28 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 24 Jun 1999 15:12:26 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A117031@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: FW: 45th IETF: FINAL AGENDA Date: Thu, 24 Jun 1999 15:12:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk -----Original Message----- From: agenda@ietf.org [mailto:agenda@ietf.org] Sent: Thursday, June 24, 1999 2:32 PM Subject: 45th IETF: FINAL AGENDA PLEASE NOTE: Meeting rooms are located in both the Oslo Radisson Plaza and the Oslo Spektrum. These two buildings are connected by a walk-way on the meeting room level of both buildings. Spektrum 1 and Spektrum 3 meeting rooms are located in the Oslo Spektrum with all other meeting rooms, as well the terminal room, located in the Oslo Radisson Plaza. ======================================================================= Agenda of the Forty-fifth IETF July 11-16, 1999 SUNDAY, July 11, 1999 1200-1900 Registration (Pre-paid Packet Pick-up) - Ballroom Foyer 1500-1900 Registration (Pre-registered and On-site) - Ballroom Foyer 1530-1600 Newcomer's Orientation - Olympia Room 1600-1630 IETF Standards Process Orientation - Olympia Room 1700-1900 Welcome Reception - Sonia Henie Ballroom MONDAY, July 12, 1999 0800-1930 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions Kunst APP appsarea Applications Open Area Meeting Room 301 INT dhc Dynamic Host Configuration WG Olympia RTG mpls Multiprotocol Label Switching WG * Munch SEC cat Common Authentication Technology WG Film TSV rap RSVP Admission Policy WG * 1130-1300 Break 1300-1500 Afternoon Sessions I Spektrum 1 APP cnrp Common Name Resolution Protocol BOF Room 301 APP wrec Web Replication and Caching WG Kunst OPS ngtrans Next Generation Transition WG Olympia RTG mpls Multiprotocol Label Switching WG * Munch SEC xmldsig XML Digital Signatures WG Film TSV cm Congestion Management BOF * Spektrum 3 USV uswg User Services WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer 1530-1730 Afternoon Sessions II Spektrum 1 APP calsch Calendaring and Scheduling WG Kunst INT dnsind DNS IXFR, Notification, and Dynamic Update WG Munch INT ipcdn IP over Cable Data Network WG Spektrum 3 OPS adslmib ADSL MIB WG Film RTG msdp Multicast Source Discovery Protocol WG * Olympia TSV diffserv Differentiated Services WG * Room 301 TSV nfsv4 Network File System Version 4 WG 1730-1930 Break 1930-2200 Evening Sessions Munch APP vpim Voice Profile for Internet Mail BOF Olympia GEN policy Policy Framework WG * Room 301 INT dhc Dynamic Host Configuration WG Kunst RTG isis IS-IS for IP Internets WG Film TSV pilc Performance Implications of Link Characteristics WG * * Designates Multicast Sessions TUESDAY, July 13, 1999 0800-1700 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions I Room 301 APP fax Internet Fax WG Kunst OPS ngtrans Next Generation Transition WG Film RTG pim Protocol Independent Multicast WG * Spektrum 1 SEC stime Secure Network Time Protocol WG Munch SEC xmldsig XML Digital Signatures WG Olympia TSV rsvp Resource Reservation Setup Protocol WG * 1130-1300 Break 1300-1400 Afternoon Sessions I Spektrum 3 APP conneg Content Negotiation WG Munch OPS rps Routing Policy System WG Spektrum 1 OPS snmpv3 SNMP Version 3 WG Kunst RTG maestro Multicast Addressing Extensions and Single Transmitter Optimizations BOF Room 301 RTG vrrp Virtual Router Redundancy Protocol WG Olympia SEC ipsec IP Security Protocol WG * Film TSV mmusic Multiparty Multimedia Session Control WG * 1415-1515 Afternoon Sessions II Spektrum 3 APP conneg Content Negotiation WG Kunst INT netwklr Network Layer BOF Munch OPS rps Routing Policy System WG Spektrum 1 OPS snmpv3 SNMP Version 3 WG Olympia SEC ipsec IP Security Protocol WG * Room 301 TSV ippm IP Performance Metrics WG Film TSV mmusic Multiparty Multimedia Session Control WG * 1515-1545 Break (Refreshments provided) - Ballroom Foyer 1545-1645 Afternoon Sessions III Olympia GEN policy Policy Framework WG * Kunst INT nits Networks in the Small (Home Networks) BOF Film RTG idmr Inter-Domain Multicast Routing WG * Spektrum 1 SEC aft Authenticated Firewall Traversal WG Room 301 SEC otp One Time Password Authentication WG Film TSV nat Network Address Translators WG 1700-1800 Afternoon Sessions IV Room 301 APP calsch Calendaring and Scheduling WG Olympia GEN policy Policy Framework WG * Spektrum 3 INT frnetmib Frame Relay Service MIB WG Kunst INT nits Networks in the Small (Home Networks) BOF Film RTG bgmp Border Gateway Multicast Protocol BOF * Spektrum 1 SEC aft Authenticated Firewall Traversal WG Munch TSV nat Network Address Translators WG * Designates Multicast Sessions WEDNESDAY, July 14, 1999 0800-1700 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions Spektrum 3 APP ipp Internet Printing Protocol WG Olympia INT ipngwg IPNG WG * Spektrum 1 GEN poisson Process for Organization of Internet Standards WG Room 301 OPS disman Distributed Management WG Munch RTG manet Mobile Ad-hoc Networks WG Kunst SEC pkix Public-Key Infrastructure (X.509) WG Film TSV avt Audio/Visual Transport WG * 1130-1300 Break 1300-1500 Afternoon Sessions I Room 301 APP trade Internet Open Trading Protocol WG Spektrum 3 INT ipfc IP Over Fibre Channel WG Olympia OPS mboned MBONE Deployment WG * Munch RTG manet Mobile Ad-hoc Networks WG Kunst SEC pkix Public-Key Infrastructure (X.509) WG Film TSV sigtran Signaling Transport WG * Spektrum 1 USV weird Web Elucidation of Internet-Related Developments WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer 1530-1730 Afternoon Sessions II Room 301 APP deltav Web Versioning and Configuration Management BOF Olympia GEN aaa Authentication, Authorization and Accounting WG * Munch INT pppext Point-to-Point Protocol Extensions WG Spektrum 3 OPS rmonmib Remote Network Monitoring WG Spektrum 1 RTG udlr UniDirectional Link Routing WG Kunst SEC ipsp IP Security Policy BOF Film TSV decides Deployment Considerations of Implementing Differentiated Problem Statement BOF * 1730-1930 Break 1930-2200 Open Plenary - Sonia Henie Ballroom o Welcome - Fred Baker, IETF Chair o Harald Alvestrand, Maxware o Dr. Houlin Zhao, Director, Telecommunication Standardization Bureau, ITU-T o IAB Plenary o IESG Plenary o ICANN/PSO MoU Discussion 2230 Late Night Session Munch PGP Key Signing * Designates Multicast Sessions THURSDAY, July 15, 1999 0800-1700 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions Room 301 APP webdav WWW Distributed Authoring and Versioning WG Munch OPS lsd2 LDAP Service Deployment - Take 2 BOF Kunst RTG idr Inter-Domain Routing WG Spektrum 1 SEC idwg Intrusion Detection Exchange Format WG Olympia TSV megaco Media Gateway Control WG * Film TSV rmt Reliable Multicast Transport WG * 1130-1300 Break 1300-1500 Afternoon Sessions I Spektrum 3 APP imapext Internet Message Access Protocol Extension BOF Munch APP ldapext LDAP Extension WG Room 301 OPS roamops Roaming Operations WG Film RTG mobileip IP Routing for Wireless/Mobile Hosts WG * Kunst SEC saag Open Security Area Directorate Meeting Olympia TSV iptel IP Telephony WG * Spektrum 1 TSV issll Integrated Services over Specific Link Layers WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer 1530-1730 Afternoon Sessions II Olympia INT ipngwg IPNG WG * Spektrum 3 OPS bmwg Benchmarking Methodology WG Spektrum 1 OPS nasreq Network Access Server Requirements WG Room 301 RTG gsmp General Switch Management Protocol WG Munch SEC smime S/MIME Mail Security WG Film TSV avt Audio/Visual Transport WG * Kunst TSV pin PSTN Internet Notification BOF 1730-1930 Break 1930-2200 Evening Sessions Munch APP impp Instant Messaging and Presence Protocol WG Kunst OPS dnsop Domain Name Server Operations WG Room 301 RTG gsmp General Switch Management Protocol WG Film Appeal to IAB by W. A. Simpson * Olympia TSV malloc Multicast-Address Allocation WG * * Designates Multicast Sessions FRIDAY, July 16, 1999 0800-1000 IETF Registration - Ballroom Foyer 0900-1130 Morning Sessions Munch APP ldup LDAP Duplication/Replication/Update Protocols WG Olympia GEN aaa Authentication, Authorization and Accounting WG * Spektrum 1 OPS te Internet Traffic Engineering BOF Film RTG mobileip IP Routing for Wireless/Mobile Hosts WG * Room 301 SEC idwg Intrusion Detection Exchange Format WG Kunst TSV sigtran Signaling Transport WG * Designates Multicast Sessions ======================================================================= Area Directors APP Applications Keith Moore/UTK and Patrik Faltstrom/Tele2/Swipnet GEN General Interest Fred Baker/Cisco Systems INT Internet Thomas Narten/IBM Corporation and Erik Nordmark/Sun Microsystems OPS Operations & Management Randy Bush/Verio, Inc. and Bert Wijnen/IBM Netherlands RTG Routing Rob Coltun/Lightera Networks and Dave Oran/Cisco Systems SEC Security Marcus Leech/Nortel and Jeff Schiller/MIT TSV Transport Scott Bradner/Harvard Univ. and Vern Paxson/ACIRI/LBNL USV User Services April Marine/Internet Engines, Inc. From owner-ipfc@standards.gadzoox.com Thu Jun 24 23:16:16 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29446 for ; Thu, 24 Jun 1999 23:16:15 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id UAA06505 for ipfc-list; Thu, 24 Jun 1999 20:11:43 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id UAA06502 for ; Thu, 24 Jun 1999 20:11:42 -0700 Received: from fishbowl02.emc.com (fishbowl02 [168.159.48.62]) by emcmail.lss.emc.com (8.9.3/8.9.3) with SMTP id XAA26446 for ; Thu, 24 Jun 1999 23:14:39 -0400 (EDT) Received: by fishbowl02.emc.com with VINES-ISMTP; Thu, 24 Jun 1999 23:14:41 -0400 Date: Thu, 24 Jun 1999 23:14:40 -0400 Message-ID: X-Priority: 3 (Normal) To: From: "steven blumenau" Reply-To: Subject: implementation progress/proofs on fibre channel management MIB X-Incognito-SN: 1467 X-Incognito-Version: 5.0.1.89 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk The following companies either have implemented the first version and/or are commited to implementing follow on versions. These have helped greatly in proving the the "correctness" of the MIB as defined. Ancor Communications ATTO Technology EMC Corp Emulex Corp Hewlett-Packard Co., OpenView Business Unit Gadzoox Networks, Inc McDATA corp Vixel Corp The product areas that these cover are: hub, switch, hba, storage, management software and SCSI bridges Steven Blumenau EMC Corp From owner-ipfc@standards.gadzoox.com Fri Jun 25 04:57:09 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18540 for ; Fri, 25 Jun 1999 04:57:05 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id BAA06763 for ipfc-list; Fri, 25 Jun 1999 01:52:31 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from Brocade.COM (asbestos.brocade.com [12.7.224.244]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id BAA06760 for ; Fri, 25 Jun 1999 01:52:29 -0700 Received: from brocade.com (isdn-khasin-6 [192.168.8.110]) by Brocade.COM (8.8.8+Sun/8.8.8) with ESMTP id XAA12891; Thu, 24 Jun 1999 23:51:07 -0700 (PDT) Message-ID: <377326DA.499C58CD@brocade.com> Date: Thu, 24 Jun 1999 23:51:07 -0700 From: Kha Sin Teow Organization: Brocade Communications Systems Inc. X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Juergen Schoenwaelder CC: murali@gadzoox.com, narten@raleigh.ibm.com, nordmark@eng.sun.com, randy@psg.com, WIJNEN@vnet.ibm.com, ipfc@standards.gadzoox.com Subject: Re: IESG quality review for draft-ietf-ipfc-fabric-element-mib-04 References: <199905142129.XAA22430@mumm.ibr.cs.tu-bs.de> <199906111509.RAA29749@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > >>>>> Bert Wijnen writes: > > Bert> Juergen, thans for your commitment to do a quality review of > Bert> this MIB within the next couple of weeks. Pls send your > Bert> comments to the author and cc: the WG chair and ADs as listed > Bert> above. > > Below is my review for . > Some points repeat several times - that is why the list looks quite > long. Some of the comments listed here have already been raised by > Bert Wijnen - you probably have already adressed them. Feel free to > contact me if you have any questions. Hi Mr. Schoenwaelder, Thanks for your review and comments. I revised the document and will submit a new draft tomorrow. As the editor of the document, I took the liberty to incorporate what I consider trivial editorial changes (no major technical change). There are other suggestions that I agree in principle, but does not have time to completely incorporate them due to time constraint. I will tag my response to those comments with "R1". There are some that I thought may affect implementations and therefore I would like to get the WG to discuss them before I change them. I will tag my response to those specific comments with "R2". > 1) I am confused by the statement "version 2" since this is going to > be published as Proposed Standard (see Bert's comment). It's deleted. > 2) You should use the MIB boilerplate available from www.ops.ietf.org. done. > 3) There is a reference to [12] in section 3 which does not exist in > the references section. corrected. > 4) Section 3.1 starts "> From" - the "> " got probably inserted by a > mail system. yes. > 5) We have learned that it is useful to carefully check that limits > (e.g. range or size restrictions) defined in MIB modules have good > architectural reason. Note that you can't change any limits once > the MIB has been published. First example: Is there an > architectural reason for restricting fcFeModuleCapacity to 256 > (see section 3.1)? agree. This particular limit is removed. > 6) Section 3.1 says that "modules may come and go without causing a > management reset." Please make sure that all counter objects > related to a module clearly indicate the discontinuity indicator > in the DESCRIPTION clause. agree. > 7) Is there an architectural reason to limit fcFeModuleFxPortCapacity > to 256 (section 3.1)? no - the limit is removed. > 8) Is there an architectural reason to limit NxPort to 126 (section > 3.1)? yes - this is defined in FC-AL. > 9) I suggest to remove "(manager, agent, or proxy agent)" from the > first sentence in section 3.2. done. > 10) I have some question wrt. the figure at the end of section > 3.1. What is [i], [n] and [L]? corrected with additional explanation. > 11) Section 4.1 says that sysServices will have an integer value "2" > or higher. I do not really like this description. Perhaps it is > sufficient to say that Fibre Channel is a datalink layer protocol > (layer 2). > 12) In section 4.2 you refer to the "interface group". I think you > should instead refer to the IF-MIB and add a reference. The latest > version is defined in RFC 2233. > > 13) I think section 4.3 can be removed. If you want to keep this > statement, you should refer to RFC 1907 instead of the "system > group". > > 14) You should also change the title of section 4. This section > describes the relationship to other relevant MIBs. (I generally > prefer to avoid the term MIB-II since this is ambiguous. RFC 1213 > has been split in many smaller modules and its just a matter of > time until it will go to historic.) I removed this section to avoid confusions. > 15) The OID value for the MODULE-IDENTITY macro is invalid. I assumed that the value will be assigned as part of the IESG approval process.Does the IPFC WG need to apply for this assigned value separately from IANA? > 16) You should turn all ASN.1 type definitions into SMIv2 > TEXTUAL-CONVENTIONS. done. > 17) Should FabricName not be named FcFabricName? Shoud FcNameId be > renamed to FcName? Note that it is not allowed in SMIv2 to derive > new TEXTUAL-CONVENTIONS from existing TEXTUAL-CONVENTIONS. collapsed all into FcNameId. > 18) What about IPv6 addresses and FcNameId? Unfortunately, the definition of FC World_wide name does not include IPv6.It's an issue that is outside the scope of this document. > 19) Is there an architectural reason for restricting FcAddressId to > 24 bits? > 20) Is there an architectural reason for the range of FcRxDataFieldSize? > > 21) Is there an architectural reason for the range of FcBbCredit? > > 22) Is there an architectural reason for the range of FcphVersion? > Should this type be named FcPhVersion for consistency? yes - these are defined in FC-PH. > 23) Is BITS not a more appropriate type for FcCosCap? This is an R2. > 24) Is there an architectural reason for the range of > FcFeModuleCapacity and FcFeFxPortCapacity? No - the limits have been removed. > 25) Is there an architectural reason for the range of FcFeModuleIndex, > FcFeFxPortIndex and FcFeNxPortIndex? No for FcFeModuleIndex and FcFeFxPortIndex;yes for FcFeNxPortIndex (see response to Comment 8). > 26) The comment above fcFabricName defines compliance > requirements. You should put these into formal compliance > definitions. (Comments should in general not carry any important > information in MIB modules.) This is an R1 - I will incorporate a Conformance Statement in the next rev. > 27) Index elements must generally be not-accessible. agree - corrected. > 28) fcFeModuleDescr is of type DisplayString. Note that this implies > that it contains printable ASCII characters (which means that this > statement in the DESCRIPTION clause is not needed). In order to > facilitate internationalization, you should seriously consider to > use SnmpAdminString instead of DisplayString. This is an R2. > 29) I am wondering whether the type for fcFeModuleLastChange should be > TimeStamp rather than TimeTicks. This is an R2. > 30) What about changing fcFxConfTable to fcFxPortTable? I think using > the fcFxPort prefix consistently in this table helps to understand > the structure of the MIB. This is an R2. > 31) There is text in several places about obsoleted variables. I > suggest to remove this text since this MIB is just going to enter > the standards track (and hence there should not be any obsolete > objects). All except fcFPortFlogiTable and FcFxPortOperTable have been removed.I believe fcFPortFlogiTable and FcFxPortOperTable are an R2. > 32) What about adding UNITS clauses to fcFxPortRxBufSize, > fcFxPortRatov, fcFxPortEdtov and fcFxPortHoldTime? This is an R1. > 33) The comment above the fcFxPortOperTable defines conformance > requirements. This should be moved into appropriate compliance > definitions. This is an R1. > 34) fcFxPortOperTable should augment fcFxPortTable if there will > always be exactly one entry in the fcFxPortOperTable for each > entry in the fcFxPortTable. Otherwise, you should at least reuse > the index components from the fcFxPortTable rather than defining > similar obejct types for the fcFxPortOperTable. This is an R2. > 35) All columns in a conceptual table should have the same prefix in > their names. (This may lead to longer names than you have now. But > it helps to understand the MIB structure.) This is an R1. > 36) The registration of the columns in fcFxPortOperTable is not > contiguous due to some of those "obsolete" objects. You may want > to change that by removing the obsolete objects and filling up the > gaps. same as response to Comment 31 above. > 37) Is the fcFxPortPhysTable another augmentation of fcFxPortTable? If > there is a sparse relationship, then use the index elements of the > fcFxPortTable in the fcFxPortPhysTable. This is an R2. > 38) The MIB allows to set fcFxPortAdminMode to `unknown'. Does this > make sense? corrected. > 39) fcFxPortPhysOperStatus says that "other values may be used to > indicate online/testing diagnostic for failed tests." This is no > good idea since different implementations will use the same named > number with different semantics. This causes interoperability > problems on the manager side. agree - corrected. > 40) Should fcFxPortPhysLastChange have type TimeStamp rather than > TimeTicks? This is an R2. > 41) What about adding a UNITS clause to fcFxPortPhysRttov? > > 42) What about changing fcFxlogiTable to fcFxLoginTable and using the > fcFxLogin prefix consistently? these are R1. > 43) You should reuse fcFxPortModuleIndex and fcFxPortIndex rather than > defining fcFxlogiModuleIndex and fcFxlogiFxPortIndex in the INDEX > clause of fcFxlogiEntry. this is an R2. > 44) In some DESCRIPTION clauses in the fcFxlogiTable, you refer to > FxPort where I thought you actually mean an NxPort. Not sure why there is confusion. For now, I treat it as an R1. > 45) Should there be UNITS clauses for fcFxPortNxPortBbCredit and > fcFxPortNxPortRxDataFieldSize? This is an R1 > 46) The last sentence in the DESCRIPTION of > fcFxPortNxPortRxDataFieldSize can be removed since the range > limits are already defined in the type definition. agree - corrected. > 47) I am wondering whether fcFxPortIntermixSuppAgreed, > fcFxPortStackedConnModeAgreed, fcFxPortClass2SeqDelivAgreed, > fcFxPortClass3SeqDelivAgreed should not be merged into a single > BITS type. This can probably all be merged into > fcFxPortCosSuppAgreed? This is an R2. > 48) The DESCRIPTION of fcFxPortNxPortName says that the value has some > default if no NxPort is attached to the FxPort. I wondering how > this can happen since the table in indexed by an NxPort number... agree - corrected. > 49) I suggest to change the logic of some sentences. For example, the > DESCRIPTION of fcFxPortConnectedNxPort says: > > If the value of this object is '000000'H, this FxPort is not > engaged in a connection. > > I think its better to first name the condition and afterwards > describe which value applies: > > If this FxPort is not engaged in a connection, then the value > of this object is '000000'H. > > This applies as well to several other sentences. agree - corrected. > 50) I found the DESCRIPTION of fcFxPortBbCreditModel confusing. The > text more or less reads like a description of the FcBbCreditModel > type rather than the fcFxPortBbCreditModel obejct type. I removed the additional explanation. > 51) The text above fcFxPortErrorTable contains a conformance > requirement which should be made explicit in a compliance > statement. this is an R1. > 52) The fcFxPortErrorTable is probably another table augmentation or > you should at least reuse the INDEX components of the > fcFxPortTable. agree - R2 > 53) The counters in the fcFxPortErrorTable should have a clear > indication which object serves as a discontinuity indicator. This is an R2. > 54) The comments above the fcFxPortC1AcctTable define conformance > requirements. This should be moved into appropriate compliance > definitions. This is an R1 > 55) The accounting tables seem to either augment the port table or > they have a sparse augmentation relationship. In the later case, > use the index object of the port table. this is an R2. > 56) What you call accounting groups look more like statistic groups in > the IETF MIB module slang. Is accounting the term used in the > fibre channel standards? This would be a good reason to use the > term in the MIB as well. Otherwise, I would probably suggest to > talk about statistics rather than accounting throughout the MIB. agree - this is an R2. > 57) The description of fcFxPortC1ConnTime says that "the amount of > time of each connection is counted in octets from after a > connect-request has been accepted...". I am confused how you count > time in octets. Sounds more like fcFxPortC1ConnOctets to me. this is an R2. > 54) The comment above the fcFxPortC2AcctTable defines conformance > requirements. This should be moved into appropriate compliance > definitions. this is an R1. > 58) The accounting tables have similar objects (e.g. *InFrames, > *OutFrames). It would be nice if similar objects would be at > similar positions in the table. (In other words, put similar > objects at the beginning of the SEQUENCE.) agree - this is an R2. > 59) The comment above the fcFxPortCapTable defines conformance > requirements. This should be moved into appropriate compliance > definitions. this is an R2. > 60) Check the table indexing of fcFxPortCapTable. not sure what you mean? > 61) fcFxPortCapBbCreditMax, fcFxPortCapBbCreditMin, > fcFxPortCapRxDataFieldSizeMax, fcFxPortCapRxDataFieldSizeMin, > fcFxPortCapHoldTimeMax, fcFxPortCapHoldTimeMin > should probably have UNITS clauses. agree - this is an R1. > 62) You should only have one References sections and references should > have a unique identification. I changed that into three sub-sections for IETF References, Approved ANSI/NCITSReferences and ANSI/NCITS References Under Development respectively. References now have a unique identification. > 63) A security considerations section must be written. See the OPS web > server http://www.ops.ietf.org for some guidelines. done. > 64) You need a copyright and probably also an IPR section. done. > Juergen > -- > Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw > Technical University Braunschweig, Dept. Operating Systems & Computer Networks > Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Again, thanks for your comments. -- ---------------------------------------------------------------------- Kha Sin Teow khasin@Brocade.Com Brocade Communications Systems Tel: 408-487-8180 1901 Guadalupe Parkway Fax: 408-487-8090 San Jose, CA 95131 http://www.Brocade.Com ---------------------------------------------------------------------- From owner-ipfc@standards.gadzoox.com Mon Jun 28 12:13:01 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05079 for ; Mon, 28 Jun 1999 12:12:59 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id JAA08275 for ipfc-list; Mon, 28 Jun 1999 09:03:11 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id JAA08272 for ; Mon, 28 Jun 1999 09:03:11 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Jun 1999 09:08:09 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A11703E@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: IPFC IETF Meeting Agenda Date: Mon, 28 Jun 1999 09:08:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk WEDNESDAY, July 14, 1999 In Spektrum 3 INT Area ipfc IP Over Fibre Channel WG Agenda for IPFC WG: 1. Status of IPFC Proposed Std. RFC - Murali Rajagopal (Gadzoox) 2. Fibre Channel MIB Frame Work draft presentation - Lee (Vixel) 3. Fibre Channel Management MIB - Black (EMC) 4. New Business Discussion Murali Rajagopal IPFC WG Chair From owner-ipfc@standards.gadzoox.com Tue Jun 29 14:13:05 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17019 for ; Tue, 29 Jun 1999 14:13:04 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id LAA08727 for ipfc-list; Tue, 29 Jun 1999 11:08:18 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from Brocade.COM (asbestos.brocade.com [12.7.224.244]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id LAA08724 for ; Tue, 29 Jun 1999 11:08:14 -0700 Received: from brocade.com (gingham [192.168.1.51]) by Brocade.COM (8.8.8+Sun/8.8.8) with ESMTP id JAA00094; Tue, 29 Jun 1999 09:59:49 -0700 (PDT) Message-ID: <3778FB85.780ABD8C@brocade.com> Date: Tue, 29 Jun 1999 09:59:49 -0700 From: Kha Sin Teow Organization: Brocade Communications Systems Inc. X-Mailer: Mozilla 4.06 [en] (X11; U; SunOS 5.7 sun4u) MIME-Version: 1.0 To: Murali Rajagopal CC: "'ipfc@standards.gadzoox.com'" Subject: Re: IPFC IETF Meeting Agenda References: <312419998E3CD211A52900A0C991A47A11703E@gordan.pl.gadzoox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Murali Rajagopal wrote: > > WEDNESDAY, July 14, 1999 > > In Spektrum 3 INT Area ipfc IP Over Fibre Channel WG > > Agenda for IPFC WG: > > 1. Status of IPFC Proposed Std. RFC - Murali Rajagopal (Gadzoox) > 2. Fibre Channel MIB Frame Work draft presentation - Lee (Vixel) > 3. Fibre Channel Management MIB - Black (EMC) > 4. New Business Discussion > > Murali Rajagopal > > IPFC WG Chair Hi Murali, I would like to add Fibre Channel Fabric Element MIB on the agenda. Thanks. ---------------------------------------------------------------------- Kha Sin Teow khasin@Brocade.Com Brocade Communications Systems Tel: 408-487-8180 1901 Guadalupe Parkway Fax: 408-487-8090 San Jose, CA 95131 http://www.Brocade.Com ---------------------------------------------------------------------- From owner-ipfc@standards.gadzoox.com Wed Jun 30 07:44:38 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13479 for ; Wed, 30 Jun 1999 07:44:37 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id EAA09180 for ipfc-list; Wed, 30 Jun 1999 04:39:33 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id EAA09177 for ; Wed, 30 Jun 1999 04:39:32 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13426; Wed, 30 Jun 1999 07:42:26 -0400 (EDT) Message-Id: <199906301142.HAA13426@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipfc@standards.gadzoox.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipfc-fabric-element-mib-05.txt Date: Wed, 30 Jun 1999 07:42:26 -0400 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Over Fibre Channel Working Group of the IETF. Title : Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard Author(s) : K. Teow Filename : draft-ietf-ipfc-fabric-element-mib-05.txt Pages : 52 Date : 29-Jun-99 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfc-fabric-element-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990629142638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfc-fabric-element-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990629142638.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipfc@standards.gadzoox.com Wed Jun 30 11:17:41 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18508 for ; Wed, 30 Jun 1999 11:17:39 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA09226 for ipfc-list; Wed, 30 Jun 1999 08:12:16 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mailserver.enetvalue.com ([216.64.36.2]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id IAA09223 for ; Wed, 30 Jun 1999 08:12:12 -0700 From: Internet-Drafts@ietf.org Received: from mail pickup service by mailserver.enetvalue.com with Microsoft SMTPSVC; Wed, 30 Jun 1999 11:15:40 -0400 Received: from loki.ietf.org ([132.151.1.177]) by mailserver.enetvalue.com with Microsoft SMTPSVC(5.5.1875.185.18); Wed, 30 Jun 1999 10:55:22 -0400 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA27629 for ietf-123-outbound.03@ietf.org; Wed, 30 Jun 1999 10:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA26653 for ; Wed, 30 Jun 1999 07:46:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13426; Wed, 30 Jun 1999 07:42:26 -0400 (EDT) Message-Id: <199906301142.HAA13426@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipfc@standards.gadzoox.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipfc-fabric-element-mib-05.txt Date: Wed, 30 Jun 1999 07:42:26 -0400 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Over Fibre Channel Working Group of the IETF. Title : Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard Author(s) : K. Teow Filename : draft-ietf-ipfc-fabric-element-mib-05.txt Pages : 52 Date : 29-Jun-99 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfc-fabric-element-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990629142638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfc-fabric-element-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990629142638.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipfc@standards.gadzoox.com Wed Jun 30 11:19:29 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18582 for ; Wed, 30 Jun 1999 11:19:24 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA09233 for ipfc-list; Wed, 30 Jun 1999 08:14:59 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mailserver.enetvalue.com ([216.64.36.2]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id IAA09230 for ; Wed, 30 Jun 1999 08:14:57 -0700 From: Internet-Drafts@ietf.org Received: from mail pickup service by mailserver.enetvalue.com with Microsoft SMTPSVC; Wed, 30 Jun 1999 11:18:35 -0400 Received: from loki.ietf.org ([132.151.1.177]) by mailserver.enetvalue.com with Microsoft SMTPSVC(5.5.1875.185.18); Wed, 30 Jun 1999 10:55:22 -0400 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA27629 for ietf-123-outbound.03@ietf.org; Wed, 30 Jun 1999 10:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA26653 for ; Wed, 30 Jun 1999 07:46:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13426; Wed, 30 Jun 1999 07:42:26 -0400 (EDT) Message-Id: <199906301142.HAA13426@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipfc@standards.gadzoox.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipfc-fabric-element-mib-05.txt Date: Wed, 30 Jun 1999 07:42:26 -0400 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Over Fibre Channel Working Group of the IETF. Title : Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard Author(s) : K. Teow Filename : draft-ietf-ipfc-fabric-element-mib-05.txt Pages : 52 Date : 29-Jun-99 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfc-fabric-element-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990629142638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfc-fabric-element-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990629142638.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipfc@standards.gadzoox.com Wed Jun 30 11:19:36 1999 Received: from standards.gadzoox.com (standards.gadzoox.com [208.244.121.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18592 for ; Wed, 30 Jun 1999 11:19:31 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA09238 for ipfc-list; Wed, 30 Jun 1999 08:15:01 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mailserver.enetvalue.com ([216.64.36.2]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id IAA09235 for ; Wed, 30 Jun 1999 08:15:00 -0700 From: Internet-Drafts@ietf.org Received: from mail pickup service by mailserver.enetvalue.com with Microsoft SMTPSVC; Wed, 30 Jun 1999 11:18:37 -0400 Received: from loki.ietf.org ([132.151.1.177]) by mailserver.enetvalue.com with Microsoft SMTPSVC(5.5.1875.185.18); Wed, 30 Jun 1999 10:55:22 -0400 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA27629 for ietf-123-outbound.03@ietf.org; Wed, 30 Jun 1999 10:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA26653 for ; Wed, 30 Jun 1999 07:46:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13426; Wed, 30 Jun 1999 07:42:26 -0400 (EDT) Message-Id: <199906301142.HAA13426@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipfc@standards.gadzoox.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipfc-fabric-element-mib-05.txt Date: Wed, 30 Jun 1999 07:42:26 -0400 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Over Fibre Channel Working Group of the IETF. Title : Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard Author(s) : K. Teow Filename : draft-ietf-ipfc-fabric-element-mib-05.txt Pages : 52 Date : 29-Jun-99 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfc-fabric-element-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990629142638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfc-fabric-element-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfc-fabric-element-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990629142638.I-D@ietf.org> --OtherAccess-- --NextPart--