From exim@www1.ietf.org  Tue Mar  2 02:07:39 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16346
	for <midcom-archive@odin.ietf.org>; Tue, 2 Mar 2004 02:07:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ay3zi-0006jd-9Z
	for midcom-archive@odin.ietf.org; Tue, 02 Mar 2004 02:07:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i22778eq025839
	for midcom-archive@odin.ietf.org; Tue, 2 Mar 2004 02:07:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ay3zb-0006eS-Kp; Tue, 02 Mar 2004 02:07:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ay3z2-0006Kc-Pz
	for midcom@optimus.ietf.org; Tue, 02 Mar 2004 02:06:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14852
	for <midcom@ietf.org>; Tue, 2 Mar 2004 02:06:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ay3yz-0002TD-00
	for midcom@ietf.org; Tue, 02 Mar 2004 02:06:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ay3y3-0002M7-00
	for midcom@ietf.org; Tue, 02 Mar 2004 02:05:27 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ay3xg-0002EB-00
	for midcom@ietf.org; Tue, 02 Mar 2004 02:05:04 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2274Q605478
	for <midcom@ietf.org>; Tue, 2 Mar 2004 02:04:26 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <FS3DBG6S>; Tue, 2 Mar 2004 02:04:27 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD340A5AE334@zcard0ka.ca.nortel.com>
From: "Sharon Chisholm" <schishol@nortelnetworks.com>
To: midcom@ietf.org
Date: Tue, 2 Mar 2004 02:04:25 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [midcom] A few comments on the Midcom MIB-00
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>

hi

I started to review the Midcom MIB, but it was suggested that I wait until
the next version. I figured I might as well send in the comments I generated
from the first few pages of the ID:

1. In the Overview section, how do the managed objects described in the
third paragraph relate to the solution described in the second paragraph?
This connection has not been made.

2. In section 3.1, on Terminology, it would be good to tell us what RFCXXXX
is. Right now I have no idea what document you are referring to, but even
after it is published, I think including the title of the RFC would greatly
increase readability.

3. In section 3.1 in Terminology, it might be worth noting that the latest
terminology in SNMP is 'SNMP entity' and using this should clarify things
for you. See section 2.1 in RFC3410. You could then indicate that the Midcom
SNMP Entity acts in both the manager and agent roles, or something along
those lines.

4. In section 4, the first paragraph, I might suggest something more along
the lines of "This memo describes a method of using managing Midcom in SNMP
and also provides the necessary MIB objects to support this method."


Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Tue Mar  2 03:43:49 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26793
	for <midcom-archive@odin.ietf.org>; Tue, 2 Mar 2004 03:43:49 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ay5Uf-0008V2-3q
	for midcom-archive@odin.ietf.org; Tue, 02 Mar 2004 03:43:21 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i228hCNm032604
	for midcom-archive@odin.ietf.org; Tue, 2 Mar 2004 03:43:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ay5UX-0008Se-9P; Tue, 02 Mar 2004 03:43:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ay5Tn-0008He-Jy
	for midcom@optimus.ietf.org; Tue, 02 Mar 2004 03:42:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26661
	for <midcom@ietf.org>; Tue, 2 Mar 2004 03:42:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ay5Tl-0000Bw-00
	for midcom@ietf.org; Tue, 02 Mar 2004 03:42:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ay5Sm-00001h-00
	for midcom@ietf.org; Tue, 02 Mar 2004 03:41:17 -0500
Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ay5Ro-0007eo-00
	for midcom@ietf.org; Tue, 02 Mar 2004 03:40:16 -0500
Received: from cgn.dhcp.ietf59.or.kr (unknown [218.145.160.102])
	by ftp.ccrle.nec.de (Postfix) with ESMTP
	id 0BA91F5A9; Tue,  2 Mar 2004 09:45:02 +0100 (CET)
Date: Tue, 02 Mar 2004 09:40:16 +0100
From: Martin Stiemerling <stiemerling@netlab.nec.de>
To: Sharon Chisholm <schishol@nortelnetworks.com>
Cc: midcom@ietf.org
Subject: Re: [midcom] A few comments on the Midcom MIB-00
Message-ID: <2147483647.1078220416@cgn.dhcp.ietf59.or.kr>
In-Reply-To: <3549C09B853DD5119B540002A52CDD340A5AE334@zcard0ka.ca.nortel.com>
References: <3549C09B853DD5119B540002A52CDD340A5AE334@zcard0ka.ca.nortel.com
 >
X-Mailer: Mulberry/3.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Sharon,

Thanks for the first comments. For the remaining part of the document I 
recommend to really wait for the upcoming version.

|
| 1. In the Overview section, how do the managed objects described in the
| third paragraph relate to the solution described in the second paragraph?
| This connection has not been made.

Actually I'm not sure to what you refer. Could please cite the paragraphs 
by email?

|
| 2. In section 3.1, on Terminology, it would be good to tell us what
| RFCXXXX is. Right now I have no idea what document you are referring to,
| but even after it is published, I think including the title of the RFC
| would greatly increase readability.

See Section 11 References: RFCXXX is the MIDCOM semantics document that is 
currently in IESG review.

|
| 3. In section 3.1 in Terminology, it might be worth noting that the latest
| terminology in SNMP is 'SNMP entity' and using this should clarify things
| for you. See section 2.1 in RFC3410. You could then indicate that the
| Midcom SNMP Entity acts in both the manager and agent roles, or something
| along those lines.

We have actually chosen (after long discussions) MIDCOM client for 
clarification. I feel that this brings it to the point, but MIDCOM SNMP 
entity will confuse readers even more (considering that they like more 
MIDCOM-folks)

|
| 4. In section 4, the first paragraph, I might suggest something more along
| the lines of "This memo describes a method of using managing Midcom in
| SNMP and also provides the necessary MIB objects to support this method."
|

Why do you think it is not appropriate? I have problems to follow your 
suggestion "...using managing Midcom in SNMP". This sounds rather confusing 
for me.
Here is the original excerpt:
"In order to realize middlebox communication as described in RFC XXXX,
several aspects and properties of the MIDCOM protocol need to be
mapped to SNMP capabilities and expressed in terms of the Structure
of Management Information version 2 (SMIv2)."

  Martin

|
| Sharon Chisholm
| Portfolio Integration
| Nortel Networks
| Ottawa, Canada
|
| _______________________________________________
| 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 exim@www1.ietf.org  Tue Mar  2 19:58:34 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15371
	for <midcom-archive@odin.ietf.org>; Tue, 2 Mar 2004 19:58:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyKi6-0005NY-0H
	for midcom-archive@odin.ietf.org; Tue, 02 Mar 2004 19:58:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i230w5Kg020676
	for midcom-archive@odin.ietf.org; Tue, 2 Mar 2004 19:58:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyKi1-0005Mz-EK; Tue, 02 Mar 2004 19:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyKhv-0005MB-K5
	for midcom@optimus.ietf.org; Tue, 02 Mar 2004 19:57:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15362
	for <midcom@ietf.org>; Tue, 2 Mar 2004 19:57:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AyKht-0001R3-00
	for midcom@ietf.org; Tue, 02 Mar 2004 19:57:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AyKh5-0001KT-00
	for midcom@ietf.org; Tue, 02 Mar 2004 19:57:04 -0500
Received: from nam.ietf59.or.kr ([218.37.196.23])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AyKgL-0001CY-00
	for midcom@ietf.org; Tue, 02 Mar 2004 19:56:17 -0500
Received: from mac-0-3-93-ed-db-33.wireless.ietf59.or.kr (MAC-0-3-93-ed-db-33.wireless.ietf59.or.kr [218.37.227.127])
	by nam.ietf59.or.kr (8.12.11/8.12.11) with ESMTP id i230uElD006147;
	Wed, 3 Mar 2004 09:56:15 +0900 (KST)
	(envelope-from quittek@ccrle.nec.de)
Date: Wed, 03 Mar 2004 01:57:01 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Sharon Chisholm <schishol@nortelnetworks.com>, midcom@ietf.org
Subject: Re: [midcom] A few comments on the Midcom MIB-00
Message-ID: <2147483647.1078279021@mac-0-3-93-ed-db-33.wireless.ietf59.or.kr>
In-Reply-To: <3549C09B853DD5119B540002A52CDD340A5AE334@zcard0ka.ca.nortel.com>
References: <3549C09B853DD5119B540002A52CDD340A5AE334@zcard0ka.ca.nortel.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.6; VDF 6.24.0.34
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Sharon,

Thanks a lot for your comments!

--On 02.03.2004 2:04 Uhr -0500 Sharon Chisholm wrote:

> hi
>
> I started to review the Midcom MIB, but it was suggested that I wait until
> the next version. I figured I might as well send in the comments I generated
> from the first few pages of the ID:
>
> 1. In the Overview section, how do the managed objects described in the
> third paragraph relate to the solution described in the second paragraph?
> This connection has not been made.

I see your point.  We sill state more clearly in the next version
that the managed objects implement the solution described in the
second paragraph.

> 2. In section 3.1, on Terminology, it would be good to tell us what RFCXXXX
> is. Right now I have no idea what document you are referring to, but even
> after it is published, I think including the title of the RFC would greatly
> increase readability.

We use RFCXXXX in several places of this document as placeholder for the
RFC that contains the MIDCOM semantics.  RFCXXX is used consistently and
you'll find this reference resolved in the references section.

RFCXXX is currently under IESG review.  We will replace it with the correct
number, if the RFC is published before we enter WG last call.  Otherwise
we will ad a note for the RFC editor to replace RFCXXX with the appropriate
number.

> 3. In section 3.1 in Terminology, it might be worth noting that the latest
> terminology in SNMP is 'SNMP entity' and using this should clarify things
> for you. See section 2.1 in RFC3410. You could then indicate that the Midcom
> SNMP Entity acts in both the manager and agent roles, or something along
> those lines.

The problem we are resolving here is that the MIDCOM agent includes an SNMP
entity with management applications.  Using the term "agent" for this
entity cause complaints from the SNMP community, because even RFC3410
acknowledges "agent" as the term traditionally used for SNMP entities
which provides remote access to management instrumentation.  Therefore,
we decided to avoid using the term 'MIDCOM agent' and replaced it by
'MIDCOM client'.

The term 'SNMP agent' or just 'agent' is used about 25 times in the document.
I do not think the document will become easier to read if we replace all
these instances by 'SNMP entity which provides remote access to management instrumentation' as suggested by RFC 3410.  Please note that we cannot just
use 'SNMP entity, because we are discussing both roles, the manager and the
agent role.

> 4. In section 4, the first paragraph, I might suggest something more along
> the lines of "This memo describes a method of using managing Midcom in SNMP
> and also provides the necessary MIB objects to support this method."

Good point! We will use a phrase like the one you suggested as introduction
to this section.  But please forgive us if we do not use your phrasing
without modifications ;-)

Thanks,

    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

>
> Sharon Chisholm
> Portfolio Integration
> Nortel Networks
> Ottawa, Canada
>
> _______________________________________________
> 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 exim@www1.ietf.org  Tue Mar  2 19:59:30 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15441
	for <midcom-archive@odin.ietf.org>; Tue, 2 Mar 2004 19:59:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyKiz-0005Sq-OA
	for midcom-archive@odin.ietf.org; Tue, 02 Mar 2004 19:59:01 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i230x119020967
	for midcom-archive@odin.ietf.org; Tue, 2 Mar 2004 19:59:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyKiz-0005S5-BB; Tue, 02 Mar 2004 19:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyKiv-0005Rm-9B
	for midcom@optimus.ietf.org; Tue, 02 Mar 2004 19:58:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15395
	for <midcom@ietf.org>; Tue, 2 Mar 2004 19:58:55 -0500 (EST)
From: pete@TECH-KNOW-WARE.COM
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AyKit-0001Zh-00
	for midcom@ietf.org; Tue, 02 Mar 2004 19:58:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AyKhu-0001RG-00
	for midcom@ietf.org; Tue, 02 Mar 2004 19:57:55 -0500
Received: from [211.162.118.214] (helo=lspc)
	by ietf-mx with smtp (Exim 4.12)
	id 1AyKhG-0001Ka-00
	for midcom@ietf.org; Tue, 02 Mar 2004 19:57:14 -0500
Date: Wed, 03 Mar 2004 09:09:43 +0800
To: midcom@ietf.org
Message-ID: <nlnvcjkbxcqadlavnni@TECH-KNOW-WARE.COM>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="--------wblnaqrsbowoksnxupxt"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no 
	version=2.60
Subject: [midcom] Hey, ya! =))
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>

----------wblnaqrsbowoksnxupxt
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

The  access is open  !!!

archive password:  71552

----------wblnaqrsbowoksnxupxt
Content-Type: application/octet-stream; name="AttachedFile.zip"
Content-Disposition: attachment; filename="AttachedFile.zip"
Content-Transfer-Encoding: base64

UEsDBAoAAQAAAAC3YjAsP+zudFAAAGhQAAAMAAAAY291ZHdldGYuc2NyGMZjpkl2UX0my/YX
ndAhGh30Y785L4Sn++G4OS/w6IcQQlcsQtihW5gA2hT7KrMsX/iBwgf9YOSn01qNrrMbDYB+
Bi9Dmzt2xTbCu9NKRQjlHTCsLrW3syc671Et1GwCcNmQ0UFLvV0Dpp2C9ir9isxmEBK+988g
jx3hPK2h4u7BqD+Wv/V16rv1tZmJdd80PLl/me2kJGeipEPOY5ajQb0guJHr/C2Uweq1fz3C
aM4yDPC4VT+QrpeW1YpIPqvGJqbZ9ASwKR2zs4+t1XMsSdA82wV8Z+90oWrqa8b7q83YR55U
xaGIQtIq6IAa8I1ZNbefGjMusYgc8968o1oJ1XhCTGUl47Xn8Jy6jOYwnOMchmTmaCmiswFq
0wnQ1Cj2hA7dZkr1HhjLpQIqvYMlowhWFIoXZUJ1R2G+SxYqEW/dhdO/vQyxjCbW+guAGvwO
ooGDtDjpGX+h5yaqQJtjPE6bNzfbab0+cAvg3gJXX73BxdlFxDxlcWqmI4yg9E8ZWfdo9/RM
16s4azstaAIZsYfmm+krZJS9p5OBnppcTCbfuQI4jsMulh+n56mj+TdwIZayPOG1iK3dkmdo
XD7gHOms4aT2vPvoLGqPYq82Bkjwac+nu30OM3Py3QsRQWD0lWIDVSvkd6oOne3U41Lt4w6w
XQXm+xR1z7fygZxNJ0hu+NMHc8i/nPhhi6+Rr5vTrvdue13y6vjJuYsBYFTsnQlC9R9pkZX7
gb6LedqtZe2MNWJBWAP4DhV+oeU7IccnFYZ7Dghyotyeze81KwJrvnYkIjcR9qVasZlpq/WG
A0weJ7FSRjVFjxiQYvv1ydXmfn39tz6jEi+bLFqp7xKv3oA3UjyF8EAvMszBHfo8HLW0INuX
o404ri3S6aMhBhL6fXdMG06LdbNNKBpC2T9fuHBeEyy97ONSHLJD+kAM8Qv1OwWc9rhVZKqM
Xz3f7ZcCM8MrEwtExwO8Ja3Sq/4kuz5whHtSHRjZav6AWtOtNt62viXHUdH54nPr6hy1xk6B
49oJuNPx5ycNwYRDV42+y9CPdBzdvlZhXa8BQKHM2O4qBH17xFWj8H45krlvaPJTokVDruxF
SFur+YlQ6cfGV7AT9WMx65tR8ymJzwbs2hZTRRj9fZ6aOoBmLjpi4M70Yt9T1E4QVkVS5hYj
FYc0phsUS/V/G+dNNTvkITpDUGRjm+qNaRW0yeql50tneti9ZqT4E9j0eeK8Qk4gmGZyFT9S
fVTe+JIDJ/NS+Mt620OSU+uMa6qIhj093G9Fk2TDHoU+oBm5XvBAmYIwHdCrQARHnClearuZ
EwYDoMMqMyBpJ73p2BacqNCyjgT3ru71nnjoITY4l7rA7KnLEcKs5bIcTdhqlRaBhcdqDCdN
jJ82229fslQwd5e0eZuFzeHutsSfLw38mT3CUne4FuTHGeUQBa2sFWdM8sIHcNUYerud9ttC
4vhIjrfYO0QtR6ADC0X2gbeOScCEtx7cvW6PncXYW4xJzM03AIjUUCGS9KOY2uszuq1u73Tb
rkeKKOlBhRK3LfWSc20C4k35EkqaG62XqFqZ5V//6cJnE60ejZfRHScuLC06KJQxC4z3F5So
t3Ab3MOumrx7Dekiwz9Uv5hj3IkfdKcpAWB6YSj6XkeSJ7Va6IcnNGOWMGENGm9xMK01O/sm
htOSbu6v+JdoH6itAAnogXSjHrIcVKYlk5UpZEJngMLokLOuXf0x15L0D2znqFRG2DWsT25A
1n6Fu6B+yR4IfP0Hr6eCuU9yOG1TvTzXPh/QhDI/4Z1+FBkrvFucw1nc0KOjq/ANuV8eN3FY
e6lttNt0Q1Vy1DYc89ZEGoOpcBLGo673Lz5xFN0qwGZvQJT+kjXBrY3eKx3/Wx7XYWF4GcXU
KG/M987QHhUFiaYy7dwZhk+NK+n7szEU2iwnCOw0jPbBsOzIAms0KQLt4DpDduwdDtRCER7u
kreO4eQmXpRHeXd8Za1y5YnByRusCmjN/QQMLye8mLrObCkyGSA6Dn+mKPp+XmepnPKmATL3
wSyTyDJIolW7Np4bajIx2h61+b1VIE//ykoDduoscKPgIuU2kIaKB+7TsXhpt5ulZuZgd1kr
pFtNDHdMrEkaHPwj9s0EcQ92g6jgBHeaCqb/us+ttvBPfm+QLyd8eB+E32hKLqWX12CLLisJ
xxD0kkuqDah9iQTMY6q+mxMjVkRU+taTt57QDLrlLCJPMS2I3ME90ViMeA25jd5drZ7tpgi5
ujxOz/d1NYAkYha6f4Fs/2dqSZ8ucq722rnWnEr/F8o07KBf3KA6TbOE3KSgFXjuI+q+wtJy
Sk/MP4GJOSXl4aYaPOreGBlzWGEe5n9K2gsGcmQt092VRmIyXvlcvY9FE7lHybtRr6n0DEq8
udT+A6a0Z/dLmx/uouRb75TV69UM+qMm8qxy9JJm7o8a3T6PxKKEd/cd65wScVsIQniIg7l8
P2ArIioCjiW/EHYPn2acZqzlQ2Ye0k5eKXtidGZm93+hFmhQNETE7scriZjWddbJkCfgYN/n
O4f0D0OqT+W31jNU76sx6izJnNWqgKVX56caugNh6Pu0D+jNQKmcwEuZ8LJ/mrlcKJIh/76c
bOlYvtlyrUDv+SW9i5AqpZ8N9OXPw3Yyt48TjJAOpu2cC3/HlThqy6iM04Fhdw1dS+lrF5y6
Zjxn65GQFrQc4clj/M2NRwHIHCpFhjhVKsh8pgxeArQmPnUhaaS51FA4g9l4vz3lE0zi9nz6
nnx+x+Hkq8uFFFG0mcftmLHcr8YJgMtojGwz2ArG4XieVAOjDmE5VV81MUkE151fwjZDbpxS
+bm6jDGBchM8SCKxpa2KV0flLfcwJmb5Jiio8Rfs3CyPXyW53lAEbucpYdM4xm5xIsyOd9Ym
WpgmvanFWBQvg6UiXrEtxs5wKXw19mJew5H6o7Rbu8COaHOj7bjvUSOy93mLzbu/A+leQfBi
ahFdA+OCKmoFSd4prsP9c/UspKB2x0EuH5f89hx46o/HMjZQ7wmQM9/sKG2IM5lhQN1p4AJF
mKRr+YIgNUMMbIi/9BLn7XH51FrdvtPajL68Ke/3re5TzW33QGDr/B+vTdf4aC5x17vieziw
V5IMmmpUTICs+0YfkXNd4ShsmoYt/DI+pRQuJCgYQx9ApyqA8T90sXgtCwjB1jMCj4Hrjrlq
Bc2X/mkUi+n9hxu6MtbKuoF2zOaYphOKbUyWkko83T1u1G/mxLpa/V24daN9Wy95/Qz7Ajv5
ZB9EEc6joh82jimmEWaGhW/8N+FJACK7xmW0MQxVyOHPjkJmCs8QLonLd9oJd/XuX7WkabkF
j+cdTVNZqI7ZCiZ5urBB2djtHx3B5+t/iHjh/xVKS4hx2wNvZGGqoA3xpRSLcA+7TZb33PK2
rtL8ndUQCvETDCfXqCgCruK07hkb1U6anAIAnqJe4lS0Q9Jir1gvkxOAVXUdcynfhejl8zrM
Rz7zRUWgdZVxMjUdMCAorJo7BETyJvm0xxbQMwdlE/yITrG/ieko5IFaJ1VX348J+skeW3G4
AEIMXqOD7Sd4fDZYUuuuH78IPSXgqfKB12NbFwb9YkJw2fQNhMFz4GYiQYu852x4cAnfEtYk
rA6FDuJXxREbPCe1Eyjqm7xBV2RCqeN2jrXZLEyZoX/nXE0Wy93w0KyDhGGUQf1BASpOoHuJ
TGZ/fejU2oCVObNf+irCsXPSCv+jWLYvGRBQE0ITXYLWt5LL5yn/yj2vZeWi/ZXvNygEeJ/T
KXfBRC29EoDJExxNksGyrsMtHvdfC4/Ji7jTuadBCIBIU32YWN/e0MM7mR/xwIo7+g79TxWO
TNVNzj+NXd8I7FPi4b1B0CadHyYKvP6O0s1i90lepqnIzS4s/CF5qwuBIEc07k+iJZFeS+R+
H3SBxHlJ+lPmet45pXlYSXoHZoa8cyEwpK+h/XmzL3SDFI/kMUbZ+ZZaUYEsvb3NwGURrec7
3Oq6Uoum0e8HdemjrGKAX4dVXx7UlaAJMZCFWPboXRw4urHeeynWOhxgwVPCaONTnZIRz90Z
9tZ2zAwQHDzGQO8bYtoiXONmJJJZQF1tKc3Y/gu6r8oyCtrH6vbCrTD3DgZODgBws7YSu8Fv
etGjgBobT7HIjXZ9HIErGphCv7JpD2Re6zeVDGMb5vAl39yU4FvNWlN/e5Kxoxb0zilFCo5Q
8Mjgv+jJV+qNeV6IyvV5jr18Zis18dgzJom7eOWOeJT++AhhjHEjFQDwWWSDbZODm+4dqmdq
wU0rEUxUuaZrXpjzyy7KR53gFfZQOHbD02uASql1L6/lA8gdn8ZF3Tt59vlAvGzwH9H2zjlU
m1RAKrFLgdSd9c3x6cOmGEZ/kaP+sSr3jFPhijZB4YEcKtOkbh7UdVFUyGvwUstFsPwy7Psa
0Zc/HnFy9dzsyVcYI7i0Z2AYhAt07osPu0YyuwWcC5ps+7eErtvs34+FCcKXPnkqKk9yQFDP
HY2o0aayElCb0RVQkPiygJv2d4/BPeeerk0kNRrC0XifYz+ENI0xj7vVi5brf30BxrMxL5IT
YYCN2ivGSiSfOPy18147a9rmjqr1C2iGsNAc5MdpNqkG5By+Sxheo5+VGqoZabkachknQJs6
T9o1Cp+ZC1A5Sq87naHvAROz0ZqeXRz9xtNA3XeKUNnHDiV4GjXeUNbRba6QW5XxrfWK4hTT
7PzbwZjWWbbX44VO8NKRcU8SdDDDxn46oj+0sLZSxiMY9dHw8OY4sOW002OCdvEvS5eX+lKX
6jsgY9XihDl9gZYOL1zmFxvCwjpgErJUr6E3tUQpbZcvN6vAWYvXEKVEoGP5H7a/M29OuSwa
N8xcT9ntVnZ6O8dunTFEAlj/t5Pgg4shKuOkVvNiCrtPYuhk3HawqcNiz7uGkHGmUR+6PTzB
/xgLledXu/1qlumrDcHeYall8uesKkhKA16jBukp7IXUCsHlusSFh9VAzLLx28c5nr/3mal9
TLR9jVlp6K2xsm7+oNrQw/zLeGS6ejeX7mEsmWQDZFTE8Rse9BOZiPlt/B2T4/9GmM/h5suk
QEIsEcrC4DiNQMdeMb9CNjzkrCGuUvwrrz0EvfYi4eQgcVnM0iKHJbw0e/QMnfdOaxJvVKJp
x+BtqAlK+xgpytobA2nezg15UNOjMg29EXD7Y6zD6bYDP+VBsAvI7Edr9qYZAMBSqeyGl25L
1hezvS7ddtQozT0AuhB07ibAqOBgM78yyIdBxK6y5BhMt1G+ntbLUE3BsElGsoF11ZYAj2w3
Ekn8pvxy9Ntc/WSw83dYWoN1lg7wHY8OeHcUZ33sm3J8AQBZiLR6UOeKUcV7pZFjRUT2zHcS
9L0U38wDIb2YBHa73U0f6a3JxSaVSuDJ9ws67TabMOmpb5X24LD5w7bE41EZQ6bttAaD0slH
xMOiLcghYlHK86Ojk7dVUsdjTye+CZPRRrjL9z4g9jg7Nev/yd1amTH63JuV8Dr8Ozzjy9PX
p9gw3Hd9ExHO20opqWeQ/0IUPN+dwIfete66Vv2kQhAgHEur4NLItKvF6qo6Mwzhsz2gDyPj
ay9m0G1I9rppKdKqtRevjnvBT6pR9HktRyyRqusRRX8ACBXamOK1XpXRsGOiHTj0qeXNOdEU
W+eEIbOlXEO2tx+Qd5DumarZkOpKVQ8gJbj4OQo6glu5PKXqWQGGYo1amm6uPoRip3dODksA
jQprhvgwMR+x89gDuVlWDByxuYINjmgPt+/eVbgLnMCCotLiu9+rMV5zvPgkxWnkOXIEp/+Z
tT0WLP4ZeAwqya0Z9Tip7YSfgl4XwLGeUOO7qOp68zuW9c7En2VNmiTxckpGu549kli26xWC
KqIJusc17q/gvMq8sNxpPb73l8xTeBdSsEykcmYcIEx69nHzFXa+wsWpsLdxV+vuUETVnuAt
uuSpnVFflVd2bvGa0zVZlvh5wnU2PPOGzQbnm8xjHQ35roFQ88Cqvex1CZeqd2Sui4k9Ng3G
LQMo8oOQ3M2XVgv6xVYX5TDR8X39o564du1+Lh/MGy+k55c0giNdgIS53XUH5+L+3c/++3Gg
R1OdOZ1sJbi8y6pXSxUjuf/R49uu7auNshukP59AbiTLL44Dicgq4vaVMQKj9RnnFWSz49qy
ZfqEn4rcg5ujotgOa6TyPcD3GCOzfVLqc5Sfod83/nde9nKD8EqiKfccy+zKnZQHsBdpte+L
qDuBJET1VPd2sB3pbNoWebwOHkNokjKbKurAIdj/8IVMUQnEiEoUdJ834cZQmyMGN0dGL4w6
ZZ3ti2zSTxvtyylcjEY8pj4wICU5EZhak7MwpghDZgeVb2RmR1sif2HOMuZeJtL/ZyfNfjbg
KtBMXGgh7c+FkLOPs5WVLnTXIvo8jv9BLum5aCQ89qwn1P59N/ZgkRoBcjrKShJ2430O+EXk
uf/8VkzCI33CvHdxzUc/we+A+F2PlEaJOtpXmqCh2woeKfSrqUB+IodeuIBF1jvO/nh92w7w
T9Yf/isCaIaFVSfOjpByGS1nWPiIGU7uPGulKZLiLqj2FFn1zTO0PWR6shOpQhSe/Bit3bWj
UYbzevAwT0PUczwQo1X2Y72vvsaND//nAenKb6buEKgBjsjyySxGb8d+Nv+j59JP36LCEXZY
I8D3MLgdGj2RfdNSRVWwVtYAN5oQ3EHKUC9BT/HKs1096dLlIqSzT7ujLD945rjai8CPUXjs
RZXZ3YaDb4i64HRTOqCJrM9h4aLRs0veKnXAuWKFnkzKl/N3gvwCutHKzeqOdEEGoBXSvAIw
Gaxk5eD1xWDnBi6/JzWU/IRUfwpZOD0mriME0hthqbYgSccdEMO/BeiJM6K447rM3woAHB66
CIf3outxqIhxTkSdu0CVGqiKa25YrlauFLWzjF48Nhzv7+V36Tn+Eiv6Z/yAUAHatPNW4yYO
nVzDfuCYuqbNUAyc+gCTDZT0kVAWJVWpQwl2DpeE5rG3ckloWeQI0II3jowY27JGeQqmLM6t
Wn0NiDdsn/rc215OsYEH6QL5AUfciEc2j668t8uaDq2IPznjXkOUK+WVVgZJUypwqosQsOTD
j0GFOKgr61LyN3Q34H/m8xVO99EO7rYDCa7Ac3KLfFVUxqoq+V/Bco4AjSvi52bi8ugZQLsD
9Qo9DHQlyp35dOsQ+QZ64Gve44d/dmxP2A08OtqUmhzQCk4XYke9LPOd8/JNJBRA08ahA/64
37NyhbXoXLYCBBAU7wr6bAP2behgoFql0AjrQkesmb7Ft5ZuwIvFDCnnPjXLb1jlNuYQ40mo
iB0SqoIUDt/uR/VCzCRkn4nZ86idEq/+yIvtrA37ID2sA/l+yQXs1BjK0YXeP+mPYTWR5mVb
TT8LsdBYli7e0P1QjQvf22uXkT4SZLUnMVZDZi/mq7KtXg1WaKF0iqjCIHB6yc2U5WUveT1D
FZW0OvpN08hrAu19yD0D7jRoTgKRatXAPYla2D4k24GYbmf3ao/Q3iaYc9OA8jc9l3gICJAW
K1kz2KtEe38GCvBpiPcuQla9HfS3ovRmyfETKXS1XrZN4im95dZaXocAZlDpzvOe9wuO0lU8
/8r2SiTJRm1Rqwo21GxBs63fTv5Lk5dMvXvX41fXTmIHaqKYR3zdlYzypszuM4ahcCx4dyFt
wEljmb5CYPfHIyssDoW7uh98Q/d2YKIsmUNJgTXG4BvU5B2TYWY0crFbEL4MElKsS3wC97sD
/J0gKSqacLRkht6LlJYiT6Tjv3bmodMlDEgbfuF+ie7mqawQf26t3DgfQR7HHsfyStUrvUhI
y1x9bRnWvxjgJ/nFtH6CyCV/9JvuF82FIg83m5iSaxnw6IcEK2P2xQVJn9wOqTv3CYobMAH/
PwVaeXwRs3eVZi042VGTl0nS4EgyWJAS2qNMIlogB5riTRcijDlvCOBLPUFlb3aKwVm82pFY
0bOzui9umI+qGi5HZH+XRVOK/qd0VmhOyPd8D4EvKgzbR3gAbzKbAkW4ZskymUS22ApHUzLO
FMI1A7A52AK78G6wudWmNF8Xodh4bvnz/TJ+Lfx06zboxeoSmUAF+7ibpH5FMKDTrMwWlEnW
c1VBUukZbST2ad5kCKMOLT7a4E9biBj8s4UBhoDTF+9eoQcevUuDWQatePH8OloYLna+653S
WxC60UYp9vvilwfuciICqbN38oQlkipB/roE/5GSerLwAPBrLr+8ldqb3QluFNIn8eBnrfxN
eE2KO7Pj51FBiG/adeQha8sGWYFIbULIQVHy/mIw9o+joN3ep4bzMtvv/GGMNqvaBLA5LbSU
fJkuCT6mbyzenpyUGHNeZHX2lGZ1Tyat+oANpmYgsdaA2Y6cGrPJfeHnY+SSZ2i3Obv2jwje
6pIB66PTm+UvIfNoRHU/832ywo3uXwRGs0RV320vkbfWZq6ou/pAXnTiJwWzBUel9AmM5ONc
7O8TyvM9hFbs/lhKZQR7ajp9MqWgvfpJ6HxczBpvDnY6qq+u5FvVoMzw7yhq0bGbVojZ0RIV
DEwTyZMZAt+BS9GBQafo/2gPMiRZrhQQch0BsYxw0h5CP11Ar1PAxWRnW8xTRkknABIGe7H7
s67/qwXquCSJJV+vIYfosG0kxjQpUlVCRvqGvMBe7vuUi8XJre99SUtJ0PX4zgq2xYM6HWWW
YJ29+VwL58sEobGvtN+NkWook3aR2H5C5d2W4egBI+t/jQSDhcWEbk+/meICSMbFBVTVEBiL
grxHSfKwaBmTG+edjk795fv0C44vb2/GUulDwwUDyCU7hklobuRi7Ay49HrSWNqEvsWe9TkT
JD2k0/Ay3kb0FhhPsxaZ+j2teG+Dz3zIog/aIZz5Kjm9Wve7OApx3YnjCT31aqy9mjk2PISe
U762ge0vcA+0GI2PwvqC40KuNROxTak5fm0Zdm69hUXfI0OKRVHcBYZcwjkRoBikYRQmqXWI
Mo8mrUELYKNdoFMXx6dhumqg2P7miHKXku43skmvkNmx5xST/oS3Gf+lJrdMG23Rjbxh9kTQ
lEVWL9VRWJaBNC21/FhI/APNXQWJuWoZo4osyx1hrY/29YB8dqHAR2ttkTEyt0FGkVHDvTXa
yhsEKmoKHLtZ3/mXmbdMFryc0F8aN0gnDl7RegPRwlYNs0jaxzyT8sHcsNjqGL5XWfpx6nk0
ZQ/9Qp95AvChapLdIekiosR9gChUAbKUboT2Mh01+GYgi43932Gfsj4Fq9/ZePNsuamHMY+7
Tw8DF3ZDA85TrRVmJQI7EtX20NI4ru+fPR+PNUPk912aY4ke3pNe52QvSnQbEFWYh/4F8FRh
v6jWG5vZTS6SqQqsVI53jMRVkk/SmXqwxMSio87wQqyAcy0c8XvIARsHxrcEMCjGkDNiNU+/
Cq9BWrgtS6FntWY5yL/xt/ihs+N5hNABCjMsJxrcIhxWrlEljn5dVUCJ6CW+iQSdhBzI92Ne
kKmf5Ya79+hkqBv1YW7kpw6IVZJnq6DsTpcCGNfTl4Y6SXLTsnpY5cT8uwaTXs72ri4lrce2
EoKMcA0z8zGt6phIytFpYuY+YexkhpdvlQSk4FXjVilKXZwDVmOVE9wDhqYHB2i2vhnE1fom
EFl7ikHhUGGnLYth5ceRBkycYf3mVkOYHReJJ2MmYnjxwAE5CUX0icjo2u9nQt4RTpdzTSSr
b0bxDQfOB5rEq/jaUthfkmBUw0atEpBmujTZvm/CYCK6rEyznWbuikhOIgdOjHi+RSFLbogM
NFlRsa+EQnCl1nfRFjsxr8DREnScVtqtDLNzfqF0KzRB/z2C9HbVLoLTYQWTqeaYsC4r8oSQ
eefaNCFKo52M9UzzAywS8nKHRliFxTH8V2hmJcIObwDkvLtN2WB/cdIHlbErd1UTpYH2ybAz
Sy1ZtmVUxY7elDAMsWkHTnR/8A3X7Kjh888YyhgD7qogCanC/zyHNcLnJ8HCabKis7X875SQ
UnJZ+bPh5otZk2kINK3uw6eqNWyjM+48LLcL3whQ0x8Z7B2En9/2PoqHIzKlRsNacz2nWNDd
53RAKFhRUAQ4/grDpkY54o5Mu0jfbWc0/pm55CMALn3znva3yVvj/OhAN//TTbCU8lB4KJLD
TFPKXmeAu8BE3ltJaDJ8Y6X6OlzZEBxgtqaNHw/QJS14NlgOoUn7L5rSGByxZOMTHaBXdUUW
uM9oMpAOVGnFaxq8cHYk17Q/FAI6cWu6vcyUyblk4vvDuPq3wd/wYBkMNZ0cak4ODeiivfkL
dURasDAirjTGYwFaOKhZzI7YK1fdu0tpdU8EzckUJy80MMA9gm7DXJJvfU2DDkJsTQOZSJNZ
VavE+4gx0HB0m6h+t1kMvkt1Nci6fDJtT7qMgroJFpGSOifCgsZWeTrVp7c4lolGbo4+ijla
MeOafMDpq1cSSJqWnoyE84DQ25c7G9xZKGZcbKKF2H6aPklRT+/BKeDFYxHcK/VMP6GZGVEZ
oc+EB5jbCtfU6RSA7Pz2puVl4SZ7chp6KbqxT9ttIq4RGwR+zryomH+TP+5oeYNA4fzIvTHn
MuFpXYgno6x74LMFsDyshNX/fPryKqghDhkIyQEnjeMuDcx/Xsm6tS+OmbVZggPzvem2vQ/a
NzrPDpVENeUjns9FbrYGgyYqVc8Np+Ywy4XVWMjjwYDwHkxV0Nwdggylq86TWUw+tkC2scr9
8lZQ3jvI3eqRwn+Ws1qz9OzhAYd8/NZnPaH87S+oWqMUCFZ6fxq9VSuYLquqAVmEngGrJmU+
ycGUvXaXY3B7Ob6r8Z5MTY2G1B02fE2bcqY3HTNNQgLuIo9W1vDOHQtVBn+XRToZ9c1HjZXp
TbvOq6fKv6LH/JwtO4aUxxJeMHQROX1PSQ7db2Uah1VODBTg7xA3j0JCyx7845WY1eVlcMf0
U2+tADT4wo+ldSulPJQbbH9U/AK29Hl29gmMV3VvvOXqjwzLZld+aqEz7reGq9Sl4Z5sPTnG
JxsYgR5gIK6XzcCQbjN+HqmWLT7h9FFZD2p75ffvHI2Ba06k5kOd9iDCLXPi4V9guU9myhsc
iLHG1pxGSA9L+Nmkbbt8c2cSmadG7PRxjtWg8UiCqDN44MsnG+2W2RtPEEpJ01yIB7Rj3tte
3toP1tjOd0LS1gn6+GRkFUVYW0Gl22aFi15Ses/dUYLPekYKiS/EAW+e24JQOTY5dVsyxAcy
sEaRvn93RXwd8w9DeK2t/ZA/MV2pJH/EXIwycDjKWTqdq4gVavaED5/zmLitLBtWAY5wQ4A+
8TVJB2pjwmnUZ4mC2ncfNnz8fNyQxcK5ZUh78ahg2sMb8sR1aXkUaFlRbyYr9QXoSHjT44vv
FGyBQpntTlJZ8/TMVvTN2caoRnEKNyaMBhNVFtM8v0RKRLv6WgK+kDRlF6RYmBaU8Gc6f2FT
cmgH3Q0jEExgd66mzYkPKKSG7Jev7IvFfyDCWqne7Ar1Gdtzoe973I8VXnp8DrD2FpmvE/4t
8AYg/BVJ4dOYOvus9x0NzyglCjn1nsinxHe2oHLO3yQ6JhplZGnj4doTe1DxZRP+GWdWJqQo
xhC7b9zvxBO9ZwO30F22oPKvFgXa09dPUqXsY2RWMnAmwe8WsvG+VAs4qYUHKdiw8msmpaZQ
TPxin9dozjQzm1IwzjzmNVepelA3QUvaomhZ+U1xDXsnJOq4p/aw2xE94VLb9nMBAQhvXzY5
VGnfNslOa1PApsNDBjdTxOjxRK1nlcRja2CbKcw2m5dHi+Y8v35brVEvD0f2gEwTyfuHqe6X
7C7r3/JKK10yuaIFdR15x66uCJXpgY9/5vskxhuu+Jz4ejijFli5m/qWd/f15h5ay7NdJlX6
XQoNSMk/SLRQLiy7EQmA5asx79Ue+x4uoDJ1ct4hAvbwXOsuXmguTDJHhAVisO8f+5w7RqL6
wa3YKzYx6avkMuiLIGSydcue8QNtij1wSSm1D4CMOGq0OCfPeqSrhPdF/3zCFYfu42v3gFp/
bMh15SjWEBA9h2ngXi3yHF5Z0hYZB6xqL9M2OpGiNTaj0ARosd7M+xsxuKbQ+A262FeUOsmh
zQKqfGktlAkyjN9iaSgjdnGIyiqqz77/KF7+CKwKz44InKFm0DR0pet06SiXpxpHSwQBUXJH
SgiwzMQ8iaOVZslxFdQmQ/56vzPep9JN4RLgdv0iGvk6JOzyDNisd9+1Brw+GyQIa4G9ESaU
LA/syN9nNALLhomzEMd/yNQfSGOcf96G2+yyJmMm5yOM919skQfqXI2kMIo6Rydl6LNCMJYr
ziFgjmH80vjcWpAlsHfYg982WOcqLB37ZfXJe1Lzjfp9gUaid2Apb0j6var9q5fOF4Kz7rDy
xRYNTr19xbgi4Sg60QIJjQt4IMUIfDAUqGhKxmF+eZn5M5mxfhPULni6HZnZlu5MyVzY/b/X
3DbJmVQ47kjoMzGCt//WeDcSTDu21RlXB2q5e9p64QZ0n8zP6LghFWFISFFN0Eljk/eSsHXb
aOPckQwjC4+NsstbkpEEFEc/ux4nZOlPEL9g6/3fZ6Xwjj8RXd9if5TS53Gew5cnsm8eZf+c
SllMPMuMD7+fkwHK+6pgBp/+i2d+pnF60BPpmC/9GRXcSX7RFb5rclL8WIbcDoHkpgZ5nSnC
wcZxxiBiEwGMbbsgD1M90S/pzb/+RsaioTVYLjhvLJZWmxOL7lS05g6KDtjEWZbsXX9WDOFP
MNw0VPQVV5n5n0zWktKfXyzGSfXPNN7bF6yXJGdepCtaPUDDYLX4uyeLnAQbW0Z0JFSMCLOK
ZT+xId0zYT4XHn4Q1yYNIczZcKEmxYaEIqC5SOJdbgomzI4ZQoWpOb/kxxFNskxEvqY2YDCI
q+R3c0SDGYXrqoqLDi/Uv2TWcx2pCxZJVY6q6COgivCc0phDadLEjzd8BO4VOmF0DNUhH4A4
DbmDchftu7nXCcDtLwSYfBV5+28wC/JTLIFxWVwXe0eNtHVwznTL8Psk014Zp0MJUASDuvCP
6ab77NPM2x0CgI2Q2XX7ES9H+IWXWYRrfbAh4Cx0ngWiCt5XvaIPa/6K4UftsrwNk39Z799M
p86rt2uQkD62E5U5t2yZfpiGpjsj8iNnCuuq+Xy6KqZDz+/onI6MV4QmDBcM9bWAchqFbhxW
j+TTNMP5L6PN4sx1lUvNiMfH6f/jTDb85+esF8BZZEBJLO1CMHNlAkC9UGeofEVFfHzc+Wex
+IPzRSNfhfgys26ZhKmChsg/tBIibfGfHvT3oUVfcyDj7U+9eDDiu9+Z312RBaA5CBbUH7vb
EuO6INFMm190HzE10r90PJ+p9QaT3CjLNtEXvTppWEE7zR6tr51Zm45TjShXQszadAANJ/cw
CdXeiuN4GGeVij7QZLdTS2xFVtK7k85BQOvkUDJSvf8BKnDkb26cQLxTDchVKot2TTx14XIv
x22TrM2EjBdlvbr+xZ3ooor+EuuRREu2lQwIBMcj2l6Rig/BXJ0It5PkrUhxFJ0Jxxv/Yv5o
Jzag7r5so5HK8bYJPAnsOkSImsCmoXSNwYK/vRmT+97Ipe1PBUGvM3iuIBacmJBrbaxZ8g0Z
9qW8Sl/suWIJMio6pjgxGciNBu3hcNOjj3vt/mWl0RsCiN+DY8SF6nCinBc1FmSPZoLbg+d6
amLSCh/iDsPvMRbR72IncPseei7Aw076bPQBVNdB4WgRYOPlSqPcy1o1TKJUpDs1FOjAyg7t
K7tKAYLtf+nz4KJevPFB3QAWmTmV9t/et6/3h8n6BOSFAZqF5fzNDiNctwidqbRj5W2mGX5J
WHXod8pcInKZhMjHug+wlcIPBflkGatrgbsNVxhlytfeWey8xn3HZRDdFPiCxrpEqjB8RXSx
0xr9ZZBXEbBG0OJZlRa3GxAmwqch6z24CnSZDCZOGdi3MaLjbrC6hbPILiDY6AhECK77b62q
ZMFBo7W6kjTHCftd3blTI3QvfHuYfcF3+bm2V1dlDxos0w3/Q84OH/ZAsxZA5ucVvByVjRbU
vcdfl045dLj8JkZtzhpLWdKoUNrsM2ZgPTtxpGYTcJt6CrFdK/nlZtAhNGsCGNM2A+hL6hVj
3XK267LsFs0Z+k1nGoNru25890J01frbYZ6wl5Up+zGOTdCIeBD2CEA5af+j8XB48OL8f+8y
oLX3WxydfzYOXlvN8nDsupMQDzuLYcCHupA0KE03yooBaP3aHPk4TKxcJptphCu/GpCPedtu
IsZJYimKVGEcZ4xLNH46b2xdaiLzdiD5W5uRMCO8jNyUOXATOgXgf2+yg49uNPWUyDGAHvpX
YR2hAJTJ9Y4nHAGTtwnXXierAmoknsQiRgYcpLSRWtRveR99f0Wa6JmQXxiJvoIeWj0G2HY6
gjesGwYgHD9BqElrSW35pWxXolMggWS6/agzif0oPuIad/2rQdXHpfGAE/LDkKgBqCYgrfQe
q3h6IUlTKJnJ5n4M0bdyKL28CmaCAb3pX2scA6R1dDWrcRieF98UYEH11h42vVUtR9Xf7RFw
1eJKEPpEBYNARciFjEkCWQfPxUuVRqhVOaCAaxEIijkJBHzrou9VzU8kVfW/Kt2Y1YQhF7gy
1p0QV3GrBQ0Chspm7Ln7MukRbwBKp7gK62OvKa/MQ5RjrKSHeMauEwtA7ItnFJ0IgBCFSKRD
gsHKPMB0t68mm2//eMOieyoY/cJIZttH3Lz3veB7GdYeiola6NHsWc72abAZHfQVAJCpPgXh
DORQP/9DH2S7aEp9zY4N1f1HzGaDnJOf/aZwgt9F4v98jMY8dL1EArQ8tZpgyx3tmBBGZa87
dsDTt89AGbrOaWaWLvpniIadWxR+n+GBUX66JrOclVkkIpyotSLT8nqC2vOyjByRkbqmWnGt
YMo1kz4Xpdld/xuRtBl8KzF7bfzLTY3KwbC/hopENInOyxLvZH2M7l25IG+9ZHMSF8t5uMWc
n1uEwEUp0wEwbr3qbZ7UDTnKlFydvo1KDir41LMbu/rhGfEzrx9xYLNOoEhS8aR7CF+/NIjj
xsQ74vATGPuENO/7FIfz0bdQePTf/c/Epu2igLef5saDTSTXJjelLjYQOftiYXKNhxQ7vthd
XEYE84Q+1JFCBrwR+ydJ64orxpBfFBoM5Lg3k7uhJaVtE9gFBqNgk+R85fx3mr94etLO76o9
B7k2+rJKL5968fa68ez9bC3pgRjg5RiqqNx0h94/9rBPGCLZQQGPxsxh9SvInR3x5ZQW+KKR
w8Aut9DN9dI/N1aZwpFwaX2RAx7D+jLN7qEYglKzSNUWfuMxHZ61pPfVBn94pQkIu5TrINlm
sId2RBMiW9dSIvqFX5jNIn0JMOUq1ERNiASkjTGtex1OC2L74CnNelLf1Nyk97ei3Jldx7Dl
3qIQjEdmrOHDdccZtwnXnQIfenVfq2WCpmuFd+6qj3SLk9XZUAWnoqUYoCu1F3GFvzgXuFaa
FfQ1ax/9ZieaK2f38+bAgSoyAMqfrdHO4gmIAYTKUzazbYCybIDG1i54NyD1ZlKA9CxfI/YD
SrInh2ikQy4KadPusMcNHA16qMBwNT6a/IfBMnrf9nLmF1IFaMF/vW8MathPJb5l5elolZy4
2uwy615A2OqpaJi9GHJtuTy3O3EAoniUIwky5VLv9mp0l8sUQW5IiaK3NBg4cCnAgyXvKnMb
u8p+jTS9NXEUBBb3liKVUTid7eeyT1lDClgcBXeumtvCicidkypRpRrp2BsEU8xn6Eo+1yAO
NEeJi2cl/Cd7uIjkbJ8jIp+bb6ysI9nWiUmh712uzgp9+kv/Ulz/ikiZqKJ1G9ZPGFmUvNNP
/SXyNqNuqzZq+nxHnyYsv88y5fcbNBVISARlJAAlfZmPlYxpbFUME+jpUnuf/UShgVL+1s1o
gnIMApa8h8VLufNbwx1+b3sGJ/4ovD8M2QtpdAEG9nvLNuiHM4vLbyE1UCud302u8G2GQj6k
44KxFykoMUz2UkjAz6zmqPCAiHpl1wYs6y+yHm+rN8db9AIeZTuGO4FbxM+AgKDJq8bigkqq
f+DsLdoWMdFXMpEFblfRtNYEziuvVzl3SMcwoCmmv2csDsZ2qeSEGJMk+i2E7IvLcIaZilcD
mDzkz7mkXdx79+rnqTRO+psthx0h1Mx/eHxlK/17QAYvtTlhhxLJkdGIZB1rwGDobuHaurMb
/J/0SDxnc216tOyyF9vehQkdTUmQXUd7omvZfTAVqkGiX6KTMxOkGGrUrodARh2xktzZB43y
+ZpJ7F6Th8sKUwbGBhh5SN9CBIWayDHVdN8jQCWQul9JG5ao9XzvzrXUPqqdbBJKafy4KwlU
F1AiM9sPeslQ4Rj1Svp5d8oKJrkYZT7b7CAc0+c0yZiDPfbz6ouE5iBsGDBjm0uhEMfGPPhm
w+08t5bW64s3QZOOYxpHThjEfCpuN4i8RCy9sdgBA4PHwxE9KkooSjfsZwXkUtdKqqpVJJ9b
KL2b4URC7TL22hv9uWcALI6PHS65LlhSAzCg0l9fXfzu9TQc/UzajLXtQHLA4R4B2IGRlbFz
WLLeWobMDoOOGOrY+dnsQTtWXhe+vgz1yhBm6LK4Xaxq30rL3BiSsb4JjtBt9oYA5dwuEv+C
m1JvSK2C9pdmeEERBOgqj6PLBChHf+axs7bL8DmIvM1EoL6+nBd6qIdNdWbl/cmLlBBHUu0t
PMx2RfelThTunsvUWEW67/CFucWqDPwGwxyJhU13cCoFIYK1Jm1tbcBbqy9/fHUXm0xSBIKH
SsHdOpC0ib5QVMIEMcvV1guk5hi8PHAbYKwLsxnUVCOEjYBOa0asfr8DxUAuZrMyRLMga0p4
7nSAdNZ+u3eZFhiYfnU45g22sA4pCI1STpWT7axA5L4iQtbAbzVSPnXRb9ivvZlIPBguFAt5
3YgxdRcvwBaNOXlXaJfH438d5N99ZiMUcTWDve8tZ/RNk0PoB6S09MkeIDClmckRKBq47nHr
7kclFNR3kVv531r2ynSFL4DMf4c87RIN6O/QfRwWkL0KJcQMAOiYzP8EWaOy/8mVUN1q4Htj
hFuergNxxpLy6aFDrvfJRTiSbrEhwFK/fqK3X5TRohXhTzouBr3btsBTD+dzjSol86ulG57r
TRZ0oNJ4k2+Lu+0fAZVlgycmsHApGFvSwYyLs9dkd0OgB1Xr7lnHpWOB8PuaNk5BcT6JQMyk
b9aBOv80tEo+gUyJ6168AcZbp97vxC4J0+fYiKuaEe9LHHvMkHiS/bzeY6KoLhuHXVt3pgzp
OyYkrE5mzOxyHU0eDUjXiKygAtBFe2ZFzdO0STEunkNmLlstKbo7k8dN2S24kS3r53T9HlAs
hawi4IqAOG7VY57jvTA7YwLKgP4+3w3unlT4YnnvReFzuCWCmerFnElZ3w+k6UHbdLCRxNnV
yQmlxcFOFharPasrrrZd3PkoLfJbY2z+h6paCV3MOXbQQI17S2piDplkkHASd4w9w1w3kB8W
2rtu+9NkeePrMEgKnQjGTiJp2jZHxkFfgdsSi7dF38kQOjZTJ5e1F59bOa7LxkIbdiQzebTB
gbtGb8JqeCLWVJtC1ZG/CAYGJTrcKk1SI/J4Z3nntN8YCNFiUN2MNqjZ4ex/ZUBQpT+Gunk0
0jYNBPbTMeXYl2mC3bug8090LsAYSTteqfWL55Z6Cbu/8k3yHvJ39pvVdjgZ8iO4tsVSJTYm
I3eg1Zlb6O3W+QJFNcFneYkAhgiBXhiQ/xzTzJUBfcx4SqC2IvfNXDLwczskC6fyZTUtge0i
70ndQwzd3eSeRH2QicZVa+vQSDhvX0Vpkd8+s7Hqn4y8122tWJ99mT5+aSLraApd0doJXKvA
Y7BUiczYeVk9hmALpBwDPI7y5hVaIE6xWXxnQE7xHF8oXKJzmtnboDcmU7qEbM+fGGXSW6k/
AX0Ms/3TYFlgytIgCJ+do6npdOKTYndTNFpzY22Q3833Z70oJ0icSWF5pLy7/aYzzzTVEmAr
pVJL5kGIx/fF7Spn+BsO5txR3qg5aFrO1RMWC42Na+qVIrb2EkEGMWs2PyFCPRFdVeuWcUsN
y12aiWqlAIVYi4Mmyrk7OoqCaiEkChBk9Y5AZSeej3S9EsJjZ5Fua16aPgf9lZo+5FVSWBdJ
3mbPcSPZ09GLTEGAH+x0JQZY6Kf5Jekgip6AY9QJSQQfkvgp9+ncTzcgcOmeFIVtr4Ud4NUZ
3rjkSBrNKaX+3hz7mlfqIbdTzGzWK4+VAwLiba4GASk9kxXWIX4NpPdg+Q5toMoZx4O5Kl5x
ljMLbH3tIdJzu6ZoD+9vJFZNHv8FFO9yvt6PCf3hYgVgOrUvr9fAWqJ/Ld9tA5rq7xZM/v5Z
eXTswLJJAqJlxYzNOZ6sAJWmcKn9F2RY9+y8FvbWgFlnw4bVGA+iN47OSJoefww15CgHmJfh
lLP4d+OYk1taib0meBPa3hoIrkHKYw0EhlJUjisxGc9KHyaUGSmAD0Wqh1XZwYksIbbjDIZ8
CrDOMQ+j5bPKBdw9iamnP4j6tGwYPL+kpa2uC3p/KHlq0JvSnN3btu6b5bvUdK0umdrpCj98
3hJV/FSVqQf/9qMgVuqbNhM93NwyyuLlgHCRYqPKnK8hCsMX3oQ+e1pCHFGf1V2GLNabO5RH
y6S0EnNl6yxQ7sp23J/z7VBQI6VvOJSwmdSQzFjx3PL4rWjm5U0rmXs57aNoKMBR23x8ZncE
J0SeYYMQSbk4zSkIxN1vArr3PeF8IWRhVHCS3+aYJeJPIPzCoO42fU7jZlxPz1BwU3k5aSLk
KWUAwTFP96IC13vo5aA93CUVjuv1OnCzjiSsmhLnj929DSLidEWU0tNMD0VFiXoUyRVWhlPL
7BJGmvfdsz3STiNlNduYPPqRV6jatU0orS8rF3hi9ryggrMyAxxHp524qnM/SkEyE6jk4b8A
2JVws6G3Pb9rsqcwFrrqL+xnXqhucUbeAXmWAZElLhPp/LOBis4BEpuXdUor1SUResQKTYdk
MB1e514V3IVhunKeOWSEIS+S913/9d/Oc47Ooi1pGToYblwBgKyR72qXXgy51iISFgDIJUN2
nNzlkzWmIc85Yw9cGW9KkDnwwJiKOAdx+jnL5uqlOw01bYL7wcHC/OJEdLkjAqkUrFcEuZGI
wbGSVgknxoxlDyTWN28wnXNkryoAM26xVuSnNVwrDdEw7Mp+g5O5CYDjMhzFS4N34nY3+bmu
EQkVPBDqIJKWB254/9dcUYcGMT5Ua14sXyte+aOq3QSqsV4XycZzeMgrHbEtYdJO+jQtmULo
XvWNdfOadHCMIMvyr2oGMptMJkQpWlvfXIqo+1Bz3ilUUFoirZuEO9usWLDAdEkCTRsQcNmA
sbXNUtZ9KACrYAaYZ2p9/GsjHkcDgqHSqstFz93YKTSDfxukWOJjoekdnHIzPA9xJ6It4+T9
kE35piRxvg4+BRdVY+WD1Ih9GTmqTMdH9cDbvEEwJ/aXDpz/KoghYpUyJqKMTShJeeKeO7Z9
24dsRh3Ssi444eXaR5JhzxMgpNHWhrDdvprwD76E7tc9tfqickvzjQ1NhuJzdXwgo2M6ybJH
jbTWfxwms90tVSxC9Z+BRgIHwhLFksiLcOs0MQhJqcXFDgYwSDu03GGT9eMXaG23GXdzaRTC
msCd9joXn2AsvRife4QbYyeI/AZ2vJvZd2Sl6k3T72Qb/VZ9YHmMH7+QKA/ydyybr5IJlTJZ
JKCKfHVZc0Uq8XUe9WfK7fxzUJQB69ooc6upoVJiUnj4yliZf5drURW+Brm8S0Cn3EaEjo/m
enoKGeeC3RP/HzkNAK9d0xzfkO8Ym5xTwbyDr08hZCo2+Pac5QgdoDxnNAnPTxHuwMnuSdPE
Z7QJrlMnuLMVgUUX8Zm6A6H+MJzVEmEdtyqCEoTw5eIVzB6OWa4H9zwg1pyuuWtwOkiCo6E9
CBXMNZsufOrZp0CmwsDSbHem5gCSjTNoG7rh/nwmYUSFfnVXP4uRGshvNzku8YkI3fvrKJyF
qbTqOfGvdfjxPc9rpe8fRqZXUkvBK4x1w3PI4bo1crnW/llEzxwXhTXdAAFKX/98epwGCD3I
julvokkokY65Vij3XLH1Ysfv5j/NH2wn/us3iUqvYUtlRP8nDSv0o3sEBPBBf5JqhshaFg9c
MA49Syx5UoT47iWBxWReyUndqQACI1uUZm/ciSt4+KhQa/JCaaYPlsAaMpBA9WUdbNU5JC74
Lw8C5SFM2rc8SMszIHT5w2V+W6Aij/bnjTViSe40zx/fEETo87MOKOuQ/btN03a2lq2sVrQC
RbR4phOMFO+OK/rwTDml3ia0E5xO6dPR1Ouxvpq3lL6MzIPfaLnLtXBm2YlB78r7ALQXH6N0
I7RSNSyOMpUCjWsl08aaitwourQXzv4ljA8OzHueVFDltbdyP9S9lsqGv1sYPwgn2vTb/WRx
S87qBldYVmgusR2PckmFkSHsI+xdJPOGgPgoRiZzb07aCmkLXY8O0ckexXhPcKYTjlQI3w6J
9I4qHUDPmemkwfhnlaFPl+jMp44vX80rFq/koJEVj+II8eiYHuf/UAM35A/k0dI1O6oJWFo3
cXmlrUHzU2tccpOgHXrv7Nw9v61C7Z7z38QwoAwbl/yaRVBSXX3ztwh4CW3+AJZo4+kqvxBM
XjNS6oSgqiRVwLVNm2Zu3asG0bmlH8ZEypVJ9Q4KIru0T318fQcB1JpMLemGYxAfJDIQWRDz
rI7cgl0BFWJAJUsihZ49ueGEAqJopKLg0Tfo0kMkcbIL+SDd9PrEUlqQ4VV6BmeEdAlgHFcM
HMVzAIv2DUAE3SgsVnBa4kTmvDJ8CVUYH27pg7a/nW8BRrhcNuigGHybny6umr7/WNu+XE6M
/T3JwCqnLoEk3aykuHtg9uVCx4WrIRyUHZJHINxN00/8eEfaeRVFry0fV5mHdY7on4r7s9Wh
+WCSvQ1aw/oYbdgNwYJdmxeE5XM4tLouE8D6CYF/qQF9XleTypgd7FhP2iF1NOwpCmc072G8
Gp3CFNqpIaM3LKiouywBNIQvxLhyE/81DfCe3y1q4YBR79dUd9UPuca5CetoSPWBJVmmstET
kaju5nmyAdY8ZXP89oAaf8w9qqqoOwv7NB3SKYaJlNHbPhlVPWYg0alAJ7dloewzaY+jsicL
/nvj5kdVZ1Bqwm4ylT0ShYH1BEzWvQLT3Hax53cIOCDdNozN8JgV/cFQJGyzemb87Hjns7kh
yDXLj1qKqKwZHfJZm0xrZ9kK19JnnL2Yf/eoAUEfMzHTlCVCOd0ksR5Idp7E758aoAiI6SwY
HkowYKxkvCXMTdxFyN0mPxMYMLYEzJOZE5J91BeStD3d3R0dkBmhbeMAo8PRViJHIEE4TG2O
tNJrXAV8P3gp5jUToHCYK+8B6WYifSapiWUzlv0/gGSB5q/eJSDsLMIUj/7inpfZn6l6URaa
YxY0MBk7YH9n3QOpR6qXnw4vCV8eQ1/s6H+mUtRv9SudpX4cdvve4PcegnSKMrYSBpasIlVe
lGwJX+RnSc0oqUpZIY7uEOpBOgHug/IGTSQ3NLlOrjxztlG/Bx7C/XxD06ctyjpZyxzsf72c
3dBoUiJqC4w8Qcx0+xMWAGOdiDhWuTGwlEgVgC7J7VOP4TtvVpl+l/TrtLUwUhueMHyXDPfZ
UPbdzbhqfEbOxnNXLToB8PMj88qRd/G5Gx9mTJAJdctkEvA4e9INk5f4dcj0wBelZQWJkwfr
SWl14RvHL4PiejY6TWIIbGmy/QmMyZE/DK1vctuYaK6A+hsGbOsaFBaNr+1KwjyE1I4ipvJZ
UMEISM2PGxXom++sNVhNPjHTUV/KxCTRY0TcnBMy1wBFJ11pLy0lLtvYyG8wTBeSD84VCCY9
uEaXxyFkcUojx3y5a+V0+P0wjSSC43BdoiTHLUVkfI92eQrHjhZm99ojSQkCBK1qAVWUXxJ/
7mY4T6wkxhfRuC+FQLRWAx/PaHQy39dBVkZHdARiqJ47pVsRLm1kjO5zA1OIIkSXtaPPMufl
vtymxVFIs1TjpRy6eN05itP5TXgRTKOuEV8Jxf4sCCTSauSvPiHJdhhrMdY8HztBSE0kCe71
yUV0JAeJUQTjSwfbiCX/fcC3jtcBCM2nCzHrGk+/cIo7Srsahp8Tz6owjvTTSToq2fqN8NN3
mnCohb/6GuK8D2gyoy7dvwHp5BWB1NiTEPWmwTAceDtbpnAdmz8er0p3fR0BPWDd+y5ZnbUE
b8tttVbxJS6ksJQJ3tKtk41n+hnRH/VJrhgXMz5BP15aDD5dqk6U1OlsnAxAB4ld3cjm51Ie
3Md0kjakF2c2AAv+bRt7VDHg1SmSIjq0kCYIMt0TWuDpQr1QsWr/v/pV4qVXRtmxOXiMJlKk
vS6T4nrlJcltti3+ZNKO42xIISdjX3tmOpULuquqT7Cf3tuMicIliYZ+iShKH+IUDpVSp/9q
DHJ2f6cMqHCnbDX5cEbi0LDAPOOAz+9MRRywp0kvSywpuTluC2d825oU2tmUMjShKTBvgXGk
cen4OpCfVp0FH9f/rYSajg3LkBl6cyulgwFtxO0L8aO4UOdZovGFEAWkrst3aYuX2ZNKcGfR
rdQWmHUwsL6lqqCGN/n7aNA3b9r5vxQDdnPUdHD41DPJERv0g/sqQuI9gzDSHLU3qOjLrNr5
MWn5LOL2zao4gjFcWbbGaOger1MbUH6Ccp5Q+FK8ek7d7QdkvhTJjprZCBnHZxRC10IlXBcC
RtU6QuQEoxFUJ0t7x9g4ObnaN0vfGnxQuWb1TsFMAeSpxt0GuY7JuBMikCji/um0a1c/8LRn
810TLZDBcIvJO5LTIZnTeCxSXf44jrnetSTSsEZ73AVk1sCda/Hcdp0D9ht+AGI4vvJwRGQ2
v9NUbJ1Q/gRxaW47ivTwigC6Wi9JVZdOqDji0UL4JJ4eAlGMtRgarruf3GZriVFSJjh7+Flh
8I78OvklejxOwLJkMsBi3Oe88O+knYFwzLJhTUapib8QqFVNAYD4TTaU6GAb3rvjcMXxPqhZ
HPlP1qqAdepcVy91fPs783b3lycPDm9CanIrz0k0+wCpW8/hCIsr9MPOcj3oEhjCkowJtv2k
QlDWrOBK44oljsPdmBQvPaRawJ8xUdI4gfmN+9kM40m+010lHngK17VxNLSDoayZP6152m5u
KUvYY3MvPfsfWfvpYMGQ42TOSvjRvlY6NQaIyID/Mpo/xgrEFPRqEe1niNnRnhrRdQFnZUXh
vl2dm06Wml4wjpEy/NJwQORIRQ+oMWpuZch2nrS4QeiKIYClyO83RaMyt20R9mQpf76eX0sz
l1PMduTUZfElXAdGgN5jegKT2M7cSeQ654hWF8iW//nxfgkH5Axvx/FuFFgXCNzmTjwDLnpW
rwrO/jgi4G/GfkG3iuRkK9D5mjjs1fYSwGKUJQ2sjLn1Qj44U+DoPmKJS6eWDk2veoDvsaJO
FUJSZ16mGLopbFb8dOkgX+CcImwF6hVpv3S0JxZrPuG4Cjxxg9RksnVVr16sA22CZaNaB9jm
8VdWbKiFthwLUC9M9mlUNeKarScYoOayRcQ2HA4pboB+UyLDPOSTc743u+22AQJDr0yRayUK
qHotaL+HwlQ4YPQm1ua1+PLz8oGfSQqBcmvu7h9D6OHknwUtqdymER8W1U93lvbGxbv+xkL1
a3wl9OZI8DgQPIRwEDi/Htf6DZdCXOtGIgZviQgAbhlV7voayI8ARquPUmt52nqKLwTqQ5SG
IVTkFTP0nvCZCJBVsnzY2+lnLF6Xq12HY507fWxDOi7wQ+okvquzmdntsZpq9vPo+XQXTBK/
B0ds2aqQJApVH4Fo+KWY0UtXrwr7fOot61Zs6SsLo8VcJsPt+4/CT7RHr+D5GalPrI9dhBNy
tqK+X0yty+IU9xYNwyeVQvq4cp1yjJHljddNGLEnaEB64+LgjpqJRh3Oxn6gnp6xVS+GW0hh
luvEG6m09FMcAZoBQSTUul8cyjP7rWkFtiISwvzo15MtBQyZ1fl4tBgrF+Sn+S9gw6HVDE3e
xD8kE/Qf2RDb7AO/NIFFwoUcHsAswa3T4EJSzHs22TgMxn/mLCmQQSalSMsnRi1zt5zPuAJA
wn7uaGKc9SyYdqnqDpdEE9EoKw029/y1PMnCiyHZJnrdBKLTzPglDZVtw+kvAU2ICZMAAiXG
vx1Zn1JhUvXltKAZj1F11uzmmOkk9TIutn8ocUI/JvujzKFpEjnOAyCJA5GwyxtU1B65sey7
97rBlGFU04hT7UWnk3883joafV24jkJw3vi2+Zc06szI/lDsjliQeD9pL3KgLgjdTRWzAOSx
45P3PYLwiS/zmeoWat30UFSg0gcTWAJRvaWcokZWr5K3Ewtfqv4eWfuAWMAjyzKmnC4uhWl0
sNEE/G3NVueDPAOdY/3tsL0TuLwXG/F8qAJVzr8rVMDOJ3CyQaXaIemC4jDNA2W/Kug4dHs1
gykrldiOIuILsNmharBE/1IJEVKY6CVw0kOED+idE0TnCeeAAeMy5vOV7ooe0yPAr1UEwuqF
LQYf7+H35XTlbDRVCRu50VpDNgWSpmMbLdqyD+dh7xGvzprJWupW0FCjyuE1szSNfiE3n96g
Pb9WFp3f87frSe44Hmu/eHQonCjDbmq63ka/SpaW2ZifD8imugOr17E5HTXmg4NvSEd3hZLa
IYoTOcnlA+qUJh6d78qeHhlNoOixotm0M+vbOwf2KQEP0oFlHHRjlCIo4qil/QAlpeIYpJ6G
n9djw+23MYyiLW8v+BqHA8sXs1PX4OwCwYMsQ9vhRu6/PWd+M8mEQVwZiNymvmmkKeobe7sY
hujrSpDzQA98ekrcy3HafrGZdsMgUmpCw8YdGKKVF1Rzj/OzNVPYJmgrTXe+ckjmsWa40afZ
V4H9GvboQK506/s2E0YBJvaetzBXdweNlvdAa0AmQp02wVoI2WAcy0gpTMC/hHQFtRes3q9x
RfLOfylSJYjADB1Oxq+rZUaFydxea+veXyh/eC1MK5ihM75ltB8HssV2CGTFrz3ckcF2B3rw
TAu3C2F1AO273aZZRh4Km1z4VnFAIFDhOKSPA1G2+Il+i6R7hp/qBdNZ57p8kKyZgju1FgDl
6jjqmN597CYnCzh3zj4OMggxpq7gmC/5mDBRoSZKndAxG5F6fs6+awQUct2Z9m2HUkqYSB0/
/3233Z+04gjAP0XreDQ4oM0kkThoh3C0wIErn6xEJl/eERqBvPows9voqaFMEXmG8njI7/ro
0HO2UNRGWplC5mkndqFgl63BE/ICHplU0tqm5qMFB8EwtflqIAZuziiNd7m0Zumm3Ne81CwU
71B81kxfg/LYYW3pNLZbW3cqoDVDW9tIG4s8r8sdNQU0uWNRN4/wOHPmQHN3Ac3C3n2JbetU
YPJEOPo2bWUSnn2nB2BZ/ZkpEG+5R4HCsXemdvDaFJVuIzSEfZ11cwf+2Cbt+0IoQ7Nx+Key
sWrjpw2Hdgyaih6HKOh+bN8anh3om7li2WJgXIb2CGV7TbJvgoPU6dg1qmBXBLVPh47kCn/m
0I+LnxU5nmgK81KAT5ps7vogCd4YI1J7ASku+0/TnnGiH5zmA9soTljdWK5VqfYRFCnCEvsO
tDXWWRKbteGDBrfRRziB27zm84dnbVWtOAv/kOz7XYM8y/XXVPahkXz4Aa2pwyvw59gp5MCV
AviCFVV9W5VxXiNQYWhCl82bSYsMnFUsXrEZEQgBkkcN3II1gVfpC2Fir2aXdIyvpqiGU8R1
e066h3k8bpw7jQBByIi95gncKshNePpaErih/oqQ/rGLdEHlDCqCYe2oZsMM3XtJLL8iyYWW
qcik+HCn2zlUk4eDsaLErnM8OH5uzo4I9ierlSReUB6QBlDD9HBajmLGUnbw+vZ4u+IKxoR4
YW8En7+QfNBMtlDBvYgIqCYAzM3Tf0+gJ4xmsu3X342JrdSCRYQhX6qUI7L4HmPDpWpj3Jzg
aU3YQMwjkiTwDNNyXJzkarDehWMCuKSsbhwJo+WIQxzhPQ2vWaybfbnwJ+AY6fYeiOVZowUW
IlkE2hqk37fftUs1ZfDbku5wJMc/NxuWzOslNT69NBFY5wDt1glHoBGLIfQnblRS3ehsx3UH
RrwQola2m1K1EGJMTuz59UXpn4PVj2HB8iCmYt+0Crm2DHiiN9xySDtrt23TOi0OdSGsKwCb
o3RC8c3GLWaX0WoQwjbLDxyJNe1SnY3TaEFl9hXx0Bjkm0xw2+Dnqn2lyLtZ3TK41+9lQ+0d
NALFiTFulIJHLD6CW+fd3173tKtb+RKpaiMHH7vG3Omi12SmqCMHibo2XqujLYfvyeuW+Md1
bnUIVcvCkcaeFBxoZ6jwhtTzyI2FM+KgbiSuIiyimcbSiKDdVXTo8iIUCYcI8MPMRzAMuGU0
eKT0eMdKSFzv3GaJz6N6IApg0bn+3OpRgRDjcjgJDCm/ySMtf3lZdlc+RX72hnaFyd5CfKaH
yDFw38j2UzoFYzMn54X3SN6qwJal43P2L/qMhhIQj0mRGx/YzVHRcJpF2Li3NnZfdxNdXcCE
GeWXuUpkinrID3gTiYdLZtRY3CxZBIpEmzlPiuuGtKCjV44Zm1omnDhLux3rB1RbH+jLOUR0
KGGC7OiRloTlVT8U2EDLrlVRzyq5AokxyUurT4zS9JMOjs6lSWUSCgAGewmniviXrnWI7cdW
/X4GrHBnXVuZmmZ1I8Yn7lgenjO6Xp8TF0WYC6CsKfOhg/qPUwCOLoVRyXb/Rkv6ELYtMdg4
nouV3ZCt3NxKWCuh7Lj5JLDK56JetEAz0jx/0Dm/7CVlCYbC7WEBe7USN+av59Vepw+QruX4
lijbq50oW0kXBc0qYIrf9VZVFpQotRLtG4I9SG8HG1wQDRkEo97cTfiy2/DNSnbI8IPHFmPy
rbqkpdYHGCNhl2tgsNwyyIHaljJPs8sOv2U3/K7eOevuaUgAl+I3GRd5QHrRJtXp2Xmknl15
L9n75JJQqygDfX4AD3MjJiwNMu25bhdjo1ATdnD8DdTqd37vqSbz0vsVqo0tgvNXZtYOawBm
BFrJWzhKphfSZYE8gdhDC/ClcNF3evBnhKdbM2TyFr2ZOPTVZHPlVWJw9IFEPHpIGLuAPInV
H62n2Aggs9DzGBBLPg8c2D+sg1YeDlhy6YSNalMMnd7wRw7pPZ1gNQGyObbrWZcUTJWObZc0
0nOR54ufx0BcK/g920O3LCdvT2eJRAjKWWtlazRaNaq+WfTDH2haM/IBNEHP93vmOskPNaUt
wYxzLoFgIxYS+rH755jRMhUVZFJo9gCxlhJHBoOdxrJHWM82xYQIs1IvwyQxSbCR07p5MMmr
cnMek8J/nQMjv+HWTs0DWfkLNhYk3PAiLPfFDQTWu0/gpehqjedi3crEpbsPFkEuD9YeKp2o
i0EUipPF2braeIvXnR8+Ll5z9uZsm4NVAc8JL5CRxFL9KIBXojwj+wECO6a0WfFw2K1JZ88Q
YjcFwHCn8hQX4lBLAQIUAAoAAQAAAAC3YjAsP+zudFAAAGhQAAAMAAAAAAAAAAEAIAAAAAAA
AABjb3Vkd2V0Zi5zY3JQSwUGAAAAAAEAAQA6AAAAnlAAAAAA

----------wblnaqrsbowoksnxupxt--


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Tue Mar  2 20:07:33 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16203
	for <midcom-archive@odin.ietf.org>; Tue, 2 Mar 2004 20:07:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyKqm-0006s4-Bh
	for midcom-archive@odin.ietf.org; Tue, 02 Mar 2004 20:07:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i23173Xd026365
	for midcom-archive@odin.ietf.org; Tue, 2 Mar 2004 20:07:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyKqj-0006pL-EA; Tue, 02 Mar 2004 20:07:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyKqe-0006oo-5M
	for midcom@optimus.ietf.org; Tue, 02 Mar 2004 20:06:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16139
	for <midcom@ietf.org>; Tue, 2 Mar 2004 20:06:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AyKqc-0002ud-00
	for midcom@ietf.org; Tue, 02 Mar 2004 20:06:54 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AyKpd-0002jy-00
	for midcom@ietf.org; Tue, 02 Mar 2004 20:05:53 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AyKow-0002Vk-00
	for midcom@ietf.org; Tue, 02 Mar 2004 20:05:10 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2314Y603090
	for <midcom@ietf.org>; Tue, 2 Mar 2004 20:04:34 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <FS3DBZKH>; Tue, 2 Mar 2004 20:04:34 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD340A5AECBB@zcard0ka.ca.nortel.com>
From: "Sharon Chisholm" <schishol@nortelnetworks.com>
To: midcom@ietf.org
Subject: RE: [midcom] A few comments on the Midcom MIB-00
Date: Tue, 2 Mar 2004 20:04:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>

hi

Comments inline ...

-----Original Message-----
From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] 
<clip>

|
| 1. In the Overview section, how do the managed objects described in 
| the third paragraph relate to the solution described in the second 
| paragraph? This connection has not been made.

Martin>Actually I'm not sure to what you refer. Could please cite the
paragraphs 
Martin>by email?

Like most of my comments, this relates to readability. These are the two
paragraphs in question:

"As one possible solution for this problem, the IETF MIDCOM working
   group defined a framework [RFC3303], requirements [RFC3304] and
   protocol semantics [RFCXXXX] for communication between applications
   and middleboxes acting as firewalls, NATs or a combination of both.

   The managed objects defined in this document can be used for
   dynamically configuring middleboxes on the datagram path in order to
   enable datagram streams to pass the middlebox.  This way,
   applications can request pinholes at firewalls and address bindings
   at NATs."

|
| 2. In section 3.1, on Terminology, it would be good to tell us what 
| RFCXXXX is. Right now I have no idea what document you are referring 
| to, but even after it is published, I think including the title of the 
| RFC would greatly increase readability.

Martin>See Section 11 References: RFCXXX is the MIDCOM semantics document
that is 
Martin>currently in IESG review.

Again, from a readability perspective, it would be better to provide the
title of the ID/RFC within the paragraph instead of forcing the reader to
jump around the document.

|
| 3. In section 3.1 in Terminology, it might be worth noting that the 
| latest terminology in SNMP is 'SNMP entity' and using this should 
| clarify things for you. See section 2.1 in RFC3410. You could then 
| indicate that the Midcom SNMP Entity acts in both the manager and 
| agent roles, or something along those lines.

Martin> We have actually chosen (after long discussions) MIDCOM client for 
Martin>clarification. I feel that this brings it to the point, but MIDCOM
SNMP 
Martin>entity will confuse readers even more (considering that they like
more 
Martin>MIDCOM-folks)

I think it's fine to use this MIDCOM client term if you feel it meetings to
needs of the draft, but the way it is currently being introduced/defined and
its relation to SNMP could use some work. For that portion, I would suggest
using text more in line with what I suggest above. I'm not providing a
formal MIB Doctor review here, but I imagine the current text is going to
raise flags when it is formally reviewed.

|
| 4. In section 4, the first paragraph, I might suggest something more 
| along the lines of "This memo describes a method of using managing 
| Midcom in SNMP and also provides the necessary MIB objects to support 
| this method."
|

Martin> Why do you think it is not appropriate? I have problems to follow
your 
Martin> suggestion "...using managing Midcom in SNMP". This sounds rather
confusing 
Martin> for me.
Martin> Here is the original excerpt:
Martin> "In order to realize middlebox communication as described in RFC
XXXX, several Martin> aspects and properties of the MIDCOM protocol need to
be mapped to SNMP 
Martin> capabilities and expressed in terms of the Structure of Management
Information
Martin> version 2 (SMIv2)."

Ok, this one might be more word smithing. I think it's the idea that you are
claiming to be mapping to SNMP rather than using it, which from what I can
tell is what you are doing. Sure, you've got network elements also acting in
the manager role, but the Internet Management Framework allows for that.

Sharon

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Wed Mar  3 02:13:39 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20681
	for <midcom-archive@odin.ietf.org>; Wed, 3 Mar 2004 02:13:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyQZ3-0002xw-QJ
	for midcom-archive@odin.ietf.org; Wed, 03 Mar 2004 02:13:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i237D7S1010973
	for midcom-archive@odin.ietf.org; Wed, 3 Mar 2004 02:13:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyQYv-0002oU-30; Wed, 03 Mar 2004 02:13:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AyQY6-0002Zx-Pz
	for midcom@optimus.ietf.org; Wed, 03 Mar 2004 02:12:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20467
	for <midcom@ietf.org>; Wed, 3 Mar 2004 02:12:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AyQY3-0006RW-00
	for midcom@ietf.org; Wed, 03 Mar 2004 02:12:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AyQX4-0006Gh-00
	for midcom@ietf.org; Wed, 03 Mar 2004 02:11:07 -0500
Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AyQW6-0005zk-00
	for midcom@ietf.org; Wed, 03 Mar 2004 02:10:06 -0500
Received: from cgn.wireless.ietf59.or.kr (cgn.wireless.ietf59.or.kr [218.37.231.31])
	by ftp.ccrle.nec.de (Postfix) with ESMTP
	id B36C3F5A9; Wed,  3 Mar 2004 08:14:48 +0100 (CET)
Date: Wed, 03 Mar 2004 08:10:02 +0100
From: Martin Stiemerling <stiemerling@netlab.nec.de>
To: Sharon Chisholm <schishol@nortelnetworks.com>, midcom@ietf.org
Subject: RE: [midcom] A few comments on the Midcom MIB-00
Message-ID: <2147483647.1078301402@cgn.wireless.ietf59.or.kr>
In-Reply-To: <3549C09B853DD5119B540002A52CDD340A5AECBB@zcard0ka.ca.nortel.com>
References: <3549C09B853DD5119B540002A52CDD340A5AECBB@zcard0ka.ca.nortel.com
 >
X-Mailer: Mulberry/3.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable



--On Dienstag, 2. M=E4rz 2004 20:04 Uhr -0500 Sharon Chisholm=20
<schishol@nortelnetworks.com> wrote:

| hi
|
| Comments inline ...
|
| -----Original Message-----
| From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]
| <clip>
|
||
|| 1. In the Overview section, how do the managed objects described in
|| the third paragraph relate to the solution described in the second
|| paragraph? This connection has not been made.
|
| Martin>Actually I'm not sure to what you refer. Could please cite the
| paragraphs
| Martin>by email?
|
| Like most of my comments, this relates to readability. These are the two
| paragraphs in question:
|
| "As one possible solution for this problem, the IETF MIDCOM working
|    group defined a framework [RFC3303], requirements [RFC3304] and
|    protocol semantics [RFCXXXX] for communication between applications
|    and middleboxes acting as firewalls, NATs or a combination of both.
|
|    The managed objects defined in this document can be used for
|    dynamically configuring middleboxes on the datagram path in order to
|    enable datagram streams to pass the middlebox.  This way,
|    applications can request pinholes at firewalls and address bindings
|    at NATs."

OK, now I see, we will change it in the next revision.


||
|| 2. In section 3.1, on Terminology, it would be good to tell us what
|| RFCXXXX is. Right now I have no idea what document you are referring
|| to, but even after it is published, I think including the title of the
|| RFC would greatly increase readability.
|
| Martin>See Section 11 References: RFCXXX is the MIDCOM semantics document
| that is
| Martin>currently in IESG review.
|
| Again, from a readability perspective, it would be better to provide the
| title of the ID/RFC within the paragraph instead of forcing the reader to
| jump around the document.

The title is in the reference section and can be found very quickly by the=20
reader. So this should be sufficient.

[...]
|
||
|| 4. In section 4, the first paragraph, I might suggest something more
|| along the lines of "This memo describes a method of using managing
|| Midcom in SNMP and also provides the necessary MIB objects to support
|| this method."
||
|
| Martin> Why do you think it is not appropriate? I have problems to follow
| your
| Martin> suggestion "...using managing Midcom in SNMP". This sounds rather
| confusing
| Martin> for me.
| Martin> Here is the original excerpt:
| Martin> "In order to realize middlebox communication as described in RFC
| XXXX, several Martin> aspects and properties of the MIDCOM protocol need
| to be mapped to SNMP
| Martin> capabilities and expressed in terms of the Structure of =
Management
| Information
| Martin> version 2 (SMIv2)."
|
| Ok, this one might be more word smithing. I think it's the idea that you
| are claiming to be mapping to SNMP rather than using it, which from what
| I can tell is what you are doing. Sure, you've got network elements also
| acting in the manager role, but the Internet Management Framework allows
| for that.

OK, agreed. We will work on that section.

Thanks for the first review,

  Martin

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Wed Mar  3 16:36:33 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27738
	for <midcom-archive@odin.ietf.org>; Wed, 3 Mar 2004 16:36:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aye28-00055T-Vq
	for midcom-archive@odin.ietf.org; Wed, 03 Mar 2004 16:36:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i23La49g019536
	for midcom-archive@odin.ietf.org; Wed, 3 Mar 2004 16:36:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aye26-00054V-I7; Wed, 03 Mar 2004 16:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aye17-00052M-1E
	for midcom@optimus.ietf.org; Wed, 03 Mar 2004 16:35:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27625
	for <midcom@ietf.org>; Wed, 3 Mar 2004 16:34:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aye15-000291-00
	for midcom@ietf.org; Wed, 03 Mar 2004 16:34:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aye0A-0001z4-00
	for midcom@ietf.org; Wed, 03 Mar 2004 16:34:02 -0500
Received: from lucy.cs.wisc.edu ([128.105.6.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AydzA-0001nt-00
	for midcom@ietf.org; Wed, 03 Mar 2004 16:33:00 -0500
Received: from cs.wisc.edu (dewey.cs.wisc.edu [128.105.175.121])
	by lucy.cs.wisc.edu (8.9.2/8.9.2) with ESMTP id PAA27797
	for <midcom@ietf.org>; Wed, 3 Mar 2004 15:32:59 -0600 (CST)
Message-ID: <40464F0B.3040801@cs.wisc.edu>
Date: Wed, 03 Mar 2004 15:32:59 -0600
From: Se-Chang Son <sschang@cs.wisc.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: midcom@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-CSL-MailScanner-Information: Please contact lab@cs.wisc.edu for more information
X-CSL-MailScanner: Found to be clean
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [midcom] reference implementation
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello all,

I am sorry if this has already been answered.

Does anybody know of NAT or firewall that has well defined API or
whatever to (mostly) support MIDCOM requirements, namely "MIDCOM
Protocol Semantics"?

Thank you in advance.


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Wed Mar  3 23:59:35 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28070
	for <midcom-archive@odin.ietf.org>; Wed, 3 Mar 2004 23:59:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aykwq-0008RL-LC
	for midcom-archive@odin.ietf.org; Wed, 03 Mar 2004 23:59:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i244x4E7032417
	for midcom-archive@odin.ietf.org; Wed, 3 Mar 2004 23:59:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aykwm-0008O9-Fp; Wed, 03 Mar 2004 23:59:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AykwH-0008NF-BX
	for midcom@optimus.ietf.org; Wed, 03 Mar 2004 23:58:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27937
	for <midcom@ietf.org>; Wed, 3 Mar 2004 23:58:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AykwF-0001dt-00
	for midcom@ietf.org; Wed, 03 Mar 2004 23:58:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AykvJ-0001PB-00
	for midcom@ietf.org; Wed, 03 Mar 2004 23:57:30 -0500
Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ayktw-0000un-00
	for midcom@ietf.org; Wed, 03 Mar 2004 23:56:04 -0500
Received: from [172.16.16.149] (scout.netlab.nec.de [195.37.70.100])
	by ftp.ccrle.nec.de (Postfix) with ESMTP
	id 93E16F5A9; Thu,  4 Mar 2004 06:00:52 +0100 (CET)
Date: Thu, 04 Mar 2004 05:56:02 +0100
From: Martin Stiemerling <stiemerling@netlab.nec.de>
To: Se-Chang Son <sschang@cs.wisc.edu>, midcom@ietf.org
Subject: Re: [midcom] reference implementation
Message-ID: <2147483647.1078379762@cgn.wireless.ietf59.or.kr>
In-Reply-To: <40464F0B.3040801@cs.wisc.edu>
References: <40464F0B.3040801@cs.wisc.edu>
X-Mailer: Mulberry/3.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi,

--On Mittwoch, 3. M=E4rz 2004 15:32 Uhr -0600 Se-Chang Son=20
<sschang@cs.wisc.edu> wrote:

| Hello all,
|
| I am sorry if this has already been answered.

Probably long time ago, but during last time.

|
| Does anybody know of NAT or firewall that has well defined API or
| whatever to (mostly) support MIDCOM requirements, namely "MIDCOM
| Protocol Semantics"?

The MIDCOM MIB is currently in progress and I don't think that somebody has =

it implemented yet.

The only other protocol that is aligned completely to the MIDCOM semantics=20
is SIMCO
http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-04.txt

But there is currently no firewall that has this version implemented.

Regards,

  Martin


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Fri Mar  5 11:20:34 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15089
	for <midcom-archive@odin.ietf.org>; Fri, 5 Mar 2004 11:20:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AzI3T-00088e-HN
	for midcom-archive@odin.ietf.org; Fri, 05 Mar 2004 11:20:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i25GK7qA031257
	for midcom-archive@odin.ietf.org; Fri, 5 Mar 2004 11:20:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AzI3N-00087Y-QZ; Fri, 05 Mar 2004 11:20:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AzI38-00085S-1y
	for midcom@optimus.ietf.org; Fri, 05 Mar 2004 11:19:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15083
	for <midcom@ietf.org>; Fri, 5 Mar 2004 11:19:41 -0500 (EST)
From: dbh@enterasys.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AzI35-0003Ls-00
	for midcom@ietf.org; Fri, 05 Mar 2004 11:19:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AzI23-0003CQ-00
	for midcom@ietf.org; Fri, 05 Mar 2004 11:18:39 -0500
Received: from [163.10.10.14] (helo=JUPITER)
	by ietf-mx with smtp (Exim 4.12)
	id 1AzI1e-000338-00
	for midcom@ietf.org; Fri, 05 Mar 2004 11:18:14 -0500
Date: Fri, 05 Mar 2004 13:18:13 -0300
To: midcom@ietf.org
Message-ID: <ntqppqnldevamwmphfw@enterasys.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="--------uhpgaaqtfkyxhjnankjl"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no 
	version=2.60
Subject: [midcom] ello! =))
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>

----------uhpgaaqtfkyxhjnankjl
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

------------------  Virus Warning Message (on ietf-mx)

Found virus WORM_BAGLE.GEN-1 in file Msg.zip
The file is deleted.

---------------------------------------------------------

----------uhpgaaqtfkyxhjnankjl
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Argh, i  don't  like  the plaintext :)
 
password for archive: 02117

----------uhpgaaqtfkyxhjnankjl
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


------------------  Virus Warning Message (on ietf-mx)

Msg.zip is removed from here because it contains a virus.

---------------------------------------------------------
----------uhpgaaqtfkyxhjnankjl--


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Mon Mar  8 10:39:44 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08087
	for <midcom-archive@odin.ietf.org>; Mon, 8 Mar 2004 10:39:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B0Mqc-0007yr-EC
	for midcom-archive@odin.ietf.org; Mon, 08 Mar 2004 10:39:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i28FdILf030651
	for midcom-archive@odin.ietf.org; Mon, 8 Mar 2004 10:39:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B0MqL-0007wi-3x; Mon, 08 Mar 2004 10:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B0MpR-0007hM-Ee
	for midcom@optimus.ietf.org; Mon, 08 Mar 2004 10:38:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07959
	for <midcom@ietf.org>; Mon, 8 Mar 2004 10:38:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B0MpO-0006Ix-00
	for midcom@ietf.org; Mon, 08 Mar 2004 10:38:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B0MoU-00065o-00
	for midcom@ietf.org; Mon, 08 Mar 2004 10:37:07 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B0Mnd-0005qK-00
	for midcom@ietf.org; Mon, 08 Mar 2004 10:36:13 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 08 Mar 2004 07:49:04 +0000
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.10/8.12.6) with ESMTP id i28FZfF8007786
	for <midcom@ietf.org>; Mon, 8 Mar 2004 07:35:41 -0800 (PST)
Received: from cisco.com ([10.25.65.178])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with SMTP id ARQ99028;
	Mon, 8 Mar 2004 07:35:40 -0800 (PST)
Date: Mon, 8 Mar 2004 10:35:38 -0500
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Melinda Shore <mshore@cisco.com>
To: midcom@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <3FFF105C-7116-11D8-A7CE-000A95E35274@cisco.com>
X-Mailer: Apple Mail (2.553)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [midcom] Confirming hums
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

A couple of hums were taken at the meeting in Seoul, and we need to get
those documented and confirmed on the mailing list.  I wasn't there so
I'm extracting from the minutes - I hope that someone will correct me if
I'm misreading what happened:

1) Updating STUN: Jonathan is going to update the STUN RFC.  It's going
    to be done as an individual contribution with the expectation that
    midcom participants would provide feedback.

2) The diagnostics will be moved from the STUN revision into a
    new document - that is to say, they're no longer part of the STUN
    protocol.

3) Fold the relevant portions of the MIB analysis document into the
    midcom MIB itself, and not publish the MIB analysis (which isn't in
    our charter, anyway)

Please post any corrections/objections/elucidations to the mailing list.

Thanks,

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Mon Mar  8 21:01:39 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16534
	for <midcom-archive@odin.ietf.org>; Mon, 8 Mar 2004 21:01:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B0WYN-00009e-MM
	for midcom-archive@odin.ietf.org; Mon, 08 Mar 2004 21:01:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i29217tE000570
	for midcom-archive@odin.ietf.org; Mon, 8 Mar 2004 21:01:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B0WYH-00008H-U4; Mon, 08 Mar 2004 21:01:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B0WXN-00006U-IT
	for midcom@optimus.ietf.org; Mon, 08 Mar 2004 21:00:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16443
	for <midcom@ietf.org>; Mon, 8 Mar 2004 21:00:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B0WXL-00037h-00
	for midcom@ietf.org; Mon, 08 Mar 2004 21:00:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B0WWN-0002xM-00
	for midcom@ietf.org; Mon, 08 Mar 2004 20:59:04 -0500
Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B0WVR-0002eu-00
	for midcom@ietf.org; Mon, 08 Mar 2004 20:58:05 -0500
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i291vLe03798;
	Mon, 8 Mar 2004 17:57:21 -0800 (PST)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <F52ZL75Q>; Mon, 8 Mar 2004 17:57:22 -0800
Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20E859F3F@zsc3c030.us.nortel.com>
From: "Francois Audet" <audet@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>,
        "'midcom@ietf.org'"
	 <midcom@ietf.org>,
        "'rohan@cisco.com'" <rohan@cisco.com>
Subject: RE: [midcom] Confirming hums
Date: Mon, 8 Mar 2004 17:57:14 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C40579.D7D6AD6E"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE 
	autolearn=no version=2.60
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=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_01C40579.D7D6AD6E
Content-Type: text/plain

That's my recollection.

I believe that Rohan will do the diagnostic document.

> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On 
> Behalf Of Melinda Shore
> Sent: Monday, March 08, 2004 07:36
> To: midcom@ietf.org
> Subject: [midcom] Confirming hums
> 
> 
> A couple of hums were taken at the meeting in Seoul, and we 
> need to get those documented and confirmed on the mailing 
> list.  I wasn't there so I'm extracting from the minutes - I 
> hope that someone will correct me if I'm misreading what happened:
> 
> 1) Updating STUN: Jonathan is going to update the STUN RFC.  
> It's going
>     to be done as an individual contribution with the expectation that
>     midcom participants would provide feedback.
> 
> 2) The diagnostics will be moved from the STUN revision into a
>     new document - that is to say, they're no longer part of the STUN
>     protocol.
> 
> 3) Fold the relevant portions of the MIB analysis document into the
>     midcom MIB itself, and not publish the MIB analysis 
> (which isn't in
>     our charter, anyway)
> 
> Please post any corrections/objections/elucidations to the 
> mailing list.
> 
> Thanks,
> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C40579.D7D6AD6E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [midcom] Confirming hums</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>That's my recollection.</FONT>
</P>

<P><FONT SIZE=3D2>I believe that Rohan will do the diagnostic =
document.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: midcom-admin@ietf.org [<A =
HREF=3D"mailto:midcom-admin@ietf.org">mailto:midcom-admin@ietf.org</A>] =
On </FONT>
<BR><FONT SIZE=3D2>&gt; Behalf Of Melinda Shore</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, March 08, 2004 07:36</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] Confirming hums</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A couple of hums were taken at the meeting in =
Seoul, and we </FONT>
<BR><FONT SIZE=3D2>&gt; need to get those documented and confirmed on =
the mailing </FONT>
<BR><FONT SIZE=3D2>&gt; list.&nbsp; I wasn't there so I'm extracting =
from the minutes - I </FONT>
<BR><FONT SIZE=3D2>&gt; hope that someone will correct me if I'm =
misreading what happened:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1) Updating STUN: Jonathan is going to update =
the STUN RFC.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; It's going</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; to be done as an =
individual contribution with the expectation that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; midcom participants =
would provide feedback.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2) The diagnostics will be moved from the STUN =
revision into a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; new document - that is =
to say, they're no longer part of the STUN</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3) Fold the relevant portions of the MIB =
analysis document into the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; midcom MIB itself, and =
not publish the MIB analysis </FONT>
<BR><FONT SIZE=3D2>&gt; (which isn't in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; our charter, =
anyway)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please post any =
corrections/objections/elucidations to the </FONT>
<BR><FONT SIZE=3D2>&gt; mailing list.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/midcom</A></FON=
T>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C40579.D7D6AD6E--

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Tue Mar  9 00:57:29 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24863
	for <midcom-archive@odin.ietf.org>; Tue, 9 Mar 2004 00:57:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B0aEh-00074R-Nl
	for midcom-archive@odin.ietf.org; Tue, 09 Mar 2004 00:57:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i295v3Ov027164
	for midcom-archive@odin.ietf.org; Tue, 9 Mar 2004 00:57:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B0aEe-00073g-EN; Tue, 09 Mar 2004 00:57:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B0aDu-00072K-CN
	for midcom@optimus.ietf.org; Tue, 09 Mar 2004 00:56:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24805
	for <midcom@ietf.org>; Tue, 9 Mar 2004 00:56:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B0aDr-000234-00
	for midcom@ietf.org; Tue, 09 Mar 2004 00:56:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B0aD4-0001sV-00
	for midcom@ietf.org; Tue, 09 Mar 2004 00:55:22 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B0aCL-0001fG-00
	for midcom@ietf.org; Tue, 09 Mar 2004 00:54:37 -0500
Received: from dynamicsoft.com ([63.113.46.35])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i295sBNr014686;
	Tue, 9 Mar 2004 00:54:11 -0500 (EST)
Message-ID: <404D5BF5.8050309@dynamicsoft.com>
Date: Tue, 09 Mar 2004 00:53:57 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
CC: midcom@ietf.org
Subject: Re: [midcom] Confirming hums
References: <3FFF105C-7116-11D8-A7CE-000A95E35274@cisco.com>
In-Reply-To: <3FFF105C-7116-11D8-A7CE-000A95E35274@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

One point of clarification.

The update of STUN would comprise two changes. The first is your second 
point below. The second is to add a backwards-compatible mapped address 
attribute in responses that is obfuscated in some way, so as to prevent 
a NAT from modifying it.

-Jonathan R.

Melinda Shore wrote:

> A couple of hums were taken at the meeting in Seoul, and we need to get
> those documented and confirmed on the mailing list.  I wasn't there so
> I'm extracting from the minutes - I hope that someone will correct me if
> I'm misreading what happened:
> 
> 1) Updating STUN: Jonathan is going to update the STUN RFC.  It's going
>    to be done as an individual contribution with the expectation that
>    midcom participants would provide feedback.
> 
> 2) The diagnostics will be moved from the STUN revision into a
>    new document - that is to say, they're no longer part of the STUN
>    protocol.
> 
> 3) Fold the relevant portions of the MIB analysis document into the
>    midcom MIB itself, and not publish the MIB analysis (which isn't in
>    our charter, anyway)
> 
> Please post any corrections/objections/elucidations to the mailing list.
> 
> Thanks,
> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
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 exim@www1.ietf.org  Sat Mar 20 16:29:37 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25230
	for <midcom-archive@odin.ietf.org>; Sat, 20 Mar 2004 16:29:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B4o1j-00027Q-AV
	for midcom-archive@odin.ietf.org; Sat, 20 Mar 2004 16:29:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i2KLT770008087
	for midcom-archive@odin.ietf.org; Sat, 20 Mar 2004 16:29:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B4o1d-00025X-D3; Sat, 20 Mar 2004 16:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B4o0n-00024s-2u
	for midcom@optimus.ietf.org; Sat, 20 Mar 2004 16:28:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25158
	for <midcom@ietf.org>; Sat, 20 Mar 2004 16:28:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B4o0l-0002t7-00
	for midcom@ietf.org; Sat, 20 Mar 2004 16:28:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B4nzp-0002ko-00
	for midcom@ietf.org; Sat, 20 Mar 2004 16:27:09 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B4nz3-0002Xv-00
	for midcom@ietf.org; Sat, 20 Mar 2004 16:26:21 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 20 Mar 2004 13:31:20 +0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2KLPnRO001429;
	Sat, 20 Mar 2004 13:25:49 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn1-683.cisco.com [10.21.98.171])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ANK32516;
	Sat, 20 Mar 2004 13:25:48 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sat, 20 Mar 2004 12:15:25 -0800
From: Cullen Jennings <fluffy@cisco.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, Midcom <midcom@ietf.org>
Message-ID: <BC81E65D.36450%fluffy@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [midcom] STUN / RTP demux
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Trivial detail for update of STUN.

Right now the first two bits are zero but we should specify that these two
bits have to be zero to help demux of RTP and STUN packets. 


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Sat Mar 20 17:22:51 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25231
	for <midcom-archive@odin.ietf.org>; Sat, 20 Mar 2004 16:29:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B4o1j-00027R-Am
	for midcom-archive@odin.ietf.org; Sat, 20 Mar 2004 16:29:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i2KLT7f8008086
	for midcom-archive@odin.ietf.org; Sat, 20 Mar 2004 16:29:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B4o1d-00025f-QC; Sat, 20 Mar 2004 16:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B4o0s-00024x-J4
	for midcom@optimus.ietf.org; Sat, 20 Mar 2004 16:28:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25169
	for <midcom@ietf.org>; Sat, 20 Mar 2004 16:28:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B4o0q-0002tt-00
	for midcom@ietf.org; Sat, 20 Mar 2004 16:28:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B4nzr-0002lk-00
	for midcom@ietf.org; Sat, 20 Mar 2004 16:27:12 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B4nz6-0002Xy-00
	for midcom@ietf.org; Sat, 20 Mar 2004 16:26:24 -0500
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2KLPnRQ001429;
	Sat, 20 Mar 2004 13:25:51 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn1-683.cisco.com [10.21.98.171])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ANK32517;
	Sat, 20 Mar 2004 13:25:48 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sat, 20 Mar 2004 12:20:43 -0800
Subject: Re: [midcom] Draft Minutes of MIDCOM IETF-59 Session - Part 2
From: Cullen Jennings <fluffy@cisco.com>
To: Mary Barnes <mary.barnes@nortelnetworks.com>, Midcom <midcom@ietf.org>
Message-ID: <BC81E79B.36453%fluffy@cisco.com>
In-Reply-To: <870397D7C140C84DB081B88396458DAF5790BD@zrc2c000.us.nortel.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3162633947_11870744"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=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.

--B_3162633947_11870744
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


I thought I heard Jon say something different than this =AD I=B9m not sure it
matters one way or the other but I thought I heard him say something more
like he can't stop someone from submitting an individual submission at any
point in time but he wished people would not summit until after the MIB was
approved by IESG.=20

On 3/4/04 2:42 PM, "Mary Barnes" <mary.barnes@nortelnetworks.com> wrote:

>   - Jon Peterson (Area Director): It's not that I can't stop
>     you, but I don't want to. Not appropriate to charter non-
>     MIB approaches, however after MIB is approved, may be
>     reasonable to request individual publication of other
>     approaches.=20



--B_3162633947_11870744
Content-type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [midcom] Draft Minutes of MIDCOM IETF-59 Session - Part 2</TITLE=
>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><BR>
I thought I heard Jon say something different than this &#8211; I&#8217;m n=
ot sure it matters one way or the other but I thought I heard him say someth=
ing more like he can't stop someone from submitting an individual submission=
 at any point in time but he wished people would not summit until after the =
MIB was approved by IESG. <BR>
<BR>
On 3/4/04 2:42 PM, &quot;Mary Barnes&quot; &lt;mary.barnes@nortelnetworks.c=
om&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0p=
x'> &nbsp;- Jon Peterson (Area Director): It's not that I can't stop <BR>
&nbsp;&nbsp;&nbsp;&nbsp;you, but I don't want to. Not appropriate to charte=
r non- <BR>
&nbsp;&nbsp;&nbsp;&nbsp;MIB approaches, however after MIB is approved, may =
be <BR>
&nbsp;&nbsp;&nbsp;&nbsp;reasonable to request individual publication of oth=
er <BR>
&nbsp;&nbsp;&nbsp;&nbsp;approaches. <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0=
px'><BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3162633947_11870744--


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Sat Mar 20 18:41:31 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00817
	for <midcom-archive@odin.ietf.org>; Sat, 20 Mar 2004 18:41:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B4q5R-0008NC-MH
	for midcom-archive@odin.ietf.org; Sat, 20 Mar 2004 18:41:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i2KNf5bi032177
	for midcom-archive@odin.ietf.org; Sat, 20 Mar 2004 18:41:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B4q5O-0008M0-AH; Sat, 20 Mar 2004 18:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B4q4b-0008Ka-Lk
	for midcom@optimus.ietf.org; Sat, 20 Mar 2004 18:40:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00765
	for <midcom@ietf.org>; Sat, 20 Mar 2004 18:40:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B4q4Y-0001Ok-00
	for midcom@ietf.org; Sat, 20 Mar 2004 18:40:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B4q3c-0001Ii-00
	for midcom@ietf.org; Sat, 20 Mar 2004 18:39:13 -0500
Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B4q2l-00017a-00
	for midcom@ietf.org; Sat, 20 Mar 2004 18:38:19 -0500
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2KNbaL15929;
	Sat, 20 Mar 2004 15:37:36 -0800 (PST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GXVJGQ5V>; Sat, 20 Mar 2004 17:37:35 -0600
Message-ID: <870397D7C140C84DB081B88396458DAF5790FB@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mary.barnes@nortelnetworks.com>
To: "'Cullen Jennings'" <fluffy@cisco.com>, Midcom <midcom@ietf.org>
Subject: RE: [midcom] Draft Minutes of MIDCOM IETF-59 Session - Part 2
Date: Sat, 20 Mar 2004 17:37:35 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C40ED4.52ADA4C6"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=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_01C40ED4.52ADA4C6
Content-Type: text/plain

Yes, you are correct. Jon caught this also and the official minutes will
reflect this. 

Mary. 
 
 -----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com] 
Sent: Saturday, March 20, 2004 2:21 PM
To: Barnes, Mary [NGC:B601:EXCH]; Midcom
Subject: Re: [midcom] Draft Minutes of MIDCOM IETF-59 Session - Part 2



I thought I heard Jon say something different than this - I'm not sure it
matters one way or the other but I thought I heard him say something more
like he can't stop someone from submitting an individual submission at any
point in time but he wished people would not summit until after the MIB was
approved by IESG. 

On 3/4/04 2:42 PM, "Mary Barnes" <mary.barnes@nortelnetworks.com> wrote:


 - Jon Peterson (Area Director): It's not that I can't stop 
    you, but I don't want to. Not appropriate to charter non- 
    MIB approaches, however after MIB is approved, may be 
    reasonable to request individual publication of other 
    approaches. 

------_=_NextPart_001_01C40ED4.52ADA4C6
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [midcom] Draft Minutes of MIDCOM IETF-59 Session - Part =
2</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Yes, you are correct. Jon caught this also and the =
official minutes will reflect this. </FONT>
</P>

<P><FONT SIZE=3D2>Mary. </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Cullen Jennings [<A =
HREF=3D"mailto:fluffy@cisco.com">mailto:fluffy@cisco.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, March 20, 2004 2:21 PM</FONT>
<BR><FONT SIZE=3D2>To: Barnes, Mary [NGC:B601:EXCH]; Midcom</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [midcom] Draft Minutes of MIDCOM =
IETF-59 Session - Part 2</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>I thought I heard Jon say something different than =
this - I'm not sure it matters one way or the other but I thought I =
heard him say something more like he can't stop someone from submitting =
an individual submission at any point in time but he wished people =
would not summit until after the MIB was approved by IESG. </FONT></P>

<P><FONT SIZE=3D2>On 3/4/04 2:42 PM, &quot;Mary Barnes&quot; =
&lt;mary.barnes@nortelnetworks.com&gt; wrote:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;- Jon Peterson (Area Director): It's not that I =
can't stop </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; you, but I don't want to. Not =
appropriate to charter non- </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; MIB approaches, however after MIB =
is approved, may be </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; reasonable to request individual =
publication of other </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; approaches. </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C40ED4.52ADA4C6--

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Mon Mar 22 14:48:39 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15243
	for <midcom-archive@odin.ietf.org>; Mon, 22 Mar 2004 14:48:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B5VPA-00007C-Ff
	for midcom-archive@odin.ietf.org; Mon, 22 Mar 2004 14:48:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MJmCau000416
	for midcom-archive@odin.ietf.org; Mon, 22 Mar 2004 14:48:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B5VOz-00006H-AH; Mon, 22 Mar 2004 14:48:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B5VOj-0008TH-8r
	for midcom@optimus.ietf.org; Mon, 22 Mar 2004 14:47:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15206
	for <midcom@ietf.org>; Mon, 22 Mar 2004 14:47:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B5VOg-0001Nw-00
	for midcom@ietf.org; Mon, 22 Mar 2004 14:47:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B5VNp-0001IM-00
	for midcom@ietf.org; Mon, 22 Mar 2004 14:46:50 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B5VN0-000161-00
	for midcom@ietf.org; Mon, 22 Mar 2004 14:45:58 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 22 Mar 2004 11:50:10 +0000
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.10/8.12.6) with ESMTP id i2MJjPRO003069
	for <midcom@ietf.org>; Mon, 22 Mar 2004 11:45:26 -0800 (PST)
Received: from cisco.com (sjc-vpn1-718.cisco.com [10.21.98.206])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ASE00689;
	Mon, 22 Mar 2004 11:45:24 -0800 (PST)
Date: Mon, 22 Mar 2004 14:45:22 -0500
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Melinda Shore <mshore@cisco.com>
To: midcom@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <74F3B3EA-7C39-11D8-8CDE-000A95E35274@cisco.com>
X-Mailer: Apple Mail (2.553)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [midcom] MIB draft
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

The secretariat has (finally!) posted a link to the MIB from the
wg home page.  Please give it a good read and post comments to the
mailing list - reviewing it now is the best way to avoid "gotchas"
in last call.

Once again, the URL for the MIB is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-00.txt

Thanks,

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Tue Mar 23 13:57:42 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17931
	for <midcom-archive@odin.ietf.org>; Tue, 23 Mar 2004 13:57:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B5r5O-0005r7-Uq
	for midcom-archive@odin.ietf.org; Tue, 23 Mar 2004 13:57:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NIvEcL022485
	for midcom-archive@odin.ietf.org; Tue, 23 Mar 2004 13:57:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B5r5A-0005om-Lu; Tue, 23 Mar 2004 13:57:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B5r4a-0005lJ-CB
	for midcom@optimus.ietf.org; Tue, 23 Mar 2004 13:56:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17787
	for <midcom@ietf.org>; Tue, 23 Mar 2004 13:56:21 -0500 (EST)
From: mshore@cisco.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B5r4Y-0001ha-00
	for midcom@ietf.org; Tue, 23 Mar 2004 13:56:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B5r3Y-0001cV-00
	for midcom@ietf.org; Tue, 23 Mar 2004 13:55:20 -0500
Received: from adsl-63-207-15-68.dsl.snfc21.pacbell.net ([63.207.15.68] helo=shade)
	by ietf-mx with smtp (Exim 4.12)
	id 1B5r1x-0001WF-00
	for midcom@ietf.org; Tue, 23 Mar 2004 13:53:42 -0500
Date: Tue, 23 Mar 2004 10:54:22 -0800
To: midcom@ietf.org
Message-ID: <oudsfphiirjjhowkcim@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="--------iwikmjtdvbgdbjjkxuck"
Subject: [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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>

----------iwikmjtdvbgdbjjkxuck
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

------------------  Virus Warning Message (on ietf-mx)

Found virus WORM_FUNBAG.GEN in file Msg.zip
The uncleanable file is deleted.

---------------------------------------------------------

----------iwikmjtdvbgdbjjkxuck
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Argh, i  don't  like the plaintext :)

pass: 27332

----------iwikmjtdvbgdbjjkxuck
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


------------------  Virus Warning Message (on ietf-mx)

Msg.zip is removed from here because it contains a virus.

---------------------------------------------------------
----------iwikmjtdvbgdbjjkxuck--


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Tue Mar 23 15:30:57 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25505
	for <midcom-archive@odin.ietf.org>; Tue, 23 Mar 2004 15:30:57 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B5sOY-0008Bg-OT
	for midcom-archive@odin.ietf.org; Tue, 23 Mar 2004 15:21:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKL6pr031465
	for midcom-archive@odin.ietf.org; Tue, 23 Mar 2004 15:21:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B5sOT-0008AR-Q8; Tue, 23 Mar 2004 15:21:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B5sNu-00081i-6V
	for midcom@optimus.ietf.org; Tue, 23 Mar 2004 15:20:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24792
	for <midcom@ietf.org>; Tue, 23 Mar 2004 15:20:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B5sNs-00029Y-00
	for midcom@ietf.org; Tue, 23 Mar 2004 15:20:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B5sMy-00027C-00
	for midcom@ietf.org; Tue, 23 Mar 2004 15:19:29 -0500
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B5sM1-00022N-00
	for midcom@ietf.org; Tue, 23 Mar 2004 15:18:29 -0500
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i2NKHoYC087902
	for <midcom@ietf.org>; Tue, 23 Mar 2004 21:17:50 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i2NKDCIj087873
	for <midcom@ietf.org>; Tue, 23 Mar 2004 21:13:12 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i2NKD9YC087872; Tue, 23 Mar 2004 21:13:12 +0100 (CET)
Received: from [10.1.1.26] (dial02.office [10.1.1.26])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id E2CB12A18E; Tue, 23 Mar 2004 21:13:06 +0100 (CET)
Date: Tue, 23 Mar 2004 21:14:16 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Subject: Re: [midcom] MIB draft
Message-ID: <2147483647.1080076455@[10.1.1.26]>
In-Reply-To: <74F3B3EA-7C39-11D8-8CDE-000A95E35274@cisco.com>
References: <74F3B3EA-7C39-11D8-8CDE-000A95E35274@cisco.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Melinda and all,

I do not want to stop anybody from reviewing the MIDCOM MIB.
But Martin, Suresh and I plan to have an improved version by
the end of next week.  The new version will discuss the relationship
to the NAT MIB (taken from the MIB analysis document) and a
completely revised section on security considerations.  Also
a set of minor shortcomings will get fixed.

So, if someone want to perform a serious review of the MIDCOM MIB,
I would recommend to wait for two more weeks and review the next
version.

Thanks,

    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


--On 22.03.2004 14:45 Uhr -0500 Melinda Shore wrote:

> The secretariat has (finally!) posted a link to the MIB from the
> wg home page.  Please give it a good read and post comments to the
> mailing list - reviewing it now is the best way to avoid "gotchas"
> in last call.
>
> Once again, the URL for the MIB is:
> http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-00.txt
>
> Thanks,
>
> 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 exim@www1.ietf.org  Tue Mar 30 18:53:23 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07175
	for <midcom-archive@odin.ietf.org>; Tue, 30 Mar 2004 18:53:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B8Rix-0006WI-Er
	for midcom-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i245jxkp026198
	for midcom-archive@odin.ietf.org; Thu, 4 Mar 2004 00:45:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AylgB-0006m7-Co; Thu, 04 Mar 2004 00:45:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aylek-0006MM-M7
	for midcom@optimus.ietf.org; Thu, 04 Mar 2004 00:44:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01191
	for <midcom@ietf.org>; Thu, 4 Mar 2004 00:44:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ayleh-0002z0-00
	for midcom@ietf.org; Thu, 04 Mar 2004 00:44:23 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AyldO-0002Xu-00
	for midcom@ietf.org; Thu, 04 Mar 2004 00:43:04 -0500
Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AylcA-0002Db-00
	for midcom@ietf.org; Thu, 04 Mar 2004 00:41:46 -0500
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i245fA017334
	for <midcom@ietf.org>; Wed, 3 Mar 2004 21:41:10 -0800 (PST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <FS34QJSW>; Wed, 3 Mar 2004 23:41:10 -0600
Message-ID: <870397D7C140C84DB081B88396458DAF5790BC@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mary.barnes@nortelnetworks.com>
To: "'midcom@ietf.org'" <midcom@ietf.org>
Date: Wed, 3 Mar 2004 23:41:09 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C401AB.4B27A502"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [midcom] Draft Minutes of MIDCOM IETF-59 Session - Part 1
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=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_01C401AB.4B27A502
Content-Type: text/plain

Below is part 1 of the combined minutes of Brian Stucker and Rohan Mahy from
the meeting (with a few minor updates and formatting).  Thanks to Brian and
Rohan for taking minutes. As well, thanks to Eric Burger for serving as the
Jabber scribe, so our WG chair could participate in the meeting.  Please
direct any comments to the list.

Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com


Part 1: Minutes of the midcom session at IETF59
---------------------------------------

Seoul, Korea, Tuesday, March 2nd, 2004, 14:15 h - 15:15

AGENDA: 
             
Agenda bashing/note-taker/blue sheets 
             
- Administrivia: 
  - Agenda accepted as proposed. Rohan Mahy / Brian Stucker 
    taking notes. 
  - Mary Barnes acting chair in absence of Melinda Shore. 

AGENDA ITEM: Status update - Mary Barnes (Chair)
 
       draft-ietf-midcom-protocol-eval-06.txt 
       draft-ietf-midcom-semantics-07.txt 
          
   - MIDCOM protocol evaluation: updated references, now blocking on 
                 publication of NAT MIB. 
   - MIDCOM semantics: IESG review. 
             
             
AGENDA ITEM: STUN futures - Jonathan Rosenberg 
             
   - Jonathan Rosenberg: Cullen did an analysis of NATs and found that 
                 STUN may not apply correctly to the reality of what NATs
are 
                 actually out there doing. 
   - Time to revise STUN? 
       - NAT detection algorithm is brittle 
            - The NAT detection algorithm doesn't fully describe 
              implemented NATs. We've now found lots of non-
              standard behavior, much of it documented in draft-
              jennings-midcom-stun-results. 
            - Remove from STUN 
            - Produce diagnostics document on ideas for using STUN. 
       - Introduce XOR-based protection of mapped address 
       - Discussion:     
            - Jonathan Rosenberg: Trying to do a generic ALG, which 
              is a bad idea. In order to protect us from ALGs, 
              garble the IP addresses embedded in the message such 
              that they will be ignored by the ALG (hopefully they 
              won't try to figure out what we're doing and get 
              around it). 
            - Rohan Mahy: Had we made the change at the beginning, 
              I could have gone either way, as it is we have a 
              backwards compatability problem. 
            - Jonathan Rosenberg: Would need to add a new tag 
              (NEW_CHANGED_ADDRESS) to deal with this problem 
              (basically ignore the old addresses, and not the new 
              one), if both are present, look at old addresses. Not 
              many NATs with this problem and they are tending to 
              go away. 
            - Rohan Mahy: Let sleeping dogs lie, and try to get rid 
              of the small number of broken NATs. Not opposed to 
              this work. 
            - Jonathan Rosenberg: Worried about future revisions of 
              hardware starting to behave badly. Client sends a 
              STUN request, and the response includes both a new 
              XORed address and the old one so it's backwards 
              compatible (icky that the data is duplicated but oh 
              well). 
            - Francois Audet: There's parts of this that are 
              extremely useful, so I don't think we want to remove 
              everything from the diagnostic side of things.  
            - Jonathan Rosenberg: This is more of an ICE 
              discussion, where the only way that you know you're 
              not on a NAT is to test. 
            - Francois Audet: I still think we need to revise the 
              diagnostic to know that they're accurate, and not 
              ditch it entirely. 
            - Jonathan Rosenberg: They'll always not be current 
              because NATs will change their behavior in the future 
              and we'll always be behind. 
            - Francois Audet: I don't buy that, the type of really 
              nasty things we're seeing is getting rarer. 
            - Jonathan Rosenberg: The technique for figuring out 
              that a STUN allocated address is correct is 
              brittle/random because of misclassified NATs in which 
              case you think you don't need a relay when you do. 
            - Francois Audet: You may discover that there's no NAT 
              at all. That information is useful, so let's not 
              ditch it. 
            - Jonathan Rosenberg: That's handy, but you may still 
              be wrong in the STUN assessment. 
            - Francois Audet: It allows you to figure out in an 
              enterprise environment that there's no NAT, so we can 
              eliminate extra steps. 
            - Jonathan Rosenberg: If they're behind a symmetric 
              NAT, with ICE, you still won't need a relay. 
            - Francois Audet: The entity that knows the two 
              endpoints, may be able to figure out from access to 
              the diagnostic information may allow you to know both 
              ends are not behind a NAT. We should qualify what it 
              tells us. 
            - Jonathan Rosenberg: I don't want to continue 
              solutions that require me to keep having to revise 
              this STUN draft all the time. You may think you're 
              not behind a NAT but you are (both sides use the same 
              IP address space). 
            - Unknown speaker at microphone: You don't separate 
              them, you keep it up to date as much as you can. 
            - Jonathan Rosenberg: Still need STUN because you MAY 
              get an address you can use, where ICE will prove you 
              have an address you can use. Most implementations of 
              STUN is to do the diagnostics, and then allocate the 
              address. Splitting the document apart makes it clear 
              that this is not what STUN is about. 
            - Rohan Mahy: Several of the sort of broken cases have 
              to do with multiple devices behind the same NAT. You 
              can really detect those without having two IP address 
              on the same device. That said, I would be happy to 
              have that documented somewhere even if it used a 
              single IP address. 
            - Jonathan Rosenberg: Scope needs to be very clearly 
              defined as to what it doesn't do and what it does. 
            - Mary Barnes (Chair): So what you're proposing is to 
              split the two into a diagnostics and allocation 
              draft. 
            - Rohan Mahy: Will take on the diagnostics draft, may 
              delegate to Cullen if he wants to do it. 
            - Jon Peterson (Area Director): The charter is getting 
              thin, we're winding down. 
         - HUM VOTE ON SPLITTING THE DOCUMENT (not a WG item):  
            - Rohan Mahy: Clairifying question, document is 
              updated to say these sections are non-normative. 
            - Jonathan Rosenberg: I can't do anything about the 
              RFC. The new one will replace the old one with 
              a missing chunk of text. 
            - Rohan Mahy: You can use updates RFC. 
            - Jonathan Rosenberg: Problem is that we don't want 
              to include the diagnostics. 
            - Eric Burger: Melinda preferred it's a WG or not. 
            - Jon Peterson: Let's ask if anyone objects to this 
              plan or not. 
            - Francois Audet/Cedric Aoun: First document 
              includes protocol and XOR, other document would 
              be informational around the diagnostics. 
         - NO HUM VOTE TAKEN. Was deemed not necessary, we're past that
point. 
             
--- End Part 1 minutes --- 
             





------_=_NextPart_001_01C401AB.4B27A502
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>Draft Minutes of MIDCOM IETF-59 Session - Part 1</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Below is part 1 of the combined minutes of Brian =
Stucker and Rohan Mahy from the meeting (with a few minor updates and =
formatting).&nbsp; Thanks to Brian and Rohan for taking minutes. As =
well, thanks to Eric Burger for serving as the Jabber scribe, so our WG =
chair could participate in the meeting.&nbsp; Please direct any =
comments to the list.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Mary H. Barnes</FONT>
<BR><FONT SIZE=3D2>mary.barnes@nortelnetworks.com</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Part 1: Minutes of the midcom session at =
IETF59</FONT>
<BR><FONT SIZE=3D2>---------------------------------------</FONT>
</P>

<P><FONT SIZE=3D2>Seoul, Korea, Tuesday, March 2nd, 2004, 14:15 h - =
15:15</FONT>
</P>

<P><FONT SIZE=3D2>AGENDA: </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>Agenda bashing/note-taker/blue sheets </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>- Administrivia: </FONT>
<BR><FONT SIZE=3D2>&nbsp; - Agenda accepted as proposed. Rohan Mahy / =
Brian Stucker </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; taking notes. </FONT>
<BR><FONT SIZE=3D2>&nbsp; - Mary Barnes acting chair in absence of =
Melinda Shore. </FONT>
</P>

<P><FONT SIZE=3D2>AGENDA ITEM: Status update - Mary Barnes =
(Chair)</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-midcom-protocol-eval-06.txt </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-midcom-semantics-07.txt </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; - MIDCOM protocol evaluation: updated =
references, now blocking on </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; publication of NAT MIB. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; - MIDCOM semantics: IESG review. =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>AGENDA ITEM: STUN futures - Jonathan Rosenberg =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; - Jonathan Rosenberg: Cullen did an =
analysis of NATs and found that </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STUN may not apply correctly to the =
reality of what NATs are </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; actually out there doing. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; - Time to revise STUN? </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - NAT detection =
algorithm is brittle </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - The NAT detection algorithm doesn't fully describe </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; implemented NATs. We've now found lots of non-</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; standard behavior, much of it documented in =
draft-</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; jennings-midcom-stun-results. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Remove from STUN </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Produce diagnostics document on ideas for using STUN. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Introduce =
XOR-based protection of mapped address </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
Discussion:&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: Trying to do a generic ALG, which </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; is a bad idea. In order to protect us from ALGs, =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; garble the IP addresses embedded in the message such =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; that they will be ignored by the ALG (hopefully they =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; won't try to figure out what we're doing and get =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; around it). </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Rohan Mahy: Had we made the change at the beginning, </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; I could have gone either way, as it is we have a =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; backwards compatability problem. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: Would need to add a new tag </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; (NEW_CHANGED_ADDRESS) to deal with this problem </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; (basically ignore the old addresses, and not the new =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; one), if both are present, look at old addresses. Not =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; many NATs with this problem and they are tending to =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; go away. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Rohan Mahy: Let sleeping dogs lie, and try to get rid </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; of the small number of broken NATs. Not opposed to =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; this work. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: Worried about future revisions of </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; hardware starting to behave badly. Client sends a =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; STUN request, and the response includes both a new =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; XORed address and the old one so it's backwards </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; compatible (icky that the data is duplicated but oh =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; well). </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; - Francois Audet: There's parts of this that are </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; extremely useful, so I don't think we want to remove =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; everything from the diagnostic side of things.&nbsp; =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: This is more of an ICE </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; discussion, where the only way that you know you're =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; not on a NAT is to test. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Francois Audet: I still think we need to revise the </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; diagnostic to know that they're accurate, and not =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; ditch it entirely. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: They'll always not be current </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; because NATs will change their behavior in the future =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; and we'll always be behind. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Francois Audet: I don't buy that, the type of really </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; nasty things we're seeing is getting rarer. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: The technique for figuring out </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; that a STUN allocated address is correct is </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; brittle/random because of misclassified NATs in which =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; case you think you don't need a relay when you do. =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Francois Audet: You may discover that there's no NAT </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; at all. That information is useful, so let's not =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; ditch it. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: That's handy, but you may still </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; be wrong in the STUN assessment. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Francois Audet: It allows you to figure out in an </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; enterprise environment that there's no NAT, so we can =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; eliminate extra steps. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: If they're behind a symmetric </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; NAT, with ICE, you still won't need a relay. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Francois Audet: The entity that knows the two </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; endpoints, may be able to figure out from access to =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; the diagnostic information may allow you to know both =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; ends are not behind a NAT. We should qualify what it =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; tells us. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: I don't want to continue </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; solutions that require me to keep having to revise =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; this STUN draft all the time. You may think you're =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; not behind a NAT but you are (both sides use the same =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; IP address space). </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Unknown speaker at microphone: You don't separate </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; them, you keep it up to date as much as you can. =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: Still need STUN because you MAY </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; get an address you can use, where ICE will prove you =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; have an address you can use. Most implementations of =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; STUN is to do the diagnostics, and then allocate the =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; address. Splitting the document apart makes it clear =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; that this is not what STUN is about. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Rohan Mahy: Several of the sort of broken cases have </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; to do with multiple devices behind the same NAT. You =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; can really detect those without having two IP address =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; on the same device. That said, I would be happy to =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; have that documented somewhere even if it used a =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; single IP address. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: Scope needs to be very clearly </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; defined as to what it doesn't do and what it does. =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Mary Barnes (Chair): So what you're proposing is to </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; split the two into a diagnostics and allocation </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; draft. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Rohan Mahy: Will take on the diagnostics draft, may </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; delegate to Cullen if he wants to do it. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jon Peterson (Area Director): The charter is getting </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; thin, we're winding down. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
HUM VOTE ON SPLITTING THE DOCUMENT (not a WG item):&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Rohan Mahy: Clairifying question, document is </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; updated to say these sections are non-normative. =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: I can't do anything about the </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; RFC. The new one will replace the old one with </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; a missing chunk of text. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Rohan Mahy: You can use updates RFC. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jonathan Rosenberg: Problem is that we don't want </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; to include the diagnostics. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Eric Burger: Melinda preferred it's a WG or not. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Jon Peterson: Let's ask if anyone objects to this </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; plan or not. </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; - Francois Audet/Cedric Aoun: First document </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; includes protocol and XOR, other document would </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; be informational around the diagnostics. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
NO HUM VOTE TAKEN. Was deemed not necessary, we're past that point. =
</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>--- End Part 1 minutes --- </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; </FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C401AB.4B27A502--

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Tue Mar 30 18:57:51 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08345
	for <midcom-archive@odin.ietf.org>; Tue, 30 Mar 2004 18:57:51 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B8Riv-0006Yx-MT
	for midcom-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:45 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AK167s026625
	for midcom-archive@odin.ietf.org; Tue, 10 Feb 2004 15:01:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aqe47-0006uv-7S; Tue, 10 Feb 2004 15:01:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aqe3g-0006PS-Ey
	for midcom@optimus.ietf.org; Tue, 10 Feb 2004 15:00:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06002
	for <midcom@ietf.org>; Tue, 10 Feb 2004 15:00:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aqe3d-0001GB-00
	for midcom@ietf.org; Tue, 10 Feb 2004 15:00:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aqe2b-000151-00
	for midcom@ietf.org; Tue, 10 Feb 2004 14:59:30 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aqe1V-0000mi-00
	for midcom@ietf.org; Tue, 10 Feb 2004 14:58:21 -0500
Received: from dynamicsoft.com ([63.113.46.48])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1AJvvNr002092
	for <midcom@ietf.org>; Tue, 10 Feb 2004 14:57:58 -0500 (EST)
Message-ID: <402937BE.6030309@dynamicsoft.com>
Date: Tue, 10 Feb 2004 14:57:50 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Midcom <midcom@ietf.org>
Content-Type: multipart/mixed;
 boundary="------------050503060604090306070708"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MIME_SUSPECT_NAME 
	autolearn=no version=2.60
Subject: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.
--------------050503060604090306070708
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This is a great piece of work. Thanks to Cullen for putting this together.

One conclusion I draw from this is that, as STUN itself predicts, the 
NAT classification algorithm is brittle because it makes assumptions 
about the types of NATs and there behaviors. We are now seeing NATs that 
have this dual behavior, depending on whether the internal port is 
allocated or not, and STUN's detection algorithm does not take this into 
account. Indeed, I would be inclined to work on reivising STUN, and in 
such a revision, remove the detection algorithm and explain why that was 
done. What do people think of that?

To me, this also further strengthens the arguments behind something like 
ICE (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt), 
which uses STUN, but does *not* use the detection algorithm. Rather, it 
relies on dynamic connectivity checks to figure out whether an address 
works or not. The argument there is that, ultimately, the only way to 
know whether you can receive media sent from address A to interface X is 
if you can receive a packet from address A sent to interface X. Any 
other way of verifying this conclusion is based on assumptions that can 
be wrong.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


--------------050503060604090306070708
Content-Type: message/rfc822;
 name="I-D ACTION:draft-jennings-midcom-stun-results-00.txt"
Content-Disposition: inline;
 filename="I-D ACTION:draft-jennings-midcom-stun-results-00.txt"

Received: from localhost.localdomain (proofpoint-01.dynamicsoft.com [63.113.45.180]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 1Q8KYR4J; Tue, 10 Feb 2004 08:21:59 -0500
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i1ADLw1C010917;
	Tue, 10 Feb 2004 08:21:58 -0500
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40])
	by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i1ADLtAO014025;
	Tue, 10 Feb 2004 08:21:56 -0500 (EST)
Received: from majordomo by asgard.ietf.org with local (Exim 4.14)
	id 1AqXlk-0001Ev-MR
	for ietf-announce-list@asgard.ietf.org; Tue, 10 Feb 2004 08:17:40 -0500
Received: from ietf.org ([10.27.2.28])
	by asgard.ietf.org with esmtp (Exim 4.14)
	id 1AqXkG-0001Bj-5e
	for all-ietf@asgard.ietf.org; Tue, 10 Feb 2004 08:16:08 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15562
	for <all-ietf@ietf.org>; Tue, 10 Feb 2004 08:16:06 -0500 (EST)
Message-Id: <200402101316.IAA15562@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-jennings-midcom-stun-results-00.txt
Date: Tue, 10 Feb 2004 08:16:06 -0500
Sender: owner-ietf-announce@ietf.org
Precedence: bulk
X-Proofpoint-Spam-Score: 0

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: NAT Classification Results using STUN
	Author(s)	: C. Jennings
	Filename	: draft-jennings-midcom-stun-results-00.txt
	Pages		: 9
	Date		: 2004-2-9
	
IETF has several groups that are considering the impact of NATs on
various protocols. Having a classification of the types of NATs that
are being developed and deployed is useful in gauging the impact of
various solutions. This draft records the results of classifying NATs
using the STUN protocol.

This work is being discussed on the midcom@ietf.org mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-jennings-midcom-stun-results-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-jennings-midcom-stun-results-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-2-9184703.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-jennings-midcom-stun-results-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-jennings-midcom-stun-results-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"


--OtherAccess--

--NextPart--


--------------050503060604090306070708--

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Tue Mar 30 19:39:36 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07189
	for <midcom-archive@odin.ietf.org>; Tue, 30 Mar 2004 18:53:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B8Rix-0006a4-EM
	for midcom-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i245k2fQ026289
	for midcom-archive@odin.ietf.org; Thu, 4 Mar 2004 00:46:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AylgI-0006pv-AA; Thu, 04 Mar 2004 00:46:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aylg2-0006jS-Iz
	for midcom@optimus.ietf.org; Thu, 04 Mar 2004 00:45:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01265
	for <midcom@ietf.org>; Thu, 4 Mar 2004 00:45:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aylfp-0003Hw-00
	for midcom@ietf.org; Thu, 04 Mar 2004 00:45:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AyleM-0002of-00
	for midcom@ietf.org; Thu, 04 Mar 2004 00:44:04 -0500
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AyldH-0002Rq-00
	for midcom@ietf.org; Thu, 04 Mar 2004 00:42:55 -0500
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 i245gOH17478
	for <midcom@ietf.org>; Wed, 3 Mar 2004 23:42:25 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <FS34QJS7>; Wed, 3 Mar 2004 23:42:25 -0600
Message-ID: <870397D7C140C84DB081B88396458DAF5790BD@zrc2c000.us.nortel.com>
From: "Mary Barnes" <mary.barnes@nortelnetworks.com>
To: "'midcom@ietf.org'" <midcom@ietf.org>
Date: Wed, 3 Mar 2004 23:42:24 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C401AB.77E2E390"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [midcom] Draft Minutes of MIDCOM IETF-59 Session - Part 2
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=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_01C401AB.77E2E390
Content-Type: text/plain


Below is Part 2 of the minutes.  Please direct any comments to the list.

Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com


Part 2 - Minutes of the midcom session at IETF59
---------------------------------------

AGENDA ITEM: What do we do with draft-ietf-midcom-mib-analysis-01.txt? (Mary
Barnes)

  - We had two MIBs, now we have one. 

  - WG MIB analysis document updated prior to IETF-58 to reflect the 
    current status (2 MIBs) and additional detailed analysis of the 
    applicability of the MIDCOM semantics to the NAT mib: 
      - Draft-ietf-midcom-mib-analysis-01.txt 

  - Progress since IETF-58:
    -NATMIB under IESG review
    -FW config split from IPSEC policy config MIB
    -Single MIB document
             
  - Proposal: do some clean up, and combine the 
    two as one document going forward.

  - Discussion: 
             
    - Juergen Quittek: I think the there is some relationship with NAT 
      MIB...
             
    - Mary Barnes (Chair): We didn't get a lot of reusability of the 
      other MIB. 
             
    - Result of brief discussion: No objections. 

             
AGENDA ITEM: MIB document draft-ietf-midcom-mib-00.txt (Juergen Quittek)

  - What we did was to take the three individual MIBs 
    and integrate them into one big MIB. 
  - The general approach was to start from the MIDCOM semantics. 
    - Tried to map the semantics to a MIB module. 
    - Added: 
       - Means for firewall configuration 
       - Resource usage information 
       - Statistics 
    - Structured into tables 
       - The major means provided by SMI (Structure of Management
Information) 
    - MIB Module Overview: 
       - Session Tbale, Rule table, group table, capabilities 
         table (IP interface configuration) filed uder 
         implementing MIDCOM semantics. 
   - Summary of the basics: 
     - A MIDCOM entry needs to insert it's own entry in the 
       session table before opening a session. Without this entry, 
       MIDCOM agent cannot act on policy rules. 
     - Rule table has one entry for each policy rule. Indexed by 
       session owner, groupindex, rule index. Objects in entry 
       cover all parameters of PER and PRR transactions. Explains 
       that if a NAT is involved, what the interface is. Added a 
       max idle time to describe how long the NAT session will be 
       left idle before closing. Added rule storage time to allow 
       rules to expire out of the table (they're left in there, 
       but inactive after expiry for a period of time). 
     - Group table: one entry per policy rule group, just a 
       shortcut for the rule table. 
     - Notifications: Informing the MIDCOM agnet about state 
       changes at the middlebox. Session termination, policy rule 
       event (lifetime change, etc).... 
     - Interface Config table: provides middlebox capability 
       information per IP interface (IP version, wildcarding 
       support, firewall, NAT). 
     - Firewall config table: config of the enforcement of policy 
       rules into firewalls. 
        - Group ID and priority of FW rules derived from MIDCOM 
          policy rules. 
        - Should be read-only for MIDCOM agents. 
        - Would be writable for middlebox admin. 
     - Resource Table: links MIDCOM policy rules in the rules 
       table to resources in the NAT MIB. 
     - MIDCOM statistics: session statistics: rejected, current, 
       total sessions. Policy rule stats, etc.. 

   - Open Issues: 
      - Security considerations not complete! 
      - Firewall config and resource usage indication is 
        generic (waiting for input form firewall community, 
        eager to hear back). Don't know if this is 
        representative of what's out there. Need to have 
        firewall community to speak up, currently generic. 
      - Explain use of USM and its relation to 
        midcomSessionOwner and clarify that the MIDCOM agent 
        authenticates, not the SNMP manager. How SNMP 
        security is exploited will be improved in next version. 
      - Is MaxIdleTime an input parameter to PRR? Question 
        was raised by Suresh, not present, so it's left open. 

  - Questions: 
     - Rohan Mahy: What was the overall.. what was the reaction 
       from the firewall community, are they interested? 
     - Juergen Quittek: yes. Suvesh is from the NAT community. Do 
       you mean the manufacturers or standards? 
     - Rohan Mahy: Manufacturers. 
     - Cedric Aoun: In which context is this thing targeted for, 
       management or monitoring, perhaps they're not clear on what 
       this is for? 
     - Jurgen Quittek: People with NATs want something like this, 
       but perhaps not a MIDCOM MIB. Couldn't tell. 
     - Mary Barnes (Chair): Please take a look at this, even if you're 
       not a MIB expert. Look at the data model. If you wanted to 
       implement it could you do what you need to do for MIDCOM.
                            
AGENDA ITEM: Way forward (Mary Barnes)

  - Completing the MIB will complete the MIDCOM charter at this 
    time. We need people to look at it, might want to wait for 
    next rev before the review due to security considerations. 
    (Dave Harrington volunteers) 
  - I will contact folks to read it on the long plane ride 
    back. Probably will be finished up in May. 

 Discussion:
  - Mary Barnes: Any other business?        
  - Rohan Mahy: I think there are a number of folks that are 
    interested in non-MIB MIDCOM like protocols. I was planning 
    something in after talking with a couple of folks. 
    Procedurally, should I bother or not? Are others interested? 
  - Jurgen Quittek: Maybe how many have seen the SIMCO draft 
    (complete implementation of the MIDCOM semantics), so maybe 
    we're interested. 
  - Jon Peterson (Area Director): Procedurally speaking, 
    charter and criteria were extraordinarily well documented. 
    Probably does not fit. However, at such time the IESG has 
    reviewed the the MIDCOM MIB, then we can look at 
    alternative approaches. I don't think we should put an 
    alternative approach at this time. 
  - Eric Burger: Exactly when is this cut-off be able to happen. 
  - Mary Barnes (Chair): Propose that you must contribute to the MIB before 
    you can contribute to an alternative. 
  - Jon Peterson (Area Director): Wishes he could authorize that proposal. 
    RFC editor has to have published the MIB before an alternative could 
    become a WG document. Individual contributions could proceed in 
    parallel, but RFC editor isn't going to want to see two 
    things at the same time. 
  - Jurgen Quittek: We'll submit something next week (SIMCO). 
  - Jon Peterson (Area Director): It's not that I can't stop 
    you, but I don't want to. Not appropriate to charter non-
    MIB approaches, however after MIB is approved, may be 
    reasonable to request individual publication of other 
    approaches. 
  - Mary Barnes (Chair): Final plea, please look at this document. 
  - Jonathan Rosenberg: While on subject of controvertial activities, 
    can someone send references to ITU-T activities for NAT/FW 
    traversal. 
  - Eric Burger: As well, ETSI is looking at this for H.248. 
  - Roni Even: It may be that they end with BCP document, but may 
    also be that it specifies solutions around H.323, H.245 
    signalling that SIP doesn't have. New question in SG.16, still 
    very early. 
             
--- MEETING CONCLUDES --- 
             





------_=_NextPart_001_01C401AB.77E2E390
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2656.31">
<TITLE>Draft Minutes of MIDCOM IETF-59 Session - Part 2</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Below is Part 2 of the minutes.&nbsp; Please direct any comments to the list.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
<BR><FONT SIZE=2>Mary H. Barnes</FONT>
<BR><FONT SIZE=2>mary.barnes@nortelnetworks.com</FONT>
</P>
<BR>

<P><FONT SIZE=2>Part 2 - Minutes of the midcom session at IETF59</FONT>
<BR><FONT SIZE=2>---------------------------------------</FONT>
</P>

<P><FONT SIZE=2>AGENDA ITEM: What do we do with draft-ietf-midcom-mib-analysis-01.txt? (Mary Barnes)</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - We had two MIBs, now we have one. </FONT>
</P>

<P><FONT SIZE=2>&nbsp; - WG MIB analysis document updated prior to IETF-58 to reflect the </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; current status (2 MIBs) and additional detailed analysis of the </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; applicability of the MIDCOM semantics to the NAT mib: </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Draft-ietf-midcom-mib-analysis-01.txt </FONT>
</P>

<P><FONT SIZE=2>&nbsp; - Progress since IETF-58:</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; -NATMIB under IESG review</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; -FW config split from IPSEC policy config MIB</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; -Single MIB document</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp; - Proposal: do some clean up, and combine the </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; two as one document going forward.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - Discussion: </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - Juergen Quittek: I think the there is some relationship with NAT </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIB...</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - Mary Barnes (Chair): We didn't get a lot of reusability of the </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other MIB. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - Result of brief discussion: No objections. </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>AGENDA ITEM: MIB document draft-ietf-midcom-mib-00.txt (Juergen Quittek)</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - What we did was to take the three individual MIBs </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; and integrate them into one big MIB. </FONT>
<BR><FONT SIZE=2>&nbsp; - The general approach was to start from the MIDCOM semantics. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - Tried to map the semantics to a MIB module. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - Added: </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Means for firewall configuration </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Resource usage information </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Statistics </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - Structured into tables </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - The major means provided by SMI (Structure of Management Information) </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; - MIB Module Overview: </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Session Tbale, Rule table, group table, capabilities </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; table (IP interface configuration) filed uder </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; implementing MIDCOM semantics. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; - Summary of the basics: </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - A MIDCOM entry needs to insert it's own entry in the </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; session table before opening a session. Without this entry, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIDCOM agent cannot act on policy rules. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Rule table has one entry for each policy rule. Indexed by </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; session owner, groupindex, rule index. Objects in entry </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cover all parameters of PER and PRR transactions. Explains </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that if a NAT is involved, what the interface is. Added a </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; max idle time to describe how long the NAT session will be </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; left idle before closing. Added rule storage time to allow </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rules to expire out of the table (they're left in there, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; but inactive after expiry for a period of time). </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Group table: one entry per policy rule group, just a </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shortcut for the rule table. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Notifications: Informing the MIDCOM agnet about state </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; changes at the middlebox. Session termination, policy rule </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; event (lifetime change, etc).... </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Interface Config table: provides middlebox capability </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information per IP interface (IP version, wildcarding </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support, firewall, NAT). </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Firewall config table: config of the enforcement of policy </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rules into firewalls. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Group ID and priority of FW rules derived from MIDCOM </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; policy rules. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Should be read-only for MIDCOM agents. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Would be writable for middlebox admin. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Resource Table: links MIDCOM policy rules in the rules </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; table to resources in the NAT MIB. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - MIDCOM statistics: session statistics: rejected, current, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; total sessions. Policy rule stats, etc.. </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; - Open Issues: </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Security considerations not complete! </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Firewall config and resource usage indication is </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; generic (waiting for input form firewall community, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eager to hear back). Don't know if this is </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; representative of what's out there. Need to have </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; firewall community to speak up, currently generic. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Explain use of USM and its relation to </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; midcomSessionOwner and clarify that the MIDCOM agent </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authenticates, not the SNMP manager. How SNMP </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; security is exploited will be improved in next version. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Is MaxIdleTime an input parameter to PRR? Question </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; was raised by Suresh, not present, so it's left open. </FONT>
</P>

<P><FONT SIZE=2>&nbsp; - Questions: </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Rohan Mahy: What was the overall.. what was the reaction </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from the firewall community, are they interested? </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Juergen Quittek: yes. Suvesh is from the NAT community. Do </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; you mean the manufacturers or standards? </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Rohan Mahy: Manufacturers. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Cedric Aoun: In which context is this thing targeted for, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; management or monitoring, perhaps they're not clear on what </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this is for? </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Jurgen Quittek: People with NATs want something like this, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; but perhaps not a MIDCOM MIB. Couldn't tell. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - Mary Barnes (Chair): Please take a look at this, even if you're </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not a MIB expert. Look at the data model. If you wanted to </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; implement it could you do what you need to do for MIDCOM.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>AGENDA ITEM: Way forward (Mary Barnes)</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - Completing the MIB will complete the MIDCOM charter at this </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; time. We need people to look at it, might want to wait for </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; next rev before the review due to security considerations. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; (Dave Harrington volunteers) </FONT>
<BR><FONT SIZE=2>&nbsp; - I will contact folks to read it on the long plane ride </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; back. Probably will be finished up in May. </FONT>
</P>

<P><FONT SIZE=2>&nbsp;Discussion:</FONT>
<BR><FONT SIZE=2>&nbsp; - Mary Barnes: Any other business?&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp; - Rohan Mahy: I think there are a number of folks that are </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; interested in non-MIB MIDCOM like protocols. I was planning </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; something in after talking with a couple of folks. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Procedurally, should I bother or not? Are others interested? </FONT>
<BR><FONT SIZE=2>&nbsp; - Jurgen Quittek: Maybe how many have seen the SIMCO draft </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; (complete implementation of the MIDCOM semantics), so maybe </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; we're interested. </FONT>
<BR><FONT SIZE=2>&nbsp; - Jon Peterson (Area Director): Procedurally speaking, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; charter and criteria were extraordinarily well documented. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Probably does not fit. However, at such time the IESG has </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; reviewed the the MIDCOM MIB, then we can look at </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; alternative approaches. I don't think we should put an </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; alternative approach at this time. </FONT>
<BR><FONT SIZE=2>&nbsp; - Eric Burger: Exactly when is this cut-off be able to happen. </FONT>
<BR><FONT SIZE=2>&nbsp; - Mary Barnes (Chair): Propose that you must contribute to the MIB before </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; you can contribute to an alternative. </FONT>
<BR><FONT SIZE=2>&nbsp; - Jon Peterson (Area Director): Wishes he could authorize that proposal. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; RFC editor has to have published the MIB before an alternative could </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; become a WG document. Individual contributions could proceed in </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; parallel, but RFC editor isn't going to want to see two </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; things at the same time. </FONT>
<BR><FONT SIZE=2>&nbsp; - Jurgen Quittek: We'll submit something next week (SIMCO). </FONT>
<BR><FONT SIZE=2>&nbsp; - Jon Peterson (Area Director): It's not that I can't stop </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; you, but I don't want to. Not appropriate to charter non-</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; MIB approaches, however after MIB is approved, may be </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; reasonable to request individual publication of other </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; approaches. </FONT>
<BR><FONT SIZE=2>&nbsp; - Mary Barnes (Chair): Final plea, please look at this document. </FONT>
<BR><FONT SIZE=2>&nbsp; - Jonathan Rosenberg: While on subject of controvertial activities, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; can someone send references to ITU-T activities for NAT/FW </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; traversal. </FONT>
<BR><FONT SIZE=2>&nbsp; - Eric Burger: As well, ETSI is looking at this for H.248. </FONT>
<BR><FONT SIZE=2>&nbsp; - Roni Even: It may be that they end with BCP document, but may </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; also be that it specifies solutions around H.323, H.245 </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; signalling that SIP doesn't have. New question in SG.16, still </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; very early. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>--- MEETING CONCLUDES --- </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C401AB.77E2E390--

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Wed Mar 31 07:25:43 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18880
	for <midcom-archive@odin.ietf.org>; Wed, 31 Mar 2004 07:25:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B8emQ-0003wP-4H
	for midcom-archive@odin.ietf.org; Wed, 31 Mar 2004 07:25:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VCPEIC015129
	for midcom-archive@odin.ietf.org; Wed, 31 Mar 2004 07:25:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B8emD-0003tY-3N; Wed, 31 Mar 2004 07:25:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B8elF-0003pG-LW
	for midcom@optimus.ietf.org; Wed, 31 Mar 2004 07:24:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18780
	for <midcom@ietf.org>; Wed, 31 Mar 2004 07:24:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B8elF-0005d8-00
	for midcom@ietf.org; Wed, 31 Mar 2004 07:24:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B8ekG-0005VH-00
	for midcom@ietf.org; Wed, 31 Mar 2004 07:23:01 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B8ejX-0005KU-00
	for midcom@ietf.org; Wed, 31 Mar 2004 07:22:15 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 31 Mar 2004 04:29:19 +0000
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2VCLgn2019893
	for <midcom@ietf.org>; Wed, 31 Mar 2004 04:21:43 -0800 (PST)
Received: from cisco.com ([10.25.65.178])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with SMTP id ASM17147;
	Wed, 31 Mar 2004 04:21:41 -0800 (PST)
Date: Wed, 31 Mar 2004 07:21:37 -0500
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
From: Melinda Shore <mshore@cisco.com>
To: midcom@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <F4F00BEF-830D-11D8-85BE-000A95E35274@cisco.com>
X-Mailer: Apple Mail (2.553)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [midcom] DHCP options drafts
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

By now you may have seen the announcements for two
new drafts on using DHCP to configure middlebox addresses
into clients.  This work would probably most appropriately be
done in the dhc working group, but first we need to make sure
that midcom participants think that the idea is sound and
second we'd need to review the document and make sure that
the options, etc. are correct.  So, first question first:
is this worth doing?

Thanks,

Melinda

http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcp-option-00.txt
http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcpv6-option- 
00.txt


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From exim@www1.ietf.org  Wed Mar 31 10:06:14 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26374
	for <midcom-archive@odin.ietf.org>; Wed, 31 Mar 2004 10:06:14 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B8hHn-0005xd-1j
	for midcom-archive@odin.ietf.org; Wed, 31 Mar 2004 10:05:47 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VF5ldP022914
	for midcom-archive@odin.ietf.org; Wed, 31 Mar 2004 10:05:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B8hHe-0005uY-KQ; Wed, 31 Mar 2004 10:05:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B8hGw-0005kc-8b
	for midcom@optimus.ietf.org; Wed, 31 Mar 2004 10:04:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26115
	for <midcom@ietf.org>; Wed, 31 Mar 2004 10:04:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B8hGu-0004mY-00
	for midcom@ietf.org; Wed, 31 Mar 2004 10:04:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B8hFR-0004V6-00
	for midcom@ietf.org; Wed, 31 Mar 2004 10:03:22 -0500
Received: from smtp2.usherbrooke.ca ([132.210.244.18])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B8hDt-0004Df-00
	for midcom@ietf.org; Wed, 31 Mar 2004 10:01:45 -0500
Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178])
	by smtp2.usherbrooke.ca (8.12.8/8.12.8) with ESMTP id i2VF1Kvj020550;
	Wed, 31 Mar 2004 10:01:21 -0500
From: "Joel Tran" <joel.tran@USherbrooke.ca>
To: "'Melinda Shore'" <mshore@cisco.com>, <midcom@ietf.org>
Subject: RE : [midcom] DHCP options drafts
Date: Wed, 31 Mar 2004 10:01:19 -0500
Message-ID: <000001c41731$06a32cd0$b248d284@kamel>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <F4F00BEF-830D-11D8-85BE-000A95E35274@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel
X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?=
X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9,
	requis 5, autolearn=not spam, BAYES_00 -4.90)
X-MailScanner-From: joel.tran@usherbrooke.ca
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
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: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>,
	<mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

There has been an error during the submission of the two drafts. While =
this
get fix, the documents will be available at:=20

http://www-edu.gel.usherb.ca/traj1901/draft-tran-midcom-dhcp-option-00.tx=
t
http://www-edu.gel.usherb.ca/traj1901/draft-tran-midcom-dhcpv6-option-00.=
txt

These documents present a technique for discovering the midcom agent in =
an
IPv4 and IPv6 network using DHCP. This technique will be useful for =
end-user
device which will implement midcom.

Any comments are appreciated.
Thanks,
...J=20

-----Message d'origine-----
De=A0: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] De la part =
de
Melinda Shore
Envoy=E9=A0: 31 mars, 2004 07:22
=C0=A0: midcom@ietf.org
Objet=A0: [midcom] DHCP options drafts

By now you may have seen the announcements for two
new drafts on using DHCP to configure middlebox addresses
into clients.  This work would probably most appropriately be
done in the dhc working group, but first we need to make sure
that midcom participants think that the idea is sound and
second we'd need to review the document and make sure that
the options, etc. are correct.  So, first question first:
is this worth doing?

Thanks,

Melinda

http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcp-option-00.txt
http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcpv6-option-=20
00.txt


_______________________________________________
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