From daemon@optimus.ietf.org Fri Mar 1 06:17:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09755 for ; Fri, 1 Mar 2002 06:17:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA25951 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 06:17:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24918; Fri, 1 Mar 2002 06:16:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24888 for ; Fri, 1 Mar 2002 06:16:00 -0500 (EST) Received: from dumbo.jumbomailer.com ([203.21.76.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09629 for ; Fri, 1 Mar 2002 06:15:53 -0500 (EST) Received: (from news@cigarettestation.com) by dumbo.jumbomailer.com (8.11.6/8.11.6) id 57061-91104 for midcom@ietf.org; Sat Mar 2 06:46:23 EST 2002 +1000 Message-ID: <57061-91104@jumbomailer.com> From: "Station News" To: Date: Sat Mar 2 06:46:23 EST 2002 MIME-Version: 1.0 MIME-Engine: JumboMailer 1.01 Content-Type: multipart/mixed; boundary="----=_Next_Part_0000000000_jumbomailer_57061-91104=----" X-Mailer: JumboMailer 1.01 X-Unsubscribe: http://www.jumbomailer.com/cgi-bin/jumbomailer/unsubscribe.cgi?UNSUBID=NTcwNjEtOTExMDR8Y2lnc3RhdGlvbnxtaWRjb21AaWV0Zi5vcmc= Subject: [midcom] Welcome to $1.81 a pack prices! Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. ----=_Next_Part_0000000000_jumbomailer_57061-91104=---- Content-Type: text/plain; charset="iso-8859-1" Welcome! Thanks for joining the Cigarette Station Newsletter! We'll keep you continually up-to-date with our specials as soon as they are available. We often quote prices as low as $1.76 a pack! Remember, if you ever want to unsubscribe you can use the link at the bottom of this newsletter or visit http://www.cigarettestation.com/cigmail This weeks specials: - Davidoff From $1.76 pack! - Marlboro From $1.81 pack! - Dunhill From $1.81 pack! - Salem From $1.81 pack! Visit us at: http://www.CigaretteStation.com Brands we stock: Marlboro | Winston | Dunhill | Salem | Parliament Davidoff | L&M | Camel | Rothmans | Lucky Strike Kent | Pall Mall | Virginia Slims |Vogue | Chesterfield Mild Seven | More | Gauloises | Gitanes | 555 http://www.CigaretteStation.com Please note: You must be 18 years or older to order cigarettes and other Tobacco products from this site We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mails of this sort from us, please click on the following link to unsubscribe from our mailing list: http://www.jumbomailer.com/cgi-bin/jumbomailer/unsubscribe.cgi?UNSUBID=NTcwNjEtOTExMDR8Y2lnc3RhdGlvbnxtaWRjb21AaWV0Zi5vcmc= This email was sent to: midcom@ietf.org ------=_Next_Part_0000000000_jumbomailer_57061-91104=---- Content-Type: text/html; charset="iso-8859-1"
   

Cigarette Brands:

  Marlboro
  Winston
  Dunhill
  Salem
  Parliament
  Davidoff
  L&M
  Camel
  Rothmans
  Lucky Strike
  Kent
  Pall Mall
  Virginia Slims
  Vogue
  Chesterfield
  Mild Seven
  More
  Gauloises
  Gitanes
  555
 

General Info:

  About Us
  Ordering
  Shipping
  FAQ
  Contact Us
  Customer Support

>>http://www.CigaretteStation.com <<

Welcome!

Thanks for joining the Cigarette Station Newsletter! We'll keep you continually up-to-date with our specials as soon as they are available. We often quote prices as low as $1.76 a pack!

Remember, if you ever want to unsubscribe you can use the link at the bottom of this newsletter.

This weeks featured Bargains are:


Marlboro
From $1.81 pack!

  
Davidoff
From $1.76 pack!

Dunhill
From $1.81 pack!

  
Salem
From $1.81 pack!


Come visit us: http://www.CigaretteStation.com

Subscribe | Unsubscribe | Refer a friend

Please note: You must be 18 years or older to order cigarettes and other Tobacco products from this site.

>>http://www.CigaretteStation.com <<

 
We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mails of this sort from us, please click on the following link to unsubscribe from our mailing list: Unsubscribe

This email was sent to: midcom@ietf.org
------=_Next_Part_0000000000_jumbomailer_57061-91104=------ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Mar 1 14:26:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17591 for ; Fri, 1 Mar 2002 14:26:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22485 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 14:26:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22401; Fri, 1 Mar 2002 14:24:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22364 for ; Fri, 1 Mar 2002 14:23:58 -0500 (EST) Received: from nt (adsl-66-123-53-169.dsl.lsan03.pacbell.net [66.123.53.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17382 for ; Fri, 1 Mar 2002 14:23:54 -0500 (EST) Message-Id: <200203011923.OAA17382@ietf.org> From: "Ree Soo Club" To: Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Fri, 1 Mar 2002 11:17:43 Subject: [midcom] [웹 광 고] 하리수 전문사이트 모음(누드 영상집 최초 공개) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org
본 사이트는 21세 이상성인만이 관람및 열람하실수 있읍니다.
본 광고는 정보통신부 스팸관련 법령을 준수하고 단 한번의 메일로 종료되며
추가메일링이 생기지 않습니다. 구독신청이나 해지는 반드시 이메일로 해주시기 바랍니다.
 
[성인 21세 전용 ]
 
하리수의 누드집과 말도 많은 자위행위 비디오를 공개합니다.
하리수 멤버에 가입하셔야 하며 무단 배포를 금합니다.
또한 자위행위비디오는 본인 확인이 않된 상태로 무단 배포시 법적인 책임을
지게 됩니다.
 
사이트 안내:
 
http://www.risu.da.ru/
http://www.harisu.da.ru/
http://www.risucafe.com/
http://www.harisuclub.wo.to/
http://www.venuswonder.com/suri/
http://www.pogoproducts.com/beta/vti/
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Mar 1 14:47:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19830 for ; Fri, 1 Mar 2002 14:47:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23747 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 14:47:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23695; Fri, 1 Mar 2002 14:45:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23670 for ; Fri, 1 Mar 2002 14:45:47 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19719 for ; Fri, 1 Mar 2002 14:45:42 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id OAA21937 for ; Fri, 1 Mar 2002 14:44:27 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B6F.006C6A8D ; Fri, 1 Mar 2002 14:44:11 -0500 X-Lotus-FromDomain: MITEL To: midcom@ietf.org Message-ID: <85256B6F.006C6822.00@kanmta01.software.mitel.com> Date: Fri, 1 Mar 2002 14:44:14 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA23671 Subject: [midcom] =?iso-8859-1?Q?Signal_to_SPAM_Ratio_Below_Unity_--_Re:_[midcom]_[?= =?iso-8859-1?Q?=C0=A5_=B1=A4_=B0=ED]_=C7=CF=B8=AE=BC=F6_=C0=FC=B9=AE?= =?iso-8859-1?Q?=BB=E7=C0=CC=C6=AE_=B8=F0=C0=BD(=B4=A9=B5=E5_=BF=B5?= =?iso-8859-1?Q?=BB=F3=C1=FD_=C3=D6=C3=CA_=B0=F8=B0=B3)?= Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit From: Tom Gray@MITEL on 03/01/2002 02:44 PM An announcement on the IMPP list has just been sent to the effect that theany notes from non-members will be forwarded to the chair for approval before being sent to the list. The chair had asked for and received permission to do this. This was due to the very low signal to SPAM ratio. Since this ratio on this list appears to have moved below 1, Would it be possible to move to the same system here. "Ree Soo Club" on 03/01/2002 06:17:43 AM To: midcom@ietf.org cc: (bcc: Tom Gray/Kan/Mitel) Subject: [midcom] [웹 광 고] 하리수 전문사이트 모음(누드 영상집 최초 공개) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Mar 1 14:56:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21045 for ; Fri, 1 Mar 2002 14:56:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24123 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 14:56:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAB24071; Fri, 1 Mar 2002 14:55:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24042 for ; Fri, 1 Mar 2002 14:54:56 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20947 for ; Fri, 1 Mar 2002 14:54:50 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g21JsLx17039; Fri, 1 Mar 2002 11:54:21 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACZ43809; Fri, 1 Mar 2002 11:52:33 -0800 (PST) Message-Id: <5.1.0.14.0.20020301145432.00a7c8d0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Mar 2002 14:58:00 -0500 To: Tom_Gray@Mitel.COM, midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Signal to SPAM Ratio Below Unity -- Re: [midcom] [ 웹 광 고] 하리수 전문 사이트 모음(누드 영 상집 최초 공개) In-Reply-To: <85256B6F.006C6822.00@kanmta01.software.mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:44 PM 3/1/02 -0500, Tom_Gray@Mitel.COM wrote: >An announcement on the IMPP list has just been sent to the effect that theany >notes from non-members will be forwarded to the chair for approval before being >sent to the list. The chair had asked for and received permission to do this. >This was due to the very low signal to SPAM ratio. Since this ratio on this list >appears to have moved below 1, Would it be possible to move to the same system >here. We had this discussion here and on the main IETF mailing list last year, and the conclusion was that it's less work to allow most stuff through than it is to deal with whining from that constituency which believes that holding any mail for approval constitutes censorship. Also, spammers are now subscribing their bogus addresses to mailing lists, like midcom, in order to get their mail through. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Mar 1 15:46:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25691 for ; Fri, 1 Mar 2002 15:46:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27273 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 15:46:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27250; Fri, 1 Mar 2002 15:45:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27220 for ; Fri, 1 Mar 2002 15:45:16 -0500 (EST) Received: from ruby.he.net (ruby.he.net [216.218.187.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25520 for ; Fri, 1 Mar 2002 15:45:13 -0500 (EST) Received: from hyksoscharliei ([212.161.14.185] (may be forged)) by ruby.he.net (8.8.6/8.8.2) with SMTP id MAA18687 for ; Fri, 1 Mar 2002 12:43:57 -0800 Message-ID: <000901c1c162$f8b8c920$c350a8c0@hyksoscharliei> From: "R Cescon" To: Date: Fri, 1 Mar 2002 20:52:14 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C1C162.F7B82200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [midcom] Invest. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1C162.F7B82200 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C1C162.F7B82200" ------=_NextPart_001_0006_01C1C162.F7B82200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not a member of this discussion yet, but I would like to = partecipate. I have found this message, does anyone know this user of mine? Rob Subject:=20 Discussion Date:=20 Wed, 27 Feb 2002 18:37:18 -0000 From:=20 "Uper Lescun" To:=20 It's almost that time of the year again. That's right - time for another = material demonstration of your love in the ballet of relentless consumption. Why question the ritual when you can react mindlessly and = predictably? You can get her the cute teddy bear and act out the little girl fantasy or get her the chocolates so there will be that much = more of her to love. I mock mindlessness because I will always hate the lies that act as easy answers and widen the void that modern culture = digs for all. You are either brave and move forward with noble values or you cower to what is easy, dishonest, and comfortable. If 95% of = humanity is unable to think for itself and merely exists by emulating = the ideology of commercial culture, what does that say for our collective = future? Many of these people are good inside, but remain asleep as life merely happens to them. Can you go to this site about human rights and let me know about your = opinion? Human Rights News What do you think about saerch engine positioning? Can you let me know? If you come in London you will stay free in my hotel: London PROPAGANDA = Hotel=20 Again about search engine positioning, Eif NET,Eif NET RT,EuCtBu RT,Hyksos Matrix Securities Group=20 Stateframe By Alia System Press for support Go by Coach by National = Express Vistapapers=20 is the no. 1 in London-UK, is it fair that this people put your page on = top for a fee? They have the monopoly of Banking Keywords, You should join with me the Anti Eif Pressure Group, We have to stop them they are too good and they are manipulating the = net! Write to me we can stop them! Anti Eif OWAP Pressure Group They even are the best Data Recovery and Firewall security Tester read = about Good News Search Engine Example the Amex and Chase Manhattan Bank Visa MasterCard no1 on yahoo = with: EIF NET : SECURITY EXPERT AND=20 ___________________________________________________=20 REMOVAL remove@eif.net To unsubscribe: REMOVAL PAGE Under US EU LAW Your email is considered by our server OPT IN-SUSCRIBED Earn up to 11% back for every purchase you make - Stockback MasterCard = from Chase=20 Capital One UK - Football MasterCard EIF NET IS NOT RESPONSABLE FOR THE CONTENT OF EMAILS OR WEB SITES OF ITS = USERS. ANY COMPLAIN (Info@eif.net) AS FOR THE US FOI AND UK DATA PROTECTION ACT ANY REMOVAL = REQUEST ON ALL OUR SERVERS IS GOING ON THE EIF PUBLIC REMOVAL LISTS YOU CAN CHECK THEM AT = http://www.e-c-b.com/remove/ IF YOU HAVE REMOVED ONCE AND YOU RECEIVE OTHER EMAILS WE WILL CONSIDER IT SPAM AND = WE WILL SHUT DOWN THE ACCOUNT. OUR REMOVAL LIST HAS BEEN STARTED ON 1998=20 _________________________________________ Roberto Cescon ICQ#:93867901 Current ICQ status:=20 SMS: (Send an SMS message to my ICQ): +278314293867901 More ways to contact me: http://wwp.icq.com/93867901 _________________________________________=20 _________________________________________ Roberto Cescon ICQ#:93867901 Current ICQ status:=20 SMS: (Send an SMS message to my ICQ): +278314293867901 More ways to contact me: http://wwp.icq.com/93867901 _________________________________________=20 ------=_NextPart_001_0006_01C1C162.F7B82200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
I am not a member of this discussion = yet, but I=20 would like to partecipate.
I have found this message, does anyone = know this=20 user of mine?
 
 
Rob
 
 
 
 
 
 
 
Subject:=20
        = Discussion
   Date:=20
        Wed, 27 Feb 2002 18:37:18 = -0000
   From: =
        "Uper=20 Lescun" <group@eif.net>
   =  =20 To:
        <widya.pribadi@gecapital.com>
 
 
 

It's almost that time of the year again. That's right - time = for=20 another material demonstration of your love in the ballet of=20 relentless
consumption. Why question the ritual when you can react = mindlessly=20 and predictably? You can get her the cute teddy bear and act out = the
little=20 girl fantasy or get her the chocolates so there will be that much more = of her to=20 love. I mock mindlessness because I will always hate the
lies that = act as=20 easy answers and widen the void that modern culture digs for all. You = are either=20 brave and move forward with noble values or
you cower to what is = easy,=20 dishonest, and comfortable. If 95% of humanity is unable to think for = itself and=20 merely exists by emulating the
ideology of commercial culture, what = does that=20 say for our collective future? Many of these people are good inside, but = remain=20 asleep as life
merely happens to them.
 
Can you go to this site about human rights and let me know about = your=20 opinion? Human Rights News
What do you think about saerch engine = positioning?=20 Can you let me know?
If you come in London you will stay free in my = hotel:=20 London PROPAGANDA Hotel
Again about search engine = positioning,
Eif=20 NET,Eif NET RT,EuCtBu RT,Hyksos Matrix Securities Group
Stateframe = By Alia=20 System Press for support Go by Coach by National Express Vistapapers =
is the=20 no. 1 in London-UK, is it fair that this people put your page on top for = a=20 fee?
They have the monopoly of Banking Keywords,
You should join = with me=20 the Anti Eif Pressure Group,
We have to stop them they are too good = and they=20 are manipulating the net!
 
Write to me we can stop them! Anti Eif OWAP Pressure Group
They = even are=20 the best Data Recovery and Firewall security Tester read about Good=20 News
Search Engine
Example the Amex and Chase Manhattan Bank Visa=20 MasterCard no1 on yahoo with: EIF NET : SECURITY EXPERT AND=20
___________________________________________________
REMOVAL remove@eif.net
 
To unsubscribe: REMOVAL PAGE
Under US EU LAW Your email is = considered by=20 our server OPT IN-SUSCRIBED
 
Earn up to 11% back for every purchase you make - Stockback = MasterCard from=20 Chase
Capital One UK - Football MasterCard
 
EIF NET IS NOT RESPONSABLE FOR THE CONTENT OF EMAILS OR WEB SITES = OF ITS=20 USERS. ANY COMPLAIN
(Info@eif.net) AS FOR=20 THE US FOI AND UK DATA PROTECTION ACT ANY REMOVAL REQUEST ON ALL OUR=20 SERVERS
IS GOING ON THE EIF PUBLIC REMOVAL LISTS YOU CAN CHECK THEM = AT http://www.e-c-b.com/remove/ = IF YOU=20 HAVE
REMOVED ONCE AND YOU RECEIVE OTHER EMAILS WE WILL CONSIDER IT = SPAM AND=20 WE WILL SHUT DOWN THE
ACCOUNT. OUR REMOVAL LIST HAS BEEN STARTED ON = 1998=20
_________________________________________
Roberto = Cescon
ICQ#:93867901
Current ICQ=20 status: =

SMS:=20 (Send an SMS message to my ICQ): +278314293867901
More ways to contact = me: http://wwp.icq.com/93867901
_________________= ________________________=20
_________________________________________
Roberto = Cescon
ICQ#:93867901
Current ICQ=20 status: =

SMS:=20 (Send an SMS message to my ICQ): +278314293867901
More ways to contact = me: http://wwp.icq.com/93867901
_________________= ________________________=20
------=_NextPart_001_0006_01C1C162.F7B82200-- ------=_NextPart_000_0005_01C1C162.F7B82200 Content-Type: application/octet-stream; name="online.dll?icq=93867901&img=7" Content-Transfer-Encoding: base64 Content-Location: http://wwp.icq.com/scripts/online.dll?icq=93867901&img=7 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhOQAPANX/AP///1paWmNjY3t7e4SEhIyMjKWlpa2trbW1tcbGxs7OztbW1t7e3ufn5+/v 7/f3987GxtbOzufe3r21ta2lpbWtrZSMjKWcnHtzc4R7e97Ozq2cnJyMjKWUlIx7e4Rzc3tra3Nj Y2taWoRra2NKSlpCQlI5OUoxMTkhISkQEDEQEHsICIwICJQICJwICKUICLUICL0ICCEAAHMIAHsI AGsIAKVza5xza62MhFI5Qs4AEN4AEP8AEAAAAAAAAAAAACwAAAAAOQAPAEAG/0CAcEgsGo/IZLFR IBAKDQCO1oLpdjpYi4YTfmSKRcMhAy1kHwVFRlF8F++3Ipdbiz6Y9MKBtM1YLS4tLDM2QxIqJxQX JyoJDTIkFWsZE18MEBMODg9KQgQAAQ+jAKBCGjg3OBpID5ubnaOys7S1o6+dSqiqrJ6+v0QFDgYF AwcOBVNVV1lbXQAlJQwLDA4lORwyJhciMiIVX24yDBllGyokC+gVJyTVDAQODWMEUX6AgoSGQwok MpETFpzJsKCCjAoLyjGII0NgtAUIUMhA0YFaLmAYM2rcyNFXg3jzHNQTcqMGjRU0auwbEqHEPxIJ OH1RIcElCQ8yHOAk5QuUAJRZpTTUYPECRgwYL1jU6HVJoIIyICZaOCHjxIFwHHI06ABixMSYECRK 4ySMmDFkNla4iLGDx44YLlbseyjmwUM0CQywScAQTkMFJkzY+WACzLsmT6IIJWoUqdJeiE5c2NAI wpk0axD2fbMgR4kFKbaFSFMtiQ2TKGvcMPKgwTRqYxwwGOOa9uzarjfhFljtYsffHYMAADsA ------=_NextPart_000_0005_01C1C162.F7B82200-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Mar 1 16:16:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28526 for ; Fri, 1 Mar 2002 16:16:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29603 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 16:16:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29443; Fri, 1 Mar 2002 16:14:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29404 for ; Fri, 1 Mar 2002 16:14:14 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28394 for ; Fri, 1 Mar 2002 16:14:12 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21LDJk05144; Fri, 1 Mar 2002 16:13:19 -0500 (EST) Received: from matt.verizon.net (MATT [10.128.82.148]) by sonusdc3.sonusnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1Z0KC10J; Fri, 1 Mar 2002 16:13:27 -0500 Message-Id: <5.1.0.14.2.20020301130957.02411310@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Mar 2002 13:11:42 -0800 To: Melinda Shore , midcom@ietf.org From: Matt Holdrege Subject: Re: [midcom] Signal to SPAM Ratio Below Unity -- Re: [midcom] [ =?iso-8859-1?Q?=C0=A5?= =?iso-8859-1?Q?_=B1=A4_=B0=ED]_?= =?iso-8859-1?Q?=C7=CF=B8=AE=BC=F6?= =?iso-8859-1?Q?_=C0=FC=B9=AE_?= =?iso-8859-1?Q?=BB=E7=C0=CC=C6=AE?= =?iso-8859-1?Q?_=B8=F0=C0=BD(?= =?iso-8859-1?Q?=B4=A9=B5=E5?= =?iso-8859-1?Q?_=BF=B5_=BB=F3=C1=FD_?= =?iso-8859-1?Q?=C3=D6=C3=CA?= =?iso-8859-1?Q?_=B0=F8=B0=B3)?= In-Reply-To: <5.1.0.14.0.20020301145432.00a7c8d0@localhost> References: <85256B6F.006C6822.00@kanmta01.software.mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 11:58 AM 3/1/2002, Melinda Shore wrote: >At 02:44 PM 3/1/02 -0500, Tom_Gray@Mitel.COM wrote: > >An announcement on the IMPP list has just been sent to the effect that > theany > >notes from non-members will be forwarded to the chair for approval > before being > >sent to the list. The chair had asked for and received permission to do > this. > >This was due to the very low signal to SPAM ratio. Since this ratio on > this list > >appears to have moved below 1, Would it be possible to move to the same > system > >here. > >We had this discussion here and on the main IETF mailing list >last year, and the conclusion was that it's less work to allow >most stuff through than it is to deal with whining from that >constituency which believes that holding any mail for approval >constitutes censorship. Also, spammers are now subscribing their >bogus addresses to mailing lists, like midcom, in order to get >their mail through. It's really up to the chair to update the filter whenever the list receives spam. I try to do this on the NAT list and it has dramatically reduced the amount of spam. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Mar 1 17:11:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02990 for ; Fri, 1 Mar 2002 17:11:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03399 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 17:11:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03330; Fri, 1 Mar 2002 17:10:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03301 for ; Fri, 1 Mar 2002 17:10:15 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02918 for ; Fri, 1 Mar 2002 17:10:13 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g21M9jT15856; Fri, 1 Mar 2002 14:09:45 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACZ48303; Fri, 1 Mar 2002 14:07:57 -0800 (PST) Message-Id: <5.1.0.14.0.20020301165953.00ac4990@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Mar 2002 17:13:20 -0500 To: Matt Holdrege , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Signal to SPAM Ratio Below Unity -- Re: [midcom] [ 웹 광 고] 하리수 전문 사이트 모음( 누드 영 상집 최초 공개) In-Reply-To: <5.1.0.14.2.20020301130957.02411310@mail.verizon.net> References: <5.1.0.14.0.20020301145432.00a7c8d0@localhost> <85256B6F.006C6822.00@kanmta01.software.mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 01:11 PM 3/1/02 -0800, Matt Holdrege wrote: >It's really up to the chair to update the filter whenever the list receives spam. I try to do this on the NAT list and it has dramatically reduced the amount of spam. We're actually doing a fair amount of filtering already, and I'm reviewing and discarding typically between 4 and 9 messages each day. The filtering is on a set of heuristics that has nothing to do with subscription status. Adding filters for each piece of spam that makes it through creates more work than it saves, because spammers tend not to reuse email addresses or subject headers. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Mar 1 17:16:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03296 for ; Fri, 1 Mar 2002 17:16:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03590 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 17:17:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03538; Fri, 1 Mar 2002 17:15:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03511 for ; Fri, 1 Mar 2002 17:15:19 -0500 (EST) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03178 for ; Fri, 1 Mar 2002 17:15:17 -0500 (EST) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 41FB88214 for ; Fri, 1 Mar 2002 16:15:19 -0600 (CST) Received: by isis.visi.com (Postfix, from userid 2286) id EF4FF76C27; Fri, 1 Mar 2002 16:15:18 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by isis.visi.com (Postfix) with ESMTP id E26FC76C26 for ; Fri, 1 Mar 2002 16:15:18 -0600 (CST) Date: Fri, 1 Mar 2002 16:15:18 -0600 (CST) From: Andrew Molitor To: midcom@ietf.org In-Reply-To: <5.1.0.14.0.20020301165953.00ac4990@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [midcom] =?X-UNKNOWN?Q?Re=3A_=5Bmidcom=5D_Signal_to_SPAM_Ratio_Below?= =?X-UNKNOWN?Q?_Unity_--_Re=3A_=5Bmidcom=5D__=5B__=C0=A5?= =?X-UNKNOWN?Q?_=B1=A4_=B0=ED=5D__=C7=CF=B8=AE=BC=F6_=C0=FC=B9?= =?X-UNKNOWN?Q?=AE__=BB=E7=C0=CC=C6=AE_=B8=F0=C0=BD=28_=B4=A9=B5?= =?X-UNKNOWN?Q?=E5_=BF=B5_=BB=F3=C1=FD__=C3=D6=C3=CA_=B0=F8=B0?= =?X-UNKNOWN?Q?=B3=29?= Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Is it possible to filter on something like 'more than half the characters are not printable' and 'includes the keyword "forklift"'? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Mar 1 17:55:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04788 for ; Fri, 1 Mar 2002 17:54:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05332 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 17:54:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05193; Fri, 1 Mar 2002 17:50:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05163 for ; Fri, 1 Mar 2002 17:50:25 -0500 (EST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04567 for ; Fri, 1 Mar 2002 17:50:23 -0500 (EST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 1 Mar 2002 14:48:43 -0800 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Mar 2002 14:48:56 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 14:48:56 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 14:48:55 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Fri, 1 Mar 2002 14:47:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [midcom] Re: [midcom] Signal to SPAM Ratio Below Unity Date: Fri, 1 Mar 2002 14:47:05 -0800 Message-ID: Thread-Topic: [midcom] Re: [midcom] Signal to SPAM Ratio Below Unity thread-index: AcHBblZMn6I4w0DIQ9yGWJyqiM7RUQABMHCA From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 01 Mar 2002 22:47:05.0893 (UTC) FILETIME=[0301BD50:01C1C173] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA05164 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > Is it possible to filter on something like 'more than half the > characters are not printable' and 'includes the keyword "forklift"'? There is an even simpler filter: if it is not plain text, filter it. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Mar 1 19:26:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07882 for ; Fri, 1 Mar 2002 19:26:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA10645 for midcom-archive@odin.ietf.org; Fri, 1 Mar 2002 19:26:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10519; Fri, 1 Mar 2002 19:24:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10488 for ; Fri, 1 Mar 2002 19:24:41 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07806 for ; Fri, 1 Mar 2002 19:24:38 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21Nqwk22101; Fri, 1 Mar 2002 18:52:58 -0500 (EST) Received: from matt.verizon.net (MATT [10.128.82.148]) by sonusdc3.sonusnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1Z0KCF9H; Fri, 1 Mar 2002 18:53:04 -0500 Message-Id: <5.1.0.14.2.20020301154853.00a405a0@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Mar 2002 15:51:09 -0800 To: Melinda Shore , midcom@ietf.org From: Matt Holdrege Subject: Re: [midcom] Signal to SPAM Ratio Below Unity -- Re: [midcom] In-Reply-To: <5.1.0.14.0.20020301165953.00ac4990@localhost> References: <5.1.0.14.2.20020301130957.02411310@mail.verizon.net> <5.1.0.14.0.20020301145432.00a7c8d0@localhost> <85256B6F.006C6822.00@kanmta01.software.mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:13 PM 3/1/2002, Melinda Shore wrote: >At 01:11 PM 3/1/02 -0800, Matt Holdrege wrote: > >It's really up to the chair to update the filter whenever the list > receives spam. I try to do this on the NAT list and it has dramatically > reduced the amount of spam. > >We're actually doing a fair amount of filtering already, and I'm >reviewing and discarding typically between 4 and 9 messages each day. >The filtering is on a set of heuristics that has nothing to do with >subscription status. Adding filters for each piece of spam that makes >it through creates more work than it saves, because spammers tend not to >reuse email addresses or subject headers. My filter list blocks a lot of the spam that I see here on MIDCOM. You are right that they don't always use the same address, but lately a lot of it comes from yahoo.co.kr and gtech21.com and a couple of others. If you could filter those, you'd save us a lot of email. Sorry for spamming on spam. I'll shut up for now. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Mar 3 21:58:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03590 for ; Sun, 3 Mar 2002 21:58:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA15026 for midcom-archive@odin.ietf.org; Sun, 3 Mar 2002 21:58:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14750; Sun, 3 Mar 2002 21:50:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14692 for ; Sun, 3 Mar 2002 21:50:03 -0500 (EST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03527; Sun, 3 Mar 2002 21:49:59 -0500 (EST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA26834; Mon, 4 Mar 2002 11:49:58 +0900 (JST) Received: from pc-pj100h (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA18854; Mon, 4 Mar 2002 11:49:55 +0900 (JST) To: midcom@ietf.org, nat@ietf.org Cc: nats@ml.canonet.ne.jp, nats@nats-project.org From: Kuniaki Kondo Message-Id: <200203041149.FJE08810.OLVJLJB@iij.ad.jp> X-Mailer: Winbiff [Version 2.34beta2] X-Accept-Language: ja,en Date: Mon, 4 Mar 2002 11:49:56 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] [OT]new NATS draft released Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hello, ALL. This is a off topic for this mailing list. However, I would like to announce our new internet draft which was announced to this list few months ago. So, Our draft is named "NATS". And draft name is "draft-kuniaki-capsulated-nats-01.txt" which is submitted 22th Feb. The purpose of this protocol is traverse NAT/NAPT. it is same as middle-box, but framework and mechanism or something are different. This protocol's most advantage is what most client host placed in private network never support this protocol. And, this protocol was enhanced NAT mechanism, thus, implementation is very easy. We will release the first implementation. All information is available at http://www.nats-project.org/ And we have a mailling list to discuss the protocol technically. -- Kuniaki Kondo kuniaki@iij.ad.jp NATS Page : http://www.nats-project.org/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Mar 3 22:48:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05019 for ; Sun, 3 Mar 2002 22:48:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA17095 for midcom-archive@odin.ietf.org; Sun, 3 Mar 2002 22:48:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16838; Sun, 3 Mar 2002 22:37:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16808 for ; Sun, 3 Mar 2002 22:37:08 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04879 for ; Sun, 3 Mar 2002 22:37:06 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g243acT18121 for ; Sun, 3 Mar 2002 19:36:38 -0800 (PST) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACE06187; Sun, 3 Mar 2002 19:36:49 -0800 (PST) From: "Cullen Jennings" To: Subject: RE: [midcom] Signal to SPAM Ratio Below Unity -- Re: [midcom] Date: Sun, 3 Mar 2002 19:38:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <5.1.0.14.2.20020301154853.00a405a0@mail.verizon.net> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I'm sure all possibilities have been considered to death but I have this incredible urge to put in my hair brain scheme :-) Actually this email is pretty much spam itself, but hey, it's not like it's going to change the SPAM/HAM ratio of this group. You can only post if you are subscribed but the Chair does not need to review your post. To subscribe, the chair does need to approve you but you get approval by answering a question that demonstrates you actually know what the topic of the list is. For example Q. The MIDCOM working group is a: A) Group of midwifes and other professionals discussing the difficulties of birthing standards B) A group of anarchists trying to defeat capitalism by causing the collapse of the internet by stopping the deployment of IPv6 C) A groups working on boxes that keep the .com people out of public and in their own little space where they can feel more protected. D) A group of wordsmiths formed in the middle ages that focus on communications and spending much time in dark, smoke filled rooms trying to make sure the OED is growing at a respectable rate. Sorry, Cullen :-) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 4 07:15:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21281 for ; Mon, 4 Mar 2002 07:15:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA24185 for midcom-archive@odin.ietf.org; Mon, 4 Mar 2002 07:15:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23590; Mon, 4 Mar 2002 07:08:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23557 for ; Mon, 4 Mar 2002 07:08:11 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20750; Mon, 4 Mar 2002 07:08:07 -0500 (EST) Message-Id: <200203041208.HAA20750@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 04 Mar 2002 07:08:07 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-framework-07.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communication Architecture and framework Author(s) : P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan Filename : draft-ietf-midcom-framework-07.txt Pages : 35 Date : 01-Mar-02 There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications such as SIP and H.323 and peer-to-peer applications such as Napster and NetMeeting cannot be identified by merely examining packet headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-07.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-ietf-midcom-framework-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-framework-07.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: <20020301135405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-framework-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-framework-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301135405.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 4 09:20:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25584 for ; Mon, 4 Mar 2002 09:20:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01342 for midcom-archive@odin.ietf.org; Mon, 4 Mar 2002 09:20:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01232; Mon, 4 Mar 2002 09:18:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01201 for ; Mon, 4 Mar 2002 09:18:16 -0500 (EST) Received: from hotmail.com ([218.51.101.77]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25476 for ; Mon, 4 Mar 2002 09:18:10 -0500 (EST) Message-Id: <200203041418.JAA25476@ietf.org> Reply-To: hanbay7@hotmail.com From: HanBay To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 4 Mar 2002 23:15:17 +0900 Subject: [midcom] [광 고] 해외교포들의 한국식품 종합쇼핑몰 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org :+: 한베이 홍보메일 :+:
+ 클릭하시면 바로 저희 자료에서 귀하의 이메일 주소가 삭제됩니다   ☞ 수신거부
 
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 4 19:46:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02148 for ; Mon, 4 Mar 2002 19:46:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13631 for midcom-archive@odin.ietf.org; Mon, 4 Mar 2002 19:46:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13572; Mon, 4 Mar 2002 19:44:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13512 for ; Mon, 4 Mar 2002 19:44:38 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02114 for ; Mon, 4 Mar 2002 19:44:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g250i86Y025377; Mon, 4 Mar 2002 19:44:08 -0500 (EST) Message-ID: <3C8414A0.A4E1363A@dynamicsoft.com> Date: Mon, 04 Mar 2002 19:43:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings CC: midcom@ietf.org Subject: Re: [midcom] note to design team on STUN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit This has been pointed out to me by others. I have made the change in -01 to do natural alignment. Thanks, Jonathan R. Cullen Jennings wrote: > > Would be nice if any 32 bit values like address in the message were > aligned > on word boundaries. > > Thanks, Cullen > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 4 19:50:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02263 for ; Mon, 4 Mar 2002 19:50:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13868 for midcom-archive@odin.ietf.org; Mon, 4 Mar 2002 19:50:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13565; Mon, 4 Mar 2002 19:44:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13501 for ; Mon, 4 Mar 2002 19:44:38 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02113 for ; Mon, 4 Mar 2002 19:44:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g250ho6Y025374; Mon, 4 Mar 2002 19:43:54 -0500 (EST) Message-ID: <3C84148E.401BDEA4@dynamicsoft.com> Date: Mon, 04 Mar 2002 19:42:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings CC: midcom@ietf.org, Rohan Mahy , jweinberger@dynamicsoft.com, huitema@microsoft.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Which port to put in the Changed-Address attribute? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Responses inline. Cullen Jennings wrote: > > All comments referring to draft-rosenberg-midcom-stun-00.txt > > Imagine the case where a STUN server is running on two interfaces, A and > B. > This could be on one computer or as a second server on another computer. > Now > lets say I am using ports 5000 and 5001 and interface A and 6000 and > 6001 on > interface B. When A gets a request, if no flags are set it will return a > response from 5000. If the change ip flag is set it will get a response > from > port 6000 on IP B. If both flags are set, it will get a response from > 6001 > on IP B. > > Now the 3rd paragraph on page 7 says "The server must add a > CHANGE-ADDRESS > attribute ... that contains the source IP address and port that would be > used ...". It clear I put the address of B in but what port do I put in > 5001, 6000, or 6001? Good question. Let me express it another way. The client can request a change in IP only, a change in port only, or both. When the changed address is returned, which of those are assumed? > > I can see two responses too this: > > 1) you can't do that - if you use port 5000 and 5001 on A you MUST use > 5000 > and 5001 on B. > > 2) we need to add a bit to deal with this case > > I'm in favor or option 1 but wanted to make sure this is what the > authors > had intended. I honestly hadn't thought about it. I think (1) is simpler. Option (2) would entail returning at least two CHANGED-ADDRESSes in the response - one of the case of a change in port, and the other, for a case of change in address and port. Rather than add another attribute, I think its easy enough to simply mandate the same port be used. Thanks for your comment, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Mar 5 05:49:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22814 for ; Tue, 5 Mar 2002 05:49:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA24319 for midcom-archive@odin.ietf.org; Tue, 5 Mar 2002 05:49:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24080; Tue, 5 Mar 2002 05:42:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24055 for ; Tue, 5 Mar 2002 05:42:30 -0500 (EST) Received: from yourwebsite.com (ppp118-44.blf.ssi-pci.net [63.118.118.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22773 for ; Tue, 5 Mar 2002 05:42:25 -0500 (EST) From: breenterprises@yahoo.com Message-Id: <200203051042.FAA22773@ietf.org> Reply-To: breenterprises@yahoo.com To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 5 Mar 2002 05:43:03 -0500 Subject: [midcom] In need of 10 dedicated individuals!!! Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Dear Friend, I am looking for 10 people that are willing to dedicate 5-15 hours a week. I will personally be there every step of the way to assist you on your journey, whether your goals include more free time, more money in your pocket, or just overall happiness, I would like to help you. -----Do you have the time you need to enjoy the things you really love? -----Are you happy with your current job, and the amount of time you put in each week? -----Do you wish that you could be making the kind of money you deserve? Well, I can tell you from personal experience that you can achieve your goals. If you are willing to dedicate a l ittle of your time, and allow me to help you along the way, we can both achieve our goals. If you want more information about how I can help you please go to the following website, and then reply with your thought or any questions you may have. Go To: http://breenterprises.tripod.com/pointer.html Best Regards, Benjamin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 6 03:18:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27176 for ; Wed, 6 Mar 2002 03:18:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA21656 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 03:18:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21576; Wed, 6 Mar 2002 03:16:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21546 for ; Wed, 6 Mar 2002 03:16:12 -0500 (EST) Received: from znsgs01r.europe.nortel.com (h90s128a211n47.user.nortelnetworks.com [47.211.128.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27150 for ; Wed, 6 Mar 2002 03:16:08 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g268FD508907 for ; Wed, 6 Mar 2002 08:15:13 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 08:15:42 -0000 Message-ID: From: "Cedric Aoun" To: "Midcom IETF (E-mail)" Cc: "Sanjoy Sen" Date: Wed, 6 Mar 2002 08:15:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C4E7.1742D570" Subject: [midcom] Identifying Intra realm calls Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1C4E7.1742D570 Content-Type: text/plain; charset="iso-8859-1" Hello, > One of the open issues that had been briefly discussed in the mailing list > in the context of the pre-Midcom solutions - STUN, PHANTOM and MINT - is > how to effectively route intra-realm calls (e.g. calls behind the same > NAT), i.e., how does the client or a signaling server determine that the > called party is in the same network realm and the media is directly > routable without going through the NAT or a relay NAT (i.e. a Media > Proxy). For example, the last para of Sec 9.3 in STUN draft states: It is > possible that both participants in the multimedia session are behind the > same NAT. In that case, both will repeat this procedure > above, and both will obtain public address bindings. When one sends > media to the other, the media is routed to the nat, and then turns > right back around to come back into the enterprise, where it is > translated to the private address of the recipient. This is not > particularly efficient, but it does work. > > Note that, the above solution is not applicable to NATs all vendors. Given > that a significant percentage of Enterprise calls are intra-realm, the > issue, if resolved, will lead to considerable saving of egress bandwidth > at the NAT and will lead to general improvement in service quality. Note that this is also an issue within the MIDCOM framework. An ID was submitted to discuss this issue http://www.ietf.org/internet-drafts/draft-aoun-midcom-intrarealmcalls-00.txt > The intent of this ID is to initiate some discussions (perhaps, offline) > towards a solution for this issue. The intent is in no way to disrupt the > progress of the WG's chartered work items, so, if you're interested to > work on this problem, please send comments offline and we can move the > discussions to a private mailing list (midcom-interest@eng.registro.br). Thanks Cedric Cedric Aoun Nortel Networks France mailto:cedric.aoun@nortelnetworks.com > > ------_=_NextPart_001_01C1C4E7.1742D570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Identifying Intra realm calls

Hello,

One of the open issues that had been = briefly discussed in the mailing list in the context of the pre-Midcom = solutions - STUN, PHANTOM and MINT - is how to effectively route = intra-realm calls (e.g. calls behind the same NAT), i.e., how does the client or a signaling server = determine that the called party is in the same network realm and the = media is directly routable without going through the NAT or = a relay NAT (i.e. a Media = Proxy). For example, the last para = of Sec 9.3 in STUN draft states: It is possible that both participants in the multimedia session = are behind the same NAT. In that case, both will repeat this = procedure

   above, and both = will obtain public address bindings. When one sends
   media to the = other, the media is routed to the nat, and then turns
   right back around = to come back into the enterprise, where it is
   translated to the = private address of the recipient. This is not
   particularly = efficient, but it does work.

Note that, the above solution is not = applicable to NATs all vendors. Given that a significant percentage of = Enterprise calls are intra-realm, the issue, if resolved, will lead to = considerable saving of egress bandwidth at the NAT and will lead to = general improvement in service quality.

Note that this is = also an issue within the MIDCOM framework.

An ID was submitted = to discuss this issue http://www.ietf.org/internet-drafts/draft-aoun-midcom-= intrarealmcalls-00.txt

The intent of this ID is to initiate = some discussions (perhaps, offline) towards a solution for this issue. = The intent is in no way to disrupt the progress of the WG's chartered = work items, so, if you're interested to work on this problem, please = send comments offline = and we can move the discussions to a private mailing list = (midcom-interest@eng.registro.br).

Thanks
Cedric

Cedric Aoun
Nortel Networks
France
mailto:cedric.aoun@nortel= networks.com


 

------_=_NextPart_001_01C1C4E7.1742D570-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 6 11:35:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16673 for ; Wed, 6 Mar 2002 11:35:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22669 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 11:35:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21550; Wed, 6 Mar 2002 11:26:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21524 for ; Wed, 6 Mar 2002 11:26:54 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16121 for ; Wed, 6 Mar 2002 11:26:50 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 6 Mar 2002 08:26:23 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Mar 2002 08:26:22 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 08:26:22 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 08:26:22 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 6 Mar 2002 08:23:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] Identifying Intra realm calls Date: Wed, 6 Mar 2002 08:23:28 -0800 Message-ID: Thread-Topic: [midcom] Identifying Intra realm calls thread-index: AcHE52v5psLMfA02QA6yKGQ1U8SzmAAQw+xQ From: "Christian Huitema" To: "Cedric Aoun" , "Midcom IETF (E-mail)" Cc: "Sanjoy Sen" X-OriginalArrivalTime: 06 Mar 2002 16:23:28.0999 (UTC) FILETIME=[3FEF2F70:01C1C52B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA21525 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit You are correct: many NATs will not "send back" the traffic. The STUN statement is wrong: when two parties are behind the same NAT, not only is the solution not very efficient; in fact, it does not always work. We should only use a solution like STUN when we know that the two stations are "far apart". Even so, there are failure modes, e.g. in the cases of dual NAT: an ISP allocate 10/8 addresses to its customers, who in turn run a NAT. A partial solution is to use multicast discovery to find out whether the other party is local: from the UDP port that uses STUN, send a multicast packet to a conventional IPv4 multicast address and port, documenting something like "I am local and my STUN address is x.x.x.x:p"; the receiver of these packet keeps a catalog; this is what is document in version 04 of the shipworm/teredo draft. You may combine the solution with a hint, e.g. the fact that the STUN mapped addresses of the parties look alike. However, there will still be failure modes, such as the 10/8 ISP. The only real solution to this problem is to use IPv6 and global addresses. All other solutions are hacks. -- Christian Huitema -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Wednesday, March 06, 2002 12:16 AM To: Midcom IETF (E-mail) Cc: Sanjoy Sen Subject: [midcom] Identifying Intra realm calls Hello, One of the open issues that had been briefly discussed in the mailing list in the context of the pre-Midcom solutions - STUN, PHANTOM and MINT - is how to effectively route intra-realm calls (e.g. calls behind the same NAT), i.e., how does the client or a signaling server determine that the called party is in the same network realm and the media is directly routable without going through the NAT or a relay NAT (i.e. a Media Proxy). For example, the last para of Sec 9.3 in STUN draft states: It is possible that both participants in the multimedia session are behind the same NAT. In that case, both will repeat this procedure 젨 above, and both will obtain public address bindings. When one sends 젨 media to the other, the media is routed to the nat, and then turns 젨 right back around to come back into the enterprise, where it is 젨 translated to the private address of the recipient. This is not 젨 particularly efficient, but it does work. Note that, the above solution is not applicable to NATs all vendors. Given that a significant percentage of Enterprise calls are intra-realm, the issue, if resolved, will lead to considerable saving of egress bandwidth at the NAT and will lead to general improvement in service quality. Note that this is also an issue within the MIDCOM framework. An ID was submitted to discuss this issue http://www.ietf.org/internet-drafts/draft-aoun-midcom-intrarealmcalls-00.txt The intent of this ID is to initiate some discussions (perhaps, offline) towards a solution for this issue. The intent is in no way to disrupt the progress of the WG's chartered work items, so, if you're interested to work on this problem, please send comments offline and we can move the discussions to a private mailing list (midcom-interest@eng.registro.br). Thanks Cedric Cedric Aoun Nortel Networks France mailto:cedric.aoun@nortelnetworks.com � _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 6 11:53:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17814 for ; Wed, 6 Mar 2002 11:53:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23766 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 11:53:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23672; Wed, 6 Mar 2002 11:50:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23644 for ; Wed, 6 Mar 2002 11:50:38 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17638 for ; Wed, 6 Mar 2002 11:50:33 -0500 (EST) Received: from jku2.dynamicsoft.com (dhcp165.fokus.gmd.de [195.37.78.165]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g26GoWd11425; Wed, 6 Mar 2002 17:50:32 +0100 Message-Id: <5.1.0.14.0.20020306174821.02229110@mailhost.fokus.gmd.de> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 17:49:57 +0100 To: "Christian Huitema" , "Cedric Aoun" , "Midcom IETF (E-mail)" From: Jiri Kuthan Subject: RE: [midcom] Identifying Intra realm calls Cc: "Sanjoy Sen" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Note there is also the option of having end-to-end STUN and embedding STUN servers in hosts like we do with ping. That makes some cases more simple. -Jiri At 05:23 PM 3/6/2002, Christian Huitema wrote: >You are correct: many NATs will not "send back" the traffic. The STUN statement is wrong: when two parties are behind the same NAT, not only is the solution not very efficient; in fact, it does not always work. We should only use a solution like STUN when we know that the two stations are "far apart". Even so, there are failure modes, e.g. in the cases of dual NAT: an ISP allocate 10/8 addresses to its customers, who in turn run a NAT. > >A partial solution is to use multicast discovery to find out whether the other party is local: from the UDP port that uses STUN, send a multicast packet to a conventional IPv4 multicast address and port, documenting something like "I am local and my STUN address is x.x.x.x:p"; the receiver of these packet keeps a catalog; this is what is document in version 04 of the shipworm/teredo draft. You may combine the solution with a hint, e.g. the fact that the STUN mapped addresses of the parties look alike. However, there will still be failure modes, such as the 10/8 ISP. > >The only real solution to this problem is to use IPv6 and global addresses. All other solutions are hacks. > >-- Christian Huitema > >-----Original Message----- >From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] >Sent: Wednesday, March 06, 2002 12:16 AM >To: Midcom IETF (E-mail) >Cc: Sanjoy Sen >Subject: [midcom] Identifying Intra realm calls > >Hello, >One of the open issues that had been briefly discussed in the mailing list in the context of the pre-Midcom solutions - STUN, PHANTOM and MINT - is how to effectively route intra-realm calls (e.g. calls behind the same NAT), i.e., how does the client or a signaling server determine that the called party is in the same network realm and the media is directly routable without going through the NAT or a relay NAT (i.e. a Media Proxy). For example, the last para of Sec 9.3 in STUN draft states: It is possible that both participants in the multimedia session are behind the same NAT. In that case, both will repeat this procedure > above, and both will obtain public address bindings. When one sends > media to the other, the media is routed to the nat, and then turns > right back around to come back into the enterprise, where it is > translated to the private address of the recipient. This is not > particularly efficient, but it does work. >Note that, the above solution is not applicable to NATs all vendors. Given that a significant percentage of Enterprise calls are intra-realm, the issue, if resolved, will lead to considerable saving of egress bandwidth at the NAT and will lead to general improvement in service quality. >Note that this is also an issue within the MIDCOM framework. >An ID was submitted to discuss this issue http://www.ietf.org/internet-drafts/draft-aoun-midcom-intrarealmcalls-00.txt >The intent of this ID is to initiate some discussions (perhaps, offline) towards a solution for this issue. The intent is in no way to disrupt the progress of the WG's chartered work items, so, if you're interested to work on this problem, please send comments offline and we can move the discussions to a private mailing list (midcom-interest@eng.registro.br). >Thanks >Cedric >Cedric Aoun >Nortel Networks >France >mailto:cedric.aoun@nortelnetworks.com > > > >_______________________________________________ >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 daemon@optimus.ietf.org Wed Mar 6 12:06:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18661 for ; Wed, 6 Mar 2002 12:06:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26076 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 12:06:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25882; Wed, 6 Mar 2002 12:03:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25849 for ; Wed, 6 Mar 2002 12:03:52 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18508 for ; Wed, 6 Mar 2002 12:03:47 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g26H3EN02541; Wed, 6 Mar 2002 11:03:14 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 11:03:13 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011879B1@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Christian Huitema'" , "Cedric Aoun", "Midcom IETF (E-mail)" Subject: RE: [midcom] Identifying Intra realm calls Date: Wed, 6 Mar 2002 11:03:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C530.CD003710" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1C530.CD003710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christian, Thanks for your comments. See inline. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Wednesday, March 06, 2002 10:23 AM > To: Aoun, Cedric [QPD:MA01:EXCH]; Midcom IETF (E-mail) > Cc: Sen, Sanjoy [NGC:B692:EXCH] > Subject: RE: [midcom] Identifying Intra realm calls >=20 >=20 > You are correct: many NATs will not "send back" the traffic.=20 > The STUN statement is wrong: when two parties are behind the=20 > same NAT, not only is the solution not very efficient; in=20 > fact, it does not always work.=20 I thought so too. Then this should be mentioned in the next version of = STUN document.=20 > We should only use a solution=20 > like STUN when we know that the two stations are "far apart".=20 Not sure how would you determine if the stations are "wide apart". > Even so, there are failure modes, e.g. in the cases of dual=20 > NAT: an ISP allocate 10/8 addresses to its customers, who in=20 > turn run a NAT. >=20 > A partial solution is to use multicast discovery to find out=20 > whether the other party is local: from the UDP port that uses=20 > STUN, send a multicast packet to a conventional IPv4=20 > multicast address and port, documenting something like "I am=20 > local and my STUN address is x.x.x.x:p"; the receiver of=20 > these packet keeps a catalog; this is what is document in=20 > version 04 of the shipworm/teredo draft. You may combine the=20 > solution with a hint, e.g. the fact that the STUN mapped=20 > addresses of the parties look alike.=20 The problem, we noted, also occurs when there're multiple NAT's = fronting a=20 big network realm or in case of dual-homed NAT's, when this kind of = hint doesn't work. But, as you said, its a hint anyway:-) Why can't we use a unicast ping-like message to determine connectivity between private addresses behind NAT's? That's one of the possible = solutions discussed in the draft. Sanjoy >=20 > -----Original Message----- > From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com]=20 > Sent: Wednesday, March 06, 2002 12:16 AM > To: Midcom IETF (E-mail) > Cc: Sanjoy Sen > Subject: [midcom] Identifying Intra realm calls >=20 > Hello,=20 > One of the open issues that had been briefly discussed in the=20 > mailing list in the context of the pre-Midcom solutions -=20 > STUN, PHANTOM and MINT - is how to effectively route=20 > intra-realm calls (e.g. calls behind the same NAT), i.e., how=20 > does the client or a signaling server determine that the=20 > called party is in the same network realm and the media is=20 > directly routable without going through the NAT or a relay=20 > NAT (i.e. a Media Proxy). For example, the last para of Sec=20 > 9.3 in STUN draft states: It is possible that both=20 > participants in the multimedia session are behind the same=20 > NAT. In that case, both will repeat this procedure > =A0=A0 above, and both will obtain public address bindings. When=20 > one sends=20 > =A0=A0 media to the other, the media is routed to the nat, and then = turns=20 > =A0=A0 right back around to come back into the enterprise, where it = is=20 > =A0=A0 translated to the private address of the recipient. This is = not=20 > =A0=A0 particularly efficient, but it does work.=20 > Note that, the above solution is not applicable to NATs all=20 > vendors. Given that a significant percentage of Enterprise=20 > calls are intra-realm, the issue, if resolved, will lead to=20 > considerable saving of egress bandwidth at the NAT and will=20 > lead to general improvement in service quality. > Note that this is also an issue within the MIDCOM framework.=20 > An ID was submitted to discuss this issue=20 http://www.ietf.org/internet-drafts/draft-aoun-midcom-intrarealmcalls-00= .txt The intent of this ID is to initiate some discussions (perhaps, = offline) towards a solution for this issue. The intent is in no way to disrupt = the progress of the WG's chartered work items, so, if you're interested to = work on this problem, please send comments offline and we can move the discussions to a private mailing list = (midcom-interest@eng.registro.br). Thanks=20 Cedric=20 Cedric Aoun=20 Nortel Networks=20 France=20 mailto:cedric.aoun@nortelnetworks.com=20 =A0=20 ------_=_NextPart_001_01C1C530.CD003710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Identifying Intra realm calls

Christian, Thanks for your comments. See = inline.

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: Wednesday, March 06, 2002 10:23 AM
> To: Aoun, Cedric [QPD:MA01:EXCH]; Midcom IETF = (E-mail)
> Cc: Sen, Sanjoy [NGC:B692:EXCH]
> Subject: RE: [midcom] Identifying Intra realm = calls
>
>
> You are correct: many NATs will not "send = back" the traffic.
> The STUN statement is wrong: when two parties = are behind the
> same NAT, not only is the solution not very = efficient; in
> fact, it does not always work.

I thought so too. Then this should be mentioned in = the next version of STUN document.

> We should only use a solution
> like STUN when we know that the two stations = are "far apart".

Not sure how would you determine if the stations are = "wide apart".

> Even so, there are failure modes, e.g. in the = cases of dual
> NAT: an ISP allocate 10/8 addresses to its = customers, who in
> turn run a NAT.
>
> A partial solution is to use multicast = discovery to find out
> whether the other party is local: from the UDP = port that uses
> STUN, send a multicast packet to a conventional = IPv4
> multicast address and port, documenting = something like "I am
> local and my STUN address is x.x.x.x:p"; = the receiver of
> these packet keeps a catalog; this is what is = document in
> version 04 of the shipworm/teredo draft. You = may combine the
> solution with a hint, e.g. the fact that the = STUN mapped
> addresses of the parties look alike.

The problem, we noted, also occurs when there're = multiple NAT's fronting a
big network realm or in case of dual-homed NAT's, = when this kind of hint doesn't work. But, as you said, its a hint = anyway:-)

Why can't we use a unicast ping-like message to = determine connectivity between private addresses behind NAT's? That's = one of the possible solutions discussed in the draft.

Sanjoy

>
> -----Original Message-----
> From: Cedric Aoun [mailto:cedric.aoun@nortel= networks.com]
> Sent: Wednesday, March 06, 2002 12:16 AM
> To: Midcom IETF (E-mail)
> Cc: Sanjoy Sen
> Subject: [midcom] Identifying Intra realm = calls
>
> Hello,
> One of the open issues that had been briefly = discussed in the
> mailing list in the context of the pre-Midcom = solutions -
> STUN, PHANTOM and MINT - is how to effectively = route
> intra-realm calls (e.g. calls behind the same = NAT), i.e., how
> does the client or a signaling server determine = that the
> called party is in the same network realm and = the media is
> directly routable without going through the NAT = or a relay
> NAT (i.e. a Media Proxy). For example, the last = para of Sec
> 9.3 in STUN draft states: It is possible that = both
> participants in the multimedia session are = behind the same
> NAT. In that case, both will repeat this = procedure
> =A0=A0 above, and both will obtain public = address bindings. When
> one sends
> =A0=A0 media to the other, the media is routed = to the nat, and then turns
> =A0=A0 right back around to come back into the = enterprise, where it is
> =A0=A0 translated to the private address of the = recipient. This is not
> =A0=A0 particularly efficient, but it does = work.
> Note that, the above solution is not applicable = to NATs all
> vendors. Given that a significant percentage of = Enterprise
> calls are intra-realm, the issue, if resolved, = will lead to
> considerable saving of egress bandwidth at the = NAT and will
> lead to general improvement in service = quality.
> Note that this is also an issue within the = MIDCOM framework.
> An ID was submitted to discuss this issue =
http://www.ietf.org/internet-drafts/draft-aoun-midcom-= intrarealmcalls-00.txt
The intent of this ID is to initiate some = discussions (perhaps, offline) towards a solution for this issue. The = intent is in no way to disrupt the progress of the WG's chartered work = items, so, if you're interested to work on this problem, please send = comments offline and we can move the discussions to a private mailing = list (midcom-interest@eng.registro.br).

Thanks
Cedric
Cedric Aoun
Nortel Networks
France
mailto:cedric.aoun@nortel= networks.com

=A0

------_=_NextPart_001_01C1C530.CD003710-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 6 12:10:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18955 for ; Wed, 6 Mar 2002 12:10:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26398 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 12:10:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25777; Wed, 6 Mar 2002 12:03:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25728 for ; Wed, 6 Mar 2002 12:03:03 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18469 for ; Wed, 6 Mar 2002 12:02:58 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g26H2uF08129; Wed, 6 Mar 2002 12:02:56 -0500 (EST) Message-Id: <200203061702.g26H2uF08129@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Christian Huitema" cc: "Cedric Aoun" , "Midcom IETF (E-mail)" , "Sanjoy Sen" Subject: Re: [midcom] Identifying Intra realm calls In-reply-to: (Your message of "Wed, 06 Mar 2002 08:23:28 PST.") Date: Wed, 06 Mar 2002 12:02:56 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > A partial solution is to use multicast discovery to find out whether the > other party is local: from the UDP port that uses STUN, send a > multicast packet to a conventional IPv4 multicast address and port, > ... one reason this is a partial solution is that some of today's 'Ethernet switch' products don't correctly emulate Ethernet multicast - the sending host thinks it's sending a multicast packet to all other hosts on the subnet but the other hosts never see it. > The only real solution to this problem is to use IPv6 and > global addresses. All other solutions are hacks. indeed. and I wish midcom would work on things for which there is a reasonable exit strategy to IPv6 in preference to things that just dig us deeper in the NAT hole. Keith p.s. while not directly related to midcom, some midcomers might still be interested in a draft I wrote recently: Recommendations for the Design and Implementation of NAT-Tolerant Applications ( draft-moore-nat-tolerance-recommendations-00 ) which looks at possible workarounds for the NAT problem from the point-of-view of an applications developer that has no control over the networks in which his apps will be deployed. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 6 12:17:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19516 for ; Wed, 6 Mar 2002 12:17:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26862 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 12:17:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26601; Wed, 6 Mar 2002 12:12:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26574 for ; Wed, 6 Mar 2002 12:12:26 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19184 for ; Wed, 6 Mar 2002 12:12:21 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g26HBtd10290 for ; Wed, 6 Mar 2002 09:11:55 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADA97648; Wed, 6 Mar 2002 09:09:41 -0800 (PST) Message-Id: <5.1.0.14.0.20020306120414.00a94d90@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 12:15:28 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Upcoming meeting Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We're scheduled to meet from 3:30pm to 5:30 on the afternoon of Thursday, 21 March. The two main things on the agenda will be pre-midcom and rechartering. As you know, there's a design team that's hammering through the pre-midcom work. Bringing it back to the working group at this point in its progress would sort of defeat the purpose of having a design team, but there are a few issues which merit discussion. We're close to completing the rechartering process, and we're clear that the first deliverable will be an evaluation of existing IETF protocols against the midcom requirements and framework. Mary Barnes (mbarnes@nortelnetworks.com) will be responsible for the document, and she'll be discussing the process of putting the document together. There will be NO discussion of protocols themselves. Please let me know if there's anything else that you feel requires discussion at this point in the process, with the caveat that there will be no presentations and no discussion of anything that hasn't been discussed on the mailing list first. If you ask for a slot on the agenda, give some thought about what you'd like to see produced from the discussion and why it's relevant to the working group in March, 2002. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 6 12:20:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19880 for ; Wed, 6 Mar 2002 12:20:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27509 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 12:20:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27034; Wed, 6 Mar 2002 12:17:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27006 for ; Wed, 6 Mar 2002 12:17:55 -0500 (EST) Received: from localhost ([61.72.132.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19576 for ; Wed, 6 Mar 2002 12:17:49 -0500 (EST) Message-Id: <200203061717.MAA19576@ietf.org> Reply-To: lhcv@orgio.net From: 고인돌스매니아 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 7 Mar 2002 02:18:00 +0900 Subject: [midcom] [광고]게임도하고 돈도벌고~일석이조 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org

(이메일 주소는 인터넷으로 통하여 알게되었습니다.
원치 않으메일이었으면....... 정말 죄송합니다.
아래에 수신거부를 누르시면 다음부터는 메일이 가지 않습니다.
죄송합니다.)
만약 메일이 1회이상왔다면 저의 실수로 그랬나봅니다. 용서해주세요

 

안녕하세요.

데이콤과 협찬하여 운영하는 고인돌스입니다.

이곳은 게임사이트로서.. 이곳에서 발생하는 모든 수익금을 100% 회원님께 되돌려 드리고 있습니다..

쉽게 설명드리자면.. 기존의 게임사이트에서는 아무리 잘해봤자 계급이나 포인트만 올라갔지만..

이곳은 자신의 게임능력만큼 무한 대로 실제 현금을 얻을 수 있는곳입니다..

그럼 이곳이 유료 사이트 이냐구여??  천만에 말씀..   100%무료로 이용하실수 있는곳입니다..
 

그럼 게임에 대해 간략하게 설명드리겠습니다.

캐릭터 들이 옷을 벗구 있네여 -,.-
이게임은 퀴즈를 맞추는 게임입니다..  어느정도의 상식만
있으면돈이 팍팍 쌓일 수 있습니다..^^;


이 게임은 빙글뱅글입니다.. 돌아가는 그림을 잘 찾아서                  
맞추면 되는 게임입니다.. 퍼즐 좋아하시는 분은 유리합니다.


오옷!! 위에 공룡들이 무섭져 ㅡㅡ;                                    
서바이벌 타자로서 위에서 내려오는 글자를 빨리 쳐야하는    .
게임입니다. 아님 공룡에게 먹힘니다.  타자 빠르신 분들에게 유리합니다..              

 

이게임의 제목은 어리버리 입니다.  
위의 세 개의 그림중 틀린그림을 찾는것입니다.  
서치아이 잘하시던분 꼭 도전해 보세요.돈좀 벌껍니다.아마^^;

 


말 그래도  O X 퀴즈입니다..                                         
어느정도의 상식이 있으시면.. 역시 돈좀 벌수 있답니다..     

 



이 게임의 제목은 준비땅입니다..
타자를 빨리쳐서 먼저 목표지점에 꼴인하는 사람이 모든돈을 다 딱먹는
아주 스릴넘치는 게임입니다... 타자 자신있는분께 강추!!!

 

    

이건 테트리스입니다..                                                         
이전과는 새로운 방식인데.. 아이템도 등장하네요..                
테트리스 고수님들 딴데가서 하시지 말구 여기서 하셔서         
꼭 돈벌어 가시기 바랍니다..  정말루여..@@                  

 

이건 뭐냐구여..? 보시다시피 자신의 캐릭터를 꾸미는 겁니다..
게임을 하면서 자신의 개성을 맘껏 뽐낼 수 있답니다..
그뿐만이 아니라 매주에 한명씩 킹카,퀸카를 뽑아서 엄청난 상금을 또 주고
있답니다...  캐릭터 꾸미기에 자신있는분들 꼭 도전해 보세요^^

 




위에것은 제가 이번주에 벌어간 돈입니다..약 14만원가량 되네요^^;
여러분도 조금만 노력하시면 충분히 가능하리라 봅니다..결코 어려운게 아닙니다.
사실 잘하는 사람이 별로 없어서 저처럼 조금만 열성적으로 하면
돈이 정말 팍팍!! 쌓일 수 있답니다...   

그뿐만 아니라 매주 게임왕을 선발해서 20명에게 엄청난 상금을 쏟아 붓고 있습니다..
이런이벤트는 아무때나 있는게 아니니 빨리 오셔서 참여 하세요...
참여 자체만으로도 돈이 쌓일 수 있다는걸 명심하시구여.


데이콤,다음,천리안등 국내 최고의 인터넷 기업이 제휴를 맺은 곳이니 신용또한 걱정 없이
즐기실수 있습니다...   모든면에서 국내 게임계의 왕좌를 차지할 곳입니다..  강추!!!

참고 : 게임 하셔야 합니다^_^ 가입하시구 게임클릭해서 설치하시구 게임 즐겁게하세요~~ 능력만큼 벌수 있으니깐요.

 

 무료회원 가입하기!!!

 

원치않는 메일 이였다면... 깊이 사과드립니다..
아래 수신거부를 클릭해 주시면.. 다시는 메일이 가지 않을 것입니다..
(수신거부를 안하셔도 다음부터는 메일이 가지 않아요^^*) 죄송합니다~~7
만약에 또 왔다면 그건 제가보낸게 아님을 유념하시기 바랍니다.

 [수신거부]제목은 수신거부라고 해주세요

O 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다
O e-mail주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다


_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 6 12:26:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20212 for ; Wed, 6 Mar 2002 12:26:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27971 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 12:26:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27360; Wed, 6 Mar 2002 12:19:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27273 for ; Wed, 6 Mar 2002 12:19:35 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19694 for ; Wed, 6 Mar 2002 12:19:30 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g26HItN06432; Wed, 6 Mar 2002 11:18:56 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 11:18:55 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011879B2@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jiri Kuthan'" , Christian Huitema , "Cedric Aoun", "Midcom IETF (E-mail)" Subject: RE: [midcom] Identifying Intra realm calls Date: Wed, 6 Mar 2002 11:18:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C532.FCF313F0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1C532.FCF313F0 Content-Type: text/plain; charset="iso-8859-1" Right. This end-to-end STUN may be useful in detecting direct connectivity in some cases (basically detecting that there's no NAT between them). I've not given enough thought on the error cases though. Thoughts from STUN authors? > -----Original Message----- > From: Jiri Kuthan [mailto:jkuthan@dynamicsoft.com] > Sent: Wednesday, March 06, 2002 10:50 AM > To: Christian Huitema; Aoun, Cedric [QPD:MA01:EXCH]; Midcom IETF > (E-mail) > Cc: Sen, Sanjoy [NGC:B692:EXCH] > Subject: RE: [midcom] Identifying Intra realm calls > > > Note there is also the option of having end-to-end STUN and embedding > STUN servers in hosts like we do with ping. That makes some cases more > simple. > > -Jiri > > At 05:23 PM 3/6/2002, Christian Huitema wrote: > >You are correct: many NATs will not "send back" the traffic. > The STUN statement is wrong: when two parties are behind the > same NAT, not only is the solution not very efficient; in > fact, it does not always work. We should only use a solution > like STUN when we know that the two stations are "far apart". > Even so, there are failure modes, e.g. in the cases of dual > NAT: an ISP allocate 10/8 addresses to its customers, who in > turn run a NAT. > > > >A partial solution is to use multicast discovery to find out > whether the other party is local: from the UDP port that uses > STUN, send a multicast packet to a conventional IPv4 > multicast address and port, documenting something like "I am > local and my STUN address is x.x.x.x:p"; the receiver of > these packet keeps a catalog; this is what is document in > version 04 of the shipworm/teredo draft. You may combine the > solution with a hint, e.g. the fact that the STUN mapped > addresses of the parties look alike. However, there will > still be failure modes, such as the 10/8 ISP. > > > >The only real solution to this problem is to use IPv6 and > global addresses. All other solutions are hacks. > > > >-- Christian Huitema > > > >-----Original Message----- > >From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] > >Sent: Wednesday, March 06, 2002 12:16 AM > >To: Midcom IETF (E-mail) > >Cc: Sanjoy Sen > >Subject: [midcom] Identifying Intra realm calls > > > >Hello, > >One of the open issues that had been briefly discussed in > the mailing list in the context of the pre-Midcom solutions - > STUN, PHANTOM and MINT - is how to effectively route > intra-realm calls (e.g. calls behind the same NAT), i.e., how > does the client or a signaling server determine that the > called party is in the same network realm and the media is > directly routable without going through the NAT or a relay > NAT (i.e. a Media Proxy). For example, the last para of Sec > 9.3 in STUN draft states: It is possible that both > participants in the multimedia session are behind the same > NAT. In that case, both will repeat this procedure > > above, and both will obtain public address bindings. When > one sends > > media to the other, the media is routed to the nat, and > then turns > > right back around to come back into the enterprise, where it is > > translated to the private address of the recipient. This is not > > particularly efficient, but it does work. > >Note that, the above solution is not applicable to NATs all > vendors. Given that a significant percentage of Enterprise > calls are intra-realm, the issue, if resolved, will lead to > considerable saving of egress bandwidth at the NAT and will > lead to general improvement in service quality. > >Note that this is also an issue within the MIDCOM framework. > >An ID was submitted to discuss this issue > http://www.ietf.org/internet-drafts/draft-aoun-midcom-intrarea lmcalls-00.txt >The intent of this ID is to initiate some discussions (perhaps, offline) towards a solution for this issue. The intent is in no way to disrupt the progress of the WG's chartered work items, so, if you're interested to work on this problem, please send comments offline and we can move the discussions to a private mailing list (midcom-interest@eng.registro.br). >Thanks >Cedric >Cedric Aoun >Nortel Networks >France >mailto:cedric.aoun@nortelnetworks.com > > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1C532.FCF313F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Identifying Intra realm calls

Right. This end-to-end STUN may be useful in = detecting direct connectivity in some cases (basically detecting that = there's no NAT between them). I've not given enough thought on the = error cases though. Thoughts from STUN authors?

> -----Original Message-----
> From: Jiri Kuthan [mailto:jkuthan@dynamicsoft.com]
> Sent: Wednesday, March 06, 2002 10:50 AM
> To: Christian Huitema; Aoun, Cedric = [QPD:MA01:EXCH]; Midcom IETF
> (E-mail)
> Cc: Sen, Sanjoy [NGC:B692:EXCH]
> Subject: RE: [midcom] Identifying Intra realm = calls
>
>
> Note there is also the option of having = end-to-end STUN and embedding
> STUN servers in hosts like we do with ping. = That makes some cases more
> simple.
>
> -Jiri
>
> At 05:23 PM 3/6/2002, Christian Huitema = wrote:
> >You are correct: many NATs will not = "send back" the traffic.
> The STUN statement is wrong: when two parties = are behind the
> same NAT, not only is the solution not very = efficient; in
> fact, it does not always work. We should only = use a solution
> like STUN when we know that the two stations = are "far apart".
> Even so, there are failure modes, e.g. in the = cases of dual
> NAT: an ISP allocate 10/8 addresses to its = customers, who in
> turn run a NAT.
> >
> >A partial solution is to use multicast = discovery to find out
> whether the other party is local: from the UDP = port that uses
> STUN, send a multicast packet to a conventional = IPv4
> multicast address and port, documenting = something like "I am
> local and my STUN address is x.x.x.x:p"; = the receiver of
> these packet keeps a catalog; this is what is = document in
> version 04 of the shipworm/teredo draft. You = may combine the
> solution with a hint, e.g. the fact that the = STUN mapped
> addresses of the parties look alike. However, = there will
> still be failure modes, such as the 10/8 = ISP.
> >
> >The only real solution to this problem is = to use IPv6 and
> global addresses. All other solutions are = hacks.
> >
> >-- Christian Huitema
> >
> >-----Original Message-----
> >From: Cedric Aoun [mailto:cedric.aoun@nortel= networks.com]
> >Sent: Wednesday, March 06, 2002 12:16 = AM
> >To: Midcom IETF (E-mail)
> >Cc: Sanjoy Sen
> >Subject: [midcom] Identifying Intra realm = calls
> >
> >Hello,
> >One of the open issues that had been = briefly discussed in
> the mailing list in the context of the = pre-Midcom solutions -
> STUN, PHANTOM and MINT - is how to effectively = route
> intra-realm calls (e.g. calls behind the same = NAT), i.e., how
> does the client or a signaling server determine = that the
> called party is in the same network realm and = the media is
> directly routable without going through the NAT = or a relay
> NAT (i.e. a Media Proxy). For example, the last = para of Sec
> 9.3 in STUN draft states: It is possible that = both
> participants in the multimedia session are = behind the same
> NAT. In that case, both will repeat this = procedure
> >   above, and both will obtain = public address bindings. When
> one sends
> >   media to the other, the media = is routed to the nat, and
> then turns
> >   right back around to come back = into the enterprise, where it is
> >   translated to the private = address of the recipient. This is not
> >   particularly efficient, but it = does work.
> >Note that, the above solution is not = applicable to NATs all
> vendors. Given that a significant percentage of = Enterprise
> calls are intra-realm, the issue, if resolved, = will lead to
> considerable saving of egress bandwidth at the = NAT and will
> lead to general improvement in service = quality.
> >Note that this is also an issue within the = MIDCOM framework.
> >An ID was submitted to discuss this issue =
> http://www.ietf.org/internet-drafts/draft-aoun-midcom-= intrarea
lmcalls-00.txt
>The intent of this ID is to initiate some = discussions (perhaps, offline) towards a solution for this issue. The = intent is in no way to disrupt the progress of the WG's chartered work = items, so, if you're interested to work on this problem, please send = comments offline and we can move the discussions to a private mailing = list (midcom-interest@eng.registro.br).

>Thanks
>Cedric
>Cedric Aoun
>Nortel Networks
>France
>mailto:cedric.aoun@nortel= networks.com
>
> 
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>https://www1.ietf.org/mailman/listinfo/midcom =

------_=_NextPart_001_01C1C532.FCF313F0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 6 20:11:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19169 for ; Wed, 6 Mar 2002 20:11:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA02130 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 20:11:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01978; Wed, 6 Mar 2002 20:08:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01943 for ; Wed, 6 Mar 2002 20:08:47 -0500 (EST) Received: from ogbon001 (ipc379db96.dial.wxs.nl [195.121.219.150]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19079 for ; Wed, 6 Mar 2002 20:08:42 -0500 (EST) Message-Id: <200203070108.UAA19079@ietf.org> From: "Edward Mobutu" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 7 Mar 2002 02:11:47 Subject: [midcom] URGENT ASSISTANCE. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org "SOLICITING FOR AN ASSISTANCE" I am the son of the late President of the Federal Republic of Zaire, President Mobutu Sese Seko,now Republic of Congo, under the leadership of the son of Mr. Laurent Kabila}. I presume you are aware there is a financial dispute between my family {THE MOBUTU}and the present civilian Government. This is based on what they believe as bad and corrupt government on my fathers' part. May his soul rest in peace. Presently, we cannot do business here in Togo where we are seeking for asylum due to our refugee status, and many countries of the world because of the new friendly relationship between the present government and the western world. As you might have heard, a lot of my fathers' bank account in Switzerland and North America have since been frozen. Following the above mentioned reasons, I am soliciting for your humble and confidential assistance to take custody of Twenty Five Million, Five Hundred Thousand United States Dollars {US$25,500,000.00},also to front for me in the areas of business you desire profitable. This sum of US$25.5M, has secretly been deposited into a confidential Security Company where it can easily be withdrawn or paid to a recommended beneficiary. The funds will be released to you by the Security Company based on my recommendations. On this note, you will be presented as my partner who will be fronting for me and my family in any subsequent ventures. If this proposal satisfies you, do respond as soon as possible and contact my financial consultant Mr Frank Williams who is presently in Holland on +31 613178411 for further clarification. Thank you and God bless. Yours Faithfully, Mr.Edward Mobutu. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 7 02:08:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12088 for ; Thu, 7 Mar 2002 02:08:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA00795 for midcom-archive@odin.ietf.org; Thu, 7 Mar 2002 02:08:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00557; Thu, 7 Mar 2002 02:02:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00528 for ; Thu, 7 Mar 2002 02:02:07 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06576 for ; Thu, 7 Mar 2002 02:02:03 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2772G6Y027987; Thu, 7 Mar 2002 02:02:17 -0500 (EST) Message-ID: <3C87103F.361AE4AB@dynamicsoft.com> Date: Thu, 07 Mar 2002 02:01:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sanjoy Sen CC: "'Jiri Kuthan'" , Christian Huitema , Cedric Aoun , "Midcom IETF (E-mail)" Subject: Re: [midcom] Identifying Intra realm calls References: <933FADF5E673D411B8A30002A5608A0E011879B2@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > > Right. This end-to-end STUN may be useful in detecting direct > connectivity in some cases (basically detecting that there's no NAT > between them). I've not given enough thought on the error cases though. > Thoughts from STUN authors? I think its workable. stun-01 did make it in before the I-D deadline, so you should see it shortly. There is additional text in there that mentions the possibility of e2e usage between endpoints directly. However, it does not go into any details on the application of this to discover whether two parties are behind the same nat. -Jonathan R. > > > -----Original Message----- > > From: Jiri Kuthan [ mailto:jkuthan@dynamicsoft.com > ] > > Sent: Wednesday, March 06, 2002 10:50 AM > > To: Christian Huitema; Aoun, Cedric [QPD:MA01:EXCH]; Midcom IETF > > (E-mail) > > Cc: Sen, Sanjoy [NGC:B692:EXCH] > > Subject: RE: [midcom] Identifying Intra realm calls > > > > > > Note there is also the option of having end-to-end STUN and embedding > > STUN servers in hosts like we do with ping. That makes some cases more > > > simple. > > > > -Jiri > > > > At 05:23 PM 3/6/2002, Christian Huitema wrote: > > >You are correct: many NATs will not "send back" the traffic. > > The STUN statement is wrong: when two parties are behind the > > same NAT, not only is the solution not very efficient; in > > fact, it does not always work. We should only use a solution > > like STUN when we know that the two stations are "far apart". > > Even so, there are failure modes, e.g. in the cases of dual > > NAT: an ISP allocate 10/8 addresses to its customers, who in > > turn run a NAT. > > > > > >A partial solution is to use multicast discovery to find out > > whether the other party is local: from the UDP port that uses > > STUN, send a multicast packet to a conventional IPv4 > > multicast address and port, documenting something like "I am > > local and my STUN address is x.x.x.x:p"; the receiver of > > these packet keeps a catalog; this is what is document in > > version 04 of the shipworm/teredo draft. You may combine the > > solution with a hint, e.g. the fact that the STUN mapped > > addresses of the parties look alike. However, there will > > still be failure modes, such as the 10/8 ISP. > > > > > >The only real solution to this problem is to use IPv6 and > > global addresses. All other solutions are hacks. > > > > > >-- Christian Huitema > > > > > >-----Original Message----- > > >From: Cedric Aoun [ mailto:cedric.aoun@nortelnetworks.com > ] > > >Sent: Wednesday, March 06, 2002 12:16 AM > > >To: Midcom IETF (E-mail) > > >Cc: Sanjoy Sen > > >Subject: [midcom] Identifying Intra realm calls > > > > > >Hello, > > >One of the open issues that had been briefly discussed in > > the mailing list in the context of the pre-Midcom solutions - > > STUN, PHANTOM and MINT - is how to effectively route > > intra-realm calls (e.g. calls behind the same NAT), i.e., how > > does the client or a signaling server determine that the > > called party is in the same network realm and the media is > > directly routable without going through the NAT or a relay > > NAT (i.e. a Media Proxy). For example, the last para of Sec > > 9.3 in STUN draft states: It is possible that both > > participants in the multimedia session are behind the same > > NAT. In that case, both will repeat this procedure > > > above, and both will obtain public address bindings. When > > one sends > > > media to the other, the media is routed to the nat, and > > then turns > > > right back around to come back into the enterprise, where it is > > > translated to the private address of the recipient. This is not > > > particularly efficient, but it does work. > > >Note that, the above solution is not applicable to NATs all > > vendors. Given that a significant percentage of Enterprise > > calls are intra-realm, the issue, if resolved, will lead to > > considerable saving of egress bandwidth at the NAT and will > > lead to general improvement in service quality. > > >Note that this is also an issue within the MIDCOM framework. > > >An ID was submitted to discuss this issue > > http://www.ietf.org/internet-drafts/draft-aoun-midcom-intrarea > > lmcalls-00.txt > >The intent of this ID is to initiate some discussions (perhaps, > offline) towards a solution for this issue. The intent is in no way to > disrupt the progress of the WG's chartered work items, so, if you're > interested to work on this problem, please send comments offline and we > can move the discussions to a private mailing list > (midcom-interest@eng.registro.br). > > >Thanks > >Cedric > >Cedric Aoun > >Nortel Networks > >France > > mailto:cedric.aoun@nortelnetworks.com > > > > > > > > >_______________________________________________ > >midcom mailing list > >midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 7 08:39:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23455 for ; Thu, 7 Mar 2002 08:39:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23338 for midcom-archive@odin.ietf.org; Thu, 7 Mar 2002 08:39:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23101; Thu, 7 Mar 2002 08:36:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23072 for ; Thu, 7 Mar 2002 08:36:32 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23321 for ; Thu, 7 Mar 2002 08:36:29 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g27DZv304067; Thu, 7 Mar 2002 05:35:57 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADB28360; Thu, 7 Mar 2002 05:33:47 -0800 (PST) Message-Id: <5.1.0.14.0.20020307083733.00a9bec0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Mar 2002 08:39:48 -0500 To: Jonathan Rosenberg , Sanjoy Sen From: Melinda Shore Subject: Re: [midcom] Identifying Intra realm calls Cc: "'Jiri Kuthan'" , Christian Huitema , Cedric Aoun , "Midcom IETF (E-mail)" In-Reply-To: <3C87103F.361AE4AB@dynamicsoft.com> References: <933FADF5E673D411B8A30002A5608A0E011879B2@zrc2c012.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:01 AM 3/7/02 -0500, Jonathan Rosenberg wrote: >> Right. This end-to-end STUN may be useful in detecting direct >> connectivity in some cases (basically detecting that there's no NAT >> between them). I've not given enough thought on the error cases though. >> Thoughts from STUN authors? > >I think its workable. stun-01 did make it in before the I-D deadline, so >you should see it shortly. There is additional text in there that >mentions the possibility of e2e usage between endpoints directly. >However, it does not go into any details on the application of this to >discover whether two parties are behind the same nat. Not to be tiresome about this, but it's basically the network- friendlier proposal with the far endpoint writing the address it sees rather than having the NAT write the address it's going to use. It solves a bunch of problems, including some identified by the IAB in the UNSAF document. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 7 12:28:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09021 for ; Thu, 7 Mar 2002 12:28:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14696 for midcom-archive@odin.ietf.org; Thu, 7 Mar 2002 12:28:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14613; Thu, 7 Mar 2002 12:25:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14582 for ; Thu, 7 Mar 2002 12:25:00 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08762 for ; Thu, 7 Mar 2002 12:24:54 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g27HPP6Y028390 for ; Thu, 7 Mar 2002 12:25:25 -0500 (EST) Message-ID: <3C87A24B.332EA7A0@dynamicsoft.com> Date: Thu, 07 Mar 2002 12:24:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Open issue in STUN Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Folks, As I mentioned previously, I managed to get a rev of stun in before the I-D deadline. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-01.txt The changes since -00 are: * alignment of parameters on natural boundaries (previously, 32 bit addresses were not 32 bit aligned). Note that this will result in incompatibility between implementations based on -00 and -01. * addressing UNSAF considerations * CMS and TCP SYN attack style prevention stuff * added some missing attribute values * clarified semantic of CHANGED_ADDRESS * split reference section, IANA considerations, general prep for IESG consideration One issue worth broader list discussion, was the design teams conclusions on security. stun-00 had no security mechanisms. However, we found a security vulnerability that needed addressing. An attacker could inject a fake stun response, containing a MAPPED-ADDRESS that pointed to itself. THis would allow the attacker to fool the victim into giving out the wrong address. The attacker could use this to steal phone calls, for example, by having the media and/or signaling get routed to them instead of the caller. To address this, we decided that the appropriate mechanism was to provide authentication and itegrity of the response. Since the response will be coming from a server, typically run by a service provider on the public Internet, we chose to provide for a CMS-based public key signature mechanism over the response. There is no client authentication. However, to avoid DDoS attacks where an attacker can force a public key operation with an unauthenticated request, we added support for a cookie mechanism, similar to that used to prevent TCP SYN attacks. We debated, but chose not to additionally provide a shared-secret based integrity/authentication scheme, since we felt it was not approrpriate or scalable for network servers to autehnticate themselves to end users with a shared secret. We also wanted to reduce the set of options. Sadly, the CMS aspect of the protocol will be the most complex to implement, far harder than the protocol itself. However, no one ever said security was easy. The design team felt it was important to get broader group input on this design choice. I think most of the remaining changes in stun do not require any discussion, but comments are welcome of course. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 8 01:30:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15406 for ; Fri, 8 Mar 2002 01:30:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA04460 for midcom-archive@odin.ietf.org; Fri, 8 Mar 2002 01:30:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04074; Fri, 8 Mar 2002 01:27:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04049 for ; Fri, 8 Mar 2002 01:27:32 -0500 (EST) Received: from localhost ([211.222.243.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15364 for ; Fri, 8 Mar 2002 01:27:29 -0500 (EST) Message-Id: <200203080627.BAA15364@ietf.org> Reply-To: thisweb78@hotmail.com From: 진성데이터시스템 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 8 Mar 2002 15:27:29 +0900 Subject: [midcom] 삭제된 하드 데이터 완전 복구 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org


제목 : 삭제된데이타 완전 복구 (인천)

보낸사람 : 진성데이타시스템<master@thisweb.co.kr>

-.안녕하세여, 하드데이터 복구율에서는 업계의 선두를 지키고 있는 진성데이타 시스템
입니다

-.저희 회사는 컴퓨터 관련 최적화된 운영방법을 상담 하고 있습니다

-.컴퓨터 피시 내장 하드 자료의 포멧, 파괴, 침수, 삭제, 바이러스 등으로

  손상데 데이타를 정상적으로 복구가 가능 하며

-.복구 가능한 OS : WIN98, NT4.0, NT5.0, UNIX, SUN, LINUX, NETWARE, 기타

-.통상 80%이상의 복구기술을 보유하고 있습니다.

-.중요한 자료의 손실시 48시간내에 완벽 복구 하여 드립니다

-.자료의 망실시 추후 작업을 하시게 되면 복구가 지연 및
  정보가 손실이 될 수 있음으로 어떤 조치를 하지 마시고

-.저희 진성데이타시스템에게 즉시 연락을 주시시 바랍니다

-.주저 하지 마시고 상담을 바라겠습니다 

-.문의 (책임 담당자 박 남 신)

  전화 : 032-426-6864 , 011-256-0476,

  메일 : master@thiswewb.co.kr 

-.책임과 신용을 가지고 만사에 임하고자 합니다 .끝. 

불편을 끼쳤다면 다시한번 정중히 사과 드립니다.수신을 원치 않으시면 반송메일을 부탁드리겠습니다.
귀하의 메일주소는 웹서핑시 우연히 수집 된 것이며 메일 이외에  어떠한 정보는 없습니다.
              >수신거부<

 

copyright www.thisweb.co.kr

 

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 8 09:55:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08190 for ; Fri, 8 Mar 2002 09:55:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06953 for midcom-archive@odin.ietf.org; Fri, 8 Mar 2002 09:55:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06567; Fri, 8 Mar 2002 09:46:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06537 for ; Fri, 8 Mar 2002 09:46:09 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07772 for ; Fri, 8 Mar 2002 09:46:07 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g28Ejdd01075 for ; Fri, 8 Mar 2002 06:45:39 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADB62156; Fri, 8 Mar 2002 06:43:26 -0800 (PST) Message-Id: <5.1.0.14.0.20020308094440.00abc600@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 08 Mar 2002 09:49:26 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Agenda Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I've appended the agenda for the upcoming meeting. Note that the revision of the STUN document is now available on the IETF server. When the secretary starts accepting drafts again we'll resubmit it as a working group draft. Please let me know of any omissions/changes/what-have-you. Melinda Middlebox Communication WG (midcom) Thursday, March 21 at 1530-1730 =============================== CHAIR: Melinda Shore AGENDA: Administrivia Agenda-bashing Blue sheets Note taker Status update Rechartering & new deliverables Pre-midcom STUN "Other thing" Documents: http://search.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-01.txt _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 8 10:00:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08483 for ; Fri, 8 Mar 2002 10:00:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07509 for midcom-archive@odin.ietf.org; Fri, 8 Mar 2002 10:00:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07167; Fri, 8 Mar 2002 09:59:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07137 for ; Fri, 8 Mar 2002 09:59:01 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08346 for ; Fri, 8 Mar 2002 09:58:59 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id JAA19530; Fri, 8 Mar 2002 09:58:17 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B76.00523BA5 ; Fri, 8 Mar 2002 09:58:12 -0500 X-Lotus-FromDomain: MITEL To: Melinda Shore cc: midcom@ietf.org Message-ID: <85256B76.005234A1.00@kanmta01.software.mitel.com> Date: Fri, 8 Mar 2002 09:57:33 -0500 Subject: Re: [midcom] Agenda Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org From: Tom Gray@MITEL on 03/08/2002 09:57 AM What is 'other thing'? Melinda Shore on 03/08/2002 09:49:26 AM To: midcom@ietf.org cc: (bcc: Tom Gray/Kan/Mitel) Subject: [midcom] Agenda I've appended the agenda for the upcoming meeting. Note that the revision of the STUN document is now available on the IETF server. When the secretary starts accepting drafts again we'll resubmit it as a working group draft. Please let me know of any omissions/changes/what-have-you. Melinda Middlebox Communication WG (midcom) Thursday, March 21 at 1530-1730 =============================== CHAIR: Melinda Shore AGENDA: Administrivia Agenda-bashing Blue sheets Note taker Status update Rechartering & new deliverables Pre-midcom STUN "Other thing" Documents: http://search.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-01.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 From daemon@optimus.ietf.org Fri Mar 8 12:23:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18587 for ; Fri, 8 Mar 2002 12:23:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18610 for midcom-archive@odin.ietf.org; Fri, 8 Mar 2002 12:23:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17804; Fri, 8 Mar 2002 12:04:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17773 for ; Fri, 8 Mar 2002 12:04:40 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17124 for ; Fri, 8 Mar 2002 12:04:37 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g28H46315712; Fri, 8 Mar 2002 09:04:06 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADB65238; Fri, 8 Mar 2002 09:01:57 -0800 (PST) Message-Id: <5.1.0.14.0.20020308120604.00ac8d90@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 08 Mar 2002 12:07:54 -0500 To: From: Melinda Shore Subject: Re: [midcom] Agenda Cc: midcom@ietf.org In-Reply-To: <85256B76.005234A1.00@kanmta01.software.mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 09:57 AM 3/8/02 -0500, Tom_Gray@Mitel.COM wrote: >What is 'other thing'? We have two pre-midcom deliverables: 1) STUN, and 2) the other thing. We don't have a name for it yet. Suggestions are probably appreciated but we *definitely* won't be spending time on finding a name for it at the meeting. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 8 12:49:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20246 for ; Fri, 8 Mar 2002 12:49:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20426 for midcom-archive@odin.ietf.org; Fri, 8 Mar 2002 12:49:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20240; Fri, 8 Mar 2002 12:44:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20213 for ; Fri, 8 Mar 2002 12:44:40 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19914 for ; Fri, 8 Mar 2002 12:44:38 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id MAA12593; Fri, 8 Mar 2002 12:43:47 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B76.00616275 ; Fri, 8 Mar 2002 12:43:41 -0500 X-Lotus-FromDomain: MITEL To: Melinda Shore cc: midcom@ietf.org Message-ID: <85256B76.00613362.00@kanmta01.software.mitel.com> Date: Fri, 8 Mar 2002 12:37:43 -0500 Subject: Re: [midcom] Agenda Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org From: Tom Gray@MITEL on 03/08/2002 12:37 PM Is there anything we can read on 'other thing.' Melinda Shore on 03/08/2002 12:07:54 PM To: Tom Gray/Kan/Mitel@Mitel cc: midcom@ietf.org Subject: Re: [midcom] Agenda At 09:57 AM 3/8/02 -0500, Tom_Gray@Mitel.COM wrote: >What is 'other thing'? We have two pre-midcom deliverables: 1) STUN, and 2) the other thing. We don't have a name for it yet. Suggestions are probably appreciated but we *definitely* won't be spending time on finding a name for it at the meeting. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 8 14:30:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27976 for ; Fri, 8 Mar 2002 14:30:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28631 for midcom-archive@odin.ietf.org; Fri, 8 Mar 2002 14:30:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26414; Fri, 8 Mar 2002 14:10:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26375 for ; Fri, 8 Mar 2002 14:10:17 -0500 (EST) Received: from n7.groups.yahoo.com (n7.groups.yahoo.com [216.115.96.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26102 for ; Fri, 8 Mar 2002 14:10:12 -0500 (EST) X-eGroups-Return: notify-return-midcom=ietf.org@yahoogroups.com Received: from [216.115.96.140] by n7.groups.yahoo.com with NNFMP; 08 Mar 2002 19:09:43 -0000 Date: 8 Mar 2002 19:09:41 -0000 Message-ID: <1015614581.1749.71841.w53@yahoogroups.com> From: mplsissues moderator Reply-To: confirm-invite-vcC9W3F8KWbrLrt5LKTGMR0NVLs-midcom=ietf.org@yahoogroups.com To: midcom@ietf.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Invitation to join the mplsissues group Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hello, You've been invited to join the mplsissues group, an email group hosted by Yahoo! Groups, a free, easy-to-use email group service. JOIN NOW, IT'S EASY: 1) REPLY to this email by clicking "Reply" and then "Send" in your email program -OR- 2) Go to the Yahoo! Groups site at http://groups.yahoo.com/invite/mplsissues?email=midcom%40ietf%2Eorg&iref=vcC9W3F8KWbrLrt5LKTGMR0NVLs By joining mplsissues, you will be able to exchange messages with other group members. Yahoo! Groups also makes it easy to store photos and files, coordinate events and more. Here's an introductory message from the group moderator: ------------------------------------------------------------------------ This is a group whereby you can share information and assist others with concern to MPLS/GMPLS technology issues, developments, implementations, news etc... ------------------------------------------------------------------------ If you do not wish to join the mplsissues group, please ignore this invitation. SPECIAL NOTE FROM Yahoo! Groups: Because Yahoo! Groups values your privacy, it is a violation of our service rules for moderators to abuse this invitation feature. If you feel this has happened, please notify us at abuse@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 8 14:30:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28028 for ; Fri, 8 Mar 2002 14:30:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28703 for midcom-archive@odin.ietf.org; Fri, 8 Mar 2002 14:30:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27628; Fri, 8 Mar 2002 14:21:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27601 for ; Fri, 8 Mar 2002 14:21:47 -0500 (EST) Received: from n6.groups.yahoo.com (n6.groups.yahoo.com [216.115.96.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27267 for ; Fri, 8 Mar 2002 14:21:44 -0500 (EST) X-eGroups-Return: notify-return-midcom=ietf.org@yahoogroups.com Received: from [216.115.96.38] by n6.groups.yahoo.com with NNFMP; 08 Mar 2002 19:21:16 -0000 Date: 8 Mar 2002 19:21:12 -0000 Message-ID: <1015615272.112.42355.w17@yahoogroups.com> From: mplsissues Moderator To: midcom@ietf.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Welcome to mplsissues Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hello, Welcome to the mplsissues group at Yahoo! Groups, a free, easy-to-use email group service. Please take a moment to review this message. To learn more about the mplsissues group, please visit http://groups.yahoo.com/group/mplsissues To start sending messages to members of this group, simply send email to mplsissues@yahoogroups.com If you do not wish to belong to mplsissues, you may unsubscribe by sending an email to mplsissues-unsubscribe@yahoogroups.com To see and modify all of your groups, go to http://groups.yahoo.com/mygroups Regards, Moderator, mplsissues Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 8 14:33:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28297 for ; Fri, 8 Mar 2002 14:33:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29569 for midcom-archive@odin.ietf.org; Fri, 8 Mar 2002 14:33:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29218; Fri, 8 Mar 2002 14:31:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29175 for ; Fri, 8 Mar 2002 14:31:50 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28132 for ; Fri, 8 Mar 2002 14:31:47 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g28JVId29740; Fri, 8 Mar 2002 11:31:18 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADB71142; Fri, 8 Mar 2002 11:29:05 -0800 (PST) Message-Id: <5.1.0.14.0.20020308143326.00a93810@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 08 Mar 2002 14:35:07 -0500 To: mplsissues Moderator , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Welcome to mplsissues In-Reply-To: <1015615272.112.42355.w17@yahoogroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 07:21 PM 3/8/02 +0000, mplsissues Moderator wrote: >Welcome to the mplsissues group at Yahoo! Groups, a >free, easy-to-use email group service. Please >take a moment to review this message. Whoever clicked on that hyperlink and subscribed the midcom mailing list to the Yahoo mpls mailing list owes the entire midcom working group a drink in Minneapolis. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Mar 9 09:58:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10234 for ; Sat, 9 Mar 2002 09:58:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27573 for midcom-archive@odin.ietf.org; Sat, 9 Mar 2002 09:58:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27351; Sat, 9 Mar 2002 09:49:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27325 for ; Sat, 9 Mar 2002 09:49:35 -0500 (EST) Received: from hanmeil.net ([61.43.176.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10151 for ; Sat, 9 Mar 2002 09:49:21 -0500 (EST) Message-Id: <200203091449.JAA10151@ietf.org> Reply-To: emaket@hanmeil.net From: 마케터 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 9 Mar 2002 22:44:37 +0900 Subject: [midcom] [광고] e 마케팅 이란??? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org O본메일은정보통신망이용촉진및정보보호등에관한법률제50조에의거한[광고]메일입니다

O 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다
O e-mail주소는 인터넷상 게시판에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다
O 본 메일은 단 일회만 전달 됩니다.

도대체 e-mail 광고가 무엇이길래?

e-mail을 통한 마케팅의 효과는 미국의 마케팅보고서 그리고 우리나라의 신문,잡지상에서 많이 소개되어 있습니다.

모든 마케팅이 그러하듯이 이메일 마케팅 역시 복합적인 마케팅 기법이 적용되면 매우 큰 효과를 볼 수 있습니다. e-mail을 이용한 마케팅에는 단순광고, 홈페이지 방문유도 , 설문조사, 판매광고등 광고주의 요구에 의한 다양한 형태와 목적이 있을 수 있습니다.  

인터넷배너광고 및 우편물광고와 비교하였을 때 최소 10배에서 최대 30배 이상의 높은 광고효과 입증

- 회신율 : 10~15%(우편물1%) - 리서치응답율 : 3일내 50%이상(대상인원과 무관)  

위와 같은 효과를 거둘 수 있었던 첫 번째 이유는 이메일이 가지는 기본적 속성에 기인합니다.

즉 소비자를 찾아가는 방문형 다이렉트 마케팅수단으로서, 사용자는 복잡한 웹서핑을 하지 않고필요한 정보를 받아볼 수 있다는 편의성에 기인합니다.

둘째 특정 홍보대상에 적합한, 타켓 선정이 가능한 데이터 베이스 마케팅에 있습니다.
데이터를 저장하고 데이터 마이닝기법을 통해 적합한 타겟집단을 선정해 광고메일을 발송하기 때문입니다

이제는 기업이든 개인이든 할 것 없이 인터넷에서 자신의 PR은 필수요건이 되어가고 있습니다.
일반화된 인터넷 환경에서 자신을 알릴 수 있는 수단으로는 기본적인 홈페이지 구축과 더 더욱 중요한 웹 프로모션이 있습니다.

아무리 잘 만들어진 홈페이지나 상품, 서비스라 할지라도 고객이 찾아주지 않으면 무용지물이기 되기 때문입니다.
그러므로 고객과의 인터페이스를 고려한 홈페이지 제작과 검색엔진등록을 비롯한 여러 가지 웹 프로모션은 인터넷 비즈니스에 있어서는 핵심 기술이자 필수적 요건이라 할 수 있습니다.  

인터넷사용인구의 폭발적인 증가, 인터넷사용자의 70-80%이상이 이메일을 사용하고 있는 온라인 시장에서 이메일이 가지는 신속성, 저비용, 정확성을 최대한 활용하여 고객의 로열티를 증대시키며, 고객과의 유대관계를 강화시키기 위한 명백한 목적을 가지고 이메일 마케팅을 수행한다면 날로 치열해지는 시장에서 마케터와 고객은 상호만족을 통하여 언제나 동반자적 위치에 있게 될 것입니다.

이메일 마케팅에 대한 필요성은 모두 공감하시리라 생각됩니다.
문제는 이러한 마케팅을 실현하실 수 있는 효과적인 툴과 DB(이메일 주소등), 그리고 마케팅 노하우입니다.
하지만 걱정하지 않으셔도 됩니다.
웹에 대한 지식이 전혀 없으셔도 신청하시는 즉시 모든 과정을 신속하게 처리해드리며 모든 프로그램의 설치와 어드바이스를 직접 찾아 뵙고 해드립니다.

자세한 마케팅 문의를 원하시면 이메일은 발송 전용메일이니 회신을 누르지 마시고 다음 이메일 주소를 클릭하시여 연락 가능한 전화번호를 남겨 주시기 바랍니다.   

ema2002@dreamwiz.com

 

<<정보통신망이용촉진 및 정보보호에 관한 법률에 의거 표시>>

허락없이 메일을 보내서 죄송합니다. 이 메일은 웹서핑 도중 공개된 메일을 보고 보내드리는 광고입니다.
결코, 메일주소이외 님에 대한 어떤 정보도 가지고 있지 않습니다. 메일 수신을 원치 않으시면 하단에 표시된 수신거부자에 등록해주시면 다시는 메일 보내지 않겠습니다. 원치 않으신 분들은 메일 수신거부를 해주십시요. 만약 불필요한 정보였다면 사과 드립니다.
- 메일수신거부 - 

 

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Mar 10 09:23:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08670 for ; Sun, 10 Mar 2002 09:23:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26030 for midcom-archive@odin.ietf.org; Sun, 10 Mar 2002 09:23:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25929; Sun, 10 Mar 2002 09:17:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25902 for ; Sun, 10 Mar 2002 09:17:12 -0500 (EST) Received: from finmania ([210.108.175.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08571 for ; Sun, 10 Mar 2002 09:17:07 -0500 (EST) From: notexistingaddress@ohmylotto.com Received: from mail pickup service by finmania with Microsoft SMTPSVC; Sun, 10 Mar 2002 23:14:24 +0900 To: Date: Sun, 10 Mar 2002 19:23:51 +0900 Message-ID: <3dd6401c1c81d$ac9a6190$64af6cd2@finmania> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3DD65_01C1C869.1C820990" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcHIHayYdUHVcXIuQZSlwzZjRn+SpA== Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 10 Mar 2002 14:14:24.0319 (UTC) FILETIME=[E165CCF0:01C1C83D] Subject: [midcom] =?ks_c_5601-1987?B?W7GksO1dIMPgx8/H1bTPtNkhIMi4v/iwocDUIDUwMDDG9w==?= =?ks_c_5601-1987?B?wM7Grr+hILTnw7e1x7zMvcC0z7TZLg==?= Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_3DD65_01C1C869.1C820990 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 IDxodHRwOi8vZGV2Lmdhcm9zdS5jby5rci9jYXRlZ29yeS9sb3R0by9hY3Rpb25fbG90dG8uYXNw P21fY29kZT00MjIxNT4NCg0KIAkNCgkNCiAJDQogCQ0KIAkgCSANCg0Kvsiz58fPvLy/5CENCr3M sde3r7/uILq9udm297+hILi2wL3AzCC8s7e5tMIgsOjA/SENCrv9yLC80yCx4rvdwLsgw6O+xiDH 4Lq5wLsgteW4rrDtwNogx9W0z7TZLiANCsHxsMW/7iC7/ciwISC/wLi2wMy3zrbHDQo8aHR0cDov L2Rldi5nYXJvc3UuY28ua3IvY2F0ZWdvcnkvbG90dG8vYWN0aW9uX2xvdHRvLmFzcD9tX2NvZGU9 NDIyMTU+IL/NDQrH1LKyIMfPvLy/5CEhDQoJDQoJDQrB9rHdIL/AvcO46SwguLbAz7iuwfYgNTAw MMb3wM7Grg0KPGh0dHA6Ly9kZXYuZ2Fyb3N1LmNvLmtyL2NhdGVnb3J5L2xvdHRvL2FjdGlvbl9s b3R0by5hc3A/bV9jb2RlPTQyMjE1PiC4pg0KwPu4s8fYIA0KteW4s7TPtNkuILi2wM+4rsH2ILq5 scfAuLfOIMf2sd2058O3wMcNCrHiyLi4piDA4sC4vLy/5CEhISANCii03CwgwMwguN7Az8C7IMXr x9ggsKHA1MfPvcUgutC/oSDH0cfUKSAJDQogCQ0KIDxodHRwOi8vZGV2Lmdhcm9zdS5jby5rci9j YXRlZ29yeS9sb3R0by9hY3Rpb25fbG90dG8uYXNwP21fY29kZT00MjIxNT4NCg0KIDxodHRwOi8v ZGV2Lmdhcm9zdS5jby5rci9jYXRlZ29yeS9sb3R0by9hY3Rpb25fbG90dG8uYXNwP21fY29kZT00 MjIxNT4NCg0KIDxodHRwOi8vZGV2Lmdhcm9zdS5jby5rci9jYXRlZ29yeS9sb3R0by9hY3Rpb25f bG90dG8uYXNwP21fY29kZT00MjIxNT4NCg0KIDxodHRwOi8vZGV2Lmdhcm9zdS5jby5rci9jYXRl Z29yeS9sb3R0by9hY3Rpb25fbG90dG8uYXNwP21fY29kZT00MjIxNT4NCg0KIDxodHRwOi8vZGV2 Lmdhcm9zdS5jby5rci9jYXRlZ29yeS9sb3R0by9hY3Rpb25fbG90dG8uYXNwP21fY29kZT00MjIx NT4NCg0KIDxodHRwOi8vZGV2Lmdhcm9zdS5jby5rci9jYXRlZ29yeS9sb3R0by9hY3Rpb25fbG90 dG8uYXNwP21fY29kZT00MjIxNT4NCg0KIAkNCiAgICAgICAgICogursgZS1tYWlswLogwPy76rjB ILq4sd7IrsDlsPogwMy/68PLwfi/oSCw/MfRILn9t/y/oSDAx7DFx8+/qSC89r3FwNqwoSCwxbrO uKYgyLi9xcC4t84gDQogICAgICAgICAgILngyPkgyMS/obTCILq4s7vB9iC+yr3AtM+02S4gW7z2 vcWwxbrOXQ0KPGh0dHA6Ly9kZXYuZ2Fyb3N1LmNvLmtyL2NhdGVnb3J5L2xvdHRvL3ZldG9fbG90 dG8uYXNwP21fY29kZT00MjIxNT4gIAkNCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiAgICAgICAgICogscOx3cfPvcUgu+fH18DMIMDWwLi9w7jpIL7wwaa287W1IL+s tvTB1ry8v+QuIGxvdHRvQG9obXlsb3R0by5jb20NCjxtYWlsdG86bG90dG9Ab2hteWxvdHRvLmNv bT4gDQoJDQogCQ0KIDxodHRwOi8vd3d3Lm9obXlsb3R0by5jb20vbHVjay9sdWNrXzAyLmpzcD4g CSANCiAJIA0K ------=_NextPart_000_3DD65_01C1C869.1C820990 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Untitled Document = = = = = = = = =
 
= =
= =
 
=
=BE=C8=B3=E7=C7=CF=BC=BC=BF=E4!
= =BD=CC=B1=D7=B7=AF=BF=EE =BA=BD=B9=D9=B6=F7=BF=A1 = =B8=B6=C0=BD=C0=CC =BC=B3=B7=B9=B4=C2 =B0=E8=C0=FD!
= =BB=FD=C8=B0=BC=D3 =B1=E2=BB=DD=C0=BB =C3=A3=BE=C6 =C7=E0=BA=B9=C0=BB = =B5=E5=B8=AE=B0=ED=C0=DA =C7=D5=B4=CF=B4=D9.
= =C1=F1=B0=C5=BF=EE =BB=FD=C8=B0! =BF=C0=B8=B6=C0=CC=B7=CE=B6=C7=BF=CD = =C7=D4=B2=B2 =C7=CF=BC=BC=BF=E4!!
= =C1=F6=B1=DD =BF=C0=BD=C3=B8=E9, =B8=B6=C0=CF=B8=AE=C1=F6 = 5000=C6=F7=C0=CE=C6=AE=B8=A6 =C0=FB=B8=B3=C7=D8
= =B5=E5=B8=B3=B4=CF=B4=D9. =B8=B6=C0=CF=B8=AE=C1=F6 = =BA=B9=B1=C7=C0=B8=B7=CE =C7=F6=B1=DD=B4=E7=C3=B7=C0=C7
= =B1=E2=C8=B8=B8=A6 =C0=E2=C0=B8=BC=BC=BF=E4!!!
(=B4=DC, =C0=CC =B8=DE=C0=CF=C0=BB =C5=EB=C7=D8 = =B0=A1=C0=D4=C7=CF=BD=C5 =BA=D0=BF=A1 =C7=D1=C7=D4) =
    =      * =BA=BB e-mail=C0=BA =C0=FC=BB=EA=B8=C1 = =BA=B8=B1=DE=C8=AE=C0=E5=B0=FA =C0=CC=BF=EB=C3=CB=C1=F8=BF=A1 = =B0=FC=C7=D1 =B9=FD=B7=FC=BF=A1 =C0=C7=B0=C5=C7=CF=BF=A9 = =BC=F6=BD=C5=C0=DA=B0=A1 =B0=C5=BA=CE=B8=A6 =C8=B8=BD=C5=C0=B8=B7=CE =
           =B9=E0=C8=F9 = =C8=C4=BF=A1=B4=C2 =BA=B8=B3=BB=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9. [=BC=F6=BD=C5=B0=C5=BA=CE] =
  =       =  -------------------------------------------------------------------= -------------------------
         * = =B1=C3=B1=DD=C7=CF=BD=C5 =BB=E7=C7=D7=C0=CC =C0=D6=C0=B8=BD=C3=B8=E9 = =BE=F0=C1=A6=B6=F3=B5=B5 =BF=AC=B6=F4=C1=D6=BC=BC=BF=E4. lotto@ohmylotto.com
 
------=_NextPart_000_3DD65_01C1C869.1C820990-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Mar 10 17:18:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14926 for ; Sun, 10 Mar 2002 17:18:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13564 for midcom-archive@odin.ietf.org; Sun, 10 Mar 2002 17:18:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13398; Sun, 10 Mar 2002 17:13:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13362 for ; Sun, 10 Mar 2002 17:13:01 -0500 (EST) Received: from yahoo.com ([211.106.170.191]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14836 for ; Sun, 10 Mar 2002 17:12:53 -0500 (EST) From: rte294@yahoo.com Message-Id: <200203102212.RAA14836@ietf.org> To: midcom@ietf.org Date: 11 Mar 2002 07:13:23 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_3KdAr6j7_yhUxKy98_MA" Subject: [midcom] =?ISO-8859-1?B?KMirurgpw9awrcirurjHwbfOsde3pSEhyKu6uLDGwaSzoS4=?= Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org ------=_3KdAr6j7_yhUxKy98_MA Content-Type: text/plain Content-Transfer-Encoding: 8bit -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- ------=_3KdAr6j7_yhUxKy98_MA Content-Type: text/html Content-Transfer-Encoding: 8bit O본메일은정보통신망이용촉진및정보보호등에관한법률제50조에의거한[광고]메일입니다

O 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다
O e-mail주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다
수신거부를 원하시면 아래에서 수신거부 해 주세요.정보를 원치 않는 분께는 대단히 죄송 합니다.

♧♧♧ 홍보 때문에 걱정 하셨나요? 이젠 걱정 마세요. ♧♧♧
홍보에 대한 모든것과 노하우 여기 다 있습니다.
무었이든지 물어 보세요.  sejin14859@yahoo.com

▶▶▶ 이번에 홍보대행업 으로 전환함에따라
3년동안  모아놓은 홍보플그램을 염가로  다드림니다.◀◀◀

♥♥♥ 홍보초보용 ♥♥♥

♡이멜추출기2개 ♡이멜편집기1개 ♡이멜발송기2개(정품1,데모1)
♡이멜리스트50만개 ♡게시판등록기1개 ♡게시판디DB2000개

☞ 위의 모든것을 10만원에 다 드립니다. ☜

♥♥♥ 홍보중급용 ♥♥♥

♡이멜추출기3개 ♡이멜편집기1개 ♡이멜발송기3개(정품2개,데모1개)
♡이멜리스트100만개 ♡게시판등록기1개 ♡게시판DB5000개

☞ 위의 모든것을 20만원에 다 드립니다. ☜

♥♥♥ 홍보고급용(1) ♥♥♥

♠♠♠개인 홈페지에 이멜추출,발송기를 직접 설치 해 드립니다.♠♠♠

♡이멜추출기능♡이멜중복삭제기능♡수신거부자동기능♡이멜발송기능
♡수신거부자임시보내기♡임시거부자수신거부자로

☞설치가능한곳=홈페지에MYSQL계정이 있어야함
유료홈이 없는경우는 (200메가,일년호스팅4.4000원별도임)

☞ 위의 설치를 20만원에 해드립니다. ☜

♥♥♥ 홍보고급용(2) ♥♥♥

1000만개 이멜리스트를 올린서버를 몇사람에게만임대함니다.
(기간1년=가격100만원)홍보프로그램과 모든 노하우를 전부 전수 함니다.

◈◈◈ 이멜 광고 대행 ◈◈◈

그동안 홍보의 노하우로 2년에 걸쳐 발송시설을 완비 하고
6000만개의 이멜데이타를 구비하여 이멜홍보를 대행해 드립니다.

♡발송능력= 시간당 1000만통
♡이멜중복 완전제거, 산이멜채크=시간당40만통이상
♡타켓이멜만 분류 (지역,성별,업종,나이등 모든것 가능)

☞ 이멜발송 대행 가격은 10만통 기준 으로 10만원 이며,
살아있는 이멜만 채크해서 보내며, 효과 없으면 100% 환불 합니다.☜


전화폭주로 꼭필요하신분만 아래로 연락 주시면 안내 해드리겠습니다.
 ☞문의메일주실곳 sejin14859@yahoo.com

수신거부

------=_3KdAr6j7_yhUxKy98_MA-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 11 06:10:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04454 for ; Mon, 11 Mar 2002 06:10:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA05932 for midcom-archive@odin.ietf.org; Mon, 11 Mar 2002 06:10:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05450; Mon, 11 Mar 2002 06:06:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05425 for ; Mon, 11 Mar 2002 06:06:26 -0500 (EST) Received: from eugnpop1.eugn.uswest.net (eugnpop1.eugn.uswest.net [207.109.240.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04326 for ; Mon, 11 Mar 2002 06:06:21 -0500 (EST) Message-Id: <200203111106.GAA04326@ietf.org> Received: (qmail 28530 invoked by uid 0); 11 Mar 2002 11:06:23 -0000 Received: from unknown (HELO SOLTANI) (63.224.205.30) by eugnpop1.eugn.uswest.net with SMTP; 11 Mar 2002 11:06:23 -0000 Date: Mon, 11 Mar 2002 03:17:43 -0800 From: "Jamshid Pashutan" <> To: midcom@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: SA-SMTPMail 1.0 (http://www.aspstudio.com) Reply-To: pashutan@qwest.net Content-Transfer-Encoding: 7bit Subject: [midcom] Urgent! Iran! Can you help? Please also forward. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit The purpose of my letter is to introduce the Azadegan Foundation and to request your assistance. The Azadegan Foundation is a Not-for-Profit 501c3 organization dedicated to the promotion of democracy, human rights, and the establishment of a secular government in Iran. Our organization has a concrete, measurable strategy for facilitating change, and it is crucial for us at this juncture to secure your financial and moral support in order to accomplish our objectives. The clerical clique in Tehran views the world as a Mosque to be run by clerics who are inspired by the ecumenical revolutionary ideals of Ayatollah Khomeini. As each day passes, The Islamic regime of Tehran is ever increasing its covert political, financial, military and logistical support to a variety of terrorist groups. Citizens who have risen against the tyrannical rule of the clerics have been repressed brutally. Despite the danger they face, they are demanding that the regime put an end to its arbitrary rule, and to free political prisoners. Their struggle will continue and will intensify until the retreat of the ruling clerics to mosques, and the ultimate transfer of power to the people. Today, persecution of religious minorities continues, almost all pro-democracy newspapers have been shut down, and editors and writers have been imprisoned. Student leaders and all nationalist opposition leaders are being arrested and mercilessly tortured in prison, and women (even pregnant women) are stoned to death. Iran's population is now 70 million, with 45 million under 25 years of age. The economic situation and the over all standard of living is rapidly deteriorating. Discontent among the military, and even the Revolutionary Guard created by the regime, is ever increasing. Religious leaders and religious foundations totally control the economy. The Iranian people desire freedom, democracy, and the establishment of a secular Government. Please reply to this Email for more information about volunteering or supporting the Azadegan Foundation. Support the struggle of the Iranian people! Volunteers are always welcome. Contributions and Inquiries should be addressed to: Azadegan Foundation, PO Box 40152, Washington, DC 20016, USA Phone 541-606-3050 Fax 202-363-5985. Email: pashutan@qwest.net Thank you very much for your time and consideration in to this matter. I look forward to speaking with you further. Please forward this letter to your friends and associates. You can help make a difference! Sincerely Yours, Jamshid Pashutan Advocate for the People Please reply by Email, call us, fax, or snail mail us for more information and reference material. Email me at:: pashutan@qwest.net You received this Email because we aquire Email lists of individuals who may be interested in supporting the Iranian people and their struggle for freedom and democracy. If you have received this message in error, or if you do not wish any further communications from our office, Please respond with 'remove' in the subject line. To stop all Emails instantly, Email pashutan@qwest.net with subject of 'remove'. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 11 16:11:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24600 for ; Mon, 11 Mar 2002 16:11:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15740 for midcom-archive@odin.ietf.org; Mon, 11 Mar 2002 16:11:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15667; Mon, 11 Mar 2002 16:09:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15636 for ; Mon, 11 Mar 2002 16:08:58 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24531 for ; Mon, 11 Mar 2002 16:08:53 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2BL8Qh21835 for ; Mon, 11 Mar 2002 13:08:26 -0800 (PST) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADE27997; Mon, 11 Mar 2002 13:06:07 -0800 (PST) Message-Id: <5.1.0.14.0.20020311160843.01333b80@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Mar 2002 16:10:55 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] New charter Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Our charter revision has been approved and posted, and the new version includes the pre-midcom deliverables. Please take a gander: http://www.ietf.org/html.charters/midcom-charter.html Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Mar 12 12:03:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27546 for ; Tue, 12 Mar 2002 12:03:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26079 for midcom-archive@odin.ietf.org; Tue, 12 Mar 2002 12:03:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24217; Tue, 12 Mar 2002 11:56:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24185 for ; Tue, 12 Mar 2002 11:56:18 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27313 for ; Tue, 12 Mar 2002 11:56:13 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2CGtf316361 for ; Tue, 12 Mar 2002 08:55:41 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACH38391; Tue, 12 Mar 2002 08:55:58 -0800 (PST) From: "Cullen Jennings" To: Date: Tue, 12 Mar 2002 08:57:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <5.1.0.14.0.20020311160843.01333b80@localhost> Content-Transfer-Encoding: 7bit Subject: [midcom] STUN over TCP? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Is there any need to run STUN over TCP? A few places in the 01 draft make it sound like this is possible. Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Mar 12 12:03:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27563 for ; Tue, 12 Mar 2002 12:03:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26093 for midcom-archive@odin.ietf.org; Tue, 12 Mar 2002 12:03:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24249; Tue, 12 Mar 2002 11:56:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24193 for ; Tue, 12 Mar 2002 11:56:18 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27315 for ; Tue, 12 Mar 2002 11:56:14 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2CGtg316375 for ; Tue, 12 Mar 2002 08:55:42 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACH38392; Tue, 12 Mar 2002 08:55:58 -0800 (PST) From: "Cullen Jennings" To: Date: Tue, 12 Mar 2002 08:57:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Subject: [midcom] port name for IANA Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit What service name will be used for the port number IANA gives to STUN? The name stun-port and stun-p1 through stun-p3 are used. I'm fine with going with stun as the name but it might cause a bit of confusion since it is very similar. Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Mar 12 13:30:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00309 for ; Tue, 12 Mar 2002 13:30:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00363 for midcom-archive@odin.ietf.org; Tue, 12 Mar 2002 13:30:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29778; Tue, 12 Mar 2002 13:25:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29747 for ; Tue, 12 Mar 2002 13:25:22 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00079 for ; Tue, 12 Mar 2002 13:25:18 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g2CIOmT26361; Tue, 12 Mar 2002 10:24:49 -0800 (PST) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADE54958; Tue, 12 Mar 2002 10:22:29 -0800 (PST) Message-Id: <5.1.0.14.0.20020312132120.01316050@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Mar 2002 13:28:06 -0500 To: "Cullen Jennings" , From: Melinda Shore Subject: Re: [midcom] STUN over TCP? In-Reply-To: References: <5.1.0.14.0.20020311160843.01333b80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 08:57 AM 3/12/02 -0800, Cullen Jennings wrote: >Is there any need to run STUN over TCP? A few places in the 01 draft make it >sound like this is possible. What's driving that is security mechanism. We absolutely need to authenticate server responses, and adding a signature runs the considerable risk of pushing the packet size up beyond the MTU. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Mar 12 14:18:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02377 for ; Tue, 12 Mar 2002 14:18:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03352 for midcom-archive@odin.ietf.org; Tue, 12 Mar 2002 14:18:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03088; Tue, 12 Mar 2002 14:14:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03062 for ; Tue, 12 Mar 2002 14:14:39 -0500 (EST) Received: from hyperion.site5.com (64-21-152-2.site5.com [64.21.152.2] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02131 for ; Tue, 12 Mar 2002 14:14:35 -0500 (EST) Received: from [66.46.102.74] (helo=aura) by hyperion.site5.com with smtp (Exim 3.34 #1) id 16krjK-0004TI-00; Tue, 12 Mar 2002 14:14:38 -0500 Reply-To: From: "Email Administrator" To: , "Cullen Jennings" , "Melinda Shore" Subject: RE: [midcom] STUN over TCP? Date: Tue, 12 Mar 2002 12:14:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.0.20020312132120.01316050@localhost> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hyperion.site5.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - polyphase.ca Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit All; The additional burden of implementing the security features in -01.txt are quite notable. Agreed that TCP would be preferable for MTU considerations, but, as an author of a STUN sample implementation, I ask: Does anyone have any pointers to libraries to aid in implementing the signature authentication? I see this as being a very heavy bit of code. Especially where embedded devices are concerned and where footprint size of the client software is critical. Unless I overlooked something in -01, I feel that this could easily increase the code size and implementation effort for the STUN client by an order of magnitude. Comments? Pointers? I have read RFC 2630 and feel very unenlightened. ;) Alan Hawrylyshen bcc: STUN mailing list. (address omitted, see http://www.polyphase.ca/software/stun/ ) -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Melinda Shore Sent: 12-Mar-2002 11:28 To: Cullen Jennings; midcom@ietf.org Subject: Re: [midcom] STUN over TCP? At 08:57 AM 3/12/02 -0800, Cullen Jennings wrote: >Is there any need to run STUN over TCP? A few places in the 01 draft make it >sound like this is possible. What's driving that is security mechanism. We absolutely need to authenticate server responses, and adding a signature runs the considerable risk of pushing the packet size up beyond the MTU. 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 daemon@optimus.ietf.org Tue Mar 12 15:01:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04469 for ; Tue, 12 Mar 2002 15:01:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06632 for midcom-archive@odin.ietf.org; Tue, 12 Mar 2002 15:01:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06053; Tue, 12 Mar 2002 14:58:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06024 for ; Tue, 12 Mar 2002 14:58:25 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04312 for ; Tue, 12 Mar 2002 14:58:20 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2CJvl304146; Tue, 12 Mar 2002 11:57:47 -0800 (PST) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADE59073; Tue, 12 Mar 2002 11:55:33 -0800 (PST) Message-Id: <5.1.0.14.0.20020312145559.00ac8da0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Mar 2002 15:00:42 -0500 To: , From: Melinda Shore Subject: RE: [midcom] STUN over TCP? In-Reply-To: References: <5.1.0.14.0.20020312132120.01316050@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:14 PM 3/12/02 -0700, Email Administrator wrote: >Does anyone have any pointers to libraries to aid in implementing the >signature authentication? I see this as being a very heavy bit of code. It overwhelms the rest of the protocol, but it's necessary. Without it you've got a serious exposure that's trivial to implement. Note that we're going to have the same problem with the midcom protocol. The canonical place to go for free crypto code is OpenSSL. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Mar 13 04:34:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01283 for ; Wed, 13 Mar 2002 04:34:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03140 for midcom-archive@odin.ietf.org; Wed, 13 Mar 2002 04:34:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02292; Wed, 13 Mar 2002 04:24:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02267 for ; Wed, 13 Mar 2002 04:24:08 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01155 for ; Wed, 13 Mar 2002 04:24:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.117]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2D9OcTE002940; Wed, 13 Mar 2002 04:24:38 -0500 (EST) Message-ID: <3C8F1A99.FB5192EB@dynamicsoft.com> Date: Wed, 13 Mar 2002 04:23:37 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings CC: midcom@ietf.org Subject: Re: [midcom] port name for IANA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I asked for nat-stun-port. -Jonathan R. Cullen Jennings wrote: > > What service name will be used for the port number IANA gives to STUN? > The > name stun-port and stun-p1 through stun-p3 are used. I'm fine with going > with stun as the name but it might cause a bit of confusion since it is > very > similar. > > Cullen > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Mar 13 04:34:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01299 for ; Wed, 13 Mar 2002 04:34:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03154 for midcom-archive@odin.ietf.org; Wed, 13 Mar 2002 04:34:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03058; Wed, 13 Mar 2002 04:32:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03031 for ; Wed, 13 Mar 2002 04:32:53 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01250 for ; Wed, 13 Mar 2002 04:32:49 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.117]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2D9XMTE002943; Wed, 13 Mar 2002 04:33:22 -0500 (EST) Message-ID: <3C8F1CA5.64C3CE42@dynamicsoft.com> Date: Wed, 13 Mar 2002 04:32:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: email.administrator@polyphase.ca, midcom@ietf.org Subject: Re: [midcom] STUN over TCP? References: <5.1.0.14.0.20020312145559.00ac8da0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Melinda Shore wrote: > > At 12:14 PM 3/12/02 -0700, Email Administrator wrote: > >Does anyone have any pointers to libraries to aid in implementing the > >signature authentication? I see this as being a very heavy bit of code. I understand your frustration, and you are correct that the CMS stuff will be easily an order of magnitude more complex than the protocol it protects. However, there are very serious security risks unless STUN responses are well protected. If I could inject a fake stun response, containing my own IP address and port in the MAPPED-ADDRESS attribute, I can steal peoples phone calls, re-route media, and so on. All sorts of really bad things. It would be an effective back door to break security of any application protocols that would use STUN. Now, we debated whether or not to use a public key mechanism to sign the responses, or shared secret. The latter would allow us to use a simple keyed HMAC, much, much less complicated. However, its not practical. A server does not authenticate itself to a user with a shared secret. On the web, its with server certificates in TLS/SSL. The simple fact is that you will want to use stun servers in domains you don't even have a shared secret with at all. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 13 05:54:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02095 for ; Wed, 13 Mar 2002 05:54:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA07192 for midcom-archive@odin.ietf.org; Wed, 13 Mar 2002 05:54:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06970; Wed, 13 Mar 2002 05:50:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06941 for ; Wed, 13 Mar 2002 05:50:26 -0500 (EST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02053 for ; Wed, 13 Mar 2002 05:50:22 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 13 Mar 2002 02:49:53 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 13 Mar 2002 02:49:53 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Mar 2002 02:49:52 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Mar 2002 02:49:53 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 13 Mar 2002 02:46:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN over TCP? Date: Wed, 13 Mar 2002 02:46:50 -0800 Message-ID: Thread-Topic: [midcom] STUN over TCP? Thread-Index: AcHKccTwsbqbNMFZSUef4FI9iDIU3AACB0Ig From: "Christian Huitema" To: "Jonathan Rosenberg" , "Melinda Shore" Cc: X-OriginalArrivalTime: 13 Mar 2002 10:46:49.0002 (UTC) FILETIME=[60B080A0:01C1CA7C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA06942 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > However, there are very serious security risks unless STUN responses are > well protected. If I could inject a fake stun response, containing my > own IP address and port in the MAPPED-ADDRESS attribute, I can steal > peoples phone calls, re-route media, and so on. All sorts of really bad > things. It would be an effective back door to break security of any > application protocols that would use STUN. > > Now, we debated whether or not to use a public key mechanism to sign the > responses, or shared secret. The latter would allow us to use a simple > keyed HMAC, much, much less complicated. However, its not practical. A > server does not authenticate itself to a user with a shared secret. On > the web, its with server certificates in TLS/SSL. The simple fact is > that you will want to use stun servers in domains you don't even have a > shared secret with at all. There are several levels of protection that can be implemented, and result in various trade-off. The simplest protection is to insert a "nonce" in the request, and to check that the "nonce" is copied in the response. This prevents attacks by parties that are not on the direct path between the STUN client and server, and is almost free from an implementation point-of-view. The level of protection is equivalent to the one of clear-text signaling protocols. The simpler protection can be complement by a simple test on the returned mapping. If the clients already obtained mappings in a secure way, and if the IP address component in the new mappings is the same as the address in a previous mapping, then the risk of just using the mapping provided is very limited. All other protections imply having a form of digital signature, which makes the STUN server notably more expensive to run. The simplest cryptographic solution is to assume that the STUN server has a public key certificate, and uses the private key associated to the public key certificate to sign the responses. Melinda correctly points out that certificates can be very large. We should not require that the full certificate be transmitted in every response. A better design would be to carry a signature in the response, and to also provide the URL at which the response can be obtained. Using any form of cryptography closes one type of attack (forged responses) but creates another, the possibility to bring the server down by forcing it to sign a large number of queries. It also open a distributed denial of service avenue, as responses can be much longer than queries. Both risks can be mitigated by using a four ways handshake: Request mapping + nonce A --> <-- mapping + nonce A + nonce B Request signed mapping + nonce B --> <-- signed mapping The idea being to force the client to send back a cookie to the server, proving that the initial message did not come from a forged address, before sending a signed mapping. Note that the algorithm also enables the client to decide whether or not to request the signed mapping. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 13 09:22:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06061 for ; Wed, 13 Mar 2002 09:22:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17366 for midcom-archive@odin.ietf.org; Wed, 13 Mar 2002 09:22:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17277; Wed, 13 Mar 2002 09:20:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17252 for ; Wed, 13 Mar 2002 09:20:55 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06039 for ; Wed, 13 Mar 2002 09:20:53 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2DEKJ301155 for ; Wed, 13 Mar 2002 06:20:19 -0800 (PST) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADE83144; Wed, 13 Mar 2002 06:18:05 -0800 (PST) Message-Id: <5.1.0.14.0.20020313090930.00aa0140@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Mar 2002 09:24:14 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Protocol development Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Jonathan has mentioned in the past that he feels that the actual packetization and protocol used to send requests around the network is less interesting and less important than the semantics of those requests. I agree, and I can foresee us becoming mired in a lengthy and contentious argument about which base protocol to use while the substance of the problem gets short shrift. In order to 1) avoid that, 2) make progress while the protocol evaluation is underway, and 3) try to maintain focus on the meat of the problem, I'd like to suggest that we start developing a working document (i.e. not necessarily for publication) that lays out the semantics of midcom requests and midcom responses. Thoughts/opinions/comments/etc. welcome. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 13 09:34:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06474 for ; Wed, 13 Mar 2002 09:34:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18260 for midcom-archive@odin.ietf.org; Wed, 13 Mar 2002 09:34:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18131; Wed, 13 Mar 2002 09:32:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18083 for ; Wed, 13 Mar 2002 09:32:12 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06419 for ; Wed, 13 Mar 2002 09:32:10 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2DEVeD24259 for ; Wed, 13 Mar 2002 09:31:40 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 09:31:42 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102B15E@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Protocol development Date: Wed, 13 Mar 2002 09:31:46 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I had started to do that for my own purposes and ran into some questions on what we really mean by some of the requirements. I'll put my questions out to the list in the next couple of days as I have time. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, March 13, 2002 9:24 AM To: midcom@ietf.org Subject: [midcom] Protocol development Jonathan has mentioned in the past that he feels that the actual packetization and protocol used to send requests around the network is less interesting and less important than the semantics of those requests. I agree, and I can foresee us becoming mired in a lengthy and contentious argument about which base protocol to use while the substance of the problem gets short shrift. In order to 1) avoid that, 2) make progress while the protocol evaluation is underway, and 3) try to maintain focus on the meat of the problem, I'd like to suggest that we start developing a working document (i.e. not necessarily for publication) that lays out the semantics of midcom requests and midcom responses. Thoughts/opinions/comments/etc. welcome. 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 daemon@optimus.ietf.org Wed Mar 13 09:46:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06865 for ; Wed, 13 Mar 2002 09:46:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18781 for midcom-archive@odin.ietf.org; Wed, 13 Mar 2002 09:46:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18727; Wed, 13 Mar 2002 09:44:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18698 for ; Wed, 13 Mar 2002 09:44:55 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06813 for ; Wed, 13 Mar 2002 09:44:52 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.117]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2DEjMTE003087; Wed, 13 Mar 2002 09:45:23 -0500 (EST) Message-ID: <3C8F65C4.48ED055D@dynamicsoft.com> Date: Wed, 13 Mar 2002 09:44:20 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] STUN over TCP? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > However, there are very serious security risks unless STUN responses > are > > well protected. If I could inject a fake stun response, containing my > > own IP address and port in the MAPPED-ADDRESS attribute, I can steal > > peoples phone calls, re-route media, and so on. All sorts of really > bad > > things. It would be an effective back door to break security of any > > application protocols that would use STUN. > > > > Now, we debated whether or not to use a public key mechanism to sign > the > > responses, or shared secret. The latter would allow us to use a simple > > keyed HMAC, much, much less complicated. However, its not practical. A > > server does not authenticate itself to a user with a shared secret. On > > the web, its with server certificates in TLS/SSL. The simple fact is > > that you will want to use stun servers in domains you don't even have > a > > shared secret with at all. > > There are several levels of protection that can be implemented, and > result in various trade-off. > > The simplest protection is to insert a "nonce" in the request, and to > check that the "nonce" is copied in the response. This prevents attacks > by parties that are not on the direct path between the STUN client and > server, and is almost free from an implementation point-of-view. The > level of protection is equivalent to the one of clear-text signaling > protocols. Right. We always had that, in the form of the transaction ID in the request, which had to be mirrored in the response. > > The simpler protection can be complement by a simple test on the > returned mapping. If the clients already obtained mappings in a secure > way, and if the IP address component in the new mappings is the same as > the address in a previous mapping, then the risk of just using the > mapping provided is very limited. True; this won't work for nats which are mapping addresses into more than one public IP address, though. > > All other protections imply having a form of digital signature, which > makes the STUN server notably more expensive to run. The simplest > cryptographic solution is to assume that the STUN server has a public > key certificate, and uses the private key associated to the public key > certificate to sign the responses. Right. THis is what we do in stun-01. > > Melinda correctly points out that certificates can be very large. We > should not require that the full certificate be transmitted in every > response. A better design would be to carry a signature in the response, > and to also provide the URL at which the response can be obtained. We do something slightly different, which is to carry only the signature in the UDP response. But, if you send the request via TCP, you get the certificates too. All of the other data from the TCP response is not useful - just the certificates are useful. One you have them, you can store them, and you won't need to retrieve them again from the same server (until they expire). > > Using any form of cryptography closes one type of attack (forged > responses) but creates another, the possibility to bring the server down > by forcing it to sign a large number of queries. It also open a > distributed denial of service avenue, as responses can be much longer > than queries. Both risks can be mitigated by using a four ways > handshake: > > Request mapping + nonce A --> > <-- mapping + nonce A + nonce B > Request signed mapping + nonce B --> > <-- signed mapping > > The idea being to force the client to send back a cookie to the server, > proving that the initial message did not come from a forged address, > before sending a signed mapping. Note that the algorithm also enables > the client to decide whether or not to request the signed mapping. Right. We also have this in stun-01 using the cookie. The flow looks exactly like what you have above, with nonce A = transaction ID, and nonce B being the cookie attribute. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Mar 13 13:39:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14589 for ; Wed, 13 Mar 2002 13:39:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03970 for midcom-archive@odin.ietf.org; Wed, 13 Mar 2002 13:39:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03922; Wed, 13 Mar 2002 13:36:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03882 for ; Wed, 13 Mar 2002 13:36:13 -0500 (EST) Received: from localhost ([211.52.243.248]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14410 for ; Wed, 13 Mar 2002 13:31:31 -0500 (EST) Message-Id: <200203131831.NAA14410@ietf.org> Reply-To: lysjjy@netian From: 금일수협수산 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 14 Mar 2002 03:31:29 +0900 Subject: [midcom] 완도 금일수협수산 입니다[정보] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 금일수협수산 광고메일.

 

 

 

 

 

 완도 금일수산업협동조합의 자사 금일수협수산입니다. 

 저희 수협수산에서는 청정해역 완도에서 나오는 모든 수산물, 특히 다시마 를 가지고 여러가지 상품화 하는데 성공하여 전국에 유통과 세계 여러나라에 자랑스럽게 수출하는 금일수협수산 입니다. 변비, 비만, 다이어트, 체질개선 및 각종 성인병에 다시마 의 놀라운 현상은 현대 과학으로 입증된 바, 현재 수산물 개방으로 인하여 한해동안 바다의 농사를 지은 후40~50%는 다시 바다로 버려지는 현 시점이고, 수산업계가 이루 말로 표현하지 못할 정도로 상당히 어려운 실정이라 자구책의 일환으로 저희 금일수협수산의 홈페이지를 개방했습니다. 다시마의 중요성과 왜 다시마 를 많이 먹어야 되는지를 상세히 기록, 수록해 놓았고, 철따라 계절따라 생산되는 수산물의 대한 정보를 알려 드리고 있습니다. 금번 저희 조합에서는 전 국민들에게 우리 수산물의 중요성과 조합에서 나오는 상품을 알리고 직거래하며 저희 조합의 평생 직거래 회원으로 모시고자 합니다.  많이들 방문하셔서 많은 지도 편달 바랍니다.

http://soosan1.com
 금일수협수산  홈페이지로 바로가기 금일수협수산 홈페이지 바로가기

 

 

 

 

 

 

정통부 권고사항에 의거 제목에 [광고]라고 표기한 1회성 메일입니다.

웹서핑중 알게된 메일 입니다. 수신을 원치 않으면 수신거부를 눌러주세요



버튼을 클릭하시면 수신거부처리가 이루어 집니다.
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Mar 13 17:53:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23183 for ; Wed, 13 Mar 2002 17:53:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24115 for midcom-archive@odin.ietf.org; Wed, 13 Mar 2002 17:53:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23538; Wed, 13 Mar 2002 17:48:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23497 for ; Wed, 13 Mar 2002 17:48:30 -0500 (EST) Received: from znsgs01r.europe.nortel.com (h14s128a211n47.user.nortelnetworks.com [47.211.128.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22995 for ; Wed, 13 Mar 2002 17:48:26 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2DMkwt05659; Wed, 13 Mar 2002 22:46:58 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 22:47:37 -0000 Message-ID: From: "Cedric Aoun" To: "'Jonathan Rosenberg'" , Christian Huitema Cc: Melinda Shore , midcom@ietf.org Subject: RE: [midcom] STUN over TCP? Date: Wed, 13 Mar 2002 22:47:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CAE1.10FBE300" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1CAE1.10FBE300 Content-Type: text/plain We should be able to handle the segmentation issue without TCP, since the message length sent by the STUN client won't normaly exceed the MTU (the client is not sending a certificate).We already have a mechanism to retransmit the requests if nothing happens (in case one fragment is lost). The issue with fragmentation and NATs is when 2 NATTed clients are trying to reach the same server and both datagrams are fragmented with the same fragment id, the STUN server won't be able to distinguish the 2 client messages. I don't see this case happening here since the client is not sending several hundred bytes certificate, am I missing something? -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, March 13, 2002 3:44 PM To: Christian Huitema Cc: Melinda Shore; midcom@ietf.org Subject: Re: [midcom] STUN over TCP? Christian Huitema wrote: > > > However, there are very serious security risks unless STUN responses > are > > well protected. If I could inject a fake stun response, containing my > > own IP address and port in the MAPPED-ADDRESS attribute, I can steal > > peoples phone calls, re-route media, and so on. All sorts of really > bad > > things. It would be an effective back door to break security of any > > application protocols that would use STUN. > > > > Now, we debated whether or not to use a public key mechanism to sign > the > > responses, or shared secret. The latter would allow us to use a simple > > keyed HMAC, much, much less complicated. However, its not practical. A > > server does not authenticate itself to a user with a shared secret. On > > the web, its with server certificates in TLS/SSL. The simple fact is > > that you will want to use stun servers in domains you don't even have > a > > shared secret with at all. > > There are several levels of protection that can be implemented, and > result in various trade-off. > > The simplest protection is to insert a "nonce" in the request, and to > check that the "nonce" is copied in the response. This prevents attacks > by parties that are not on the direct path between the STUN client and > server, and is almost free from an implementation point-of-view. The > level of protection is equivalent to the one of clear-text signaling > protocols. Right. We always had that, in the form of the transaction ID in the request, which had to be mirrored in the response. > > The simpler protection can be complement by a simple test on the > returned mapping. If the clients already obtained mappings in a secure > way, and if the IP address component in the new mappings is the same as > the address in a previous mapping, then the risk of just using the > mapping provided is very limited. True; this won't work for nats which are mapping addresses into more than one public IP address, though. > > All other protections imply having a form of digital signature, which > makes the STUN server notably more expensive to run. The simplest > cryptographic solution is to assume that the STUN server has a public > key certificate, and uses the private key associated to the public key > certificate to sign the responses. Right. THis is what we do in stun-01. > > Melinda correctly points out that certificates can be very large. We > should not require that the full certificate be transmitted in every > response. A better design would be to carry a signature in the response, > and to also provide the URL at which the response can be obtained. We do something slightly different, which is to carry only the signature in the UDP response. But, if you send the request via TCP, you get the certificates too. All of the other data from the TCP response is not useful - just the certificates are useful. One you have them, you can store them, and you won't need to retrieve them again from the same server (until they expire). > > Using any form of cryptography closes one type of attack (forged > responses) but creates another, the possibility to bring the server down > by forcing it to sign a large number of queries. It also open a > distributed denial of service avenue, as responses can be much longer > than queries. Both risks can be mitigated by using a four ways > handshake: > > Request mapping + nonce A --> > <-- mapping + nonce A + nonce B > Request signed mapping + nonce B --> > <-- signed mapping > > The idea being to force the client to send back a cookie to the server, > proving that the initial message did not come from a forged address, > before sending a signed mapping. Note that the algorithm also enables > the client to decide whether or not to request the signed mapping. Right. We also have this in stun-01 using the cookie. The flow looks exactly like what you have above, with nonce A = transaction ID, and nonce B being the cookie attribute. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1CAE1.10FBE300 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] STUN over TCP?

We should be able to handle the segmentation issue = without TCP, since the message length sent by the STUN client won't = normaly exceed the MTU (the client is not sending a certificate).We = already have a mechanism to retransmit the requests if nothing happens = (in case one fragment is lost).

The issue with fragmentation and NATs is when 2 = NATTed clients are trying to reach the same server and both datagrams = are fragmented with the same fragment id, the STUN server won't be able = to distinguish the 2 client messages.

I don't see this case happening here since the client = is not sending several hundred bytes certificate, am I missing = something?

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, March 13, 2002 3:44 PM
To: Christian Huitema
Cc: Melinda Shore; midcom@ietf.org
Subject: Re: [midcom] STUN over TCP?




Christian Huitema wrote:
>
> > However, there are very serious security = risks unless STUN responses
> are
> > well protected. If I could inject a fake = stun response, containing my
> > own IP address and port in the = MAPPED-ADDRESS attribute, I can steal
> > peoples phone calls, re-route media, and = so on. All sorts of really
> bad
> > things. It would be an effective back door = to break security of any
> > application protocols that would use = STUN.
> >
> > Now, we debated whether or not to use a = public key mechanism to sign
> the
> > responses, or shared secret. The latter = would allow us to use a simple
> > keyed HMAC, much, much less complicated. = However, its not practical. A
> > server does not authenticate itself to a = user with a shared secret. On
> > the web, its with server certificates in = TLS/SSL. The simple fact is
> > that you will want to use stun servers in = domains you don't even have
> a
> > shared secret with at all.
>
> There are several levels of protection that can = be implemented, and
> result in various trade-off.
>
> The simplest protection is to insert a = "nonce" in the request, and to
> check that the "nonce" is copied in = the response. This prevents attacks
> by parties that are not on the direct path = between the STUN client and
> server, and is almost free from an = implementation point-of-view. The
> level of protection is equivalent to the one of = clear-text signaling
> protocols.

Right. We always had that, in the form of the = transaction ID in the
request, which had to be mirrored in the response. =

>
> The simpler protection can be complement by a = simple test on the
> returned mapping. If the clients already = obtained mappings in a secure
> way, and if the IP address component in the new = mappings is the same as
> the address in a previous mapping, then the = risk of just using the
> mapping provided is very limited.

True; this won't work for nats which are mapping = addresses into more
than one public IP address, though.

>
> All other protections imply having a form of = digital signature, which
> makes the STUN server notably more expensive to = run. The simplest
> cryptographic solution is to assume that the = STUN server has a public
> key certificate, and uses the private key = associated to the public key
> certificate to sign the responses.

Right. THis is what we do in stun-01.

>
> Melinda correctly points out that certificates = can be very large. We
> should not require that the full certificate be = transmitted in every
> response. A better design would be to carry a = signature in the response,
> and to also provide the URL at which the = response can be obtained.

We do something slightly different, which is to carry = only the signature
in the UDP response. But, if you send the request = via TCP, you get the
certificates too. All of the other data from the TCP = response is not
useful - just the certificates are useful. One you = have them, you can
store them, and you won't need to retrieve them = again from the same
server (until they expire).

>
> Using any form of cryptography closes one type = of attack (forged
> responses) but creates another, the possibility = to bring the server down
> by forcing it to sign a large number of = queries. It also open a
> distributed denial of service avenue, as = responses can be much longer
> than queries. Both risks can be mitigated by = using a four ways
> handshake:
>
>         = Request mapping + nonce A -->
>          = ;       <-- mapping + nonce A + nonce = B
>         = Request signed mapping + nonce B -->
>          = ;       <-- signed mapping
>
> The idea being to force the client to send back = a cookie to the server,
> proving that the initial message did not come = from a forged address,
> before sending a signed mapping. Note that the = algorithm also enables
> the client to decide whether or not to request = the signed mapping.

Right. We also have this in stun-01 using the cookie. = The flow looks
exactly like what you have above, with nonce A =3D = transaction ID, and
nonce B being the cookie attribute.

-Jonathan R.


--
Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
dynamicsoft        &nbs= p;           &nbs= p;        East Hanover, NJ = 07936
jdrosen@dynamicsoft.com      &nbs= p;          FAX: (973) = 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
http://www.dynamicsoft.com

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

------_=_NextPart_001_01C1CAE1.10FBE300-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu Mar 14 14:19:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26818 for ; Thu, 14 Mar 2002 14:19:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26960 for midcom-archive@odin.ietf.org; Thu, 14 Mar 2002 14:19:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26635; Thu, 14 Mar 2002 14:14:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26605 for ; Thu, 14 Mar 2002 14:14:39 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26599; Thu, 14 Mar 2002 14:14:33 -0500 (EST) Message-Id: <200203141914.OAA26599@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , midcom@ietf.org From: The IESG Date: Thu, 14 Mar 2002 14:14:33 -0500 Subject: [midcom] Document Action: Middlebox Communications (MIDCOM) Protocol Requirements to Informational Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org The IESG has approved the Internet-Draft 'Middlebox Communications (MIDCOM) Protocol Requirements' as an Informational RFC. This document is the product of the Middlebox Communication Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu Mar 14 14:19:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26850 for ; Thu, 14 Mar 2002 14:19:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27023 for midcom-archive@odin.ietf.org; Thu, 14 Mar 2002 14:19:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26862; Thu, 14 Mar 2002 14:18:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26834 for ; Thu, 14 Mar 2002 14:17:57 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26699; Thu, 14 Mar 2002 14:17:53 -0500 (EST) Message-Id: <200203141917.OAA26699@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , midcom@ietf.org From: The IESG Date: Thu, 14 Mar 2002 14:17:52 -0500 Subject: [midcom] Document Action: Middlebox Communication Architecture and framework to Informational Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org The IESG has approved the Internet-Draft 'Middlebox Communication Architecture and framework' as an Informational RFC. This document is the product of the Middlebox Communication Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 14 21:05:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08081 for ; Thu, 14 Mar 2002 21:05:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA26858 for midcom-archive@odin.ietf.org; Thu, 14 Mar 2002 21:05:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26469; Thu, 14 Mar 2002 21:03:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26440 for ; Thu, 14 Mar 2002 21:03:49 -0500 (EST) Received: from email4.gm20.com (email4.gm20.com [164.109.174.93]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07873 for ; Thu, 14 Mar 2002 21:03:46 -0500 (EST) Message-ID: <6377634.1016157829180.Kada.Kada1(pc-93)@email4.gm20.com> Date: Thu, 14 Mar 2002 21:03:49 -0500 (EST) From: "Northland Systems Training Inc." To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [midcom] Two Day MPLS Course Toronto April 8-9 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: quoted-printable
3D""=A0= =A03D""

2 Day Multi-Protocol Label Switching (MPLS)
Course Toro= nto April 8-9



Due to the popularity of this course, Northland, the = leader in complex technical eLearning and instructor-led training, is runni= ng its non-vendor specific MPLS course again in Toronto on April 8-9. Part= icipants need a strong understanding and experience in WANs, LANs, data com= munications, routing, internetworking and communications protocols. Seati= ng is limited to 20, so register immediately to reserve your spot.

This course addresses the challenge of next generatio= n networks and describes MPLS concepts, architecture and components, and pr= actical solutions. For more information and a detailed course outline foll= ow the link below.

Join the thousands of satisfied students who have tak= en Northland's high quality, industry leading courses to increase their ski= lls, and maintain their knowledge in the fast paced telecom market.

Additional course information and registration=

Upon completion of this course you receive 30 days acc= ess to the Northland on-line MPLS course.

Anyone registering two or more people on any of Northl= and=92s instructor-led courses will receive a complimentary Northland denim= shirt.

Please forward the email to any colleagues or clients= who would be interested in this course.


Thank you for your interest.

Sincerely,

Alan P. Daly
Account Manager
Northland Systems Training Inc.
255 Albert Street, Suite 500
Ottawa, Ontario
K1P 6A9

Direct:=09(613) 667-5063
Cell:=09(613) 223-1062
Fax:=09(613) 667-5098

"Changing learning from an event to a life long process"

KNOW YOUR WAY
visit www.northlandeLearning.= com



Click here to unsubscribe from our mailing list. Or reply to t= his message with the word unsubscribe in the subject line.


_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 15 03:13:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23295 for ; Fri, 15 Mar 2002 03:13:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26299 for midcom-archive@odin.ietf.org; Fri, 15 Mar 2002 03:13:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26034; Fri, 15 Mar 2002 03:07:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26002 for ; Fri, 15 Mar 2002 03:07:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23224 for ; Fri, 15 Mar 2002 03:07:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2F88CTE006355; Fri, 15 Mar 2002 03:08:12 -0500 (EST) Message-ID: <3C91ABB0.2DC815FA@dynamicsoft.com> Date: Fri, 15 Mar 2002 03:07:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cedric Aoun CC: Christian Huitema , Melinda Shore , midcom@ietf.org Subject: Re: [midcom] STUN over TCP? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Cedric Aoun wrote: > > We should be able to handle the segmentation issue without TCP, since > the message length sent by the STUN client won't normaly exceed the MTU > (the client is not sending a certificate). THe problem is in the response. The response needs to have certificates. > We already have a mechanism to > retransmit the requests if nothing happens (in case one fragment is > lost). Its not just loss probabilities, its the total failure of fragment traversal through NAT. > > The issue with fragmentation and NATs is when 2 NATTed clients are > trying to reach the same server and both datagrams are fragmented with > the same fragment id, the STUN server won't be able to distinguish the 2 > client messages. No; the problem as I understand it is that most nats won't refragment an IP packet. So, they totally ignore fragment bits. So, the first fragment will pass since it has the UDP header. But, the second one doesn't, and will be dropped by the NAT since it doesn't match any UDP sessions in progress through the NAT. Thats because the NAT thinks that there should be a UDP or TCP header after IP, but there won't be anything. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 15 05:26:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25526 for ; Fri, 15 Mar 2002 05:26:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA07319 for midcom-archive@odin.ietf.org; Fri, 15 Mar 2002 05:26:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07117; Fri, 15 Mar 2002 05:25:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07059 for ; Fri, 15 Mar 2002 05:24:41 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25415 for ; Fri, 15 Mar 2002 05:19:48 -0500 (EST) Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2FAJE321333; Fri, 15 Mar 2002 02:19:14 -0800 (PST) Received: from cisco.com (mahadev-u5.cisco.com [128.107.162.96]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ACG40444; Fri, 15 Mar 2002 02:12:33 -0800 (PST) Message-ID: <3C91CAA8.A040347F@cisco.com> Date: Fri, 15 Mar 2002 02:19:20 -0800 From: Mahadev Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Cedric Aoun , Christian Huitema , Melinda Shore , midcom@ietf.org Subject: Re: [midcom] STUN over TCP? References: <3C91ABB0.2DC815FA@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > > > > > The issue with fragmentation and NATs is when 2 NATTed clients are > > trying to reach the same server and both datagrams are fragmented with > > the same fragment id, the STUN server won't be able to distinguish the 2 > > client messages. > > No; the problem as I understand it is that most nats won't refragment an > IP packet. So, they totally ignore fragment bits. So, the first fragment > will pass since it has the UDP header. But, the second one doesn't, and > will be dropped by the NAT since it doesn't match any UDP sessions in > progress through the NAT. Thats because the NAT thinks that there should > be a UDP or TCP header after IP, but there won't be anything. > This is not a big problem as such. There are NAT implementations which take care of fragmentation issue by storing state information from the first fragment. But then, this would work only if fragment 0 arrives first. -Mahadev _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 15 08:26:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28229 for ; Fri, 15 Mar 2002 08:26:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20535 for midcom-archive@odin.ietf.org; Fri, 15 Mar 2002 08:26:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19060; Fri, 15 Mar 2002 08:11:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19035 for ; Fri, 15 Mar 2002 08:11:37 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27845 for ; Fri, 15 Mar 2002 08:11:33 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2FDAWL15848; Fri, 15 Mar 2002 14:10:33 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 13:10:36 -0000 Message-ID: From: "Cedric Aoun" To: "'Mahadev'" , Jonathan Rosenberg Cc: Christian Huitema , Melinda Shore , midcom@ietf.org Subject: RE: [midcom] STUN over TCP? Date: Fri, 15 Mar 2002 13:10:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CC22.C210A670" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1CC22.C210A670 Content-Type: text/plain Mahadev, Good point, you are right about the sequencing problem. So TCP will be mandatory if we exceed the standard minimal MTU sizes on low bandwidth links. Thanks Cedric -----Original Message----- From: Mahadev [mailto:mahadev@cisco.com] Sent: Friday, March 15, 2002 11:19 AM To: Jonathan Rosenberg Cc: Aoun, Cedric [QPD:MA01:EXCH]; Christian Huitema; Melinda Shore; midcom@ietf.org Subject: Re: [midcom] STUN over TCP? > > > > > The issue with fragmentation and NATs is when 2 NATTed clients are > > trying to reach the same server and both datagrams are fragmented with > > the same fragment id, the STUN server won't be able to distinguish the 2 > > client messages. > > No; the problem as I understand it is that most nats won't refragment an > IP packet. So, they totally ignore fragment bits. So, the first fragment > will pass since it has the UDP header. But, the second one doesn't, and > will be dropped by the NAT since it doesn't match any UDP sessions in > progress through the NAT. Thats because the NAT thinks that there should > be a UDP or TCP header after IP, but there won't be anything. > This is not a big problem as such. There are NAT implementations which take care of fragmentation issue by storing state information from the first fragment. But then, this would work only if fragment 0 arrives first. -Mahadev ------_=_NextPart_001_01C1CC22.C210A670 Content-Type: text/html RE: [midcom] STUN over TCP?

Mahadev,
Good point, you are right about the sequencing problem.
So TCP will be mandatory if we exceed the standard minimal MTU sizes on low bandwidth links.
Thanks
Cedric

-----Original Message-----
From: Mahadev [mailto:mahadev@cisco.com]
Sent: Friday, March 15, 2002 11:19 AM
To: Jonathan Rosenberg
Cc: Aoun, Cedric [QPD:MA01:EXCH]; Christian Huitema; Melinda Shore;
midcom@ietf.org
Subject: Re: [midcom] STUN over TCP?


>
> >
> > The issue with fragmentation and NATs is when 2 NATTed clients are
> > trying to reach the same server and both datagrams are fragmented with
> > the same fragment id, the STUN server won't be able to distinguish the 2
> > client messages.
>
> No; the problem as I understand it is that most nats won't refragment an
> IP packet. So, they totally ignore fragment bits. So, the first fragment
> will pass since it has the UDP header. But, the second one doesn't, and
> will be dropped by the NAT since it doesn't match any UDP sessions in
> progress through the NAT. Thats because the NAT thinks that there should
> be a UDP or TCP header after IP, but there won't be anything.
>

This is not a big problem as such. There are NAT implementations which
take care of fragmentation issue by storing state information from the
first fragment. But then, this would work only if fragment 0 arrives
first.

-Mahadev

------_=_NextPart_001_01C1CC22.C210A670-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 15 10:27:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01491 for ; Fri, 15 Mar 2002 10:27:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00151 for midcom-archive@odin.ietf.org; Fri, 15 Mar 2002 10:27:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29719; Fri, 15 Mar 2002 10:19:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29694 for ; Fri, 15 Mar 2002 10:19:40 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01303 for ; Fri, 15 Mar 2002 10:19:37 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g2FFJ8T26432; Fri, 15 Mar 2002 07:19:09 -0800 (PST) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADF53896; Fri, 15 Mar 2002 07:16:49 -0800 (PST) Message-Id: <5.1.0.14.0.20020315102222.01330ec0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Mar 2002 10:23:02 -0500 To: Mahadev From: Melinda Shore Subject: Re: [midcom] STUN over TCP? Cc: midcom@ietf.org In-Reply-To: <3C91CAA8.A040347F@cisco.com> References: <3C91ABB0.2DC815FA@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:19 AM 3/15/02 -0800, Mahadev wrote: >This is not a big problem as such. There are NAT implementations which >take care of fragmentation issue by storing state information from the >first fragment. Is this commonly the case, or is it only done on high-end devices? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 15 11:15:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02984 for ; Fri, 15 Mar 2002 11:15:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04956 for midcom-archive@odin.ietf.org; Fri, 15 Mar 2002 11:15:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04872; Fri, 15 Mar 2002 11:14:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04841 for ; Fri, 15 Mar 2002 11:14:26 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02933 for ; Fri, 15 Mar 2002 11:14:23 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2FGDsG02844 for ; Fri, 15 Mar 2002 11:13:54 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 11:13:53 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102B18B@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: midcom@ietf.org Date: Fri, 15 Mar 2002 11:13:50 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] MIDCOM Protocol Information Elements Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a first rough cut at the information exchanges required between a MIDCOM Agent and a Middlebox. I've taken the requirements document as the basis for discussion. I'll summarize the discussion in terms of actual messages and parameters in another note. Requirement 2.1.1: authentication and authorization. There are two ways to read this requirement. One is that the necessary parameters for authentication and authorization must be included in each request made by a MIDCOM agent. An alternative is that the protocol supports an exchange of messages which sets up an association with a defined scope of authorization between the MIDCOM Agent and the Middlebox. In this second case, the association identifier must clearly be present or implicit in all subsequent exchanges between the two entities. --- Requirement 2.1.2: one MIDCOM agent related to multiple Middleboxes I believe this implies that a parameter must be present in each message coming from a Middlebox, identifying that Middlebox uniquely. --- Requirement 2.1.3: one Middlebox related to multiple MIDCOM Agents Similarly, a parameter must be present in each message coming from a MIDCOM Agent, identifying that MIDCOM Agent instance uniquely. --- Requirement 2.1.4: deterministic Middlebox behaviour when multiple MIDCOM Agents interact with it. One step in meeting this requirement is to allow the Middlebox to send messages indicating that particular requests have caused resource conflict. There is obviously dynamic behaviour implied by such messages, but this analysis is just about the information flows required. We can debate whether these messages should contain diagnostic material giving details about the conflict. --- Requirement 2.1.5: known and stable state The explanation of this requirement suggests that a request identifier parameter is needed for each request, that each request must have a reply, and that the reply must include the request identifier parameter as well as the result of the request. It seems to me the requirement also implies the need for a MIDCOM Agent to be able to audit the Middlebox state as it relates to requests made in the past by that Agent. The audit request might include parameters limiting the scope of the audit. The response includes a state parameter expressed as a sequence of rulesets. We may want to think about the additional parameters needed to support segmentation of the response. --- Requirement 2.1.6: Middlebox reporting state This and the previous requirement may imply a need for a Middlebox to send autonomous notifications to a MIDCOM Agent when it believes it is holding stale state. Such a notification would contain either a ruleset identifier or an actual ruleset, and should also contain a reason parameter indicating why the notification was generated. Clearly on receipt of such notifications the MIDCOM Agent must either allow the state to persist or clear it, but we have a choice whether to model the Agent's action as a response to the notification or simply as a new request if action is required. --- Requirement 2.1.7: autonomous reporting of conditions and autonomous actions The discussion of the previous requirement partly covered this one. The additional elements in this requirement are that the reported condition may not necessarily involve a ruleset. On the other hand, there is the additional need for an action parameter, composed of a field indicating the action taken by the Middlebox and a field indicating either the rulesets if any affected by the action or identifiers for those rulesets. --- Requirement 2.1.8: mutual authentication The discussion here is similar to that for 2.1.1, but in the reverse direction. --- Requirement 2.1.9: either entity can terminate a session It is not clear what terminating a session means. Does it mean that the MIDCOM Agent is no longer allowed to make requests and receive notifications without re-autheticating, or does it also mean that all state owned solely by that MIDCOM Agent is also cleared? I suspect it is the latter, given that the framework limits discussion to in-path Agents. In any event, the minimal messaging requirement is that each entity be able to send a message to the other indicating the end of the association. --- Requirement 2.1.10: MIDCOM Agent can determine success or failure of a request Messaging requirement covered by discussion of 2.1.5. --- Requirement 2.1.11: version interworking There seems to be agreement to include protocol version in each message, governing the content of that message. It is possible the initial message of a session should include an additional parameter listing the versions supported by the originator. If the protocol has identifiable options the initial message of the session in each direction should include a parameter indicating what options the message sender supports. --- Requirement 2.1.12: overlapping rulesets The behaviour required when overlapping rulesets are offered is out of scope of this analysis. However, there is clearly a requirement, addressed also in 2.1.4, to indicate a resource conflict in the response to a request. It may be that we are prepared to support three parameters in response to a request to install a ruleset: the ruleset installed and "owned by" the requesting MIDCOM Agent alone, the ruleset already installed and also "owned by" other MIDCOM Agents, and the ruleset denied because of resource conflict and policy regarding resolution of that conflict. Similarly, the response to a request to modify or remove a ruleset may contain two parameters, indicating the ruleset successfully changed or removed and the ruleset unchanged because it also has other owners and policy regarding resolution of the conflict indicated that it should be retained. All of these rulesets come about because of partitioning of the ruleset in the original request according to the different logical possibilities. --- Requirement 2.2.1: extensibility Information requirements are probably sufficiently covered by the discussion of 2.1.11. --- Requirement 2.2.2: control of multiple functions I believe this validates the framework's distinction between filter specs and action specs as separate components of a ruleset parameter. It also implies that a ruleset can be represented as a sequence of {filter spec, action spec} pairs, where the filter specs possibly overlap and the corresponding action specs may differ so long as they are not contradictory. --- Requirement 2.2.3: ruleset groups I believe this implies a requirement for a message from a MIDCOM Agent associating a ruleset group identifier with either a sequence of rulesets or a sequence of ruleset identifiers. It also implies that a message from a MIDCOM Agent requesting modification or removal may include a ruleset group identifier as an alternative to a ruleset or ruleset identifier. --- Requirement 2.2.4: ruleset lifetime extension This requires a message that a MIDCOM Agent can send, designating a ruleset or ruleset identifier, which carries the meaning that the lifetime of that ruleset should be extended. --- Requirement 2.2.5: action on unknown attributes This requires a sub-field within certain attributes indicating whether the attribute can be ignored if not understood or stops the request from being processed. I can't be more specific until I've done detailed work on the attributes which can be present in messages. It also implies that the responses to individual requests must identify components of the request which have caused failure or which have been ignored. --- Requirement 2.2.6: failure reasons A detailed work item. --- Requirement 2.2.7: multiple Agents working on the same ruleset See discussion of 2.1.4 and 2.1.12. --- Requirement 2.2.8: filter specs See 2.2.2 regarding filter specs as components of rulesets. Also requires a detailed specification of the possible content of a filter spec. At a minimum we need the basic 5-tuple with CHOOSE and ALL wildcards allowed for individual components. --- Requirement 2.2.9: matching parity ("oddity") Semantically this that it must be possible to add qualifier to the CHOOSE wildcard for a port, indicating whether it should be ODD or EVEN. --- Requirement 2.2.10: ranges of ports This adds another semantic qualifier for a CHOOSE-wildcarded port, indicating the number of ports to assign. The ODD/EVEN qulifier would be interpreted to apply to the first port of a range. --- Requirement 2.2.11: contradictory actions for sub-filters No new information requirement, given other points addressed above. --- I'll leave the 2.3.x requirements as an exercise for our security design. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 15 12:27:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05148 for ; Fri, 15 Mar 2002 12:27:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11551 for midcom-archive@odin.ietf.org; Fri, 15 Mar 2002 12:27:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11331; Fri, 15 Mar 2002 12:25:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11283 for ; Fri, 15 Mar 2002 12:25:17 -0500 (EST) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05044 for ; Fri, 15 Mar 2002 12:23:48 -0500 (EST) Received: from MDUFFY ([10.1.3.117]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6WDBGST; Fri, 15 Mar 2002 12:23:21 -0500 Message-Id: <3.0.5.32.20020315122036.009b1690@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 15 Mar 2002 12:20:36 -0500 To: Melinda Shore , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] STUN over TCP? In-Reply-To: <5.1.0.14.0.20020315102222.01330ec0@localhost> References: <3C91CAA8.A040347F@cisco.com> <3C91ABB0.2DC815FA@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org It certainly requires more complexity/expense in the NAT device. Therefore I think it would be safe to assume there are and will continue to be NATs out there that do not do this. -Mark At 10:23 AM 3/15/02 -0500, you wrote: >At 02:19 AM 3/15/02 -0800, Mahadev wrote: >>This is not a big problem as such. There are NAT implementations which >>take care of fragmentation issue by storing state information from the >>first fragment. > >Is this commonly the case, or is it only done on high-end devices? > >Melinda > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 15 14:04:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07327 for ; Fri, 15 Mar 2002 14:04:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19093 for midcom-archive@odin.ietf.org; Fri, 15 Mar 2002 14:04:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18971; Fri, 15 Mar 2002 14:03:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18945 for ; Fri, 15 Mar 2002 14:03:16 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07298 for ; Fri, 15 Mar 2002 14:03:12 -0500 (EST) Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g2FJ2iT14723; Fri, 15 Mar 2002 11:02:44 -0800 (PST) Received: from cisco.com (mahadev-u5.cisco.com [128.107.162.96]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ACG49069; Fri, 15 Mar 2002 10:55:56 -0800 (PST) Message-ID: <3C924552.2A72DCC3@cisco.com> Date: Fri, 15 Mar 2002 11:02:42 -0800 From: Mahadev Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: midcom@ietf.org Subject: Re: [midcom] STUN over TCP? References: <3C91ABB0.2DC815FA@dynamicsoft.com> <5.1.0.14.0.20020315102222.01330ec0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Yes, this very common irrespective of the device type (low/high end)... -Mahadev Melinda Shore wrote: > > At 02:19 AM 3/15/02 -0800, Mahadev wrote: > >This is not a big problem as such. There are NAT implementations which > >take care of fragmentation issue by storing state information from the > >first fragment. > > Is this commonly the case, or is it only done on high-end devices? > > Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Mar 16 15:42:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09136 for ; Sat, 16 Mar 2002 15:42:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04880 for midcom-archive@odin.ietf.org; Sat, 16 Mar 2002 15:43:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03710; Sat, 16 Mar 2002 15:19:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03679 for ; Sat, 16 Mar 2002 15:19:08 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08899 for ; Sat, 16 Mar 2002 15:19:03 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.120]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2GKJcTE007654; Sat, 16 Mar 2002 15:19:38 -0500 (EST) Message-ID: <3C93A89B.CAC73C89@dynamicsoft.com> Date: Sat, 16 Mar 2002 15:18:35 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mahadev CC: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] STUN over TCP? References: <3C924552.2A72DCC3@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Mahadev wrote: > > Yes, this very common irrespective of the device type (low/high end)... Sorry - "this" meaning "support for fragmentation" or "no support for fragmentation". I'd love to see some documented tests on residential devices to see fragmentation support. I'd bet its not good... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Mar 16 18:46:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11426 for ; Sat, 16 Mar 2002 18:46:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA11484 for midcom-archive@odin.ietf.org; Sat, 16 Mar 2002 18:46:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11343; Sat, 16 Mar 2002 18:40:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11313 for ; Sat, 16 Mar 2002 18:40:50 -0500 (EST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11378 for ; Sat, 16 Mar 2002 18:40:46 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 16 Mar 2002 15:40:20 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 16 Mar 2002 15:40:20 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 16 Mar 2002 15:40:19 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 16 Mar 2002 15:40:19 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Sat, 16 Mar 2002 15:37:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN over TCP? Date: Sat, 16 Mar 2002 15:37:15 -0800 Message-ID: Thread-Topic: [midcom] STUN over TCP? Thread-Index: AcHNKYSN9YMivcVhS8+jWu0caM8wMgAGkTMA From: "Christian Huitema" To: "Jonathan Rosenberg" , "Mahadev" Cc: "Melinda Shore" , X-OriginalArrivalTime: 16 Mar 2002 23:37:15.0444 (UTC) FILETIME=[81090740:01C1CD43] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA11314 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Anecdotal evidence from the field is that no, it is no good. There is a significant fraction of deployed NAT that just drop any fragmented packet. -- Christian Huitema > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, March 16, 2002 12:19 PM > To: Mahadev > Cc: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] STUN over TCP? > > > > Mahadev wrote: > > > > Yes, this very common irrespective of the device type (low/high end)... > > Sorry - "this" meaning "support for fragmentation" or "no support for > fragmentation". I'd love to see some documented tests on residential > devices to see fragmentation support. I'd bet its not good... > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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 daemon@optimus.ietf.org Sun Mar 17 10:00:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01972 for ; Sun, 17 Mar 2002 10:00:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA23362 for midcom-archive@odin.ietf.org; Sun, 17 Mar 2002 10:00:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22861; Sun, 17 Mar 2002 09:48:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22826 for ; Sun, 17 Mar 2002 09:48:18 -0500 (EST) Received: from localhost ([61.37.141.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01887 for ; Sun, 17 Mar 2002 09:48:13 -0500 (EST) Message-Id: <200203171448.JAA01887@ietf.org> Reply-To: test@test.com From: test To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 17 Mar 2002 23:50:48 +0900 Subject: [midcom] 아직도 과속위반 범칙금을 내고 계십니까? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 아이캐어프리 위성핸즈프리 한정 10대 파격세일 안내


허락없이 메일을 드려 죄송합니다. E-mail 주소는 게시판 등 인터넷을 통해 알게 되었습니다. 메일주소외에는 어떤 정보도 가지고 있지 않습니다. 본 메일은 정보통신망에 관한 법률 제 50조에 의거하여 [광고]메일임을 밝힙니다. 수신을 원치 않으시면 수신거부를 클릭하여 주십시요 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Mar 17 11:41:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05097 for ; Sun, 17 Mar 2002 11:41:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27886 for midcom-archive@odin.ietf.org; Sun, 17 Mar 2002 11:41:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27786; Sun, 17 Mar 2002 11:37:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27755 for ; Sun, 17 Mar 2002 11:37:28 -0500 (EST) Received: from localhost ([211.218.102.172]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04972 for ; Sun, 17 Mar 2002 11:37:22 -0500 (EST) Message-Id: <200203171637.LAA04972@ietf.org> Reply-To: test@test.com From: test To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 18 Mar 2002 01:40:30 +0900 Subject: [midcom] *成人廣告* 전국의 유흥업소 안내도 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Untitled Document

다시 메일 수신을 희망하지 않으시면 수신거부 버튼을 눌러주세요.

 
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Mar 17 13:38:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08200 for ; Sun, 17 Mar 2002 13:38:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03103 for midcom-archive@odin.ietf.org; Sun, 17 Mar 2002 13:38:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03026; Sun, 17 Mar 2002 13:34:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03000 for ; Sun, 17 Mar 2002 13:34:34 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08178 for ; Sun, 17 Mar 2002 13:34:30 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2HIXei11884; Sun, 17 Mar 2002 19:33:40 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Mar 2002 18:33:49 -0000 Message-ID: From: "Cedric Aoun" To: "'Jonathan Rosenberg'" , "'Mahadev'" , Melinda Shore Cc: "'midcom@ietf.org'" Subject: RE: [midcom] STUN over TCP? Date: Sun, 17 Mar 2002 18:33:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CDE2.4621AE80" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1CDE2.4621AE80 Content-Type: text/plain I thought of this again, since there is a reply to the server, in case the first fragment of the packet doesn't reach the NAT first; the NAT will drop all the packet's fragments and the server will not get a reply. The result will be that the server will retransmit again, and at some point the fragments will reach the NAT in the right sequence. The sequencing problem occured because the routing changed in the network, this doesn't happen all the time. I know that some NATs work with fragmentation (but I don't know if all of them do like the 100$ residential NATs)when the fragment id is unique given the remote address (in this case the STUN server) and the NAT address. Any way the current document doesn't impose the usage of TCP so I don't find any issue with it, but we probably want to have couple of lines to mention the real problem that we have with NATs and fragmentation and that it is not applicable to all NATs.In case the NAT supports fragmentation the STUN client is configured to use UDP. Cedric -----Original Message----- From: Mahadev [mailto:mahadev@cisco.com] Sent: Friday, March 15, 2002 8:03 PM To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] STUN over TCP? Yes, this very common irrespective of the device type (low/high end)... -Mahadev Melinda Shore wrote: > > At 02:19 AM 3/15/02 -0800, Mahadev wrote: > >This is not a big problem as such. There are NAT implementations which > >take care of fragmentation issue by storing state information from the > >first fragment. > > Is this commonly the case, or is it only done on high-end devices? > > Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1CDE2.4621AE80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] STUN over TCP?

I thought of this again, since there is a reply to = the server, in case the first fragment of the packet doesn't reach the = NAT first; the NAT will drop all the packet's fragments and the server = will not get a reply. The result will be that the server will = retransmit again, and at some point the fragments will reach the NAT in = the right sequence.

The sequencing problem occured because the routing = changed in the network, this doesn't happen all the time.

I know that some NATs work with fragmentation (but I = don't know if all of them do like the 100$ residential NATs)when the = fragment id is unique given the remote address (in this case the STUN = server) and the NAT address.

Any way the current document doesn't impose the usage = of TCP so I don't find any issue with it, but we probably want to have = couple of lines to mention the real problem that we have with NATs and = fragmentation and that it is not applicable to all NATs.In case the NAT = supports fragmentation the STUN client is configured to use = UDP.

Cedric 

-----Original Message-----
From: Mahadev [mailto:mahadev@cisco.com]
Sent: Friday, March 15, 2002 8:03 PM
To: Melinda Shore
Cc: midcom@ietf.org
Subject: Re: [midcom] STUN over TCP?


Yes, this very common irrespective of the device type = (low/high end)...

-Mahadev

Melinda Shore wrote:
>
> At 02:19 AM 3/15/02 -0800, Mahadev = wrote:
> >This is not a big problem as such. There = are NAT implementations which
> >take care of fragmentation issue by storing = state information from the
> >first fragment.
>
> Is this commonly the case, or is it only done = on high-end devices?
>
> Melinda

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

------_=_NextPart_001_01C1CDE2.4621AE80-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Mar 17 13:54:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08454 for ; Sun, 17 Mar 2002 13:54:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03553 for midcom-archive@odin.ietf.org; Sun, 17 Mar 2002 13:54:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03514; Sun, 17 Mar 2002 13:53:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03485 for ; Sun, 17 Mar 2002 13:53:23 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08448 for ; Sun, 17 Mar 2002 13:53:20 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2HIqii12059; Sun, 17 Mar 2002 19:52:44 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Mar 2002 18:52:53 -0000 Message-ID: From: "Cedric Aoun" To: "'Jonathan Rosenberg'" Cc: midcom@ietf.org Date: Sun, 17 Mar 2002 18:52:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CDE4.F02AD120" Subject: [midcom] some comments on stun 01 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1CDE4.F02AD120 Content-Type: text/plain; charset="iso-8859-1" Hi, I have some comments on stun-01 Page 7, "STUN servers are discovered through DNS SRV records [2], and is generally assumed that the client is configured with the domain to use to find the STUN server. " I prefer saying STUN servers could/might be discovered, I think we should clearly decouple STUN from the ability to send DNS SRV record queries to find the STUN server. Section 9.2 page 17 "It then starts a timer with a value of T seconds. When this timer fires, the client sends a request to server A, with the "change IP" and "change port" flags set. If the binding is still active, this response should be received through all nat types." This bind expiry timer discovery method works only for NATs that are not full cone NAT. When the NAT is full cone, it won't work since we have refreshed the bind by sending out the message to the original server I suggest adding a timer in the STUN query when the NAT is found full cone. This counter will be used to say after how many secs the server should reply back. Section 12, page 23; Cullen mentioned this issue already where a specific protocol name will need to be assigned when used in DNS SRV records, Jonathan provided already the name.The next version of the draft will need to incoeporate the "nat-stun-port" page 24, section 13.2 "STUN can also help facilitate the introduction of midcom. As midcom- capable NATs are deployed, applications will, instead of using STUN (which also resides at the application layer), first allocate an address binding using midcom. However, it is a well-known limitation of midcom that it only works when the agent knows the middleboxes through which its traffic will flow. Once bindings have been allocated from those middleboxes, a STUN detection procedure can validate that there are no additional middleboxes on the path from the public Internet to the client. If this is the case, the application can continue operation using the address bindings allocated from midcom. If it is not the case, STUN provides a mechanism for self-address fixing through the remaining midcom- unaware middlboxes. Thus, STUN provides a way to help transition to full midcom-aware networks." This is only valid only if a peer to peer STUN messaging is launched to discover if there are no other NATs traversed by the Media flow, this is actually one of the issues of STUN, in case a realm has several NATs on its boundaries the STUN stream (between the client and the STUN server) could be sent to a different NAT than the media stream. I think that we should have this stated in a STUN applicability statement. page 27, section 13.6 "The result of this lack of standardization has been a proliferation of devices whose behavior is highly predictable, extremely variable, and uncontrollable" Did you originally mean highly unpredictable? Cedric Cedric Aoun Nortel Networks France ------_=_NextPart_001_01C1CDE4.F02AD120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable some comments on stun 01

Hi,
I have some comments on = stun-01

Page 7,
"STUN servers are discovered = through DNS SRV records [2], and is generally
 assumed that the client is = configured with the domain to use to find
   the STUN server. = "
I prefer saying STUN servers = could/might be discovered, I think we should clearly decouple STUN =
from the ability to send DNS SRV = record queries to find the STUN server.

Section 9.2 page 17
"It then starts a timer with = a
   value of T seconds. When = this timer fires, the client sends a request
   to server A, with the = "change IP" and "change port" flags set. If = the
   binding is still active, = this response should be received through all
   nat types."

This bind expiry timer discovery = method works only for NATs that are not full cone NAT. When the NAT is = full cone,
it won't work since we have refreshed = the bind by sending out the message to the original server I suggest = adding a
timer in the STUN query when the NAT = is found full cone. This counter will be used to say after how many = secs
 the server should reply = back.

Section 12, page 23; Cullen mentioned = this issue already where a specific protocol name will need to be = assigned
when used in DNS SRV records, = Jonathan provided already the name.The next version of the draft will = need to incoeporate the "nat-stun-port"

page 24, section 13.2
"STUN can also help facilitate = the introduction of midcom. As midcom-
   capable NATs are = deployed, applications will, instead of using STUN
   (which also resides at = the application layer), first allocate an
   address binding using = midcom. However, it is a well-known limitation
   of midcom that it only = works when the agent knows the middleboxes
   through which its = traffic will flow. Once bindings have been
   allocated from those = middleboxes, a STUN detection procedure can
   validate that there are = no additional middleboxes on the path from
   the public Internet to = the client. If this is the case, the
   application can continue = operation using the address bindings
   allocated from midcom. = If it is not the case, STUN provides a
   mechanism for = self-address fixing through the remaining midcom-
   unaware middlboxes. = Thus, STUN provides a way to help transition to
   full midcom-aware = networks."

This is only valid only if a peer to = peer STUN messaging is launched to discover if there are no
other NATs traversed by the Media = flow, this is actually one of the issues of STUN, in case a realm =
has several NATs on its boundaries = the STUN stream (between the client and the STUN server)
could be sent to a different NAT than = the media stream.
I think that we should have this = stated in a STUN applicability statement.

page 27, section 13.6
"The result of this lack of = standardization has been a
   proliferation of devices = whose behavior is highly predictable,
   extremely variable, and = uncontrollable"
Did you originally mean highly = unpredictable?

Cedric

Cedric = Aoun
Nortel = Networks
France
<mailto:cedric.aoun@nortel= networks.com>

------_=_NextPart_001_01C1CDE4.F02AD120-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 18 09:21:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05764 for ; Mon, 18 Mar 2002 09:21:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05322 for midcom-archive@odin.ietf.org; Mon, 18 Mar 2002 09:21:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05125; Mon, 18 Mar 2002 09:18:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05083 for ; Mon, 18 Mar 2002 09:18:55 -0500 (EST) Received: from localhost ([61.73.49.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05732 for ; Mon, 18 Mar 2002 09:18:48 -0500 (EST) Message-Id: <200203181418.JAA05732@ietf.org> Reply-To: ok3624@korea.com From: 이사역경매 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 18 Mar 2002 23:17:17 +0900 Subject: [midcom] (no subject) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 18 11:11:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08510 for ; Mon, 18 Mar 2002 11:11:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12652 for midcom-archive@odin.ietf.org; Mon, 18 Mar 2002 11:11:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12527; Mon, 18 Mar 2002 11:08:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12443 for ; Mon, 18 Mar 2002 11:08:38 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08361 for ; Mon, 18 Mar 2002 11:08:32 -0500 (EST) Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2IG85d17662; Mon, 18 Mar 2002 08:08:05 -0800 (PST) Received: from mahadev-w2k.cisco.com (sjc-vpn2-390.cisco.com [10.21.113.134]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ACH15778; Mon, 18 Mar 2002 08:00:14 -0800 (PST) Message-Id: <4.3.2.7.2.20020318073451.00af4b08@mira-sjcd-2.cisco.com> X-Sender: mahadev@mira-sjcd-2.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 08:04:25 -0800 To: Jonathan Rosenberg From: Mahadev Somasundaram Subject: Re: [midcom] STUN over TCP? Cc: Melinda Shore , midcom@ietf.org In-Reply-To: <3C93A89B.CAC73C89@dynamicsoft.com> References: <3C924552.2A72DCC3@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 03:18 PM 3/16/2002 -0500, Jonathan Rosenberg wrote: >Mahadev wrote: > > > > Yes, this very common irrespective of the device type (low/high end)... > >Sorry - "this" meaning "support for fragmentation" or "no support for >fragmentation". I'd love to see some documented tests on residential meant "support for fragmentation". _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 18 11:42:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10396 for ; Mon, 18 Mar 2002 11:42:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15253 for midcom-archive@odin.ietf.org; Mon, 18 Mar 2002 11:42:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14903; Mon, 18 Mar 2002 11:35:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14876 for ; Mon, 18 Mar 2002 11:35:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10018 for ; Mon, 18 Mar 2002 11:35:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2IGZfTE009148; Mon, 18 Mar 2002 11:35:43 -0500 (EST) Message-ID: <3C96171E.4BA57CB5@dynamicsoft.com> Date: Mon, 18 Mar 2002 11:34:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cedric Aoun CC: "'Mahadev'" , Melinda Shore , "'midcom@ietf.org'" Subject: Re: [midcom] STUN over TCP? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Cedric Aoun wrote: > > Any way the current document doesn't impose the usage of TCP so I don't > find any issue with it, but we probably want to have couple of lines to > mention the real problem that we have with NATs and fragmentation and > that it is not applicable to all NATs.In case the NAT supports > fragmentation the STUN client is configured to use UDP. I will mention the motivation for TCP. However, the big question is how the client knows that its nat supports fragmentation? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 18 12:12:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11870 for ; Mon, 18 Mar 2002 12:12:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18900 for midcom-archive@odin.ietf.org; Mon, 18 Mar 2002 12:12:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18528; Mon, 18 Mar 2002 12:10:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18499 for ; Mon, 18 Mar 2002 12:10:22 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11743 for ; Mon, 18 Mar 2002 12:10:17 -0500 (EST) Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2IH9pd09195; Mon, 18 Mar 2002 09:09:51 -0800 (PST) Received: from mahadev-w2k.cisco.com (sjc-vpn2-390.cisco.com [10.21.113.134]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ACH16960; Mon, 18 Mar 2002 09:02:47 -0800 (PST) Message-Id: <4.3.2.7.2.20020318085940.00b26bb8@mira-sjcd-2.cisco.com> X-Sender: mahadev@mira-sjcd-2.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 09:09:44 -0800 To: "Christian Huitema" From: Mahadev Somasundaram Subject: RE: [midcom] STUN over TCP? Cc: "Jonathan Rosenberg" , "Melinda Shore" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org the question here is, there are significant NATs which support fragmentation need to be considered... -Mahadev At 03:37 PM 3/16/2002 -0800, Christian Huitema wrote: >Anecdotal evidence from the field is that no, it is no good. There is a >significant fraction of deployed NAT that just drop any fragmented >packet. > >-- Christian Huitema > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Saturday, March 16, 2002 12:19 PM > > To: Mahadev > > Cc: Melinda Shore; midcom@ietf.org > > Subject: Re: [midcom] STUN over TCP? > > > > > > > > Mahadev wrote: > > > > > > Yes, this very common irrespective of the device type (low/high >end)... > > > > Sorry - "this" meaning "support for fragmentation" or "no support for > > fragmentation". I'd love to see some documented tests on residential > > devices to see fragmentation support. I'd bet its not good... > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > 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 daemon@ns.ietf.org Mon Mar 18 15:53:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19734 for ; Mon, 18 Mar 2002 15:53:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05466 for midcom-archive@odin.ietf.org; Mon, 18 Mar 2002 15:53:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05298; Mon, 18 Mar 2002 15:48:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05266 for ; Mon, 18 Mar 2002 15:48:55 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19548 for ; Mon, 18 Mar 2002 15:48:50 -0500 (EST) Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g2IKmNT12827; Mon, 18 Mar 2002 12:48:23 -0800 (PST) Received: from mahadev-w2k.cisco.com (sjc-vpn1-52.cisco.com [10.21.96.52]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ACH23538; Mon, 18 Mar 2002 12:41:19 -0800 (PST) Message-Id: <4.3.2.7.2.20020318115326.00b46fa0@mira-sjcd-2.cisco.com> X-Sender: mahadev@mira-sjcd-2.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 12:38:33 -0800 To: Jonathan Rosenberg From: Mahadev Somasundaram Subject: Re: [midcom] STUN over TCP? Cc: Cedric Aoun , Melinda Shore , "'midcom@ietf.org'" In-Reply-To: <3C96171E.4BA57CB5@dynamicsoft.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 11:34 AM 3/18/2002 -0500, Jonathan Rosenberg wrote: >Cedric Aoun wrote: > > > > Any way the current document doesn't impose the usage of TCP so I don't > > find any issue with it, but we probably want to have couple of lines to > > mention the real problem that we have with NATs and fragmentation and > > that it is not applicable to all NATs.In case the NAT supports > > fragmentation the STUN client is configured to use UDP. > >I will mention the motivation for TCP. However, the big question is how >the client knows that its nat supports fragmentation? one way to detect could be by sending large size packet (~5000bytes) and wait for the server reply. If the reply from server reaches the client, then the NAT supports fragmentation. If there is no reply, the reason may not be due to NAT fragmentation support (like packet loss, fragment out-of-sequence). So, the client retransmits with the interval time of 1 second and doubles with every try. After 3 tries, with the elapsed time of 7 seconds, client gives up and assumes that the NAT does not support fragmentation. this could be done during the NAT discovery phase... -Mahadev _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Mar 18 18:03:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24437 for ; Mon, 18 Mar 2002 18:03:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17282 for midcom-archive@odin.ietf.org; Mon, 18 Mar 2002 18:03:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15955; Mon, 18 Mar 2002 17:51:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15928 for ; Mon, 18 Mar 2002 17:51:07 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24055 for ; Mon, 18 Mar 2002 17:51:02 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2IMoad08949 for ; Mon, 18 Mar 2002 14:50:36 -0800 (PST) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACJ23613; Mon, 18 Mar 2002 14:50:47 -0800 (PST) From: "Cullen Jennings" To: Subject: RE: [midcom] STUN over TCP? Date: Mon, 18 Mar 2002 14:54:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3C96171E.4BA57CB5@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit If the STUN server had a flag to send a really big packet, it is likely that it will be fragmented and you will find out what your NAT does. I am mostly joking here - I don't think this is the right path but it is an possible option. Not to mention this would make a STUN server into an amplifier from a DDOS point of view. Cullen -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: Monday, March 18, 2002 8:35 AM To: Cedric Aoun Cc: 'Mahadev'; Melinda Shore; 'midcom@ietf.org' Subject: Re: [midcom] STUN over TCP? Cedric Aoun wrote: > > Any way the current document doesn't impose the usage of TCP so I don't > find any issue with it, but we probably want to have couple of lines to > mention the real problem that we have with NATs and fragmentation and > that it is not applicable to all NATs.In case the NAT supports > fragmentation the STUN client is configured to use UDP. I will mention the motivation for TCP. However, the big question is how the client knows that its nat supports fragmentation? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 daemon@ns.ietf.org Mon Mar 18 18:56:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26243 for ; Mon, 18 Mar 2002 18:56:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21562 for midcom-archive@odin.ietf.org; Mon, 18 Mar 2002 18:56:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21444; Mon, 18 Mar 2002 18:54:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21413 for ; Mon, 18 Mar 2002 18:54:55 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26195 for ; Mon, 18 Mar 2002 18:54:52 -0500 (EST) Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2INsOh14548; Mon, 18 Mar 2002 15:54:24 -0800 (PST) Received: from mahadev-w2k.cisco.com (sjc-vpn1-653.cisco.com [10.21.98.141]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ACH28767; Mon, 18 Mar 2002 15:47:20 -0800 (PST) Message-Id: <4.3.2.7.2.20020318155137.00b40ef8@mira-sjcd-2.cisco.com> X-Sender: mahadev@mira-sjcd-2.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 15:55:02 -0800 To: jdrosen@dynamicsoft.com, cedric.aoun@nortelnetworks.com, midcom@ietf.org From: Mahadev Somasundaram Subject: Re: [midcom] STUN over TCP? Cc: Jonathan Rosenberg , Cedric Aoun , Melinda Shore In-Reply-To: <4.3.2.7.2.20020318115326.00b46fa0@mira-sjcd-2.cisco.com> References: <3C96171E.4BA57CB5@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:38 PM 3/18/2002 -0800, Mahadev Somasundaram wrote: >At 11:34 AM 3/18/2002 -0500, Jonathan Rosenberg wrote: > > >>Cedric Aoun wrote: >> > >> > Any way the current document doesn't impose the usage of TCP so I don't >> > find any issue with it, but we probably want to have couple of lines to >> > mention the real problem that we have with NATs and fragmentation and >> > that it is not applicable to all NATs.In case the NAT supports >> > fragmentation the STUN client is configured to use UDP. >> >>I will mention the motivation for TCP. However, the big question is how >>the client knows that its nat supports fragmentation? >one way to detect could be by sending large size packet (~5000bytes) and >wait for the server reply. If the reply from server reaches the client, >then the NAT supports should be read "requesting to send" instead of "sending" thanks, -Mahadev >fragmentation. If there is no reply, the reason may not be due to NAT >fragmentation support (like packet loss, fragment out-of-sequence). So, >the client retransmits with the interval time of 1 second and doubles with >every try. After 3 tries, with the elapsed time of 7 seconds, client gives >up and assumes that the NAT does not support fragmentation. > >this could be done during the NAT discovery phase... > >-Mahadev > > >_______________________________________________ >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 daemon@ns.ietf.org Mon Mar 18 22:08:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01275 for ; Mon, 18 Mar 2002 22:08:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA01737 for midcom-archive@odin.ietf.org; Mon, 18 Mar 2002 22:08:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01664; Mon, 18 Mar 2002 22:06:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01636 for ; Mon, 18 Mar 2002 22:06:29 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01220 for ; Mon, 18 Mar 2002 22:06:24 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2J35lh19365; Tue, 19 Mar 2002 04:05:47 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2J35Ea14191; Tue, 19 Mar 2002 03:05:14 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 03:05:46 -0000 Message-ID: From: "Cedric Aoun" To: "'Mahadev Somasundaram'" , jdrosen@dynamicsoft.com, midcom@ietf.org Cc: Jonathan Rosenberg , Melinda Shore Subject: RE: [midcom] STUN over TCP? Date: Tue, 19 Mar 2002 03:05:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CEF2.F5FB5020" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1CEF2.F5FB5020 Content-Type: text/plain Mahadev, This is a good way to discover the fragmentation support on the NAT. we could use a packet size of more than 1500 bytes. -----Original Message----- From: Mahadev Somasundaram [mailto:mahadev@cisco.com] Sent: Tuesday, March 19, 2002 12:55 AM To: jdrosen@dynamicsoft.com; Aoun, Cedric [QPD:MA01:EXCH]; midcom@ietf.org Cc: Jonathan Rosenberg; Aoun, Cedric [QPD:MA01:EXCH]; Melinda Shore Subject: Re: [midcom] STUN over TCP? At 12:38 PM 3/18/2002 -0800, Mahadev Somasundaram wrote: >At 11:34 AM 3/18/2002 -0500, Jonathan Rosenberg wrote: > > >>Cedric Aoun wrote: >> > >> > Any way the current document doesn't impose the usage of TCP so I don't >> > find any issue with it, but we probably want to have couple of lines to >> > mention the real problem that we have with NATs and fragmentation and >> > that it is not applicable to all NATs.In case the NAT supports >> > fragmentation the STUN client is configured to use UDP. >> >>I will mention the motivation for TCP. However, the big question is how >>the client knows that its nat supports fragmentation? >one way to detect could be by sending large size packet (~5000bytes) and >wait for the server reply. If the reply from server reaches the client, >then the NAT supports should be read "requesting to send" instead of "sending" thanks, -Mahadev >fragmentation. If there is no reply, the reason may not be due to NAT >fragmentation support (like packet loss, fragment out-of-sequence). So, >the client retransmits with the interval time of 1 second and doubles with >every try. After 3 tries, with the elapsed time of 7 seconds, client gives >up and assumes that the NAT does not support fragmentation. > >this could be done during the NAT discovery phase... > >-Mahadev > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1CEF2.F5FB5020 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] STUN over TCP?

Mahadev,
This is a good way to discover the fragmentation = support on the NAT. we could use a packet size of more than 1500 = bytes.

-----Original Message-----
From: Mahadev Somasundaram [mailto:mahadev@cisco.com]
Sent: Tuesday, March 19, 2002 12:55 AM
To: jdrosen@dynamicsoft.com; Aoun, Cedric = [QPD:MA01:EXCH];
midcom@ietf.org
Cc: Jonathan Rosenberg; Aoun, Cedric = [QPD:MA01:EXCH]; Melinda Shore
Subject: Re: [midcom] STUN over TCP?


At 12:38 PM 3/18/2002 -0800, Mahadev Somasundaram = wrote:
>At 11:34 AM 3/18/2002 -0500, Jonathan Rosenberg = wrote:
>
>
>>Cedric Aoun wrote:
>> >
>> > Any way the current document doesn't = impose the usage of TCP so I don't
>> > find any issue with it, but we = probably want to have couple of lines to
>> > mention the real problem that we have = with NATs and fragmentation and
>> > that it is not applicable to all = NATs.In case the NAT supports
>> > fragmentation the STUN client is = configured to use UDP.
>>
>>I will mention the motivation for TCP. = However, the big question is how
>>the client knows that its nat supports = fragmentation?
>one way to detect could be by sending large size = packet (~5000bytes) and
>wait for the server reply. If the  reply = from server reaches the client,
>then the NAT supports

should be read "requesting to send" instead = of "sending"

thanks,
-Mahadev

>fragmentation. If there is no reply, the reason = may not be due to NAT
>fragmentation support (like packet loss, = fragment out-of-sequence). So,
>the client retransmits with the interval time of = 1 second and doubles with
>every try. After 3 tries, with the elapsed time = of 7 seconds, client gives
>up and assumes that the NAT does not support = fragmentation.
>
>this could be done during the NAT discovery = phase...
>
>-Mahadev
>
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C1CEF2.F5FB5020-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Mar 19 00:25:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06052 for ; Tue, 19 Mar 2002 00:25:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA07829 for midcom-archive@odin.ietf.org; Tue, 19 Mar 2002 00:25:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07515; Tue, 19 Mar 2002 00:17:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07486 for ; Tue, 19 Mar 2002 00:17:45 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05630 for ; Tue, 19 Mar 2002 00:17:43 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2J5I2TE010188; Tue, 19 Mar 2002 00:18:03 -0500 (EST) Message-ID: <3C96C9CC.7F2C4783@dynamicsoft.com> Date: Tue, 19 Mar 2002 00:17:00 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mahadev Somasundaram CC: Cedric Aoun , Melinda Shore , "'midcom@ietf.org'" Subject: Re: [midcom] STUN over TCP? References: <4.3.2.7.2.20020318115326.00b46fa0@mira-sjcd-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Mahadev Somasundaram wrote: > > At 11:34 AM 3/18/2002 -0500, Jonathan Rosenberg wrote: > > >Cedric Aoun wrote: > > > > > > Any way the current document doesn't impose the usage of TCP so I > don't > > > find any issue with it, but we probably want to have couple of lines > to > > > mention the real problem that we have with NATs and fragmentation > and > > > that it is not applicable to all NATs.In case the NAT supports > > > fragmentation the STUN client is configured to use UDP. > > > >I will mention the motivation for TCP. However, the big question is how > >the client knows that its nat supports fragmentation? > one way to detect could be by sending large size packet (~5000bytes) and > > wait for the server reply. I guess you are assuming that we would add a feature to STUN to allow you to send large requests that trigger large responses. I really don't like this approach. Its correctness is dependent on a lot of other variables in the system. As you say, no reply can occur for MANY reasons. Assuming its because of fragmentation seems risky. What is so bad with TCP? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Mar 19 08:56:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21849 for ; Tue, 19 Mar 2002 08:56:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16053 for midcom-archive@odin.ietf.org; Tue, 19 Mar 2002 08:56:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15922; Tue, 19 Mar 2002 08:54:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15893 for ; Tue, 19 Mar 2002 08:53:58 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21808 for ; Tue, 19 Mar 2002 08:53:55 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g2JDrRQ77774 for ; Tue, 19 Mar 2002 14:53:27 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA06870 for ; Tue, 19 Mar 2002 14:53:26 +0100 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 115E0D59B for ; Tue, 19 Mar 2002 14:53:25 +0100 (CET) Message-ID: <3C9742D3.8010201@ccrle.nec.de> Date: Tue, 19 Mar 2002 14:53:23 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: midcom@ietf.org Subject: Re: [midcom] Protocol development References: <5.1.0.14.0.20020313090930.00aa0140@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > In order to 1) avoid that, 2) make progress while > the protocol evaluation is underway, and 3) try to > maintain focus on the meat of the problem, I'd like > to suggest that we start developing a working document > (i.e. not necessarily for publication) that lays out > the semantics of midcom requests and midcom responses. > Thoughts/opinions/comments/etc. welcome. There have been a lot of calls for doing the real work on the protocol, as far as I know. But there haven't been so much technical discussions, though there are some drafts for a protocol. These drafts define a semantic and a syntax for a protocol. I think there is no need to stuck on the syntax, but the work that has been made is a good starting point to see where the problems and possibly solutions are. Martin > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Mar 19 12:04:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27295 for ; Tue, 19 Mar 2002 12:04:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02264 for midcom-archive@odin.ietf.org; Tue, 19 Mar 2002 12:04:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01786; Tue, 19 Mar 2002 12:01:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01743 for ; Tue, 19 Mar 2002 12:01:36 -0500 (EST) Received: from hatmail.com ([211.220.54.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27179 for ; Tue, 19 Mar 2002 12:01:31 -0500 (EST) Message-Id: <200203191701.MAA27179@ietf.org> Reply-To: price2@hatmail.com From: price2 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 20 Mar 2002 01:57:44 +0900 Subject: [midcom] ▲7만원▲ 다음우표제/중복메일 걱정NO! I광*고I Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org


안녕하십니까, 최고의 메일데이터를 최고 저렴한 가격인 7만원에 드립니다.
저렴하고 중복없다면서 싸게파는 판매자에게 사기당한 경험이 많지요?
저에게 메일데이터를 구입하시면 정말 제게 고마워하실 것입니다.
(최근 3천만개가 중복없다면서 판매하는 것을 확인결과 중복이 많았습니다)

중복이 하나도 없는 메일데이터의 갯수는 616만 7906개입니다. (한메일 없음)
너무 저렴해서 의심이 가십니까? 신용 확실합니다. 절대 거짓정보가 아닙니다.
각 사이트의 공개게시판에서 임의추출한 것이므로 귀하의 신용정보와 아무런 연관이 없습니다.

여러 프로그램으로 추출하여 작업한 메일데이터의 특징은 다음과 같습니다.

● 다음우표제 - 철저한 작업으로 제 메일데이터에는 한메일이 없습니다.
                          다음우표제가 이제 실시된다고 합니다. 한메일로는 메일이 보내지지 않습니다.
                          한메일로 굳이 보낼필요가 있겠습니까? 확실한 마케팅이 필요합니다!
● 가격 - 요즘 600만개를 62만원에 판매하는 사람을 보았습니다. 그리고 메일 하나당 1원씩
               판매하는 사람들도 있는 등 엄청나게 비싼가격에 판매하고 있습니다.
               하지만 제가 제공하는 메일데이터는 훨씬 질도 우수하면서(정리,중복,다음우표제)
               가격은 몇십분의 일로 저렴합니다. 정말 확실하지 않습니까?
● 중복메일 - 프로그램으로 철저히 작업하여 중복메일이 없습니다.
                  중복메일이 없다면서 메일데이터를 판매하는 사람들 많이 보셨지요?
                  제가 거의 사본결과 중복메일이 없는 경우는 한번도 없었습니다.
                  초기에는 이강일이라는 분이 판매했었죠. 중복메일 엄청 많았습니다.
                  이미영이라는 분도 최근 판매하는 메일도 사본결과 중복메일 투성이었습니다.
                  아마 곤욕 치르신 분들 많으실 겁니다. 비싼돈주고 후회도 많이 하셨죠?
                  그 외 몇 번 메일데이터를 구입한 결과 중복메일 투성인 것밖에 없었습니다.
                  메일판매자들은 절대 좋은 메일을 판매하려 하지 않을 것입니다. 왜냐하면,
                  그 메일데이터를 판매하기에는 너무 아까우니까요. 자신만 쓰고 싶어하니까요.
                  하지만 저는 정말 양질의 메일데이터를 제공합니다.
                  아직도 사기를 당하십니까? 이젠 그런 걱정 일체 하지 마십시오.
● 정리 - 요즘 판매하는 메일을 사본결과 정리조차 되어있지 않더군요.
                하지만 제 메일은 알파벳 순으로 정리까지 잘 되어 있습니다.
● 편리 - 정확히 20만개씩 나누었습니다.
● 호환 - 한줄에 하나씩, 그리고 TXT로 저장되어 있습니다.
                어떤 프로그램과도 호환가능합니다.
● 사기? - 입금하시기 전에 자료를 다운받게 해드립니다.
● 각종 당부사항을 알려드립니다.
● 인터넷으로 부자가 되는 방법들을 알려드립니다.

※ 건전한 용도로 쓰지 않는 분에게 판매하지 않습니다.

price.ox.ro   price.ce.ro   price.pe.ky
(구입하시려면 위 사이트에 접속해 주십시오)

접속이 느리면 price2.(ce.ro / pe.ky / ox.ro)로 접속해 주십시오.
공지없이 연결되지 않으면 price3, price4, 5...이렇게 접속하시면 됩니다.
이유없이 사이트를 비방, 방해하는 사람에게 손해배상을 요구합니다.
본 사이트는 회사나 기업이 아닙니다. 오해마시길 바랍니다.
또한 본 메일은 사용자의 편의를 위해 한번이상 발송하지 않습니다.
따라서 수신거부하실 필요가 없습니다.
중복메일 받으시는 경우는 다른 계정으로부터 메일포워딩을 받으시거나,
동일한 도메인이 있는 메일 계정을 사용하는 경우입니다.
(예를들어 kornet.net, kornet21.net 또는 kornet.mn.kr 모두 같은 도메인입니다)
주의하도록 하겠습니다. 너그럽게 이해해 주십시오.
문의사항 있으시면 메일주십시오. 계정이 종료되어 리턴되어 돌아올 수 있습니다.
 

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 20 00:14:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15594 for ; Wed, 20 Mar 2002 00:14:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA11479 for midcom-archive@odin.ietf.org; Wed, 20 Mar 2002 00:14:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11191; Wed, 20 Mar 2002 00:07:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11160 for ; Wed, 20 Mar 2002 00:07:36 -0500 (EST) Received: from hanmir.com ([211.208.193.104]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15490 for ; Wed, 20 Mar 2002 00:07:31 -0500 (EST) Message-Id: <200203200507.AAA15490@ietf.org> Reply-To: dlatmdejr2000@hanmir.com From: 사랑해 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 20 Mar 2002 14:07:26 +0900 Subject: [midcom] [성인광고]성인들만을 위한 공간입니다. 확인하세요...!!! Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org

본 메일은 정보통신부 권고 사항에 의거 제목에 [광고]라 표시된 광고 메일입니다.
광고멜을 보내드린점 사과드립니다. 수신거부는 수신거부를 해주신다면 다시 안보내겠습니다.
더 이상 메일을 수신하고 싶지 않으시면 아래 [수신 거부] 그림을  클릭해 주십시오.


국내최대 화상채팅 동시접속 1000명이상가능
많은분들이 가입하고 있는 이유가 있습니다.

동영상, 패티쉬, 몰카, 원조교제, 포르노, 모든자료가
여러분을 기다립니다. 단 절대 성인만 클릭하시기 바랍니다.

서두르세요.. 다시 한번 죄송합니다.


미성년자는 오지마세여!! 성인들만 오시기 바랍니다.!!!


_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 20 00:56:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16240 for ; Wed, 20 Mar 2002 00:56:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA13123 for midcom-archive@odin.ietf.org; Wed, 20 Mar 2002 00:56:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12889; Wed, 20 Mar 2002 00:52:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12845 for ; Wed, 20 Mar 2002 00:52:39 -0500 (EST) Received: from hanmail.net ([218.145.87.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16181 for ; Wed, 20 Mar 2002 00:52:32 -0500 (EST) Message-Id: <200203200552.AAA16181@ietf.org> Reply-To: chlwlgur22@hanmail.net From: 성인 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 20 Mar 2002 14:51:54 +0900 Subject: [midcom] [성인광고] 절때 성인만...미성년자는 당장 이멜을 지워주시기바랍니다.. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 본 메일은 정보통신부 권고사항에 의거,제목에 [광고]라 표시된 광고메일입니다. 귀하의 E-MAIL은 게시판 등 인터넷 상에서 알게 되었으며, E-mail을 제외한 어떠한 정보도 알지 못함을 밝힙니다. 허락없이 성인광고메일을 보내드려 죄송하오며,정중히 양해부탁드리겠습니다. 이 메일을 더이상 받고 싶지 않으시다면  하단에 수신거부 표시가 있으니 클릭해 주세요. 그렇게 하시면 다시는 메일 발송을 하지 않겠습니다.아울러 이 이메일은 절때 성인들만 절때!!!!!!!!!  성인들만 보는것이므로 미성년자분들은 당장 삭제해주시기바랍니다.정말 죄송합니다. 이왕 이멜을 여신 것이라면 고급정보가 있으니 꼼꼼히 고려해 주신다면 감사하겠습니다!!

 

 

 

수많은 자료가 있습니다..

몰카....화상채팅......투명비디오....수중..........

왜 사람들이 그리 화상채팅을 하는지 바로 보실수 있습니다..

국내 여성가입율 1위!!

모든 방에는....지금 화상채팅을 하시는 분들로 가득차있습니다..

빨리 오시기바랍니다..

 

성인만 클릭해주세요!!! 미성년자는 사절!!!!

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 20 10:59:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03169 for ; Wed, 20 Mar 2002 10:59:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21539 for midcom-archive@odin.ietf.org; Wed, 20 Mar 2002 10:59:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21161; Wed, 20 Mar 2002 10:49:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21118 for ; Wed, 20 Mar 2002 10:49:00 -0500 (EST) Received: from Localhost ([211.228.141.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02811 for ; Wed, 20 Mar 2002 10:48:54 -0500 (EST) Message-Id: <200203201548.KAA02811@ietf.org> From: "mgpwkr" To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 21 Mar 2002 00:46:28 +0900 Subject: [midcom] [광고] 종량제 봉투 절약형 압축쓰레기통 소개 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org



 

----------------------------------------------------------------------------------------
이사 전문업체로서 10년의 노하우와 최소비용으로 고객의 최대만족을 위해 노력합니다.
----------------------------------------------------------------------------------------
수수료없는 포장이사전문사이트!!
견적보기 및 사이트 사용법 안내까지...
국내최초로 방문견적없는 이사가능 사이트!!
각종 이사관련 정보와 상식을 알려드립니다.

소비자
역경매
신청
회원사
경매참여
내견적
보기
&
확인
업체선정
및
경매
  사이트 도우미
이사를 원하는 고객이 이사 견적을 신청하면 다수의 이사업체가 고객의 이사 정보를 보고 고객에게
견적 가격을 제시하게 되며 고객은 업체의 제시된 가격을 보고 이사업체를 선정하는 서비스-역경매
실시간으로 자신의 이사견적을 간단하게 계산하여 볼 수 있는 서비스
무료 가정이사 역경매신청 무료 고급이사 역경매신청
무료 사무실이사 역경매신청 무료 해외이사 견적신청
---------------------------------------------------------------------------------------
이사정보마당
이사정보 : 전세들어갈때/계약서작성할때/이사전후 처리할일/
주택이사시 아랑두어야 할 사항/사무실 이전시 알아두어야 할 사항
포장요령 : 이사짐 직접 포장하는 요령/ 주방살림 포장하는 요령
인테리어 : 침실, 부엌, 욕실, 현관, 거실꾸미기
이사업체 선택기준
---------------------------------------------------------------------------------------
가정이사
소비자 유의사항/ 이사용품준비 및 용도/ 종류별 이사짐싸기
민원처리와 공과금정산은 이렇게/ 우편배달 이전 신고/구번호 착신통화제도
---------------------------------------------------------------------------------------
사무실이사
사무실이전/ 이전작업 계획서작성/ 작업순서/ 사무실이전 가이드/ 사무실 이전시 알아두어야 할 사항
---------------------------------------------------------------------------------------
해외이사
해외이주화물의 종류/ 운송기간 및 통관서류/운송요금안내/운송업체선택시 주의사항/
이주화물의 운송흐름/ 클레임 해결방법/ 보험정보/ 고객이 알아야 할 사항
---------------------------------------------------------------------------------------
용달이사화물
용달차요금표/예약신청/예약확인
---------------------------------------------------------------------------------------
생활의 지혜
수납방법/세탁방법 등///

허락없이 메일을 보내 죄송합니다. 본 메일은 1회성 광고입니다. 귀하의 메일주소는 웹서핑중 알게되었으며, 메일외에 어떠한 정보도 없습니다.
더 이상 메일을 수신하고 싶지 않으시면 [수신 거부]를 클릭해 주십시오.

[ www.i24man.com ]

▷ 원치않은 정보였다면 정중히 사과 드리며, 수신 거부를 해주시면 다음부터는 메일이 발송되지 않을 것입니다.
▷ 메일클라이언트의 필터 기능을 이용하여 [광고] 문구를 필터링하면 모든 광고 메일을 자동으로 차단하실 수 있습니다.
수신거부(Unsubscribe)
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 20 11:07:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03498 for ; Wed, 20 Mar 2002 11:07:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22534 for midcom-archive@odin.ietf.org; Wed, 20 Mar 2002 11:07:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22233; Wed, 20 Mar 2002 11:03:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22208 for ; Wed, 20 Mar 2002 11:03:13 -0500 (EST) Received: from hanmir.com ([211.208.193.104]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03314 for ; Wed, 20 Mar 2002 11:02:25 -0500 (EST) Message-Id: <200203201602.LAA03314@ietf.org> Reply-To: dlatmdejr2000@hanmir.com From: 사랑해 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 21 Mar 2002 01:03:06 +0900 Subject: [midcom] [광고] 몸에 않좋은 담배를 이제 떨쳐 버리셔야져...누구나 끊어야져!!! Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 금연 캠페인

O 나도 이번엔 꼭 성공 할 수 있다. 한달 담배값 3만원 정도만 투자하시면 피우시면서 끊을 수 있습니다.
신용카드 구입하신 모든분께 200만원 상당의 아쿠아미네랄 정수기 증정 이벤트를 실시합니다.

O 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다.
본 E-mail은 전산망 보급확장과 이용촉진에 관한 법률에 의거하여 수신자가 의사를
회신으로 밝힌후에는 또다시 보낼 수 없습니다. 수신거부
본 금*연*캠*페*인* 메일은 단 한번만 발송되는 일회성 메일입니다. 감사합니다.

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 20 22:22:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23678 for ; Wed, 20 Mar 2002 22:22:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA02345 for midcom-archive@odin.ietf.org; Wed, 20 Mar 2002 22:22:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02305; Wed, 20 Mar 2002 22:19:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02277 for ; Wed, 20 Mar 2002 22:19:45 -0500 (EST) Received: from yahoo.co.kr. ([211.109.42.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23614 for ; Wed, 20 Mar 2002 22:19:40 -0500 (EST) Message-Id: <200203210319.WAA23614@ietf.org> Reply-To: yyoill@yahoo.co.kr From: 이승훈 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 21 Mar 2002 12:20:52 +0900 Subject: [midcom] 현재 유료게시판을 공개하고 있습니다. 확실한 증권정보가 있습니다 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org

11.bmp

 

 

 

 

 현재 유료게시판을 잠시동안 오픈하고 있습니다. 돈이되는 족집게 종목추천 게시판으로 가셔서

 94스탁 종목추천에 대한 노하우를 직접 확인해 보시기 바랍니다. 귀하께 큰 도움이 되리라 자부합니다.

 

 아이디 : a7153   비밀번호 : c2338

 

33.bmp

 

 이제 경기가 바닥을 치고 서서히 정상을 향해 기지개를 키고 있습니다. 증권계에서는 대박장으로의 진입이

 얼마남지 않은 시기입니다.

 주식시장에서 현재의 장세는 아주 중요합니다. 앞으로 다가올 대박장에서 누가 먼저 황금주를 선점하느냐 하는

 길목이라고 할 수 있기 때문입니다.

 그런 의미에서 지금이 주식 투자를 하기에 적기라고 할 수 있습니다.

 하루라도 빨리 투자기준을 마련하여 대비를 해야합니다. 이에 저희 94스탁에서는 여러분들을 위해 확실한

 노하우를 준비 해두고 있습니다.

 다른 사이트와는 차별화되는 피부에 와닿는 투자노하우입니다.

 

33.bmp

 

 저희 94스탁은 주식투자가들을 위해 각종 정보를 제공하는 회원제 증권컨설팅 사이트입니다.

 대형 증권포탈 사이트를 표방하지 않습니다. 소수의 회원들과 밀도있게 커뮤니케이션하는 것을 추구합니다.

 투자종목 몇 개 던져주고 끝인 그런 사이트들과는 틀린 구체적인 정보를 회원들께 주려 노력합니다.

 안정적인 수익이야말로 투자컨설팅에 있어서 기본입니다. 이것을 94스탁은 귀하께 실현시켜드립니다.

 

 

 94스탁만의 노하우로 만들어진 투자비법입니다.

 

 정신없이 숨가쁘게 변화하는 장세 속에서 자신만의 투자 노하우를 쌓기는 매우 힘이 듭니다.

 자신만의 기법을 찾았다하더라도 엄청난 손실의 대가이거나 운좋게도 큰 손실은 모면했다하더라도 실로 많은

 시간과 정력을 쏟아부었을 것입니다.

 94스탁은 이러한 손실과 노력을 최소화할 수 있는 방법을 제시합니다. 바로 94 실전투자기법입니다.

  

33.bmp

 

 94스탁에서 회원제로 밀도있는 종목추천을 하고 있습니다. 바로 족집게 종목추천입니다.

 

 하루 전날 심도있는 분석으로 유망 투자 종목을 집어드립니다. 각종 차트와 함께 추세분석 등등 다양한 기법이

 동원됩니다. 회원들께 최대한 안정적인 수익률을 안겨드립니다. 든든한 투자기준을 제시해 주리라 믿습니다.

 

 더욱 자세한 사항은 94스탁 사이트로 오셔서 확인하시기 바랍니다. 이 외에도 다양한 정보들이 있습니다.

 

 아이디 : a7153   비밀번호 : c2338

 

 

 지금까지 이 메일을 읽어주신 귀하께 감사의 말씀드립니다. 항상 건승하시길 바랍니다.

 

귀하께 다시는 메일발송이 없을 것이오나 수신거부를 원하신다면 아래를 클릭하세요!

 

 

 다시한번 말씀드립니다. 이 메일은 처음이자 마지막 메일입니다. 이 점 이해 부탁드립니다.

 항상 행복 가득한 생활되시길 바랍니다!

 

Copyright ⓒ 2001 94stock All Rights Reserved

 

 

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 21 09:11:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11099 for ; Thu, 21 Mar 2002 09:11:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10502 for midcom-archive@odin.ietf.org; Thu, 21 Mar 2002 09:11:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10301; Thu, 21 Mar 2002 09:09:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10274 for ; Thu, 21 Mar 2002 09:09:17 -0500 (EST) Received: from localhost ([211.104.22.148]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10949 for ; Thu, 21 Mar 2002 09:09:07 -0500 (EST) Message-Id: <200203211409.JAA10949@ietf.org> Reply-To: webmaster@ludia.co.kr From: 루디아 패션몰 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 21 Mar 2002 23:05:49 +0900 Subject: [midcom] (no subject) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 메일링페이지-03월 수정

1.본 메일은 정보통신망 이용촉진 및 정보 보호등에 관한 법률 제 50조에 의거한[광고]메일 입니다.
   이메일 주소는 인터넷상에서 취득하였으며, 주소외 어떠한 정보도 가지고 있지 않습니다.

2. DB오류로 인하여 약간의 메일이 복수 발송 되었습니다. 담당자에게 메일을 주시면 즉시 조처해 드리겠습니다.
   수신 거부를 원하시면 아래 수신거부 버튼을 눌러 주세요.

 

 

 

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Mar 23 09:49:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22093 for ; Sat, 23 Mar 2002 09:49:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02467 for midcom-archive@odin.ietf.org; Sat, 23 Mar 2002 09:49:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01887; Sat, 23 Mar 2002 09:43:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01853 for ; Sat, 23 Mar 2002 09:43:13 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22034 for ; Sat, 23 Mar 2002 09:43:09 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2NEgXI10992 for ; Sat, 23 Mar 2002 06:42:33 -0800 (PST) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADH78101; Sat, 23 Mar 2002 06:40:18 -0800 (PST) Message-Id: <5.1.0.14.0.20020323094509.034f2130@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Mar 2002 09:46:38 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] STUN status Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Unless I hear otherwise from Jonathan I'm assuming that the next version of the STUN document is the one that will go into working group last call. Please have a good, careful read of the current document and raise (on the mailing list) any issues or problems that you find. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Mar 23 20:40:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27649 for ; Sat, 23 Mar 2002 20:40:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09754 for midcom-archive@odin.ietf.org; Sat, 23 Mar 2002 20:40:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07435; Sat, 23 Mar 2002 20:30:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07336 for ; Sat, 23 Mar 2002 20:30:46 -0500 (EST) Received: from localhost ([211.186.108.145]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27370 for ; Sat, 23 Mar 2002 20:30:41 -0500 (EST) Message-Id: <200203240130.UAA27370@ietf.org> Reply-To: winwin@insuwel.com From: 인슈웰컴 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 24 Mar 2002 10:25:30 +0900 Subject: [midcom] [광$고]이베트 주인공이 되십시요. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 인슈웰컴


귀하의 메일주소는 웹서핑중에 알게 된것이며, E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다.
정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다. 원치 않으면 ☞ 수신거부 를 눌러주세요. 본 메일은 한번이상 발송되지 않습니다. 
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Mar 24 21:22:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21172 for ; Sun, 24 Mar 2002 21:22:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA22627 for midcom-archive@odin.ietf.org; Sun, 24 Mar 2002 21:23:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21125; Sun, 24 Mar 2002 21:16:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21087 for ; Sun, 24 Mar 2002 21:16:11 -0500 (EST) Received: from localhost ([61.254.65.77]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21136 for ; Sun, 24 Mar 2002 21:16:06 -0500 (EST) Message-Id: <200203250216.VAA21136@ietf.org> Reply-To: yaho365@naver.com From: 라이프 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 24 Feb 2002 11:16:12 +0900 Subject: [midcom] [광고]정말 아무조건없이 드립니다. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 희소식

 

  

 

 

    하나 : 삼성 다맛 숙성기능 김치냉장고  SKRA0770G      http://samsung.malldamoa.com/
   둘 : 최고급 아쿠아 정수기 UW2000        http://www.mistzone.com/right4.php3?i1=1030&i2=21&i3=11&i4=0&i7=9
   셋 : 최고급 연수기  FT110                   http://www.mistzone.com/right4.php3?i1=1030&i2=21&i3=15&i4=0&i7=3

위의 세가지 상품을 모두 포함한 가격이 "69만원"
거기에다 3개월 무이자!!  후불결재

상담메일 : goodjoy365@empal.com

설치비 및 운송비는 일체무료 [단,정수기는 별도] 후불결재

후불재 결재방법

결재방법은 모든 제품을 다 받는 그 순간 신용카드를 직원에게 제출하여 주시면 3개월 무이자의 혜택을 받으실수 있습니다.



 희소식 하나더...

현금으로 구매를 하시면 최고급 행남자기 그릇세트(소비자가격 7만원대)를 사은품으로 드립니다.



위 사은품은 조기 품절시 동급의 상품으로 드립니다.

 

상담메일 : goodjoy365@empal.com

 

 

 본 메일은 정보통신부 권고사항에 의거, 제목에 [광고]라 표시된 광고메일입니다. 귀하의 E-MAIL은 게시판 등 인터넷 상에서 알게 되었으며, E-mail을 제외한 어떠한 정보도 알지 못함을 밝힙니다. 허락없이 광고메일을 보내드려 죄송하오며,정중히 양해부탁드리겠습니다. 이 메일을 더이상 받고 싶지 않으시다면 제 메일 yaho365@naver.com으로 수신거부 메일을 보내주시면 다시는 메일 발송을 하지 않겠습니다. 감사 합니다.

 

이왕 이멜을 여신 것이라면 고급정보가 있으니 꼼꼼히 고려해 주신다면 감사하겠습니다!!

 
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 02:47:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05058 for ; Mon, 25 Mar 2002 02:47:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA07027 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 02:47:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04766; Mon, 25 Mar 2002 02:38:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04739 for ; Mon, 25 Mar 2002 02:38:13 -0500 (EST) Received: from 3w-smtp-ac.korea.com ([211.109.1.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04999 for ; Mon, 25 Mar 2002 02:38:09 -0500 (EST) Received: from 3w-smtp-ah.korea.com ([172.31.1.67]) by 3w-smtp-ac.korea.com with Microsoft SMTPSVC(5.0.2195.3651); Mon, 25 Mar 2002 16:37:48 +0900 Received: from 3W-POP3-AB.korea.com ([211.109.1.12]) by 3w-smtp-ah.korea.com with Microsoft SMTPSVC(5.0.2195.3651); Mon, 25 Mar 2002 16:37:45 +0900 Received: from localhost ([61.254.77.142]) by 211.109.1.12 with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Mon, 25 Mar 2002 16:37:43 +0900 Reply-To: webmaster@toyntoy.co.kr From: TnT관리자 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 25 Mar 2002 16:37:47 +0900 Message-ID: <3W-SMTP-AHZI0Hi2Rug002d66e6@3w-smtp-ah.korea.com> X-OriginalArrivalTime: 25 Mar 2002 07:37:45.0909 (UTC) FILETIME=[F4A2DE50:01C1D3CF] Subject: [midcom] [AD]예쁜 토이앤토이 인형 받아가세요!! ^.^ Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 이벤트메일
 
 
 
 
http://www.toyntoy.co.kr

 
본 메일은 게시판에서 발췌한 것으로서 어떠한 개인정보도 갖고 있지 않습니다.
이후 수신을 원하지 않으시면 아래 수신거부를 눌러주시기 바랍니다.
Copyright ⓒ 2000-2001 by Globalbiz All rights reserved.
 
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 07:10:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07310 for ; Mon, 25 Mar 2002 07:10:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07616 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 07:10:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06664; Mon, 25 Mar 2002 07:06:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06615 for ; Mon, 25 Mar 2002 07:06:07 -0500 (EST) Received: from localhost ([211.175.225.85]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07251 for ; Mon, 25 Mar 2002 07:05:52 -0500 (EST) Message-Id: <200203251205.HAA07251@ietf.org> Reply-To: adminggun@gguns.com From: 소스왕국 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 25 Mar 2002 21:12:23 +0900 Subject: [midcom] [광고]소스왕국 사이트의 풀소스를 공개/판매합니다. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org

먼저 허락없이 메일을 보내 죄송합니다.
본 메일은 게시판에 추출된 귀하의 이메일을 활용하여 저희 회사의 좋은 제품
홍보를 위하여보내드리는 메일입니다.
원치 않으시면 아래의 수신거부 버튼을 클릭하여 주시기 바랍니다.

 
☞ 본메일은 돈벌기 등의 메일이나, 불법 성인사이트 광고 메일이 아닙니다.
☞ 원치 않으시는 경우 절대 다시 보내지 않겠습니다.

가격 : 55,000GM
PHP+Oracle+Java


본 제품은 리눅스 시스템에서 오라클DB 를 이용하여 제작되었습니다.
혹시 귀하께서는 인터넷을 이용하여 재테크를 해보고자 했던 생각을 해보지 않았습니까?
때론 인터넷 쇼핑몰을 운영해 보고자 하거나, 동호회, 정보제공 사이트를 한번쯤 운영해 보고 싶지는 않았습니까?
그때마다 어떻게 만들고, 어떻게 구현할까를 고민하여 좋은 아이디어를 그냥 포기하지는 않았나요?
쇼핑몰을 몇만원에 판다거나, 자신의 홈페이지를 몇만원에 구축하는 정도의 제품이 아닙니다.
아예 수십여종의 방대한 솔루션들이 포함되어 있는 제품을 풀소스를 포함하여 판매하는 국내 최초의 웹 솔루션 완전 오픈 소스 판매 방식으로 지금껏 어디에서도 이러한 정보를 판매하는 사례는 없었으며,귀하께서 어떠한 사업이나, 인터넷 비지니스를 하고자 하실때에도 유용하게 이용될 수 있는 정보가 담겨 있습니다.
이는 인터넷상에서 소프트웨어 개발 관련 정보를 제공하는 소스왕국(www.codeland.co.kr) 에서 이번에 제공하는 "IT Solution 패키지" 는 현재 국내에서 서비스 되고 있는 방대한 종류의 웹 솔루션을 자체 기술력으로 개발하여 저렴한 가격으로 판매하는 국내 최초의 IT 용 솔루션중 가장 유용한 제품입니다. 또한 구매하시는 전원에게 DB 용량 50M 를 6개월간 무료로 제공하고 있어 더욱 좋은 기회로 귀하만의 쇼핑몰, 채팅사이트, 커뮤니티 사이트, 정보사이트, 게시판, 복권, 엔터테인먼트 등의 서비스를 구현할 수 있습니다. 아래의 제품에는 다음과 같은 기능의 웹 솔루션이 전체 풀소스와 함께 제공되고 있습니다.
※ 풀소스 : 풀소스는 프로그램을 만들기 위하여 사용되는 프로그램의 원시 언어로서 이를 가공하여 어떠한 프로그램이든지 원하는 방식으로 재 창조가 가능한 프로그램의 정보입니다.
※ 본 제품은 소스를 담아서 판매하는 제품으로 별도의 제품 설치가 필요합니다.
※ 별도의 셋팅을 하여 테스트 및 서비스를 위한 준비를 원하시는 경우 당사에서 직접 셋팅비(200,000원)에 원하는 서버에 셋팅을 하여 드립니다. (웹 호스팅을 하는 경우는 불가능하며, 이 경우 당사에서 웹 호스팅을 지원할 수 있습니다.
※ 웹 호스팅 : 50M DB 계정 + 1G 용량 지원 + 100M Line + PHP 가능 = 월 5만원(6개월 선납)




쇼 핑 몰
자재관리,물품관리,배송관리,상품관리 등의 기존의 쇼핑몰의 기능이 완벽하게 구현되어 있는 쇼핑몰 제품입니다.
웹 채팅
웹에서 로그인만으로 바로 다른 사용자와 채팅 및 쪽지, P2P 1:1파일 전송 등을 할 수 있는 웹 메신저 기능의 채팅 솔루션으로 역시 소스왕국에 로그인을 하신후 바로 다른 사용자와 테스트를 할 수 있습니다.흔히 알고 계시는 세이클럽,프리첼 등의 채팅과 동일합니다.
6인용 자바 테트리스
웹 채팅중 자유롭게 회원과 6인용의 테트리스를 할 수 있도록 지원되는 6인용 자바 온라인 테트리스 게임 솔루션
자바 게임8종
 온라인에서 자유롭게 게임을 할 수있는 자바게임을 자체 개발한 제품으로 소스와 함께 등록되어 있습니다. 로보캅,두더지,지렁이,테트리스,헥사,퍼즐,벽돌깨기등
마이웹
 "www.codeland.co.kr/자신의 아이디" 를 입력하시면 바로 자신만의 작은 홈페이지가 나타납니다. 사이트에 가입만으로 자신의 홈페이지를 만들어 사용할 수 있는 서비스 제품입니다.
마이웹에는 게시판,자료실,앨범관리,스케쥴,명함관리,회원간 채팅 기능, 전광판등의 기능이 있습니다.
구인/구직
기업회원과 개인회원간 자유로운 구인구직을 연동할 수 있는 솔루션입니다.
개인은 자신의 이력서 관리를 할 수 있으며, 기업은 기업의 구인관리를 쉽게 할 수 있습니다.
과금 방식의
유료 멀티 게시판
 단순한 일반 게시판이 아닙니다.정보를 자유롭게 사고 팔 수 있는 과금방식의 유료 게시판입니다. 소스왕국의 정보 게시판에서 확인
복권 시스템
자유롭게 당첨확률을 조율하여 구현할 수 있는 웹 복권 시스템입니다. 실제 복권을 긁는 듯한 느낌으로 구현할 수 있는 시스템으로
유료 방식의
설문조사
 등록자가 원하는 금액으로 설문조사를 등록하면 참여자에게 분배되어 배당금을 제공하는 유료 방식의 설문조사 시스템으로 물론 무료로도 등록과 참여가 가능합니다. 역시 소스왕국에서 확인이 가능합니다
아바타몰
자신이 직접 아바타를 만들수 있는 아바타 제작 프로그램, 아바타를 쇼핑몰 방식으로 사고 팔 수 있는아바타 거래소 등의 솔루션입니다. 소스왕국 로그인후에 테스트 가능합니다. 이외의 회원관리 및 포인트 관리와 각종 게시판등이 포함되어 있는 완전한 풀소스제품으로 어떠한 웹 환경에서 바로 활용하여 적용할 수 있는 제품으로 제작되었습니다.
그밖의 웹 기능
 그밖의 온라인 결제 연동 시스템과 다양한 게시판 시스템 및 회원의 활동 내역확인 및 활동에 따른 포인트 상승과 관리 등의 완벽한 포털 사이트의 모든 기능이 탑재되어 현재 서비스되고 있는 '소스왕국(www.codeland.co.kr)'의 모든 소스가 그대로 CD 에 포함되어 제공됩니다.



이모든 제품이 55,000원의 가격으로 지금 현재 판매하고 있습니다.
소스왕국은 국내 IT 관련 종합 정보를 제공하는
국내 최대의 정보 제공 사이트입니다.


본 제품은 구매이후 직접 서비스를 할 수 있는 라이센스를 포함하고 있습니다.
단! 초보자분들의 경우 당사에 직접 셋팅을 의뢰하거나, 주변의 개발자분들에게 본 제품을 참고로 원하는 솔루션을 개발/구축할 수 있습니다.



***수신을 원하지 안으시면 수신거부 버튼을 눌러주세요***


Copyrightⓒ (주)꾼커뮤니케이션 All Rights Reserved.. Webmaster
 
 
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 08:46:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10267 for ; Mon, 25 Mar 2002 08:46:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01485 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 08:46:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00984; Mon, 25 Mar 2002 08:45:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00929 for ; Mon, 25 Mar 2002 08:45:24 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10096 for ; Mon, 25 Mar 2002 08:45:21 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id IAA20021 for ; Mon, 25 Mar 2002 08:23:23 -0500 (EST) Subject: Signal to SPAM ratio is now well below OdB was Re: [midcom] [ =?iso-8859-1?Q?=B1=A4=B0=ED]_=B8=F6=BF=A1_=BE=CA=C1=C1=C0=BA?= =?iso-8859-1?Q?_=B4=E3=B9=E8=B8=A6_=C0=CC=C1=A6_=B6=B3=C3=C4_=B9=F6=B8=AE?= =?iso-8859-1?Q?=BC=C5=BE=DF=C1=AE=2E=2E=2E=B4=A9=B1=B8=B3=AA_=B2=F7=BE=EE?= =?iso-8859-1?Q?=BE=DF=C1=AE=21=21=21?= To: Date: Mon, 25 Mar 2002 08:23:22 -0500 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 03/25/2002 08:23:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org SIP, SIPPING and IMPP have instituted policies for moderation of non-member postings. According to a SIP chair and personal observations, this has dramatically decreased the amount of SPAM on these lists. The new policy seems to have been met with approval or at least there have been no visible 'censorship' objections. Would it be possible to reconsider the previous decision of SPAM filtering for this list. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 09:07:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10874 for ; Mon, 25 Mar 2002 09:07:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06207 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 09:07:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05536; Mon, 25 Mar 2002 09:04:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05507 for ; Mon, 25 Mar 2002 09:04:08 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10755 for ; Mon, 25 Mar 2002 09:04:06 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2PE3bK27575; Mon, 25 Mar 2002 06:03:37 -0800 (PST) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADH94112; Mon, 25 Mar 2002 06:01:13 -0800 (PST) Message-Id: <5.1.0.14.0.20020325085818.0385ad20@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 09:07:37 -0500 To: Tom_Gray@Mitel.COM, From: Melinda Shore Subject: Re: Signal to SPAM ratio is now well below OdB was Re: [midcom] [ 광고] 몸에 않좋은 담배를 이제 떨쳐 버리 셔야져...누구나 끊어 야져!!! In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 08:23 AM 3/25/02 -0500, Tom_Gray@Mitel.COM wrote: >SIP, SIPPING and IMPP have instituted policies for moderation of non-member >postings. According to a SIP chair and personal observations, this has >dramatically decreased the amount of SPAM on these lists. The new policy >seems to have been met with approval or at least there have been no visible >'censorship' objections. Would it be possible to reconsider the previous >decision of SPAM filtering for this list. It's reconsidered every time I delete a piece of junk mail. There's a series of tradeoffs. The IETF mailing list software holds the mail for review rather than just dropping it (which is desirable behavior, BTW), which means that 1) every time a piece of mail is held I receive a notice, increasing my personal junk mail load, and 2) I have to review each piece of mail and either release it or trash it. You're asking me to increase my workload. If I felt that it was interfering with working group progress I'd do it in a heartbeat, but at this point it's just an ugly annoyance. I've found that it helps if you read each one as a testimony to the unfettered market. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 10:02:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13069 for ; Mon, 25 Mar 2002 10:02:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19536 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 10:02:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18027; Mon, 25 Mar 2002 09:56:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17992 for ; Mon, 25 Mar 2002 09:56:15 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12609 for ; Mon, 25 Mar 2002 09:56:11 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2PEtlt27181; Mon, 25 Mar 2002 09:55:48 -0500 (EST) Message-Id: <200203251455.g2PEtlt27181@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Melinda Shore cc: Tom_Gray@mitel.com, midcom@ietf.org Subject: Re: Signal to SPAM ratio is now well below OdB was Re: [midcom] [ ] ... !!! In-reply-to: (Your message of "Mon, 25 Mar 2002 09:07:37 EST.") <5.1.0.14.0.20020325085818.0385ad20@localhost> Date: Mon, 25 Mar 2002 09:55:47 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > I've found that it helps if you read each one as a testimony to > the unfettered market. I've found that moderation works best if somebody besides WG chair is responsible for moderation. (this is both because chairs are busy with other things and also because chairs too-easily confuse the job of filtering out spam with the job of keeping the list on topic) Keith p.s. If the market were really unfettered then you'd be reading news stories about spammers being fire-bombed. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 10:08:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13324 for ; Mon, 25 Mar 2002 10:08:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21015 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 10:08:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20476; Mon, 25 Mar 2002 10:06:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20355 for ; Mon, 25 Mar 2002 10:06:01 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13209 for ; Mon, 25 Mar 2002 10:05:57 -0500 (EST) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2PF59a08811; Mon, 25 Mar 2002 09:05:09 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 07:05:04 -0800 Message-ID: <7B802811BE77D51189910002A55CFD2C0188047D@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Melinda Shore , Tom_Gray@Mitel.COM, midcom@ietf.org Date: Mon, 25 Mar 2002 07:05:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D40E.79354750" Subject: [midcom] =?iso-8859-1?Q?RE=3A_Signal_to_SPAM_ratio_is_now_well_below_Od?= =?iso-8859-1?Q?B_was_Re=3A_=5Bmidcom=5D_=5B_=B1=A4=B0=ED=5D_=B8=F6=BF=A1?= =?iso-8859-1?Q?_=BE=CA=C1=C1=C0=BA_=B4=E3=B9=E8=B8=A6_=C0=CC=C1=A6_=B6?= =?iso-8859-1?Q?=B3=C3=C4_=B9=F6=B8=AE_=BC=C5=BE=DF=C1=AE=2E=2E=2E=B4=A9?= =?iso-8859-1?Q?=B1=B8=B3=AA_=B2=F7=BE=EE_=BE=DF=C1=AE=21=21=21?= Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1D40E.79354750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable you do not need to look at every email. You just need to configure the = list to allow member-only postings. If one of these spammers is already on = the list you just unsusbcribe him/them. regards, Reinaldo >-----Original Message----- >From: Melinda Shore [mailto:mshore@cisco.com] >Sent: Monday, March 25, 2002 6:08 AM >To: Tom_Gray@Mitel.COM; midcom@ietf.org >Subject: Re: Signal to SPAM ratio is now well below OdB was=20 >Re: [midcom] >[ =B1=A4=B0=ED] =B8=F6=BF=A1 =BE=CA=C1=C1=C0=BA =B4=E3=B9=E8=B8=A6 = =C0=CC=C1=A6 =B6=B3=C3=C4 =B9=F6=B8=AE = =BC=C5=BE=DF=C1=AE...=B4=A9=B1=B8=B3=AA =B2=F7=BE=EE =BE=DF=C1=AE!!! > > >At 08:23 AM 3/25/02 -0500, Tom_Gray@Mitel.COM wrote: >>SIP, SIPPING and IMPP have instituted policies for moderation=20 >of non-member >>postings. According to a SIP chair and personal observations, this = has >>dramatically decreased the amount of SPAM on these lists. =20 >The new policy >>seems to have been met with approval or at least there have=20 >been no visible >>'censorship' objections. Would it be possible to reconsider=20 >the previous >>decision of SPAM filtering for this list. > >It's reconsidered every time I delete a piece of junk mail. > >There's a series of tradeoffs. The IETF mailing list >software holds the mail for review rather than just dropping it >(which is desirable behavior, BTW), which means that 1) every >time a piece of mail is held I receive a notice, increasing >my personal junk mail load, and 2) I have to review each piece=20 >of mail and either release it or trash it. You're asking me to >increase my workload. If I felt that it was interfering with >working group progress I'd do it in a heartbeat, but at this >point it's just an ugly annoyance. > >I've found that it helps if you read each one as a testimony to=20 >the unfettered market. > >Melinda > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1D40E.79354750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Signal to SPAM ratio is now well below OdB was Re: [midcom] = [ =B1=A4=B0=ED] =B8=F6=BF=A1 =BE=CA=C1=C1=C0=BA =B4=E3=B9=E8=B8=A6 = =C0=CC=C1=A6 =B6=B3=C3=C4 =B9=F6=B8=AE = =BC=C5=BE=DF=C1=AE...=B4=A9=B1=B8=B3=AA =B2=F7=BE=EE = =BE=DF=C1=AE!!!

you do not need to look at every email. You just need = to configure the list to allow member-only postings. If one of these = spammers is already on the list you just unsusbcribe = him/them.

regards,

Reinaldo

>-----Original Message-----
>From: Melinda Shore [mailto:mshore@cisco.com]
>Sent: Monday, March 25, 2002 6:08 AM
>To: Tom_Gray@Mitel.COM; midcom@ietf.org
>Subject: Re: Signal to SPAM ratio is now well = below OdB was
>Re: [midcom]
>[ =B1=A4=B0=ED] =B8=F6=BF=A1 =BE=CA=C1=C1=C0=BA = =B4=E3=B9=E8=B8=A6 =C0=CC=C1=A6 =B6=B3=C3=C4 =B9=F6=B8=AE = =BC=C5=BE=DF=C1=AE...=B4=A9=B1=B8=B3=AA =B2=F7=BE=EE = =BE=DF=C1=AE!!!
>
>
>At 08:23 AM 3/25/02 -0500, Tom_Gray@Mitel.COM = wrote:
>>SIP, SIPPING and IMPP have instituted = policies for moderation
>of non-member
>>postings. According to a SIP chair and = personal observations, this has
>>dramatically decreased the amount of SPAM on = these lists. 
>The new policy
>>seems to have been met with approval or at = least there have
>been no visible
>>'censorship' objections. Would it be = possible to reconsider
>the previous
>>decision of SPAM filtering for this = list.
>
>It's reconsidered every time I delete a piece of = junk mail.
>
>There's a series of tradeoffs.  The IETF = mailing list
>software holds the mail for review rather than = just dropping it
>(which is desirable behavior, BTW), which means = that 1) every
>time a piece of mail is held I receive a notice, = increasing
>my personal junk mail load, and 2) I have to = review each piece
>of mail and either release it or trash it.  = You're asking me to
>increase my workload.  If I felt that it = was interfering with
>working group progress I'd do it in a heartbeat, = but at this
>point it's just an ugly annoyance.
>
>I've found that it helps if you read each one as = a testimony to
>the unfettered market.
>
>Melinda
>
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1D40E.79354750-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 10:22:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14062 for ; Mon, 25 Mar 2002 10:22:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24862 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 10:22:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24314; Mon, 25 Mar 2002 10:20:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24274 for ; Mon, 25 Mar 2002 10:20:42 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13956 for ; Mon, 25 Mar 2002 10:20:38 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2PFJvI07758; Mon, 25 Mar 2002 07:19:57 -0800 (PST) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADH95156; Mon, 25 Mar 2002 07:17:43 -0800 (PST) Message-Id: <5.1.0.14.0.20020325101552.00accb40@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 10:24:06 -0500 To: "Reinaldo Penno", midcom@ietf.org From: Melinda Shore Subject: RE: Signal to SPAM ratio is now well below Od B was Re: [midcom] [ 광고] 몸에 않좋은 담배를 이제 � 냉� 버리 셔야져...누 구나 끊어 야져!!! In-Reply-To: <7B802811BE77D51189910002A55CFD2C0188047D@zsc3c032.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 07:05 AM 3/25/02 -0800, Reinaldo Penno wrote: >you do not need to look at every email. You just need to configure the list to allow member-only postings. If one of these spammers is already on the list you just unsusbcribe him/them. Yes, you do need to look at each piece of email or else risk mistakenly rejecting legitimate mail. In information retrieval recall and relevance are clearly found to be inversely related. I'm happy to continue to discuss this, but in the interest of getting some work done perhaps each complaint about the mailing list should include an addendum regarding either pre-midcom or the protocol comparison. We've got a document about to go into WG last call and I think that's at least as deserving of our attention as is the continuing stream of off-topic email. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 10:42:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15075 for ; Mon, 25 Mar 2002 10:42:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29713 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 10:42:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29076; Mon, 25 Mar 2002 10:40:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29037 for ; Mon, 25 Mar 2002 10:40:15 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14890 for ; Mon, 25 Mar 2002 10:40:11 -0500 (EST) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2PFdSa18941; Mon, 25 Mar 2002 09:39:29 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 07:39:29 -0800 Message-ID: <7B802811BE77D51189910002A55CFD2C018804CD@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Melinda Shore , midcom@ietf.org Date: Mon, 25 Mar 2002 07:39:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D413.3E35EF56" Subject: [midcom] =?iso-8859-1?Q?RE=3A_Signal_to_SPAM_ratio_is_now_well_below_Od?= =?iso-8859-1?Q?_B_was_Re=3A_=5Bmidcom=5D_=5B_=B1=A4=B0=ED=5D_=B8=F6=BF?= =?iso-8859-1?Q?=A1_=BE=CA=C1=C1=C0=BA_=B4=E3=B9=E8=B8=A6_=C0=CC=C1=A6_?= =?iso-8859-1?Q?=B6_=B3=C3=C4_=B9=F6=B8=AE_=BC=C5=BE=DF=C1=AE=2E=2E=2E=B4?= =?iso-8859-1?Q?=A9_=B1=B8=B3=AA_=B2=F7=BE=EE_=BE=DF=C1=AE=21=21=21?= Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1D413.3E35EF56 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Melinda Shore [mailto:mshore@cisco.com] >Sent: Monday, March 25, 2002 7:24 AM >To: Penno, Reinaldo [SC9:T327:EXCH]; midcom@ietf.org >Subject: RE: Signal to SPAM ratio is now well below Od B was Re: >[midcom] [ =B1=A4=B0=ED] =B8=F6=BF=A1 =BE=CA=C1=C1=C0=BA = =B4=E3=B9=E8=B8=A6 =C0=CC=C1=A6 =B6 =B3=C3=C4 =B9=F6=B8=AE = =BC=C5=BE=DF=C1=AE...=B4=A9 =B1=B8=B3=AA >=B2=F7=BE=EE =BE=DF=C1=AE!!! > > >At 07:05 AM 3/25/02 -0800, Reinaldo Penno wrote: >>you do not need to look at every email. You just need to=20 >configure the list to allow member-only postings. If one of=20 >these spammers is already on the list you just unsusbcribe him/them. > >Yes, you do need to look at each piece of email or else risk >mistakenly rejecting legitimate mail. In information retrieval >recall and relevance are clearly found to be inversely >related. huh? okay, do what you think is best... > > ------_=_NextPart_001_01C1D413.3E35EF56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Signal to SPAM ratio is now well below Od B was Re: [midcom] = [ =B1=A4=B0=ED] =B8=F6=BF=A1 =BE=CA=C1=C1=C0=BA =B4=E3=B9=E8=B8=A6 = =C0=CC=C1=A6 =B6 =B3=C3=C4 =B9=F6=B8=AE =BC=C5=BE=DF=C1=AE...=B4=A9 = =B1=B8=B3=AA =B2=F7=BE=EE =BE=DF=C1=AE!!!

>-----Original Message-----
>From: Melinda Shore [mailto:mshore@cisco.com]
>Sent: Monday, March 25, 2002 7:24 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]; = midcom@ietf.org
>Subject: RE: Signal to SPAM ratio is now well = below Od B was Re:
>[midcom] [ =B1=A4=B0=ED] =B8=F6=BF=A1 = =BE=CA=C1=C1=C0=BA =B4=E3=B9=E8=B8=A6 =C0=CC=C1=A6 =B6 =B3=C3=C4 = =B9=F6=B8=AE =BC=C5=BE=DF=C1=AE...=B4=A9 =B1=B8=B3=AA
>=B2=F7=BE=EE =BE=DF=C1=AE!!!
>
>
>At 07:05 AM 3/25/02 -0800, Reinaldo Penno = wrote:
>>you do not need to look at every email. You = just need to
>configure the list to allow member-only = postings. If one of
>these spammers is already on the list you just = unsusbcribe him/them.
>
>Yes, you do need to look at each piece of email = or else risk
>mistakenly rejecting legitimate mail.  In = information retrieval
>recall and relevance are clearly found to be = inversely
>related.

huh? okay, do what you think is best...

>
>

------_=_NextPart_001_01C1D413.3E35EF56-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 13:01:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23036 for ; Mon, 25 Mar 2002 13:01:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05487 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 13:01:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02496; Mon, 25 Mar 2002 12:50:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02410 for ; Mon, 25 Mar 2002 12:50:46 -0500 (EST) Received: from localhost ([211.216.72.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22487 for ; Mon, 25 Mar 2002 12:50:42 -0500 (EST) Message-Id: <200203251750.MAA22487@ietf.org> Reply-To: webmaster@mobilewiz.co.kr From: 모바일위즈 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 26 Mar 2002 02:43:04 +0900 Subject: [midcom] (no subject) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 모바일위즈 -이벤트

응모방법 : 모바일위즈에 회원가입만 하시면 됩니다.
당첨자발표: 4월11일 추첨을 통해 발표합니다. (제세공과금 본인부담)
(추첨후, 당첨자명단 모바일위즈 공지사항을 참조하십시오.)


정보통신망 이용촉진 및 정보보호등에 관한법률 규정을 준수하여 광고성 메일임을 표시하였으며, 수신을 원치 않으시면 수신거부를 클릭해 주십시요.
본 메일은 정보통신부 권고 사항에 의거 제목에 [광고]라 표시된 광고 메일입니다.
수신거부 버튼을 클릭하시면 수신거부처리가 이루어 집니다.
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 14:04:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26707 for ; Mon, 25 Mar 2002 14:04:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20500 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 14:04:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18984; Mon, 25 Mar 2002 13:58:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18949 for ; Mon, 25 Mar 2002 13:58:33 -0500 (EST) Received: from localhost ([211.216.72.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26440 for ; Mon, 25 Mar 2002 13:58:28 -0500 (EST) Message-Id: <200203251858.NAA26440@ietf.org> Reply-To: webmaster@mobilewiz.co.kr From: 모바일위즈 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 26 Mar 2002 03:50:51 +0900 Subject: [midcom] (no subject) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 모바일위즈 -이벤트

응모방법 : 모바일위즈에 회원가입만 하시면 됩니다.
당첨자발표: 4월11일 추첨을 통해 발표합니다. (제세공과금 본인부담)
(추첨후, 당첨자명단 모바일위즈 공지사항을 참조하십시오.)


정보통신망 이용촉진 및 정보보호등에 관한법률 규정을 준수하여 광고성 메일임을 표시하였으며, 수신을 원치 않으시면 수신거부를 클릭해 주십시요.
본 메일은 정보통신부 권고 사항에 의거 제목에 [광고]라 표시된 광고 메일입니다.
수신거부 버튼을 클릭하시면 수신거부처리가 이루어 집니다.
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 14:04:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26733 for ; Mon, 25 Mar 2002 14:04:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20520 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 14:04:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18790; Mon, 25 Mar 2002 13:57:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18747 for ; Mon, 25 Mar 2002 13:57:54 -0500 (EST) Received: from dreamx.net (s211-33-122-177.thrunet.ne.kr [211.33.122.177]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26413 for ; Mon, 25 Mar 2002 13:57:52 -0500 (EST) Message-ID: <42350-22002312519250203@dreamx.net> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #0010630410721500AB30 Reply-To: stern19@dreamx.net From: "침코리아" To: midcom@ietf.org Date: Tue, 26 Mar 2002 04:02:50 +0900 MIME-Version: 1.0 Content-Type: text/html; charset=KS_C_5601-1987 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [midcom] [광고] 건조한 봄, 피부관리의 기본은 ? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: quoted-printable =BA=F1=C8=B8=BF=F83_1
=09 =09 =09 =09=09 =09 =09
=09=09   CHIMKOREA [=C8=AB=BA=B8=B8=DE=C0=CF]= =09 =09=09=C7=D1=B9=E6=C1=BE=C7=D5=BB=E7=C0=CC=C6=AE    =09
=09 =09=09 =09 =20 =09 =09=09 =09 =09 =09 =09=09 =09 =09 =09=09 =09 =09 =09 =09=09 =09 =09 =09 =09 =09=09 =09 =09 =09=09 =09 =09 =09=09 =09
=09=09=09 =20
<= /td>
=
=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09
=09=09=09=09=09=09 =09=09=09=09=09=09
=BC=BA=C0=CE=BA=B4=C0=C7 =B4=EB=C7=A5=B6=F3
=B0=ED=B5=B5 =C7=D2 =BC=F6 =C0=D6=B4=C2
=20 =B4=E7=B4=A2=BA=B4=2E =B1=D7 =C1=F5=BC=BC
=BF=CD =C4=A1=B7=E1=B9=FD=BF=A1 =B4=EB=C7=D1
=B5=BF=BF=B5=BB=F3=B0=AD=C0=C7=2E =09=09=09=09=09= =09 =09=09=09=09=09=09 =09=09=09=09=09		 =09=09=09=09=09=09 =09=09=09=09=09=09
=C0=CF=BB=F3=BB=FD=C8=B0=BF=A1=BC=AD =C0=DA
=C1=D6=B0=DE=B4=C2 =C7=F6=B1=E2=C1=F5=C0=CC
=B3=AA =B1=CD=B0=A1 =BF=EF=B8=AE=B4=C2
=C1=F5=BB=F3 =B5=EE=BF=A1 =B4=EB=C7=D1
=B5=BF=BF=B5=BB=F3=B0=AD=C0=C7=2E =09=09=09=09=09= =09 =09=09=09=09=09=09 =09=09=09=09=09		 =09=09=09=09=09=09 =09=09=09=09=09=09
=C6=F3=B0=E6=B1=E2 =BF=A9=BC=BA=B5=E9=C0=CC
=B0=DE=B4=C2 =BF=A9=B7=AF =B0=A1=C1=F6
=C1=F5=BB=F3=B0=FA =C4=A1=B7=E1=B9=FD=BF=A1
=B4=EB=C7=D1 =B5=BF=BF=B5=BB=F3=B0=AD=C0=C7=2E =09= =09=09=09=09=09 =09=09=09=09=09
=09=09
=09=09=09 =09=09=09=09 =09=09=09=09=09=09=09=C4=A7=C4=DA=B8=AE=BE=C6=BF=A1=BC=AD=B4=C2 =BD=C7=BB=FD= =C8=B0=BF=A1 =BD=B1=B0=D4 =C0=C0=BF=EB=C7=D2 =BC=F6 =C0=D6=B4=C2 =BF=A9=B7= =AF =B0=A1=C1=F6 =B5=BF=BF=B5=BB=F3=C0=BB =BC=AD=BA=F1=BD=BA=C7=CF=B0=ED =C0=D6=BD=C0=B4=CF=B4=D9=2E =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09
=
=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09 =09=09=09
=09=09=09 =09=09=09 =09=09=09 =A1=DF =BC=FA=C0=BB =B8= =B6=BD=C3=B8=E9 =C0=D4=BE=C8=C0=CC =C7=E6=BE=EE=BF=E4=2E
=BC=FA=C0=BB =C1=BB =B8=B9=C0=CC =B8=B6=BD=C3=B0=ED =B8= =E7=C4=A5 =C1=F6=B3=AA=B8=E9
=C0=D4=BE=C8=C0=CC=B3=AA =C7=F4=BF=A1 =BF=B0=C1=F5=C0=CC= =BB=FD=B0=DC=BC=AD =C0=CF=C1=D6=C0=CF=C1=A4=B5=B5 =B0=A9=B4=CF=B4=D9=2E=20 =B0=E1=B1=B9 =C0=CF=C1=D6=C0=CF=BF=A1 =B5=CE =B9=F8 =C1= =A4=B5=B5 =BC=FA=C0=BB =B8=B6=BD=C3=B8=E9 =B0=E8=BC=D3
=C0=D4=BE=C8=C0=CC =B2=F7=C0=CC=C1=F6 =BE=CA=B0=ED =BF=B0= =C1=F5=C0=CC =BB=FD=B1=E2=B4=C2 =B0=CD=C0=CE=B5=A5 =BE=EE=B5=F0=B8=A6
=BE=EE=B6=BB=B0=D4 =C4=A1=B7=E1=B8=A6=2E=2E=2E =09=09=09=09=09=09=09=09 =09=09=09=09=09		 =09=09=09 =09=09=09 =09=09=09 =A1=DF =B8=F6=BF=A1 =BF= =AD=C0=CC =B8=B9=BE=C6=BC=AD =BB=EC=C0=CC=2E=2E=2E
 =B8=F6=BF=A1 =BF=AD=C0=CC =B8=B9=B0=ED =BA=F1=C0=A7= =B0=A1 =BE=C8=C1=C1=B4=D9=B4=C2 =BB=FD=B0=A2=C0=CC
 =B5=E9=BE=EE=BC=AD=C0=CE=C1=F6 =BB=EC=C0=CC =C2=EE= =C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9=2E =C7=D1=C0=C7=BF=F8=BF=A1=BC=AD=B4=C2  =BF=AD=C0=CC =B8=B9=BE=C6=BC=AD =BB=EC=C0=CC =BE=C8= =C2=EE=B4=C2 =B0=CD=C0=CC=B6=F3=B0=ED =C7=CF=B4=C2=B5=A5
 =B9=DD=B4=EB=B7=CE =BF=AD=C0=BB =B3=B7=C3=DF=BE=EE= =BC=AD =BB=EC=C0=BB =C2=EE=B0=B3=C7=CF=B4=C2 =B9=E6=B9=FD=C0=CC
 =C0=D6=C0=BB=B1=EE=BF=E4? =09=09=09=09=09=09=09=09 =09=09=09=09=09
=09=09
=
=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09 =09=09=09
=09=09=09 =A1=DF =BA=AF=BA=F1, =C0=CC=C1=A6 =BE=E0 =B8=D4=C1=F6 =B8=BB=C0= =DA!
=A1=DF =C0=BD=BD=C4=BF=A1=B5=B5 =B1=C3=C7=D5=C0=CC =C0=D6=B4=D9= ? =09=09=09=09=09=09=09=09 =09=09=09=09=09		 =09=09=09 =A1=DF =B9=AB=C1=BB=B1=D5 =B4=EB=C3=BB=BC=D2
=A1=DF =B4=EB=B8=D3=B8=AE=B0=A1 =B5=C7=B1=E4 =BD=C8=BE=EE! =09=09=09=09=09=09=09=09 =09=09=09=09=09		 =09=09=09 =A1=DF =C4=A1=C5=EB=C0=C7 =C0=C0=B1=DE=C3=B3=C4=A1
=A1=DF =BA=F1=B8=B8=C0=C7 =C7=D1=B9=E6=C4=A1=B7=E1 =09=09=09=09=09=09=09=09 =09=09=09=09=09
=09=09
=09=09=09 =09=09=09=09=C6=F2=BC=D2=BF=A1 =B1=C3=B1=DD=C7= =CF=B4=F8 =BB=FD=C8=B0=B0=C7=B0=AD=C1=A4=BA=B8=B0=A1 =C0=D6=C0=B8=BD=C5=B0=A1=BF=E4? =09=09=09=09=09=09 =09
=09=09=09 =09=09=09=09=09=09=09=09=09=09=B0=C7=B0=AD=BF=A1 =B4=EB=C7=D8 =B1=C3=B1=DD= =C7=D1 =C1=A1=C0=CC =C0=D6=C0=B8=BD=C3=B0=C5=B3=AA, =C7=D1=C0=C7=C7=D0 =C1= =F6=BD=C4=B0=FA =C0=FC=C5=EB=C4=A1=B7=E1=B9=FD=BF=A1 =B0=FC=BD=C9=C0=CC =B8=B9=C0=B8=BD=C5 =BA=D0=B5=E9=C0=BA
=09=09=09=09=09=09=09=09=09=09=C4=A7=C4=DA=B8=AE=BE=C6(www=2Echimkorea=2Ecom)=B8=A6= =B9=E6=B9=AE=C7=CF=BF=A9 =C1=D6=BD=C3=B1=E2 =B9=D9=B6=F8=B4=CF=B4=D9=2E =09=09=09 =09=09=09 =09=09
=09=09 =BA=BB =B8=DE=C0=CF=C0=BA =C1=A4=BA=B8=C5=EB=BD=C5=BA=CE =B1=C7=B0= =ED=BB=E7=C7=D7=BF=A1 =C0=C7=B0=C5=C7=CF=BF=A9 =B9=DF=BC=DB=B5=C8 =B1=A4=B0= =ED =B8=DE=C0=CF=C0=D4=B4=CF=B4=D9=2E
=B1=CD=C7=CF=C0=C7 =B8=DE=C0=CF=C0=BA =C0=CE=C5=CD=B3=DD =B0=D4=BD= =C3=C6=C7 =B5=EE=C0=BB =C5=EB=C7=CF=BF=A9 =BC=F6=C1=FD=B5=C7=BE=FA=C0=B8=B8= =E7, =C0=CC=B8=DE=C0=CF =C1=D6=BC=D2 =C0=CC=BF=DC=BF=A1 =B1=CD=C7=CF=BF=A1
=B4=EB=C7=D1 =C1=A4=BA=B8=B4=C2 = =BE=C6=B9=AB=B0=CD=B5=B5 =B0=AE=B0=ED =C0=D6=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9= =2E
=B4=F5 =C0=CC=BB=F3 =B8=DE=C0=CF=C0=BB =BC=F6=BD=C5=C7=CF=B0=ED =BD= =CD=C1=F6 =BE=CA=C0=B8=BD=C3=B8=E9 =BC=F6=BD=C5=B0=C5=BA=CE=B8=A6 =C5=AC=B8=AF=C7=CF=BC= =BC=BF=E4=2E =09
=09=09 Copyright(c) 2001 by Chimkorea All right reserved=2E =20
=20
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 14:31:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28235 for ; Mon, 25 Mar 2002 14:31:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27571 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 14:31:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26050; Mon, 25 Mar 2002 14:25:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25996 for ; Mon, 25 Mar 2002 14:25:37 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27730 for ; Mon, 25 Mar 2002 14:25:36 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2PJP6G17068 for ; Mon, 25 Mar 2002 14:25:06 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 14:25:05 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A1B8@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: midcom@ietf.org Date: Mon, 25 Mar 2002 14:24:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D432.3604FF38" Subject: [midcom] MIDCOM Semantics Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1D432.3604FF38 Content-Type: text/plain; charset="iso-8859-1" Cedric Aoun and I are working on an I-D describing MIDCOM semantics. What follows is the part that deals with message contents. The remainder of the draft deals with the detailed structure of Policy Rules and shows application of the messages and detailed structure to the scenarios documented in draft-ietf-midcom-scenarios-02.txt. 3 Message semantics 3.1 General assumptions 1. The exchanges are all structured as request/response, to accord with requirement 2.1.5 (known and stable state). There are other ways to meet this requirement, if someone wants to document them. 2. No explicit association startup sequence. Instead, each party supplies its credentials in every message it sends. The Agent's authority is based on those credentials and the policy available to the Middlebox. 3. There is an ambiguity in the requirements regarding the ability to group "rulesets", as well as inconsistency in terminologies where rulesets are used instead of policy rule. It is assumed that a Policy Rule provides all of the grouping required. 4. It is assumed in this note that the protocol supports both "all or nothing" and partial intallation of Policy Rules (see discussion in the next section), where the choice is made by the Agent. The partial installation option may be considered too complex to support, in which case the semantics will simplify accordingly. 3.2 Summary of Exchanges: 1) Policy Rule Request/Response Request from the Agent to install a specific Policy Rule, associating it with a specific identifier and assigning it a specific lifetime. The request also indicates whether partial installation is allowed. This request has replacement semantics: if the identified rule was previously installed, it is replaced completely by the content of the request assuming that the Agent has the authority to make this request. This assumption is made to simplify the semantic presentation: the WG may wish as an optimization to define an additional message to incrementally modify a rule already in place. An empty Policy Rule implies that the rule has been deactivated and the associated identifier is available for reuse. The Policy Rule Response indicates the Policy Rule actually installed and the lifetime assigned to it by the Middlebox. 2) Middlebox Action Notification/Acknowledgement Asynchronous notification from the Middlebox, indicating what Policy Rule was affected, if any, what action or event has occurred, and a reason for the action or event. Acknowledgement has no additional content. 3) Deactivation Request/Acknowledgement Request from either peer to deactivate all Policy Rules associated with the given Agent. Acknowledgement indicates compliance and has no additional content. Open issue: does the Middlebox deactivate all Policy Rules the Agent has ever installed, or only those for which it is the most recent installer? 4) Policy Rule Audit Request/Response Request from the Agent to audit the content of a given Policy Rule or all rules associated with that Agent, as viewed by the Middlebox. The response provides the desired information, possibly in multiple messages. Open issue: when "ALL" is requested, does the Middlebox return all Policy Rules the Agent has ever installed, or only those for which it is the most recent installer? 5) Capability Request/Response Assuming the possibility that the Middlebox may support differing options, the request is made by the Agent and the response indicates the supported Middlebox options. Open issue: besides the Policy Rule audit, there is also the possibility of a flow audit, asking about the specifications for active flows which have been bound to Policy Rules. 3.3 Detailed Message Description General parameters ------------------ Every message carries the following parameters: - Version: the version of the MIDCOM protocol used to encode the message. - Source Identifier: the Agent or Middlebox identifier associated with the accompanying credentials. - Credentials: authenticating content. - Transaction Identifier: used to correlate requests with their responses. These are omitted from the following message descriptions for brevity. 1 (a): Policy Rule Request (Agent to Middlebox) -------------------------- Specific Parameters: Policy Rule Identifier, Policy Rule, Lifetime, Integrity Policy Rule Identifier: An identifier which can be used to correlate further requests involving this rule. At a minimum, the tuple {Agent Identifier, Middlebox Identifier, Policy Rule Identifier) must be unique. It is probably necessary that the Policy Rule Identifier be globally unique so that one Agent can (if given the authority) manipulate rules belonging to other Agents. Policy Rule: The specific Policy Rule which the Agent is asking to take effect, specified as a set of {Filter, Action} pairs. This replaces any Policy rule previously associated with the same Policy rule Identifier. An empty Policy Rule implies that the rule has been deactivated and the associated identifier is available for reuse. Lifetime: The desired lifetime of the rule, e.g. in number of seconds from the time of installation. The Middlebox deactivates the rule and notifies the Agent if the lifetime expires. The Middlebox may autonomously extend the lifetime when it detects packet activity coming within the scope of the Policy Rule. Note that such autonomous extension could be undesirable under certain failure conditions. If the Policy Rule is empty, Lifetime is set to 0. Integrity: This has two values: (a) The Policy Rule must apply completely or not at all. (b) Partial installation of the Policy rule is allowed. Integrity has effect throughout the lifetime of the rule: � at the time of processing of the Policy Rule request, it affects the outcome if conflicting Policy Rules are found � subsequently, if any Agent issues a Policy Rule request with a different Policy Rule Identifier which is found to conflict with this one and policy finds that this one is of lower priority, Integrity determines whether it is deactivated or modified. If a Policy Rule Request causes another Policy Rule to be modified or deactivated, the Middlebox sends a Middlebox Action Notification message to the Agent which requested the installation of that rule, as well as sending a Policy Rule Response to the source of the Policy Rule Request. 1(b) Policy Rule Response (Middlebox to Agent) ------------------------- Specific parameters: Policy Rule Identifier, Policy Rule, Lifetime, Reason Policy Rule Identifier: Policy Rule Identifier as it appeared in the Policy Rule Request. Policy Rule: The Policy Rule actually installed. If partial installation is allowed this may differ from the Policy Rule in the original request. If the request was denied completely this must be empty. Lifetime: The rule lifetime actually assigned by the Middlebox. This may differ from the lifetime requested, regardless of the value of Integrity in the request. Changes in lifetime are not reflected in Reason (e.g. a request could be "accepted", yet lifetime has been modified). If the Policy Rule is empty, Lifetime is set to 0. Reason: Indicates the reason for the outcome. Possible values are: - accepted - Policy Rule modified due to conflict - denied due to conflict (returned Policy Rule must be empty) - Policy Rule modified due to lack of resources - denied due to lack of resources (returned Policy Rule must be empty) - denied due to lack of authority (returned Policy Rule must be empty) 2(a) Middlebox Action Notification (Middlebox to Agent) ---------------------------------- Specific parameters: Reason, Policy Rule Identifier (optional), Policy Rule (optional) Reason: Indicates why the notification was issued. Possible values are: - Policy Rule modified due to conflict (Policy Rule Identifier and Policy Rule must be present) - Policy Rule deactivated due to conflict (Policy Rule Identifier must be present) - Policy Rule deactivated due to lifetime expiry (Policy Rule Identifier must be present) - ??? Policy Rule Identifier: If present, identifies the Policy Rule affected by the event. Policy Rule: If present, indicates the present content of the given Policy Rule. 2(b) Middlebox Action Acknowledgement (Agent to Middlebox) ------------------------------------- No specific parameters. 3(a) Deactivation Request (either Agent or Middlebox to peer) ------------------------- No specific parameters. 3(b) Deactivation Acknowledgement (responding peer to requesting Agent or Middlebox) --------------------------------- No specific parameters. 4(a) Policy Rule Audit Request (Agent to Middlebox) ------------------------------ Specific parameter: Policy Rule Identifier Policy Rule Identifier: The identifier of the specific policy to be audited, or else the special identifier ALL. If ALL is specified the request is for an audit of all Policy Rules installed by the requesting Agent. 4(b) Policy Rule Audit Response (Middlebox to Agent) ------------------------------- Specific parameters: Sequence Number, Total Count, Policy Rule Identifier, Policy Rule, Lifetime, Integrity Each Policy Rule Audit Response message reports the content of one Policy Rule associated with the Agent. Sequence Number: The order of the message in the set of responses, beginning with 1 and incrementing by 1 for each additional message. Total Count: The total number of Policy Rules associated with the Agent. This may be 0 if no Policy Rules are currently associated with the Agent. Policy Rule Identifier (optional): Present unless no Policy Rules are currently associated with the Agent. Identifies the Policy Rule specified in this message. Policy Rule (optional): Present unless no Policy Rules are currently associated with the Agent. Specifies the Policy Rule as it is known to the Middlebox. Lifetime (optional): Present unless no Policy Rules are currently associated with the Agent. Indicates the remaining lifetime of the Policy Rule at the time of the response. Integrity (optional): Present unless no Policy Rules are currently associated with the Agent. Indicates whether the Middlebox deactivate or modify the Policy Rule if a conflicting rule takes precedence. 5(a) Capability Request (Agent to Middlebox) ----------------------- Specific parameters: Option List Option List (optional): if present, indicates options the Agent proposes to use. Possible options are for further study. 5(b) Capability Response (Middlebox to Agent) ----------------------- Specific parameters: Option List Option List): indicates options supported by the Middlebox. Possible options are for further study. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C1D432.3604FF38 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIDCOM Semantics

Cedric Aoun and I are working on an I-D describing = MIDCOM semantics.  What follows is the part that deals with = message contents.  The remainder of the draft deals with the = detailed structure of Policy Rules and shows application of the = messages and detailed structure to the scenarios documented in = draft-ietf-midcom-scenarios-02.txt.

3       Message = semantics

3.1     General = assumptions


1. The exchanges are all structured as = request/response, to accord with requirement 2.1.5 (known and stable = state).  There are other ways to meet this requirement, if someone = wants to document them.

2. No explicit association startup sequence.  = Instead, each party supplies its credentials in every message it = sends.  The Agent's authority is based on those credentials and = the policy available to the Middlebox.

3. There is an ambiguity in the requirements = regarding the ability to group "rulesets", as well as inconsistency in = terminologies where rulesets are used instead of policy rule.  It = is assumed that a Policy Rule provides all of the grouping = required.

4. It is assumed in this note that the protocol = supports both "all or nothing" and partial intallation of = Policy Rules (see discussion in the next section), where the choice is = made by the Agent.  The partial installation option may be = considered too complex to support, in which case the semantics will = simplify accordingly.



3.2     Summary of = Exchanges:


1) Policy Rule Request/Response

Request from the Agent to install a specific Policy = Rule, associating it with a specific identifier and assigning it a = specific lifetime.  The request also indicates whether partial = installation is allowed.  This request has replacement semantics: = if the identified rule was previously installed, it is replaced = completely by the content of the request assuming that the Agent has = the authority to make this request.  This assumption is made to = simplify the semantic presentation: the WG may wish as an optimization = to define an additional message to incrementally modify a rule already = in place.

An empty Policy Rule implies that the rule has been = deactivated and the associated identifier is available for = reuse.

The Policy Rule Response indicates the Policy Rule = actually installed and the lifetime assigned to it by the = Middlebox.

2) Middlebox Action = Notification/Acknowledgement

Asynchronous notification from the Middlebox, = indicating what Policy Rule was affected, if any, what action or event = has occurred, and a reason for the action or event.  = Acknowledgement has no additional content.

3) Deactivation Request/Acknowledgement

Request from either peer to deactivate all Policy = Rules associated with the given Agent.  Acknowledgement indicates = compliance and has no additional content.

Open issue: does the Middlebox deactivate all Policy = Rules the Agent has ever installed, or only those for which it is the = most recent installer?

4) Policy Rule Audit Request/Response
  
Request from the Agent to audit the content of a = given Policy Rule or all rules associated with that Agent, as viewed by = the Middlebox.  The response provides the desired information, = possibly in multiple messages.

Open issue: when "ALL" is requested, does = the Middlebox return all Policy Rules the Agent has ever installed, or = only those for which it is the most recent installer?

5) Capability Request/Response

Assuming the possibility that the Middlebox may = support differing options, the request is made by the Agent and the = response indicates the supported Middlebox options.

Open issue: besides the Policy Rule audit, there is = also the possibility of a flow audit, asking about the specifications = for active flows which have been bound to Policy Rules.


 
3.3     Detailed Message = Description


General parameters
------------------

Every message carries the following = parameters:

 - Version: the version of the MIDCOM protocol = used to encode the message.
 - Source Identifier: the Agent or Middlebox = identifier associated with the accompanying credentials.
 - Credentials: authenticating content.
 - Transaction Identifier: used to correlate = requests with their responses.

These are omitted from the following message = descriptions for brevity.


1 (a): Policy Rule Request (Agent to = Middlebox)
--------------------------

Specific Parameters: Policy Rule Identifier, Policy = Rule, Lifetime, Integrity
 
Policy Rule Identifier:
An identifier which can be used to correlate further = requests involving this rule.  At a minimum, the tuple {Agent = Identifier, Middlebox Identifier, Policy Rule Identifier) must be = unique.  It is probably necessary that the Policy Rule Identifier = be globally unique so that one Agent can (if given the authority) = manipulate rules belonging to other Agents. 

Policy Rule:
The specific Policy Rule which the Agent is asking = to take effect, specified as a set of {Filter, Action} pairs.  = This replaces any Policy rule previously associated with the same = Policy rule Identifier.  An empty Policy Rule implies that the = rule has been deactivated and the associated identifier is available = for reuse.

Lifetime:
The desired lifetime of the rule, e.g. in number of = seconds from the time of installation.  The Middlebox deactivates = the rule and notifies the Agent if the lifetime expires.  The = Middlebox may autonomously extend the lifetime when it detects packet = activity coming within the scope of the Policy Rule.  Note that = such autonomous extension could be undesirable under certain failure = conditions.  If the Policy Rule is empty, Lifetime is set to = 0.

Integrity:
This has two values:
(a) The Policy Rule must apply completely or not at = all.
(b) Partial installation of the Policy rule is = allowed.
Integrity has effect throughout the lifetime of the = rule:

=B7       at the time = of processing of the Policy Rule request, it affects the outcome if = conflicting Policy Rules are found

=B7       subsequently, = if any Agent issues a Policy Rule request with a different Policy Rule = Identifier which is found to conflict with this one and policy finds = that this one is of lower priority, Integrity determines whether it is = deactivated or modified.

If a Policy Rule Request causes another Policy Rule = to be modified or deactivated, the Middlebox sends a Middlebox Action = Notification message to the Agent which requested the installation of = that rule, as well as sending a Policy Rule Response to the source of = the Policy Rule Request.

1(b) Policy Rule Response (Middlebox to Agent)
-------------------------

Specific parameters: Policy Rule Identifier, Policy = Rule, Lifetime, Reason

Policy Rule Identifier:
Policy Rule Identifier as it appeared in the Policy = Rule Request.

Policy Rule:
The Policy Rule actually installed.  If partial = installation is allowed this may differ from the Policy Rule in the = original request.  If the request was denied completely this must = be empty.

Lifetime:
The rule lifetime actually assigned by the = Middlebox.  This may differ from the lifetime requested, = regardless of the value of Integrity in the request.  Changes in = lifetime are not reflected in Reason (e.g. a request could be = "accepted", yet lifetime has been modified).  If the = Policy Rule is empty, Lifetime is set to 0.

Reason:
Indicates the reason for the outcome.  Possible = values are:
 - accepted
 - Policy Rule modified due to conflict
 - denied due to conflict (returned Policy Rule = must be empty)
 - Policy Rule modified due to lack of = resources
 - denied due to lack of resources (returned = Policy Rule must be empty)
 - denied due to lack of authority (returned = Policy Rule must be empty)


2(a) Middlebox Action Notification (Middlebox to = Agent)
----------------------------------

Specific parameters: Reason, Policy Rule Identifier = (optional), Policy Rule (optional)

Reason:
Indicates why the notification was issued.  = Possible values are:
 - Policy Rule modified due to conflict (Policy = Rule Identifier and Policy Rule must be present)
 - Policy Rule deactivated due to conflict = (Policy Rule Identifier must be present)
 - Policy Rule deactivated due to lifetime = expiry (Policy Rule Identifier must be present)
 - ???

Policy Rule Identifier:
If present, identifies the Policy Rule affected by = the event.

Policy Rule:
If present, indicates the present content of the = given Policy Rule.

2(b) Middlebox Action Acknowledgement (Agent to = Middlebox)
-------------------------------------

No specific parameters.


3(a) Deactivation Request (either Agent or Middlebox = to peer)
-------------------------

No specific parameters.

3(b) Deactivation Acknowledgement (responding peer to = requesting Agent or Middlebox)
---------------------------------

No specific parameters.


4(a) Policy Rule Audit Request (Agent to = Middlebox)
------------------------------

Specific parameter: Policy Rule Identifier

Policy Rule Identifier:
The identifier of the specific policy to be audited, = or else the special identifier ALL.  If ALL is specified the = request is for an audit of all Policy Rules installed by the requesting = Agent.

4(b) Policy Rule Audit Response (Middlebox to = Agent)
-------------------------------

Specific parameters: Sequence Number, Total Count, = Policy Rule Identifier, Policy Rule, Lifetime, Integrity

Each Policy Rule Audit Response message reports the = content of one Policy Rule associated with the Agent.

Sequence Number:
The order of the message in the set of responses, = beginning with 1 and incrementing by 1 for each additional = message.

Total Count:
The total number of Policy Rules associated with the = Agent.  This may be 0 if no Policy Rules are currently associated = with the Agent.

Policy Rule Identifier (optional):
Present unless no Policy Rules are currently = associated with the Agent.  Identifies the Policy Rule specified = in this message.

Policy Rule (optional):
Present unless no Policy Rules are currently = associated with the Agent.  Specifies the Policy Rule as it is = known to the Middlebox.

Lifetime (optional):
Present unless no Policy Rules are currently = associated with the Agent.  Indicates the remaining lifetime of = the Policy Rule at the time of the response.

Integrity (optional):
Present unless no Policy Rules are currently = associated with the Agent.  Indicates whether  the Middlebox = deactivate or modify the Policy Rule if a conflicting rule takes = precedence.


5(a) Capability Request (Agent to Middlebox)
-----------------------

Specific parameters: Option List

Option List (optional):
if present, indicates options the Agent proposes to = use.  Possible options are for further study.

5(b) Capability Response (Middlebox to Agent)
-----------------------

Specific parameters: Option List

Option List):
indicates options supported by the Middlebox.  = Possible options are for further study.

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C1D432.3604FF38-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 14:33:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28433 for ; Mon, 25 Mar 2002 14:33:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28045 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 14:33:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26996; Mon, 25 Mar 2002 14:29:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26966 for ; Mon, 25 Mar 2002 14:29:25 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27978 for ; Mon, 25 Mar 2002 14:29:24 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2PJSUw18004; Mon, 25 Mar 2002 14:28:30 -0500 (EST) Received: from matt.verizon.net (MATT [10.128.83.148]) by sonusdc3.sonusnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G2CW9WJF; Mon, 25 Mar 2002 14:28:45 -0500 Message-Id: <5.1.0.14.2.20020325112526.026c43c0@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 11:27:29 -0800 To: Melinda Shore , midcom@ietf.org From: Matt Holdrege Subject: Re: Signal to SPAM ratio is now well below OdB was Re: [midcom] [ =?iso-8859-1?Q?=B1=A4=B0=ED?= =?iso-8859-1?Q?]_=B8=F6=BF=A1_?= =?iso-8859-1?Q?=BE=CA=C1=C1=C0=BA?= =?iso-8859-1?Q?_=B4=E3=B9=E8=B8=A6?= =?iso-8859-1?Q?_=C0=CC=C1=A6_?= =?iso-8859-1?Q?=B6=B3=C3=C4?= =?iso-8859-1?Q?_=B9=F6=B8=AE_?= =?iso-8859-1?Q?=BC=C5=BE=DF=C1=AE?= ... =?iso-8859-1?Q?=B4=A9=B1=B8=B3=AA?= =?iso-8859-1?Q?_=B2=F7=BE=EE_?= =?iso-8859-1?Q?=BE=DF=C1=AE!!!?= In-Reply-To: <5.1.0.14.0.20020325085818.0385ad20@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 06:07 AM 3/25/2002, Melinda Shore wrote: >At 08:23 AM 3/25/02 -0500, Tom_Gray@Mitel.COM wrote: > >SIP, SIPPING and IMPP have instituted policies for moderation of non-member > >postings. According to a SIP chair and personal observations, this has > >dramatically decreased the amount of SPAM on these lists. The new policy > >seems to have been met with approval or at least there have been no visible > >'censorship' objections. Would it be possible to reconsider the previous > >decision of SPAM filtering for this list. > >It's reconsidered every time I delete a piece of junk mail. > >There's a series of tradeoffs. The IETF mailing list >software holds the mail for review rather than just dropping it >(which is desirable behavior, BTW), which means that 1) every >time a piece of mail is held I receive a notice, increasing >my personal junk mail load, and 2) I have to review each piece >of mail and either release it or trash it. You're asking me to >increase my workload. If I felt that it was interfering with >working group progress I'd do it in a heartbeat, but at this >point it's just an ugly annoyance. All of us other chairs are doing it on various IETF-hosted lists, and it only takes a few seconds to do. The web interface makes it quite easy to handle spam. But if you really can't spare those few seconds per day, then you can assign someone else to do it. >I've found that it helps if you read each one as a testimony to >the unfettered market. We don't need dozens of reminders each day to accomplish that. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 14:36:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28608 for ; Mon, 25 Mar 2002 14:36:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28697 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 14:36:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25296; Mon, 25 Mar 2002 14:22:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25184 for ; Mon, 25 Mar 2002 14:22:37 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27632 for ; Mon, 25 Mar 2002 14:22:36 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2PJM5a20652 for ; Mon, 25 Mar 2002 13:22:05 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 13:22:06 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE38E3@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Mon, 25 Mar 2002 13:22:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D432.59EC0D60" Subject: [midcom] Proposed Timeline for Protocol Evaluation Documents Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1D432.59EC0D60 Content-Type: text/plain; charset="iso-8859-1" Hi all, The following summarizes the timeline that I presented during the MIDCOM WG session on Thursday afternoon: March 21st-April 3rd Submission of intent to contribute to a specific protocol evaluation(an email should be sent to editor indicating the intent to contribute a specific protocol evaluation). * Interested parties wanting to work on the same protocol will be offered the opportunity to work together, however priority is given to whomever puts in the first claim or submits the draft first. * Mailing list discussion on document content. April 3rd Cutoff for submission of intent to contribute a specific protocol evaluation. * Final document required content agreed, WG document template and rules April 19th Final cutoff for specific protocol drafts. * Drafts must be as objective as possible, identify the applicability to the framework and clearly identify the requirements that are satisfied, those that are "partially" satisfied, and those that are NOT satisfied. April 19th- May 3rd Mailing list discussion of specific protocol drafts, allowing authors to incorporate WG feedback into their contribution to improve comparison and add completeness. May 10th Deadline for any updates to protocol drafts. May 10th-May 24th Editor's primary task is underway. Information from the specific protocol drafts is synthesize into a consistent format, with an objective comparison of the various proposals based upon the drafts May 24th 1st version of Protocol evaluation draft available. May 24th-June 7th Mailing list discussion of the draft. Discussion of amalgamated pros/cons of the various proposals Any other issues with the draft. June 7th Conclusion of mailing list discussion. June 14th Second version of draft available. June 14th-June 21st Mailing list discussion June 28th Draft ready for WGLC July 19th WGLC ends July 26th Updated draft based upon WGLC comments available July 26th- Aug (whether another iteration is required for WGLC depends upon the extent of changes, etc.) Aug Draft submitted to IESG As I mentioned during the meeting, the intent is to have a draft template of the information that should be contained in the documents (and that will form the basis of the WG protocol evaluation document) available this week. Note, that I don't intend to be prescriptive on the formats for the individual documents, however, similarity in content will facilitate the editing task and provide a more uniform basis for the protocol comparison. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 ------_=_NextPart_001_01C1D432.59EC0D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Proposed Timeline for Protocol Evaluation Documents

Hi all,

The following summarizes the timeline that I = presented during the MIDCOM WG session on Thursday afternoon:

March 21st-April 3rd    Submission of = intent to contribute to a specific 
          &nb= sp;           &nb= sp; protocol evaluation(an email should be sent to
          &nb= sp;           &nb= sp; editor indicating the intent to contribute a
          &nb= sp;           &nb= sp; specific protocol evaluation).

          &nb= sp;           &nb= sp;  * Interested parties wanting to work on the same
          &nb= sp;           &nb= sp;    protocol will be offered the opportunity to work =
          &nb= sp;           &nb= sp;    together, however priority is given to = whomever
          &nb= sp;           &nb= sp;    puts in the first claim or submits the draft =
          &nb= sp;           &nb= sp;    first.

          &nb= sp;           &nb= sp;  * Mailing list discussion on document content.

April 3rd       Cutoff = for submission of intent to contribute a specific
          &nb= sp; protocol evaluation.
          &nb= sp; *  Final document required content agreed, WG document = template
          &nb= sp;    and rules

April 19th      Final cutoff = for specific protocol drafts.
          &nb= sp; *  Drafts must be as objective as possible, identify = the
          &nb= sp;    applicability to the framework and clearly = identify the
          &nb= sp;    requirements that are satisfied, those = that
          &nb= sp;    are "partially" satisfied, and those = that are NOT satisfied.

April 19th- May 3rd     Mailing = list discussion of specific protocol
          &nb= sp;           &nb= sp; drafts, allowing authors to incorporate WG feedback
          &nb= sp;           &nb= sp; into their contribution to improve comparison and
          &nb= sp;           &nb= sp; add completeness.

May 10th        = Deadline for any updates to protocol drafts.

May 10th-May 24th       = Editor's primary task is underway.
          &nb= sp;       Information from the specific = protocol drafts is
          &nb= sp;       synthesize into a consistent = format, with an objective
          &nb= sp;       comparison of the various = proposals based upon the drafts

May 24th        = 1st version of Protocol evaluation draft available.

May 24th-June 7th       = Mailing list discussion of the draft.
          &nb= sp;       Discussion of amalgamated = pros/cons of the various proposals
          &nb= sp;       Any other issues with the = draft.

June 7th        = Conclusion of mailing list discussion.

June 14th       Second = version of draft available.
 
June 14th-June 21st     Mailing = list discussion

June 28th       Draft = ready for WGLC

July 19th       WGLC = ends

July 26th       Updated = draft based upon WGLC comments available

July 26th- Aug (whether another iteration is required = for WGLC depends upon
          &nb= sp;     the extent of changes, etc.)

Aug     Draft submitted to IESG

As I mentioned during the meeting, the intent is to = have a draft template of the information that should be contained in = the documents (and that will form the basis of the WG protocol = evaluation document) available this week.  Note, that I don't = intend to be prescriptive on the formats for the individual documents, = however, similarity in content will facilitate the editing task and = provide a more uniform basis for the protocol comparison.

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806

------_=_NextPart_001_01C1D432.59EC0D60-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 22:59:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15056 for ; Mon, 25 Mar 2002 22:59:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA00643 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 22:59:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA29986; Mon, 25 Mar 2002 22:57:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA29879 for ; Mon, 25 Mar 2002 22:57:06 -0500 (EST) Received: from localhost ([211.106.130.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15014 for ; Mon, 25 Mar 2002 22:57:00 -0500 (EST) Message-Id: <200203260357.WAA15014@ietf.org> Reply-To: test@test.com From: test To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 26 Mar 2002 12:55:15 +0900 Subject: [midcom] (no subject) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org

귀하의 메일주소는 웹 서핑 중에서 알게 된 것이며, E-Mail 주소 외에, 다른 정보는 보유하고  있지 않습니다.
정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다. 원치 않으면  수신 거부 눌러주세요

                 

 

 최고보다는 최선을 지향하는 고객의 충실한 조력자가 되겠습니다.

               GA Communications와 만남은 성공 캠페인을 위한 지름길입니다.

               GA는 소비자를 읽는 분석력과소비자를 창출하고 움직이는 다양한

               마케팅 전략을 겸비한 Good  Assistant 입니다.

 

 


IMC (Integrated Marketing Communications) 기반의 운영을 통한 마케팅 전략 수립의 일관성 확보, 각 커뮤니케이션 전략 간의 상호 보완성 유지를 통한 저비용 고효율의 마케팅 계획수립 및 효과적인 커뮤니케이션 플랜의 수행이 가능한 마케팅 에이전시 입니다.

 


능력 있는 파트너를 고르는 혜안은 곧 기업의 경쟁력입니다.
GA PR팀은 고객이 목표 지점에 성공적으로 상륙할 수 있도록 지원하는 전략가이자 조언자입니다.
      - PR Consulting  /    - Research & Survey
      - Crisis & Issue Management
      - Publicity   /   - PR Event

 


고객 만족을 실현하기 위해 다양한 구슬을 엮어야 할 때 GA에 오십시오. 소비자를 이끄는 치밀한 프로모션 전략으로 평범한 구슬을 고객 만족이라는 찬란한 보석으로 엮어드립니다.
      - Customer participation / - User Conference
      - Road Show  / - Kick-off Meeting
      - Seminer  / - Exposition / - Exhibition
      - Social Event / - Welfare Event

 


정확한 컨셉 도출에 의한 아이디어 표현과 키 메세지 전달만이 소비자의 마음을 움직일 수 있습니다.
GA의 Creative 팀은 디자이너(Designer)를 넘어 프로듀서(Producer)로서 귀사의 광고를 살아 숨쉬게 합니다
      - Marketing Material
         ( Catalog / Brochure / Leaflet )
      - Newsletter
      - Annual Report, Fact Book
      - Manual   /   - Product Packaging

 


정확한 시장분석과 타깃 설정을 통한 효과적인 광고 노출
     - Market Analysis
     - Brand Positioning
     - Media Mix

 

 

 

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Mar 25 23:37:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15773 for ; Mon, 25 Mar 2002 23:37:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA08925 for midcom-archive@odin.ietf.org; Mon, 25 Mar 2002 23:37:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06167; Mon, 25 Mar 2002 23:24:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06126 for ; Mon, 25 Mar 2002 23:24:50 -0500 (EST) Received: from localhost ([218.232.7.244]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15270 for ; Mon, 25 Mar 2002 23:24:44 -0500 (EST) Message-Id: <200203260424.XAA15270@ietf.org> Reply-To: test1@test.com From: 하나로 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 26 Mar 2002 13:31:54 +0900 Subject: [midcom] 마지막! 하나로통신 가입설치비+2개월무료 [광고] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org




본 메일은 정보통신부 권고 사항에 의거 제목에 [광고]라 표시된 광고 메일입니다.
수신거부 버튼을 클릭하시면 수신거부처리가 이루어 집니다.
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Mar 26 05:20:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28490 for ; Tue, 26 Mar 2002 05:20:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA00460 for midcom-archive@odin.ietf.org; Tue, 26 Mar 2002 05:20:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29655; Tue, 26 Mar 2002 05:17:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29620 for ; Tue, 26 Mar 2002 05:17:09 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28468 for ; Tue, 26 Mar 2002 05:17:04 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g2QAGbQ83245; Tue, 26 Mar 2002 11:16:37 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA25003; Tue, 26 Mar 2002 11:16:36 +0100 Date: Tue, 26 Mar 2002 11:19:27 +0100 From: Juergen Quittek To: Melinda Shore , Reinaldo Penno , midcom@ietf.org Subject: RE: Signal to SPAM ratio is now well below Od B was Re: [midcom] [ XXXX] XXXX XXXXXX XXXXXX XXXX X XXX XXXX XXXXXX...XX XXXX XXXX XXXX!!! Message-ID: <1501398.1017141567@[192.168.102.164]> In-Reply-To: <5.1.0.14.0.20020325101552.00accb40@localhost> References: <5.1.0.14.0.20020325101552.00accb40@localhost> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Melinda, I do not get your point. In both cases - open mailing list or - moderated mailing list you will get the same number of messages. And I assume that you as chair read all them anyway. So for you there would be no difference in the number of messages to read. However, if you (after reading) reject all spam messages, it would be a significant difference for all other subscribers, because spam is increasing heavily. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 25 March 2002 10:24 -0500 Melinda Shore wrote: > At 07:05 AM 3/25/02 -0800, Reinaldo Penno wrote: >> you do not need to look at every email. You just need to configure the list to allow member-only postings. If one of these spammers is already on the list you just unsusbcribe him/them. > > Yes, you do need to look at each piece of email or else risk > mistakenly rejecting legitimate mail. In information retrieval > recall and relevance are clearly found to be inversely > related. > > I'm happy to continue to discuss this, but in the interest of > getting some work done perhaps each complaint about the mailing > list should include an addendum regarding either pre-midcom or > the protocol comparison. We've got a document about to go into > WG last call and I think that's at least as deserving of our > attention as is the continuing stream of off-topic email. > > 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 daemon@ns.ietf.org Tue Mar 26 16:16:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24313 for ; Tue, 26 Mar 2002 16:16:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25785 for midcom-archive@odin.ietf.org; Tue, 26 Mar 2002 16:16:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25271; Tue, 26 Mar 2002 16:14:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25239 for ; Tue, 26 Mar 2002 16:14:09 -0500 (EST) Received: from berkshire.research.att.com (H-135-207-23-61.research.att.com [135.207.23.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24219 for ; Tue, 26 Mar 2002 16:14:05 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 31E727B4B; Tue, 26 Mar 2002 16:14:06 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Melinda Shore Cc: Tom_Gray@Mitel.COM, midcom@ietf.org Subject: Re: Signal to SPAM ratio is now well below OdB was Re: [midcom] [ ] ... !!! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Mar 2002 16:14:06 -0500 Message-Id: <20020326211406.31E727B4B@berkshire.research.att.com> Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org In message <5.1.0.14.0.20020325085818.0385ad20@localhost>, Melinda Shore writes : >At 08:23 AM 3/25/02 -0500, Tom_Gray@Mitel.COM wrote: >>SIP, SIPPING and IMPP have instituted policies for moderation of non-member >>postings. According to a SIP chair and personal observations, this has >>dramatically decreased the amount of SPAM on these lists. The new policy >>seems to have been met with approval or at least there have been no visible >>'censorship' objections. Would it be possible to reconsider the previous >>decision of SPAM filtering for this list. > >It's reconsidered every time I delete a piece of junk mail. > >There's a series of tradeoffs. The IETF mailing list >software holds the mail for review rather than just dropping it >(which is desirable behavior, BTW), which means that 1) every >time a piece of mail is held I receive a notice, increasing >my personal junk mail load, and 2) I have to review each piece >of mail and either release it or trash it. It can't be dropped automatically -- see http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 27 12:50:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11097 for ; Wed, 27 Mar 2002 12:50:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22120 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 12:50:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21478; Wed, 27 Mar 2002 12:48:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21404 for ; Wed, 27 Mar 2002 12:48:48 -0500 (EST) Received: from hotmail.com ([203.238.135.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10922 for ; Wed, 27 Mar 2002 12:48:46 -0500 (EST) Message-Id: <200203271748.MAA10922@ietf.org> Reply-To: hotpoolm93@hotmail.com From: 정보 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 02:52:17 +0900 Subject: [midcom] ('광.고') 메가패스를 쓰고 있는 분을 위한 엄청난 혜택! Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 나우누리 회원가입
 
 
- 매주 개봉영화를 미리 보는 시사회 무료 초대!

- 국내 최대, 영화 8,000원 할인(1인 동반 시)
  메가박스 등 전국 260여개 상영관/실시간 예매
  * 멤버쉽카드 발급 시(5월 28일부터 신청 및 발급 가능)
 
 
 
- 만화에선 이들을 따라올 수 없다! 만화사랑(MANSA), 앙끄(ANC),
- 국내 NO.1 게임전략 동호회! 나모모
- 파워 유저들의 활기찬 공간! 파워 유저 동호회 등 엄청난 동호회가 가득!

- 와레즈를 능가하는 나우누리 자료실 무료 이용까지!
 
 
 
- 디지털 카메라, DVD, 명품시계.. 365일 공짜상품이 가득~
  무제한 사이버머니로 게임같이 베팅도 즐기고 푸짐한 경품도 탄다!
 
 
 
- 이상형을 매일매일 10명씩 추천해드립니다.
  원하는 미팅 상대와의 즉석 온라인 미팅!
  확실한 유료회원만의 짜릿한 미팅 서비스가 무료 ~
 
 

 나우누리만의 특별한 혜택, 지금 아래 버튼을 클릭하셔서 기회를 잡으세요!~
 
허락도 없이 메일을 드려 죄송합니다. 귀하의 이메일 주소는 게시판 등 인터넷을 통해 알게 되었습니다.
메일 수신을 원치않으시면 아래에 본인의 이메일 주소를 입력하시고 수신거부버튼을 눌러주세요
   
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 27 13:30:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14564 for ; Wed, 27 Mar 2002 13:30:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28617 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 13:30:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27434; Wed, 27 Mar 2002 13:26:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27393 for ; Wed, 27 Mar 2002 13:26:30 -0500 (EST) Received: from localhost ([211.49.192.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14176 for ; Wed, 27 Mar 2002 13:26:25 -0500 (EST) Message-Id: <200203271826.NAA14176@ietf.org> Reply-To: admin@lec.co.kr From: "lec-academy.com" To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 03:32:07 +0900 Subject: [midcom] [광고]저자직강 CORE VOCA동영상 강좌 무료수강기회 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 신규 회원 가입 이벤트
     
  신규 회원가입 이벤트
  신규회원 가입시 선착순 300명에게 저자직강 Core Vocabulary 강좌 무료 수강기회 제공
    신규회원 가입시 선착순 200명 독일어 모의고사강좌 무료 수강기회 제공
  법무사 교재 제공 이벤트
    법무사 합격패키지(법무사 실무법 수강료 : 157,500원 수강기간 : 120일) 신청자 선착순 20명에게 교재 무료 제공(부등법,공탁법)
  자격시험 패키지
    법무사 헌법(황남기교수)/민법(유정변호사)/형법(이인규교수) 최종정리 패키지 수강료 : 75,000원 수강기간 : 90일
    감정 평가사 강의 개설(민총,물권,경제학,회계학,부동산관계법규)
    공인 중계사 패키지(총 5분야 6과목 수강료 : 150,000원 수강기간 : 150일)
       
     
* 헌법 - 김학성교수, 황남기교수, 이경찬교수, 김명환교수, 차강진교수
* 민법 - 유정변호사, 박성열교수, 김종원교수, 박영태교수, 이창근교수
* 형법 - 이인규박사, 송춘근교수
* 경제학 - 최병권교수
* 행정학 - 김중규박사
이외에 사법시험,행정고시,외무고시등 고등고시 전분야 강좌 개설		   * 현직 실무진과 저명 교수진으로 구성된 자격시험 강좌
* 법무사, 감평사, 변리사, 공인회계사, 공인중계사 등 자격시험 분야의기초,기본,심화 과정과 합격전략 강좌
* 최신의 수험정보제공(합격기,교양강좌,공개강좌,
세심한 수험일정과 수험가 소식등 제공)		   * 행정학 분야의 최고 권위자 김중규 교수, 경찰 간부 실무진 박상근 교수
* 7급,9급공무원 시험,경찰채용시험분야의 기초,기본,심화과정과 합격전략 강좌
* 최신의 수험정보제공(합격기,교양강좌,공개강좌,
세심한 수험일정과 수험가 소식 제공)		   * 코아토플의 저자(김채환교수) 직강, Top 토플 저자(유종건교수) 직강, 프린시피아 저자(성기근교수) 직강,문법특급 저자(고헌석 교수) 직강, 거로보카(강수정교수),중국어(오영남교수)등
* 국가고시의 영어시험 인증제 도입으로 인한 인증시험대비 - TEPS, TOEIC, TOEFL강좌
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 27 13:55:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16120 for ; Wed, 27 Mar 2002 13:55:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00663 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 13:55:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00502; Wed, 27 Mar 2002 13:53:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00473 for ; Wed, 27 Mar 2002 13:52:59 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15935 for ; Wed, 27 Mar 2002 13:52:58 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2RIqQb12907 for ; Wed, 27 Mar 2002 12:52:26 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:52:28 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3906@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Wed, 27 Mar 2002 12:52:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D5C0.8001C000" Subject: [midcom] Protocol Evaluation document template Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1D5C0.8001C000 Content-Type: text/plain; charset="iso-8859-1" Hi all, The protocol evaluation document template is now available at: http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt I won't be submitting this to the archives as the intent would be to get feedback such that the format for the initial protocol evaluation document can be agreed. Section 4 of this template contains the "mandatory" content for the individual protocol evaluations. There are a couple of format items for which I would like feedback, so that we're not arguing these things once we actually get technical content: 1. In section 3, where the protocols are summarized against each of the requirements, I've got a level 3 heading per requirement to match the requirements document section 2. The really pedantic question is whether I should ensure that the protocol evaluation document is also section 2? 2. The second question related to section 3 is with regards to the actual text for the level 3 headings, in section 3.1, I've started copying the headings verbatim from the requirements document. In section 3.3, I've abstract the requirement to a higher level description/tag. Is there a preference? You loose a bit of information in the abstraction, BUT including the text verbatim seems a bit too verbose, however, this does make this document fairly self contained. So, if you have a preference, please let me know now, so that we're not debating this nit later. Also, there had been some discussion during the meeting to have some additional comparison criteria that seemed to be geared towards more general protocol evaluation criteria. I think it's a good idea for some of this to be included in the individual documents, perhaps in the section highlighting the pros/cons of the protocol against the framework. I've not included such things specifically in the template at this time, but will if someone has specific suggestions for which we have WG concensus that these are good criteria. The things I could think of with regards to simplicity (easy to implement), efficiency (small code size, fast code, etc.) and other such protocol "motherhood" requirements tend to be things for which there are implementation tradeoffs and might end up being far more subjective than the comparison against the MIDCOM requirements. However, I think this would be a useful thing to discuss on this list prior to finalizing the proposed document content and format. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 ------_=_NextPart_001_01C1D5C0.8001C000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Protocol Evaluation document template

Hi all,

The protocol evaluation document template is now = available at:
http://www.obsidian97.com/draft-midcom-protocol-eval-t= emplate.txt

I won't be submitting this to the archives as the = intent would be to get feedback such that the format for the initial = protocol evaluation document can be agreed.  Section 4 of this = template contains the "mandatory" content for the individual = protocol evaluations.

There are a couple of format items for which I would = like feedback, so that we're not arguing these things once we actually = get technical content:

1. In section 3, where the protocols are summarized = against each of the requirements, I've got a level 3 heading per = requirement to match the requirements document section 2.  The = really pedantic question is whether I should ensure that the protocol = evaluation document is also section 2?   

2. The second question related to section 3 is with = regards to the actual text for the level 3 headings, in section 3.1, = I've started copying the headings verbatim from the requirements = document. In section 3.3, I've abstract the requirement to a higher = level description/tag.  Is there a preference?  You loose a = bit of information in the abstraction, BUT including the text verbatim = seems a bit too verbose, however, this does make this document fairly = self contained.  So, if you have a preference, please let me know = now, so that we're not debating this nit later.

Also, there had been some discussion during the = meeting to have some additional comparison criteria that seemed to be = geared towards more general protocol evaluation criteria.  I think = it's a good idea for some of this to be included in the individual = documents, perhaps in the section highlighting the pros/cons of the = protocol against the framework.  I've not included such things = specifically in the template at this time, but will if someone has = specific suggestions for which we have WG concensus that these are good = criteria. The things I could think of with regards to simplicity (easy = to implement), efficiency (small code size, fast code, etc.) and other = such protocol "motherhood" requirements tend to be things for = which there are implementation tradeoffs and might end up being far = more subjective than the comparison against the MIDCOM = requirements.  However, I think this would be a useful thing to = discuss on this list prior to finalizing the proposed document content = and format. 

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806






------_=_NextPart_001_01C1D5C0.8001C000-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 27 14:57:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19157 for ; Wed, 27 Mar 2002 14:57:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05550 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 14:57:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05288; Wed, 27 Mar 2002 14:55:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05257 for ; Wed, 27 Mar 2002 14:55:34 -0500 (EST) Received: from localhost ([211.61.65.120]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19110 for ; Wed, 27 Mar 2002 14:55:31 -0500 (EST) Message-Id: <200203271955.OAA19110@ietf.org> Reply-To: jsrkjutkjjwer@hananet.net From: 지영 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 04:54:56 +0900 Subject: [midcom] 테마 누드여행~~~~~~~!!! Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org
   테마 누드여행 ..)a
 
  겨우내 움추렸던 몸과마음을 훌훌 벗어버리고~~!
 
  여행을 떠나자~!
 
  저희 060 - 700 - 4249 만의 특별한 정보
 
  솔로들을 위한   커플만들기
 
  딱 맞는 이성을 만나보세요~~! 
 
  전국 각지의 명승지및 관광지 정보또한 가득하답니다~~~!!
 
  060 - 700 - 4249    060 - 700  - 4249     060 - 700 - 4249 
 
 칠공공    사이사구~~   사이사구~   
본 메일은 정보통신부 권고 사항에 의거 제목에 [광고]라 표시된 광고 메일입니다.
수신거부 버튼을 클릭하시면 수신거부처리가 이루어 집니다.
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 27 15:00:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19306 for ; Wed, 27 Mar 2002 15:00:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05770 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 15:00:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05389; Wed, 27 Mar 2002 14:55:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05300 for ; Wed, 27 Mar 2002 14:55:45 -0500 (EST) Received: from localhost ([211.61.65.120]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19114 for ; Wed, 27 Mar 2002 14:55:39 -0500 (EST) Message-Id: <200203271955.OAA19114@ietf.org> Reply-To: test1@test.com From: 소영 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 04:55:40 +0900 Subject: [midcom] 테마누드여행 ..)a Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org
   테마 누드여행 ..)a

  겨우내 움추렸던 몸과마음을 훌훌 벗어버리고~~!

  여행을 떠나자~!

  저희 060- 700 -4249 만의 특별한 정보 ~!

  솔로들을 위한 커플만들기 ~!

  딱 맞는 이성을 만나보세요~~! 

  전국 각지의 명승지및 관광지 정보또한 가득하답니다~~!

  060 - 700 - 4249    060 - 700 -4249     060 -700 -4249 

  칠공공 사이사구~~ 사이사구~   
본 메일은 정보통신부 권고 사항에 의거 제목에 [광고]라 표시된 광고 메일입니다.
수신거부 버튼을 클릭하시면 수신거부처리가 이루어 집니다.
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 27 15:50:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22165 for ; Wed, 27 Mar 2002 15:50:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09728 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 15:50:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09602; Wed, 27 Mar 2002 15:48:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09572 for ; Wed, 27 Mar 2002 15:48:17 -0500 (EST) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22095 for ; Wed, 27 Mar 2002 15:48:15 -0500 (EST) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RKm2e29890; Wed, 27 Mar 2002 12:48:02 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RKmE519778; Wed, 27 Mar 2002 12:48:14 -0800 (PST) Subject: Re: [midcom] Protocol Evaluation document template To: "Mary Barnes" Cc: "'midcom@ietf.org'" Date: Wed, 27 Mar 2002 14:39:10 -0600 Message-ID: MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=86256B89007179F38f9e8a93df938690918c86256B89007179F3" Content-Disposition: inline Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --0__=86256B89007179F38f9e8a93df938690918c86256B89007179F3 Content-type: text/plain; charset=us-ascii Mary, As I indicated in the MIDCOM session last Thursday, 3Com / CommWorks will contribute to the evaluation of the RSIP protcol (RFCs 3102 ff.). We would like to lead that evaluation, and will welcome anyone that would like to work with us on it. If anyone else volunteers for this, please have them contact me. Thanks in advance, Jim Renkel Director, Advanced Technology & System Engineering The CommWorks Corp., a 3Com company "Mary Barnes"@ietf.org on 03/27/2002 12:52:10 PM Sent by: midcom-admin@ietf.org To: "'midcom @ietf.org'" cc: Subject: [midcom] Protocol Evaluation document template Hi all, The protocol evaluation document template is now available at: http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt I won't be submitting this to the archives as the intent would be to get feedback such that the format for the initial protocol evaluation document can be agreed. Section 4 of this template contains the "mandatory" content for the individual protocol evaluations. There are a couple of format items for which I would like feedback, so that we're not arguing these things once we actually get technical content: 1. In section 3, where the protocols are summarized against each of the requirements, I've got a level 3 heading per requirement to match the requirements document section 2. The really pedantic question is whether I should ensure that the protocol evaluation document is also section 2? 2. The second question related to section 3 is with regards to the actual text for the level 3 headings, in section 3.1, I've started copying the headings verbatim from the requirements document. In section 3.3, I've abstract the requirement to a higher level description/tag. Is there a preference? You loose a bit of information in the abstraction, BUT including the text verbatim seems a bit too verbose, however, this does make this document fairly self contained. So, if you have a preference, please let me know now, so that we're not debating this nit later. Also, there had been some discussion during the meeting to have some additional comparison criteria that seemed to be geared towards more general protocol evaluation criteria. I think it's a good idea for some of this to be included in the individual documents, perhaps in the section highlighting the pros/cons of the protocol against the framework. I've not included such things specifically in the template at this time, but will if someone has specific suggestions for which we have WG concensus that these are good criteria. The things I could think of with regards to simplicity (easy to implement), efficiency (small code size, fast code, etc.) and other such protocol "motherhood" requirements tend to be things for which there are implementation tradeoffs and might end up being far more subjective than the comparison against the MIDCOM requirements. However, I think this would be a useful thing to discuss on this list prior to finalizing the proposed document content and format. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 (See attached file: C.htm) --0__=86256B89007179F38f9e8a93df938690918c86256B89007179F3 Content-type: text/html; name="C.htm" Content-Disposition: attachment; filename="C.htm" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC44OSI+DQo8VElUTEU+UHJvdG9j b2wgRXZhbHVhdGlvbiBkb2N1bWVudCB0ZW1wbGF0ZTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4N Cg0KPFA+PEZPTlQgU0laRT0yPkhpIGFsbCw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj5UaGUgcHJvdG9jb2wgZXZhbHVhdGlvbiBkb2N1bWVudCB0ZW1wbGF0ZSBpcyBub3cgYXZhaWxh YmxlIGF0OjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+PEEgSFJFRj0iaHR0cDovL3d3dy5vYnNp ZGlhbjk3LmNvbS9kcmFmdC1taWRjb20tcHJvdG9jb2wtZXZhbC10ZW1wbGF0ZS50eHQiIFRBUkdF VD0iX2JsYW5rIj5odHRwOi8vd3d3Lm9ic2lkaWFuOTcuY29tL2RyYWZ0LW1pZGNvbS1wcm90b2Nv bC1ldmFsLXRlbXBsYXRlLnR4dDwvQT48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5J IHdvbid0IGJlIHN1Ym1pdHRpbmcgdGhpcyB0byB0aGUgYXJjaGl2ZXMgYXMgdGhlIGludGVudCB3 b3VsZCBiZSB0byBnZXQgZmVlZGJhY2sgc3VjaCB0aGF0IHRoZSBmb3JtYXQgZm9yIHRoZSBpbml0 aWFsIHByb3RvY29sIGV2YWx1YXRpb24gZG9jdW1lbnQgY2FuIGJlIGFncmVlZC4mbmJzcDsgU2Vj dGlvbiA0IG9mIHRoaXMgdGVtcGxhdGUgY29udGFpbnMgdGhlICZxdW90O21hbmRhdG9yeSZxdW90 OyBjb250ZW50IGZvciB0aGUgaW5kaXZpZHVhbCBwcm90b2NvbCBldmFsdWF0aW9ucy4gPC9GT05U PjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlRoZXJlIGFyZSBhIGNvdXBsZSBvZiBmb3JtYXQgaXRl bXMgZm9yIHdoaWNoIEkgd291bGQgbGlrZSBmZWVkYmFjaywgc28gdGhhdCB3ZSdyZSBub3QgYXJn dWluZyB0aGVzZSB0aGluZ3Mgb25jZSB3ZSBhY3R1YWxseSBnZXQgdGVjaG5pY2FsIGNvbnRlbnQ6 PC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPjEuIEluIHNlY3Rpb24gMywgd2hlcmUgdGhl IHByb3RvY29scyBhcmUgc3VtbWFyaXplZCBhZ2FpbnN0IGVhY2ggb2YgdGhlIHJlcXVpcmVtZW50 cywgSSd2ZSBnb3QgYSBsZXZlbCAzIGhlYWRpbmcgcGVyIHJlcXVpcmVtZW50IHRvIG1hdGNoIHRo ZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgc2VjdGlvbiAyLiZuYnNwOyBUaGUgcmVhbGx5IHBlZGFu dGljIHF1ZXN0aW9uIGlzIHdoZXRoZXIgSSBzaG91bGQgZW5zdXJlIHRoYXQgdGhlIHByb3RvY29s IGV2YWx1YXRpb24gZG9jdW1lbnQgaXMgYWxzbyBzZWN0aW9uIDI/Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4yLiBUaGUgc2Vjb25kIHF1ZXN0aW9uIHJl bGF0ZWQgdG8gc2VjdGlvbiAzIGlzIHdpdGggcmVnYXJkcyB0byB0aGUgYWN0dWFsIHRleHQgZm9y IHRoZSBsZXZlbCAzIGhlYWRpbmdzLCBpbiBzZWN0aW9uIDMuMSwgSSd2ZSBzdGFydGVkIGNvcHlp bmcgdGhlIGhlYWRpbmdzIHZlcmJhdGltIGZyb20gdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudC4g SW4gc2VjdGlvbiAzLjMsIEkndmUgYWJzdHJhY3QgdGhlIHJlcXVpcmVtZW50IHRvIGEgaGlnaGVy IGxldmVsIGRlc2NyaXB0aW9uL3RhZy4mbmJzcDsgSXMgdGhlcmUgYSBwcmVmZXJlbmNlPyZuYnNw OyBZb3UgbG9vc2UgYSBiaXQgb2YgaW5mb3JtYXRpb24gaW4gdGhlIGFic3RyYWN0aW9uLCBCVVQg aW5jbHVkaW5nIHRoZSB0ZXh0IHZlcmJhdGltIHNlZW1zIGEgYml0IHRvbyB2ZXJib3NlLCBob3dl dmVyLCB0aGlzIGRvZXMgbWFrZSB0aGlzIGRvY3VtZW50IGZhaXJseSBzZWxmIGNvbnRhaW5lZC4m bmJzcDsgU28sIGlmIHlvdSBoYXZlIGEgcHJlZmVyZW5jZSwgcGxlYXNlIGxldCBtZSBrbm93IG5v dywgc28gdGhhdCB3ZSdyZSBub3QgZGViYXRpbmcgdGhpcyBuaXQgbGF0ZXIuPC9GT05UPjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPkFsc28sIHRoZXJlIGhhZCBiZWVuIHNvbWUgZGlzY3Vzc2lvbiBk dXJpbmcgdGhlIG1lZXRpbmcgdG8gaGF2ZSBzb21lIGFkZGl0aW9uYWwgY29tcGFyaXNvbiBjcml0 ZXJpYSB0aGF0IHNlZW1lZCB0byBiZSBnZWFyZWQgdG93YXJkcyBtb3JlIGdlbmVyYWwgcHJvdG9j b2wgZXZhbHVhdGlvbiBjcml0ZXJpYS4mbmJzcDsgSSB0aGluayBpdCdzIGEgZ29vZCBpZGVhIGZv ciBzb21lIG9mIHRoaXMgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIGluZGl2aWR1YWwgZG9jdW1lbnRz LCBwZXJoYXBzIGluIHRoZSBzZWN0aW9uIGhpZ2hsaWdodGluZyB0aGUgcHJvcy9jb25zIG9mIHRo ZSBwcm90b2NvbCBhZ2FpbnN0IHRoZSBmcmFtZXdvcmsuJm5ic3A7IEkndmUgbm90IGluY2x1ZGVk IHN1Y2ggdGhpbmdzIHNwZWNpZmljYWxseSBpbiB0aGUgdGVtcGxhdGUgYXQgdGhpcyB0aW1lLCBi dXQgd2lsbCBpZiBzb21lb25lIGhhcyBzcGVjaWZpYyBzdWdnZXN0aW9ucyBmb3Igd2hpY2ggd2Ug aGF2ZSBXRyBjb25jZW5zdXMgdGhhdCB0aGVzZSBhcmUgZ29vZCBjcml0ZXJpYS4gVGhlIHRoaW5n cyBJIGNvdWxkIHRoaW5rIG9mIHdpdGggcmVnYXJkcyB0byBzaW1wbGljaXR5IChlYXN5IHRvIGlt cGxlbWVudCksIGVmZmljaWVuY3kgKHNtYWxsIGNvZGUgc2l6ZSwgZmFzdCBjb2RlLCBldGMuKSBh bmQgb3RoZXIgc3VjaCBwcm90b2NvbCAmcXVvdDttb3RoZXJob29kJnF1b3Q7IHJlcXVpcmVtZW50 cyB0ZW5kIHRvIGJlIHRoaW5ncyBmb3Igd2hpY2ggdGhlcmUgYXJlIGltcGxlbWVudGF0aW9uIHRy YWRlb2ZmcyBhbmQgbWlnaHQgZW5kIHVwIGJlaW5nIGZhciBtb3JlIHN1YmplY3RpdmUgdGhhbiB0 aGUgY29tcGFyaXNvbiBhZ2FpbnN0IHRoZSBNSURDT00gcmVxdWlyZW1lbnRzLiZuYnNwOyBIb3dl dmVyLCBJIHRoaW5rIHRoaXMgd291bGQgYmUgYSB1c2VmdWwgdGhpbmcgdG8gZGlzY3VzcyBvbiB0 aGlzIGxpc3QgcHJpb3IgdG8gZmluYWxpemluZyB0aGUgcHJvcG9zZWQgZG9jdW1lbnQgY29udGVu dCBhbmQgZm9ybWF0LiZuYnNwOyA8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+UmVnYXJk cyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPk1hcnkgSC4gQmFybmVzPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj5tYmFybmVzQG5vcnRlbG5ldHdvcmtzLmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+OTcyLTY4NC01NDMyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5XaXJlbGVzcyA4MTct NzAzLTQ4MDY8L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQoNCjwv Qk9EWT4NCjwvSFRNTD4= --0__=86256B89007179F38f9e8a93df938690918c86256B89007179F3-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 27 15:59:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22537 for ; Wed, 27 Mar 2002 15:59:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10348 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 15:59:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09871; Wed, 27 Mar 2002 15:53:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09842 for ; Wed, 27 Mar 2002 15:53:10 -0500 (EST) Received: from localhost ([211.212.67.113]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22217 for ; Wed, 27 Mar 2002 15:51:28 -0500 (EST) Message-Id: <200203272051.PAA22217@ietf.org> Reply-To: mailad1004@yahoo From: 메일천사 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 05:46:58 +0900 Subject: [midcom] [광고]* 무료로 회계/급여,부가가치세 프로그램을 드립니다. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 회계/급여, 부가가치세 프로그램을 "무상" 지원합니다.
※ 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다.
※ e-mail주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다
※ e-mail 수신을 원치 않으시면 수신 거부를 보내주시면 메일 리스트에서 삭제하겠습니다.
  정부에서는 2003년까지 3만개의 중소기업을 대상으로 IT화 지원사업을 벌이고 있습니다.
중소기업진흥공단 주관으로 실시되고 있는 본 사업은정보화를 추진하고자 하는 중소기업에
대해 업종별, 규모별로 정보화 수준에 맞는 사내 IT 화를 지원하여 기업 경영의 효율성과
경쟁력 을 높이는데 그 목적이 있습니다.

  ○'중소기업기본법＇상 중소기업 (상시 종업원수 5인 이상 중소기업)
○ 인사/급여, 회계, 판매/영업, 생산, 자재/조달, 물류, 원가 등 2개 이상 단위 업무를 통합
지원 하는 S/W를 신규 또는추가 도입하여 IT화를 추진하고자 하는 중소기업
○ 현재 사용중인 기초정보 S/W의 기능을 개선(Up-grade)하고자 하는 중소기업

  ○ 기초정보 S/W 무상제공
○ 교육, 컨설팅, 커스터마이징 비용 지원 (기업당 100만원 한도)
  


  

※ 모든 비용은 정부에서 지원합니다.

   (Kicom.net 에이전트)

주소: 서울시 용산구 한강로2가 16-1 대닉스 B/D
담당자: IT 정보화 지원팀

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 27 16:07:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23145 for ; Wed, 27 Mar 2002 16:07:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11864 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 16:07:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11530; Wed, 27 Mar 2002 16:04:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11488 for ; Wed, 27 Mar 2002 16:04:57 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22920 for ; Wed, 27 Mar 2002 16:04:54 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2RL4QK13183; Wed, 27 Mar 2002 13:04:26 -0800 (PST) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADI74166; Wed, 27 Mar 2002 13:02:01 -0800 (PST) Message-Id: <5.1.0.14.0.20020327160627.00a76d40@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Mar 2002 16:08:09 -0500 To: James_Renkel@3com.com, "Mary Barnes" From: Melinda Shore Subject: Re: [midcom] Protocol Evaluation document template Cc: "'midcom@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:39 PM 3/27/02 -0600, James_Renkel@3com.com wrote: >As I indicated in the MIDCOM session last Thursday, 3Com / CommWorks >will contribute to the evaluation of the RSIP protcol (RFCs 3102 ff.). >We would like to lead that evaluation, and will welcome anyone that >would like to work with us on it. If anyone else volunteers for this, >please have them contact me. By way of reminder, in the IETF the work is done by individual contributors rather than by companies. We'll need for the individual who wants to work on the RSIP evaluation to identify him/herself. Many thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Mar 27 16:28:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24749 for ; Wed, 27 Mar 2002 16:28:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14500 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 16:28:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14327; Wed, 27 Mar 2002 16:26:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14297 for ; Wed, 27 Mar 2002 16:26:53 -0500 (EST) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24652 for ; Wed, 27 Mar 2002 16:26:50 -0500 (EST) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RLQRe04985; Wed, 27 Mar 2002 13:26:27 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RLQd525377; Wed, 27 Mar 2002 13:26:39 -0800 (PST) Subject: Re: [midcom] Protocol Evaluation document template To: Melinda Shore Cc: "Mary Barnes", "'midcom@ietf.org'" Date: Wed, 27 Mar 2002 15:26:05 -0600 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Melinda, I will be doing the RSIP evaluation work myself. Should anyone else at 3Com / CommWorks work with me on this, I will identify them as soon as their participation begins. If you need anymore information on this, don't hesitate to ask. Jim Renkel Director, Advanced Technology & System Engineering The CommWorks Corp., a 3Com company e-mail: james_renkel@commworks.com Melinda Shore @ietf.org on 03/27/2002 03:08:09 PM Sent by: midcom-admin@ietf.org To: James Renkel/MW/US/3Com, "Mary Barnes" cc: "'midcom @ietf.org'" Subject: Re: [midcom] Protocol Evaluation document template At 02:39 PM 3/27/02 -0600, James_Renkel@3com.com wrote: >As I indicated in the MIDCOM session last Thursday, 3Com / CommWorks >will contribute to the evaluation of the RSIP protcol (RFCs 3102 ff.). >We would like to lead that evaluation, and will welcome anyone that >would like to work with us on it. If anyone else volunteers for this, >please have them contact me. By way of reminder, in the IETF the work is done by individual contributors rather than by companies. We'll need for the individual who wants to work on the RSIP evaluation to identify him/herself. Many 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 daemon@optimus.ietf.org Wed Mar 27 22:17:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04111 for ; Wed, 27 Mar 2002 22:17:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA06077 for midcom-archive@odin.ietf.org; Wed, 27 Mar 2002 22:17:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05919; Wed, 27 Mar 2002 22:09:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05888 for ; Wed, 27 Mar 2002 22:09:26 -0500 (EST) Received: from favskin.com ([218.50.39.54]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04010 for ; Wed, 27 Mar 2002 22:09:24 -0500 (EST) Message-Id: <200203280309.WAA04010@ietf.org> Reply-To: favskin@favskin.com From: 패브스킨 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 12:08:58 +0900 Subject: [midcom] [광고]겨우내 지친 피부를 하얗게 되살리세요.. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org ::www.favskin.com::
허락없이 메일을 보낸점 깊이 사과 드립니다.
혹시, 유용한 자료가 되지 않을까 하여 보내드리오니 넓으신 아량으로 이해 바랍니다.
본 메일은 1회만 발송된 것입니다. 귀하의 E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다.
정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다.
원치 않으면[수신거부]를 눌러주세요.
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 28 05:41:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20762 for ; Thu, 28 Mar 2002 05:41:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA08324 for midcom-archive@odin.ietf.org; Thu, 28 Mar 2002 05:41:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08080; Thu, 28 Mar 2002 05:35:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08048 for ; Thu, 28 Mar 2002 05:35:56 -0500 (EST) Received: from localhost ([61.74.172.186]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20687 for ; Thu, 28 Mar 2002 05:35:50 -0500 (EST) Message-Id: <200203281035.FAA20687@ietf.org> Reply-To: test@test.com From: "앤[Anne]" To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 19:33:36 +0900 Subject: [midcom] 알뜰정보[호/보]:[드레스]필요한 분들에게는 소중한 정보입니다. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 알뜰정보 :  필요한 분들에게는 소중한 정보입니다.
 
알뜰정보 : 필요한 분들에게는 소중한 정보입니다.
                      아래의 내용을 확인해 주세요.                                감사합니다.

bc010w100.jpg (2175 bytes)l100.jpg (2005 bytes)n100.jpg (2122 bytes)y100.jpg (2050 bytes)tk100.jpg (2194 bytes)tt100.jpg (2147 bytes)yb100.jpg (2304 bytes)

fd018-100.jpg (2427 bytes)ba104-100.jpg (2331 bytes)fd005-100.jpg (2465 bytes)fd010-100.jpg (2561 bytes)ba121-100.jpg (2144 bytes)fd002-100.jpg (2017 bytes)

littleanne-girldress70.jpg (3636 bytes)

weddingbeati70.jpg (4238 bytes)

girl-01.jpg (2538 bytes)# 공동구매 가격보다 낮게 책정되었습니다. #

*. 본 홍보메일로 절약되는 - 홍보비용까지 할인한 가격으로 인터넷 온라인 반짝 세일을 합니다.

CLICK HERE

*.한정수량 판매로, 주문과 입금순으로 판매합니다.
수량이 많지 않은 관계로 조기 품절될 수 있습니다.

ba113-150.jpg (3648 bytes)*.웨딩베아띠에서 수출로 인한 - STOCK WEDDING GOWN에 한하여, WEDDING PACKAGE상품으로
(한정수량) 할인 SALE합니다. DESIGN별로 STOCK량이 1~2벌 정도이므로, 서둘러야 원하시는 디자인을 선택하실 수가 있습니다.

*.본 홍보메일을 통해, 견적을 문의하시고 계약을 하시는 분에게는 작으나마 감사의 혜택을 준비하겠습니다.
    >>> 홍보메일을 보고 견적문의

"본 메일은 2~3개월에 1회 정도 발송할 예정입니다. 본 메일[필요한 분들에게는 소중한 정보입니다]의 정보가 필요하신 분은 [정기구독]을 신청하시고, 불필요 하신분은 수신거부를 하시면 됩니다. 본 E-mail은 정보통신망이용촉진 및 정보보호등에 관한법률에 의거하여 수신자께서 [수신거부]의사를 회신으로 밝힌 후에는 또다시 보내지 않습니다.  본 E-mail을 받고 혹, 기분이 상하셨다면 너그러우신 마음으로 양해바랍니다."

         

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 28 06:21:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21260 for ; Thu, 28 Mar 2002 06:21:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA10495 for midcom-archive@odin.ietf.org; Thu, 28 Mar 2002 06:21:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09873; Thu, 28 Mar 2002 06:18:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09702 for ; Thu, 28 Mar 2002 06:17:55 -0500 (EST) Received: from localhost ([211.219.142.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21109 for ; Thu, 28 Mar 2002 06:17:51 -0500 (EST) Message-Id: <200203281117.GAA21109@ietf.org> Reply-To: abc@eintech.co.jp.kr From: AVCAFE To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 20:16:21 +0900 Subject: [midcom] [광고]세계 최초 휴대용 디지털 어학기 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Untitled Document




  본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고]메일입니다
  귀하의 E-MAIL은 게시판 등 인터넷 상에서 알게 되었으며, E-mail을 제외한 어떠한 정보도 알지 못함을 밝힙니다.
  메일을 수신하고 싶지 않으시면 [수신 거부]를 클릭해 주십시오.
  전송자 : AV 전문쇼핑몰 AVcafe
  연락처 : mailing@eintech.co.kr
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 28 07:07:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22274 for ; Thu, 28 Mar 2002 07:07:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA12596 for midcom-archive@odin.ietf.org; Thu, 28 Mar 2002 07:07:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12480; Thu, 28 Mar 2002 07:04:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12443 for ; Thu, 28 Mar 2002 07:04:48 -0500 (EST) Received: from localhost ([211.227.73.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22030 for ; Thu, 28 Mar 2002 07:04:44 -0500 (EST) Message-Id: <200203281204.HAA22030@ietf.org> Reply-To: riches7@simmani.com From: 백만장자클럽 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 21:04:47 +0900 Subject: [midcom] 백만장자클럽 안내(무료가입)[광*고] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 백만장자 클럽입니다.

                       누구나 직접 자신의 사업체를 경영해 볼 수 있습니다.
                        기존에 오프라인에서 실천을 해보고자 하면 엄청난
                  자본과 세월이 소요되지만  실제 체험을 통한 진행방식
                  으로 백만장자 의 꿈을 실현시킬 수 있을 것입니다.

 

귀하의 메일주소는 웹 서핑중에 알게 된 것이며
정보통신부 권고 사항에 의거 제목에 [광고]라고 표기한 광고 메일입니다.
이메일은 1회만 보낼 것이며, 수신을 원치 않으시면
수신거부버튼을 클릭하시면 재발송하지 않겠습니다.

_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 28 08:54:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25751 for ; Thu, 28 Mar 2002 08:54:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA17284 for midcom-archive@odin.ietf.org; Thu, 28 Mar 2002 08:54:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17179; Thu, 28 Mar 2002 08:51:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17148 for ; Thu, 28 Mar 2002 08:51:26 -0500 (EST) Received: from neoever.com ([211.208.182.61]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25607 for ; Thu, 28 Mar 2002 08:51:22 -0500 (EST) Message-Id: <200203281351.IAA25607@ietf.org> Reply-To: neoever@neoever.com From: 네오에버 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 22:51:24 +0900 Subject: [midcom] 따뜻한 봄날 아직도 애인이 없으신가요? [광고] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 네오에버 - 어른들의 인터넷 세상
※ If you recieve this e-mail, please click the rejection button. [rejection]
※ Because of operation error, this e-mail may be delivered.
※ Please click the rejection button, and a measure suited to the rejection will be done.
※ 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다
※ e-mail주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다
※ DB오류로 인하여 약간의 메일이 복수발송 될수 있습니다. 아래 담당자에게 메일주시면 즉시 조치해
    드리겠습니다. 수신거부를 원하시면 아래 수신거부버튼을 눌러주세요.
미팅 : 이보다 물이 좋을 순 없다.!! 부킹 100 % !!
채팅 : 실시간으로 진행되는 채팅& 연인과의 1:1 데이트를 즐기세요~
게임 : 고도리, 포커, 테트리스등최고 인기 게임이한자리에 !!
만화 : 무협만화, 순정만화, 성인만화, 드라마등 의 최신작을 만나보세요~
영화 : 한국영화관, 외국관, 성인관 취향대로 골라보세요 ~
운세 : 연인과의 궁합, 사주, 띠별운세 등의 운을 점쳐보세요~
어른들만의 인터넷 세상을 만들어 나가는 네오에버가 오픈 기념 이벤트를
마련하였습니다. 인터넷을 통해서 회원님들의 좋은 만남이 이루어지길 기원합니다.
이벤트 기간 : 2002년 3월 19일 ~ 2002년
대상 : 정회원에 가입하시는 모든 여성회원
발표 : 2002년 4월 25일
공지 : 네오에버 사이트 공지 게시판과 회원님의 메일
어른들만의 인터넷 세상 네오에버 www.neoever.com

※ 본 메일은 정보통신부 권고 사항에 의거제목에 [광고]라 표시된 광고 메일입니다.
※ 수신거부
버튼을 클릭하시면 수신거부처리가 이루어 집니다.
_______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 28 18:12:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19055 for ; Thu, 28 Mar 2002 18:12:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20996 for midcom-archive@odin.ietf.org; Thu, 28 Mar 2002 18:12:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20920; Thu, 28 Mar 2002 18:10:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20889 for ; Thu, 28 Mar 2002 18:10:30 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19039 for ; Thu, 28 Mar 2002 18:10:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2SNAvTE019388; Thu, 28 Mar 2002 18:10:57 -0500 (EST) Message-ID: <3CA3A2BD.CDFA36A@dynamicsoft.com> Date: Thu, 28 Mar 2002 18:09:49 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mary Barnes CC: "'midcom@ietf.org'" Subject: Re: [midcom] Protocol Evaluation document template References: <1B54FA3A2709D51195C800508BF9386A03DE3906@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I must admit that I really feel that this approach is still quite broken. The requirements documents are at a high enough level that I do not see how they would be used to rule out or support protocols. Just about any sensible protocol that supports a session oriented communication between two things, with messages in both directions, will meet the requirements. Thus, the protocol analysis work will enter the swamps of "efficient" and "simple" and "easier to work with" and other things that are the source of unending debate on other lists. As an example, the fact that we will be having an analysis of BOTH RSIP and MEGACO for suitability, when these are such vastly different protocols, tells me that we are in for a long and mostly futile debate. Furthermore, this tactic makes no sense when, in parallel, we have decided to move forward and specify the protocol abstractly anyway. I would really like to understand why we cannot just specify the abstract protocol completely FIRST, and then evaluate concrete protocols SECOND. This makes much more sense, since we will know EXACTLY how well each candidate protocol fits. I would also welcome comments from our ADs, as I understand they have been the motivating force behind this comparison work. -Jonathan R. Mary Barnes wrote: > > Hi all, > > The protocol evaluation document template is now available at: > http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt > > > I won't be submitting this to the archives as the intent would be to get > feedback such that the format for the initial protocol evaluation > document can be agreed. Section 4 of this template contains the > "mandatory" content for the individual protocol evaluations. > > There are a couple of format items for which I would like feedback, so > that we're not arguing these things once we actually get technical > content: > > 1. In section 3, where the protocols are summarized against each of the > requirements, I've got a level 3 heading per requirement to match the > requirements document section 2. The really pedantic question is > whether I should ensure that the protocol evaluation document is also > section 2? > > 2. The second question related to section 3 is with regards to the > actual text for the level 3 headings, in section 3.1, I've started > copying the headings verbatim from the requirements document. In section > 3.3, I've abstract the requirement to a higher level description/tag. > Is there a preference? You loose a bit of information in the > abstraction, BUT including the text verbatim seems a bit too verbose, > however, this does make this document fairly self contained. So, if you > have a preference, please let me know now, so that we're not debating > this nit later. > > Also, there had been some discussion during the meeting to have some > additional comparison criteria that seemed to be geared towards more > general protocol evaluation criteria. I think it's a good idea for some > of this to be included in the individual documents, perhaps in the > section highlighting the pros/cons of the protocol against the > framework. I've not included such things specifically in the template > at this time, but will if someone has specific suggestions for which we > have WG concensus that these are good criteria. The things I could think > of with regards to simplicity (easy to implement), efficiency (small > code size, fast code, etc.) and other such protocol "motherhood" > requirements tend to be things for which there are implementation > tradeoffs and might end up being far more subjective than the comparison > against the MIDCOM requirements. However, I think this would be a > useful thing to discuss on this list prior to finalizing the proposed > document content and format. > > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > 972-684-5432 > Wireless 817-703-4806 -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 28 18:25:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19191 for ; Thu, 28 Mar 2002 18:25:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21339 for midcom-archive@odin.ietf.org; Thu, 28 Mar 2002 18:25:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21313; Thu, 28 Mar 2002 18:24:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21283 for ; Thu, 28 Mar 2002 18:24:22 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19168 for ; Thu, 28 Mar 2002 18:24:16 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2SNNoY04263; Thu, 28 Mar 2002 15:23:50 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADJ12862; Thu, 28 Mar 2002 15:21:26 -0800 (PST) Message-Id: <5.1.0.14.0.20020328181716.00a849e0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Mar 2002 18:27:24 -0500 To: Jonathan Rosenberg , Mary Barnes From: Melinda Shore Subject: Re: [midcom] Protocol Evaluation document template Cc: "'midcom@ietf.org'" In-Reply-To: <3CA3A2BD.CDFA36A@dynamicsoft.com> References: <1B54FA3A2709D51195C800508BF9386A03DE3906@zrc2c000.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 06:09 PM 3/28/02 -0500, Jonathan Rosenberg wrote: >The requirements documents are at a high enough level that I do not see >how they would be used to rule out or support protocols. Just about any >sensible protocol that supports a session oriented communication between >two things, with messages in both directions, will meet the >requirements. Right. I think there may be some confusion at work, though - the protocol "evaluation" document is not a protocol recommendation document - the decision about which protocol will ultimately be used will take place after the evaluation document is complete. By then the semantics document should be done or nearly done, although I'm somewhat disappointed that there hasn't been one response to the proposal that Tom has put out and there haven't been any other proposals put forward. And, frankly, I don't think that the semantics we settle on are going to have that much discriminatory power. I understand your concern but I think we're okay. If you're familiar with "Indiana Jones and the Last Crusade" you may recall the scene in which he steps into the abyss only to find that there's actually an invisible bridge there. It's possible that there's no bridge here, but I'm willing to try it anyway. I really don't want to delay starting the protocol evaluation until the semantics are put together - it would end up taking us over a year to finish. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Mar 28 19:55:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20551 for ; Thu, 28 Mar 2002 19:55:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA24761 for midcom-archive@odin.ietf.org; Thu, 28 Mar 2002 19:55:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24709; Thu, 28 Mar 2002 19:53:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24680 for ; Thu, 28 Mar 2002 19:53:32 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20529 for ; Thu, 28 Mar 2002 19:53:28 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g2T0qiB17719; Thu, 28 Mar 2002 19:52:44 -0500 (EST) Date: Thu, 28 Mar 2002 19:52:44 -0500 (EST) From: Scott Bradner Message-Id: <200203290052.g2T0qiB17719@newdev.harvard.edu> To: jdrosen@dynamicsoft.com, mbarnes@nortelnetworks.com Subject: Re: [midcom] Protocol Evaluation document template Cc: midcom@ietf.org Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > I would really like to understand why we cannot just specify the > abstract protocol completely FIRST, and then evaluate concrete protocols > SECOND. This makes much more sense, since we will know EXACTLY how well > each candidate protocol fits. seems like a lot of work to specify an abstract protocol but if the WG feels that would be a more efficient way to proceed it would be OK by me (as AD) but its not actually my call - the WG chair is front line "management" Scott _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 29 08:56:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13506 for ; Fri, 29 Mar 2002 08:56:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07521 for midcom-archive@odin.ietf.org; Fri, 29 Mar 2002 08:56:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07337; Fri, 29 Mar 2002 08:55:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27916 for ; Fri, 29 Mar 2002 04:56:51 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07626 for ; Fri, 29 Mar 2002 04:56:45 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g2T9uEQ30021; Fri, 29 Mar 2002 10:56:14 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA03117; Fri, 29 Mar 2002 10:56:12 +0100 Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 897C336B93; Fri, 29 Mar 2002 10:56:11 +0100 (CET) Cc: "'midcom@ietf.org'" , Jonathan Rosenberg , Mary Barnes X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen References: <1B54FA3A2709D51195C800508BF9386A03DE3906@zrc2c000.us.nortel.com> <5.1.0.14.0.20020328181716.00a849e0@localhost> From: Martin Stiemerling MIME-Version: 1.0 Subject: Re: [midcom] Protocol Evaluation document template To: Melinda Shore Content-type: text/plain; charset= "iso-8859-1" Date: Fri, 29 Mar 2002 10:56:11 +0100 Content-transfer-encoding: 7bit Message-Id: <20020329095611.897C336B93@imap.heidelberg.ccrle.nec.de> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi, please find my comment inline (just a short comment, because I'm on holidays). > Right. I think there may be some confusion at work, though - > the protocol "evaluation" document is not a protocol recommendation > document - the decision about which protocol will ultimately be > used will take place after the evaluation document is complete. > By then the semantics document should be done or nearly done, > although I'm somewhat disappointed that there hasn't been one response > to the proposal that Tom has put out and there haven't been any other That there haven't been any response or other proposal does not mean that nobody is working on this topic. I'm currently working on some protocl semantics, but as always it takes some days to get everything right on the paper. As well I have talked shortly with Tom on this. I hope I can provide some notes on Monday . Martin > proposals put forward. And, frankly, I don't think that the semantics > we settle on are going to have that much discriminatory power. > > I understand your concern but I think we're okay. If you're familiar > with "Indiana Jones and the Last Crusade" you may recall the scene in > which he steps into the abyss only to find that there's actually an > invisible bridge there. It's possible that there's no bridge here, > but I'm willing to try it anyway. I really don't want to delay starting > the protocol evaluation until the semantics are put together - it would > end up taking us over a year to finish. > > 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 daemon@optimus.ietf.org Fri Mar 29 09:43:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13500 for ; Fri, 29 Mar 2002 08:56:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07507 for midcom-archive@odin.ietf.org; Fri, 29 Mar 2002 08:56:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07363; Fri, 29 Mar 2002 08:55:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05091 for ; Fri, 29 Mar 2002 08:00:43 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10718 for ; Fri, 29 Mar 2002 08:00:37 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2TD07Y13137 for ; Fri, 29 Mar 2002 05:00:09 -0800 (PST) Received: from SBRIM-W2K.cisco.com (rtp-vpn2-577.cisco.com [10.82.242.65]) by airborne.cisco.com (Mirapoint) with ESMTP id AAW61274; Fri, 29 Mar 2002 04:59:55 -0800 (PST) X-Mailer: emacs 21.1.1 (via feedmail 11-beta-1 I); VM 7.01 under Emacs 21.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15524.25940.69000.539430@gargle.gargle.HOWL> Date: Fri, 29 Mar 2002 08:00:04 -0500 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Protocol Evaluation document template In-Reply-To: <200203290052.g2T0qiB17719@newdev.harvard.edu> References: <200203290052.g2T0qiB17719@newdev.harvard.edu> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 28 Mar 2002 at 19:52 -0500, Scott Bradner allegedly wrote: > > I would really like to understand why we cannot just specify the > > abstract protocol completely FIRST, and then evaluate concrete protocols > > SECOND. This makes much more sense, since we will know EXACTLY how well > > each candidate protocol fits. > > seems like a lot of work to specify an abstract protocol but if the WG > feels that would be a more efficient way to proceed it would be OK > by me (as AD) but its not actually my call - the WG chair is front line > "management" A bit of iteration is in order. The two questions are "where do we want to go" and "will this get us there", but the answer to the first depends partly on what you are looking at when you ask the second, and the answer to the second obviously depends on the first. Since we're a committee we can't answer them both at the same time, but we can work on them in parallel, with occasional exchanges of RNA. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Mar 29 13:42:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27666 for ; Fri, 29 Mar 2002 13:42:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23904 for midcom-archive@odin.ietf.org; Fri, 29 Mar 2002 13:43:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23577; Fri, 29 Mar 2002 13:40:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21937 for ; Fri, 29 Mar 2002 13:17:10 -0500 (EST) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26260 for ; Fri, 29 Mar 2002 13:17:07 -0500 (EST) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2TIGsa29383; Fri, 29 Mar 2002 10:16:54 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2TIH6s21210; Fri, 29 Mar 2002 10:17:06 -0800 (PST) Subject: Re: [midcom] Protocol Evaluation document template To: Melinda Shore Cc: Jonathan Rosenberg , Mary Barnes , "'midcom@ietf.org'" Date: Fri, 29 Mar 2002 12:16:31 -0600 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Perhaps, when the semantics document is complete, we can add one or more requirements to the requirements document and evaluation template that look for a match between the semantics of the semantics document and the semantics of the existing protocols and then QUICKLY evaluate the existing protocols against those new requirements and add the results to their evaluation(s)? In my experience, almost any attempt to write requirements and then evaluate existing things against them is an iterative process: ya make your best stab at initial requirements, during the evaluation ya discover things ya forgot, or things ya thought were important but just aren't anymore, etc., and so ya go back and amend the requirements and incrementally re-evaluate the things against the new requirements. Yah, the potential for infinite iteration exists but, again in my experience, you usually only iterate two or three times, and the later iterations are generally much faster than the first. And if anybody thinks they can get the requirements for something this nebulous and complicated right the first time, well, .... I guess I'm weighing in here in favor of continuing the parallel existing protocol evaluation and the development of "ideal" semantics, fully expecting that, because of the ideal semantics development or something else, we'll wind up amending the requirements and incrementally re-evaluating protocols. BTW, in beginning to evalute RSIP against the existing requirements, I'm starting to see some potential new requirements. I should have some comments on the e-mail list on this next week. Comments expected and welcome. Jim Renkel Director, Advanced Technology & System Engineering The CommWorks Corp., a 3Com company e-mail: james_renkel@commworks.com Melinda Shore @ietf.org on 03/28/2002 05:27:24 PM Sent by: midcom-admin@ietf.org To: Jonathan Rosenberg , Mary Barnes cc: "'midcom @ietf.org'" Subject: Re: [midcom] Protocol Evaluation document template At 06:09 PM 3/28/02 -0500, Jonathan Rosenberg wrote: >The requirements documents are at a high enough level that I do not see >how they would be used to rule out or support protocols. Just about any >sensible protocol that supports a session oriented communication between >two things, with messages in both directions, will meet the >requirements. Right. I think there may be some confusion at work, though - the protocol "evaluation" document is not a protocol recommendation document - the decision about which protocol will ultimately be used will take place after the evaluation document is complete. By then the semantics document should be done or nearly done, although I'm somewhat disappointed that there hasn't been one response to the proposal that Tom has put out and there haven't been any other proposals put forward. And, frankly, I don't think that the semantics we settle on are going to have that much discriminatory power. I understand your concern but I think we're okay. If you're familiar with "Indiana Jones and the Last Crusade" you may recall the scene in which he steps into the abyss only to find that there's actually an invisible bridge there. It's possible that there's no bridge here, but I'm willing to try it anyway. I really don't want to delay starting the protocol evaluation until the semantics are put together - it would end up taking us over a year to finish. 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 daemon@optimus.ietf.org Fri Mar 29 15:23:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02142 for ; Fri, 29 Mar 2002 15:23:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29499 for midcom-archive@odin.ietf.org; Fri, 29 Mar 2002 15:23:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29413; Fri, 29 Mar 2002 15:20:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29384 for ; Fri, 29 Mar 2002 15:20:25 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02042 for ; Fri, 29 Mar 2002 15:20:21 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2TKJpi26040; Fri, 29 Mar 2002 15:19:51 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2TKJn913905; Fri, 29 Mar 2002 15:19:49 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 15:19:49 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01D0E612@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'James_Renkel@3com.com'" , Melinda Shore Cc: Jonathan Rosenberg , "Mary Barnes", "'midcom@ietf.org'" Subject: RE: [midcom] Protocol Evaluation document template Date: Fri, 29 Mar 2002 15:19:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D75F.1363D33E" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C1D75F.1363D33E Content-Type: text/plain; charset="iso-8859-1" I tend to agree with Jonathan but I also feel that we should move forward with the protocol evaluation as soon as possible...what I am scared of is what some call "analysis-paralysis"...in some projects, people just keep analyzing without actually moving forward at some point. So, IMHO, the sooner the better. I especially agree with the iterative process, we may hit a wall on the first try, but eventually, we will get there. L-N -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, March 29, 2002 1:17 PM To: Melinda Shore Cc: Jonathan Rosenberg; Barnes, Mary [NGC:B601:EXCH]; 'midcom@ietf.org' Subject: Re: [midcom] Protocol Evaluation document template Perhaps, when the semantics document is complete, we can add one or more requirements to the requirements document and evaluation template that look for a match between the semantics of the semantics document and the semantics of the existing protocols and then QUICKLY evaluate the existing protocols against those new requirements and add the results to their evaluation(s)? In my experience, almost any attempt to write requirements and then evaluate existing things against them is an iterative process: ya make your best stab at initial requirements, during the evaluation ya discover things ya forgot, or things ya thought were important but just aren't anymore, etc., and so ya go back and amend the requirements and incrementally re-evaluate the things against the new requirements. Yah, the potential for infinite iteration exists but, again in my experience, you usually only iterate two or three times, and the later iterations are generally much faster than the first. And if anybody thinks they can get the requirements for something this nebulous and complicated right the first time, well, .... I guess I'm weighing in here in favor of continuing the parallel existing protocol evaluation and the development of "ideal" semantics, fully expecting that, because of the ideal semantics development or something else, we'll wind up amending the requirements and incrementally re-evaluating protocols. BTW, in beginning to evalute RSIP against the existing requirements, I'm starting to see some potential new requirements. I should have some comments on the e-mail list on this next week. Comments expected and welcome. Jim Renkel Director, Advanced Technology & System Engineering The CommWorks Corp., a 3Com company e-mail: james_renkel@commworks.com Melinda Shore @ietf.org on 03/28/2002 05:27:24 PM Sent by: midcom-admin@ietf.org To: Jonathan Rosenberg , Mary Barnes cc: "'midcom @ietf.org'" Subject: Re: [midcom] Protocol Evaluation document template At 06:09 PM 3/28/02 -0500, Jonathan Rosenberg wrote: >The requirements documents are at a high enough level that I do not see >how they would be used to rule out or support protocols. Just about any >sensible protocol that supports a session oriented communication between >two things, with messages in both directions, will meet the >requirements. Right. I think there may be some confusion at work, though - the protocol "evaluation" document is not a protocol recommendation document - the decision about which protocol will ultimately be used will take place after the evaluation document is complete. By then the semantics document should be done or nearly done, although I'm somewhat disappointed that there hasn't been one response to the proposal that Tom has put out and there haven't been any other proposals put forward. And, frankly, I don't think that the semantics we settle on are going to have that much discriminatory power. I understand your concern but I think we're okay. If you're familiar with "Indiana Jones and the Last Crusade" you may recall the scene in which he steps into the abyss only to find that there's actually an invisible bridge there. It's possible that there's no bridge here, but I'm willing to try it anyway. I really don't want to delay starting the protocol evaluation until the semantics are put together - it would end up taking us over a year to finish. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1D75F.1363D33E Content-Type: text/html; charset="iso-8859-1" RE: [midcom] Protocol Evaluation document template

I tend to agree with Jonathan but I also feel that we should move forward
with the protocol evaluation as soon as possible...what I am scared of is what
some call "analysis-paralysis"...in some projects, people just keep analyzing
without actually moving forward at some point. So, IMHO, the sooner the better.
I especially agree with the iterative process, we may hit a wall on the first try,
but eventually, we will get there.

L-N

-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]
Sent: Friday, March 29, 2002 1:17 PM
To: Melinda Shore
Cc: Jonathan Rosenberg; Barnes, Mary [NGC:B601:EXCH]; 'midcom@ietf.org'
Subject: Re: [midcom] Protocol Evaluation document template



Perhaps, when the semantics document is complete, we can add one or
more requirements to the requirements document and evaluation template
that look for a match between the semantics of the semantics document
and the semantics of the existing protocols and then QUICKLY evaluate
the existing protocols against those new requirements and add the
results to their evaluation(s)?

In my experience, almost any attempt to write requirements and then
evaluate existing things against them is an iterative process: ya make
your best stab at initial requirements, during the evaluation ya
discover things ya forgot, or things ya thought were important but just
aren't anymore, etc., and so ya go back and amend the requirements and
incrementally re-evaluate the things against the new requirements. Yah,
the potential for infinite iteration exists but, again in my experience,
you usually only iterate two or three times, and the later iterations are
generally much faster than the first. And if anybody thinks they can get
the requirements for something this nebulous and complicated right the
first time, well, ....

I guess I'm weighing in here in favor of continuing the parallel existing
protocol evaluation and the development of "ideal" semantics, fully
expecting that, because of the ideal semantics development or something
else, we'll wind up amending the requirements and incrementally
re-evaluating protocols.

BTW, in beginning to evalute RSIP against the existing requirements, I'm
starting to see some potential new requirements. I should have some
comments on the e-mail list on this next week.

Comments expected and welcome.

Jim Renkel
Director, Advanced Technology & System Engineering
The CommWorks Corp., a 3Com company
e-mail: james_renkel@commworks.com





Melinda Shore <mshore@cisco.com>@ietf.org on 03/28/2002 05:27:24 PM

Sent by:  midcom-admin@ietf.org


To:   Jonathan Rosenberg <jdrosen@dynamicsoft.com>, Mary Barnes
      <mbarnes@nortelnetworks.com>
cc:   "'midcom @ietf.org'" <midcom@ietf.org>
Subject:  Re: [midcom] Protocol Evaluation document template


At 06:09 PM 3/28/02 -0500, Jonathan Rosenberg wrote:
>The requirements documents are at a high enough level that I do not see
>how they would be used to rule out or support protocols. Just about any
>sensible protocol that supports a session oriented communication between
>two things, with messages in both directions, will meet the
>requirements.

Right.  I think there may be some confusion at work, though -
the protocol "evaluation" document is not a protocol recommendation
document - the decision about which protocol will ultimately be
used will take place after the evaluation document is complete.
By then the semantics document should be done or nearly done,
although I'm somewhat disappointed that there hasn't been one response
to the proposal that Tom has put out and there haven't been any other
proposals put forward.  And, frankly, I don't think that the semantics
we settle on are going to have that much discriminatory power.

I understand your concern but I think we're okay.  If you're familiar
with "Indiana Jones and the Last Crusade" you may recall the scene in
which he steps into the abyss only to find that there's actually an
invisible bridge there.  It's possible that there's no bridge here,
but I'm willing to try it anyway.  I really don't want to delay starting
the protocol evaluation until the semantics are put together - it would
end up taking us over a year to finish.

Melinda


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






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

------_=_NextPart_001_01C1D75F.1363D33E-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Mar 31 22:11:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03606 for ; Sun, 31 Mar 2002 22:11:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA25128 for midcom-archive@odin.ietf.org; Sun, 31 Mar 2002 22:11:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25031; Sun, 31 Mar 2002 22:08:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25002 for ; Sun, 31 Mar 2002 22:08:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03562 for ; Sun, 31 Mar 2002 22:08:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g31389TE022219; Sun, 31 Mar 2002 22:08:09 -0500 (EST) Message-ID: <3CA7CED3.1D8C6C8B@dynamicsoft.com> Date: Sun, 31 Mar 2002 22:06:59 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Louis-Nicolas Hamer CC: "'James_Renkel@3com.com'" , Melinda Shore , Mary Barnes , "'midcom@ietf.org'" Subject: Re: [midcom] Protocol Evaluation document template References: <9FBD322B7824D511B36900508BF93C9C01D0E612@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Louis-Nicolas Hamer wrote: > > I tend to agree with Jonathan but I also feel that we should move > forward > with the protocol evaluation as soon as possible...what I am scared of > is what > some call "analysis-paralysis"... Since I appear to be in the minority, I'll cease and desist on this point. However, I do want to be clear that I was not proposing analysis of any sort; the "abstract protocol" is design work - to specify the protocol itself in all details but the syntax. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom