From mailnull@www1.ietf.org Thu Jan 2 00:07:46 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 AAA18982 for ; Thu, 2 Jan 2003 00:07:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h025FrC14776 for midcom-archive@odin.ietf.org; Thu, 2 Jan 2003 00:15:53 -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 h025FQJ14753; Thu, 2 Jan 2003 00:15:26 -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 h025EwJ14717 for ; Thu, 2 Jan 2003 00:14:58 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18912 for ; Thu, 2 Jan 2003 00:06:15 -0500 (EST) Received: from fordcl1163 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H820090PM8PXF@mta0.huawei.com> for midcom@ietf.org; Thu, 02 Jan 2003 13:07:39 +0800 (CST) Date: Thu, 02 Jan 2003 10:42:09 +0530 From: ford To: midcom@ietf.org Message-id: <000001c2b21d$80ff5cd0$5403120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/alternative; boundary="Boundary_(ID_fAHyCDf1rPjFXMJxIbYM3Q)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [midcom] The standard for MIDCOM 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 is a multi-part message in MIME format. --Boundary_(ID_fAHyCDf1rPjFXMJxIbYM3Q) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Dear All: For MIDCOM, although it is deciede to use SNMPV3 as MIDCOM protocol, but there is no guideline on how to use SNMPV3 to control the NAT. draft-stiemerling- midcom-simco-02.txt give the details on how to use this SIMCO as MIDCOM protocol. Could anyone give some guideline on how to use SNMPV3 as MIDCOM? If there is no, I think SIMCO is a good protocol to work as MIDCOM protocol.I can not understand why not choose this as standard, which satifies the requirements for MIDCOM protocol. I am looking forwards to getting your idea as soon as possible!! Thanks in advance!! Best regards! Yours: Cheng --Boundary_(ID_fAHyCDf1rPjFXMJxIbYM3Q) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT

   Dear All:
     For MIDCOM, although it is deciede to use SNMPV3 as MIDCOM protocol,
but there is no guideline on how to use SNMPV3 to control the NAT.  draft-stiemerling-
midcom-simco-02.txt give the details on how to use this SIMCO as MIDCOM protocol.


     Could anyone give some guideline on how to use SNMPV3 as MIDCOM? If there is no,
I think SIMCO is a good protocol to work as MIDCOM protocol.I can not understand why
not choose this as standard, which satifies the requirements for MIDCOM protocol.


     I am looking forwards to getting your idea as soon as possible!!


     Thanks in advance!!
     Best regards!
                                     Yours: Cheng
 

--Boundary_(ID_fAHyCDf1rPjFXMJxIbYM3Q)-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Jan 2 10:28:22 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 KAA06439 for ; Thu, 2 Jan 2003 10:28:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02FafK31031 for midcom-archive@odin.ietf.org; Thu, 2 Jan 2003 10:36:41 -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 h02FZqJ30997; Thu, 2 Jan 2003 10:35:52 -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 h02FYuJ30961 for ; Thu, 2 Jan 2003 10:34:56 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06418 for ; Thu, 2 Jan 2003 10:26:06 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id h02FTCKv013665; Thu, 2 Jan 2003 07:29:12 -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 ABT27883; Thu, 2 Jan 2003 07:29:11 -0800 (PST) Message-Id: <200301021529.ABT27883@mira-sjc5-c.cisco.com> To: ford cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] The standard for MIDCOM In-Reply-To: Message from chengzhengqun@huawei.com of "Thu, 02 Jan 2003 10:42:09 +0530." <000001c2b21d$80ff5cd0$5403120a@in.huawei.com> Date: Thu, 02 Jan 2003 10:29:10 -0500 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: , We haven't yet published a midcom MIB. I'm currently waiting for some guidance from our ADs before we can proceed. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Jan 2 18:56:48 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 SAA17256 for ; Thu, 2 Jan 2003 18:56:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0305Il01004 for midcom-archive@odin.ietf.org; Thu, 2 Jan 2003 19:05:18 -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 h0304TJ00949; Thu, 2 Jan 2003 19:04:29 -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 h02NeWJ32333 for ; Thu, 2 Jan 2003 18:40:32 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16899; Thu, 2 Jan 2003 18:31:32 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H84008JI1HU5L@firewall.wcom.com>; Thu, 02 Jan 2003 23:34:43 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H8400F011HURV@pmismtp02.wcomnet.com>; Thu, 02 Jan 2003 23:34:42 +0000 (GMT) Received: from hsinnreich2 ([166.42.41.19]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H8400DCP1HSJ2@pmismtp02.wcomnet.com>; Thu, 02 Jan 2003 23:34:42 +0000 (GMT) Date: Thu, 02 Jan 2003 17:34:40 -0600 From: Henry Sinnreich To: sipping@ietf.org, midcom@ietf.org Message-id: <000601c2b2b7$864567d0$13292aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [midcom] UPnP and routing updates for SIPPING and MIDCOM I-Ds 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: 7bit There is quite a bit of excellent work reflected in all the SIPPING and MIDCOM I-Ds on NAT and Firewall traversal and some solutions, such as STUN and TURN. I believe we need however also updated versions of this work by enlarging the focus with some other aspects. Here are two examples that come to my mind, there may be other: UPnP Commercial UPnP residential gateways allow UPnP enabled SIP UA to function well, examples are commercial wired NAT/FWs and wireless access points working with some well known softphone clients and SIP phones. Please see for reference: http://upnp.org/resources/whitepapers.asp After experiencing the true "plug-and-play" nature of the UPnP solution, I happen to believe it is also a valid enterprise approach as well and the I-Ds should consider such an enterprise scenario for outsourced and enterprise services. UPnP gateways have a wider application area since they will also support collaboration applications that may not be SIP based, appliances, etc. Along this rationale SIP phones MUST support UPnP, I believe, see http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt . Some SIP phones already support UPnP. Both the MIDCOM and Sipping WGs need to come to grips with the reality of the excellent work done by the UPnP people and document it in an informational RFC IMHO. Is the architecture as IP-centric and good as it seems? Are there any issues, such as scalability or security? It appears UPnP has solved much of the MIDCOM problem space. Ignoring UPnP by the IETF is not a good option. Routing Solutions in most recent I-D have a single NAT/FW - this often an unacceptable single point of failure. The drafts need to show solutions with multiple NAT/FW locations and the routing implications, since all internal routers need to be aware of the NAT/FWs at the edge of the enterprise network. Should this be reflected in updates to the charter of the SIPPING and MIDCOM WGs as well? What do you think? Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Jan 3 10:47:07 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 KAA11389 for ; Fri, 3 Jan 2003 10:47:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03FtwG01358 for midcom-archive@odin.ietf.org; Fri, 3 Jan 2003 10:55:58 -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 h03FtKJ01311; Fri, 3 Jan 2003 10:55:20 -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 h03FqUJ01174 for ; Fri, 3 Jan 2003 10:52:30 -0500 Received: from smtp013.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11234 for ; Fri, 3 Jan 2003 10:43:08 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Jan 2003 15:46:21 -0000 Reply-To: From: "Pyda Srisuresh" To: "ford" , Subject: RE: [midcom] The standard for MIDCOM Date: Fri, 3 Jan 2003 07:49:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C2B2FC.B14C1010" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <000001c2b21d$80ff5cd0$5403120a@in.huawei.com> 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 is a multi-part message in MIME format. ------=_NextPart_000_0054_01C2B2FC.B14C1010 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit SNMP v3 protocol and its use is well-defined. However, MIB for a middlebox device is not as well defined and needs confirmation as to whether a MIB is adequate for MIDCOM. Perhaps, you could take a look at draft-ietf-nat-natmib-05.txt, view this from the MIDCOM perspective for a NAT middlebox device, and let us know what might be missing for MIDCOM. Thanks. regards, suresh -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of ford Sent: Wednesday, January 01, 2003 9:12 PM To: midcom@ietf.org Subject: [midcom] The standard for MIDCOM Dear All: For MIDCOM, although it is deciede to use SNMPV3 as MIDCOM protocol, but there is no guideline on how to use SNMPV3 to control the NAT. draft-stiemerling- midcom-simco-02.txt give the details on how to use this SIMCO as MIDCOM protocol. Could anyone give some guideline on how to use SNMPV3 as MIDCOM? If there is no, I think SIMCO is a good protocol to work as MIDCOM protocol.I can not understand why not choose this as standard, which satifies the requirements for MIDCOM protocol. I am looking forwards to getting your idea as soon as possible!! Thanks in advance!! Best regards! Yours: Cheng ------=_NextPart_000_0054_01C2B2FC.B14C1010 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
SNMP=20 v3 protocol and its use is well-defined.
 
However, MIB for a middlebox device is not as well=20 defined and needs
confirmation as to whether a MIB is adequate for=20 MIDCOM. Perhaps,
you=20 could take a look at  draft-ietf-nat-natmib-05.txt, view this=20 from
the=20 MIDCOM perspective for a NAT middlebox device, and let us know=20 what 
might=20 be missing for MIDCOM. Thanks.
 
regards,
suresh 
 
-----Original Message-----
From: = midcom-admin@ietf.org=20 [mailto:midcom-admin@ietf.org]On Behalf Of ford
Sent: = Wednesday, January 01, 2003 9:12 PM
To:=20 midcom@ietf.org
Subject: [midcom] The standard for=20 MIDCOM

   Dear All:
     For MIDCOM, = although it=20 is deciede to use SNMPV3 as MIDCOM protocol,
but there is no = guideline on=20 how to use SNMPV3 to control the NAT. =20 draft-stiemerling-
midcom-simco-02.txt give the details on how to = use this=20 SIMCO as MIDCOM protocol.


     Could anyone give some guideline on = how to use=20 SNMPV3 as MIDCOM? If there is no,
I think SIMCO is a good protocol = to work=20 as MIDCOM protocol.I can not understand why
not choose this as = standard,=20 which satifies the requirements for MIDCOM protocol.


     I am looking forwards to getting your = idea as=20 soon as possible!!


     Thanks in=20 advance!!
     Best=20 = regards!
          &= nbsp;           &n= bsp;           &nb= sp; =20 Yours: Cheng
 

------=_NextPart_000_0054_01C2B2FC.B14C1010-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sun Jan 5 12:10:20 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 MAA08171 for ; Sun, 5 Jan 2003 12:10:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05HK9X10218 for midcom-archive@odin.ietf.org; Sun, 5 Jan 2003 12:20:09 -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 h05HJZJ10134; Sun, 5 Jan 2003 12:19:35 -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 h05H3vJ09165 for ; Sun, 5 Jan 2003 12:03:57 -0500 Received: from smtp012.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07928 for ; Sun, 5 Jan 2003 11:53:36 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 Jan 2003 16:56:50 -0000 Reply-To: From: "Pyda Srisuresh" To: "Melinda Shore" Cc: Subject: RE: [midcom] The standard for MIDCOM Date: Sun, 5 Jan 2003 09:00:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <200301021529.ABT27883@mira-sjc5-c.cisco.com> Content-Transfer-Encoding: 7bit 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: 7bit Melinda, By midcom MIB, did you mean individual MIBs for the middlebox functions - i.e., NAT MIB, firewall MIB etc.? If you meant something different, please explain. Thanks. regards, suresh > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Melinda Shore > Sent: Thursday, January 02, 2003 7:29 AM > To: ford > Cc: midcom@ietf.org > Subject: Re: [midcom] The standard for MIDCOM > > > We haven't yet published a midcom MIB. I'm currently > waiting for some guidance from our ADs before we can > proceed. > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Jan 6 15:34:17 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 PAA14102 for ; Mon, 6 Jan 2003 15:34:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06Kidd12895 for midcom-archive@odin.ietf.org; Mon, 6 Jan 2003 15:44: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 h06KdfJ12618; Mon, 6 Jan 2003 15:39:41 -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 h06Ka5J11895 for ; Mon, 6 Jan 2003 15:36:05 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13913 for ; Mon, 6 Jan 2003 15:25:12 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h06KSWfm025164; Mon, 6 Jan 2003 12:28:32 -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 ABV12108; Mon, 6 Jan 2003 12:28:23 -0800 (PST) Message-Id: <200301062028.ABV12108@mira-sjc5-c.cisco.com> To: srisuresh@yahoo.com cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] The standard for MIDCOM In-Reply-To: Message from srisuresh@yahoo.com of "Sun, 05 Jan 2003 09:00:11 PST." Date: Mon, 06 Jan 2003 15:28:23 -0500 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: , > By midcom MIB, did you mean individual MIBs > for the middlebox functions - i.e., NAT MIB, > firewall MIB etc.? If you meant something > different, please explain. Thanks. That question is still open - this working group hasn't published any MIB midcom protocol. Whether or not the NAT MIB is suitable for midcom is something that needs evaluation. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Jan 8 09:04:25 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 JAA20097 for ; Wed, 8 Jan 2003 09:04:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08EFdj24034 for midcom-archive@odin.ietf.org; Wed, 8 Jan 2003 09:15: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 h08EAoJ23784; Wed, 8 Jan 2003 09:10:50 -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 h08E34J22849 for ; Wed, 8 Jan 2003 09:03:04 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19767 for ; Wed, 8 Jan 2003 08:51:18 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h08DsYFp003838 for ; Wed, 8 Jan 2003 05:54:34 -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 ABW42830; Wed, 8 Jan 2003 05:54:33 -0800 (PST) Message-Id: <200301081354.ABW42830@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 08 Jan 2003 08:54:32 -0500 Subject: [midcom] Design team announcement 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: , We've created a design team to tackle putting together a midcom MIB. The decision was made to keep the design team very small so that it will be able to work as quickly as reasonable - we are under time pressures. Their first tasks will be to come up with a deliverables schedule and to examine the NAT MIB for its applicability to midcom. The design team members are Mary Barnes (mbarnes@nortelnetworks.com), Martin Stiemerling (martin@ccrle.nec.de), and David Harrington (dbh@enterasys.com). Mary will be holding the leadership/editor token. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Jan 8 10:36:09 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 KAA22599 for ; Wed, 8 Jan 2003 10:36:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08FlO230325 for midcom-archive@odin.ietf.org; Wed, 8 Jan 2003 10:47:24 -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 h08FgHJ30060; Wed, 8 Jan 2003 10:42:17 -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 h08FfEJ29956 for ; Wed, 8 Jan 2003 10:41:14 -0500 Received: from smtp018.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22313 for ; Wed, 8 Jan 2003 10:29:28 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Jan 2003 15:32:42 -0000 Reply-To: From: "Pyda Srisuresh" To: "Melinda Shore" , Subject: RE: [midcom] Design team announcement Date: Wed, 8 Jan 2003 07:35:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <200301081354.ABW42830@mira-sjc5-c.cisco.com> Content-Transfer-Encoding: 7bit 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: 7bit Melinda, I understand, the WG had decided on SNMPv3 as the MIDCOM protocol. What specifically are we looking for in a single MIDCOM MIB, as opposed to a MIB for each of NAT and firewall? It is hard enough to develop a good firewall MIB, or NAT MIB, let alone combine both into one. As the design team is set up to look at the applicability of the NAT MIB draft for MIDCOM, I believe, one of the draft authors should also be a member of the design team. Do let us know, if you believe otherwise. Thanks. regards, suresh > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Melinda Shore > Sent: Wednesday, January 08, 2003 5:55 AM > To: midcom@ietf.org > Subject: [midcom] Design team announcement > > > We've created a design team to tackle putting together a > midcom MIB. The decision was made to keep the design team > very small so that it will be able to work as quickly as > reasonable - we are under time pressures. Their first tasks > will be to come up with a deliverables schedule and to > examine the NAT MIB for its applicability to midcom. > > The design team members are Mary Barnes > (mbarnes@nortelnetworks.com), Martin Stiemerling > (martin@ccrle.nec.de), and David Harrington > (dbh@enterasys.com). Mary will be holding the > leadership/editor token. > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Jan 8 11:00:01 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 LAA23118 for ; Wed, 8 Jan 2003 11:00:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08GBGW32012 for midcom-archive@odin.ietf.org; Wed, 8 Jan 2003 11:11:16 -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 h08GAQJ31969; Wed, 8 Jan 2003 11:10:26 -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 h08G9iJ31913 for ; Wed, 8 Jan 2003 11:09:44 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23035 for ; Wed, 8 Jan 2003 10:57:57 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id h08G1CKv002965; Wed, 8 Jan 2003 08:01:12 -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 ABW48165; Wed, 8 Jan 2003 08:01:05 -0800 (PST) Message-Id: <200301081601.ABW48165@mira-sjc5-c.cisco.com> To: srisuresh@yahoo.com cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Design team announcement In-Reply-To: Message from srisuresh@yahoo.com of "Wed, 08 Jan 2003 07:35:51 PST." Date: Wed, 08 Jan 2003 11:01:05 -0500 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: , It may very well be the case that two separate MIBs are appropriate, which is why the design team's second task (after establishing a deliverables schedule) is to examine the NAT MIB for its applicability to midcom. We're very fortunate to have David Harrington, plus possibly additional MIB specialists, involved, lending expertise in sound MIB design, performance, security, and so on. We're trying to keep the design team as small and effective as possible (we need to get this done quickly) and we need to keep partisanship on the design team to a minimum. I think this design team has an excellent combination of skills and a solid track record of getting work done. Also, for those who haven't read the IESG statement on design teams, please do. It's important to understand that the design team is going to be providing input to the working group and is not weighted more heavily than other input to the working group. Decisions about the working group products (documents) are made by the working group, not the design team. The URL is: http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Jan 8 11:18:10 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 LAA23579 for ; Wed, 8 Jan 2003 11:18:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08GTPP00509 for midcom-archive@odin.ietf.org; Wed, 8 Jan 2003 11:29:25 -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 h08GSNJ00457; Wed, 8 Jan 2003 11:28:23 -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 h08GR9J00396 for ; Wed, 8 Jan 2003 11:27:09 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23529 for ; Wed, 8 Jan 2003 11:15:22 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA16003 for ; Wed, 8 Jan 2003 11:31:02 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma015513; Wed, 8 Jan 03 11:28:54 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Wed, 08 Jan 2003 11:16:42 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 8 Jan 2003 11:16:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] Design team announcement Date: Wed, 8 Jan 2003 11:16:42 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA48933B@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] Design team announcement Thread-Index: AcK3LH9MK/yNqymRSzmtGF8hB598zQAA7Qyw From: "Harrington, David" To: , "Melinda Shore" , X-OriginalArrivalTime: 08 Jan 2003 16:16:42.0721 (UTC) FILETIME=[55011510:01C2B731] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08GR9J00397 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 Hi, I don't believe anybody has stated that there will be just one mib. As the member of the design team with probably the most experience with mibs, I certainly would not recommend that approach. It is my intention to recommend to the design team that we look closely at existing mibs rather than developing new mibs that would duplicate existing mib functionality, and only write new mibs to tie existing mib functionality together for MIDCOM purposes. Hopefully, there will be little need for new mibs. It would be my intention to seek out the authors of various existing mibs and to work closely with them to understand the "philosophies" behind their designs and how they compare to MIDCOM needs. I am not convinced that the authors of the existing mibs we might consider should necessarily be part of the design team; that could add significant bias to the discussions. dbh --- David Harrington dbh@enterasys.com co-chair, IETF SNMPv3 WG > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Wednesday, January 08, 2003 10:36 AM > To: Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] Design team announcement > > > Melinda, > > I understand, the WG had decided on SNMPv3 as the MIDCOM > protocol. > > What specifically are we looking for in a single MIDCOM > MIB, as opposed to a MIB for each of NAT and firewall? > It is hard enough to develop a good firewall MIB, or NAT MIB, > let alone combine both into one. > > As the design team is set up to look at the applicability > of the NAT MIB draft for MIDCOM, I believe, one of the draft > authors should also be a member of the design team. Do let us > know, if you believe otherwise. Thanks. > > regards, > suresh > > > -----Original Message----- > > From: midcom-admin@ietf.org > [mailto:midcom-admin@ietf.org]On Behalf Of > > Melinda Shore > > Sent: Wednesday, January 08, 2003 5:55 AM > > To: midcom@ietf.org > > Subject: [midcom] Design team announcement > > > > > > We've created a design team to tackle putting together a > > midcom MIB. The decision was made to keep the design team > > very small so that it will be able to work as quickly as > > reasonable - we are under time pressures. Their first tasks > > will be to come up with a deliverables schedule and to > > examine the NAT MIB for its applicability to midcom. > > > > The design team members are Mary Barnes > > (mbarnes@nortelnetworks.com), Martin Stiemerling > > (martin@ccrle.nec.de), and David Harrington > > (dbh@enterasys.com). Mary will be holding the > > leadership/editor token. > > > > Melinda > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Jan 8 11:31:56 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 LAA23995 for ; Wed, 8 Jan 2003 11:31:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08GhCN02059 for midcom-archive@odin.ietf.org; Wed, 8 Jan 2003 11:43:12 -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 h08GglJ01996; Wed, 8 Jan 2003 11:42:47 -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 h08GfbJ01849 for ; Wed, 8 Jan 2003 11:41:37 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23867 for ; Wed, 8 Jan 2003 11:29:49 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08GWsT18170; Wed, 8 Jan 2003 11:32:54 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:32:55 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E10E@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'srisuresh@yahoo.com'" , Melinda Shore , midcom@ietf.org Subject: RE: [midcom] Design team announcement Date: Wed, 8 Jan 2003 11:32:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B733.969A87C0" 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_01C2B733.969A87C0 Content-Type: text/plain IMHO we should be looking for a MIB that implements the semantics (which, BTW, need updating particularly with regard to policy rule groups). The underlying data structures will probably be common with the NAT or firewall MIB, but the MIDCOM MIB itself need not reflect anything the Agent shouldn't see. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Wednesday, January 08, 2003 10:36 AM > To: Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] Design team announcement > > > Melinda, > > I understand, the WG had decided on SNMPv3 as the MIDCOM protocol. > > What specifically are we looking for in a single MIDCOM > MIB, as opposed to a MIB for each of NAT and firewall? > It is hard enough to develop a good firewall MIB, or NAT MIB, > let alone combine both into one. > > As the design team is set up to look at the applicability > of the NAT MIB draft for MIDCOM, I believe, one of the draft > authors should also be a member of the design team. Do let us > know, if you believe otherwise. Thanks. > > regards, > suresh > > > -----Original Message----- > > From: midcom-admin@ietf.org > [mailto:midcom-admin@ietf.org]On Behalf Of > > Melinda Shore > > > Sent: Wednesday, January 08, 2003 5:55 AM > > To: midcom@ietf.org > > Subject: [midcom] Design team announcement > > > > > > We've created a design team to tackle putting together a > midcom MIB. > > The decision was made to keep the design team very small so that it > > will be able to work as quickly as reasonable - we are under time > > pressures. Their first tasks will be to come up with a > deliverables > > schedule and to examine the NAT MIB for its applicability to midcom. > > > > The design team members are Mary Barnes > (mbarnes@nortelnetworks.com), > > Martin Stiemerling (martin@ccrle.nec.de), and David Harrington > > (dbh@enterasys.com). Mary will be holding the > > leadership/editor token. > > > > Melinda > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C2B733.969A87C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Design team announcement

IMHO we should be looking for a MIB that implements = the semantics (which, BTW, need updating particularly with regard to = policy rule groups).  The underlying data structures will probably = be common with the NAT or firewall MIB, but the MIDCOM MIB itself need = not reflect anything the Agent shouldn't see.

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] =
> Sent: Wednesday, January 08, 2003 10:36 = AM
> To: Melinda Shore; midcom@ietf.org
> Subject: RE: [midcom] Design team = announcement
>
>
> Melinda,
>
> I understand, the WG had decided on SNMPv3 as = the MIDCOM protocol.
>
> What specifically are we looking for in a = single MIDCOM
> MIB, as opposed to a MIB for each of NAT and = firewall?
> It is hard enough to develop a good firewall = MIB, or NAT MIB,
> let alone combine both into one.
>
> As the design team is set up to look at the = applicability
> of the NAT MIB draft for MIDCOM, I believe, one = of the draft
> authors should also be a member of the design = team. Do let us
> know, if you believe otherwise. Thanks.
>
> regards,
> suresh 
>
> > -----Original Message-----
> > From: midcom-admin@ietf.org
> [mailto:midcom-admin@ietf.org]O= n Behalf Of
> > Melinda Shore
> >
> Sent: Wednesday, January 08, 2003 5:55 = AM
> > To: midcom@ietf.org
> > Subject: [midcom] Design team = announcement
> >
> >
> > We've created a design team to tackle = putting together a
> midcom MIB. 
> > The decision was made to keep the design = team very small so that it
> > will be able to work as quickly as = reasonable - we are under time
> > pressures.  Their first tasks will be = to come up with a
> deliverables
> > schedule and to examine the NAT MIB for = its applicability to midcom.
> >
> > The design team members are Mary Barnes =
> (mbarnes@nortelnetworks.com),
> > Martin Stiemerling (martin@ccrle.nec.de), = and David Harrington
> > (dbh@enterasys.com).  Mary will be = holding the
> > leadership/editor token.
> >
> > Melinda
> > = _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > https://www1.ietf.org/mailman/listinfo/midcom
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C2B733.969A87C0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Jan 8 12:31:37 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 MAA27123 for ; Wed, 8 Jan 2003 12:31:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Hgti06847 for midcom-archive@odin.ietf.org; Wed, 8 Jan 2003 12:42:55 -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 h08HfUJ06776; Wed, 8 Jan 2003 12:41:30 -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 h08HerJ06745 for ; Wed, 8 Jan 2003 12:40:53 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27035 for ; Wed, 8 Jan 2003 12:29:03 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h08HW4R21880; Wed, 8 Jan 2003 18:32:04 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 377D662693; Wed, 8 Jan 2003 19:31:32 +0100 (CET) Date: Wed, 08 Jan 2003 18:45:05 +0100 From: Juergen Quittek To: srisuresh@yahoo.com, Melinda Shore , midcom@ietf.org Subject: RE: [midcom] Design team announcement Message-ID: <31747780.1042051504@[10.1.1.128]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: 7bit Suresh, -- Pyda Srisuresh wrote on 08 January 2003 07:35 -0800: > Melinda, > > I understand, the WG had decided on SNMPv3 as the MIDCOM > protocol. > > What specifically are we looking for in a single MIDCOM > MIB, as opposed to a MIB for each of NAT and firewall? > It is hard enough to develop a good firewall MIB, or NAT MIB, > let alone combine both into one. > > As the design team is set up to look at the applicability > of the NAT MIB draft for MIDCOM, I believe, one of the draft > authors should also be a member of the design team. Do let us > know, if you believe otherwise. Thanks. I agree. Some time ago, I did a brief review of the NAT MIB with respect to the MIDCOM requirements and it would have been hard without support from the MIB authors. At least for the first task of the design team (evaluating the NAT IB module) progress would probably be much better if one of the authors participated. Juergen > regards, > suresh > >> -----Original Message----- >> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of >> Melinda Shore >> Sent: Wednesday, January 08, 2003 5:55 AM >> To: midcom@ietf.org >> Subject: [midcom] Design team announcement >> >> >> We've created a design team to tackle putting together a >> midcom MIB. The decision was made to keep the design team >> very small so that it will be able to work as quickly as >> reasonable - we are under time pressures. Their first tasks >> will be to come up with a deliverables schedule and to >> examine the NAT MIB for its applicability to midcom. >> >> The design team members are Mary Barnes >> (mbarnes@nortelnetworks.com), Martin Stiemerling >> (martin@ccrle.nec.de), and David Harrington >> (dbh@enterasys.com). Mary will be holding the >> leadership/editor token. >> >> Melinda >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Jan 8 12:35:41 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 MAA27350 for ; Wed, 8 Jan 2003 12:35:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Hkwg07192 for midcom-archive@odin.ietf.org; Wed, 8 Jan 2003 12:46:58 -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 h08HkGJ07164; Wed, 8 Jan 2003 12:46:16 -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 h08Hj9J07104 for ; Wed, 8 Jan 2003 12:45:09 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27299 for ; Wed, 8 Jan 2003 12:33:20 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h08HaHR21937; Wed, 8 Jan 2003 18:36:17 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0C5B776FDC; Wed, 8 Jan 2003 19:35:45 +0100 (CET) Date: Wed, 08 Jan 2003 18:49:18 +0100 From: Juergen Quittek To: Tom-PT Taylor , "'srisuresh@yahoo.com'" , Melinda Shore , midcom@ietf.org Subject: RE: [midcom] Design team announcement Message-ID: <32001015.1042051758@[10.1.1.128]> In-Reply-To: <4D79C746863DD51197690002A52CDA000400E10E@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA000400E10E@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: 7bit Tom, I share your concern, but I am not sure about it. Now it is the task of the design team - after studying the NAT MIB - to come to this conclusion or to recommend to build on top of the NAT MIB. Juergen -- Tom-PT Taylor wrote on 08 January 2003 11:32 -0500: > IMHO we should be looking for a MIB that implements the semantics (which, > BTW, need updating particularly with regard to policy rule groups). The > underlying data structures will probably be common with the NAT or firewall > MIB, but the MIDCOM MIB itself need not reflect anything the Agent shouldn't > see. > >> -----Original Message----- >> From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] >> Sent: Wednesday, January 08, 2003 10:36 AM >> To: Melinda Shore; midcom@ietf.org >> Subject: RE: [midcom] Design team announcement >> >> >> Melinda, >> >> I understand, the WG had decided on SNMPv3 as the MIDCOM protocol. >> >> What specifically are we looking for in a single MIDCOM >> MIB, as opposed to a MIB for each of NAT and firewall? >> It is hard enough to develop a good firewall MIB, or NAT MIB, >> let alone combine both into one. >> >> As the design team is set up to look at the applicability >> of the NAT MIB draft for MIDCOM, I believe, one of the draft >> authors should also be a member of the design team. Do let us >> know, if you believe otherwise. Thanks. >> >> regards, >> suresh >> >> > -----Original Message----- >> > From: midcom-admin@ietf.org >> [mailto:midcom-admin@ietf.org]On Behalf Of >> > Melinda Shore >> > >> Sent: Wednesday, January 08, 2003 5:55 AM >> > To: midcom@ietf.org >> > Subject: [midcom] Design team announcement >> > >> > >> > We've created a design team to tackle putting together a >> midcom MIB. >> > The decision was made to keep the design team very small so that it >> > will be able to work as quickly as reasonable - we are under time >> > pressures. Their first tasks will be to come up with a >> deliverables >> > schedule and to examine the NAT MIB for its applicability to midcom. >> > >> > The design team members are Mary Barnes >> (mbarnes@nortelnetworks.com), >> > Martin Stiemerling (martin@ccrle.nec.de), and David Harrington >> > (dbh@enterasys.com). Mary will be holding the >> > leadership/editor token. >> > >> > Melinda >> > _______________________________________________ >> > midcom mailing list >> > midcom@ietf.org >> > https://www1.ietf.org/mailman/listinfo/midcom >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Jan 9 08:02:10 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 IAA08450 for ; Thu, 9 Jan 2003 08:02:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09DDp021765 for midcom-archive@odin.ietf.org; Thu, 9 Jan 2003 08:13:51 -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 h09DDRJ21748; Thu, 9 Jan 2003 08:13:27 -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 h09DCQJ21719 for ; Thu, 9 Jan 2003 08:12:26 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08421 for ; Thu, 9 Jan 2003 08:00:13 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09D3Sw29072 for ; Thu, 9 Jan 2003 08:03:28 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 08:03:28 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E11C@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: midcom@ietf.org Date: Thu, 9 Jan 2003 08:03:26 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] (no subject) 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'd like to correct what I believe was a false impression left before Christmas, regarding the requirements for access control for MIDCOM objects. IMHO the critical issue is NOT mutual exclusion. After all, the worst that can happen is that one Agent deletes a policy rule for which another agent is trying to extend the lifetime. This is just as much of a mess if it happens sequentially as it would be if it happens simultaneously in some fashion, and points up a (non-MIDCOM) requirement for behind-the-scenes coordination between Agents. The critical requirement instead is that once a policy rule has been created, the only part that the Agent can change is the requested lifetime. Assuming the Agent has the authority, it can read a policy rule and it can delete it, but it cannot change its component parts. Turning from access to another topic, the part that will need careful handling is the reserved address sub-object. Depending on the function of the Middlebox, this contains zero, one, or two addresses. This sub-object can either be created in advance through a reserve operation, or created simultaneously with the rest of the policy rule. When the policy rule is instantiated, the reserved address sub-object becomes bound to it. The question is what key to use for the reserved address sub-object when it is created in advance. One possibility is to think of it as one component of a policy rule whose other components have yet to be set. Coming back to access, I am wondering what restrictions we should impose so the reserved address sub-object is not hijacked between the time of reservation and the time of policy rule instantiation. One final point, probably nothing to do with access: the obvious key for a policy rule is the combination of the creating Agent's identity and the Middlebox-generated policy rule identifier. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Jan 10 12:29:46 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 MAA04752 for ; Fri, 10 Jan 2003 12:29:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AHg2M16390 for midcom-archive@odin.ietf.org; Fri, 10 Jan 2003 12:42:02 -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 h0AHfEJ16341; Fri, 10 Jan 2003 12:41:14 -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 h0AHduJ16264 for ; Fri, 10 Jan 2003 12:39:56 -0500 Received: from dnsmx1rrc.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04654 for ; Fri, 10 Jan 2003 12:27:06 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA11815 for ; Fri, 10 Jan 2003 12:29:45 -0500 (EST) To: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Fri, 10 Jan 2003 12:34:22 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 01/10/2003 12:29:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] STUN 05 - clarification 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: , greetings, can someone clarify the following sentence in draft-ietf-midcom-stun-05? Section 8.1, page 14 the paragraph before the last paragraph: "If the username present in the request was not allocated using a Shared Secret Request, the REFLECTED-FROM attribute MUST contain the source address and port of the entity which obtained the username, as best can be verified with the mechanism used to allocate the username." How we can assert which entity obtained the username? Can someone give an example? What does it mean "as best can be verified with the mechanism used to allocate the username"? If the username was not assigned by the respective STUN server that handles the request how it can verify the username (besides performing another message exchange with another STUN server which presumably assigned the username, which may require additional authentication )? Thanks for your help Peter _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Jan 11 22:52:46 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 WAA24132 for ; Sat, 11 Jan 2003 22:52:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0C45iX29222 for midcom-archive@odin.ietf.org; Sat, 11 Jan 2003 23:05:44 -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 h0C454J29201; Sat, 11 Jan 2003 23:05:04 -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 h0C43VJ29171 for ; Sat, 11 Jan 2003 23:03:31 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24099 for ; Sat, 11 Jan 2003 22:50:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.152]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0C3rKYH029253; Sat, 11 Jan 2003 22:53:20 -0500 (EST) Message-ID: <3E20E6AD.7090101@dynamicsoft.com> Date: Sat, 11 Jan 2003 22:53:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Panayiotis A. Thermos" CC: midcom@ietf.org Subject: Re: [midcom] STUN 05 - clarification References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: 7bit inline. Panayiotis A. Thermos wrote: > greetings, > > can someone clarify the following sentence in draft-ietf-midcom-stun-05? > > Section 8.1, page 14 the paragraph before the last paragraph: > > "If the username present in the request was not allocated using a Shared > Secret Request, the REFLECTED-FROM attribute MUST contain the > source address and port of the entity which obtained the username, > as best can be verified with the mechanism used to allocate the username." > > How we can assert which entity obtained the username? It depends on the mecahnism used to allocate them. For example, if its kerberos, then the IP address of the entity to which the ticket was granted will suffice. > Can someone give an example? See above. > > What does it mean "as best can be verified with the mechanism used to > allocate the username"? Presumably, the mechanism has a way to verify that the username request is not coming from a spoofed IP address. An "anonymous" challenge, which requires the client to reflect a nonce handed it by the server, can be used to verify the return routability. That is, the client whose source IP was X in the request is capable of receiving IP packets sent to that IP address. > > If the username was not assigned by the respective STUN server that handles > the request how it can verify the username (besides performing another > message > exchange with another STUN server which presumably assigned the username, > which may require additional authentication )? This was just leaving a hook for other mechanisms to be used. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Jan 13 14:09:34 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 OAA20319 for ; Mon, 13 Jan 2003 14:09:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DJNKK15401 for midcom-archive@odin.ietf.org; Mon, 13 Jan 2003 14:23:20 -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 h0DJMjJ15284; Mon, 13 Jan 2003 14:22:45 -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 h0DJLOJ15230 for ; Mon, 13 Jan 2003 14:21:24 -0500 Received: from dnsmx1pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20176 for ; Mon, 13 Jan 2003 14:07:02 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA15904; Mon, 13 Jan 2003 14:09:07 -0500 (EST) Subject: Re: [midcom] STUN 05 - clarification To: Jonathan Rosenberg Cc: midcom@ietf.org, "Panayiotis A. Thermos" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Mon, 13 Jan 2003 14:13:48 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 01/13/2003 02:09:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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: , Jonathan thanks for the reply, see more comments below: Jonathan Rosenberg To: "Panayiotis A. Thermos" Subject: Re: [midcom] STUN 05 - clarification 01/11/2003 10:53 PM inline. Panayiotis A. Thermos wrote: >> greetings, >> >> can someone clarify the following sentence in draft-ietf-midcom-stun-05? >> >> Section 8.1, page 14 the paragraph before the last paragraph: >> >> "If the username present in the request was not allocated using a Shared >> Secret Request, the REFLECTED-FROM attribute MUST contain the >> source address and port of the entity which obtained the username, >> as best can be verified with the mechanism used to allocate the username." >> >> How we can assert which entity obtained the username? >It depends on the mechanism used to allocate them. For example, if its >kerberos, then the IP address of the entity to which the ticket was >granted will suffice. Does this mean that the STUN server has to contact another entity that has issued the user credentials to verify their validity? If so, which of the following assumptions stand? a) The STUN server will establish an out of band channel of communication with the component managing the user credentials (e.g. LDAP request). b) The STUN server and the component for managing the user credentials are co-located. c) How will the STUN server obtain the external entity's IP address/port? Do we assume that this is a local configuration/implementation preference? d) all of the above or a combination ( :-) for completeness) >> Can someone give an example? >See above. >> >> What does it mean "as best can be verified with the mechanism used to >> allocate the username"? >Presumably, the mechanism has a way to verify that the username request >is not coming from a spoofed IP address. An "anonymous" challenge, which >requires the client to reflect a nonce handed it by the server, can be >used to verify the return routability. That is, the client whose source >IP was X in the request is capable of receiving IP packets sent to that >IP address. >> >> If the username was not assigned by the respective STUN server that handles >> the request how it can verify the username (besides performing another >> message >> exchange with another STUN server which presumably assigned the username, >> which may require additional authentication )? >This was just leaving a hook for other mechanisms to be used. understood perhaps a brief example can help the reader/developer clarify what the author's intentions are here. >-Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Jan 15 10:57:00 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 KAA00918 for ; Wed, 15 Jan 2003 10:57:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGBeR21224 for midcom-archive@odin.ietf.org; Wed, 15 Jan 2003 11:11:40 -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 h0FGBBJ21204; Wed, 15 Jan 2003 11:11:11 -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 h0FG5sJ20204 for ; Wed, 15 Jan 2003 11:05:54 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00691 for ; Wed, 15 Jan 2003 10:50:43 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0FFrbYH001220; Wed, 15 Jan 2003 10:53:53 -0500 (EST) Message-ID: <3E253CB9.8010602@dynamicsoft.com> Date: Wed, 15 Jan 2003 05:49:29 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Panayiotis A. Thermos" CC: midcom@ietf.org Subject: Re: [midcom] STUN 05 - clarification References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: 7bit inline. Panayiotis A. Thermos wrote: > Jonathan thanks for the reply, > >>It depends on the mechanism used to allocate them. For example, if its >>kerberos, then the IP address of the entity to which the ticket was >>granted will suffice. > > > Does this mean that the STUN server has to contact another entity that has > issued the user credentials to verify their validity? > > If so, which of the following assumptions stand? > a) The STUN server will establish an out of band channel of > communication > with the component managing the user credentials > (e.g. LDAP request). > b) The STUN server and the component for managing the user > credentials > are co-located. > c) How will the STUN server obtain the external entity's IP > address/port? > Do we assume that this is a local > configuration/implementation preference? > d) all of the above or a combination ( :-) for completeness) None of this is specified. The text you are worrying about is merely a hook for other things. The above questions would all need to be answered in the context of a specific mechanism. There are no currently proposed alternatives, so I cannot provide any details. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Jan 28 08:49:46 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 IAA25824 for ; Tue, 28 Jan 2003 08:49:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SEAjL21547 for midcom-archive@odin.ietf.org; Tue, 28 Jan 2003 09:10:45 -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 h0SEA6J21532; Tue, 28 Jan 2003 09:10: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 h0SE8TJ21462 for ; Tue, 28 Jan 2003 09:08:29 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25762 for ; Tue, 28 Jan 2003 08:46:59 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0SDoVR60480 for ; Tue, 28 Jan 2003 14:50:31 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (stiemerling.office [10.1.1.110]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0F96A860D8 for ; Tue, 28 Jan 2003 15:56:45 +0100 (CET) Message-ID: <3E368A66.3050000@ccrle.nec.de> Date: Tue, 28 Jan 2003 14:49:26 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] MIDCOM Semantics: Open Issues 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: 7bit Hi, during end of november of last year, right after the midcom session in Atlanta, I've posted a list of open issues on the list. Only Tom responded to the question and some other people. Here again is the list of issues, compiled into one email. Martin #### #1 PRR behaviour The semantics propose currently that PRR does - outside address/port allocation for a traditional NAT - outside and inside address/port allocation for a twice NAT. But it is really needed to allocate both sides of a twice NAT during a PRR transaction or is it sufficient enough to just allocate the outside address/port? The semantics could be simplified if only the outside address/port is allocated (indepent of middlebox type). Or do you see a scenario where both sides must be allocated during the PRR transaction? #### #2 Group transaction - Currently: Groups are created explicitly - New proposal: Groups are created implicitly by PRR or PER transaction - Impact on group transaction - GE and AGD can be dropped - GLC, GL and GS are kept - Default group can be dropped - No group liftime - Group state machine can be dropped The whole group control can be simplified with dropping the explicity group establishment, so that groups are established during a PRR or PER transaction. The GLC transaction would than delete all policy rules belonging to the group when the lifetime is set to zero or change the lifetime of each policy rule (lifetime > 0) #### #3 Wildcarding Wildcarding is, due to several middlebox types and protocol types, a very tough topic. However, I'll but some thoughts on the list later. #### #4 Return values in PER What to return in PER transaction reply if inside and/or outside address/port are not allocated? Examples: middlebox is packet filter (no inside or outside address/port) or traditional NAT (only outside address/port). First choice: Return emtpy/none marker. This has the impact that the middlebox type is no longer transparent to the agent, i.e. the agent has to care what type of middlebox it is using Second choice: Return external and/or internal endpoint addresses/port if appropriate. #### #5 Split PER transaction Currently the state transitions in the policy rule state machine from - PRID UNUSED to ENABLED - RESERVED to ENABLED 'using' the same PER transaction. If you take a look into the semantics draft you will recognize that the PER for the RESERVED to ENABLED transition doesn't need all the parameters as the PER for UNUSED to ENABLED does need. So it would make sense to separate them both into two different transactions: PER1 for RESERVED to ENABLED PER2 for PRID UNUSED to ENABLED (The names PER1 and PER2 are just for the first clarification!) This would significantly simplify the semantics for the PER transaction. #### #6 Message Queuing Is it required to add a 'first come first serve' message processing statement into section 2.1.2 "Atomicity" or is the text about 'atomic operation' sufficient enough? #### #7 Capability exchange on Session Establishment Currently the semantics document proposes these capabilitiy information: - Type of middlebox - IP address wildcard support - Port wildcard support - supported IP versions - supported optional transactions - policy rule persistency - maximum policy rule lifetime - name of the default group Do you see any other capabilities that should be announced? #### #8 Other open issues Here is a list of minor issues: - Separate IP protocol version and transport protocol type in PRR/PER transaction? Currently these are defined: IP4/IP6/UDP4/UDP6/TCP4/TCP6 - Need to support ICMP, IGMP, RSVP,... as protocol types? - Encryption method in SE transaction. Should SE failure reply convey supported encryption methods? Curently a 'don't understand your encryption' is returned. - The security considerations need some further elaboration _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Jan 28 14:41:55 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 OAA04861 for ; Tue, 28 Jan 2003 14:41:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SK30D13832 for midcom-archive@odin.ietf.org; Tue, 28 Jan 2003 15:03:00 -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 h0SK2JJ13758; Tue, 28 Jan 2003 15:02:19 -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 h0SK0AJ13636 for ; Tue, 28 Jan 2003 15:00:10 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04779 for ; Tue, 28 Jan 2003 14:38:33 -0500 (EST) Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0H9F00F3CVWT7K@firewall.wcom.com> for midcom@ietf.org; Tue, 28 Jan 2003 19:38:53 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H9F00001VWSUN@pmismtp05.wcomnet.com>; Tue, 28 Jan 2003 19:38:53 +0000 (GMT) Received: from ws041v4569 ([166.35.139.149]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H9F00LSXVWTJV@pmismtp05.wcomnet.com>; Tue, 28 Jan 2003 19:38:53 +0000 (GMT) Date: Tue, 28 Jan 2003 13:38:53 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] MIDCOM Semantics: Open Issues In-reply-to: <3E368A66.3050000@ccrle.nec.de> To: "'Martin Stiemerling'" , midcom@ietf.org Message-id: <006701c2c704$e3c46210$0a00a8c0@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit 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: 7bit Inline -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Martin Stiemerling Sent: Tuesday, January 28, 2003 7:49 AM To: midcom@ietf.org Subject: [midcom] MIDCOM Semantics: Open Issues Hi, during end of november of last year, right after the midcom session in Atlanta, I've posted a list of open issues on the list. Only Tom responded to the question and some other people. Here again is the list of issues, compiled into one email. Martin #### #1 PRR behaviour The semantics propose currently that PRR does - outside address/port allocation for a traditional NAT - outside and inside address/port allocation for a twice NAT. But it is really needed to allocate both sides of a twice NAT during a PRR transaction or is it sufficient enough to just allocate the outside address/port? The semantics could be simplified if only the outside address/port is allocated (indepent of middlebox type). Or do you see a scenario where both sides must be allocated during the PRR transaction? I think that both sides must both be allocated, as Twice NAT addresses a very specific scenario where not allocating it can cause potential address conflict or incorrect packet routing, as described in RFC 2663 in the Twice NAT section, pages 13 and 14. The bindings must be reserved in both directions concurrently to insure the integrity of the nat bindings during communication. #### #2 Group transaction - Currently: Groups are created explicitly - New proposal: Groups are created implicitly by PRR or PER transaction - Impact on group transaction - GE and AGD can be dropped - GLC, GL and GS are kept - Default group can be dropped - No group liftime - Group state machine can be dropped The whole group control can be simplified with dropping the explicity group establishment, so that groups are established during a PRR or PER transaction. The GLC transaction would than delete all policy rules belonging to the group when the lifetime is set to zero or change the lifetime of each policy rule (lifetime > 0) This seems acceptable at first read, will need to dwell on this more, initial reaction is that this is an acceptable change #### #3 Wildcarding Wildcarding is, due to several middlebox types and protocol types, a very tough topic. However, I'll but some thoughts on the list later. #### #4 Return values in PER What to return in PER transaction reply if inside and/or outside address/port are not allocated? Examples: middlebox is packet filter (no inside or outside address/port) or traditional NAT (only outside address/port). First choice: Return emtpy/none marker. This has the impact that the middlebox type is no longer transparent to the agent, i.e. the agent has to care what type of middlebox it is using Second choice: Return external and/or internal endpoint addresses/port if appropriate. Second choice would be preferable in my opinion if there is a need to map this information for some sort of state, or for redundant solutions that may require mirroring this state between other middleboxes, but that is probably not what you are asking about here This is all I have for now due to time limitations Will try to address the rest/and or clarify my thoughts on the above later today or in the morning. #### #5 Split PER transaction Currently the state transitions in the policy rule state machine from - PRID UNUSED to ENABLED - RESERVED to ENABLED 'using' the same PER transaction. If you take a look into the semantics draft you will recognize that the PER for the RESERVED to ENABLED transition doesn't need all the parameters as the PER for UNUSED to ENABLED does need. So it would make sense to separate them both into two different transactions: PER1 for RESERVED to ENABLED PER2 for PRID UNUSED to ENABLED (The names PER1 and PER2 are just for the first clarification!) This would significantly simplify the semantics for the PER transaction. #### #6 Message Queuing Is it required to add a 'first come first serve' message processing statement into section 2.1.2 "Atomicity" or is the text about 'atomic operation' sufficient enough? #### #7 Capability exchange on Session Establishment Currently the semantics document proposes these capabilitiy information: - Type of middlebox - IP address wildcard support - Port wildcard support - supported IP versions - supported optional transactions - policy rule persistency - maximum policy rule lifetime - name of the default group Do you see any other capabilities that should be announced? #### #8 Other open issues Here is a list of minor issues: - Separate IP protocol version and transport protocol type in PRR/PER transaction? Currently these are defined: IP4/IP6/UDP4/UDP6/TCP4/TCP6 - Need to support ICMP, IGMP, RSVP,... as protocol types? - Encryption method in SE transaction. Should SE failure reply convey supported encryption methods? Curently a 'don't understand your encryption' is returned. - The security considerations need some further elaboration _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Jan 28 15:18:39 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 PAA06020 for ; Tue, 28 Jan 2003 15:18:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SKdjj16970 for midcom-archive@odin.ietf.org; Tue, 28 Jan 2003 15:39:45 -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 h0SKdHJ16936; Tue, 28 Jan 2003 15:39:17 -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 h0SKcVJ16890 for ; Tue, 28 Jan 2003 15:38:31 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05971 for ; Tue, 28 Jan 2003 15:16:53 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0SKKOR65273; Tue, 28 Jan 2003 21:20:24 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: by venus.office (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 5B1A68713E; Tue, 28 Jan 2003 22:26:36 +0100 (CET) Cc: "'Martin Stiemerling'" , midcom@ietf.org X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18 references: <006701c2c704$e3c46210$0a00a8c0@ws041v4569> From: "Juergen Quittek" MIME-Version: 1.0 subject: RE: [midcom] MIDCOM Semantics: Open Issues To: "Christopher A. Martin" content-type: text/plain; charset="iso-8859-1" date: Tue, 28 Jan 2003 22:26:36 +0100 content-transfer-encoding: 7bit Message-Id: <20030128212636.5B1A68713E@venus.office> Content-Transfer-Encoding: 7bit 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: 7bit Christopher, Thanks a lot for commenting. Please see replies inline. -- Christopher A. Martin wrote on 28 January 2003 13:38 -0600: > Inline > > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of > Martin Stiemerling > Sent: Tuesday, January 28, 2003 7:49 AM > To: midcom@ietf.org > Subject: [midcom] MIDCOM Semantics: Open Issues > > > Hi, > > during end of november of last year, right after the midcom session in > Atlanta, I've posted a list of open issues on the list. Only Tom > responded to the question and some other people. > Here again is the list of issues, compiled into one email. > > Martin > > >#### ># 1 PRR behaviour > The semantics propose currently that PRR does > > - outside address/port allocation for a traditional NAT > - outside and inside address/port allocation for a twice NAT. > > But it is really needed to allocate both sides of a twice NAT during a > PRR transaction or is it sufficient enough to just allocate the outside > address/port? > > The semantics could be simplified if only the outside address/port is > allocated (indepent of middlebox type). Or do you see a scenario where > both sides must be allocated during the PRR transaction? > > I think that both sides must both be allocated, as Twice NAT > addresses a very specific scenario where not allocating it can cause > potential address conflict or incorrect packet routing, as described in > RFC 2663 in the Twice NAT section, pages 13 and 14. The bindings must be > reserved in both directions concurrently to insure the integrity of the > nat bindings during communication. > Completely agreed, but this is not the issue. Maybe Martin's phrasing is a bit misleading, but the question is about whether or not the reservation needs to be for both sides IN ADVANCE. The PRR transaction does not establish a binding or pinhole, but it just reserves IP addresses to be used for bindings by later PER transactions. This strage transaction became necessary after we found a scenario (see section 4.2) where for one side ADVANCED reservation of adresses was required BEFORE sufficient information was available for establishing an address binding. The reason why Martin asks is that we only found a scenario where such a reservation is required on one side of the (twice-) NAT. However, being conservative, we designed te PRR transactions to perform reservations on both sides, because we cannot (at least not yet) exclude that on some day someone runs into a scenario where advance reservation on both sides is required. Now we are asking the working group whether to be conservative and prepared for a scenario that might never occur, or to just cover scenarios we know already today. In the latter case, we could reduce the PRR transaction to reserve addresses on only one side of the NAT. > >#### ># 2 Group transaction > - Currently: Groups are created explicitly > - New proposal: Groups are created implicitly by PRR or PER transaction > - Impact on group transaction > - GE and AGD can be dropped > - GLC, GL and GS are kept > - Default group can be dropped > - No group liftime > - Group state machine can be dropped > > The whole group control can be simplified with dropping the explicity > group establishment, so that groups are established during a PRR or PER > transaction. The GLC transaction would than delete all policy rules > belonging to the group when the lifetime is set to zero or change the > lifetime of each policy rule (lifetime > 0) > > This seems acceptable at first read, will need to dwell on this > more, initial reaction is that this is an acceptable change It is also what the authors of the document agree on and already started to work on. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Jan 31 13:10:43 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 NAA14223 for ; Fri, 31 Jan 2003 13:10:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VIEIP10410 for midcom-archive@odin.ietf.org; Fri, 31 Jan 2003 13:14:18 -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 h0VIDmJ10372; Fri, 31 Jan 2003 13:13:48 -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 h0VICIJ10329 for ; Fri, 31 Jan 2003 13:12:18 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14195 for ; Fri, 31 Jan 2003 13:08:12 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h0VIBbsv012191 for ; Fri, 31 Jan 2003 10:11:37 -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 ACU29907; Fri, 31 Jan 2003 10:11:43 -0800 (PST) Message-Id: <200301311811.ACU29907@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 31 Jan 2003 13:11:43 -0500 Subject: [midcom] Milestones update - FYI 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 sent a request to the keeper of the keys asking to update the milestones on the wg's charter page as follows: Delete: DEC 02 Submission of an existing protocol for use as midcom protocol Add: MAR 03 An analysis of the existing mibs and initial list of mibs (or portions of mibs) that need to be developed submitted to WG MAY 03 Initial mibs ID submitted MAY 03 Semantics document submitted to IESG for publication as informational RFC SEP 03 Mib documents submitted to IESG Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Jan 31 13:10: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 NAA14238 for ; Fri, 31 Jan 2003 13:10:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VIESi10429 for midcom-archive@odin.ietf.org; Fri, 31 Jan 2003 13:14:28 -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 h0VIE4J10394; Fri, 31 Jan 2003 13:14:04 -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 h0VIDrJ10379 for ; Fri, 31 Jan 2003 13:13:53 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14207 for ; Fri, 31 Jan 2003 13:09:46 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0VIDISQ025040 for ; Fri, 31 Jan 2003 10:13:19 -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 ACU30153; Fri, 31 Jan 2003 10:13:18 -0800 (PST) Message-Id: <200301311813.ACU30153@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 31 Jan 2003 13:13:17 -0500 Subject: [midcom] It's that time - wg agenda 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: , It's time to start thinking about the agenda for the March meeting in San Francisco. I've once again requested a one hour slot. The two items we know about, aside from administrivia, are 1) the semantics document - any outstanding issues before going to WG last call, and 2) mibs update. Is there anything else? Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom