From mailnull@www1.ietf.org Tue Apr 1 12:08:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00178 for ; Tue, 1 Apr 2003 12:08:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31HW4e09280 for midcom-archive@odin.ietf.org; Tue, 1 Apr 2003 12:32:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HVLK09194; Tue, 1 Apr 2003 12:31:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HSMK06883 for ; Tue, 1 Apr 2003 12:28:22 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29595 for ; Tue, 1 Apr 2003 12:04:00 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31H6Q4c017015 for ; Tue, 1 Apr 2003 09:06:26 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFK38003; Tue, 1 Apr 2003 09:06:25 -0800 (PST) Message-Id: <200304011706.AFK38003@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 01 Apr 2003 12:06:25 -0500 Subject: [midcom] Draft minutes from IETF 56 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've appended the draft minutes from the meeting in San Francisco. Please give them a read and post any additions, corrections, etc. to the mailing list. Many thanks to Tom Taylor for his excellent notes. Melinda -------- Draft IETF 56 MIDCOM minutes, reported by Tom Taylor . MIDCOM met for one hour on Tuesday afternoon, 18 March 2003. Melinda Shore chaired the meeting. 1. Agenda-bashing ================= The agenda was accepted as proposed. 2. Status update ================ STUN has now been published as RFC 3489. The protocol evaluation document is scheduled to be through WG last call in May 2003, and we appear to be on schedule. It looks like first draft of the MIDCOM MIB document is pretty well on schedule (March 2003). 3. MIDCOM MIB ============== MIDCOM is operating on the hypothesis that the MIDCOM transport protocol will be SNMPv3. A design team consisting of Mary Barnes (Editor), David Harrington , and Martin Stiemerling has begun work on the MIDCOM MIB. Mary presented the initial report on the status of the design team's work. The team is generally agreed on the applicability of the NAT MIB to the MIDCOM work. It has been looking at other MIBs (listed in Mary's charts) to see which modules or parts thereof meet the MIDCOM requirements. One of the charts showed the sets of MIBs potentially applicable at the middlebox, but also at the MIDCOM policy decision point (PDP). Several policy-related MIBs are applicable at the PDP and are of importance to the successful operation of MIDCOM, but are outside the scope of the WG. Juergen Quittek asked what aspects of the Policy Coordination and Policy MIBs the design team would tackle. David Harrington took the floor to respond. [I missed something here] David recommends using templates rather than a script base. Juergen asked whether the diagram (which showed a "MIDCOM Interface" function sitting atop a number of service configuration MIBs relating to the actual middlebox device operation) indicated that the MIDCOM MIB sits on top of the service configuration MIBs? Mary Barnes responded that MIDCOM is viewed as a coordination function amongst these MIBs. Subsequent discussion drew a clarification that the "Application Requests" from the MIDCOM agent to the middlebox are carried by SNMPv3. The design team's goal is to make a baseline document available shortly. The team needs immediate feedback before they dig more deeply. At this point David Harrington took discussion in a new direction. He noted that the question has been asked: why MIDCOM does not use XMLConf (XML-based configuration) instead of SNMP? It is clear that operators do not use SNMPv3 to do configuration now. There is a concern that operators won't turn on SNMPv3 SETs to allow MIDCOM to work. The IESG response to this proposition has been to suggest that thought be given to the general situation before doing detailed MIDCOM MIB work. Based on the outcome of the netconf BOF at this meeting, prospects look good for XMLConf to go ahead. Melinda asked what would make us think that operators will turn on XMLConf. Jonathan Rosenberg stated that they would do so because XMLConf would be much cheaper to run. David Harrington noted that we could think of the current work as design of an information model before doing a data model. The work won't be wasted if care is taken by the XMLConf design group to allow reuse of existing information modelling. Bert Wijnen offered the opinion that some of the MIDCOM MIB work going forward may be wasted. Definitely operators are not interested in using COPS/COPS-PR, and are using CLI rather than SNMP for configuration. Maybe 60-70% of the people in the room at the netconf BOF had read the XMLConf document -- an amazingly high proportion compared with typical IETF participation. There was substantial operator support for development of an XMLConf approach to configuration. Bert, as Operations Area AD, does not require writable objects in MIBs -- a change in heart from two years ago. The MIDCOM WG should take this into account. Melinda Shore confessed herself a bit surprised. Bert responded that an Operations Area open meeting is scheduled for Thursday. There will probably be an AD statement on the configuration topic then. Jonathan Rosenberg expressed a concern over whether the MIDCOM information model would be reusable. Basically we have a good understanding of the problem now. He doesn't want to do work that will be obsolete. What are the detailed reasons that operators do not enable SNMPv3 SET? Bert replied that there was no point in going into the reasons; we just have to accept the fact. The operators are not using it. In contrast, the cable and ATM worlds do use it. Christian Huitema reminded the meeting that the original perceived MIDCOM target was enabling enterprise applications to run across firewalls. The focus is on enterprise and real-time operations. This is in some contrast to configuration, which is typically a batch process. Bert agreed that netconf is addressing a different environment. Christian remarked that the main problem is to convince enterprise network operators to allow a server to punch holes in the firewall in real time. Jonathan Rosenberg remarked that SNMP was selected as the MIDCOM candidate partly because it would be there anyway. It looks like this premise was dubious. David Harrington replied that SNMP would still be there for monitoring. XMLConf will be there for configuration. The XMLConf group would like to reuse the MIB modules which were designed with config in mind. The implication is that XMLConf will be compatibile with SNMPv3. Jonathan rejoined that we are still facing a situation of reduced motivation to use SNMPv3. Marcus Brunner <...> responded that we already have a pretty good idea of the information that has to go back and forth (the semantics). We can fairly easily create an SNMP module now, then use the same source for XML. Juergen Quittek agreed that it should be easy given the semantics already defined. He sees it as worthwhile to do the MIB now. Brian Carpenter <...> remarked that SNMPv3 SETs won't work too well in enterprise environments with internal firewalls/NATs. There is a chicken-and-egg situation where MIDCOM would be needed to enable MIDCOM. David Harrington noted that SNMPv3 itself will help to some extent. Brian stated that there is a job of persuasion to do before operators will allow MIDCOM to run. Tom Taylor added that it is clear that as part of the task of persuading operators to allow MIDCOM to function, someone has to do a good job of designing the policy controls to keep applications within their intended limits when MIDCOM is present. 4. Semantics document draft-ietf-midcom-semantics-01.txt ====================================== Martin Stiemerling reviewed the latest changes to the MIDCOM semantics draft. The main one has been to downgrade the role of groups. He has alaso made some revisions to the conformance statements. Open issues: Is wildcarding of IP addresses needed? More details on capability information sent by middlebox during session establishment. Whether explicit support for other protocols besides UDP and TCP is needed. Whether the middlebox should offer a choice of encryption methods for authentication during session establishment. Fuller security considerations. Possible addition of agent-supplied parameters to restrict usage of pinhole? Martin presented an explanation of the requirement for the Policy Rule Reserve (PRR) operation. As subsequent discussion showed, the rtequirement for address reservation got confused with the IP wildcarding issue. Jonathan Rosenberg pointed out that PRR as shown in Martin's example won't work with early media. IP wildcards are essential. Jonathan was supported by Christian Huitema, who invoked the principle that one shouldn't embed policy decisions (prohibition of cones in favour of pinholes) in the design of the protocol. Jonathan further noted that forking could also result in blocked media if wildcarding is not allowed. Juergen Quittek advanced the counter-argument that if IP address wildcarding is allowed, it will always be used, and there will be no incentive to restrict firewall openings to the minimum width necessary. Christian Huitema repeated his point that this was a policy issue which should not be settled in advance by the protocol. Bob Penfield argued that the key point is that the agent needs to handle the two directions of media flow separately. Reservation is appropriate for the outgoing direction, but wildcarding is required for the incoming flow -- particularly since the source of early media can differ from the source of media sent after answer. 5. Wrapup ========= The Chair terminated discussion at this point, as the meeting time had expired. As usual with MIDCOM, there will be discussions with the IESG on how to proceed. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Apr 2 04:40:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01848 for ; Wed, 2 Apr 2003 04:40:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32A51p21409 for midcom-archive@odin.ietf.org; Wed, 2 Apr 2003 05:05:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32A46K21359; Wed, 2 Apr 2003 05:04:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32A05K21199 for ; Wed, 2 Apr 2003 05:00:05 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01792 for ; Wed, 2 Apr 2003 04:34:30 -0500 (EST) From: hlpeth@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h329Yxs05697 for ; Wed, 2 Apr 2003 15:05:00 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h329Yx205691 for ; Wed, 2 Apr 2003 15:04:59 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h329box14610 for ; Wed, 2 Apr 2003 15:07:51 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CFC.00338902 ; Wed, 2 Apr 2003 14:52:54 +0530 X-Lotus-FromDomain: HSS To: midcom@ietf.org Message-ID: <65256CFC.00338836.00@dlfmail1.hss.hns.com> Date: Wed, 2 Apr 2003 15:03:44 +0530 Subject: [midcom] Draft minutes from IETF 56 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, I was going through the draft minutes. Some of the concerns mentioned below could be looked at a different perspective: (gets mentioned somewhat in the later part of the minutes) Separation of model and implementation: SNMP based model could consist of a comprehensive set of objects (SET, GET, NOTIFICATION) Selected objects could be selected (say all SET objects) and converted to XML and also depending on the site specific requirements. The implementor of the MIB could be provided a guideline that he should be implementing only monitored attributes. Effectively what i would like to emphasize here is that there needs to exists a base model (SNMP) from which you can generate subset models (XML). We need not spend effort defining two separate models. regards -- harish ---------------------- Forwarded by Kushanava Laha/HSS on 04/02/2003 11:17 AM --------------------------- To: midcom@ietf.org cc: (bcc: Kushanava Laha/HSS) Subject: [midcom] Draft minutes from IETF 56 I've appended the draft minutes from the meeting in San Francisco. Please give them a read and post any additions, corrections, etc. to the mailing list. Many thanks to Tom Taylor for his excellent notes. Melinda -------- Draft IETF 56 MIDCOM minutes, reported by Tom Taylor . MIDCOM met for one hour on Tuesday afternoon, 18 March 2003. Melinda Shore chaired the meeting. 1. Agenda-bashing ================= The agenda was accepted as proposed. 2. Status update ================ STUN has now been published as RFC 3489. The protocol evaluation document is scheduled to be through WG last call in May 2003, and we appear to be on schedule. It looks like first draft of the MIDCOM MIB document is pretty well on schedule (March 2003). 3. MIDCOM MIB ============== MIDCOM is operating on the hypothesis that the MIDCOM transport protocol will be SNMPv3. A design team consisting of Mary Barnes (Editor), David Harrington , and Martin Stiemerling has begun work on the MIDCOM MIB. Mary presented the initial report on the status of the design team's work. The team is generally agreed on the applicability of the NAT MIB to the MIDCOM work. It has been looking at other MIBs (listed in Mary's charts) to see which modules or parts thereof meet the MIDCOM requirements. One of the charts showed the sets of MIBs potentially applicable at the middlebox, but also at the MIDCOM policy decision point (PDP). Several policy-related MIBs are applicable at the PDP and are of importance to the successful operation of MIDCOM, but are outside the scope of the WG. Juergen Quittek asked what aspects of the Policy Coordination and Policy MIBs the design team would tackle. David Harrington took the floor to respond. [I missed something here] David recommends using templates rather than a script base. Juergen asked whether the diagram (which showed a "MIDCOM Interface" function sitting atop a number of service configuration MIBs relating to the actual middlebox device operation) indicated that the MIDCOM MIB sits on top of the service configuration MIBs? Mary Barnes responded that MIDCOM is viewed as a coordination function amongst these MIBs. Subsequent discussion drew a clarification that the "Application Requests" from the MIDCOM agent to the middlebox are carried by SNMPv3. The design team's goal is to make a baseline document available shortly. The team needs immediate feedback before they dig more deeply. At this point David Harrington took discussion in a new direction. He noted that the question has been asked: why MIDCOM does not use XMLConf (XML-based configuration) instead of SNMP? It is clear that operators do not use SNMPv3 to do configuration now. There is a concern that operators won't turn on SNMPv3 SETs to allow MIDCOM to work. The IESG response to this proposition has been to suggest that thought be given to the general situation before doing detailed MIDCOM MIB work. Based on the outcome of the netconf BOF at this meeting, prospects look good for XMLConf to go ahead. Melinda asked what would make us think that operators will turn on XMLConf. Jonathan Rosenberg stated that they would do so because XMLConf would be much cheaper to run. David Harrington noted that we could think of the current work as design of an information model before doing a data model. The work won't be wasted if care is taken by the XMLConf design group to allow reuse of existing information modelling. Bert Wijnen offered the opinion that some of the MIDCOM MIB work going forward may be wasted. Definitely operators are not interested in using COPS/COPS-PR, and are using CLI rather than SNMP for configuration. Maybe 60-70% of the people in the room at the netconf BOF had read the XMLConf document -- an amazingly high proportion compared with typical IETF participation. There was substantial operator support for development of an XMLConf approach to configuration. Bert, as Operations Area AD, does not require writable objects in MIBs -- a change in heart from two years ago. The MIDCOM WG should take this into account. Melinda Shore confessed herself a bit surprised. Bert responded that an Operations Area open meeting is scheduled for Thursday. There will probably be an AD statement on the configuration topic then. Jonathan Rosenberg expressed a concern over whether the MIDCOM information model would be reusable. Basically we have a good understanding of the problem now. He doesn't want to do work that will be obsolete. What are the detailed reasons that operators do not enable SNMPv3 SET? Bert replied that there was no point in going into the reasons; we just have to accept the fact. The operators are not using it. In contrast, the cable and ATM worlds do use it. Christian Huitema reminded the meeting that the original perceived MIDCOM target was enabling enterprise applications to run across firewalls. The focus is on enterprise and real-time operations. This is in some contrast to configuration, which is typically a batch process. Bert agreed that netconf is addressing a different environment. Christian remarked that the main problem is to convince enterprise network operators to allow a server to punch holes in the firewall in real time. Jonathan Rosenberg remarked that SNMP was selected as the MIDCOM candidate partly because it would be there anyway. It looks like this premise was dubious. David Harrington replied that SNMP would still be there for monitoring. XMLConf will be there for configuration. The XMLConf group would like to reuse the MIB modules which were designed with config in mind. The implication is that XMLConf will be compatibile with SNMPv3. Jonathan rejoined that we are still facing a situation of reduced motivation to use SNMPv3. Marcus Brunner <...> responded that we already have a pretty good idea of the information that has to go back and forth (the semantics). We can fairly easily create an SNMP module now, then use the same source for XML. Juergen Quittek agreed that it should be easy given the semantics already defined. He sees it as worthwhile to do the MIB now. Brian Carpenter <...> remarked that SNMPv3 SETs won't work too well in enterprise environments with internal firewalls/NATs. There is a chicken-and-egg situation where MIDCOM would be needed to enable MIDCOM. David Harrington noted that SNMPv3 itself will help to some extent. Brian stated that there is a job of persuasion to do before operators will allow MIDCOM to run. Tom Taylor added that it is clear that as part of the task of persuading operators to allow MIDCOM to function, someone has to do a good job of designing the policy controls to keep applications within their intended limits when MIDCOM is present. 4. Semantics document draft-ietf-midcom-semantics-01.txt ====================================== Martin Stiemerling reviewed the latest changes to the MIDCOM semantics draft. The main one has been to downgrade the role of groups. He has alaso made some revisions to the conformance statements. Open issues: Is wildcarding of IP addresses needed? More details on capability information sent by middlebox during session establishment. Whether explicit support for other protocols besides UDP and TCP is needed. Whether the middlebox should offer a choice of encryption methods for authentication during session establishment. Fuller security considerations. Possible addition of agent-supplied parameters to restrict usage of pinhole? Martin presented an explanation of the requirement for the Policy Rule Reserve (PRR) operation. As subsequent discussion showed, the rtequirement for address reservation got confused with the IP wildcarding issue. Jonathan Rosenberg pointed out that PRR as shown in Martin's example won't work with early media. IP wildcards are essential. Jonathan was supported by Christian Huitema, who invoked the principle that one shouldn't embed policy decisions (prohibition of cones in favour of pinholes) in the design of the protocol. Jonathan further noted that forking could also result in blocked media if wildcarding is not allowed. Juergen Quittek advanced the counter-argument that if IP address wildcarding is allowed, it will always be used, and there will be no incentive to restrict firewall openings to the minimum width necessary. Christian Huitema repeated his point that this was a policy issue which should not be settled in advance by the protocol. Bob Penfield argued that the key point is that the agent needs to handle the two directions of media flow separately. Reservation is appropriate for the outgoing direction, but wildcarding is required for the incoming flow -- particularly since the source of early media can differ from the source of media sent after answer. 5. Wrapup ========= The Chair terminated discussion at this point, as the meeting time had expired. As usual with MIDCOM, there will be discussions with the IESG on how to proceed. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Apr 2 15:53:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08726 for ; Wed, 2 Apr 2003 15:53:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32LI6C17430 for midcom-archive@odin.ietf.org; Wed, 2 Apr 2003 16:18:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LHMK17359; Wed, 2 Apr 2003 16:17:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LEUK17178 for ; Wed, 2 Apr 2003 16:14:30 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08524 for ; Wed, 2 Apr 2003 15:49:32 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32Kppo10667; Wed, 2 Apr 2003 14:51:51 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 14:51:52 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABC1E@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Draft minutes from IETF 56 Date: Wed, 2 Apr 2003 14:51:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F959.ABF0BB22" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F959.ABF0BB22 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, April 01, 2003 11:06 AM To: midcom@ietf.org Subject: [midcom] Draft minutes from IETF 56 I've appended the draft minutes from the meeting in San Francisco. Please give them a read and post any additions, corrections, etc. to the mailing list. Many thanks to Tom Taylor for his excellent notes. Melinda -------- Draft IETF 56 MIDCOM minutes, reported by Tom Taylor . MIDCOM met for one hour on Tuesday afternoon, 18 March 2003. Melinda Shore chaired the meeting. 1. Agenda-bashing ================= The agenda was accepted as proposed. 2. Status update ================ STUN has now been published as RFC 3489. The protocol evaluation document is scheduled to be through WG last call in May 2003, and we appear to be on schedule. It looks like first draft of the MIDCOM MIB document is pretty well on schedule (March 2003). 3. MIDCOM MIB ============== MIDCOM is operating on the hypothesis that the MIDCOM transport protocol will be SNMPv3. A design team consisting of Mary Barnes (Editor), David Harrington , and Martin Stiemerling has begun work on the MIDCOM MIB. Mary presented the initial report on the status of the design team's work. The team is generally agreed on the applicability of the NAT MIB to the MIDCOM work. It has been looking at other MIBs (listed in Mary's charts) to see which modules or parts thereof meet the MIDCOM requirements. One of the charts showed the sets of MIBs potentially applicable at the middlebox, but also at the MIDCOM policy decision point (PDP). Several policy-related MIBs are applicable at the PDP and are of importance to the successful operation of MIDCOM, but are outside the scope of the WG. Juergen Quittek asked what aspects of the Policy Coordination and Policy MIBs the design team would tackle. David Harrington took the floor to respond. [I missed something here] David recommends using templates rather than a script base. Juergen asked whether the diagram (which showed a "MIDCOM Interface" function sitting atop a number of service configuration MIBs relating to the actual middlebox device operation) indicated that the MIDCOM MIB sits on top of the service configuration MIBs? Mary Barnes responded that MIDCOM is viewed as a coordination function amongst these MIBs. Subsequent discussion drew a clarification that the "Application Requests" from the MIDCOM agent to the middlebox are carried by SNMPv3. The design team's goal is to make a baseline document available shortly. The team needs immediate feedback before they dig more deeply. At this point David Harrington took discussion in a new direction. He noted that the question has been asked: why MIDCOM does not use XMLConf (XML-based configuration) instead of SNMP? It is clear that operators do not use SNMPv3 to do configuration now. There is a concern that operators won't turn on SNMPv3 SETs to allow MIDCOM to work. The IESG response to this proposition has been to suggest that thought be given to the general situation before doing detailed MIDCOM MIB work. Based on the outcome of the netconf BOF at this meeting, prospects look good for XMLConf to go ahead. Melinda asked what would make us think that operators will turn on XMLConf. Jonathan Rosenberg stated that they would do so because XMLConf would be much cheaper to run. David Harrington noted that we could think of the current work as design of an information model before doing a data model. The work won't be wasted if care is taken by the XMLConf design group to allow reuse of existing information modelling. Bert Wijnen offered the opinion that some of the MIDCOM MIB work going forward may be wasted. Definitely operators are not interested in using COPS/COPS-PR, and are using CLI rather than SNMP for configuration. Maybe 60-70% of the people in the room at the netconf BOF had read the XMLConf document -- an amazingly high proportion compared with typical IETF participation. There was substantial operator support for development of an XMLConf approach to configuration. Bert, as Operations Area AD, does not require writable objects in MIBs -- a change in heart from two years ago. The MIDCOM WG should take this into account. Melinda Shore confessed herself a bit surprised. Bert responded that an Operations Area open meeting is scheduled for Thursday. There will probably be an AD statement on the configuration topic then. Jonathan Rosenberg expressed a concern over whether the MIDCOM information model would be reusable. Basically we have a good understanding of the problem now. He doesn't want to do work that will be obsolete. What are the detailed reasons that operators do not enable SNMPv3 SET? Bert replied that there was no point in going into the reasons; we just have to accept the fact. The operators are not using it. In contrast, the cable and ATM worlds do use it. Christian Huitema reminded the meeting that the original perceived MIDCOM target was enabling enterprise applications to run across firewalls. The focus is on enterprise and real-time operations. This is in some contrast to configuration, which is typically a batch process. Bert agreed that netconf is addressing a different environment. Christian remarked that the main problem is to convince enterprise network operators to allow a server to punch holes in the firewall in real time. Jonathan Rosenberg remarked that SNMP was selected as the MIDCOM candidate partly because it would be there anyway. It looks like this premise was dubious. David Harrington replied that SNMP would still be there for monitoring. XMLConf will be there for configuration. The XMLConf group would like to reuse the MIB modules which were designed with config in mind. The implication is that XMLConf will be compatibile with SNMPv3. Jonathan rejoined that we are still facing a situation of reduced motivation to use SNMPv3. Marcus Brunner <...> responded that we already have a pretty good idea of the information that has to go back and forth (the semantics). We can fairly easily create an SNMP module now, then use the same source for XML. Juergen Quittek agreed that it should be easy given the semantics already defined. He sees it as worthwhile to do the MIB now. Brian Carpenter <...> remarked that SNMPv3 SETs won't work too well in enterprise environments with internal firewalls/NATs. There is a chicken-and-egg situation where MIDCOM would be needed to enable MIDCOM. David Harrington noted that SNMPv3 itself will help to some extent. Brian stated that there is a job of persuasion to do before operators will allow MIDCOM to run. Tom Taylor added that it is clear that as part of the task of persuading operators to allow MIDCOM to function, someone has to do a good job of designing the policy controls to keep applications within their intended limits when MIDCOM is present. 4. Semantics document draft-ietf-midcom-semantics-01.txt ====================================== Martin Stiemerling reviewed the latest changes to the MIDCOM semantics draft. The main one has been to downgrade the role of groups. He has alaso made some revisions to the conformance statements. Open issues: Is wildcarding of IP addresses needed? More details on capability information sent by middlebox during session establishment. Whether explicit support for other protocols besides UDP and TCP is needed. Whether the middlebox should offer a choice of encryption methods for authentication during session establishment. Fuller security considerations. Possible addition of agent-supplied parameters to restrict usage of pinhole? Martin presented an explanation of the requirement for the Policy Rule Reserve (PRR) operation. As subsequent discussion showed, the rtequirement for address reservation got confused with the IP wildcarding issue. Jonathan Rosenberg pointed out that PRR as shown in Martin's example won't work with early media. IP wildcards are essential. Jonathan was supported by Christian Huitema, who invoked the principle that one shouldn't embed policy decisions (prohibition of cones in favour of pinholes) in the design of the protocol. Jonathan further noted that forking could also result in blocked media if wildcarding is not allowed. Juergen Quittek advanced the counter-argument that if IP address wildcarding is allowed, it will always be used, and there will be no incentive to restrict firewall openings to the minimum width necessary. Christian Huitema repeated his point that this was a policy issue which should not be settled in advance by the protocol. Bob Penfield argued that the key point is that the agent needs to handle the two directions of media flow separately. Reservation is appropriate for the outgoing direction, but wildcarding is required for the incoming flow -- particularly since the source of early media can differ from the source of media sent after answer. 5. Wrapup ========= The Chair terminated discussion at this point, as the meeting time had expired. As usual with MIDCOM, there will be discussions with the IESG on how to proceed. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C2F959.ABF0BB22 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] Draft minutes from IETF 56

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Tuesday, April 01, 2003 11:06 AM
To: midcom@ietf.org
Subject: [midcom] Draft minutes from IETF 56


I've appended the draft minutes from the meeting in San
Francisco.  Please give them a read and post any additions,
corrections, etc. to the mailing list.  Many thanks to Tom
Taylor for his excellent notes.

Melinda

--------

Draft IETF 56 MIDCOM minutes, reported by Tom Taylor
<taylor@nortelnetworks.com>.

MIDCOM met for one hour on Tuesday afternoon, 18 March 2003.  Melinda
Shore <mshore@cisco.com> chaired the meeting.

1. Agenda-bashing
=================

The agenda was accepted as proposed.

2. Status update
================

STUN has now been published as RFC 3489.

The protocol evaluation document is scheduled to be through
WG last call in May 2003, and we appear to be on schedule.

It looks like first draft of the MIDCOM MIB document is
pretty well on schedule (March 2003).

3.  MIDCOM MIB
==============

MIDCOM is operating on the hypothesis that the MIDCOM
transport protocol will be SNMPv3.  A design team consisting
of Mary Barnes <mbarnes@nortelnetworks.com> (Editor), David
Harrington <dbh@enterasys.com>, and Martin Stiemerling
<Martin.Stiemerling@ccrle.nec.de> has begun work on the
MIDCOM MIB.

Mary presented the initial report on the status of the
design team's work.  The team is generally agreed on the
applicability of the NAT MIB to the MIDCOM work.  It has
been looking at other MIBs (listed in Mary's charts) to see
which modules or parts thereof meet the MIDCOM requirements.

One of the charts showed the sets of MIBs potentially
applicable at the middlebox, but also at the MIDCOM policy
decision point (PDP).  Several policy-related MIBs are
applicable at the PDP and are of importance to the
successful operation of MIDCOM, but are outside the scope of
the WG.

Juergen Quittek <Quittek@ccrle.nec.de> asked what aspects of
the Policy Coordination and Policy MIBs the design team
would tackle.  David Harrington took the floor to respond.
[I missed something here] David recommends using templates
rather than a script base.

Juergen asked whether the diagram (which showed a "MIDCOM
Interface" function sitting atop a number of service
configuration MIBs relating to the actual middlebox device
operation) indicated that the MIDCOM MIB sits on top of the
service configuration MIBs?  Mary Barnes responded that
MIDCOM is viewed as a coordination function amongst these
MIBs.  Subsequent discussion drew a clarification that the
"Application Requests" from the MIDCOM agent to the
middlebox are carried by SNMPv3.

The design team's goal is to make a baseline document
available shortly.  The team needs immediate feedback before
they dig more deeply.

At this point David Harrington took discussion in a new
direction.  He noted that the question has been asked: why
MIDCOM does not use XMLConf (XML-based configuration)
instead of SNMP?  It is clear that operators do not use
SNMPv3 to do configuration now.  There is a concern that
operators won't turn on SNMPv3 SETs to allow MIDCOM to work.
The IESG response to this proposition has been to suggest
that thought be given to the general situation before doing
detailed MIDCOM MIB work.

Based on the outcome of the netconf BOF at this meeting,
prospects look good for XMLConf to go ahead.  Melinda asked
what would make us think that operators will turn on
XMLConf.  Jonathan Rosenberg <jdrosen@dynamicsoft.com>
stated that they would do so because XMLConf would be much
cheaper to run.

David Harrington noted that we could think of the current
work as design of an information model before doing a data
model.  The work won't be wasted if care is taken by the
XMLConf design group to allow reuse of existing information
modelling.

Bert Wijnen <bwijnen@lucent.com> offered the opinion that
some of the MIDCOM MIB work going forward may be wasted.
Definitely operators are not interested in using
COPS/COPS-PR, and are using CLI rather than SNMP for
configuration.  Maybe 60-70% of the people in the room at
the netconf BOF had read the XMLConf document -- an
amazingly high proportion compared with typical IETF
participation.  There was substantial operator support for
development of an XMLConf approach to configuration.  Bert,
as Operations Area AD, does not require writable objects in
MIBs -- a change in heart from two years ago.  The MIDCOM WG
should take this into account.

Melinda Shore confessed herself a bit surprised.  Bert
responded that an Operations Area open meeting is scheduled
for Thursday.  There will probably be an AD statement on the
configuration topic then.

Jonathan Rosenberg expressed a concern over whether the
MIDCOM information model would be reusable.  Basically we
have a good understanding of the problem now.  He doesn't
want to do work that will be obsolete.  What are the
detailed reasons that operators do not enable SNMPv3 SET?
Bert replied that there was no point in going into the
reasons; we just have to accept the fact.  The operators are
not using it.  In contrast, the cable and ATM worlds do use
it.

Christian Huitema <chuitema@microsoft.com> reminded the
meeting that the original perceived MIDCOM target was
enabling enterprise applications to run across firewalls.
The focus is on enterprise and real-time operations.  This
is in some contrast to configuration, which is typically a
batch process.  Bert agreed that netconf is addressing a
different environment.  Christian remarked that the main
problem is to convince enterprise network operators to allow
a server to punch holes in the firewall in real time.

Jonathan Rosenberg remarked that SNMP was selected as the
MIDCOM candidate partly because it would be there anyway.
It looks like this premise was dubious.  David Harrington
replied that SNMP would still be there for monitoring.
XMLConf will be there for configuration.  The XMLConf group
would like to reuse the MIB modules which were designed with
config in mind.  The implication is that XMLConf will be
compatibile with SNMPv3.  Jonathan rejoined that we are
still facing a situation of reduced motivation to use
SNMPv3.

Marcus Brunner <...> responded that we already have a pretty
good idea of the information that has to go back and forth
(the semantics).  We can fairly easily create an SNMP module
now, then use the same source for XML.  Juergen Quittek
agreed that it should be easy given the semantics already
defined.  He sees it as worthwhile to do the MIB now.

Brian Carpenter <...> remarked that SNMPv3 SETs won't work
too well in enterprise environments with internal
firewalls/NATs.  There is a chicken-and-egg situation where
MIDCOM would be needed to enable MIDCOM.  David Harrington
noted that SNMPv3 itself will help to some extent.

Brian stated that there is a job of persuasion to do before
operators will allow MIDCOM to run.  Tom Taylor added that
it is clear that as part of the task of persuading operators
to allow MIDCOM to function, someone has to do a good job of
designing the policy controls to keep applications within
their intended limits when MIDCOM is present.

4. Semantics document
     draft-ietf-midcom-semantics-01.txt
======================================

Martin Stiemerling reviewed the latest changes to the MIDCOM
semantics draft.  The main one has been to downgrade the
role of groups.  He has alaso made some revisions to the
conformance statements.

Open issues:
   Is wildcarding of IP addresses needed?
   More details on capability information sent by middlebox during session
establishment.
   Whether explicit support for other protocols besides UDP and TCP is needed.
   Whether the middlebox should offer a choice of encryption methods for
authentication during session establishment.
   Fuller security considerations.
   Possible addition of agent-supplied parameters to restrict usage of pinhole?

Martin presented an explanation of the requirement for the
Policy Rule Reserve (PRR) operation.  As subsequent
discussion showed, the rtequirement for address reservation
got confused with the IP wildcarding issue.

Jonathan Rosenberg pointed out that PRR as shown in Martin's
example won't work with early media.  IP wildcards are
essential.  Jonathan was supported by Christian Huitema, who
invoked the principle that one shouldn't embed policy
decisions (prohibition of cones in favour of pinholes) in
the design of the protocol.  Jonathan further noted that
forking could also result in blocked media if wildcarding is
not allowed.

Juergen Quittek advanced the counter-argument that if IP
address wildcarding is allowed, it will always be used, and
there will be no incentive to restrict firewall openings to
the minimum width necessary.  Christian Huitema repeated his
point that this was a policy issue which should not be
settled in advance by the protocol.

Bob Penfield argued that the key point is that the agent
needs to handle the two directions of media flow separately.
Reservation is appropriate for the outgoing direction, but
wildcarding is required for the incoming flow --
particularly since the source of early media can differ from
the source of media sent after answer.

5. Wrapup
=========

The Chair terminated discussion at this point, as the
meeting time had expired.  As usual with MIDCOM, there will
be discussions with the IESG on how to proceed.
_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C2F959.ABF0BB22-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Apr 2 16:04:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09114 for ; Wed, 2 Apr 2003 16:04:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32LSdg18306 for midcom-archive@odin.ietf.org; Wed, 2 Apr 2003 16:28:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LS8K18188; Wed, 2 Apr 2003 16:28:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LJiK17580 for ; Wed, 2 Apr 2003 16:19:44 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08797 for ; Wed, 2 Apr 2003 15:54:48 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32Kv5o11534; Wed, 2 Apr 2003 14:57:05 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 14:57:06 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABC1F@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Melinda Shore'" , "'midcom@ietf.org'" Subject: RE: [midcom] Draft minutes from IETF 56 Date: Wed, 2 Apr 2003 14:57:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F95A.6A3807E8" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F95A.6A3807E8 Content-Type: text/plain; charset="iso-8859-1" Well, it would be nice if I'd enter some content to the email (sticky fingers and impatient person). I just noticed an error in the minutes on the protocol evaluation. It's stated that: "The protocol evaluation document is scheduled to be through WG last call in May 2003, and we appear to be on schedule." I think this should read: "The protocol evaluation document has been approved by the IESG and is in the RFC Editor's Queue." Mary. ---deleting the rest so I don't send that twice---- ------_=_NextPart_001_01C2F95A.6A3807E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Draft minutes from IETF 56

Well, it would be nice if I'd enter some content to = the email (sticky fingers and impatient person). I just noticed an = error in the minutes on the protocol evaluation.  It's stated = that:

"The protocol evaluation document is scheduled = to be through
WG last call in May 2003, and we appear to be on = schedule."

I think this should read:
"The protocol evaluation document has been = approved by the IESG and is in the RFC Editor's Queue."

Mary.

---deleting the rest so I don't send that = twice----

------_=_NextPart_001_01C2F95A.6A3807E8-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sun Apr 6 23:36:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12900 for ; Sun, 6 Apr 2003 23:36:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h373ewk25545 for midcom-archive@odin.ietf.org; Sun, 6 Apr 2003 23:40:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h373dS825495; Sun, 6 Apr 2003 23:39:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h373bs825466 for ; Sun, 6 Apr 2003 23:37:54 -0400 Received: from pop017.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12873 for ; Sun, 6 Apr 2003 23:33:23 -0400 (EDT) Received: from crunch ([68.160.21.88]) by pop017.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030407033554.LBCA1817.pop017.verizon.net@crunch> for ; Sun, 6 Apr 2003 22:35:54 -0500 Content-Type: text/plain; charset="us-ascii" From: Bryan Ford Organization: Massachusetts Institute of Technology To: midcom@ietf.org Date: Sun, 6 Apr 2003 23:35:53 -0400 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200304062335.53598.baford@mit.edu> X-Authentication-Info: Submitted using SMTP AUTH at pop017.verizon.net from [68.160.21.88] at Sun, 6 Apr 2003 22:35:53 -0500 Content-Transfer-Encoding: 8bit Subject: [midcom] Internet Draft on NAT/P2P Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear MIDCOM Group, While doing some P2P research, I found myself falling into the dark pit of NAT/P2P interaction issues, and decided to try to collect and consolidate all the relevant information I could find "out there" about this problem. Since it appears no one has done this yet (although several helpful starts have been made by others), I wrote up an Internet Draft on the topic, with the tentative plan of publishing it in the near future as an Informational RFC. The intent of the draft is not to propose any new protocols, but merely to summarize current knowledge about making P2P applications work with NAT in the absence of explicit proxy protocols like MIDCOM. You will probably not find anything new or surprising here, but nevertheless I would greatly appreciate if you could take the time to look it over and give me comments, ideas, additional information I missed, or any other feedback you might have. The draft is available on my "NAT Check" web page: http://www.pdos.lcs.mit.edu/~baford/nat/ ...or at the direct link: http://www.pdos.lcs.mit.edu/~baford/nat/draft-ford-natp2p-00.txt Thank you very much, Bryan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom