From owner-ietf-outbound Wed Mar 1 02:20:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA24444 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 02:20:03 -0500 (EST) Received: from sdp.ee.tsinghua.edu.cn (sdp.ee.tsinghua.edu.cn [166.111.64.222]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23965 for ; Wed, 1 Mar 2000 02:14:17 -0500 (EST) Received: from Zhengyq ([166.111.64.236]) by sdp.ee.tsinghua.edu.cn (Netscape Mail Server v2.02) with SMTP id AAA210 for ; Wed, 1 Mar 2000 15:25:35 +0800 Message-ID: <000d01bf834d$88c203c0$ec406fa6@Zhengyq.sdt> From: zhengyq@sdp.ee.tsinghua.edu.cn (Zheng Youquan) To: Subject: What is the latest trend of network research ??????? Date: Wed, 1 Mar 2000 15:12:41 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01BF8390.96B2E920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Loop: ietf@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BF8390.96B2E920 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Several month ago, DiffServ and MPLS is hot topic in network research. But how about now about Internet? ------=_NextPart_000_000A_01BF8390.96B2E920 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Several month ago, = DiffServ and=20 MPLS is hot topic in network research.
But how about now about=20 Internet?
------=_NextPart_000_000A_01BF8390.96B2E920-- From owner-ietf-outbound Wed Mar 1 03:20:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA25554 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 03:20:02 -0500 (EST) Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25490; Wed, 1 Mar 2000 03:14:32 -0500 (EST) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id JAA06692 Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id JAA07958 Received: from ic8u32.settimo.italtel.it (ic8u32.settimo.italtel.it [138.132.1.1]) by mix.italtel.it (8.9.3/8.9.3) with SMTP id JAA29662; Wed, 1 Mar 2000 09:14:14 +0100 (MET) Received: by ic8u32.settimo.italtel.it id AA06012; Wed, 1 Mar 2000 09:30:46 +0100 Received: from iltws09.settimo.italtel.it by ilt9h01.settimo.italtel.it with SMTP (1.38.193.5/16.2) id AA00720; Wed, 1 Mar 2000 09:05:21 +0100 Sender: buschman@icn.siemens.it Message-Id: <38BCD179.E2B7B75@icn.siemens.it> Date: Wed, 01 Mar 2000 09:14:49 +0100 From: Jonathan Buschmann Reply-To: Jonathan.Buschmann@icn.siemens.it X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: iesg@ietf.org Cc: ietf@ietf.org, floyd@EE.LBL.GOV, tsvwg@ietf.org Subject: Re: Last Call: An Extension to the Selective Acknowledgement(SACK) Option for TCP to Proposed Standard References: <200002281634.LAA13672@ietf.org> 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 IESG wrote: > The IESG has received a request from the Working Group to consider An ^tsvwg > > Extension to the Selective Acknowledgement (SACK) Option for TCP > as a Proposed Standard. I thought this was originally proposed as an Experimental RFC - the minutes from the tsvwg DC meeting confirm that. When, how and why was this changed? I didn't see any discussion on the mailing list. jonathan From owner-ietf-outbound Wed Mar 1 03:50:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA25882 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 03:50: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 DAA25823 for ; Wed, 1 Mar 2000 03:43:27 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 1 Mar 2000 08:43:19 +0000 To: zhengyq@sdp.ee.tsinghua.edu.cn (Zheng Youquan) cc: ietf Subject: Re: What is the latest trend of network research ??????? In-reply-to: Your message of "Wed, 01 Mar 2000 15:12:41 +0800." <000d01bf834d$88c203c0$ec406fa6@Zhengyq.sdt> Date: Wed, 01 Mar 2000 08:43:18 +0000 Message-ID: <1531.951900198@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org In message <000d01bf834d$88c203c0$ec406fa6@Zhengyq.sdt>, Zheng Youquan typed: >>Several month ago, DiffServ and MPLS is hot topic in network research. >>But how about now about Internet? a brief history of time-wasting in the early 80s, "research" concentrated on egp and dns - this was quite important for making the net scale - a little after this, the "flavour du jour" was policy routing - some of this was quite useful - a lot of it (mine included) was orthogonal to requirements... in the late 80s, "research" concentrated on rpc transport protocols- this would have been useful if the CERN folks hadnt ignored all the work (e.g. T/TCP) and done HTTP _ see below... in the early 90s, "research" concentrated on ip/atm and trying to make ip look as much like atm as possible (intserv) that it would fit (square pegs and round holes) - this kept a lot of people out of our hair while we got on with deploying IP everywhere as fast as physically possible (and in some cases faster) in the late 90s, "research" concentrated on http/tcp performance and web cacheing - this was actually quite useful.... in the early 2000s, "research" is concentrating on making the internet protocols look as much like the telephone net as possible to make it easier for dinosaurs to survive meteor strikes. somewhere along the way, a few neat hacks like multicast, mobile and secure IP got devised.... :-) :-) :-) j. oh, the New New Thing? clearly its wireless ordering on the web (WOW) basically, the mobile phone business is making moves to do what MSN failed and capture "the whole internet" by making itself the one and only portal - in europe at least, they stand a chance of succeeding for 3 reasons i) traditional telcos make dinosaurs look like rodents when it comes to deploying fancy new fast access nets and services - newbies are practically illegally prevented from entering the market despite EU de-regualtion ii) the mobile guys have practically no regulation iii) some mobile phone service providers are becoming credit card companies -this is very very shrewd....think about it... :-) partly From owner-ietf-outbound Wed Mar 1 04:10:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA26179 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 04:10:02 -0500 (EST) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26121; Wed, 1 Mar 2000 04:04:42 -0500 (EST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id BAA08518; Wed, 1 Mar 2000 01:04:39 -0800 (PST) Message-Id: <200003010904.BAA08518@daffy.ee.lbl.gov> To: Jonathan.Buschmann@icn.siemens.it Cc: iesg@ietf.org, ietf@ietf.org, floyd@ee.lbl.gov, tsvwg@ietf.org Subject: Re: Last Call: An Extension to the Selective Acknowledgement(SACK) Option for TCP to Proposed Standard In-reply-to: Your message of Wed, 01 Mar 2000 09:14:49 PST. Date: Wed, 01 Mar 2000 01:04:38 PST From: Vern Paxson X-Loop: ietf@ietf.org > > Extension to the Selective Acknowledgement (SACK) Option for TCP > > as a Proposed Standard. > > I thought this was originally proposed as an Experimental RFC Correct. > When, how and why was this changed? I didn't see any discussion on the > mailing list. The chairs/ADs deemed it a sufficiently minor (yet useful) change to SACK that it doesn't seem necessary to go the route of first publishing it as Experimental. When the TSVWG working group last call was issued, it was for publishing the document as Proposed, and we noted: > The document was discussed > at the last IETF and appears to have good support and no controversial > issues. There were no working group last call comments. Vern From owner-ietf-outbound Wed Mar 1 05:20:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA27120 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 05:20:02 -0500 (EST) Received: from kediri.webindonesia.com (kediri.webindonesia.com [207.106.122.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27087 for ; Wed, 1 Mar 2000 05:17:35 -0500 (EST) Received: (qmail 32630 invoked by uid 1003); 1 Mar 2000 10:16:40 -0000 Date: Wed, 1 Mar 2000 05:16:40 -0500 From: "Rahmat M. Samik-Ibrahim" To: ietf@ietf.org Cc: dick@eGroups.com Subject: TCP Encapsulation within TCP Message-ID: <20000301051640.A32593@kediri.webindonesia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us X-Loop: ietf@ietf.org Hello: Apology if this following sounds a little bit trivia. I looking for online documents about practical TCP Encapsulation within TCP implementation. I have already tried without luck the http://www.normos.org/ , http://www.altavista.org , FAQ - comp.protocols.tcp-ip, as well as the holy rfc-index.txt. What I have in mind is splitting a virtual point to point link into several queues with TCP windows. What I mean with virtual link is that there might be several physical hubs between the points. Each encapsulated TCP window will contain one or more real TCP packets that are compressed and encrypted. For example, a link might be split into four queues. One for Non Maskable/Priority Traffic, one for Small and Medium Packets, one for Large Packets, and one for forwarding no priority packets (e.g. "alt.*" traffic). Hopefully, someone has already implemented something similar. regards, -- Rahmat M. Samik-Ibrahim ------------------------ http://rms46.vlsm.org -- OSI: Same day service in a nanosecond world --- Interop T-shirt(vJ) From owner-ietf-outbound Wed Mar 1 08:01:55 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA29828 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 08:00:02 -0500 (EST) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29773 for ; Wed, 1 Mar 2000 07:54:46 -0500 (EST) Received: from pembo (pembo.cwi.nl [192.16.201.136]) by hera.cwi.nl with SMTP id NAA29377 for ; Wed, 1 Mar 2000 13:53:38 +0100 (MET) Message-ID: <003401bf837d$57d21680$88c910c0@cwi.nl> From: "Steven Pemberton" To: "James P. Salsman" Cc: , References: <200002291900.LAA21505@shell9.ba.best.com> Subject: Re: Device upload for all platforms -- the official HTML WG position Date: Wed, 1 Mar 2000 13:54:52 +0100 Organization: CWI 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.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit From: "James P. Salsman" > Where are they published? They are in the private W3C members-only > archives, in the w3c-html-wg archives around October-November 1999, > with nearly the same discussion in the private w3c-forms list earlier. That is the process for dealing with a W3C submission. I hope it is obvious that I am not empowered to republish postings from a private forum to a public one. But no worry, because people on this list (www-html) are making the same sort of comments that people on the original lists made then, so we can just read them from other people's hand. > The fact remains that non-wintel web users are excluded from a range > of very useful services involving device input and upload. Complete nonsense. There is nothing in HTML 4 that excludes any platform. Just look at Opera, which is being implemented on BeOs, Epoc, Linux, Mac Os, OS/2 and Windows. The HTML WG represents a wide range of companies, platforms and interests. > If the > HTML Working Group had incorporated device upload into specifications > when they were first submitted as an internet-draft in 1997, after > the implementation on the WebTV Plus, then all this would be a > non-issue. If you had listened to the comments to your proposal when you submitted it, you could have corrected it, and it would be a non-issue. You shouldn't think that the HTML WG accepts every suggestion from allcomers. We evaluate technical proposals before accepting them. In your case we pointed out there are fundamental flaws in your approach, and indicated how you could fix them. As members of this list are pointing out, there is nothing in HTML 4 that prevents an implementor from doing what you want. Talk to the implementors, would be my advice. > But as things stand, the W3C is contributing to wintel > dominance, and disenfranchising Unix and Mac users. Nonsense. Pure nonsense. Steven Pemberton Chair, W3C HTML Working Group From owner-ietf-outbound Wed Mar 1 08:30:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA00513 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 08:30: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 IAA00490 for ; Wed, 1 Mar 2000 08:29:58 -0500 (EST) Message-Id: <200003011329.IAA00490@ietf.org> From: The IETF Secretariat To: ietf@ietf.org Subject: IETF List maintenance Reply-to: ietf-request@ietf.org Date: Wed, 01 Mar 2000 08:29:58 -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. 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 From owner-ietf-outbound Wed Mar 1 14:40:42 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11400 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 14:40: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 ESMTP id OAA11248 for ; Wed, 1 Mar 2000 14:33:24 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id LAA02283; Wed, 1 Mar 2000 11:32:53 -0800 (PST) Date: Wed, 1 Mar 2000 11:32:53 -0800 (PST) From: "James P. Salsman" Message-Id: <200003011932.LAA02283@shell9.ba.best.com> To: Steven.Pemberton@cwi.nl Subject: Re: Device upload for all platforms -- the official HTML WG position Cc: ietf@ietf.org, www-html@W3.ORG In-Reply-To: <003401bf837d$57d21680$88c910c0@cwi.nl> X-Loop: ietf@ietf.org Dear Dr. Pemberton, Thanks for your message: > There is nothing in HTML 4 that excludes any platform. > Just look at Opera, which is being implemented on BeOs, Epoc, Linux, > Mac Os, OS/2 and Windows. Device upload -- of any kind -- has not yet been implemented in Opera. You know that the CTO of Opera software has said they will wait for a W3C Recommendation (or Working Draft) on device upload. Opera, even on Windows, will not interpret MSIE OBJECT or Netscape EMBED tags which are used for microphone upload on those browsers under Windows. There is simply no browser on Mac or Linux (other than my experimental build of pre-gecko Mozilla) which is capable of even microphone upload. > If you had listened to the comments to your proposal when you submitted > it, you could have corrected it, and it would be a non-issue. Since 1997, there have been eight revisions, incorporating the useful suggestions from anyone who cared to review and comment on the draft. The basic idea and method remained the same throughout; the significant changes mostly concerned the names of devices. > In your case we pointed out there are fundamental flaws in your > approach, and indicated how you could fix them. I am sure we both want to resolve this. Would you please list all the flaws of which you are aware -- with as little or as much detail as you have time for -- along with, when available, how they could be fixed? I promise you I will devote my efforts to your comments until you are satisfied that they are resolved, but I do need your help to understand which issues you consider flaws. I will start by addressing the question of whether ACCEPT alone is sufficient for device upload, when used with the INPUT TYPE=FILE element. The problem occurs when an image is requested on a system with both a camera and a scanner. Having a DEVICE attribute allows for the selection of a default, which is reasonable because some conferencing applications might always expect camera input whereas OCR applications would usually expect scanner input. And, as others have pointed out, in compressed media the MAXLENGTH limitation is not as practical as the MAXTIME limitation, in the case where an upload needs to be restricted in size. Does anyone think that this justification is inadequate? Cheers, James From owner-ietf-outbound Wed Mar 1 15:32:47 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA12453 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 15:32:37 -0500 (EST) Received: from helios.cstp.umkc.edu (helios.cstp.umkc.edu [134.193.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12208 for ; Wed, 1 Mar 2000 15:21:39 -0500 (EST) Received: (from ekpark@localhost) by helios.cstp.umkc.edu (8.9.1/8.9.1) id OAA02703; Wed, 1 Mar 2000 14:14:29 -0600 (CST) Date: Wed, 1 Mar 2000 14:14:29 -0600 (CST) From: Eun Kyo Park Message-Id: <200003012014.OAA02703@helios.cstp.umkc.edu> To: Hossam.Afifi@enst-bretagne.fr, MariaLuisa.Rossari@cselt.it, Omar.Elloumi@enst-bretagne.fr, enternet@bbn.com, events@teco.edu, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, ftroup@dsl.cis.upenn.edu, g-troup@ccrc.wustl.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@IEEE.ORG, kia@usl.edu, lanoms99@lrg-gw.lrg.ufsc.br, lyko@jupiter.kt.agh.edu.pl, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@IEEE.ORG, sc6wg4@ntd.comsat.com, sig-dce@OPENGROUP.ORG, sigmedia@bellcore.com, tccc@IEEE.ORG, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@IEEE.ORG, xtprelay@cs.concordia.ca Subject: IEEE ICCCN2000 CFP X-Loop: ietf@ietf.org (Our apologies if you receive this multiple times!!) ** Electronic paper submission system is up ** and ready to accept papers !!!!!!!!!!!!! ------------------------------------------- IEEE IC3N'2000 CALL FOR PAPERS NINTH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS October 16 - 18, 2000 Imperial Palace Hotel, Las Vegas, Nevada USA (Website: icccn.cstp.umkc.edu) Sponsored by IEEE Communications Society (tech. co-sponsor), Army Research Lab/Office, IBM, NOKIA, Siemens (pending approval of sponsorships) ICCCN is a major international forum to present original and fundamental advances in the field of Computer Communications and Networks. It also serves to foster communication among researchers and practitioners working in a wide variety of scientific areas with a common interest in improving Computer Communications and Networks. SCOPE: The primary focus of the conference is on new and original research results in the areas of design, implementation and applications of Computer Communications and Networks. We invite you to submit papers that address novel, challenging, and innovative results. The topics include, but are not limited to: Optical Communication Networks Wireless/Mobile/Satellite Comm Networks ATM Networking Internet Services/Applications Wireless Multimedia Applications Real-time Communications Quality of Services (QoS) Issues LAN/WAN Internetworking Network Interoperability Personal Communication Services Network Control Management Broadband Networks Intelligent Networks Multicast and Routing Protocols Network Security Media Access Control/Mobility Algorithms Network Reliability High Speed Network OAM/Protocols Video-on-Demand Data Traffic Engineering Network Management/Billing Global Infrastructure Network Evolution Network Processor Technology Performance Modeling/Analysis Communication Software Protocol Design/Validation/Testing Networked Databases Network Architectures Terabit optical switching/ routing architectures and signaling SUBMISSION: Authors are invited to submit complete and original papers. Papers that may be submitted should not have been previously published in another forum, or are not currently under review by another journal or conference. All submitted papers will be refereed for quality, correctness, originality and relevance. The program committee reserves the right to accept a submission as long, short, or poster presentation. Of particular interest are papers which address experiences with concrete Computer Communications and applications. All accepted papers will be published in the conference proceedings. Special issues of journals containing outstanding papers from the conference are being planned. Manuscripts should include an abstract and be limited to 5000 words. Submissions should include the title, author(s), author's affiliation, e-mail address, fax number and postal address. In case of multiple authors, an indication of which author is responsible for correspondence and preparing the camera ready paper for the proceedings should also be included. Electronic submission is strongly encouraged (go to the end of this CFP for more information; ps or pdf format is preferred. Please contact Dr. Park if you have to submit with hard copies). Manuscripts should be submitted by Friday, April 24, 2000 to ICCCN2000 website or contact program co-chairs with any questions: Dr. Ton Engbersen Professor E.K. Park IBM Research Laboratory Computer Science Telecommunications Saumerstrasse 4 University of Missouri 8803 Rueschlikon Robert Flarsheim Hall, Room 534 Switzerland 5100 Rockhill Road apj@zurich.ibm.com Kansas City, Missouri 64110 USA +41-1-7248302 (816)235-1497; (816)235-5159(fax) +41-1-7248599 (fax) ekpark@cstp.umkc.edu IMPORTANT DATES: Paper submission deadline : April 24, 2000 Notification of acceptance: June 26, 2000 Camera ready papers due : July 31, 2000 TUTORIALS: Proposals are solicited for tutorials. Please email your proposals in ASCII format by April 24, 1999 to one of the Program Chairs above. WEBSITE: Electronic paper submission system is up and ready (from March 1, 2000) to accept papers for the IEEE ICCCN2000 and please visit ICCCN2000 web site icccn.cstp.umkc.edu for more up-to-date information. ------------------------------------------------------------------------------- I E E E I C C C N 2000 ORGANIZATION ------------------------------------- Honorary Conference Chair: Dr. Kia Makki, Univ. of Louisiana, Dept of EECE, 2 Rex Street, Lafayette, LA 70504, kia@usl.edu Conference General Chair: Dr. Sudhir S. Dixit, Nokia Research Center, 5 Wayside Road, Burlington, MA 01803, (781)993-4607, sudhir.dixit@nokia.com Program Chairs: Dr. Ton Engbersen and Dr. EK Park (see above for addresses) Local Arrange Chair: Dr. Jerry Stach, Computer Science Telecommunications, University of Missouri, stach@cstp.umkc.edu, 816-235-2346 Publicity Chair: Dr. Wei Li, University of Louisiana, Dept of EECE, Madison Hall 248G, P.O.Box 43890, Lafayette, LA 70504-3890 (318)482-6570; (318)482-6687 (Fax), wli@usl.edu Technical Program Committee: (Last Name/First Name/Affiliation) ------------------------------------------------------------------------- Abouaissa A. Atiquzzaman Mohammed Atlas Alia U.of Tech. Belfor- Univ. of Dayton BBN Technologies Montbeliard Avresky D. R. Bestavros Azer Bhat Kabekode V. Boston University Boston University Lucent Technologies Busovaca Senad Cao Guohong Casoni Maurizio CA State U.,Sacramento Penn State Univ. Univ. of Bologna Chen Thomas Cheng Albert M. K. CHI Chi-Hung SMU Univ. of Houston Nat'l U. of Singapore Chin Kwan-Wu Choi Young B. Clauberg Rolf Curtin U. of Tech. COMPAQ Comp. Corp. IBM Research Conway Adrian Curcio Igor D.D. Das Samir R. GTE Internetworking Nokia Mobile Phones U. of Cincinnati Delp Gary Demeester Piet Douligeris Christos IBM U. Of Gent - IMEC University of Piraeus Dovrolis Constantinos Ersoy Cem Feng Hui U of Wisconsin,Madison Bogazici Univ. NEC America, Inc Fernandez Antonio Fischer Stefan Fong Simon U. Rey Juan Carlos Int'l Univ.,Germany Nanyang Tech. Univ. Frieder Ophir Fumagalli Andrea Garg Rahul IIT, Chicago U. of Texas-Dallas IBM India Res. Golmie Nada Golshani Forouzan Gusat Mitchell NIST Arizona State Univ. ZRL Herkersdorf Andreas Hetzer Dirk Hogrefe Dieter IBM Zurich Res. Lab. Deutsche Telekom Institut fuer Telematik Hou Jennifer Houatra Drissa HU X.-D. Ohio State Univ. CNET(France Telecom) Chinese Academy of Sci. Huang Chung-Ming Huang Yih Huynh D.T. Nat'l Cheng Kung U. George Mason Univ. U. of Texas-Dallas Jacob Lillykutty Jain Raj Jakobs Kai Nat'l U. of Singapore Ohio State Univ. Technical U. of Aachen Jennings Esther Jia Xiaohua Kao Ming-Yang CA Polytechnic,Pomona City U. of Hong Kong Yale University Khalil Eha A. Khendek Ferhat Kim Jaime Menoufia University Concordia Univ. CA State U.,Northridge Kim Tag Gon Koenig Hartmut Kone Ousmane KAIST, Korea Brandenburg U.of Tech. Inst. Nat'l Polytech. Krishnamurthi Govind Laurini Robert Lee Gyungho Nokia Research Center Claude B. Univ. of Lyon Iowa State Univ. Levi Albert Li J. Jenny Liu Kevin H. Oregon S.U./Bogazici U. Telcordia Technologies Telcordia Tech. Lorenz Pascal Luijten Ronald P. Manimaran G. U. of Haute Alsace IBM Zurich res. lab Iowa State Univ. Masuyama Hiroshi Modiano Eytan Moh Melody Tottori University MIT San Jose St. U./3Com Mohan G. Mohapatra Prasant Mosse Daniel Regional Eng. College Michigan State Univ. U. of Pittsburgh Carr-Motyckova Lenka Murthy C. Siva Ram Obaidat Mohammad S. Linkoping U.,Sweden IIT, Madras Monmouth Univ. Ozegovic Julije Paris Jehan-Francois Peng Wuxu FESB Split Univ. of Houston Southwest Texas St. U. Prakash Ravi Qiao Chunming Raghavendra C. S. U. of Texas-Dallas SUNY-Buffalo USC Rahouma Kamel Hussein Ramamurthy Byrav Richardson Paul Univ. of Salzburg U. of Nebraska-Lincoln U. of Michigan-Dearborn Rothermel Kurt Sanneck Henning Saran Huzur U. of Stuttgart GMD Fokus IIT, Delhi Schaller Sibylle Scotton Paolo Seckin Gamze NEC IBM Res. Div.-Zurich Arizona State Univ. Shiomoto Kohei Sivalingam Krishna Somani Arun K NTT Network Lab. Washington State U. Iowa State Univ. Stojmenovic Ivan Su David Subramaniam Suresh Univ. of Ottawa NIST George Washington U. Tseng Yu-Chee Turck Filip De Vandalore Bobby Nat'l Central Univ. University Of Gent Ohio State Univ. Varada Srihari Wang Zheng Wigglesworth Joe TranSwitch Corp. Bell Labs IBM Toronto Lab. Wolf Michael Xue Guoliang Yamamoto Miki DaimlerChrysler Res. Univ. of Vermont Osaka University Yang Oliver Yang Yuanyuan Youn Hee Yong Univ. of Ottawa SUNY-Stony Brook Info.& Comm. U.,Korea Yuan Xin Yun Kenneth Yurcik Bill Florida State Univ. U. of CA, San Diego Illinois State Univ. Zeadally Sherali Zomaya Albert Y. Wayne State Univ. U. of Western Australia -------------------------------------------------------------------------- From owner-ietf-outbound Wed Mar 1 16:10:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA13202 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 16: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 ESMTP id QAA13146 for ; Wed, 1 Mar 2000 16:07:11 -0500 (EST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08587; Wed, 1 Mar 2000 13:06:59 -0800 (PST) Message-Id: <4.3.2.20000301130403.04e6cdc0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 01 Mar 2000 13:07:09 -0800 To: "James P. Salsman" , Steven.Pemberton@cwi.nl From: Paul Hoffman / IMC Subject: Re: Device upload for all platforms -- the official HTML WG position Cc: ietf@ietf.org, www-html@W3.ORG In-Reply-To: <200003011932.LAA02283@shell9.ba.best.com> References: <003401bf837d$57d21680$88c910c0@cwi.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Why is this thread being run on the IETF mailing list? The IETF handed off responsibility for HTML to the W3C long ago. If the reason is to show people that someone has a beef with the way that the W3C is handling HTML, that point has been made. (I can already picture certain IETF folks starting to deluge W3C mailing lists when IAB appeals don't go their way...) --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-outbound Wed Mar 1 17:00:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA14116 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 17:00: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 ESMTP id QAA13948 for ; Wed, 1 Mar 2000 16:52:18 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id NAA06916; Wed, 1 Mar 2000 13:51:40 -0800 (PST) Date: Wed, 1 Mar 2000 13:51:40 -0800 (PST) From: "James P. Salsman" Message-Id: <200003012151.NAA06916@shell9.ba.best.com> To: phoffman@IMC.ORG Subject: Re: Device upload for all platforms (why on IETF list?) Cc: ietf@ietf.org In-Reply-To: <4.3.2.20000301130403.04e6cdc0@mail.imc.org> X-Loop: ietf@ietf.org Paul, Thanks for your message: > Why is this thread being run on the IETF mailing list? Some messages to the W3C lists described as "public" did not appear until my request for endorsements of the device upload draft appeared here. The W3C filters out messages from non-subscribers, but as the archive for the "public" www-forms@w3.org list shows, they also filter messages that they do not wish to have distributed. Please be patient. The IETF attention to this issue has already been very helpful. We all hope for a resolution soon. Cheers, James From owner-ietf-outbound Wed Mar 1 17:20:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA14774 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 17:20: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 ESMTP id RAA14711 for ; Wed, 1 Mar 2000 17:17:11 -0500 (EST) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12QHQD-0004Iy-00; Wed, 01 Mar 2000 22:16:45 +0000 Date: Wed, 1 Mar 2000 22:16:36 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Paul Hoffman / IMC cc: ietf@ietf.org Subject: Re: Device upload for all platforms -- the official HTML WG position In-Reply-To: <4.3.2.20000301130403.04e6cdc0@mail.imc.org> 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, 1 Mar 2000, Paul Hoffman / IMC wrote: > Why is this thread being run on the IETF mailing list? The IETF handed off > responsibility for HTML to the W3C long ago. When did the IETF ever have responsibility for HTML, exactly? L. PGP From owner-ietf-outbound Wed Mar 1 17:50:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA15502 for ietf-outbound.10@ietf.org; Wed, 1 Mar 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 ESMTP id RAA15466 for ; Wed, 1 Mar 2000 17:49:21 -0500 (EST) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.Gamma0/8.10.0.Gamma0) with ESMTP id e21MnGw32424; Wed, 1 Mar 2000 17:49:16 -0500 Message-Id: <200003012249.e21MnGw32424@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.1 10/15/1999 To: L.Wood@eim.surrey.ac.uk cc: Paul Hoffman / IMC , ietf@ietf.org Subject: Re: Device upload for all platforms -- the official HTML WG position In-reply-to: Your message of "Wed, 01 Mar 2000 22:16:36 GMT." From: Valdis.Kletnieks@vt.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[ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Mar 2000 17:49:15 -0500 X-Loop: ietf@ietf.org On Wed, 01 Mar 2000 22:16:36 GMT, Lloyd Wood said: > When did the IETF ever have responsibility for HTML, exactly? Well, searching for 'html' or 'hypertext' in rfc-index.tct, I find: 1866 Hypertext Markup Language - 2.0. T. Berners-Lee, D. Connolly. November 1995. (Format: TXT=146904 bytes) (Status: PROPOSED STANDARD) 1867 Form-based File Upload in HTML. E. Nebel, L. Masinter. November 1995. (Format: TXT=26183 bytes) (Status: EXPERIMENTAL) 1942 HTML Tables. D. Raggett. May 1996. (Format: TXT=68705 bytes) (Status: EXPERIMENTAL) 1945 Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding & H. Frystyk. May 1996. (Format: TXT=137582 bytes) (Status: INFORMATIONAL) 1980 A Proposed Extension to HTML : Client-Side Image Maps. J. Seidman. August 1996. (Format: TXT=13448 bytes) (Status: INFORMATIONAL) 2070 Internationalization of the Hypertext Markup Language. F. Yergeau, G. Nicol, G. Adams, M. Duerst. January 1997. (Format: TXT=91887 bytes) (Status: PROPOSED STANDARD) 2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann. March 1997. (Format: TXT=41961 bytes) (Obsoleted by RFC2557) (Status: PROPOSED STANDARD) 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann, N. Shelness. March 1999. (Format: TXT=61854 bytes) (Obsoletes RFC2110) (Status: PROPOSED STANDARD) 2659 Security Extensions For HTML. E. Rescorla, A. Schiffman. August 1999. (Format: TXT=8134 bytes) (Status: EXPERIMENTAL) 2731 Encoding Dublin Core Metadata in HTML. J. Kunze. December 1999. (Format: TXT=42450 bytes) (Status: INFORMATIONAL) Obviously we care enough to issue RFCs about them - some are even Proposed Standard.. I've left rfc2324 out of the list.. ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Wed Mar 1 18:30:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA16457 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 18:30:02 -0500 (EST) Received: from stargate.ctp.com (stargate.ctp.com [149.44.2.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16370 for ; Wed, 1 Mar 2000 18:25:57 -0500 (EST) Received: from yorktown.ctp.com (yorktown.ctp.com [149.44.7.32]) by stargate.ctp.com (8.8.8/8.8.8) with ESMTP id SAA04416; Wed, 1 Mar 2000 18:24:49 -0500 (EST) Received: from lochness.ctp.com (lochness.ctp.com [149.44.15.47]) by yorktown.ctp.com (8.9.3/8.9.3) with ESMTP id SAA17660; Wed, 1 Mar 2000 18:24:09 -0500 (EST) Received: by lochness.ctp.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Mar 2000 18:24:48 -0500 Message-ID: From: Sonny Ghosh To: "'James P. Salsman'" , Steven.Pemberton@cwi.nl Cc: ietf@ietf.org, www-html@W3.ORG Subject: RE: Device upload for all platforms -- the official HTML WG posit ion Date: Wed, 1 Mar 2000 18:24:35 -0500 Return-Receipt-To: Sonny Ghosh 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 James / Steven: I would encourage both of you to take your "fight" in one-on-one email traffic; I am sure there are lot of people in the ietf & www-html mailing lists who are least interested in watching you two taking shots at each other; please show some civility in using group mailing lists. If I see one more email of this nature cluttering my mailbox, I might call CyberCop!!! Thanks -----Original Message----- From: James P. Salsman [mailto:bovik@BEST.COM] Sent: Wednesday, March 01, 2000 2:33 PM To: Steven.Pemberton@cwi.nl Cc: ietf@ietf.org; www-html@w3.org Subject: Re: Device upload for all platforms -- the official HTML WG position Dear Dr. Pemberton, Thanks for your message: > There is nothing in HTML 4 that excludes any platform. > Just look at Opera, which is being implemented on BeOs, Epoc, Linux, > Mac Os, OS/2 and Windows. Device upload -- of any kind -- has not yet been implemented in Opera. You know that the CTO of Opera software has said they will wait for a W3C Recommendation (or Working Draft) on device upload. Opera, even on Windows, will not interpret MSIE OBJECT or Netscape EMBED tags which are used for microphone upload on those browsers under Windows. There is simply no browser on Mac or Linux (other than my experimental build of pre-gecko Mozilla) which is capable of even microphone upload. > If you had listened to the comments to your proposal when you submitted > it, you could have corrected it, and it would be a non-issue. Since 1997, there have been eight revisions, incorporating the useful suggestions from anyone who cared to review and comment on the draft. The basic idea and method remained the same throughout; the significant changes mostly concerned the names of devices. > In your case we pointed out there are fundamental flaws in your > approach, and indicated how you could fix them. I am sure we both want to resolve this. Would you please list all the flaws of which you are aware -- with as little or as much detail as you have time for -- along with, when available, how they could be fixed? I promise you I will devote my efforts to your comments until you are satisfied that they are resolved, but I do need your help to understand which issues you consider flaws. I will start by addressing the question of whether ACCEPT alone is sufficient for device upload, when used with the INPUT TYPE=FILE element. The problem occurs when an image is requested on a system with both a camera and a scanner. Having a DEVICE attribute allows for the selection of a default, which is reasonable because some conferencing applications might always expect camera input whereas OCR applications would usually expect scanner input. And, as others have pointed out, in compressed media the MAXLENGTH limitation is not as practical as the MAXTIME limitation, in the case where an upload needs to be restricted in size. Does anyone think that this justification is inadequate? Cheers, James From owner-ietf-outbound Wed Mar 1 23:31:04 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA23480 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 23:30:03 -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 ESMTP id XAA23433 for ; Wed, 1 Mar 2000 23:26:37 -0500 (EST) Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-green.research.att.com (Postfix) with ESMTP id 10E1D1E010; Wed, 1 Mar 2000 23:26:37 -0500 (EST) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id XAA09425; Wed, 1 Mar 2000 23:27:20 -0500 (EST) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id D811E41F16; Wed, 1 Mar 2000 23:26:30 -0500 (EST) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id C9003400B5; Wed, 1 Mar 2000 23:26:25 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: ietf@ietf.org, nanog@merit.edu Reply-To: smb@research.att.com Subject: Re: 47th IETF: ITRACE BOF Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Mar 2000 23:26:25 -0500 Sender: smb@research.att.com Message-Id: <20000302042630.D811E41F16@SIGABA.research.att.com> X-Loop: ietf@ietf.org For those who are interested in the ITRACE BoF, there is a mailing list ietf-itrace@research.att.com. Subscribe by sending the message body subscribe to majordomo@research.att.com --- > ICMP Traceback BOF (itrace) > > Thursday, March 30 at 1530-1730 > =============================== > > CHAIR: Steve Bellovin > > DESCRIPTION: > > The purpose of the BoF is to look at a mechanism to help address the > problem of tracing back denial of service attacks. The suggested > mechanism is that with low probability (order 1/20,000), a router > seeing a packet would send to the destination an ICMP message giving > as much information as it knows about the immediate previous hop of > that packet. With enough of these messages -- and if one is being > flooded, by definition there will be a lot of traffic, so that the > low probabilities will still result in a reasonably complete set of > traceback packets. > > Such a mechanism has other uses as well. It lets people trace down > the source of accidentally-emitted bogus packets, i.e., those with > RFC1918 addresses. It helps characterize the reverse path, which > traceroute does not do. > > The output will be a standards-track RFC describing the packet format, > and the conditions under which it should be sent. Issues include > authentication, router load, and host load. > > AGENDA: > > Introduction, motivation 15 min > Marcus Leech's prototype 20 min > Open issues list 30 min > Charter 20 min > > --Steve Bellovin From owner-ietf-outbound Wed Mar 1 23:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA24029 for ietf-outbound.10@ietf.org; Wed, 1 Mar 2000 23: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 ESMTP id XAA23451 for ; Wed, 1 Mar 2000 23:28:16 -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 C21B94CE03; Wed, 1 Mar 2000 23:28:17 -0500 (EST) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id XAA09996; Wed, 1 Mar 2000 23:28:17 -0500 (EST) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 4F83541F16; Wed, 1 Mar 2000 23:28:17 -0500 (EST) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 4088C400B5; Wed, 1 Mar 2000 23:28:12 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" Cc: ietf@ietf.org, nanog@merit.edu Reply-To: smb@research.att.com Subject: Re: 47th IETF: ITRACE BOF Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Mar 2000 23:28:12 -0500 Sender: smb@research.att.com Message-Id: <20000302042817.4F83541F16@SIGABA.research.att.com> X-Loop: ietf@ietf.org "Steven M. Bellovin" writes: > For those who are interested in the ITRACE BoF, there is a mailing list > ietf-itrace@research.att.com. Subscribe by sending the message body > > subscribe > > to majordomo@research.att.com I love sending followups to my own notes... The body of the message should, of course, be subscribe ietf-itrace --Steve Bellovin From owner-ietf-outbound Thu Mar 2 08:53:46 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA12762 for ietf-outbound.10@ietf.org; Thu, 2 Mar 2000 08:50:02 -0500 (EST) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12219 for ; Thu, 2 Mar 2000 08:40:17 -0500 (EST) Received: from pembo (pembo.cwi.nl [192.16.201.136]) by hera.cwi.nl with SMTP id OAA16100 for ; Thu, 2 Mar 2000 14:39:05 +0100 (MET) Message-ID: <00aa01bf844c$df390460$88c910c0@cwi.nl> From: "Steven Pemberton" To: "James P. Salsman" Cc: , References: <200003011932.LAA02283@shell9.ba.best.com> Subject: Re: Device upload for all platforms -- the official HTML WG position Date: Thu, 2 Mar 2000 14:40:28 +0100 Organization: CWI 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.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit From: "James P. Salsman" > Device upload -- of any kind -- has not yet been implemented in Opera. Which is not actually the fault of the HTML WG. > You know that the CTO of Opera software has said they will wait for a > W3C Recommendation (or Working Draft) on device upload. I checked with him at the time that you made this claim. He actually said that they wouldn't implement your proposal unless it was a W3C recommendation. > Opera, even > on Windows, will not interpret MSIE OBJECT or Netscape EMBED tags which > are used for microphone upload on those browsers under Windows. There > is simply no browser on Mac or Linux (other than my experimental > build of pre-gecko Mozilla) which is capable of even microphone upload. Which is not to say that it can't be done. > I am sure we both want to resolve this. Would you please list all > the flaws of which you are aware -- with as little or as much detail > as you have time for -- along with, when available, how they could > be fixed? I promise you I will devote my efforts to your comments > until you are satisfied that they are resolved, but I do need your > help to understand which issues you consider flaws. I will do it on two conditions that you have to promise to: That I never, ever, have to repeat it again. That you stop hassling the HTML WG and spreading mistruths. I will then spend the time to reanalyse your document. Best wishes, Steven Pemberton Chair, W3C HTML WG From owner-ietf-outbound Thu Mar 2 15:40:42 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA26205 for ietf-outbound.10@ietf.org; Thu, 2 Mar 2000 15:40: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 ESMTP id PAA25633 for ; Thu, 2 Mar 2000 15:30:25 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id MAA09607; Thu, 2 Mar 2000 12:28:57 -0800 (PST) Date: Thu, 2 Mar 2000 12:28:57 -0800 (PST) From: "James P. Salsman" Message-Id: <200003022028.MAA09607@shell9.ba.best.com> To: Steven.Pemberton@cwi.nl Subject: Re: Device upload for all platforms -- the official HTML WG position Cc: ietf@ietf.org, www-html@W3.ORG In-Reply-To: <00aa01bf844c$df390460$88c910c0@cwi.nl> X-Loop: ietf@ietf.org Dear Dr. Pemberton, Thank you for your reply: >> I am sure we both want to resolve this. Would you please list all >> the flaws of which you are aware -- with as little or as much detail >> as you have time for -- along with, when available, how they could >> be fixed? I promise you I will devote my efforts to your comments >> until you are satisfied that they are resolved, but I do need your >> help to understand which issues you consider flaws. > > I will do it on two conditions that you have to promise to: > > That I never, ever, have to repeat it again. Agreed; this is preferable for us both. > That you stop hassling the HTML WG and spreading mistruths. While I don't know what you consider hassling, and fear the subjectivity of the term could be used to call my trustworthyness in to question, I promise that, too. You understand, better than most, that reasonable people are capable of honest disagreements on both political and technical matters. I look forward to the final list of issues and the opportunity to address them conconclusivly. Cheers, James From owner-ietf-outbound Thu Mar 2 16:10:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA27176 for ietf-outbound.10@ietf.org; Thu, 2 Mar 2000 16:10:03 -0500 (EST) Received: from mercury.broadjump.com (mercury.broadjump.com [206.225.49.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27082 for ; Thu, 2 Mar 2000 16:07:48 -0500 (EST) Received: by mercury.broadjump.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 15:02:51 -0600 Message-ID: <959C31D5DB12D311903C0090277B0C7E3C8D40@mercury.broadjump.com> From: Newland Moorefield To: "'James P. Salsman'" , Steven.Pemberton@cwi.nl Cc: ietf@ietf.org, www-html@W3.ORG Subject: RE: Device upload for all platforms -- the official HTML WG posit ion Date: Thu, 2 Mar 2000 15:02:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF848A.AB9AC164" 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_01BF848A.AB9AC164 Content-Type: text/plain; charset="iso-8859-1" what is wrong with all you people? i subscribed to this god-forsaken listserv hoping that i'd learn something. all i've learned is that you're a bunch of negative, argumentative, anti-collaborative bores. shame on you for making the W3C look bad. -----Original Message----- From: James P. Salsman [mailto:bovik@best.com] Sent: Thursday, March 02, 2000 2:29 PM To: Steven.Pemberton@cwi.nl Cc: ietf@ietf.org; www-html@w3.org Subject: Re: Device upload for all platforms -- the official HTML WG position Dear Dr. Pemberton, Thank you for your reply: >> I am sure we both want to resolve this. Would you please list all >> the flaws of which you are aware -- with as little or as much detail >> as you have time for -- along with, when available, how they could >> be fixed? I promise you I will devote my efforts to your comments >> until you are satisfied that they are resolved, but I do need your >> help to understand which issues you consider flaws. > > I will do it on two conditions that you have to promise to: > > That I never, ever, have to repeat it again. Agreed; this is preferable for us both. > That you stop hassling the HTML WG and spreading mistruths. While I don't know what you consider hassling, and fear the subjectivity of the term could be used to call my trustworthyness in to question, I promise that, too. You understand, better than most, that reasonable people are capable of honest disagreements on both political and technical matters. I look forward to the final list of issues and the opportunity to address them conconclusivly. Cheers, James ------_=_NextPart_001_01BF848A.AB9AC164 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Device upload for all platforms -- the official HTML WG = position

what is wrong with all you people? i subscribed to = this god-forsaken listserv hoping that i'd learn something. all i've = learned is that you're a bunch of negative, argumentative, = anti-collaborative bores. shame on you for making the W3C look = bad.

-----Original Message-----
From: James P. Salsman [mailto:bovik@best.com]
Sent: Thursday, March 02, 2000 2:29 PM
To: Steven.Pemberton@cwi.nl
Cc: ietf@ietf.org; www-html@w3.org
Subject: Re: Device upload for all platforms -- the = official HTML WG
position


Dear Dr. Pemberton,

Thank you for your reply:

>> I am sure we both want to resolve = this.  Would you please list all
>> the flaws of which you are aware -- with as = little or as much detail
>> as you have time for -- along with, when = available, how they could
>> be fixed?  I promise you I will devote = my efforts to your comments
>> until you are satisfied that they are = resolved, but I do need your
>> help to understand which issues you = consider flaws.
>
> I will do it on two conditions that you have to = promise to:
>
>   That I never, ever, have to repeat = it again.

Agreed; this is preferable for us both.

>   That you stop hassling the HTML WG = and spreading mistruths.

While I don't know what you consider hassling, and = fear the subjectivity
of the term could be used to call my trustworthyness = in to question, I
promise that, too.  You understand, better than = most, that reasonable
people are capable of honest disagreements on both = political and
technical matters.

I look forward to the final list of issues and the = opportunity to
address them conconclusivly.

Cheers,
James

------_=_NextPart_001_01BF848A.AB9AC164-- From owner-ietf-outbound Thu Mar 2 16:20:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA27575 for ietf-outbound.10@ietf.org; Thu, 2 Mar 2000 16:20:02 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26901; Thu, 2 Mar 2000 16:02:11 -0500 (EST) Received: from gwz (ssh.cisco.com [171.69.10.34]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id NAA20113; Thu, 2 Mar 2000 13:01:29 -0800 (PST) Message-Id: <200003022101.NAA20113@franklin.cisco.com> X-Sender: gwz@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 02 Mar 2000 13:01:27 -0800 To: ietf@ietf.org From: Glen Zorn Subject: Re: 47th IETF: DRAFT AGENDA Cc: wgchairs@ietf.org, bofchairs@ietf.org In-Reply-To: <200003022016.PAA24817@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 03:16 PM 03/02/2000 -0500, agenda@ietf.org wrote: ... >MONDAY, March 27, 2000 >0800-1930 IETF Registration - Foyer 1 >0800-0900 Continental Breakfast - Foyer and Circulation Area >0900-0930 Opening Plenary Session - Hall E >0930-1130 Morning Sessions > APP apparea Applications Area Meeting > INT zeroconf Zero Configuration Networking WG > OPS tmnsnmp TMN-SNMP BOF > RTG bgmp Border Gateway Multicast Protocol WG * > SEC ipsra IP Security Remote Access BOF How many BOFs do these marketroids get? From owner-ietf-outbound Thu Mar 2 16:50:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA28820 for ietf-outbound.10@ietf.org; Thu, 2 Mar 2000 16:50:02 -0500 (EST) Received: from sjgw.ipo.att.com (gate.ipo.att.com [135.197.57.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28721 for ; Thu, 2 Mar 2000 16:46:32 -0500 (EST) Received: from exchsj06.ipo.att.com (exchsj06.ipo.att.com [135.197.72.26]) by sjgw.ipo.att.com (8.8.5/8.8.8) with ESMTP id NAA04503; Thu, 2 Mar 2000 13:44:59 -0800 (PST) Received: from larry (mp-dhcp-2-84.attlabs.att.com [135.197.2.84]) by exchsj06.ipo.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FAVRR978; Thu, 2 Mar 2000 13:41:32 -0800 From: "Larry Masinter" To: , "Paul Hoffman / IMC" Cc: Subject: IETF and HTML (was: Device upload for all platforms -- the official HTML WG position) Date: Thu, 2 Mar 2000 13:45:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0026_01BF844D.92605C00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Loop: ietf@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0026_01BF844D.92605C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > > Why is this thread being run on the IETF mailing list? The IETF > handed off responsibility for HTML to the W3C long ago. > > When did the IETF ever have responsibility for HTML, exactly? Actually, the handoff hasn't been quite completed. There was a last call on draft-connolly-text-html-01.txt issued 10/28/99. There were several comments recieved during the last call period, and I submitted draft-connolly-text-html-02.txt on 11/16/1999. The last call items are now currently listed as "AD Review" under http://www.ietf.org/IESG/status.html. It would be useful to update the XHTML reference (since this is no longer a 'work in progress'). But completion of this item would allow for the handoff to be completed. Larry -- http://larry.masinter.net ------=_NextPart_000_0026_01BF844D.92605C00 Content-Type: message/rfc822 Content-Disposition: attachment Reply-To: From: "The IESG" Sender: To: Cc: Subject: Last Call: The 'text/html' Media Type to Informational Date: Thu, 28 Oct 1999 03:01:50 -0800 Message-ID: <199910281101.HAA13443@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit The IESG has received a request to consider The 'text/html' Media Type as an Informational RFC. This has been reviewed in the IETF but is not the product of an IETF Working Group. In the same action, the IESG will consider reclassifying the following RFCs as Historic: RFC1866 Hypertext Markup Language - 2.0 RFC1867 Form-based File Upload in HTML RFC1942 HTML Tables RFC1980 A Proposed Extension to HTML: Client-Side Image Maps RFC2070 Internationalization of the Hypertext Markup Language The listed RFCs are obsolete versions of the HTML specification. The current HTML specification which is maintained by the World Wide Web consortium should be used for new implementations. The document proposed as Informational is intended to supersede the current MIME registration of the text/html content-type, which references a now-obsolete version of the HTML specification. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 10, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-connolly-text-html-01.txt ------=_NextPart_000_0026_01BF844D.92605C00-- From owner-ietf-outbound Thu Mar 2 18:40:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA01621 for ietf-outbound.10@ietf.org; Thu, 2 Mar 2000 18:40:03 -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 ESMTP id SAA01435 for ; Thu, 2 Mar 2000 18:32:04 -0500 (EST) From: Melinda.Shore@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id BAA18381; Fri, 3 Mar 2000 01:31:52 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id BAA26956; Fri, 3 Mar 2000 01:31:50 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 17:31:50 -0600 Message-ID: To: ietf@ietf.org, end2end-interest@isi.edu, nat@livingston.com Cc: tiphon@list.etsi.fr Subject: foglamps BOF and mailing list Date: Thu, 2 Mar 2000 17:30:51 -0600 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 It has been recognized for some time that breaking the end-to-end model through the introduction of elements like network address translators causes serious problems in IP networks, and the IETF has had ongoing discussions of those problems with an eye towards solving them. What is probably not fully appreciated, however, is the extent to which NAT and firewall-related problems are interfering with the deployment of major applications, such as the migration from circuit-based to packet-based telecommunications networks. Some of us are beginning to suspect that it may be time to bite the bullet and make certain network elements visible to applications by creating explicit external interfaces. To that end, we've requested a BOF session ("foglamps") for the upcoming meeting in Adelaide, and have created a foglamps mailing list on egroups.com (sorry). To subscribe, send email to foglamps-subscribe@egroups.com or use the web-based interface at http://www.egroups.com. Background reading would include: draft-lear-foglamps-01.txt draft-shore-h323-firewalls-00.txt draft-rosenberg-sip-firewalls-00.txt RFC 2775 draft-iab-ntwlyrws-over-02.txt I'll send along an agenda as soon as it's finalized. Melinda -- Melinda Shore Nokia IP Telephony 127 West State Street "Software longa, Ithaca, NY 14850 hardware brevis" +1 607 273 0724 (office) +1 607 275 3610 (fax) +1 607 227 4096 (mobile) melinda.shore@nokia.com From owner-ietf-outbound Fri Mar 3 02:42:05 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA20784 for ietf-outbound.10@ietf.org; Fri, 3 Mar 2000 02:40:02 -0500 (EST) Received: from server.jad.net ([202.134.2.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20739 for ; Fri, 3 Mar 2000 02:33:00 -0500 (EST) Received: from oke.com (cf-isrlab7.comp.nus.edu.sg [137.132.85.181]) by server.jad.net (8.9.2/8.9.2) with ESMTP id PAA20454; Fri, 3 Mar 2000 15:34:34 +0700 (JAVT) (envelope-from rms46@oke.com) Sender: ibrahim@server.jad.net Message-ID: <38BF6A84.453EE958@oke.com> Date: Fri, 03 Mar 2000 15:32:20 +0800 From: "Rahmat M. Samik-Ibrahim" Reply-To: rms46.oke.com@vlsm.org Organization: VLSM-TJT X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: MILIS IETF Subject: 1601bis -03: Still Vague 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: Just a quick comment on 1601bis version 3 http://www.ietf.org/internet-drafts/draft-iab-rfc1601bis-03.txt It is not clear on why the IAB does not want to take time for a retreat/ self-assessment of what really works and what not. It seems that the IAB still does not want to empower itself :-(. The role descriptions of section 2 remains vague. Thus, the relation with IANA and the RFC Editor will remain vague. No wonder, if the RFC Editor once has claimed: "The RFC Editor is chartered by the Internet Society (ISOC) and the Federal Network Council (FNC)" (http://www.faqs.org/rfcs/rfc-editor/what-is-rfc-editor.html) OK, it's time for an Oolong Tea Party :^, -- - Rahmat M. Samik-Ibrahim -- VLSM-TJT -- http://rms46.vlsm.org/ - Here we are,poised on the precipice of suicide slope-Calvin 20Feb89 From owner-ietf-outbound Fri Mar 3 04:51:43 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA21668 for ietf-outbound.10@ietf.org; Fri, 3 Mar 2000 04:50: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 ESMTP id EAA21611 for ; Fri, 3 Mar 2000 04:40:06 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id BAA27864; Fri, 3 Mar 2000 01:39:22 -0800 (PST) Date: Fri, 3 Mar 2000 01:39:22 -0800 (PST) From: "James P. Salsman" Message-Id: <200003030939.BAA27864@shell9.ba.best.com> To: braden@endoframe.com Subject: flying pigs considered harmful Cc: ietf@ietf.org, www-html@W3.ORG X-Loop: ietf@ietf.org > The only > way to obtain device upload does not even involve the INPUT tag > (on Windows' MSIE, the OBJECT tag is used with an insecure > "ActiveX" binary; on Netscape Navigator under Windows, the EMBED > tag is used with a similarly insecure arrangement where the user > must "Grant All" system privleges to the EMBEDed binary code.) Yes, well, one could probably use OBJECT/EMBED to make pigs fly if one were so inclined and prepared to waive the relevant security precautions. Such implementations are interesting in that they demonstrate the availability of the technology, but the applicability of their syntax to a general purpose mechanism for a specific need is low to nil. This situation is by no means unique to device upload, nor is it a particularly surprising outcome. > This complex state of affairs need not be so. > > If the W3C would just take a stand, and tell the browser vendors > that in order to be compliant with the W3C Recommendations, if > device upload is implemented then it should be available in a > certain way, then they would probably conform to stay compliant. The W3C has defined conformance terms for HTML 4, CSS1, CSS2... And how many browsers conform to date? I'm a little bit skeptical that having the W3C stomp its feet would do a bit of good. From owner-ietf-outbound Fri Mar 3 05:01:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA21777 for ietf-outbound.10@ietf.org; Fri, 3 Mar 2000 05:00: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 ESMTP id EAA21750 for ; Fri, 3 Mar 2000 04:57:40 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id BAA01160; Fri, 3 Mar 2000 01:57:03 -0800 (PST) Date: Fri, 3 Mar 2000 01:57:03 -0800 (PST) From: "James P. Salsman" Message-Id: <200003030957.BAA01160@shell9.ba.best.com> To: braden@endoframe.com Subject: Re: flying pigs considered harmful Cc: ietf@ietf.org, www-html@W3.ORG In-Reply-To: <200003030939.BAA27864@shell9.ba.best.com> X-Loop: ietf@ietf.org Line noise transmitted the message below unattributed; my apologies to Braden McDaniel. >> [JPS:] The only >> way to obtain device upload does not even involve the INPUT tag >> (on Windows' MSIE, the OBJECT tag is used with an insecure >> "ActiveX" binary; on Netscape Navigator under Windows, the EMBED >> tag is used with a similarly insecure arrangement where the user >> must "Grant All" system privileges to the EMBEDed binary code.) > > [BNM:] Yes, well, one could probably use OBJECT/EMBED to make pigs > fly if one were so inclined and prepared to waive the relevant > security precautions. The security concerns are actually more significant than the "it won't run on my Mac/Unix workstation" -- at least for the majority that don't have Mac or Unix workstations. Promiscuous use of insecure binary plug-in applications is another reason against OBJECT and EMBED. >> If the W3C would just take a stand, and tell the browser vendors >> that in order to be compliant with the W3C Recommendations, if >> device upload is implemented then it should be available in a >> certain way, then they would probably conform to stay compliant. > > The W3C has defined conformance terms for HTML 4, CSS1, CSS2... And how > many browsers conform to date? I'm a little bit skeptical that having the > W3C stomp its feet would do a bit of good. It is completely reasonable for the W3C to act in the general interest of web users. Supporting device upload would be in their interest because of the reduced security concerns, the more widespread accessibility on a diversity of platforms, and the general utility of the services enabled for education, commerce and industry. I believe the W3C will try to hold on to its leadership role in consumer protection pertaining to browser technology. Cheers, James From owner-ietf-outbound Fri Mar 3 14:42:37 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA07388 for ietf-outbound.10@ietf.org; Fri, 3 Mar 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 ESMTP id OAA07227 for ; Fri, 3 Mar 2000 14:31:04 -0500 (EST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06456; Fri, 3 Mar 2000 11:30:45 -0800 (PST) Message-Id: <4.3.2.20000303112904.00d202e0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 03 Mar 2000 11:31:21 -0800 To: rms46.oke.com@vlsm.org, MILIS IETF From: Paul Hoffman / IMC Subject: Re: 1601bis -03: Still Vague In-Reply-To: <38BF6A84.453EE958@oke.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 03:32 PM 3/3/00 +0800, Rahmat M. Samik-Ibrahim wrote: >The role descriptions of section 2 remains vague. Thus, the relation >with IANA and the RFC Editor will remain vague. It seems quite clear to me. You might want to suggest alternative wording that you think is clearer. > No wonder, if the >RFC Editor once has claimed: > "The RFC Editor is chartered by the Internet Society (ISOC) > and the Federal Network Council (FNC)" > (http://www.faqs.org/rfcs/rfc-editor/what-is-rfc-editor.html) That might have been true at one point, and things have changed. What's the problem with that? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-outbound Fri Mar 3 18:40:47 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA12056 for ietf-outbound.10@ietf.org; Fri, 3 Mar 2000 18:40:02 -0500 (EST) Received: from chaplin.csd.uwo.ca (chaplin.csd.uwo.ca [129.100.10.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11844 for ; Fri, 3 Mar 2000 18:25:32 -0500 (EST) From: Hanan Lutfiyya Message-Id: <200003032303.XAA04290@brown> Date: Fri, 3 Mar 2000 23:03:31 GMT To: *ifip-emailmgt@ics.uci.edu, agentx@zloty.fv.com, aow-nmsig@stc.ipa.go.jp, applmib-request@emi-summit.com, arslist@yorku.ca, atm@tango.cos.com, aya@arc.bs1.fc.nec.co.jp, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comp.protocols.iso@bbn.com, comsoc-conferences@IEEE.ORG, comsoc-gicb@IEEE.ORG, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, conferences@iao.fhg.de, corpcom@OSF.ORG, ctc-members@redbank.tinac.com, disman@nexen.com, dsm@nemo.ncsl.nist.gov, end2end-interest@isi.edu, enternet@bbn.com, ewos-egnm@extend.iihe.ac.be, gateway@nmf.org, hnms-users@ghost.CS.ORST.EDU, hp-nodemgr@rrz.uni-koeln.de, hubmib@rosemail.rose.hp.com, ieee.announce@bbn.com, ietf-madman@innosoft.com, ietf@ietf.org, ietf@venera.isi.edu, ifip-nm@bbn.com, iimc@thumper.bellcore.com, im97-oc@ctr.columbia.edu, im97-pc@ctr.columbia.edu, intap-aow-nm@sy.isl.melco.co.jp, yemini@cs.columbia.edu, yjy2368@chollian.dacom.co.kr, yogeshg@cai.com, yosimura@ccrle.nec.de, yun@std.trd.tmg.nec.co.jp, yzheng1@scudc.scu.edu, zhen.huang@attws.com, zhu@tri.sbc.com, zimmer@first.gmd.de, zuwei.liu@nd.edu, zwickerd@nbnet.nb.ca Subject: 4th IEEE International Workshop on Systems Management X-Loop: ietf@ietf.org Call for Papers ------------------------------------------------------------------------- We apologize if you receive this message more than once. ------------------------------------------------------------------------ This represents a change of dates due to e-mail distribution problems. ***New date for submissions is April 3, 2000*** IEEE 4th International Workshop on Systems Management (Theme: Exploitation of Data Mining and Visualization Age) Montreal Quebec, Canada June 28-30, 2000 This workshop is the fourth in a series of highly successful forums for the discussion of research in the area of systems management. Previous workshops have been held in Los Angeles, California, Toronto, Ontario, and Newport, RI. This year the scope of this workshop is mining, visualization, management, and acquisition of data for network and systems management. With the widespread adoption of standards for data collection (e.g., SNMP in data networks CMIP in telecommunications networks) and the growing acceptance of technologies for information modeling (e.g., UML, XML, and CIM), the next challenge for network and systems management is interpreting the data. These interpretations should be task oriented, such as for problem detection, problem diagnosis, and planning. The purpose of this workshop is to bring together researchers with in-depth knowledge of data interpretation and presentation to focus on challenges of network and systems management. These challenges include: heterogeneous data semantics, dealing with large data volumes, noisely data, high dimensional data, dearth of labelled data for supervised learning, and the exploitation of underlying structure (e.g., based on network topologies). To aid in our objective, several data sets will be provided in advance of the workshop, along with some background about the kinds of information that should be extracted. Workshop participants are encouraged to submit papers (or extended abstracts) that apply their techniques to these data. The URL for our site is http://www.csd.uwo.ca/SMW4. WORKSHOP FORMAT --------------- Three kinds of participation are possible. The first are presenters of full papers that fall within the topic areas considered by this workshop. The second are those who report on the results of mining and/or visualizing network and systems management data made available for this workshop, which can be found under Dataset Information at http://www.csd.uwo.ca/SMW4/. This data has been provided by Cooperative Association for Internet Data Analysis (CAIDA). Also encouraged is participation by individuals seeking information on recent advances in the application of data mining and visualization to network and systems management. An award will be presented to the best paper that provides the best insight into the analysis (visualisation or patterns) of the skitter data (please see "Dataset Information" at http://www.csd.uwo.ca/SMW4/). CALL FOR PARTICIPATION ---------------------- All submitted papers will be reviewed by experts in the area of submission. Individuals presenting the results of analyses of the data sets provided by this workshop should submit an extended abstract summarizing their methodology and results. All accepted contributions (including extended abstracts) will be eligible for publication in the bound proceedings of the workshop. At least one of the authors of each paper must register for the workshop to present the paper. Papers are to be submitted in English. The cover page should include paper title, author(s) full name, affiliations, complete address(es), telephone number(s), and electronic mail address(es). Full-length papers should have a brief abstract and be no longer than 12 pages (6,000 words), including references and figures. Extended abstracts should be in the format of an extended abstract that is no longer than 2 pages (1,000 words), excluding figures. Proposals for panel discussions are also solicited. Panels are scheduled for 1.5 hours. Proposals should specify the topic, panel chair, and participants. Please include a two page abstract that highlights key points for discussion and areas of controversy that will be addressed. SUBMISSION ---------- All submissions should be sent by email in postscript or pdf form to smw4@csd.uwo.ca with the subject line "SMW4 Paper Submission: ," where indicates the compression used if any (e.g., paper.ps.gz). If electronic submission is not possible, please submit 4 paper copies to the following address: Professor Hanan Lutfiyya Department of Computer Science The University of Western Ontario London, Ontario CANADA N6A 5B7 TOPICS ------ Application of data mining algorithms to network and systems management Scalable and effective visualizations for management tasks Efficient techniques for on-line pattern recognition (e.g., for detecting performance problems and security intrusions) Scalable architectures for distributed data mining and visualization Case studies of data mining and visualization in systems and network management Agent technologies for building distributed mining and visualization applications Information models that aid in mining and visualizing network systems management data IMPORTANT DATES --------------- Papers, panels, and extended abstracts due: April 3, 2000 Author notification: April 21, 2000 Camera ready copy: May 10, 2000 ORGANIZING COMMITTEE -------------------- GENERAL CHAIR Hanan Lutfiyya Department of Computer Science The University of Western Ontario hanan@csd.uwo.ca VICE CHAIRS: Paul J. Brusil SMD 35 Brackenbury Lane Beverly, Massachusetts, USA 01915-3821 brusil@snad.ncsl.nist.gov Joseph L. Hellerstein IBM Thomas J. Watson Research Center Hawthorne, New York, USA hellers@us.ibm.com From owner-ietf-outbound Fri Mar 3 21:40:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA13683 for ietf-outbound.10@ietf.org; Fri, 3 Mar 2000 21:40:03 -0500 (EST) Received: from emrys.qualcomm.com (emrys.qualcomm.com [129.46.2.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13621 for ; Fri, 3 Mar 2000 21:32:24 -0500 (EST) Received: from randy-nt.qualcomm.com (randy-nt.qualcomm.com [129.46.242.31]) by emrys.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with ESMTP id SAA14964; Fri, 3 Mar 2000 18:32:23 -0800 (PST) Message-Id: <4.3.0.20000303182045.00e8f420@randy-nt4.qualcomm.com> X-Sender: randy@randy-nt4.qualcomm.com@randy-nt4.qualcomm.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 03 Mar 2000 18:31:17 -0800 To: ietf47@connect.com.au, ietf@ietf.org From: Randall Gellens Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? In-Reply-To: <200002150227.MAA27866@kuji.off.connect.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 12:57 PM 2/15/00 +1030, Mark Prior wrote: >The package being offered is a WaveLAN IEEE Turbo 11Mbps PC card for >AU$276.36 (approx US$175). Drivers are available from Lucent for (at >least) Windows 95, 98, NT, CE, 2000, MacOS and Linux. Searching for "WaveLAN" at a catalog site shows (prices are in US$): LUCENT TECHNOLOGIES WaveLAN Turbo 11Mbps Wireless PC Card Silver; WEP $159.95 LUCENT TECHNOLOGIES WaveLAN Turbo 11Mbps Wireless PC Card Gold; 128RC4 $176.95 LUCENT TECHNOLOGIES WaveLan Wireless Bronze PC Card *While Supplies Last $235 LUCENT TECHNOLOGIES WaveLAN IEEE Bronze PC Card *Special Order $239.95 Could someone explain the differences between these? Is the first one the same as what is being offered? If so, it appears to be cheaper to buy it in the US. From owner-ietf-outbound Fri Mar 3 22:40:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA16035 for ietf-outbound.10@ietf.org; Fri, 3 Mar 2000 22:40:03 -0500 (EST) Received: from mauve.innosoft.com (mauve.innosoft.com [192.160.253.247]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15993 for ; Fri, 3 Mar 2000 22:36:05 -0500 (EST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-20 #35243) id <01JMLGMT3ZOG000L37@MAUVE.INNOSOFT.COM> for ietf@ietf.org; Fri, 03 Mar 2000 19:35:29 -0800 (PST) Date: Fri, 03 Mar 2000 19:20:48 -0800 (PST) Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? In-reply-to: "Your message dated Fri, 03 Mar 2000 18:31:17 -0800" <4.3.0.20000303182045.00e8f420@randy-nt4.qualcomm.com> To: Randall Gellens Cc: ietf47@connect.com.au, ietf@ietf.org Message-id: <01JMLW0UBEE0000L37@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed References: <200002150227.MAA27866@kuji.off.connect.com.au> X-Loop: ietf@ietf.org > At 12:57 PM 2/15/00 +1030, Mark Prior wrote: > >The package being offered is a WaveLAN IEEE Turbo 11Mbps PC card for > >AU$276.36 (approx US$175). Drivers are available from Lucent for (at > >least) Windows 95, 98, NT, CE, 2000, MacOS and Linux. I'm certainly not an expert on this stuff, but as it happens I've been playing around with a bunch of it recently both at home and at work. My comments below are based on this experience. > Searching for "WaveLAN" at a catalog site shows (prices are in US$): > LUCENT TECHNOLOGIES > WaveLAN Turbo 11Mbps Wireless > PC Card Silver; WEP > $159.95 This is the same card as an Apple Airport. It is 802.11 DS, 11Mbps, and supports Wire Equivalent Privacy (WEP). The idea here is that you need a key to get on the network, but once you're on you can see all the traffic "on the wire" that you care to. The Apple softare only lets you set a 40 bit key (actually what you do is enter a passphrase that is hashed down to 40 bits), but I believe a 64 bit key is supported by the underlying hardware. I don't know what the underlying crypto is -- probably DES, which of course means the key length is really only 56 bits... Unfortunately the Windows 2000 driver for this card doesn't yet support WEP. They say they are working on it. Amusingly, the Windows 95/98 driver does support WEP and it works just fine with an Apple Airport Base Station as long as you have a Mac with an Airport card to set up the base station to begin with. (Actually, even that probably isn't required unless you want to enable WEP or DHCP or NAT or some other option.) All this stuff about security probably isn't relevant in the IETF context, of course, but it nice if you what you get also is useful at home where network security may matter a bunch. $159 is about the same price I've seen for this card in the US. > LUCENT TECHNOLOGIES > WaveLAN Turbo 11Mbps Wireless > PC Card Gold; 128RC4 > $176.95 I believe this is the same as the Silver except the crypto is 128 bit. > LUCENT TECHNOLOGIES > WaveLan Wireless Bronze PC Card > *While Supplies Last > $235 I believe this card only operates at the slower 1-2 MBps rate. This is supposed to be compatible with the faster cards but I have not tried one to make sure. I believe some of these cards support WEP, but only at 40 bits. The price here seems way too high -- why not get a silver card instead? > LUCENT TECHNOLOGIES > WaveLAN IEEE Bronze PC Card > *Special Order > $239.95 I don't know what the difference between this and the previous card is, if any. > Could someone explain the differences between these? Is the first one the > same as what is being offered? If so, it appears to be cheaper to buy it > in the US. I hope this helps some. Ned From owner-ietf-outbound Fri Mar 3 23:20:41 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA16506 for ietf-outbound.10@ietf.org; Fri, 3 Mar 2000 23:20:01 -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 ESMTP id XAA16467 for ; Fri, 3 Mar 2000 23:19:19 -0500 (EST) Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by mail-green.research.att.com (Postfix) with ESMTP id 4F0881E00A; Fri, 3 Mar 2000 23:19:16 -0500 (EST) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id XAA23571; Fri, 3 Mar 2000 23:20:02 -0500 (EST) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 51FAA41F16; Fri, 3 Mar 2000 23:19:13 -0500 (EST) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 42F79400B5; Fri, 3 Mar 2000 23:19:08 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: ned.freed@innosoft.com Cc: Randall Gellens , ietf47@connect.com.au, ietf@ietf.org Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Mar 2000 23:19:08 -0500 Sender: smb@research.att.com Message-Id: <20000304041913.51FAA41F16@SIGABA.research.att.com> X-Loop: ietf@ietf.org In message <01JMLW0UBEE0000L37@MAUVE.INNOSOFT.COM>, ned.freed@innosoft.com writ es: > > This is the same card as an Apple Airport. It is 802.11 DS, 11Mbps, and > supports Wire Equivalent Privacy (WEP). The idea here is that you need a key > to > get on the network, but once you're on you can see all the traffic "on the > wire" that you care to. The Apple softare only lets you set a 40 bit key > (actually what you do is enter a passphrase that is hashed down to 40 bits), > but I believe a 64 bit key is supported by the underlying hardware. I don't > know what the underlying crypto is -- probably DES, which of course means > the key length is really only 56 bits... It's RC4, so the key length can be any integral number of bytes. --Steve Bellovin From owner-ietf-outbound Fri Mar 3 23:40:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA17056 for ietf-outbound.10@ietf.org; Fri, 3 Mar 2000 23:40:03 -0500 (EST) Received: from server.jad.net ([202.134.2.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17028 for ; Fri, 3 Mar 2000 23:37:01 -0500 (EST) Received: from oke.com (cf-isrlab7.comp.nus.edu.sg [137.132.85.181]) by server.jad.net (8.9.2/8.9.2) with ESMTP id MAA36935; Sat, 4 Mar 2000 12:38:42 +0700 (JAVT) (envelope-from rms46@oke.com) Sender: ibrahim@server.jad.net Message-ID: <38C092A9.69F1BE0D@oke.com> Date: Sat, 04 Mar 2000 12:35:53 +0800 From: "Rahmat M. Samik-Ibrahim" Reply-To: rms46.oke.com@vlsm.org Organization: VLSM-TJT X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: MILIS IETF Subject: Re: 1601bis -03: Still Vague References: <4.3.2.20000303112904.00d202e0@mail.imc.org> 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: First of all, it is not over until the RFC-Editor sings :^. Paul Hoffman / IMC wrote: >> The role descriptions of section 2 remains vague. Thus, the relation >> with IANA and the RFC Editor will remain vague. > It seems quite clear to me. You might want to suggest alternative wording > that you think is clearer. It is not about wordsmithing, but more about the fundamentals of section 2. Sub-section 2.1 is about "architectural oversight in more detail". However, it is not clear on how to measure the effectiveness of that sub-section. Thus, it will be not so easy for a NomCom member to evaluate the performance of the IAB. The only clue is perhaps the IAB's long queue of work-in-progress. For example, 1601bis has been more than 4 years in queue. Therefore, the nature of revising 1601bis must not be easy. Nonetheless, there will be no organizational improvement until the IAB is willing continuously to improve itself. See also "Managing The Non-Profit Organization -- Practices and Principles" (Peter F. Drucker, 1990) for more details. >> "The RFC Editor is chartered by the Internet Society (ISOC) >> and the Federal Network Council (FNC)" > That might have been true at one point, and things have changed. > What's the problem with that? Not much, just $1,295,517 regards, -- - Rahmat M. Samik-Ibrahim -- VLSM-TJT -- http://rms46.vlsm.org/ - Here we are,poised on the precipice of suicide slope-Calvin 20Feb89 From owner-ietf-outbound Sat Mar 4 05:00:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA01493 for ietf-outbound.10@ietf.org; Sat, 4 Mar 2000 05:00:02 -0500 (EST) Received: from server.jad.net ([202.134.2.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01448 for ; Sat, 4 Mar 2000 04:55:46 -0500 (EST) Received: from oke.com (cf-isrlab7.comp.nus.edu.sg [137.132.85.181]) by server.jad.net (8.9.2/8.9.2) with ESMTP id RAA40354; Sat, 4 Mar 2000 17:57:34 +0700 (JAVT) (envelope-from rms46@oke.com) Sender: ibrahim@server.jad.net Message-ID: <38C0BE90.165C0D69@oke.com> Date: Sat, 04 Mar 2000 15:43:12 +0800 From: "Rahmat M. Samik-Ibrahim" Reply-To: rms46.oke.com@vlsm.org Organization: VLSM-TJT X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: MILIS IETF Subject: Re: TCP Encapsulation within TCP References: <38BCED13.7FC865E6@geocities.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 Hello: A couple of days ago I have posted a query for **ONLINE DOCUMENTS** of practical TCP Encapsulation within TCP. Thanks for everyone who has replied in private. I am aware that someone in Harvard was doing it, however, I would like to know what is currently under development or already on the shelf. The issue itself was inspired by the recent DoS attack. So, basically it is about how a "small Mom and Pop ISP in the developing country" can have some control over its low speed upstream link. I was thinking of using a TCP window, since the characteristics of that technology are somewhat already known. Thus, the provider might have some control over how much SYNC packets it will accept, priority packets, filtering, etc., at the other end of the link. Someone has suggested to look on RSVP documents. However, I think that RSVP is too complicated. Someone has suggested to look on IPSEC documents. While security is desirable, it is not the main point. However, I believe that the ssh utility can be used for establishing the virtual links. Again, thanks for everyone who has replied my prior email! regards, -- - Rahmat M. Samik-Ibrahim -- VLSM-TJT -- http://rms46.vlsm.org/ - Here we are,poised on the precipice of suicide slope-Calvin 20Feb89 From owner-ietf-outbound Sat Mar 4 09:41:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA04236 for ietf-outbound.10@ietf.org; Sat, 4 Mar 2000 09:40:02 -0500 (EST) Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04183 for ; Sat, 4 Mar 2000 09:35:25 -0500 (EST) Received: from c8-a.snvl1.sfba.home.com ([24.0.25.96]) by poptart.corp.home.net (Netscape Messaging Server 3.54) with ESMTP id AAA42F8; Sat, 4 Mar 2000 06:35:19 -0800 Message-Id: <4.2.0.58.20000304093224.0098de90@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 04 Mar 2000 09:36:47 +0000 To: Randall Gellens From: RJ Atkinson Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? Cc: ietf@ietf.org In-Reply-To: <4.3.0.20000303182045.00e8f420@randy-nt4.qualcomm.com> References: <200002150227.MAA27866@kuji.off.connect.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 02:31 04-03-00 , Randall Gellens wrote: >At 12:57 PM 2/15/00 +1030, Mark Prior wrote: > >>The package being offered is a WaveLAN IEEE Turbo 11Mbps PC card for >>AU$276.36 (approx US$175). Drivers are available from Lucent for (at >>least) Windows 95, 98, NT, CE, 2000, MacOS and Linux. > >Searching for "WaveLAN" at a catalog site shows (prices are in US$): > > LUCENT TECHNOLOGIES > WaveLAN Turbo 11Mbps Wireless > PC Card Silver; WEP > $159.95 > > > LUCENT TECHNOLOGIES > WaveLAN Turbo 11Mbps Wireless > PC Card Gold; 128RC4 > $176.95 > > > LUCENT TECHNOLOGIES > WaveLan Wireless Bronze PC Card > *While Supplies Last > $235 > > > LUCENT TECHNOLOGIES > WaveLAN IEEE Bronze PC Card > *Special Order > $239.95 > >Could someone explain the differences between these? Is the first one the same as what is being offered? If so, it appears to be cheaper to buy it in the US. Mail-order/web prices for the Lucent WaveLAN Turbo Silver PCMCIA card are cheaper in the US than at the IETF-discounted price in Adelaide. That noted, a lot of IETF folks are coming from other countries, where the IETF-discounted price might represent a very considerable savings versus their local price. Also, there are "loaner" cards available at IETF (for credit card imprint) permitting folks to try one out before purchase, etc. The difference between Silver and Gold is the quality of the crypto supported, by the way. In AU, it appears that Gold cards are available for sale only to financial institutions or government-related institutions. By the way, FreeBSD, OpenBSD, and NetBSD all have device drivers for the Lucent WaveLAN PCMCIA cards according to their respective web sites. Ran rja@inet.org From owner-ietf-outbound Sat Mar 4 12:10:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA05817 for ietf-outbound.10@ietf.org; Sat, 4 Mar 2000 12:10:02 -0500 (EST) Received: from khms.westfalen.de (mail@p3E9BA4A2.dip.t-dialin.net [62.155.164.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05719 for ; Sat, 4 Mar 2000 12:00:37 -0500 (EST) Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 12RHuv-0008WM-00 (Debian); Sat, 04 Mar 2000 18:00:37 +0100 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 04 Mar 2000 17:59:59 +0200 Date: 04 Mar 2000 18:05:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: ietf@ietf.org Message-ID: <7$D-JxTmw-B@khms.westfalen.de> In-Reply-To: <1531.951900198@cs.ucl.ac.uk> Subject: Re: What is the latest trend of network research ??????? 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: <000d01bf834d$88c203c0$ec406fa6@Zhengyq.sdt> <1531.951900198@cs.ucl.ac.uk> 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-Loop: ietf@ietf.org J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) wrote on 01.03.00 in <1531.951900198@cs.ucl.ac.uk>: > basically, the mobile phone business is making moves to do what > MSN failed and capture "the whole internet" by making itself the one and > only portal - in europe at least, they stand a chance of succeeding for 3 > reasons No chance at all that I can see. Especially considering that per-minute charges from mobiles are about ten times as high as from traditional phones over here. Maybe if they come down. A lot. > i) traditional telcos make dinosaurs look like rodents when it comes > to deploying fancy new fast access nets and services - newbies are > practically illegally > prevented from entering the market despite EU de-regualtion Hmm. The best and fastest net around here seems to be the one from the former monopoly telco (much to everybody's surprise, including mine). Seems they're deploying fancy new access stuff like mad. OTOH, newcomers are certainly around, and have been for a long time. > ii) the mobile guys have practically no regulation Hmm. One of the mobile guys is the ex-monopoly telco. I don't see all that much difference between them and the others. > iii) some mobile phone service providers are becoming credit card > companies -this is very very shrewd....think about it... Haven't heard of that one happening over here. Oh, the monopoly telco had some news recently about doing something with banks - I suspect it's actually nothing all that interesting once you look past the hype. MfG Kai From owner-ietf-outbound Sat Mar 4 13:20:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA06483 for ietf-outbound.10@ietf.org; Sat, 4 Mar 2000 13:20:02 -0500 (EST) Received: from orchard.arlington.ma.us (orchard.hamachi.org [4.255.0.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06447 for ; Sat, 4 Mar 2000 13:11:48 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id SAA11701; Sat, 4 Mar 2000 18:09:01 GMT Message-Id: <200003041809.SAA11701@orchard.arlington.ma.us> To: ned.freed@innosoft.com cc: Randall Gellens , ietf47@connect.com.au, ietf@ietf.org Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? In-Reply-To: Message from ned.freed@innosoft.com of "Fri, 03 Mar 2000 19:20:48 PST." <01JMLW0UBEE0000L37@MAUVE.INNOSOFT.COM> Date: Sat, 04 Mar 2000 13:09:00 -0500 From: Bill Sommerfeld X-Loop: ietf@ietf.org > This is the same card as an Apple Airport. It is 802.11 DS, 11Mbps, and > supports Wire Equivalent Privacy (WEP). The idea here is that you need a key to > get on the network, but once you're on you can see all the traffic "on the > wire" that you care to. The Apple software only lets you set a 40 bit key > (actually what you do is enter a passphrase that is hashed down to 40 bits), > but I believe a 64 bit key is supported by the underlying hardware. [Warning... gory crypto details enclosed. I'm not a cryptographer, just a protocol engineer who uses the stuff every now and then..] I haven't found specs for the "128"-bit WEP supported by the turbo cards, but the standard version of WEP (which I believe is what's implemented by the Silver cards) uses RC4 with a 64 bit key but roughly 40 bit effective strength. RC4 is a stream cipher -- it generates a pseudo-random bitstream which then gets XOR'ed with the plaintext. If two (or more) packets share the exact same keystream, there are various cryptanalytic techniques which can be used to easily extract plaintext from one or both of them. (among other things, this is why reusing a one time pad is so dangerous). It's also usually very easy to inject chosen plaintext into a low-level network component, which makes keystream recovery even easier. So, to address this within WEP, 24 bits of the 64 bit packet key are used as an "initialization vector"; they're chosen different for each packet and are sent in the clear in the WEP header; the remaining 40 bits are a secret shared by the nodes in the network. However you still run into the "two time pad" problem if IV's are reused, which will definitely occur by the time 2**24 packets have been sent through the network using a given key (and may occur much sooner depending on how IV's are chosen). I hope the 128 bit "gold" cards use a longer IV.. - Bill From owner-ietf-outbound Sat Mar 4 14:10:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA07020 for ietf-outbound.10@ietf.org; Sat, 4 Mar 2000 14:10: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 ESMTP id OAA06876 for ; Sat, 4 Mar 2000 14:00:50 -0500 (EST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA81279; Sat, 4 Mar 2000 14:00:35 -0500 (EST) (envelope-from wollman) Date: Sat, 4 Mar 2000 14:00:35 -0500 (EST) From: Garrett Wollman Message-Id: <200003041900.OAA81279@khavrinen.lcs.mit.edu> To: RJ Atkinson Cc: Randall Gellens , ietf@ietf.org Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? In-Reply-To: <4.2.0.58.20000304093224.0098de90@avarice.inner.net> References: <200002150227.MAA27866@kuji.off.connect.com.au> <4.3.0.20000303182045.00e8f420@randy-nt4.qualcomm.com> <4.2.0.58.20000304093224.0098de90@avarice.inner.net> X-Loop: ietf@ietf.org < said: > By the way, FreeBSD, OpenBSD, and NetBSD all have device drivers for > the Lucent WaveLAN PCMCIA cards according to their respective web > sites. And thus also for other vendors' badge-engineered Lucent cards (e.g., Cabletron). -GAWollman (writing today as ) -- 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 Sat Mar 4 16:20:47 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA07961 for ietf-outbound.10@ietf.org; Sat, 4 Mar 2000 16:20:02 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07886 for ; Sat, 4 Mar 2000 16:11:52 -0500 (EST) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Sat, 4 Mar 2000 16:10:42 -0500 Received: from rftzy228.ca.nortel.com ([47.130.185.28]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GC0NQ35F; Sat, 4 Mar 2000 16:10:42 -0500 Received: from rftzy230.ca.nortel.com ([47.130.185.30]) by rftzy228.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id F60JGNML; Sat, 4 Mar 2000 16:10:41 -0500 Received: from nortelnetworks.com (47.221.35.48 [47.221.35.48]) by rftzy230.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1RN1NQPX; Sat, 4 Mar 2000 16:10:39 -0500 Sender: "Marcus Leech" Message-ID: <38C17B49.3E436AB@nortelnetworks.com> Date: Sat, 04 Mar 2000 16:08:25 -0500 From: "Marcus Leech" Organization: Nortel Networks, Information Systems X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf@ietf.org Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? References: <200003041809.SAA11701@orchard.arlington.ma.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 Bill Sommerfeld wrote: > > > I hope the 128 bit "gold" cards use a longer IV.. > > - Bill Does anyone know if the 128-bit variant of WEP is openly specified anywhere? With the spinoff of the Enterprise portion of Lucents business, will the 128-bit variant quietly die? I hope not (assuming that it's any good, of course). From owner-ietf-outbound Sat Mar 4 16:50:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA08198 for ietf-outbound.10@ietf.org; Sat, 4 Mar 2000 16:50:03 -0500 (EST) Received: from relay5.smtp.psi.net (relay5.smtp.psi.net [38.9.28.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08135 for ; Sat, 4 Mar 2000 16:40:52 -0500 (EST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay5.smtp.psi.net with smtp (Exim 1.90 #1) for ietf@ietf.org id 12RMI6-0004RR-00; Sat, 4 Mar 2000 16:40:50 -0500 Received: from agate.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA10428; Sat, 4 Mar 00 16:41:04 EST Received: from txc.com by agate.txc.com (SMI-8.6/SMI-SVR4) id QAA02793; Sat, 4 Mar 2000 16:42:35 -0500 Message-Id: <38C1845F.F354CC96@txc.com> Date: Sat, 04 Mar 2000 16:47:11 -0500 From: Harpreet Chohan X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: IETF Subject: IP mapping into SONET/SDH Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Does anybody know of any stds for direct IP mapping into a SONET/SDH payload (SPE) ? Thanks in advance. From owner-ietf-outbound Sun Mar 5 02:12:54 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA24287 for ietf-outbound.10@ietf.org; Sun, 5 Mar 2000 02:10:05 -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 ESMTP id CAA23411 for ; Sun, 5 Mar 2000 02:07:42 -0500 (EST) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.Gamma0/8.10.0.Gamma0) with ESMTP id e2577dw27202; Sun, 5 Mar 2000 02:07:39 -0500 Message-Id: <200003050707.e2577dw27202@black-ice.cc.vt.edu> To: RJ Atkinson cc: ietf@ietf.org Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? In-reply-to: Your message of "Sat, 04 Mar 2000 09:36:47 GMT." <4.2.0.58.20000304093224.0098de90@avarice.inner.net> From: Valdis.Kletnieks@vt.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[ <4.2.0.58.20000304093224.0098de90@avarice.inner.net> Date: Sun, 05 Mar 2000 02:07:39 -0500 Sender: valdis@black-ice.cc.vt.edu X-Loop: ietf@ietf.org On Sat, 04 Mar 2000 09:36:47 GMT, RJ Atkinson said: > The difference between Silver and Gold is the quality of the crypto supported, > by the way. In AU, it appears that Gold cards are available for sale only to financial > institutions or government-related institutions. Is there an issue with either (a) Australian nationals buying them offshore and importing them for their personal/company use or (b) non-Australian nationals bringing them with them for use while in the company? Or are they merely only being marketed to those two groups? Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Sun Mar 5 16:00:36 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA11281 for ietf-outbound.10@ietf.org; Sun, 5 Mar 2000 16:00: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 ESMTP id PAA11243 for ; Sun, 5 Mar 2000 15:54:46 -0500 (EST) Received: from localhost (ole@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA22303 for ; Sun, 5 Mar 2000 12:54:17 -0800 (PST) Date: Sun, 5 Mar 2000 12:54:16 -0800 (PST) From: "Ole J. Jacobsen" To: The IETF Subject: Plugging in Down Under Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org A surprising number of attendees of the Oslo IETF came without the proper power adapter plug. This is a reminder that Australia uses yet another style of plug. The blades are similar to the US or Japanese plug but set at an angle in an inverted "V" arrangement (with a third ground blade below the inverted V should you care). The official voltage is 240 at 50Hz, and they had the sense to adapt PAL as the TV standard, A4 paper and a semi-proper version of English :-) By popular demand, I will be bringing a number of "Purple Power Monsters" also know as Sascom Super adapters, that will let you plug into any power outlet in the world more or less, see: http://home.catv.ne.jp/dd/norihiro/benri/sasukomu/sasukomu.html ...but not enough for everyone. Thus, I'd suggest you get your adapter before getting on the plane for Australia. Yes, I am sure you can buy the adapter in Adelaide, but they may sell out like they did in Oslo. If you need to connect to telephone network, Australia has its own telephone connector too of course (although I suspect that major hotels may have the familar "data port" on the side of the phone). Most of what you need is available from online suppliers like Magellans and others. Have fun, and don't forget to bring back som Kangaroo Jerky for your friends. Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Cisco Systems, Office of the CTO Tel: +1 408-527-8972 e-mail: ole@cisco.com URL: http://www.cisco.com/ipj * See you at INET 2000, Yokohama, Japan July 18-21 http://www.isoc.org/inet2000 From owner-ietf-outbound Sun Mar 5 19:40:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA12637 for ietf-outbound.10@ietf.org; Sun, 5 Mar 2000 19:40:02 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12573 for ; Sun, 5 Mar 2000 19:32:16 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id QAA08438; Sun, 5 Mar 2000 16:32:10 -0800 (PST) From: Bill Manning Message-Id: <200003060032.QAA08438@boreas.isi.edu> Subject: Re: Plugging in Down Under To: ole@cisco.com (Ole J. Jacobsen) Date: Sun, 5 Mar 2000 16:32:10 -0800 (PST) Cc: ietf@ietf.org (The IETF) In-Reply-To: from "Ole J. Jacobsen" at Mar 05, 2000 12:54:16 PM X-Mailer: ELM [version 2.5 PL2] 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 % % If you need to connect to telephone network, Australia has its own % telephone connector too of course (although I suspect that major hotels % may have the familar "data port" on the side of the phone). is it the goofy british plug they use in HongKong? flipped pairs like hongkong? --bill From owner-ietf-outbound Sun Mar 5 20:00:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA12791 for ietf-outbound.10@ietf.org; Sun, 5 Mar 2000 20:00:01 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12738 for ; Sun, 5 Mar 2000 19:50:57 -0500 (EST) Received: from localhost (ole@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id QAA18722; Sun, 5 Mar 2000 16:49:58 -0800 (PST) Date: Sun, 5 Mar 2000 16:49:58 -0800 (PST) From: "Ole J. Jacobsen" To: Bill Manning cc: The IETF Subject: Re: Plugging in Down Under In-Reply-To: <200003060032.QAA08438@boreas.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org I don't think so. *If* there is a "dataport" it should be vanilla RJ-11, but I would strongly recommend getting a native phoneplug/adapter in any case. ole On Sun, 5 Mar 2000, Bill Manning wrote: > % > % If you need to connect to telephone network, Australia has its own > % telephone connector too of course (although I suspect that major hotels > % may have the familar "data port" on the side of the phone). > > > is it the goofy british plug they use in HongKong? > flipped pairs like hongkong? > > --bill > > From owner-ietf-outbound Sun Mar 5 20:20:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA13021 for ietf-outbound.10@ietf.org; Sun, 5 Mar 2000 20:20:02 -0500 (EST) Received: from A4.JCK.COM (ns.jck.com [63.65.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12945 for ; Sun, 5 Mar 2000 20:10:54 -0500 (EST) Received: from p2.jck.com ("port 1324"@[63.65.7.138]) by a4.jck.com (PMDF V6.0-20 #40360) with ESMTP id <0FQZ00A2C7AQ6Y@a4.jck.com> for ietf@ietf.org; Sun, 05 Mar 2000 20:11:15 -0500 (EST) Date: Sun, 05 Mar 2000 20:10:54 -0500 From: John C Klensin Subject: Re: Plugging in Down Under In-reply-to: <200003060032.QAA08438@boreas.isi.edu> To: Bill Manning Cc: The IETF Message-id: <3099281864.952287054@p2.jck.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b11 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit --On Sunday, 05 March, 2000 16:32 -0800 Bill Manning wrote: > % > % If you need to connect to telephone network, Australia has > its own % telephone connector too of course (although I > suspect that major hotels % may have the familar "data port" > on the side of the phone). > > > is it the goofy british plug they use in HongKong? > flipped pairs like hongkong? Think about two parallel flat pins, then a square-ish rod, then another flat pin, also with its surface parallel to the others. i.e., something like _ | | |_| | and, no, not like the British or Hong Kong ones. john From owner-ietf-outbound Sun Mar 5 20:30:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA13182 for ietf-outbound.10@ietf.org; Sun, 5 Mar 2000 20:30:03 -0500 (EST) Received: from koestler.holon.net (root@koestler.holon.net [150.101.93.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13091 for ; Sun, 5 Mar 2000 20:22:57 -0500 (EST) Received: (from mafarrin@localhost) by koestler.holon.net (8.9.3/8.9.3) id LAA22581 for ietf@ietf.org; Mon, 6 Mar 2000 11:52:55 +1030 Message-Id: <200003060122.LAA22581@koestler.holon.net> Subject: Re: Plugging in Down Under To: ietf@ietf.org Date: Mon, 6 Mar 2000 11:52:55 +1030 (CST) In-Reply-To: <200003060032.QAA08438@boreas.isi.edu> from "Bill Manning" at Mar 05, 2000 04:32:10 PM Sender: mat@foursticks.com From: mat@foursticks.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 > % If you need to connect to telephone network, Australia has its own > % telephone connector too of course (although I suspect that major hotels > % may have the familar "data port" on the side of the phone). > > is it the goofy british plug they use in HongKong? > flipped pairs like hongkong? Checkout the adaptor products on page 14 of the online catalogue at http://www.dse.com.au/ . Regards, Mat F. From owner-ietf-outbound Sun Mar 5 20:40:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA13358 for ietf-outbound.10@ietf.org; Sun, 5 Mar 2000 20:40:03 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13116 for ; Sun, 5 Mar 2000 20:23:35 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12RmE1-00013Z-00; Sun, 05 Mar 2000 17:22:21 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Manning Cc: ole@cisco.com (Ole J. Jacobsen), ietf@ietf.org (The IETF) Subject: Re: Plugging in Down Under References: <200003060032.QAA08438@boreas.isi.edu> Message-Id: Date: Sun, 05 Mar 2000 17:22:21 -0800 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > is it the goofy british plug they use in HongKong? > flipped pairs like hongkong? no. it is unique From owner-ietf-outbound Sun Mar 5 22:20:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA14919 for ietf-outbound.10@ietf.org; Sun, 5 Mar 2000 22:20:01 -0500 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14841 for ; Sun, 5 Mar 2000 22:11:45 -0500 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id NAA24497 for ; Mon, 6 Mar 2000 13:11:41 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma024489; Mon, 6 Mar 00 13:11:30 +1000 Received: from julubu.staff.apnic.net (julubu.staff.apnic.net [192.168.1.37]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with ESMTP id NAA07032 for ; Mon, 6 Mar 2000 13:11:26 +1000 (EST) Date: Mon, 6 Mar 2000 13:11:31 +1000 (EST) From: Bruce Campbell X-Sender: bc@julubu.staff.apnic.net To: The IETF Subject: Re: Plugging in Down Under In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Sun, 5 Mar 2000, Randy Bush wrote: randy> > is it the goofy british plug they use in HongKong? randy> > flipped pairs like hongkong? randy> no. it is unique The native Australian phone plug, just like the Fauna and Flora, is like nothing else on earth ;) . I've yet to see an Australian hotel (IETF class[1]) without the RJ-11 socket, with standard pinouts. In most cases, this is all that you will need. Failing that, Australian phone adaptors can be purchased either from Duty-Free as you enter the country, or the local DSE store (Dick Smith Electronics). If you are transitting via Japan or ( *insert name of city which has decent electronic goods* ), step down transformers from anything[2] to 110V can be purchased for approx 4,500 Yen (40 USD or similar), quite possibly the same item which Ole mentioned previously. (personally I just buy equipment that can deal with any voltage ;) ) If you were at APRICOT in the last week, you will be relived to hear that Adelaide will not have the same static electricity problem. --==-- Bruce. Sysadmin, APNIC Brisbane, Australia. [1] The type of hotel able to deal with the jetlagged international traveller just wanting to check their email at 3am local time. [2] 'anything' temporarily redefined to be the range 110V to 250V. From owner-ietf-outbound Mon Mar 6 07:52:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA03518 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 07:50:02 -0500 (EST) Received: from smtp.jet.es (smtp.jet.es [194.179.100.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03469 for ; Mon, 6 Mar 2000 07:48:29 -0500 (EST) Received: from jet.es (info129.jet.es [194.224.180.129]) by smtp.jet.es (8.9.3/8.9.1) with ESMTP id NAA01087 for ; Mon, 6 Mar 2000 13:47:53 +0100 (MET) X-Envelope-To: Message-ID: <38C3A7C4.48E8E6E6@jet.es> Date: Mon, 06 Mar 2000 13:42:44 +0100 From: Julio =?iso-8859-1?Q?C=E9sar?= Serrano Ortuno X-Mailer: Mozilla 4.5 [es] (Win98; I) X-Accept-Language: es MIME-Version: 1.0 To: ietf@ietf.org Subject: OFF-TOPIC: Avoid ping response 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 everyone, I'm trying to avoid the "pongs" that follows a ping request. Where can I find some detailed information. Note: When you try ping www.microsoft.com there is no answer. How to do so? Thanks! From owner-ietf-outbound Mon Mar 6 08:00:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA03666 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 08:00:02 -0500 (EST) Received: from kuji.off.connect.com.au (kuji.off.connect.com.au [203.63.69.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03631 for ; Mon, 6 Mar 2000 07:58:52 -0500 (EST) Received: from connect.com.au (mrp@localhost) by kuji.off.connect.com.au with ESMTP id XAA27534 (8.8.8/IDA-1.6); Mon, 6 Mar 2000 23:27:39 +1030 (CST) Message-ID: <200003061257.XAA27534@kuji.off.connect.com.au> To: Bill Manning cc: ole@cisco.com (Ole J. Jacobsen), ietf@ietf.org (The IETF) Subject: Re: Plugging in Down Under In-reply-to: Your message of "Sun, 05 Mar 2000 16:32:10 -0800." <200003060032.QAA08438@boreas.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27532.952347458.1@connect.com.au> Date: Mon, 06 Mar 2000 23:27:38 +1030 From: Mark Prior X-Loop: ietf@ietf.org % If you need to connect to telephone network, Australia has its own % telephone connector too of course (although I suspect that major hotels % may have the familar "data port" on the side of the phone). is it the goofy british plug they use in HongKong? flipped pairs like hongkong? I doubt it, I think it was something weird that Telstra dreamt up during its monology years :-) Most hotels should have RJ12's but you can readily buy the adaptor if you find you need it as a lot of new equipment has an RJ instead of the standard plug. Mark. From owner-ietf-outbound Mon Mar 6 11:30:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA13277 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 11:30:03 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13134 for ; Mon, 6 Mar 2000 11:26:22 -0500 (EST) Received: from cisco.com (sj-dial-4-108.cisco.com [171.68.181.237]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id IAA13633; Mon, 6 Mar 2000 08:25:51 -0800 (PST) Message-ID: <38C3DC0E.31D93F1C@cisco.com> Date: Mon, 06 Mar 2000 11:25:50 -0500 From: Albert Herrera Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf.org" CC: Thomas Narten Subject: New Mailing List for Discussing IPoPTR Content-Type: multipart/alternative; boundary="------------68978174F8E9E503BD7A9AAA" X-Loop: ietf@ietf.org --------------68978174F8E9E503BD7A9AAA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A new mailing list is now available to discuss the formation of a WG specifically addressing IP awareness within Packet Transport Rings. This is to enable tighter routing and forwarding controls between L2 and L3 features within these rings. The new mailing list for IPoPTR (IP over Packet Transport Rings) is ptrings@cisco.com. To subscribe, send an email to ptrings-request@cisco.com with 'subscribe ptrings' in the body and subject of the message. The initial goal within this list is to discuss/craft a charter for IPoPTR and to gauge interest with the intent to have a BOF or a WG in the Pittsburg timeframe. The following is a first-cut at a possible charter for a WG in this space. ***NOTE*** that this is not yet a WG but the hope is that we will become one. ------------------------------------------------------------- Proposed IPOPTR Working Group Charter Working Group Name: IP over Packet Transport Rings (IPOPTR) IETF Area: Internet Area Chair(s): A. Herrera Other Internet Area Director(s): Thomas Narten Erik Nordmark Responsible Area Director: Thomas Narten General Discussion:ptrings@cisco.com To Subscribe: ptrings-request@cisco.com (include 'subscribe ptrings' in the body and subject of message) Archive: TBD Description of Working Group: Over the past few years, enhancements to traditional bi-directional ring topologies were defined providing tremendous benefits for both packet and cell-based flows. When compared to traditional SONET BLSR or FDDI rings, Packet Transport Rings provide: * Full utilization of both (bi-directional, counter-rotating)rings for data and control packets * Destination stripping of unicast traffic for bandwidth gains on other ring spans * Protection switching by wrapping traffic around failures with rapid recovery patterned after SONET rings * Distributed ring bandwidth fairness algorithms that combine global fairness with local optimization * Media independence, capable of packet and cell transport across traditional SONET, DWDM or dark fibre infrastructures or a combination of all within the same ring. Functions currently defined (as well as those currently under development within the IEEE), primarily address MAC layer foundations. The purpose of this effort is to standardize specifications that will allow upper layer (IP) awareness within these Packet Transport Rings for tighter routing and forwarding control as well as more efficient interworking of other features. Objectives: The IPOPTR WG plans to deliver IPOPTR Specifications which will address the following areas: * Traffic Priority Mapping * Interactions between the rings and L3 routing protocols (including Ring Direction Choice, weights assignments to spans, possible IGP enhancements etc.) * MPLS TE over Packet Transport Rings This WG will also be the official focus and liaison group to other standards bodies that are currently developing specifications for PTRs. This allows for a smooth interaction and exchange within parallel development processes that can only benefit all standards bodies involved. --- end of proposed charter --------------------------------- --------------68978174F8E9E503BD7A9AAA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit A new mailing list is now available to discuss the formation
of a WG specifically addressing IP awareness within Packet
Transport Rings. This is to enable tighter routing and forwarding
controls between L2 and L3 features within these rings.

The new mailing list for IPoPTR (IP over Packet Transport Rings)
is ptrings@cisco.com. To subscribe, send an email to
ptrings-request@cisco.com with 'subscribe ptrings' in the body
and subject of the message.

The initial goal within this list is to discuss/craft a charter
for IPoPTR and to gauge interest with the intent to have a BOF
or a WG in the Pittsburg timeframe.

The following is a first-cut at a possible charter for a WG
in this space. ***NOTE*** that this is not yet a WG but the hope
is that we will become one.

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

Proposed IPOPTR Working Group Charter

Working Group Name:
IP over Packet Transport Rings (IPOPTR)

IETF Area:
Internet Area

Chair(s):
A. Herrera <albherre@cisco.com>
Other <TBD>

Internet Area Director(s):
Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Responsible Area Director:
Thomas Narten <narten@raleigh.ibm.com>

General Discussion:ptrings@cisco.com
To Subscribe: ptrings-request@cisco.com
   (include 'subscribe ptrings'
    in the body and subject of message)
 
Archive: TBD

Description of Working Group:

Over the past few years, enhancements to traditional
bi-directional ring topologies were defined providing
tremendous benefits for both packet and cell-based flows.

When compared to traditional SONET BLSR or FDDI rings,
Packet Transport Rings provide:

*  Full utilization of both (bi-directional,
   counter-rotating)rings for data and control packets
*  Destination stripping of unicast traffic for bandwidth
   gains on other ring spans
*  Protection switching by wrapping traffic around
   failures with rapid recovery patterned after SONET rings
*  Distributed ring bandwidth fairness algorithms that combine
   global fairness with local optimization
*  Media independence, capable of packet and cell transport
   across traditional SONET, DWDM or dark fibre infrastructures
   or a combination of all within the same ring.

Functions currently defined (as well as those currently
under development within the IEEE), primarily address
MAC layer foundations.

The purpose of this effort is to standardize specifications
that will allow upper layer (IP) awareness within these
Packet Transport Rings for tighter routing and forwarding control
as well as more efficient interworking of other features.

Objectives:

The IPOPTR WG plans to deliver IPOPTR Specifications
which will address the following areas:

*  Traffic Priority Mapping
*  Interactions between the rings and L3 routing protocols
   (including Ring Direction Choice, weights assignments
   to spans, possible IGP enhancements etc.)
*  MPLS TE over Packet Transport Rings

This WG will also be the official focus and liaison group to
other standards bodies that are currently developing
specifications for PTRs. This allows for a smooth interaction
and exchange within parallel development processes that can
only benefit all standards bodies involved.

--- end of proposed charter ---------------------------------
 
 
  --------------68978174F8E9E503BD7A9AAA-- From owner-ietf-outbound Mon Mar 6 11:50:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA14181 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 11:50:03 -0500 (EST) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13831 for ; Mon, 6 Mar 2000 11:41:38 -0500 (EST) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id IAA12992; Mon, 6 Mar 2000 08:41:34 -0800 (PST) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Mon, 6 Mar 2000 08:41:33 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell16.ba.best.com To: Harpreet Chohan cc: IETF Subject: Re: IP mapping into SONET/SDH In-Reply-To: 38C1845F.F354CC96@txc.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Sat, 4 Mar 2000, Harpreet Chohan wrote: > Does anybody know of any stds for direct IP mapping into a SONET/SDH > payload (SPE) ? Thanks in advance. That question probably should be addressed to T1X1.5, which is the ANSI-accredited subcommittee with the charter to define SONET payload mappings. As far as I am aware, there is nothing currently standardized nor any ongoing work regarding a direct mapping of IP. I believe that the closest thing now standardized is the HDLC-over-SONET mapping that is used for PPP over SONET (see RFC 2615) and frame relay over SONET. There was some recent work on defining an Ethernet-over-SONET mapping, but I don't know its status. For further information check the T1X1.5 file archive on the committee T1 web site at http://www.t1.org/. Mike From owner-ietf-outbound Mon Mar 6 15:30:36 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA25913 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 15:30:02 -0500 (EST) Received: from dev01.i-dns.com ([203.116.224.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24754 for ; Mon, 6 Mar 2000 15:21:39 -0500 (EST) Received: from pobox.org.sg ([212.103.165.44]) by dev01.i-dns.com (8.9.3/8.9.3) with ESMTP id UAA06239; Mon, 6 Mar 2000 20:20:58 GMT Message-ID: <38C412DD.E044EB70@pobox.org.sg> Date: Tue, 07 Mar 2000 04:19:41 +0800 From: James Seng X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,zh,zh-TW,zh-CN MIME-Version: 1.0 To: Bill Manning CC: "Ole J. Jacobsen" , The IETF Subject: Re: Plugging in Down Under References: <200003060032.QAA08438@boreas.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: > > % > % If you need to connect to telephone network, Australia has its own > % telephone connector too of course (although I suspect that major hotels > % may have the familar "data port" on the side of the phone). > > is it the goofy british plug they use in HongKong? > flipped pairs like hongkong? no..worst, it is neither :) imaging your US plug without the grounding. Then imaging someone with a twisted mind bending them to each side at 30degree giving you a sort of a V shape. This probably means you _can_ try bending your plug to fit oz power :))) but i wouldnt recommend anyone to do so... james From owner-ietf-outbound Mon Mar 6 17:10:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA11416 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 17:10:02 -0500 (EST) Received: from inetco.com (strauss.inetco.com [207.102.246.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08878 for ; Mon, 6 Mar 2000 16:58:08 -0500 (EST) Received: from dixon.inetco.com ([192.168.168.56]) by strauss.inetco.com with ESMTP id <115203>; Mon, 6 Mar 2000 13:59:00 -0800 Received: by dixon.inetco.com with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Mar 2000 13:59:19 -0800 Message-ID: <72AC01E5ABECD311A1BD0080C8E3273F06D837@dixon.inetco.com> From: Cameron Young To: The IETF Subject: Switches on Oz power outlets Date: Mon, 6 Mar 2000 13:59:18 -0800 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 Most of the wall power outlets have little rocker switches built into the outlet cover that also needs to be turned on. *Don't* forget to check this if you are charging a cell phone / laptop for use the next day. Hotel staff have a habit of turning all these switches off whenever they clean a room. Cam From owner-ietf-outbound Mon Mar 6 18:00:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA21833 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 18:00:02 -0500 (EST) Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21327 for ; Mon, 6 Mar 2000 17:57:39 -0500 (EST) Received: from ross ([207.82.79.207]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id OAA12773 for ; Mon, 6 Mar 2000 14:56:51 -0800 (PST) Message-Id: <3.0.6.32.20000306145515.00949200@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 06 Mar 2000 14:55:15 -0800 To: The IETF From: Ross Finlayson Subject: Re: Switches on Oz power outlets In-Reply-To: <72AC01E5ABECD311A1BD0080C8E3273F06D837@dixon.inetco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 01:59 PM 3/6/00 -0800, Cameron Young wrote: >Most of the wall power outlets have little rocker switches built into the >outlet cover that also needs to be turned on. > >*Don't* forget to check this if you are charging a cell phone / laptop for >use the next day. Hotel staff have a habit of turning all these switches >off whenever they clean a room. Also, don't forget that on wall switches (like almost every country in with world except the US :-) "down" means "on". Ross. From owner-ietf-outbound Mon Mar 6 19:00:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA01805 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 19:00:02 -0500 (EST) Received: from peridot.cisco.com (peridot.cisco.com [171.69.198.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01739 for ; Mon, 6 Mar 2000 18:59:47 -0500 (EST) Received: from cisco.com (dhcp-171-69-44-215.cisco.com [171.69.44.215]) by peridot.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA03806; Mon, 6 Mar 2000 15:58:48 -0800 (PST) Message-ID: <38C445EE.3F9124D2@cisco.com> Date: Mon, 06 Mar 2000 15:57:34 -0800 From: Peter Deutsch Reply-To: pdeutsch@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ross Finlayson CC: The IETF Subject: Re: Switches on Oz power outlets References: <3.0.6.32.20000306145515.00949200@shell7.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 Ross Finlayson wrote: > > At 01:59 PM 3/6/00 -0800, Cameron Young wrote: > >Most of the wall power outlets have little rocker switches built into the > >outlet cover that also needs to be turned on. > > > >*Don't* forget to check this if you are charging a cell phone / laptop for > >use the next day. Hotel staff have a habit of turning all these switches > >off whenever they clean a room. > > Also, don't forget that on wall switches (like almost every country in with > world except the US :-) "down" means "on". Well, if you pronounce "U.S." as "United States and Canada, except for parts of my house in Montreal". As I renovated, I made a point of going through and installing the switches the "right" way up (drove my Canadian spouse crazy at the time, but she got used to it! :-) Of course, now I'm selling the place, the agent seems to think I should switch them all back... - peterd From owner-ietf-outbound Mon Mar 6 21:30:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA28835 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 21: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 ESMTP id VAA27871 for ; Mon, 6 Mar 2000 21:24:34 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id 2A2901E004F; Mon, 6 Mar 2000 21:24:36 -0500 (EST) To: Ross Finlayson Cc: The IETF Subject: Re: Switches on Oz power outlets References: <3.0.6.32.20000306145515.00949200@shell7.ba.best.com> From: "Perry E. Metzger" Date: 06 Mar 2000 21:24:35 -0500 In-Reply-To: Ross Finlayson's message of "Mon, 06 Mar 2000 14:55:15 -0800" Message-ID: <871z5nbjq4.fsf@snark.piermont.com> Lines: 11 X-Mailer: Gnus v5.5/Emacs 20.3 X-Loop: ietf@ietf.org Ross Finlayson writes: > Also, don't forget that on wall switches (like almost every country in with > world except the US :-) "down" means "on". Places where people use SNMP for turning their lights on and off have left this issue far behind. Do you mean to tell me that Australians don't all use SNMP for light control yet? .pm From owner-ietf-outbound Mon Mar 6 22:10:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA08361 for ietf-outbound.10@ietf.org; Mon, 6 Mar 2000 22:10: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 ESMTP id WAA08195 for ; Mon, 6 Mar 2000 22:09:24 -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 C22C14CE15; Mon, 6 Mar 2000 22:09:21 -0500 (EST) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id WAA06261; Mon, 6 Mar 2000 22:09:21 -0500 (EST) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 2B9B141F16; Mon, 6 Mar 2000 22:09:21 -0500 (EST) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 1C865400B5; Mon, 6 Mar 2000 22:09:16 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "Perry E. Metzger" Cc: Ross Finlayson , The IETF Subject: Re: Switches on Oz power outlets Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Mar 2000 22:09:16 -0500 Sender: smb@research.att.com Message-Id: <20000307030921.2B9B141F16@SIGABA.research.att.com> X-Loop: ietf@ietf.org In message <871z5nbjq4.fsf@snark.piermont.com>, "Perry E. Metzger" writes: > > Ross Finlayson writes: > > Also, don't forget that on wall switches (like almost every country in with > > world except the US :-) "down" means "on". > > Places where people use SNMP for turning their lights on and off have > left this issue far behind. Do you mean to tell me that Australians > don't all use SNMP for light control yet? > It's a security issue -- they've been waiting for SNMPv3 security to go to full standard. Right now, it's only draft. --Steve Bellovin From owner-ietf-outbound Tue Mar 7 13:32:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA25606 for ietf-outbound.10@ietf.org; Tue, 7 Mar 2000 13:30:04 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24466 for ; Tue, 7 Mar 2000 13:23:50 -0500 (EST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA15020 for ; Tue, 7 Mar 2000 13:23:48 -0500 (EST) Received: from co7010exch001h.wins.lucent.com (h135-39-163-75.lucent.com [135.39.163.75]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA14939 for ; Tue, 7 Mar 2000 13:23:47 -0500 (EST) Received: by CO7010EXCH001H with Internet Mail Service (5.5.2448.0) id ; Tue, 7 Mar 2000 11:23:46 -0700 Message-ID: From: "Pan, Henry (Henry)** CTR **" To: "'Hanan Lutfiyya'" , *ifip-emailmgt@ics.uci.edu, agentx@zloty.fv.com, aow-nmsig@stc.ipa.go.jp, applmib-request@emi-summit.com, arslist@yorku.ca, atm@tango.cos.com, aya@arc.bs1.fc.nec.co.jp, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comp.protocols.iso@bbn.com, comsoc-conferences@IEEE.ORG, comsoc-gicb@IEEE.ORG, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, conferences@iao.fhg.de, corpcom@OSF.ORG, ctc-members@redbank.tinac.com, disman@nexen.com, dsm@nemo.ncsl.nist.gov, end2end-interest@isi.edu, enternet@bbn.com, ewos-egnm@extend.iihe.ac.be, gateway@nmf.org, hnms-users@ghost.CS.ORST.EDU, hp-nodemgr@rrz.uni-koeln.de, hubmib@rosemail.rose.hp.com, ieee.announce@bbn.com, ietf-madman@innosoft.com, ietf@ietf.org, ietf@venera.isi.edu, ifip-nm@bbn.com, iimc@thumper.bellcore.com, im97-oc@ctr.columbia.edu, im97-pc@ctr.columbia.edu, intap-aow-nm@sy.isl.melco.co.jp, yemini@cs.columbia.edu, yjy2368@chollian.dacom.co.kr, yogeshg@cai.com, yosimura@ccrle.nec.de, yun@std.trd.tmg.nec.co.jp, yzheng1@scudc.scu.edu, zhen.huang@attws.com, zhu@tri.sbc.com, zimmer@first.gmd.de, zuwei.liu@nd.edu, zwickerd@nbnet.nb.ca Cc: "'.Henry PAN @ Sun'" , "'.Henry PAN @ us'" , "'.Mary SUN s'" Subject: RE: 4th IEEE International Workshop on Systems Management Date: Tue, 7 Mar 2000 11:23:35 -0700 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 This is the 2nd Email ! -----Original Message----- From: Hanan Lutfiyya [mailto:hanan@csd.uwo.ca] Sent: Friday, March 03, 2000 4:04 PM To: *ifip-emailmgt@ics.uci.edu; agentx@zloty.fv.com; aow-nmsig@stc.ipa.go.jp; applmib-request@emi-summit.com; arslist@yorku.ca; atm@tango.cos.com; aya@arc.bs1.fc.nec.co.jp; cnom@maestro.bellcore.com; commsoft@cc.bellcore.com; comp.protocols.iso@bbn.com; comsoc-conferences@ieee.org; comsoc-gicb@ieee.org; comsoc.bog@tab.ieee.org; comsoc.tac@tab.ieee.org; comswtc@gmu.edu; conferences@iao.fhg.de; corpcom@osf.org; ctc-members@redbank.tinac.com; disman@nexen.com; dsm@nemo.ncsl.nist.gov; end2end-interest@isi.edu; enternet@bbn.com; ewos-egnm@extend.iihe.ac.be; gateway@nmf.org; hnms-users@ghost.CS.ORST.EDU; hp-nodemgr@rrz.uni-koeln.de; hubmib@rosemail.rose.hp.com; ieee.announce@bbn.com; ietf-madman@innosoft.com; ietf@ietf.org; ietf@venera.isi.edu; ifip-nm@bbn.com; iimc@thumper.bellcore.com; im97-oc@ctr.columbia.edu; im97-pc@ctr.columbia.edu; intap-aow-nm@sy.isl.melco.co.jp; yemini@cs.columbia.edu; yjy2368@chollian.dacom.co.kr; yogeshg@cai.com; yosimura@ccrle.nec.de; yun@std.trd.tmg.nec.co.jp; yzheng1@scudc.scu.edu; zhen.huang@attws.com; zhu@tri.sbc.com; zimmer@first.gmd.de; zuwei.liu@nd.edu; zwickerd@nbnet.nb.ca Subject: 4th IEEE International Workshop on Systems Management Call for Papers ------------------------------------------------------------------------- We apologize if you receive this message more than once. ------------------------------------------------------------------------ This represents a change of dates due to e-mail distribution problems. ***New date for submissions is April 3, 2000*** IEEE 4th International Workshop on Systems Management (Theme: Exploitation of Data Mining and Visualization Age) Montreal Quebec, Canada June 28-30, 2000 This workshop is the fourth in a series of highly successful forums for the discussion of research in the area of systems management. Previous workshops have been held in Los Angeles, California, Toronto, Ontario, and Newport, RI. This year the scope of this workshop is mining, visualization, management, and acquisition of data for network and systems management. With the widespread adoption of standards for data collection (e.g., SNMP in data networks CMIP in telecommunications networks) and the growing acceptance of technologies for information modeling (e.g., UML, XML, and CIM), the next challenge for network and systems management is interpreting the data. These interpretations should be task oriented, such as for problem detection, problem diagnosis, and planning. The purpose of this workshop is to bring together researchers with in-depth knowledge of data interpretation and presentation to focus on challenges of network and systems management. These challenges include: heterogeneous data semantics, dealing with large data volumes, noisely data, high dimensional data, dearth of labelled data for supervised learning, and the exploitation of underlying structure (e.g., based on network topologies). To aid in our objective, several data sets will be provided in advance of the workshop, along with some background about the kinds of information that should be extracted. Workshop participants are encouraged to submit papers (or extended abstracts) that apply their techniques to these data. The URL for our site is http://www.csd.uwo.ca/SMW4. WORKSHOP FORMAT --------------- Three kinds of participation are possible. The first are presenters of full papers that fall within the topic areas considered by this workshop. The second are those who report on the results of mining and/or visualizing network and systems management data made available for this workshop, which can be found under Dataset Information at http://www.csd.uwo.ca/SMW4/. This data has been provided by Cooperative Association for Internet Data Analysis (CAIDA). Also encouraged is participation by individuals seeking information on recent advances in the application of data mining and visualization to network and systems management. An award will be presented to the best paper that provides the best insight into the analysis (visualisation or patterns) of the skitter data (please see "Dataset Information" at http://www.csd.uwo.ca/SMW4/). CALL FOR PARTICIPATION ---------------------- All submitted papers will be reviewed by experts in the area of submission. Individuals presenting the results of analyses of the data sets provided by this workshop should submit an extended abstract summarizing their methodology and results. All accepted contributions (including extended abstracts) will be eligible for publication in the bound proceedings of the workshop. At least one of the authors of each paper must register for the workshop to present the paper. Papers are to be submitted in English. The cover page should include paper title, author(s) full name, affiliations, complete address(es), telephone number(s), and electronic mail address(es). Full-length papers should have a brief abstract and be no longer than 12 pages (6,000 words), including references and figures. Extended abstracts should be in the format of an extended abstract that is no longer than 2 pages (1,000 words), excluding figures. Proposals for panel discussions are also solicited. Panels are scheduled for 1.5 hours. Proposals should specify the topic, panel chair, and participants. Please include a two page abstract that highlights key points for discussion and areas of controversy that will be addressed. SUBMISSION ---------- All submissions should be sent by email in postscript or pdf form to smw4@csd.uwo.ca with the subject line "SMW4 Paper Submission: ," where indicates the compression used if any (e.g., paper.ps.gz). If electronic submission is not possible, please submit 4 paper copies to the following address: Professor Hanan Lutfiyya Department of Computer Science The University of Western Ontario London, Ontario CANADA N6A 5B7 TOPICS ------ Application of data mining algorithms to network and systems management Scalable and effective visualizations for management tasks Efficient techniques for on-line pattern recognition (e.g., for detecting performance problems and security intrusions) Scalable architectures for distributed data mining and visualization Case studies of data mining and visualization in systems and network management Agent technologies for building distributed mining and visualization applications Information models that aid in mining and visualizing network systems management data IMPORTANT DATES --------------- Papers, panels, and extended abstracts due: April 3, 2000 Author notification: April 21, 2000 Camera ready copy: May 10, 2000 ORGANIZING COMMITTEE -------------------- GENERAL CHAIR Hanan Lutfiyya Department of Computer Science The University of Western Ontario hanan@csd.uwo.ca VICE CHAIRS: Paul J. Brusil SMD 35 Brackenbury Lane Beverly, Massachusetts, USA 01915-3821 brusil@snad.ncsl.nist.gov Joseph L. Hellerstein IBM Thomas J. Watson Research Center Hawthorne, New York, USA hellers@us.ibm.com From owner-ietf-outbound Tue Mar 7 22:10:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA01386 for ietf-outbound.10@ietf.org; Tue, 7 Mar 2000 22:10:02 -0500 (EST) Received: from smtp.263.net ([202.96.44.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29969 for ; Tue, 7 Mar 2000 22:03:29 -0500 (EST) Received: from 263.net (unknown [202.112.109.83]) by smtp.263.net (Postfix) with ESMTP id 094A61C563BC9; Tue, 7 Mar 2000 18:23:11 +0800 (CST) Message-ID: <38C4D898.6DDC2C99@263.net> Date: Tue, 07 Mar 2000 18:23:20 +0800 From: jinglin X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: loa.andersson@nortelnetworks.com, rhthomas@cisco.com, ietf@ietf.org Subject: about address A1 ad A2 problem in LDP of 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 I cannot understand the meaning of the words:" 2. LSR1 determines whether it will play the active or passive role in session establishment by comparing addresses A1 and A2 as Andersson, et al. [Page 14] Internet Draft draft-ietf-mpls-ldp-06.txt October 1999 unsigned integers. If A1 > A2, LSR1 plays the active role; otherwise it is passive. " I want to know what kind of address of A1&A2, IP address or TCP port No.? why the role is determined by the size of A1 &A2? thanks. jinglin From owner-ietf-outbound Wed Mar 8 01:50:40 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA04282 for ietf-outbound.10@ietf.org; Wed, 8 Mar 2000 01:50:04 -0500 (EST) Received: from latte.2xtreme.net (latte.2xtreme.net [209.63.222.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02879 for ; Wed, 8 Mar 2000 01:46:30 -0500 (EST) Received: (qmail 14974 invoked from network); 8 Mar 2000 06:57:07 -0000 Received: from p85.oak2.2xtreme.net (HELO 2xtreme.net) (209.63.215.85) by latte.2xtreme.net with SMTP; 8 Mar 2000 06:57:07 -0000 Message-ID: <38C5F86F.CF5B15DF@2xtreme.net> Date: Tue, 07 Mar 2000 22:51:27 -0800 From: Dau Do X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf Subject: MPG & WCDMA format ? 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, Does anyone know where to get the MPG and WCDMA specification ? I am looking for the MPG and WCDMA frame format. Thank you Dau Do From owner-ietf-outbound Wed Mar 8 11:10:38 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA03754 for ietf-outbound.10@ietf.org; Wed, 8 Mar 2000 11:10:02 -0500 (EST) Received: from public6.sta.net.cn (public6.sta.net.cn [202.96.199.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01185 for ; Wed, 8 Mar 2000 11:02:07 -0500 (EST) Received: from jammy-huang (max-p4-36.sta.net.cn [202.96.243.228]) by public6.sta.net.cn (8.9.1a/8.9.1) with ESMTP id AAA22017 for ; Thu, 9 Mar 2000 00:01:54 +0800 (CST) Message-Id: <4.2.0.58.20000308223129.00968ba0@pop.mail.yahoo.com> X-Sender: jbhuang@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Mar 2000 22:57:35 +0800 To: ietf@ietf.org From: Jianbo Huang Subject: Critically compare the congestion control on TCP/IP and ATM? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Dear Sirs and Madams, A friend of mine are working on the paper on "critically compare the congestion control on TCP/IP and ATM", and she ask me for help. But I do not get much idea on the "congestion control on ATM". So, is there anyone can give me any idea on this topic, while my friend and I processing on this? Thank you! rgds, Sincerely yours, Jianbo Huang From owner-ietf-outbound Wed Mar 8 14:50:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA14733 for ietf-outbound.10@ietf.org; Wed, 8 Mar 2000 14:50:04 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13543 for ; Wed, 8 Mar 2000 14:47:00 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id LAA13157; Wed, 8 Mar 2000 11:39:49 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 8 Mar 2000 19:46:14 UT Received: from spud.ascend.com (spud [192.207.23.51]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id LAA09037; Wed, 8 Mar 2000 11:46:13 -0800 (PST) Received: from malisa2 ([152.148.90.98]) by spud.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id LAA28393; Wed, 8 Mar 2000 11:46:13 -0800 (PST) Message-Id: <4.2.2.20000308144012.01a76100@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Mar 2000 14:42:18 -0500 To: Jianbo Huang From: "Andrew G. Malis" Subject: Re: Critically compare the congestion control on TCP/IP and ATM? Cc: ietf@ietf.org In-Reply-To: <4.2.0.58.20000308223129.00968ba0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Jianbo, See ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0121.000.pdf, especially section 5. Regards, Andy ------- At 10:57 PM 3/8/00 +0800, Jianbo Huang wrote: >Dear Sirs and Madams, > >A friend of mine are working on the paper on "critically compare the >congestion control on TCP/IP and ATM", and she ask me for help. But I do >not get much idea on the "congestion control on ATM". So, is there anyone >can give me any idea on this topic, while my friend and I processing on >this? Thank you! > >rgds, > >Sincerely yours, >Jianbo Huang >- >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. ________________________________________________________________________ Andrew G. Malis amalis@lucent.com phone:978 952-7414 fax:978 392-2074 Lucent Technologies 1 Robbins Road Westford, MA 01886 From owner-ietf-outbound Thu Mar 9 01:40:50 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA26436 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 01:40:03 -0500 (EST) Received: from desh.cisco.com (desh.cisco.com [192.122.173.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25411 for ; Thu, 9 Mar 2000 01:37:01 -0500 (EST) Received: from cisco.com (desh.cisco.com [192.122.173.43]) by desh.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA25417 for ; Thu, 9 Mar 2000 12:06:28 +0530 (IST) Sender: sargupta@cisco.com Message-ID: <38C7466C.921FC7BC@cisco.com> Date: Thu, 09 Mar 2000 12:06:28 +0530 From: Sarika Gupta Reply-To: sargupta@cisco.com Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Information on Voice Over IP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Dear Sirs and Madams, I need information on Voice over IP for one of the technical papers which I'll be presenting. Could anyone point to really good sites for that? Thanks & regds, Sarika From owner-ietf-outbound Thu Mar 9 03:21:01 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA05245 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 03:20:02 -0500 (EST) Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04636 for ; Thu, 9 Mar 2000 03:17:10 -0500 (EST) Received: from default ([32.101.177.105]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.31a 201-229-119-114) with SMTP id <20000309081640.KHWQ17170.mtiwmhc25.worldnet.att.net@default> for ; Thu, 9 Mar 2000 08:16:40 +0000 Message-ID: <000a01bf899e$4a8484a0$69b16520@default> From: "Qiaolin Liang" To: References: <38C7466C.921FC7BC@cisco.com> Subject: MPEG4 server Date: Thu, 9 Mar 2000 00:05:51 -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.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Dear Sir & Madam, Does anybody know any information about MPEG4 server ? Regards, Qiaolin Liang From owner-ietf-outbound Thu Mar 9 03:40:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA11287 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 03:40:02 -0500 (EST) Received: from euronet.be (caolila.euronet.be [195.74.193.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09946 for ; Thu, 9 Mar 2000 03:35:34 -0500 (EST) Received: from atlas.adtech.be (i0645.bfp-n.euronet.be [212.65.58.137]) by euronet.be (8.9.3/8.9.3) with ESMTP id JAA05562 for ; Thu, 9 Mar 2000 09:35:31 +0100 (MET) Received: by ATLAS with Internet Mail Service (5.5.1960.3) id ; Thu, 9 Mar 2000 09:35:32 +0100 Message-ID: From: Michael Stilmant To: ietf@ietf.org Subject: RE: Information on Voice Over IP Date: Thu, 9 Mar 2000 09:35:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BF89A2.6E83E5C0" 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_01BF89A2.6E83E5C0 Content-Type: text/plain here you are http://www.fokus.gmd.de/research/cc/glone/projects/ipt/ http://www.tsufl.edu/williams/Projects/InternetPhone/TSCIS445.htm http://www.cis.ohio-state.edu/~jain/refs/ref_voip.htm -----Original Message----- From: Sarika Gupta [mailto:sargupta@cisco.com] Sent: jeudi 9 mars 2000 07:36 To: ietf@ietf.org Subject: Information on Voice Over IP Dear Sirs and Madams, I need information on Voice over IP for one of the technical papers which I'll be presenting. Could anyone point to really good sites for that? Thanks & regds, Sarika ------ =_NextPart_001_01BF89A2.6E83E5C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Information on Voice Over IP

here you are

        =       http://www.fokus.gmd.de/research/cc/glone/projects/ipt= /

        =       http://www.tsufl.edu/williams/Projects/InternetPhone/T= SCIS445.htm

        =       http://www.cis.ohio-state.edu/~jain/refs/ref_voip.htm<= /A>        

-----Original Message-----
From: Sarika Gupta [mailto:sargupta@cisco.com]
Sent: jeudi 9 mars 2000 07:36
To: ietf@ietf.org
Subject: Information on Voice Over IP


Dear Sirs and Madams,

I need information on Voice over IP for one of the = technical papers
which I'll be presenting. Could anyone point to = really good sites for
that?


Thanks & regds,
Sarika

------ =_NextPart_001_01BF89A2.6E83E5C0-- From owner-ietf-outbound Thu Mar 9 08:50:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA07649 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 08:50:02 -0500 (EST) Received: from public6.sta.net.cn (public6.sta.net.cn [202.96.199.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07567 for ; Thu, 9 Mar 2000 08:49:48 -0500 (EST) Received: from jammy-huang ([61.129.9.208]) by public6.sta.net.cn (8.9.1a/8.9.1) with ESMTP id VAA02316 for ; Thu, 9 Mar 2000 21:49:40 +0800 (CST) Message-Id: <4.2.0.58.20000309201102.00968450@pop.mail.yahoo.com> X-Sender: jbhuang@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 09 Mar 2000 20:31:14 +0800 To: ietf@ietf.org From: Jianbo Huang Subject: Re: Re: Critically compare the congestion control on TCP/IP and ATM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Dear Sir/Madam, Thank you all for giving me so much information! I have read some, and almost get a clear idea of how ATM manage the congestion control. But I still get one question: generally speaking, TCP/IP is equal to the transport and network layer in the OSI model, and it seems that the ATM works on the Data Link Layer (?). They serve different function in the OSI model. Through they all have congestion control facility, how to compare mechanism in different layer? Does the topic "Critically compare the congestion control on TCP/IP and ATM" mean only compare of the algorithms of them? Thank you again for you valuable help! rgds, Truly yours, Jianbo Huang :-) From owner-ietf-outbound Thu Mar 9 10:20:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA06119 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 10:20: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 ESMTP id KAA01629 for ; Thu, 9 Mar 2000 10:08:16 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA25870; Thu, 9 Mar 2000 10:08:10 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <38C7BE56.F0EAB673@cs.columbia.edu> Date: Thu, 09 Mar 2000 10:08:06 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Stilmant CC: ietf@ietf.org Subject: Re: Information on Voice Over IP 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 > Michael Stilmant wrote: > > here you are > > http://www.fokus.gmd.de/research/cc/glone/projects/ipt/ > > > http://www.tsufl.edu/williams/Projects/InternetPhone/TSCIS445.htm > > > http://www.cis.ohio-state.edu/~jain/refs/ref_voip.htm > See also http://www.cs.columbia.edu/sip http://www.cs.columbia.edu/~hgs/internet -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-ietf-outbound Thu Mar 9 10:30:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA08670 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 10:30:03 -0500 (EST) Received: from faatcrl.tc.faa.gov (faatcrl.faa.gov [155.178.252.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01901 for ; Thu, 9 Mar 2000 10:08:54 -0500 (EST) Received: from tc.faa.gov (igate.tc.faa.gov [155.178.180.5] (may be forged)) by faatcrl.tc.faa.gov (8.8.8/8.8.8) with ESMTP id KAA11114; Thu, 9 Mar 2000 10:07:46 -0500 (EST) Received: from ccMail by tc.faa.gov (IMA Internet Exchange 3.11) id 0015F93D; Thu, 9 Mar 2000 10:07:15 -0500 Mime-Version: 1.0 Date: Thu, 9 Mar 2000 10:03:34 -0500 Message-ID: <0015F93D.C22022@tc.faa.gov> From: Michael.CTR.Bellopede@tc.faa.gov (Michael CTR Bellopede) Subject: Re[2]: Re: Critically compare the congestion control on TCP/ To: Jianbo Huang , ietf@ietf.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit If you receive any good answers on this, please let me know. Thanx. Michael B. Bellopede Michael.CTR.Bellopede@tc.faa.gov ____________________Reply Separator____________________ Subject: Re: Re: Critically compare the congestion control on TCP/IP Author: Jianbo Huang Date: 3/9/00 8:31 PM Dear Sir/Madam, Thank you all for giving me so much information! I have read some, and almost get a clear idea of how ATM manage the congestion control. But I still get one question: generally speaking, TCP/IP is equal to the transport and network layer in the OSI model, and it seems that the ATM works on the Data Link Layer (?). They serve different function in the OSI model. Through they all have congestion control facility, how to compare mechanism in different layer? Does the topic "Critically compare the congestion control on TCP/IP and ATM" mean only compare of the algorithms of them? Thank you again for you valuable help! rgds, Truly yours, Jianbo Huang :-) From owner-ietf-outbound Thu Mar 9 10:40:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA11608 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 10:40: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 KAA02972 for ; Thu, 9 Mar 2000 10:11:52 -0500 (EST) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 9 Mar 2000 15:11:51 +0000 to: ietf@ietf.org, end2end-interest@ISI.EDU Subject: history Date: Thu, 09 Mar 2000 15:11:51 +0000 Message-ID: <3115.952614711@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org i was looking thru some old archives (1982 on - yes, thats right, from just before this years college kids were born) of the original tcp-ip maillist and came across a message from mark crispin about a broken vax mailer flooding neighbor mailservers with SYNs......amazing how nothings new see http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/ for a slightly incomplete archive of it all i couldn't find any other archive but if someoen does have it, let me know and i'll delete mine and point at theirs... one interesting thing is to look at pre-DNS email addresses - so there used to be this single file we'd all FTP from ISI with the hosts.txt listing of name/addresses - then one day we distributed it....now of course has to haev a .com, and the nameservers have to zone xfer it all the time too....so plus ca change, plus c'est le mome raths.... cheers jon From owner-ietf-outbound Thu Mar 9 12:24:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA14835 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 12:20:03 -0500 (EST) Received: from fortress.fnc.fujitsu.com (fortress.fnc.fujitsu.com [204.253.82.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13988 for ; Thu, 9 Mar 2000 12:17:26 -0500 (EST) Received: from rchsemx2.fnc.fujitsu.com (n105h13.fnc.fujitsu.com [167.254.105.13] (may be forged)) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id LAA25514; Thu, 9 Mar 2000 11:16:14 -0600 (CST) Received: by n105h13.fnc.fujitsu.com with Internet Mail Service (5.5.1960.3) id ; Thu, 9 Mar 2000 11:16:16 -0600 Message-ID: From: "Schipper, Dell" To: Jianbo Huang , ietf@ietf.org Subject: RE: Re[2]: Re: Critically compare the congestion control on TCP/ Date: Thu, 9 Mar 2000 11:16:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Loop: ietf@ietf.org I recall that Larry Roberts a few years ago gave presentations (at NetWorld+InterOp ?) that compared the congestion avoidance algorithms of ATM-ABR service to TCP/IP. I know he has started a new company since then and I do not have any contact information. Regards, Dell. ______________________________________________________________ Dell Schipper Phone: (214) 495-6422 Advanced Network Solutions Fax: (214) 495-6219 Fujitsu Network Services dell.schipper@fnc.fujitsu.com ______________________________________________________________ From owner-ietf-outbound Thu Mar 9 13:10:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA01989 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 13:10:02 -0500 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01810 for ; Thu, 9 Mar 2000 13:09:18 -0500 (EST) Received: from bigger-dawgs (rtp-dial-1-77.cisco.com [161.44.116.77]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA05368; Thu, 9 Mar 2000 10:08:08 -0800 (PST) Message-Id: <4.2.2.20000309130232.00a30220@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Mar 2000 13:08:06 -0500 To: "Schipper, Dell" From: Paul Ferguson Subject: RE: Re[2]: Re: Critically compare the congestion control on TCP/ Cc: Jianbo Huang , ietf@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 11:16 AM 03/09/2000 -0600, Schipper, Dell wrote: >I recall that Larry Roberts a few years ago gave presentations (at >NetWorld+InterOp ?) that compared the congestion avoidance algorithms of >ATM-ABR service to TCP/IP. I know he has started a new company since >then and I do not have any contact information. One of my favorites along those lines was: "End-to-End Traffic Management Issues in IP/ATM Internetworks," draft-jagan-e2e-traf-mgmt-00.txt, S. Jagannath and N. Yin, August 1997. - paul [snip] Abstract This document addresses the end-to-end traffic management issues in IP/ATM internetworks. In the internetwork environment, the ATM control mechanisms (e.g., Available Bit Rate (ABR) and UBR with Early Packet Discard (EPD)) are applicable to the ATM subnetwork, while the TCP flow control extends from end to end. We investigated the end to end performance in terms of TCP throughput and file transfer delay in cases using ABR and UBR in the ATM subnetwork. In this document, we also discuss the issue of trade-off between the buffer requirements at the ATM edge device (e.g., Ethernet-ATM switch, ATM router interface) versus ATM switches inside the ATM network. Our simulation results show that in certain scenarios (e.g., with limited edge device buffer memory) UBR with EPD may perform comparably to ABR or even outperform ABR. We show that it is not sufficient to have a lossless ATM subnetwork from the end-to-end performance point of view. The results illustrate the necessity for an edge device congestion handling mechanism that can couple the ABR and TCP feedback control loops. We present an algorithm that makes use of the ABR feedback information and edge device congestion state to make packet dropping decisions at the edge of the ATM network. Using the algorithm at the edge device, the end-to-end performance in throughput and delay are improved while using ABR as the ATM subnetwork technology and with small buffers in the edge device. [snip] From owner-ietf-outbound Thu Mar 9 13:50:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA13555 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 13:50:02 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11162 for ; Thu, 9 Mar 2000 13:42:23 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id KAA09860; Thu, 9 Mar 2000 10:35:53 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 9 Mar 2000 18:42:20 UT Received: from spud.ascend.com (spud [192.207.23.51]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id KAA25058; Thu, 9 Mar 2000 10:42:19 -0800 (PST) Received: from malisa2 ([152.148.90.98]) by spud.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id KAA13701; Thu, 9 Mar 2000 10:42:18 -0800 (PST) Message-Id: <4.2.2.20000309132922.024fd130@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Mar 2000 13:38:26 -0500 To: Jon Crowcroft From: "Andrew G. Malis" Subject: Re: history Cc: ietf@ietf.org, end2end-interest@isi.edu In-Reply-To: <3115.952614711@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org Jon, Sigh ... I checked out the archive and noticed my own email in the fall 82 archive, from when I was managing the NCP to TCP transition on the ARPANET (I wrote the code to disable NCP at the IMP interface). I didn't need to be reminded how long I've been doing this stuff ... :-). Cheers, Andy ====== At 03:11 PM 3/9/00 +0000, Jon Crowcroft wrote: >i was looking thru some old archives (1982 on - yes, thats right, from >just before this years college kids were born) >of the original tcp-ip maillist >and came across a message from mark crispin about a broken vax mailer >flooding neighbor mailservers with SYNs......amazing how nothings new > >see >http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/ >for a slightly incomplete archive of it all >i couldn't find any other archive but if someoen does have it, let me >know and i'll delete mine and point at theirs... > >one interesting thing is to look at pre-DNS email addresses - so there >used to be this single file we'd all FTP from ISI with the hosts.txt >listing of name/addresses - then one day we distributed it....now of >course has to haev a .com, and the nameservers have to zone xfer it >all the time too....so plus ca change, plus c'est le mome raths.... > > cheers > > jon > >- >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. ________________________________________________________________________ Andrew G. Malis amalis@lucent.com phone:978 952-7414 fax:978 392-2074 Lucent Technologies 1 Robbins Road Westford, MA 01886 From owner-ietf-outbound Thu Mar 9 18:11:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA27798 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 18:10:02 -0500 (EST) Received: from mail1.rdc3.on.home.com (mail1.rdc3.on.home.com [24.2.9.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26620 for ; Thu, 9 Mar 2000 18:05:07 -0500 (EST) Received: from home.com ([24.114.113.69]) by mail1.rdc3.on.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000309230450.KBQQ19066.mail1.rdc3.on.home.com@home.com> for ; Thu, 9 Mar 2000 15:04:50 -0800 Message-ID: <38C8588A.57A2F2FB@home.com> Date: Thu, 09 Mar 2000 18:06:02 -0800 From: Grreth Jeremiah X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Suggestion for Automated Security 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 This is just to "put the feelers out" with regards to security bug fixes / alerts / workarounds and the automation of receiving this type of information. Given any heterogeneous environment, platform or network, an administrator/security professional often needs to keep track of multiple OS bug lists. In addition to these lists, there are a number of applications running on these OS's whose lists must also be monitored for security alerts and fixes. A primary concern in the security field is that as soon as a fix is identified, or a vulnerability is identified, it is more than likely that it is already being exploited. Any further delay in fixing the problem, patching your OS for example only increases the vulnerability of your environment. My suggestion is to create an Internet Database where vendors / Emergency Response Teams, may put information in a SPECIFIC format regarding security alerts etc. Each vendor could be issued with a bit pattern representing them, and they may then implement their own bit pattern representing their various products. Then when an alert / fix or whatever becomes available they enter details into this database, using both the vendor an product pattern. The two patterns combined would uniquely identify a product. The overall effect would enable automation to be written that could query this database ( perhaps simple SQL ) and inform you when one of the products that you manage has a defect of some sort. Further, it could be extended to download the fixes identified, even install them. Of course there are security considerations in any venture such as this. For example, each entry in the database would have to be digitally signed to avoid unscrupulous people from adding false information, or trojan "fixes" for example. Assignment of vendor ID's should be managed centrally, like IANA did for example. This is only the tip of the iceberg of possibilities and ideas, but I would love to know what others think about this...... together the net can be a safe place. Monitoring your emails because you subscribed to 70 different bug-traq esque lists is OK, but an automated alerting system ( as this could easily become ) would be less infallible ( hmm is that even a proper sentence? ) I nickname this 'CRAAB' - Common Repository for Advisories/Alerts and Bulletins Anyway - what do you thing.... Garreth J Jeremiah. From owner-ietf-outbound Thu Mar 9 19:01:38 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA12792 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 19:00:03 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09785 for ; Thu, 9 Mar 2000 18:50:04 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id QAA23326 for ietf@ietf.org env-from ; Thu, 9 Mar 2000 16:50:02 -0700 (MST) Date: Thu, 9 Mar 2000 16:50:02 -0700 (MST) From: Vernon Schryver Message-Id: <200003092350.QAA23326@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: Suggestion for Automated Security Information X-Loop: ietf@ietf.org > From: Grreth Jeremiah > ... > Given any heterogeneous environment, platform or network, an > administrator/security professional often needs to keep track of > multiple OS bug lists. ... > My suggestion is to create an Internet Database where vendors / > Emergency Response Teams, may put information in a SPECIFIC format > regarding security alerts etc. > ... How is this problem related to the work of the IETF? Isn't the IETF supposed to be about protocols? How would this suggestion differ from CERT, besides trivia such as who sponsors the announcements and pays for the people and computers? > Each vendor could be issued with a bit pattern representing them, and > they may then implement their own bit pattern representing their various > ... Vendors already contact CERT when they discover serious security problems, and CERT already talks to vendors about reports from the field. They even use encruption, maintain mutual emergency contact lists, and so forth. > The overall effect would enable automation to be written that could > query this database ( perhaps simple SQL ) and inform you when one of > the products that you manage has a defect of some sort. If you don't like the serch facility at www.cert.org, why not send them some suggestions? > Further, it > could be extended to download the fixes identified, even install them. Somehow, that doesn't sound like a step in the right direction, but maybe that's merely because third party patch serving schemes have had such interesting histories. > ... Monitoring your emails because you subscribed to > 70 different bug-traq esque lists is OK, but an automated alerting > system ( as this could easily become ) would be less infallible ... If you watch 70 different bug-track lists, then you must like hearing a lot of noise and nonsense. Most reports of security problems from most sources are rumors of misunderstood problems or worse. Even CERT is not immune to the Chicken Little Syndrom. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Thu Mar 9 21:30:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA27290 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 21:30:03 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27229 for ; Thu, 9 Mar 2000 21:29:57 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id SAA29341; Thu, 9 Mar 2000 18:23:22 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 10 Mar 2000 02:29:48 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id SAA18918; Thu, 9 Mar 2000 18:29:47 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000309180932.00b0c9e0@porky> X-Sender: mhold@porky (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Mar 2000 18:29:50 -0800 To: "Marcus Leech" From: Matt Holdrege Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? Cc: Bill Sommerfeld , ietf@ietf.org In-Reply-To: <38C17B49.3E436AB@nortelnetworks.com> References: <200003041809.SAA11701@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 04:08 PM 3/4/00 -0500, Marcus Leech wrote: >Bill Sommerfeld wrote: > > > > > > I hope the 128 bit "gold" cards use a longer IV.. > > > > - Bill >Does anyone know if the 128-bit variant of WEP is openly specified anywhere? The last I heard RC4 was owned by RSA and not exactly open. But I do have a PDF file describing Lucent's WEP implementation a layer above RC4, so it covers some of the key management details. If you really need it, let me know. Also you can read the encryption section of 802.11 >With the spinoff of the Enterprise portion of Lucents business, will the > 128-bit variant quietly die? I hope not (assuming that it's any good, of >course). Certainly not. But as someone else mentioned, there are U.S. laws or regulations restricting sales of 128-bit encryption overseas. So I kind of doubt it will be enabled on the base stations in Adelaide. But I suppose you can purchase such cards in the U.S. and they will work fine in Adelaide with encryption turned off. As for pricing, note that the price for the cards that will be sold in Adelaide are in Australian dollars which are valued quite differently than U.S. dollars. Disclaimer: I am neither a lawyer or a crypto expert. Nor do I work in the Wavelan division of Lucent. I'm just lamely trying to help. From owner-ietf-outbound Thu Mar 9 23:20:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA05582 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 23:20:03 -0500 (EST) Received: from maxis_vw01.maxisnet.com.my (maxis-em01.maxisnet.com.my [202.190.228.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03494 for ; Thu, 9 Mar 2000 23:14:25 -0500 (EST) Received: from SUBGTD-Message_Server by maxis.com.my with Novell_GroupWise; Fri, 10 Mar 2000 12:11:06 +0800 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 10 Mar 2000 12:10:55 +0800 From: "Manohar Menon" To: holdrege@lucent.com, mleech@nortelnetworks.com Cc: ietf@ietf.org, sommerfeld@orchard.arlington.ma.us Subject: MMDS knowledge Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA03494 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Hi all I like to know whether anyone has address MMDS deployed within your enviroment. Pls let me know if you are able to provide me some information on this technology. regards mano Thanks and Best Regards Have a Good Day Manohar Menon Fixed Network Planning Products Plot 12155 ( Lot 13), Jalan Delima 1/1, Subang Hi-Tech Ind. Est Park 40000 Shah Alam Selangor Malaysia Tel : 006 03 580 1967 Fax : 006 03 580 1412 >>> Matt Holdrege 03/10 10:29 AM >>> At 04:08 PM 3/4/00 -0500, Marcus Leech wrote: >Bill Sommerfeld wrote: > > > > > > I hope the 128 bit "gold" cards use a longer IV.. > > > > - Bill >Does anyone know if the 128-bit variant of WEP is openly specified anywhere? The last I heard RC4 was owned by RSA and not exactly open. But I do have a PDF file describing Lucent's WEP implementation a layer above RC4, so it covers some of the key management details. If you really need it, let me know. Also you can read the encryption section of 802.11 >With the spinoff of the Enterprise portion of Lucents business, will the > 128-bit variant quietly die? I hope not (assuming that it's any good, of >course). Certainly not. But as someone else mentioned, there are U.S. laws or regulations restricting sales of 128-bit encryption overseas. So I kind of doubt it will be enabled on the base stations in Adelaide. But I suppose you can purchase such cards in the U.S. and they will work fine in Adelaide with encryption turned off. As for pricing, note that the price for the cards that will be sold in Adelaide are in Australian dollars which are valued quite differently than U.S. dollars. Disclaimer: I am neither a lawyer or a crypto expert. Nor do I work in the Wavelan division of Lucent. I'm just lamely trying to help. From owner-ietf-outbound Thu Mar 9 23:30:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA08759 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 23:30:02 -0500 (EST) Received: from mail1.rdc3.on.home.com (mail1.rdc3.on.home.com [24.2.9.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04888 for ; Thu, 9 Mar 2000 23:17:59 -0500 (EST) Received: from home.com ([24.114.113.69]) by mail1.rdc3.on.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000310041754.RAZN19066.mail1.rdc3.on.home.com@home.com>; Thu, 9 Mar 2000 20:17:54 -0800 Message-ID: <38C8A1EC.43B64692@home.com> Date: Thu, 09 Mar 2000 23:19:08 -0800 From: Grreth Jeremiah X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vernon Schryver CC: ietf@ietf.org Subject: Re: Suggestion for Automated Security Information References: <200003092350.QAA23326@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 Sir, I thank your for your comments, and agree that perhaps this was not the correct forum, however give the vast reach of the people monitoring this list, the variety of responses, and opinion would have been usefull. Unfortunatly, either I mis-explained myself, or you mis-understood. The purpose of CRAAB is to enable automation of tools to discover vulnerabilities. At present CERT does an excellent job of keeping the security world posted, however it is unreasonable for Miss Jane Bloggs, sat at home on her windows 98 pentium III 500, to know aboult, let alone moniter CERT. Disregard for EVERYONE is the commonality that has thus far allowed remote penetratrion of machines through such mechanisms as VERY WELL KNOWN RPC VULNERABILITIES, which have further permitted the recent DDoS attacks. Your candid disregard for this simple fact may explain how eager you were to disregard my suggestion without quandry. In addition to 'la fammile Bloggs' the fact that CERT caters mainly for OS's ( although admittedly not exclusivley ) however there are many products installed in corporate environments, ISP environments and the home user environment that can, and do, cause vulnerabilities in the security of that system. Many of these products never make it to CERT. Maintaining levels of code on systems ( such as keeping up to date with Sendmail or Kerberos ) are vital tasks, which may have a delay of a few days from being released to Mr Sys Admin discovering this fact. Utilising the suggestion of CRAAB, this information can be automatically discovered by ANYONE with an interest in product X, spanning the whole sphere of what a user has on their machine, not just the OS. >> Further, it >> could be extended to download the fixes identified, even install them. >Somehow, that doesn't sound like a step in the right direction, but >maybe that's merely because third party patch serving schemes have had >such interesting histories. Agreed, this is where deeper consideration is required. Steps such as this have allready been made, like Flash upgrading the OS of your cable receiver over the cable feed for example. Installation is an option that need not be considered, however an option it is. >> ... Monitoring your emails because you subscribed to >> 70 different bug-traq esque lists is OK, but an automated alerting >> system ( as this could easily become ) would be less infallible ... >If you watch 70 different bug-track lists, then you must like hearing a >lot of noise and nonsense. Most reports of security problems from most >sources are rumors of misunderstood problems or worse. Even CERT is not >immune to the Chicken Little Syndrom. Please accept my appologies for attempting mild humor, or slight sarchasm. however these were bug traq ESQUE and not BUG TRAQ - per se. An attempt to illustrate that if you install an OS, and 15 different applications for example then it is clearly possible that you could b monitoring approx 20 lists, an OS bugs/fixes list, CERT / SANS / X-Force / AUSCERT etc, plus each product mailing list looking for developments and incrimental corrections. Just think how many web sites you visit in 1 day ( disregarding Playboy ) just to keep up on development ( in terms of codefixes ) for your system. Remember that the view of security does not just include the "OH damn XYZ has been broken into" and given that the vendors the Chicken Little Syndrome can be avoided - ie only verified occurences get entered, this is the realm of process however. As said vendors would supply the data so, as opposed to sifting through CERT Advisories for the Vulnerable Systems section to see if this one applies to your OS, you can focus immediatley on ONLY those products / systems you have. your CRAAB agent could run twice daily, examine CRAAB and then report any findings directly to you. This cuts across many fields such as Databases, Cryptography, Systems Integration / Impplimentation and others. Anyway, I thank you for your comments and welcome anyone to send their comments directly do me if they fear that this conversation may pollute the waters that are these mailing lists I also appologise if my candid, pseudo sarchastic method of penning ( typing ) offends you - just making light of the corespondance...Thanks Garreth J... Vernon Schryver wrote: > > From: Grreth Jeremiah > > > ... > > Given any heterogeneous environment, platform or network, an > > administrator/security professional often needs to keep track of > > multiple OS bug lists. ... > > > My suggestion is to create an Internet Database where vendors / > > Emergency Response Teams, may put information in a SPECIFIC format > > regarding security alerts etc. > > ... > > How is this problem related to the work of the IETF? Isn't the > IETF supposed to be about protocols? > > How would this suggestion differ from CERT, besides trivia such as who > sponsors the announcements and pays for the people and computers? > > > Each vendor could be issued with a bit pattern representing them, and > > they may then implement their own bit pattern representing their various > > ... > > Vendors already contact CERT when they discover serious security problems, > and CERT already talks to vendors about reports from the field. They even > use encruption, maintain mutual emergency contact lists, and so forth. > > > The overall effect would enable automation to be written that could > > query this database ( perhaps simple SQL ) and inform you when one of > > the products that you manage has a defect of some sort. > > If you don't like the serch facility at www.cert.org, why not send > them some suggestions? > > > Further, it > > could be extended to download the fixes identified, even install them. > > Somehow, that doesn't sound like a step in the right direction, but > maybe that's merely because third party patch serving schemes have had > such interesting histories. > > > ... Monitoring your emails because you subscribed to > > 70 different bug-traq esque lists is OK, but an automated alerting > > system ( as this could easily become ) would be less infallible ... > > If you watch 70 different bug-track lists, then you must like hearing a > lot of noise and nonsense. Most reports of security problems from most > sources are rumors of misunderstood problems or worse. Even CERT is not > immune to the Chicken Little Syndrom. > > Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Thu Mar 9 23:40:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA12516 for ietf-outbound.10@ietf.org; Thu, 9 Mar 2000 23:40:03 -0500 (EST) Received: from arcc.or.ke (root@[199.2.222.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06969 for ; Thu, 9 Mar 2000 23:24:39 -0500 (EST) Received: from 199.2.222.254 ([199.2.222.123]) by arcc.or.ke (8.8.5/8.8.5) with SMTP id HAA09776 for ; Fri, 10 Mar 2000 07:39:53 +0300 (EAT) Date: Fri, 10 Mar 2000 07:39:53 +0300 (EAT) Message-Id: <200003100439.HAA09776@arcc.or.ke> X-Sender: musandu@199.2.222.254 X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org From: Musandu Subject: Re: Suggestion for Automated Security Information X-Loop: ietf@ietf.org This database if created would be a one stop shopping point for "hackers" to test their theories because it would most likely be configured to meet the standards that are advocated within it (even if the IETF was to run it under some TCP/IP reason). Yours truly, Nyagudi Musandu >My suggestion is to create an Internet Database where vendors / >Emergency Response Teams, may put information in a SPECIFIC format >regarding security alerts etc. > >Garreth J Jeremiah. > > > > > From owner-ietf-outbound Fri Mar 10 03:31:36 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA04185 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 03: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 ESMTP id DAA01435 for ; Fri, 10 Mar 2000 03:20:57 -0500 (EST) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0/8.10.0) with ESMTP id e2A8KVp26206; Fri, 10 Mar 2000 03:20:31 -0500 Message-Id: <200003100820.e2A8KVp26206@black-ice.cc.vt.edu> To: Musandu cc: ietf@ietf.org Subject: Re: Suggestion for Automated Security Information In-reply-to: Your message of "Fri, 10 Mar 2000 07:39:53 +0300." <200003100439.HAA09776@arcc.or.ke> From: Valdis.Kletnieks@vt.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: Fri, 10 Mar 2000 03:20:30 -0500 Sender: valdis@black-ice.cc.vt.edu X-Loop: ietf@ietf.org On Fri, 10 Mar 2000 07:39:53 +0300, Musandu said: > > This database if created would be a one stop shopping point for "hackers" to > test their theories because it would most likely be configured to meet the > standards that are advocated within it (even if the IETF was to run it under > some TCP/IP reason). Umm.. the hackers already *have* one-stop shopping, at a number of places. When did www.rootshell.com open for business? ;) I've appended the abstract of a possibly-relevant I-D, which I haven't read yet because I've been up to my ears in other stuff... ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech Title : Intrusion Detection Message Exchange Format Comparison of SMI and XML Implementations Author(s) : G. Mansfield, D. Curry Filename : draft-mansfield-curry-idmef-xmlsmi-01.txt Pages : 26 Date : 06-Mar-00 The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. The goals and requirements of the IDMEF are described in [3]. Two implementations of the IDMEF data format have been proposed: one using the Structure of Management Information (SMI) to describe an SNMP MIB, and the other using a Document Type Definition (DTD) to describe XML documents. Both representations appear to have their good and bad traits, and deciding between them is difficult. To arrive at an informed decision, the working group tasked the authors to identify and analyze the pros and cons of both approaches, and present the results in the form of an Internet-Draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mansfield-curry-idmef-xmlsmi-01.txt From owner-ietf-outbound Fri Mar 10 04:20:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA19547 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 04:20:02 -0500 (EST) Received: from server.jad.net ([202.134.2.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16622 for ; Fri, 10 Mar 2000 04:10:17 -0500 (EST) Received: from oke.com (cf-isrlab7.comp.nus.edu.sg [137.132.85.181]) by server.jad.net (8.9.2/8.9.2) with ESMTP id RAA35246; Fri, 10 Mar 2000 17:09:46 +0700 (JAVT) (envelope-from rms46@oke.com) Sender: ibrahim@server.jad.net Message-ID: <38C8BBBD.3794A38C@oke.com> Date: Fri, 10 Mar 2000 17:09:17 +0800 From: "Rahmat M. Samik-Ibrahim" Reply-To: rms46.oke.com@vlsm.org Organization: VLSM-TJT X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: MILIS IETF Subject: Re: history 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 Jon Crowcroft: > see > http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/ > for a slightly incomplete archive of it all > i couldn't find any other archive but if someone does have > it, let me know and i'll delete mine and point at theirs... Hopefully, there will be permanent URLs for those archives. > so there used to be this single file we'd all FTP from ISI with > the hosts.txt listing of name/addresses - I recall that even in 1988, a.cs.uiuc.edu or uiucdcs (then a VAX-11/750) did "gethostfromnic" once or twice a week. PS: It is interesting to note that in 1986, a CISCO IP gateway(1-4 way) that supports IP/TCP and V.35 cost $7950. regards, -- - Rahmat M. Samik-Ibrahim -- VLSM-TJT -- http://rms46.vlsm.org/ - - struct {char unstable;void knowledge;float hopes;double income;}; From owner-ietf-outbound Fri Mar 10 04:50:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA27332 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 04:50: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 EAA26353 for ; Fri, 10 Mar 2000 04:45:47 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 10 Mar 2000 09:45:37 +0000 To: Paul Ferguson cc: ietf@ietf.org Subject: Re: Re[2]: Re: Critically compare the congestion control on TCP/ In-reply-to: Your message of "Thu, 09 Mar 2000 13:08:06 EST." <4.2.2.20000309130232.00a30220@lint.cisco.com> Date: Fri, 10 Mar 2000 09:45:34 +0000 Message-ID: <2861.952681534@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org the best work i know of on TCP behaviour _over_ ATM services is the thesis (and papers by) Olivier Bonaventure - http://www.info.fundp.ac.be/~obo/ cheers jon From owner-ietf-outbound Fri Mar 10 05:10:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA03833 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 05:10:04 -0500 (EST) Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00648 for ; Fri, 10 Mar 2000 05:00:50 -0500 (EST) Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id <1FBGFL45>; Fri, 10 Mar 2000 05:00:15 -0500 Message-ID: <75ADD7496F0BD211ADC000104B8846CF01911645@rerun.lucentctc.com> From: "Weiss, Walter" To: "'ietf@ietf.org'" Subject: New draft and mailing list available on Information Modeling in t he IETF Date: Fri, 10 Mar 2000 05:00:14 -0500 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 In recent years, working groups have come under pressure to define multiple, parallel data structures for managing various technologies (DHCP, DiffServ, MPLS, etc.) through different protocols (SNMP, LDAP, COPS, etc.) and network management paradigms (directories, agents, policy, etc.). A new mailing list has been established to consider possible means for reducing the burden on working groups by defining protocol and management paradigm independent configuration/management data definitions that could subsequently be mapped to the various protocols. To consider the viability of this approach and determine if there is sufficient interest to create a working group, a new mailing list has been established: mailing list : nim@ops.ietf.org [un]subscribe: nim-request@ops.ietf.org archive: ftp://ops.ietf.org/pub/lists In addition, a requirements document for a network information modeling activity has been written and submitted to the IETF. This draft can be found at web: ftp://ftp.intel.com\/pub/outgoing/draft-durham-nim-reqs-00.txt ftp: ftp.intel.com\pub\outgoing\draft-durham-nim-reqs-00.txt regards, -Walter From owner-ietf-outbound Fri Mar 10 06:50:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA06359 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 06:50:02 -0500 (EST) Received: from smtp.jet.es (smtp.jet.es [194.179.100.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05991 for ; Fri, 10 Mar 2000 06:48:55 -0500 (EST) Received: from jet.es (infou407.jet.es [195.55.161.151]) by smtp.jet.es (8.9.3/8.9.1) with ESMTP id MAA24987 for ; Fri, 10 Mar 2000 12:48:03 +0100 (MET) X-Envelope-To: Message-ID: <38C8E09B.20EA927@jet.es> Date: Fri, 10 Mar 2000 12:46:35 +0100 From: Julio =?iso-8859-1?Q?C=E9sar?= Serrano Ortuno X-Mailer: Mozilla 4.5 [es] (Win98; I) X-Accept-Language: es MIME-Version: 1.0 To: ietf@ietf.org Subject: Problems with networks 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 everyone, I have errors randomly within two networks interconnected with fiber-optic. What procedure should I follow for detecting the problem? There's any RFC number that describes procedures for seek and solve network problems? Thanks a lot! From owner-ietf-outbound Fri Mar 10 07:10:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA13763 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 07:10:03 -0500 (EST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11830 for ; Fri, 10 Mar 2000 07:04:27 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id EAA03389; Fri, 10 Mar 2000 04:28:49 -0800 (PST) Received: from p7020-img-nt.cisco.com (oz-syd-dial1-14.cisco.com [144.254.157.15]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id EAA29722; Fri, 10 Mar 2000 04:09:07 -0800 Message-Id: <4.3.0.20000310222824.00e87b20@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 10 Mar 2000 22:32:23 +1100 To: Jianbo Huang From: Fred Baker Subject: Re: Critically compare the congestion control on TCP/IP and ATM? Cc: ietf@ietf.org In-Reply-To: <4.2.0.58.20000308223129.00968ba0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 05:57 PM 3/9/00 +0800, Jianbo Huang wrote: >Dear Sirs and Madams, > >A friend of mine are working on the paper on "critically compare the >congestion control on TCP/IP and ATM", and she ask me for help. But I do >not get much idea on the "congestion control on ATM". So, is there anyone >can give me any idea on this topic, while my friend and I processing on this? that's easy; there isn't any. There is ingress port policing, which is something different, and there may be PNNI call routing. But there is not anything that corresponds to what TCP expects from its underlying layers. There have been some papers written and a fair bit of experience with a technique for mitigating this, called Early packet Discard. In essence, if a link is becoming congested, rather than dropping a single cell, if it has to drop an AAL5 cell it drops the entire packet containing the cell. This may sound odd, but it is actually quite sensible - if the other cells were not also dropped, then they would uselessly occupy bandwidth on subsequent links, and at the final delivery point would consume memory unnecessarily until the SAR was able to determine that the cell had been dropped. From owner-ietf-outbound Fri Mar 10 11:10:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA02837 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 11:10:02 -0500 (EST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01484 for ; Fri, 10 Mar 2000 11:04:36 -0500 (EST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id KAA12675 for ; Fri, 10 Mar 2000 10:59:11 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdKAACx.U__; Fri Mar 10 10:58:54 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf@ietf.org; Fri, 10 Mar 2000 11:04:16 -0500 Received: from newbridge.com ([138.120.49.43]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA27E; Fri, 10 Mar 2000 11:04:14 -0500 Message-Id: <38C91CF3.E772DE8@newbridge.com> Date: Fri, 10 Mar 2000 11:04:03 -0500 From: "Scott W Brim" Organization: Newbridge Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: Jianbo Huang , ietf@ietf.org Subject: Re: Critically compare the congestion control on TCP/IP and ATM? References: <4.3.0.20000310222824.00e87b20@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 ATM ABR offers explicit closed loop feedback about congestion experienced, and will drop cells/frames if that feedback is not followed. In certain types of VBR the CLP bit can be used to indicate that a cell was out of profile. Such cells do not have to be dropped if the network has room for them. Fred Baker wrote: > At 05:57 PM 3/9/00 +0800, Jianbo Huang wrote: > >Dear Sirs and Madams, > > > >A friend of mine are working on the paper on "critically compare the > >congestion control on TCP/IP and ATM", and she ask me for help. But I do > >not get much idea on the "congestion control on ATM". So, is there anyone > >can give me any idea on this topic, while my friend and I processing on this? > > that's easy; there isn't any. There is ingress port policing, which is > something different, and there may be PNNI call routing. But there is not > anything that corresponds to what TCP expects from its underlying layers. > > There have been some papers written and a fair bit of experience with a > technique for mitigating this, called Early packet Discard. In essence, if > a link is becoming congested, rather than dropping a single cell, if it has > to drop an AAL5 cell it drops the entire packet containing the cell. This > may sound odd, but it is actually quite sensible - if the other cells were > not also dropped, then they would uselessly occupy bandwidth on subsequent > links, and at the final delivery point would consume memory unnecessarily > until the SAR was able to determine that the cell had been dropped. From owner-ietf-outbound Fri Mar 10 14:22:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA10392 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 14:20:03 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09059 for ; Fri, 10 Mar 2000 14:16:05 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA23373 for ; Fri, 10 Mar 2000 12:16:05 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA21556 for ; Fri, 10 Mar 2000 12:16:04 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA11719 for ; Fri, 10 Mar 2000 14:16:03 -0500 (EST) Message-Id: <200003101916.OAA11719@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: IETF@ietf.org Subject: Re: Critically compare the congestion control on TCP/IP and ATM? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Mar 2000 14:16:04 -0500 From: Dan Grossman X-Loop: ietf@ietf.org > -----Original Message----- > From: Fred Baker [SMTP:fred@CISCO.COM] > Sent: Friday, March 10, 2000 5:32 AM > To: Jianbo Huang > Cc: ietf@ietf.org > Subject: Re: Critically compare the congestion control on TCP/IP > and ATM? > > At 05:57 PM 3/9/00 +0800, Jianbo Huang wrote: > >Dear Sirs and Madams, > > > >A friend of mine are working on the paper on "critically compare the > >congestion control on TCP/IP and ATM", and she ask me for help. But I > do > >not get much idea on the "congestion control on ATM". So, is there > anyone > >can give me any idea on this topic, while my friend and I processing > on this? > ATM has a carefully defined traffic management architecture. Read: www.atmforum.com/pub/approved-specs/af-tm-0121.000.pdf In short, it supports a strong distinction between elastic and inelastic traffic, and provides distinct services to support each. For inelastic traffic, there is an open loop control system which shapes and polices traffic to traffic contracts defined by token buckets. Signalling triggers admission control and bandwidth reservation. Meaningful guarantees on delay, delay jitter and loss can be offered to traffic streams that conform to the traffic contract. For elastic traffic there are several options: An available bitrate (ABR) service category provides a control loop for matching the rate of each virtual connection (VC) to the larger of a nominal fair share of the bottleneck bandwidth of the path, and a negotiated minimum. End-system behavior is standardized. Switches can either directly indicate the allowed cell rate in resource management cells which are sent periodically, or can use a binary feedback system (mostly for backward compatibility). ABR provides excellent isolation, fairness, and protection against misbehaved VCs. When the end-system behavior rules are honored, there is little if any cell loss. ABR is also resistant to performance problems associated with errored links, highly asymetrical links and long bandwidth-delay product links. The unspecified bitrate (UBR) and guaranteed frame rate (GFR) service categories offer a best-effort service like IP. They depend on packet discard and end-to-end behavior (as in TCP) for stability. Modern implementations have a separate queue for each VC, and provide at least that level of isolation and fairness. There is no admission control. > that's easy; there isn't any. See the ATM Forum Traffic Managment specification >There is ingress port policing, which is > > something different, No, it's one component of the system, especially as applied to inelastic traffic. > and there may be PNNI call routing. That's another component of the system, but operates on a different timescale, and only in the context of signalling and admission control (as well as being a critical network optimization) > But there is > not > anything that corresponds to what TCP expects from its underlying > layers. What do you think is missing for UBR and GFR? The semantics are effectively the same: feedback control using packet loss as a signal. > There have been some papers written and a fair bit of experience with > a > technique for mitigating this, called Early packet Discard. In > essence, if > a link is becoming congested, rather than dropping a single cell, if > it has > to drop an AAL5 cell it drops the entire packet containing the cell. > This > may sound odd, but it is actually quite sensible - if the other cells > were > not also dropped, then they would uselessly occupy bandwidth on > subsequent > links, and at the final delivery point would consume memory > unnecessarily > until the SAR was able to determine that the cell had been dropped. Ah, the segmentation and reassembly problem. EPD is not a congestion control mechanism per se, but rather a correction to an impedence mismatch between the minimum unit that can be dropped (a cell) and the minimum unit which is useful (a packet). There were a couple of papers about this in 1993 (see Sally Floyd's web page), and it was incorporated into the ATM standards. All modern implementations support EPD and PPD. Certainly not a point that I would pick as being one of the most salient in a discussion of ATM congestion control. From owner-ietf-outbound Fri Mar 10 15:31:55 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA04161 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 15:30:03 -0500 (EST) Received: from sean.ebone.net (sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01324 for ; Fri, 10 Mar 2000 15:21:26 -0500 (EST) Received: (from smd@localhost) by sean.ebone.net (8.9.3/8.9.3) id VAA00894 for IETF@ietf.org; Fri, 10 Mar 2000 21:20:50 +0100 (CET) Date: Fri, 10 Mar 2000 21:20:50 +0100 (CET) From: Sean Doran Message-Id: <200003102020.VAA00894@sean.ebone.net> To: IETF@ietf.org Subject: Re: Critically compare the congestion control on TCP/IP and ATM? X-Loop: ietf@ietf.org Dan Grossman writes: | ATM has a carefully defined traffic management architecture. Yes, that's its problem. From issue 10 of "New Carrier" (http://www.totaltele.com/newcarrier", p 22: ... the past several years' debates over the relative technical merits of [the] Internet Protocol versus other network technologies like ATM, often missed the point. IP and its associated technologies haven't taken over because they produce a brilliantly efficient network, but because they together seem capable of creating a dynamic openness for the network economy; this is because of, and not despite, a simplicity and a lack of carrier-style attributes. Sean. From owner-ietf-outbound Fri Mar 10 19:02:03 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA18582 for ietf-outbound.10@ietf.org; Fri, 10 Mar 2000 19:00: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 ESMTP id SAA16644 for ; Fri, 10 Mar 2000 18:54:42 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id 205FB1E004F; Fri, 10 Mar 2000 18:54:44 -0500 (EST) To: Matt Holdrege Cc: "Marcus Leech" , Bill Sommerfeld , ietf@ietf.org Subject: Re: Who is interested in wireless cards for the Adelaide IETF meeting? References: <200003041809.SAA11701@orchard.arlington.ma.us> <4.2.2.20000309180932.00b0c9e0@porky> From: "Perry E. Metzger" Date: 10 Mar 2000 18:54:44 -0500 In-Reply-To: Matt Holdrege's message of "Thu, 09 Mar 2000 18:29:50 -0800" Message-ID: <87wvna1iuz.fsf@snark.piermont.com> Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.3 X-Loop: ietf@ietf.org Matt Holdrege writes: > The last I heard RC4 was owned by RSA and not exactly open. RC4 is completely public, though against the will of RSA. It's even described in Schneier. > Certainly not. But as someone else mentioned, there are U.S. laws or > regulations restricting sales of 128-bit encryption overseas. Those have been relaxed of late, as you may know. -- Perry Metzger perry@piermont.com -- "Ask not what your country can force other people to do for you..." From owner-ietf-outbound Sat Mar 11 21:53:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA08230 for ietf-outbound.10@ietf.org; Sat, 11 Mar 2000 21:40:03 -0500 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07509 for ; Sat, 11 Mar 2000 21:37:45 -0500 (EST) Received: from sao ([203.10.60.7]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id NAA05630 for ; Sun, 12 Mar 2000 13:37:15 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.2.0.58.20000312133429.00ae2990@mako1.telstra.net> X-Sender: gih@mako1.telstra.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 12 Mar 2000 13:36:28 +1100 To: ietf@ietf.org From: Geoff Huston Subject: Re: Plugging in Down Under In-Reply-To: <200003060122.LAA22581@koestler.holon.net> References: <200003060032.QAA08438@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org > > % If you need to connect to telephone network, Australia has its own > > % telephone connector too of course (although I suspect that major hotels > > % may have the familar "data port" on the side of the phone). > > > > is it the goofy british plug they use in HongKong? > > flipped pairs like hongkong? I haven't had to use a spade phone plug for over 5 years in Australia RJ-11's are pretty much the rule in Australian hotels these days. ------- Geoff Huston Chief Scientist, Internet Telstra Strategy & Research phone: +61 2 6208 1908 fax: +61 2 6248 6165 www.telstra.net/gih From owner-ietf-outbound Sun Mar 12 21:14:50 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA10028 for ietf-outbound.10@ietf.org; Sun, 12 Mar 2000 21:10:02 -0500 (EST) Received: from timtam.aarnet.edu.au (IDENT:root@timtam.aarnet.edu.au [202.6.112.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08109 for ; Sun, 12 Mar 2000 21:03:44 -0500 (EST) Received: from sao (sao.aarnet.edu.au [202.6.112.16]) by timtam.aarnet.edu.au (8.9.3/8.9.3) with SMTP id KAA04674; Mon, 13 Mar 2000 10:08:24 +0800 Return-Receipt-To: "Bruce Morgan" Reply-To: From: "Bruce Morgan" To: "Geoff Huston" , Subject: RE: Plugging in Down Under Date: Mon, 13 Mar 2000 09:52:35 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <4.2.0.58.20000312133429.00ae2990@mako1.telstra.net> Disposition-Notification-To: "Bruce Morgan" Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > I haven't had to use a spade phone plug for over 5 years > in Australia > > RJ-11's are pretty much the rule in Australian hotels these days. > Well Geoff, I was almost forced to use one this weekend in Adelaide. Only an Aussie P601(?) available and no RJ11 socket in sight. I unplugged the phone from the RJ11 and used a barrel connector - worth their weight in gold... -- Bruce Morgan mailto:bruce.morgan@aarnet.edu.au Network Engineer, Australian Academic and Research Network (AARNet) Ph: 08-9334-8944 Fax: 08-9334-8001 Mobile: 0408 88 2390 From owner-ietf-outbound Sun Mar 12 23:40:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA06244 for ietf-outbound.10@ietf.org; Sun, 12 Mar 2000 23:40:04 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02759 for ; Sun, 12 Mar 2000 23:31:27 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id VAA15008 for ; Sun, 12 Mar 2000 21:31:28 -0700 (MST)] Received: [from msgphx7.sps.mot.com (msgphx7.sps.mot.com [216.11.52.7]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id VAA08697 for ; Sun, 12 Mar 2000 21:31:27 -0700 (MST)] Received: from email.sps.mot.com ([216.210.10.248]) by msgphx7.sps.mot.com (Netscape Messaging Server 3.61) with ESMTP id AAA2995; Sun, 12 Mar 2000 21:31:25 -0700 Message-ID: <38CC6F42.28C223@email.sps.mot.com> Date: Sun, 12 Mar 2000 20:32:02 -0800 From: "Getty Verma" Organization: Motorola Semiconductor Products Sector X-Mailer: Mozilla 4.06 [en]C-MOTSPS405U (WinNT; I) MIME-Version: 1.0 To: Sean Doran CC: IETF@ietf.org, "Getty Verma (r41169)" Subject: Re: Critically compare the congestion control on TCP/IP and ATM? References: <200003102020.VAA00894@sean.ebone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Motorola-Sent-Wireless: 1 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit The biggest worry to me is that depite all the promises offered and realities measured in the labs on all this MPLS, IP switching etc etc -- Internet protocol cannot provide the QoS for voice and video multicasting with 5 Nines reliability. IETF and Carrier Class 5 Nines reliability in a bulletproof manner are like 2 cities still poles apart. Efficiency feathers went to IP- cannot we be a little more honest and praise the Optical media and the Fibres since even POS needs layer 1 optical PHYs. Traffic management is another name of 99.99999% reliabiity at the end of the day ! Just a comment , we are comparing apples with Oranges ! thx getty Sean Doran wrote: > Dan Grossman writes: > > | ATM has a carefully defined traffic management architecture. > > Yes, that's its problem. > > From issue 10 of "New Carrier" (http://www.totaltele.com/newcarrier", p 22: > > ... the past several years' debates over the relative technical > merits of [the] Internet Protocol versus other network technologies > like ATM, often missed the point. IP and its associated technologies > haven't taken over because they produce a brilliantly efficient network, > but because they together seem capable of creating a dynamic > openness for the network economy; this is because of, and not > despite, a simplicity and a lack of carrier-style attributes. > > Sean. From owner-ietf-outbound Mon Mar 13 00:50:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA02555 for ietf-outbound.10@ietf.org; Mon, 13 Mar 2000 00:50:03 -0500 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02170 for ; Mon, 13 Mar 2000 00:48:49 -0500 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id PAA09015; Mon, 13 Mar 2000 15:30:21 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma009011; Mon, 13 Mar 00 15:30:11 +1000 Received: from julubu.staff.apnic.net (julubu.staff.apnic.net [192.168.1.37]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with ESMTP id PAA18416; Mon, 13 Mar 2000 15:30:02 +1000 (EST) Date: Mon, 13 Mar 2000 15:30:08 +1000 (EST) From: Bruce Campbell X-Sender: bc@julubu.staff.apnic.net To: Julio =?iso-8859-1?Q?C=E9sar?= Serrano Ortuno cc: ietf@ietf.org Subject: Re: Problems with networks In-Reply-To: <38C8E09B.20EA927@jet.es> 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 AAA02170 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit On Fri, 10 Mar 2000, Julio César Serrano Ortuno wrote: julk> I have errors randomly within two networks interconnected with julk> fiber-optic. julk> What procedure should I follow for detecting the problem? julk> There's any RFC number that describes procedures for seek and solve julk> network problems? RFC 2321 perhaps ? Possibly you would be better off by contacting the vendors of the equipment to see if they have anything appropriate. Common sense[1] is also useful (identify common path, etc etc) Regards, -- Bruce Campbell +61-7-3367-0490 Systems Administrator Regional Internet Registry Asia Pacific Network Information Centre For the Asia Pacific Region [1] Theres nothing 'common' about common sense IMHE. From owner-ietf-outbound Mon Mar 13 01:10:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA11006 for ietf-outbound.10@ietf.org; Mon, 13 Mar 2000 01:10:06 -0500 (EST) Received: from vicosa.dpi.ufv.br (vicosa.dpi.ufv.br [200.17.74.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09624 for ; Mon, 13 Mar 2000 01:07:07 -0500 (EST) Received: from dpi.ufv.br (nbhe01-0183.bhe.embratel.net.br [200.251.224.183]) by vicosa.dpi.ufv.br (AIX4.2/UCB 8.7/8.7) with ESMTP id DAA63896; Mon, 13 Mar 2000 03:06:40 -0300 (GRNLNDST) Message-ID: <38CDD774.E7E88A3D@dpi.ufv.br> Date: Tue, 14 Mar 2000 03:08:53 -0300 From: Fabiano =?iso-8859-1?Q?Dur=E3o?= Lanini X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Dau Do , ietf@ietf.org Subject: Re: MPG & WCDMA format ? References: <38C5F86F.CF5B15DF@2xtreme.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 I'm looking for this too. If you receive anything, reply to me, please. Dau Do wrote: > Hello, > Does anyone know where to get the MPG and WCDMA specification ? > I am looking for the MPG and WCDMA frame format. > > Thank you > Dau Do From owner-ietf-outbound Mon Mar 13 01:20:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA15765 for ietf-outbound.10@ietf.org; Mon, 13 Mar 2000 01:20:04 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15653 for ; Mon, 13 Mar 2000 01:19:52 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id XAA18705 for ; Sun, 12 Mar 2000 23:19:51 -0700 (MST)] Received: [from msgphx7.sps.mot.com (msgphx7.sps.mot.com [216.11.52.7]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id XAA09169 for ; Sun, 12 Mar 2000 23:19:51 -0700 (MST)] Received: from email.sps.mot.com ([216.210.10.248]) by msgphx7.sps.mot.com (Netscape Messaging Server 3.61) with ESMTP id AAA264; Sun, 12 Mar 2000 23:19:49 -0700 Message-ID: <38CC88AA.A55E6812@email.sps.mot.com> Date: Sun, 12 Mar 2000 22:20:27 -0800 From: "Getty Verma" Organization: Motorola Semiconductor Products Sector X-Mailer: Mozilla 4.06 [en]C-MOTSPS405U (WinNT; I) MIME-Version: 1.0 To: "Fabiano =?iso-8859-1?Q?Dur=E3o?= Lanini" CC: Dau Do , ietf@ietf.org, "Getty Verma (r41169)" Subject: Re: MPG & WCDMA format ? References: <38CDD774.E7E88A3D@dpi.ufv.br> Content-Type: text/plain; charset=iso-8859-1 X-Motorola-Sent-Wireless: 1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA15653 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Does any one know what actually Q cell means in xDSL systems? Is it maintenance cell of ATM ? thx getty Fabiano Durão Lanini wrote: > I'm looking for this too. If you receive anything, reply to me, please. > > Dau Do wrote: > > > Hello, > > Does anyone know where to get the MPG and WCDMA specification ? > > I am looking for the MPG and WCDMA frame format. > > > > Thank you > > Dau Do From owner-ietf-outbound Mon Mar 13 11:10:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA04739 for ietf-outbound.10@ietf.org; Mon, 13 Mar 2000 11:10:03 -0500 (EST) Received: from smtp.263.net ([202.96.44.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00777 for ; Mon, 13 Mar 2000 11:00:51 -0500 (EST) Received: from 263.net (unknown [202.112.109.83]) by smtp.263.net (Postfix) with ESMTP id C678A1C2E867A; Mon, 13 Mar 2000 20:47:18 +0800 (CST) Message-ID: <38CCE2A9.6D049F6A@263.net> Date: Mon, 13 Mar 2000 20:44:25 +0800 From: jinglin X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Valdis.Kletnieks@vt.edu, ietf@ietf.org Subject: malformed LDP message References: <38C4D898.6DDC2C99@263.net> <200003080328.e283S8w15064@black-ice.cc.vt.edu> Content-Type: multipart/alternative; boundary="------------9DC3CB82921335E77ED19B46" X-Loop: ietf@ietf.org --------------9DC3CB82921335E77ED19B46 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tanks for your help. I have another question now. I saw the following sentences in the same draft(draft-ietf-mpls-ldp-06.txt): "" An LDP Message is malformed if: - The Message Type is unknown. If the Message Type is < 0x8000 (high order bit = 0) it is an error signaled by the Unknown Message Type Status Code. If the Message Type is >= 0x8000 (high order bit = 1) it is silently discarded. Any value of Message type(error for <0x8000,discard for >=0x8000) causes LDP message malformed, then which values are right for message type? Valdis.Kletnieks@vt.edu wrote: > On Tue, 07 Mar 2000 18:23:20 +0800, jinglin said: > > I cannot understand the meaning of the words: > >" 2. LSR1 determines whether it will play the active or passive role > > in session establishment by comparing addresses A1 and A2 as > > unsigned integers. If A1 > A2, LSR1 plays the active role; > > otherwise it is passive. " > > > I want to know what kind of address of A1&A2, IP address or TCP port > > No.? why the role is determined by the size of A1 &A2? > > I don't know what A1/A2 are, but a IP/port tuple sounds like a good > guess (*PLEASE* read the draft to see if I am right). This would have > the property that the tuples represending the two ends of the connection > would be almost guaranteed to be different (ignoring the boundary > condition of connecting a port to itself). > > A1 and A2 are both almost certainly the same *size* as in "number > of bits used to represent them". What is being compared is the *value* > of the two addresses. mlps needs a fast way to determin which will > be the active/passive role. Whichever has the higher value address > becomes active. If these were telephones, we'd say "compare the two > phone numbers as integers, whichever has the higher number acts > as the active end". > > Valdis Kletnieks > Operating Systems Analyst > Virginia Tech --------------9DC3CB82921335E77ED19B46 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tanks for your help. I have another question now.  I saw the following sentences in the same draft(draft-ietf-mpls-ldp-06.txt):
"" An LDP Message is malformed if:

     - The Message Type is unknown.

       If the Message Type is < 0x8000 (high order bit = 0) it is an
       error signaled by the Unknown Message Type Status Code.

       If the Message Type is >= 0x8000 (high order bit = 1) it is
       silently discarded.
 

Any value of Message type(error for <0x8000,discard for >=0x8000) causes LDP message malformed, then which values
are right for message type?

Valdis.Kletnieks@vt.edu wrote:

On Tue, 07 Mar 2000 18:23:20 +0800, jinglin <jinglin@263.net>  said:
> I cannot understand the meaning of the words:
>"    2.  LSR1 determines whether it will play the active or passive role
>          in session establishment by comparing addresses A1 and A2 as
>          unsigned integers.  If A1 > A2, LSR1 plays the active role;
>          otherwise it is passive.  "

> I want to know what kind of address of A1&A2, IP address or TCP port
> No.? why the role is determined by the size of A1 &A2?

I don't know what A1/A2 are, but a IP/port tuple sounds like a good
guess (*PLEASE* read the draft to see if I am right).  This would have
the property that the tuples represending the two ends of the connection
would be almost guaranteed to be different (ignoring the boundary
condition of connecting a port to itself).

A1 and A2 are both almost certainly the same *size* as in "number
of bits used to represent them".  What is being compared is the *value*
of the two addresses.  mlps needs a fast way to determin which will
be the active/passive role.  Whichever has the higher value address
becomes active.  If these were telephones, we'd say "compare the two
phone numbers as integers, whichever has the higher number acts
as the active end".

                                Valdis Kletnieks
                                Operating Systems Analyst
                                Virginia Tech

--------------9DC3CB82921335E77ED19B46-- From owner-ietf-outbound Tue Mar 14 10:41:13 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA01290 for ietf-outbound.10@ietf.org; Tue, 14 Mar 2000 10:40:04 -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 ESMTP id KAA29856 for ; Tue, 14 Mar 2000 10:36:58 -0500 (EST) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12UtNI-0005Gy-00; Tue, 14 Mar 2000 15:36:48 +0000 Date: Tue, 14 Mar 2000 15:36:45 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Lars-Erik Jonsson cc: rohc@CDT.LUTH.SE, ietf@ietf.org Subject: Re: [rohc] draft-ace-robust-hc-01.txt In-Reply-To: <000c01bf8dc9$b8cf4ec0$76b08496@e00008639f5da.epl.ericsson.se> 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, 14 Mar 2000, Lars-Erik Jonsson wrote: [while discussing http://38.197.106.103/draft-ace-robust-hc-01.txt - standard boilerplate at top; patent note right at the other end of the document.] > >btw, shouldn't the 'Intellectual Property Considerations' section be > >up top in the 'Status of this Memo' section? > > Is there a "rule" for that?? If there isn't, there should be; putting all the IPR/status material in one place would avoid giving the possible impression that potential IPR problems were intended be snuck past readers - and IPR problems can affect status. (NFS, anyone?) At least, that's IMO. cc'ing to ietf general for an Official Opinion on this; Declare It All Up Front seems entirely sensible to me. (Fred? Scott?) L. > In, for example, the ROCCO draft, there has been a statement section about IPR > since september because it was requested when ROCCO was presented for the first > time in Oslo. This section has been (and still is) in the end of the document > and I have heard no complains about it. Please let us all know if this is not > good!! > > What I think is a more important question than where to put it is what must be > said in such IPR sections. The reason for having them is that we want to know > about IPR "problems" and have the possibility to avoid solutions that are not > "free" (or is there other reasons?). What should be stated by those having IPR > to make such solutions considerable anyway??? > > Regards! > /Lars-Erik > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ PGP From owner-ietf-outbound Tue Mar 14 23:31:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA19488 for ietf-outbound.10@ietf.org; Tue, 14 Mar 2000 23:30:03 -0500 (EST) Received: from smtp.263.net ([202.96.44.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19291 for ; Tue, 14 Mar 2000 23:29:29 -0500 (EST) Received: from 263.net (unknown [202.112.109.83]) by smtp.263.net (Postfix) with ESMTP id 73E361C3DF151; Tue, 14 Mar 2000 16:25:00 +0800 (CST) Message-ID: <38CDF6AC.FD8EC25C@263.net> Date: Tue, 14 Mar 2000 16:22:04 +0800 From: jinglin X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls , ietf@ietf.org Subject: Problem about LDP Message type 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 saw the following sentences in the draft(draft-ietf-mpls-ldp-06.txt): "" An LDP Message is malformed if: - The Message Type is unknown. If the Message Type is < 0x8000 (high order bit = 0) it is an error signaled by the Unknown Message Type Status Code. If the Message Type is >= 0x8000 (high order bit = 1) it is silently discarded. Any value of Message type(error for <0x8000,discard for >=0x8000) causes LDP message Type unknown, then which values are known for message type? From owner-ietf-outbound Wed Mar 15 18:31:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA22552 for ietf-outbound.10@ietf.org; Wed, 15 Mar 2000 18:30: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 ESMTP id SAA19907 for ; Wed, 15 Mar 2000 18:22:01 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id PAA18572; Wed, 15 Mar 2000 15:21:13 -0800 (PST) Date: Wed, 15 Mar 2000 15:21:13 -0800 (PST) From: "James P. Salsman" Message-Id: <200003152321.PAA18572@shell9.ba.best.com> To: www-html@W3.ORG Subject: Re: device upload update Cc: ietf@ietf.org X-Loop: ietf@ietf.org > The addendum claims that input devices "shouldn't be visible in > the markup" -- a position that would require the user of a web-based > OCR application to select a scanner over a camera for each page of > text, while a user of a teleconferencing application would need to > select a camera over a scanner for each photo. Actually, it's worse than that. If the HTML working group chair's suggestion of using was used for both device input and filestore file upload, then the browser operator would have to choose between the filesystem and all the appropriate devices each time. That could get tedious, and impede applications (such as conferencing or spoken language instruction) that would go much smoother if a default were specified. Does anyone think that suggestion is good user interface design? Is there any doubt that the W3C specifications are omitting the proper solution for such applications? It's no wonder that the browser vendors haven't followed the spec that way for device upload. Cheers, James From owner-ietf-outbound Fri Mar 17 03:15:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA21981 for ietf-outbound.10@ietf.org; Fri, 17 Mar 2000 03:11:25 -0500 (EST) Received: from server.jad.net ([202.134.2.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20809 for ; Fri, 17 Mar 2000 03:07:52 -0500 (EST) Received: from oke.com (cf-isrlab7.comp.nus.edu.sg [137.132.85.181]) by server.jad.net (8.9.2/8.9.2) with ESMTP id QAA33817; Fri, 17 Mar 2000 16:07:59 +0700 (JAVT) (envelope-from rms46@oke.com) Sender: ibrahim@server.jad.net Message-ID: <38D1E7B3.F62DBBE6@oke.com> Date: Fri, 17 Mar 2000 16:07:15 +0800 From: "Rahmat M. Samik-Ibrahim" Reply-To: rms46.oke.com@vlsm.org Organization: VLSM-TJT X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: MILIS IETF Subject: Mbone question: the multicast addresses 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: Sorry, I could not find an answer or a pointer through http://www.ietf.org/meetings/multicast.html My provider said that it supports mbone, but only enable it on demand for specific addresses. Therefore, could anyone please inform me the multicast group addresses of the coming 47th IETF? thanks, -- - Rahmat M. Samik-Ibrahim -- VLSM-TJT -- http://rms46.vlsm.org/ - 2000:Year of the Information Snooper Highway - CathyGuisewite 25Feb From owner-ietf-outbound Sat Mar 18 02:11:03 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA26043 for ietf-outbound.10@ietf.org; Sat, 18 Mar 2000 02:10:05 -0500 (EST) Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22854 for ; Sat, 18 Mar 2000 02:06:25 -0500 (EST) Received: from kaipara.live.com (mg134-015.ricochet.net [204.179.134.15]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id XAA14007 for ; Fri, 17 Mar 2000 23:04:41 -0800 (PST) Message-Id: <4.3.1.20000317225851.00b12a60@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 17 Mar 2000 23:00:12 -0800 To: ietf@ietf.org From: Ross Finlayson Subject: An interesting new use for DNS :-) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org FYA: Seen on the web http://www.tbtf.com/blog/2000-03-12.html#6 Ross. From owner-ietf-outbound Sat Mar 18 12:20:58 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA08595 for ietf-outbound.10@ietf.org; Sat, 18 Mar 2000 12:20:02 -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 ESMTP id MAA08058 for ; Sat, 18 Mar 2000 12:18:17 -0500 (EST) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp (Exim 3.12 #7) id 12WMri-0007h1-00; Sat, 18 Mar 2000 17:18:18 +0000 Received: from [209.21.28.84] (helo=nma.com) by dfw-mmp3.email.verio.net with esmtp (Exim 3.12 #7) id 12WMrh-0004tC-00; Sat, 18 Mar 2000 17:18:18 +0000 Message-ID: <38D3BA9B.F00AB9C@nma.com> Date: Sat, 18 Mar 2000 09:19:23 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Ross Finlayson CC: ietf@ietf.org Subject: Re: An interesting new use for DNS :-) References: <4.3.1.20000317225851.00b12a60@shell7.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 Ross Finlayson wrote: > FYA: Seen on the web > > http://www.tbtf.com/blog/2000-03-12.html#6 > > Ross. This article is an example on how to distribute DeCSS via DNS. The article goes on to a "right thing to do", which is rounded up by the following argument: Therefore, if the RIAA, the DVDCCA, or the MPAA attempt to sue the owner, he countersues for exactly the same reason, saying that they weren't even authorized to know what he was posting. If their suit is valid, then so it his, and contrariwise. Which is misleading IMO because possession of stolen property can be proven by a simple search warrant. RIAA, the DVDCCA, or the MPAA can easily get a search warrant, get the evidence and sue. Also, IMO we should value privacy for what it is worth, not only for what it is used. Anyone is entitled to privacy rights, even if a criminal or the RIAA. Once we begin to try to justify the means by pointing out a nice goal, then we easily justify Hitler and Stalin also. Goals can be very nice and look good on paper and speeches, but getting there by ignoring basic rights is not a way to get there. BTW, by citing Hitler, I hope to end this thread ;-) Cheers, Ed Gerck From owner-ietf-outbound Sat Mar 18 14:50:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA06429 for ietf-outbound.10@ietf.org; Sat, 18 Mar 2000 14:50:02 -0500 (EST) Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04647 for ; Sat, 18 Mar 2000 14:44:36 -0500 (EST) Received: from [213.1.162.254] (helo=k2m5z5) by carbon.btinternet.com with smtp (Exim 2.05 #1) id 12WP8w-00053q-00 for ietf@ietf.org; Sat, 18 Mar 2000 19:44:15 +0000 From: Steve To: ietf@ietf.org; Subject: Don't Miss This...... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: Date: Sat, 18 Mar 2000 19:44:15 +0000 X-Loop: ietf@ietf.org Have you registered your URL at V21.CO.UK yet ? This is the newest Search Engine to hit the net. Do you have a banner advertising your site? The first 5000 advert orders received will be processed FREE OF CHARGE. Check it out NOW..... Webmaster@v21.co.uk From owner-ietf-outbound Sat Mar 18 16:22:01 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA08645 for ietf-outbound.10@ietf.org; Sat, 18 Mar 2000 16:20:03 -0500 (EST) Received: from hearno.cyberware.co.uk (hearno.cyberware.co.uk [194.74.221.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05048 for ; Sat, 18 Mar 2000 16:10:30 -0500 (EST) Received: from portable (dial7.cyberware.co.uk [62.172.180.74]) by hearno.cyberware.co.uk (8.9.1b+Sun/8.7.2) with SMTP id VAA29393 for ; Sat, 18 Mar 2000 21:10:11 GMT Message-Id: <3.0.6.32.20000318211028.007bb310@pop.cyberware.co.uk> X-Sender: andy@pop.cyberware.co.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sat, 18 Mar 2000 21:10:28 +0000 To: ietf@ietf.org From: Andy Fletcher Subject: Spammer is history ... Re: Don't Miss This...... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org Just had a message back from netfusion.co.uk who hosted the site. The site has now been killed off. They responded to my mail and killed the site within 10 minutes. Wish all ISPs were as quick :-) The offender posted via btinternet and I got the usual autoresponder message from them. Andy Netfusion message follows... -------------- Hi Andy Thanks for letting us know. Our terms and conditions are very clear with relation to spamming and the clients account has been terminated. Please don't hesitate to contact us should you have any further problems. =============================================== If you need to reply to this message please do so enclosing any past correspondence, your username and domain name. =============================================== Best Wishes, helpdesk@webfusion.co.uk http://www.webfusion.co.uk -------------------- From owner-ietf-outbound Sat Mar 18 17:31:47 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA04238 for ietf-outbound.10@ietf.org; Sat, 18 Mar 2000 17:30:04 -0500 (EST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00753 for ; Sat, 18 Mar 2000 17:22:19 -0500 (EST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id RAA18224 for ; Sat, 18 Mar 2000 17:16:31 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA0TL9Et; Sat Mar 18 17:16:25 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf@ietf.org; Sat, 18 Mar 2000 17:21:55 -0500 Received: from pcswb.newbridge.com ([138.120.245.138]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA1A0; Sat, 18 Mar 2000 17:21:53 -0500 Message-Id: <4.3.1.2.20000318101128.00a896e0@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 18 Mar 2000 17:20:33 -0500 To: Jianbo Huang From: "Scott W Brim" Subject: Re: Re: Critically compare the congestion control on TCP/IP and ATM Cc: ietf@ietf.org In-Reply-To: <4.2.0.58.20000309201102.00968450@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 20:31 03/09/2000 +0800, Jianbo Huang wrote: >Dear Sir/Madam, > >generally speaking, TCP/IP is equal to the transport and network layer >in the OSI model, and it seems that the ATM works on the Data Link Layer >(?). They serve different function in the OSI model. Through they all >have congestion control facility, how to compare mechanism in different >layer? Both are protocol suites. The ATM protocol suite actually includes not just the ATM layer protocol ("ATM") but lots more including a layer 4 reliable transport mechanism. Each has control signaling at multiple layers. Just compare the pieces of each that provide similar functionality. From owner-ietf-outbound Mon Mar 20 13:01:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA19012 for ietf-outbound.10@ietf.org; Mon, 20 Mar 2000 13:00:03 -0500 (EST) Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16599 for ; Mon, 20 Mar 2000 12:54:50 -0500 (EST) Received: from cci-209150226205.clarityconnect.net (HELO pcswb.yahoo.com) (209.150.226.205) by smtp.mail.yahoo.com with SMTP; 20 Mar 2000 09:54:49 -0800 X-Apparently-From: Message-Id: <4.3.1.2.20000320124132.00a90140@pop.mail.yahoo.com> X-Sender: ncc1701v@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 20 Mar 2000 12:53:19 -0500 To: ietf@ietf.org From: Scott Brim Subject: Radisson <-> Saville?? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org We have a two-room suite at the Radisson in Adelaide. My wife has decided she'd like a full kitchen. The Saville Park Suites have that but don't have any rooms letf. If you have a suite there and would like to swap for one at the Radisson (https://www.radisson.com/adelaideau/ -- closer to the convention centre but more expensive) let me know, please, and we can see what we can talk the hotels into. Thanks ... Scott -- Scott Brim +1.607.280.4000 __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-ietf-outbound Tue Mar 21 10:23:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA19728 for ietf-outbound.10@ietf.org; Tue, 21 Mar 2000 10:20:02 -0500 (EST) Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17618 for ; Tue, 21 Mar 2000 10:14:27 -0500 (EST) Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.9.3+Sun/8.8.6) with ESMTP id HAA11507; Tue, 21 Mar 2000 07:14:20 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id HAA15970 for ; Tue, 21 Mar 2000 07:14:19 -0800 (PST) Date: Tue, 21 Mar 2000 07:14:19 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200003211514.HAA15970@jackson.cs.ucsb.edu> To: ietf@ietf.org, rms46.oke.com@vlsm.org Subject: Re: Mbone question: the multicast addresses X-Loop: ietf@ietf.org >>Sorry, I could not find an answer or a pointer through >> >> http://www.ietf.org/meetings/multicast.html >> >>My provider said that it supports mbone, but only enable it on demand >>for specific addresses. Therefore, could anyone please inform me the >>multicast group addresses of the coming 47th IETF? Chan 1 audio 224.0.1.11/21010 Chan 1 video 224.0.1.12/61010 Whiteboard 224.0.1.13/41010 Chan 2 audio 224.0.1.14/21020 Chan 2 video 224.0.1.15/61020 I included ports too... also just advertised the sessions from UCSB... will be up until the Adelaide folks get their connectivity working. -Kevin From owner-ietf-outbound Tue Mar 21 11:30:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA15844 for ietf-outbound.10@ietf.org; Tue, 21 Mar 2000 11:30:03 -0500 (EST) Received: from mailserver.taqua.com ([209.130.192.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15434 for ; Tue, 21 Mar 2000 11:28:48 -0500 (EST) Received: from gaurang [192.168.102.224] by mailserver.taqua.com (SMTPD32-5.05) id A31E1A8010C; Tue, 21 Mar 2000 11:28:14 -0500 Reply-To: From: "Gaurang Kalyanpur" To: Subject: SIP phones Date: Tue, 21 Mar 2000 10:31:10 -0600 Message-ID: <003701bf9352$de07fcd0$e066a8c0@taquatx.com> 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.00.2919.6600 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I am looking for a SIP phone (physical unit) or a SIP user agent (Software driven). Does anybody know where I can buy one. I would prefer a physical unit, but a software emulation is also an option. Thanks GK From owner-ietf-outbound Tue Mar 21 16:00:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA27768 for ietf-outbound.10@ietf.org; Tue, 21 Mar 2000 16:00:02 -0500 (EST) Received: from acmey.gatech.edu (IDENT:gte600f@acmey.gatech.edu [130.207.165.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25285 for ; Tue, 21 Mar 2000 15:51:50 -0500 (EST) Received: from localhost (gte600f@localhost) by acmey.gatech.edu (8.9.2/8.9.2) with ESMTP id PAA00953 for ; Tue, 21 Mar 2000 15:51:45 -0500 (EST) Date: Tue, 21 Mar 2000 15:51:45 -0500 (EST) From: Anshuman Sharma To: ietf@ietf.org Subject: SLP v2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org Does anyone have anything on SLPv2 in terms of implementations apart from the one that's done by Sun and is on the main page of the forum. Also, any probable experiments that have been conducted in regard to scalability or security and their results. Anshuman --------------------------------------------------- "time and space are modes by which we think...... | they are not the conditions in which we live." | | ~~Einstein | --------------------------------------------------- Anshuman Sharma Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gte600f@prism.gatech.edu anshu@abraxis.com From owner-ietf-outbound Tue Mar 21 21:30:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA29597 for ietf-outbound.10@ietf.org; Tue, 21 Mar 2000 21:30:03 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27080 for ; Tue, 21 Mar 2000 21:23:55 -0500 (EST) Received: from paris.mds.local (user-2ivf7qn.dialup.mindspring.com [165.247.159.87]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA18814; Tue, 21 Mar 2000 21:23:55 -0500 (EST) Received: from berlin (berlin.mds.local [192.168.1.4]) by paris.mds.local (8.8.7/8.8.7) with SMTP id VAA08378; Tue, 21 Mar 2000 21:23:46 -0500 Message-ID: <00f001bf93a5$aec92d10$0401a8c0@mds.local> From: "Paul E. Jones" To: , References: <003701bf9352$de07fcd0$e066a8c0@taquatx.com> Subject: Re: SIP phones Date: Tue, 21 Mar 2000 21:23:58 -0500 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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit A few manufacturers are listed here: http://www.packetizer.com/sip/sip_links.html Paul ----- Original Message ----- From: "Gaurang Kalyanpur" To: Sent: Tuesday, March 21, 2000 11:31 AM Subject: SIP phones > > I am looking for a SIP phone (physical unit) or a SIP user agent (Software > driven). Does anybody know where I can buy one. I would prefer a physical > unit, but a software emulation is also an option. > > Thanks > GK > From owner-ietf-outbound Thu Mar 23 12:52:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA06464 for ietf-outbound.10@ietf.org; Thu, 23 Mar 2000 12:50:01 -0500 (EST) Received: from mailhost.metro-optix.com ([63.91.47.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03961 for ; Thu, 23 Mar 2000 12:41:35 -0500 (EST) Received: by mailhost.axa100.am.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 11:37:57 -0600 Message-ID: From: David Wang To: "'ietf@ietf.org'" Subject: How Many Routing Tables Date: Thu, 23 Mar 2000 11:37:56 -0600 Return-Receipt-To: David Wang 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 Dear Friends, This may be a silly question but I never found a clear answer form a book or a standard. A router is running BGP4, OSPF and RIP at the same time. How many routing tables(or forwarding tables) this router has? I think there should be only one table produced by all the protocols and used by the router to route every packet through the router, but I am not sure. Can somebody help get an answer ? Thank you very much David From owner-ietf-outbound Thu Mar 23 13:40:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA26416 for ietf-outbound.10@ietf.org; Thu, 23 Mar 2000 13:40:03 -0500 (EST) Received: from escape.com (xelsed@escape.com [198.6.71.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24708 for ; Thu, 23 Mar 2000 13:36:01 -0500 (EST) Received: from localhost (xelsed@localhost) by escape.com (8.9.0/8.9.1) with ESMTP id NAA10061; Thu, 23 Mar 2000 13:36:18 -0500 (EST) Date: Thu, 23 Mar 2000 13:36:16 -0500 (EST) From: Jeremy To: David Wang cc: "'ietf@ietf.org'" Subject: Re: How Many Routing Tables In-Reply-To: Message-ID: Disposition-Notification-To: Jeremy Deutsch MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org I think it may actually have 5 one for each protocal Plus the Static. BTW whats the CPU time on that thing like? -jeremyy On Thu, 23 Mar 2000, David Wang wrote: > Dear Friends, > > This may be a silly question but I never found a clear answer form a book or > a standard. > > A router is running BGP4, OSPF and RIP at the same time. How many routing > tables(or forwarding tables) this router has? I think there should be only > one table produced by all the protocols and used by the router to route > every packet through the router, but I am not sure. Can somebody help get an > answer ? > > Thank you very much > David > > From owner-ietf-outbound Thu Mar 23 13:50:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA00558 for ietf-outbound.10@ietf.org; Thu, 23 Mar 2000 13:50:03 -0500 (EST) Received: from reduno.reduno.com.mx (153-50.reduno.com.mx [200.4.153.50] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25050 for ; Thu, 23 Mar 2000 13:36:51 -0500 (EST) Received: from localhost by reduno.reduno.com.mx (8.9.2/8.9.2) with ESMTP id MAA15636; Thu, 23 Mar 2000 12:31:13 -0600 (CST) Date: Thu, 23 Mar 2000 12:31:13 -0600 (CST) From: HUGO ZAMORA LOPEZ To: David Wang cc: "'ietf@ietf.org'" Subject: Re: How Many Routing Tables In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org David, The router has only one routing table which use to propagate the best route to another routers base on adminstrative distance when you are running several routing protocols for the same networks. Regards. Hugo On Thu, 23 Mar 2000, David Wang wrote: > Dear Friends, > > This may be a silly question but I never found a clear answer form a book or > a standard. > > A router is running BGP4, OSPF and RIP at the same time. How many routing > tables(or forwarding tables) this router has? I think there should be only > one table produced by all the protocols and used by the router to route > every packet through the router, but I am not sure. Can somebody help get an > answer ? > > Thank you very much > David > > From owner-ietf-outbound Thu Mar 23 14:00:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA04276 for ietf-outbound.10@ietf.org; Thu, 23 Mar 2000 14:00:04 -0500 (EST) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29116 for ; Thu, 23 Mar 2000 13:46:42 -0500 (EST) Received: from ti.bbn.com (TI.BBN.COM [128.89.26.180]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id NAA01688; Thu, 23 Mar 2000 13:46:37 -0500 (EST) Message-Id: <3.0.3.32.20000323134800.00e35270@po2.bbn.com> X-Sender: welsh@po2.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 23 Mar 2000 13:48:00 -0500 To: David Wang , "'ietf@ietf.org'" From: Bob Welsh Subject: Re: How Many Routing Tables In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org We use one routing table, but multiple forwarding tables, depending on TOS. Bob At 11:37 AM 3/23/2000 -0600, David Wang wrote: >Dear Friends, > >This may be a silly question but I never found a clear answer form a book or >a standard. > >A router is running BGP4, OSPF and RIP at the same time. How many routing >tables(or forwarding tables) this router has? I think there should be only >one table produced by all the protocols and used by the router to route >every packet through the router, but I am not sure. Can somebody help get an >answer ? > >Thank you very much >David > > From owner-ietf-outbound Thu Mar 23 14:20:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA11830 for ietf-outbound.10@ietf.org; Thu, 23 Mar 2000 14:20:02 -0500 (EST) Received: from tea.uk.pw.com (tea.uk.pw.com [193.131.169.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09089 for ; Thu, 23 Mar 2000 14:11:31 -0500 (EST) From: damjan.gautschi@ch.pwcglobal.com Received: by tea.uk.pw.com; id TAA10606; Thu, 23 Mar 2000 19:06:08 GMT Received: from olive.uk.pw.com(10.44.240.46) by tea.uk.pw.com via smap (4.1) id xma009637; Thu, 23 Mar 00 19:05:40 GMT Received: from intleursmtp10.uk.pw.com by olive.uk.pw.com (PMDF V5.1-12 #U3018) with SMTP id <0FRW00HAK2EXV2@olive.uk.pw.com> for ietf@ietf.org; Thu, 23 Mar 2000 19:06:45 +0000 (GMT) Received: by intleursmtp10.uk.pw.com(Lotus SMTP MTA v1.2 hotfix6 (702.3 8-27-1998)) id 802568AB.00691A71 ; Thu, 23 Mar 2000 19:08:00 +0000 Date: Thu, 23 Mar 2000 20:03:37 +0100 Subject: Re: How Many Routing Tables To: "'ietf@ietf.org'" Message-id: <802568AB.0069FD9F.00@intleursmtp10.uk.pw.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline X-Lotus-FromDomain: EMEA-CH@INTL X-Loop: ietf@ietf.org Hy David - It depends! If you're redistributing RIP into OSPF, and into BGP, fine. If not, I don't see what you're doing. You'll have one for every protocol. Assuming it is a Cisco router, the router will have a BGP table (build on BGP messages), a OSPF table with the redistributed RIP routes and the OSPF entries. Note that the router needs to be redistributing in order that OSPF understands RIP messages. Every routing protocol (RIP being vector, OSPF being link state) has it's own "language", way of exchanging information. This info is carried in the fields in the packets. An OSPF packet doesn't equal a RIP packet. Thus also the database will be different. Besides the algorithm is not the same. RIP defines 2 message types: Request and Response. "Uses a routing algorithm in which routers periodically send routing updates to all neighbours by broadcasting their entire route tables. Next hop information relevant for routing. OSPF has link state advertisements that it put's into the topology database. When database is synchronised with neighbour, only changes will be sent. Metric cost relevant for routing. I hope this helps Sincerly, Damjan ---------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. From owner-ietf-outbound Thu Mar 23 20:10:34 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA12747 for ietf-outbound.10@ietf.org; Thu, 23 Mar 2000 20:10:03 -0500 (EST) Received: from terra.post1.com (terra.pobox.org.sg [203.116.23.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09877 for ; Thu, 23 Mar 2000 20:02:50 -0500 (EST) Received: from engineer ([203.116.56.208]) by terra.post1.com (8.9.3/8.9.3) with SMTP id AAA74174; Fri, 24 Mar 2000 00:55:52 GMT Reply-To: From: "Gabriel Lim" To: "Yan" , "William" , "Vernon Cornelius" , "Tylor" , "Tony Teoh" , "Steven Chan" , "Stanley" , "Siah Song" , "Sherhan" , "Shaun Ng" , "Seng Kian See Tow" , "Samantha Chong" , "Ryan" , "Roy Koh CC" , "Rjpaper@Pacific. Net. Sg" , "Reflecto" , "Randy_Ter" , "Peter Teng" , "Peter Foo" , "Patrick Lee" , "Ong Yang Peng" , "Noraini" , "Nicholas Ling" , "Nicholas Lim" , "Nhliang" , "Ming Chen" , "Mike James" , "Mike" , "Mickey Xu" , "Miak" , "Mervin Toh" , "Lisa Sam" , "Lincoln Chia" , "Leander Lim" , "Lau Jit Khoon" , "Kishore Babu" , "Khairil Anwar Bin Musa" , "Kenny" , "Kenneth Tang Meng Hwee" , "Ken Lim" , "Kelvin" , "Kelvin" , "Jonathan Ong" , "Jonathan Lee Hin Wah" , "Jon_Yeo" , "John Tan" , "John Pielsticker" , "Joel Mah" , "Jerome" , "Jennifer" , "Jeffrey Yau" , "Jeffrey Phang" , "Jeffrey" , "Jay" , "Jason Le Borgne" , "Isaac" , "Ietf" , "Ho Fang Meng" , "Helen Chung" , "Goh Thiang Hock" , "Gerard" , "Gan Willis" , "Felix Low" , "Eugene Lim" , "Enoch_Chng" , "Edwin Gan" , "Edward Leong" , "EAKACHAI PUTTAMASUTTAYASONTI" , "Denny Tjong(GST)" , "Denny Den" , "Dennis" , "Deepak Melwani/SIN/Lotus" , "David (CHARGINGSTAR)" , "Daniel Tan" , "Dancertm" , "Cosmic" , "Chua Dunstan" , "Choo Kwok Yong" , "Chin Yu Chung" , "Cai Jinze" , "Bunny" , "Bernard" , "Benny Hew" , "Benny" , "Anson Anson" , "Andre Crozier" , "Alicia Chong" , "Alex" , "Aaron Christopher Yap" , "Aaron Ann" Subject: My International VoiceMail & Fax no Date: Fri, 24 Mar 2000 08:57:11 +0800 Message-ID: <001101bf952b$e322bc20$d03874cb@engineer.cananex> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Hi All, An update for everybody. In case any of u are overseas, and would like to contact me.....I can be contacted at the following numbers by voice mail & fax, my code is 4275 Singapore toll-free number: 1800 260 1555 Hong Kong toll-free number: 852 3002 7155 Taiwan toll-free number : 080 061 555 Korea toll-free number : 080 778 1555 Malaysia toll-free number : 1800 387 155 USA toll-free number : 1877 651 1555 Regards Gabriel From owner-ietf-outbound Fri Mar 24 07:50:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA29572 for ietf-outbound.10@ietf.org; Fri, 24 Mar 2000 07:50:02 -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 ESMTP id HAA27240 for ; Fri, 24 Mar 2000 07:42:16 -0500 (EST) Received: from classic (modemcable245.48-201-24.que.mc.videotron.net [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.9.3) with ESMTP id HAA00229 for ; Fri, 24 Mar 2000 07:41:05 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <4.2.2.20000324073346.02a51e38@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 24 Mar 2000 07:44:05 -0500 To: ietf@ietf.org From: Marc Blanchet Subject: tarballs of drafts,rfcs and agendas 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, rfcs and wg-bof agendas of the ietf meeting. The internet-drafts and rfcs tarballs are always available at the normos site and are updated daily. The wg-bof agendas tarball for the upcoming meeting is generated a few days before the ietf meeting. Here are the urls: internet-drafts (19M, tar-gzipped): http://www.normos.org/ietf/draft.tgz ftp://ftp.normos.org/ietf/draft.tgz rfcs (32M, tar-gzipped): http://www.normos.org/ietf/rfc.tgz ftp://ftp.normos.org/ietf/rfc.tgz Agendas (37K, tar-gzipped): http://www.normos.org/ietf/ietf-agendas.tgz ftp://ftp.normos.org/ietf/ietf-agendas.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 Fri Mar 24 08:30:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA14119 for ietf-outbound.10@ietf.org; Fri, 24 Mar 2000 08:30:03 -0500 (EST) Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13199 for ; Fri, 24 Mar 2000 08:27:05 -0500 (EST) Received: from [62.104.201.6] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.13 #3) id 12YU7E-0003CL-00 for ietf@ietf.org; Fri, 24 Mar 2000 14:27:04 +0100 Received: from [62.104.198.141] (helo=canna.atm-bb.de) by mx0.freenet.de with esmtp (Exim 3.13 #3) id 12YU7E-0004TP-00 for ietf@ietf.org; Fri, 24 Mar 2000 14:27:04 +0100 Received: from adieball by canna.atm-bb.de with local (Exim 3.12 #1 (Debian)) id 12YV7U-0000CT-00 for ; Fri, 24 Mar 2000 14:31:24 +0000 Date: Fri, 24 Mar 2000 14:31:24 +0000 To: ietf@ietf.org Subject: AAL 2 Informations Message-ID: <20000324143124.A407@canna.atm-bb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.9i From: Andre Dieball X-Loop: ietf@ietf.org Hello Whre can I get more informations about AAL 1, 2, 3/4 and 5? I have special interrest in AAL2 used in UMTS networks. Thanks Mit freundlichen Gruessen Best regards Andre Dieball ---------------------------------------------------------------------------- MobilCOM City LINE GmbH phone: +49 4331 69-1229 Network Operations fax : +49 4331 69-2260 Hollerstr. 126 em@il: a.dieball@mobilcom.de 24782 Buedelsdorf http://www.mobilcom.de GERMANY ---------------------------------------------------------------------------- From owner-ietf-outbound Fri Mar 24 13:51:39 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA06274 for ietf-outbound.10@ietf.org; Fri, 24 Mar 2000 13:50:02 -0500 (EST) Received: from mail.nbn.net (root@nbn.net [207.51.86.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02670 for ; Fri, 24 Mar 2000 13:40:00 -0500 (EST) Received: from server-1 (dial2-22.nbn.net [208.139.67.64]) by mail.nbn.net (8.9.3/8.9.3) with SMTP id NAA26780 for ; Fri, 24 Mar 2000 13:39:55 -0500 Message-ID: <38DBB85D.5678@nbn.net> Date: Fri, 24 Mar 2000 13:47:57 -0500 From: Betsy Brennan Reply-To: bbrennan@nbn.net X-Mailer: Mozilla 3.04 (Win95; U) MIME-Version: 1.0 To: ietf@ietf.org Subject: Switches Vs Routers and EGP vs IPG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Can you help me understand when a router would be used instead of a switch? Also, I need to understand the differences between EGP and IGP. I know that IGP is for exchanging network info within a network and EGP is for use between Autonomous systems, but what other differences are there? Respectfully, Betsy B. From owner-ietf-outbound Fri Mar 24 14:20:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA17579 for ietf-outbound.10@ietf.org; Fri, 24 Mar 2000 14:20:03 -0500 (EST) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16346 for ; Fri, 24 Mar 2000 14:16:57 -0500 (EST) Received: from hpindfca.cup.hp.com (hpindfca.cup.hp.com [15.13.108.63]) by palrel1.hp.com (Postfix) with ESMTP id C978A4B5; Fri, 24 Mar 2000 11:16:52 -0800 (PST) Received: (from ftc@localhost) by hpindfca.cup.hp.com (8.8.6 (PHNE_17135)/8.7.3) id KAA12891; Fri, 24 Mar 2000 10:54:24 -0800 (PST) From: Frank Chen Message-Id: <200003241854.KAA12891@hpindfca.cup.hp.com> Subject: Re: My International VoiceMail & Fax no ??? !!!!! ??? To: gbrl@POBOX.ORG.SG Date: Fri, 24 Mar 2000 10:54:24 -0800 (PST) Cc: intldiv@EastAsia.com.sg, ix@letterbox.com, vern@PACIFIC.NET.SG, mosche@catcha.com, tteoh@tm.net.my, stevenyy@PACIFIC.NET.SG, stancondor@PACIFIC.NET.SG, tks_27@yahoo.com, sherhan@swiftech.net.sg, shaunng@SINGNET.COM.SG, skseetow@sgp.ra.rockwell.com, sam.chong@cananex.com.sg, gidragon@cyberway.com.sg, chengchu@SINGNET.COM.SG, rjpaper@PACIFIC.NET.SG, reflecto@PACIFIC.NET.SG, randyter@SINGNET.COM.SG, denglk@pc.jaring.my, ethefoo@HOTMAIL.COM, lpatrick@SINGNET.COM.SG, yangpeng.ong@cananex.com.sg, noraini.jasman@cananex.com.sg, nicko@mbox3.singnet.com.sg, nicholas.lsf@PACIFIC.NET.SG, nhliang@pd.jaring.my, prettyboy4sex@yahoo.com, nahelam@HOTMAIL.COM, mlimks@hadco.com, mickey_xu@yahoo.com, miak@PACIFIC.NET.SG, mervin.toh@cananex.com.sg, samlexus@PACIFIC.NET.SG, demonte@SINGNET.COM.SG, leander@tm.net.my, laujk@plexus.com.sg, kishorebabu@sis.com.sg, khairil.musa@cananex.com.sg, kenwin@PACIFIC.NET.SG, lathander@PACIFIC.NET.SG, seamlk@pc.jaring.my, fmradio05@HOTMAIL.COM, ksing@cyberway.com.sg, ace654@HOTMAIL.COM, immaculate76@PACIFIC.NET.SG, jon_yeo@HOTMAIL.COM, johntan@sis.com.sg, texassy@gammy.com, myh77@PACIFIC.NET.SG, lamorte@SINGNET.COM.SG, jennifer@euyansang.com.sg, jeffreyyau@PACIFIC.NET.SG, jeffpsy@yahoo.com, ekingtam@pop.singnet.com.sg, jaylengjai@yahoo.com, gay_nino_ny17@HOTMAIL.COM, izzz@PACIFIC.NET.SG, ietf@ietf.org, fenming@mbox4.singnet.com.sg, "Helen@pobox.org.sg"@hpindfca.cup.hp.com In-Reply-To: <001101bf952b$e322bc20$d03874cb@engineer.cananex> from Gabriel Lim at Mar "24," 2000 "08:57:11" am X-Mailer: ELM [$Revision: 1.17.214.3 $] 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 Hi Gabriel, and others in the list, I really hate to send this message to you. But, I have no choice. --------------------- IMPORTANT NOTICE ----------------------------- Your email did NOT reach to FRANK CHEN in TAIWAN. I will NOT forward your email to FRANK CHEN in TAIWAN, either. --------------------- IMPORTANT NOTICE ----------------------------- Please read the following, Thanks. I am NOT the Frank Chen in Taiwan which you guys wanted. Very Often, I receive emails that you really want to send to Frank Chen in Taiwan. This is very anonying to me. - If you use HPDESK to send mails: If you are looking for Frank Chen in Taiwan, when you select FRANK CHEN, Please DON'T just enter "FRANK CHEN". There are more than one Frank Chen in HP. Please choose FRANK CHEN/TAIWAN but not Frank Chen/Cupertino or Frank Chen/Ft. Collins for information to GCIPO. - If you use UNIX mailing system: Please DON'T use "ftc@cup.hp.com", this is not the Frank Chen in Taiwan. Please use "FRANK_CHEN@HP-Taiwan-om1.om.hp.com". I am the Frank Chen at Cupertino, California USA. Thanks for your help in advance Frank Chen Cupertino, California, U.S.A ftc@cup.hp.com Telnet 1-447-2615 > Hi All, > > An update for everybody. In case any of u are overseas, and would like > to contact me.....I can be contacted at the following numbers by voice mail > & fax, my code is 4275 > > Singapore toll-free number: 1800 260 1555 > Hong Kong toll-free number: 852 3002 7155 > Taiwan toll-free number : 080 061 555 > Korea toll-free number : 080 778 1555 > Malaysia toll-free number : 1800 387 155 > USA toll-free number : 1877 651 1555 > > Regards > Gabriel > > From owner-ietf-outbound Fri Mar 24 14:40:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA24902 for ietf-outbound.10@ietf.org; Fri, 24 Mar 2000 14:40:03 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23897 for ; Fri, 24 Mar 2000 14:37:07 -0500 (EST) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Fri, 24 Mar 2000 14:35:47 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H3HTD93Y; Fri, 24 Mar 2000 14:35:34 -0500 Received: from americasm01.nt.com (bcarsa3b.ca.nortel.com [47.14.97.55]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNNLV1JG; Fri, 24 Mar 2000 14:35:32 -0500 Sender: "Baghdad Barka" Message-ID: <38DBC384.2EAD4BAF@americasm01.nt.com> Date: Fri, 24 Mar 2000 14:35:32 -0500 From: "Baghdad Barka" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: bbrennan@nbn.net CC: ietf@ietf.org Subject: Re: Switches Vs Routers and EGP vs IPG References: <38DBB85D.5678@nbn.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 Betsy Brennan wrote: > > Can you help me understand when a router would be used instead of a > switch? > > Also, I need to understand the differences between EGP and IGP. > I know that IGP is for exchanging network info within a network > and EGP is for use between Autonomous systems, but what other > differences are there? > Respectfully, Betsy B. To Betsy Brennan: Historically,The use of routers in existing LAN infrastructures has led the adoption of IP addressing schemes in which multiple IP subnets exist within the LAN. Packets can only be forwarded between subnets by a routing function (Router capabilities), not by LAN switches. Replacing routers by switches would require that the IP addresses of all the stations on the LAN be changed so that all the addresses are on a single subnet identity, which is not a good approche ............. Unlike switches, most routers offer a range of access controls which can form a useful part of the entreprise LAN security policy. A fully switches LAN which has no routing in it would have to operate as a single large broadcast domain. In the other hand switch reduces shared media contention .... And we do have MLS " multilayer switch" that combines the performance of switching with the intelligence of routing. There are several different approches to "Multilayer Switch" from - Cut-Thru Layer 2 "CTL2" - Packet-by-Packet Layer 3 "PPL3" - and even some Layer 4 solutions. Switching at Layer 3 is actually routing .. I hope that will help you Betsy to make a diffrence between router and switch .... Baghdad Barka From owner-ietf-outbound Fri Mar 24 17:50:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA03741 for ietf-outbound.10@ietf.org; Fri, 24 Mar 2000 17:50:02 -0500 (EST) Received: from itc-eml2.ta.israel.madge.com (at.lannet.com [194.90.94.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01421; Fri, 24 Mar 2000 17:42:37 -0500 (EST) Received: by ITC-EML2 with Internet Mail Service (5.5.2650.21) id ; Sat, 25 Mar 2000 00:41:31 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA6140B993D@ITC-EML2> From: Dan Romascanu To: "Wijnen, Bert (Bert)" , mibs@ops.ietf.org, snmpv3@lists.tis.com, iesg@ietf.org, ietf@ietf.org Subject: RE: Last Call: Textual Conventions for Additional High Capacity D ata Types to Proposed Standard Date: Sat, 25 Mar 2000 00:41:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org The following text at Section 6 is too restrictive in a manner that is both unnecessary and not consistent with other text (e.g. at Section 5) The following textual conventions are defined to support unsigned 64-bit data types for HC-RMON [HC-RMON]. I suggest replacing this text by the following: The following textual conventions are defined to support unsigned 64-bit data types for MIBs such as the HC-RMON MIB [HC-RMON]. The reason is that other MIB documents should feel free to use the Textual Conventions described by this document freely, until a permanent solution is standardized as part of some evolution of the SNMP SMI. Regards, Dan > -----Original Message----- > From: Wijnen, Bert (Bert) [SMTP:bwijnen@lucent.com] > Sent: Mon March 20 2000 20:26 > To: mibs@ops.ietf.org; snmpv3@lists.tis.com > Subject: FW: Last Call: Textual Conventions for Additional High > Capacity D ata Types to Proposed Standard > > Just in case someone missed it. > > Bert > > > ---------- > > From: The IESG[SMTP:iesg-secretary@ietf.org] > > Reply To: iesg@ietf.org > > Sent: Monday, March 20, 2000 4:43 PM > > Cc: kzm@cisco.com > > Subject: Last Call: Textual Conventions for Additional High Capacity > > Data Types to Proposed Standard > > > > > > The IESG has received a request to consider Textual Conventions for > > Additional High Capacity Data Types as > > a Proposed Standard. This has been reviewed in the IETF but is not the > > product of an IETF Working Group. > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by April 18, 2000. > > > > Files can be obtained via > > http://www.ietf.org/internet-drafts/draft-kzm-hcdata-types-05.txt > > > > From owner-ietf-outbound Fri Mar 24 19:00:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA28849 for ietf-outbound.10@ietf.org; Fri, 24 Mar 2000 19:00:05 -0500 (EST) Received: from mail.nbn.net (root@nbn.net [207.51.86.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28724 for ; Fri, 24 Mar 2000 18:59:44 -0500 (EST) Received: from server-1 (dial1-24.nbn.net [208.139.67.18]) by mail.nbn.net (8.9.3/8.9.3) with SMTP id SAA27582 for ; Fri, 24 Mar 2000 18:59:39 -0500 Message-ID: <38DC0348.6E89@nbn.net> Date: Fri, 24 Mar 2000 19:07:36 -0500 From: Betsy Brennan Reply-To: bbrennan@nbn.net X-Mailer: Mozilla 3.04 (Win95; U) MIME-Version: 1.0 To: ietf@ietf.org Subject: IPG vs EPG 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 need to understand the differences between EGP and IGP. I know that IGP is for exchanging network info within a network and EGP is for use between Autonomous systems, but what other differences are there? Respectfully, Betsy B. From owner-ietf-outbound Sun Mar 26 06:12:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA10339 for ietf-outbound.10@ietf.org; Sun, 26 Mar 2000 06:10:02 -0500 (EST) Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07425 for ; Sun, 26 Mar 2000 06:02:16 -0500 (EST) Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45]) by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id NAA17834 for ; Sun, 26 Mar 2000 13:02:08 +0200 (MET DST) Message-Id: <200003261102.NAA17834@bettina.informatik.uni-bremen.de> X-Sender: jo@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 X-Priority: 1 (Highest) Date: Sun, 26 Mar 2000 13:00:01 +0200 To: ietf@ietf.org From: Joerg Ott Subject: Security Advice Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org Folks, it may be a *very* good idea for everyone in Adelaide NOT TO LEAVE ANY ITEMS OF VALUE VISIBLY IN THE HOTEL ROOM not even for short periods of time (such as breakfast or so). When returning from the reception tonight, Carsten found his hotel room at the Hindley Parkroyal broken into and his camera, passport, PCMCIA cards, and numerous other electrical devices had disappeared. Fortunately, he took his laptop to the reception so "the worst case could be avoided". Needless to say that the hotel room door apparently did not provide any protection whatsoever and was opened in a way that was not even noticeable when returning. As he did not walk around with any of the stolen items in public on his way to or out of the room, the knowledge about valuables in the room must have been obtained in a different way (e.g., by someone who had access to the room). Due to all of this, he is currently lacking connectivity which is why I am sending out this warning to you on his behalf. This mail is not intended to provoke any longer discussion on the list, we just like to share this "experience" with you so that it won't happen to anybody else. Joerg From owner-ietf-outbound Mon Mar 27 05:01:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA09312 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 05:00:03 -0500 (EST) Received: from sasi.com (sasi.com [164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08314 for ; Mon, 27 Mar 2000 04:58:00 -0500 (EST) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id PAA00356; Mon, 27 Mar 2000 15:28:46 +0530 (IST) Received: from hpd11.sasi.com ([10.0.16.11]) by sasi.com; Mon, 27 Mar 2000 15:28:44 +0000 (IST) Received: from localhost (ramp@localhost) by hpd11.sasi.com (8.9.1/8.9.1) with ESMTP id PAA02345; Mon, 27 Mar 2000 15:34:08 +0530 (IST) Date: Mon, 27 Mar 2000 15:34:08 +0530 (IST) From: R G Ramprasad Torati To: ietf@ietf.org cc: MPLS@UU.NET Subject: Regarding MPLS simulation....! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org Hi, I heard that some simulation part is available for MPLS combined with OSPF/ISIS floods. Can anybody please tell where can I get it. If U have a one, please send it to me. And I want to know is there any MPLS simulation results available. If any of U have these, please let me know. Thanks in advance Ramp From owner-ietf-outbound Mon Mar 27 05:30:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA21165 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 05:30:02 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17569; Mon, 27 Mar 2000 05:20:16 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA07586; Mon, 27 Mar 2000 12:20:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA24258; Mon, 27 Mar 2000 12:20:03 +0200 Date: Mon, 27 Mar 2000 12:20:03 +0200 Message-Id: <200003271020.MAA24258@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dromasca@lucent.com CC: bwijnen@lucent.com, mibs@ops.ietf.org, snmpv3@lists.tis.com, iesg@ietf.org, ietf@ietf.org In-reply-to: <15F58915DF84D311AC7D0090279AA6140B993D@ITC-EML2> (message from Dan Romascanu on Sat, 25 Mar 2000 00:41:21 +0200) Subject: Re: Last Call: Textual Conventions for Additional High Capacity D ata Types to Proposed Standard References: <15F58915DF84D311AC7D0090279AA6140B993D@ITC-EML2> X-Loop: ietf@ietf.org >>>>> Dan Romascanu writes: [...] Dan> I suggest replacing this text by the following: Dan> The following textual conventions are defined to support unsigned Dan> 64-bit data types for MIBs such as the HC-RMON MIB [HC-RMON]. Dan> The reason is that other MIB documents should feel free to use Dan> the Textual Conventions described by this document freely, until Dan> a permanent solution is standardized as part of some evolution of Dan> the SNMP SMI. I think that MIB authors should think at least twice before using these TCs. There is text in the ID on the limitations and implications of using these TCs. The abstract actually says that these TCs may be deprecated in the future (when a long term solution is in place). So taking your comment into account, I suggest the following replacement text: : The following textual conventions are defined to support unsigned : 64-bit data types for MIBs such as the HC-RMON MIB [HC-RMON]. The : textual conventions represent a limited short-term solution and : may be deprecated as a long term solution is defined and deployed : to replace it. This is basically a repetition of the warning which is already in the TC definitions. But I think it is important so that people really think twice whether they want to use these TCs. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-ietf-outbound Mon Mar 27 08:11:38 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA23182 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 08:10:02 -0500 (EST) Received: from perq.cac.washington.edu (dhcp-32-252.ietf.connect.com.au [169.208.32.252]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19936 for ; Mon, 27 Mar 2000 08:01:52 -0500 (EST) Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.9.3/8.9.3) with ESMTP id WAA08121 for ; Mon, 27 Mar 2000 22:31:51 +0930 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Mon, 27 Mar 2000 22:31:50 +0930 (CST) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: ietf@ietf.org Subject: WaveLAN Bronze and IETF wireless? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org I hate to bug the list with this, but I suspect I may not be the only one with this problem. I brought with me to IETF 47 a WaveLAN Turbo Bronze wireless card which I use daily in my office at home, but it doesn't appear to work with the WaveLAN-Silver-based wireless net here (the LEDs flash briefly as though it's not finding the named network). Other folks here with Bronze cards also find they don't work, regardless of laptop or OS. So are we bronze toters just out of luck? Is it a known thing that WaveLAN Bronze cards are not interoperable with Silver? Anything to be done to fix? Thanks for any info, - RL "Bob" From owner-ietf-outbound Mon Mar 27 08:20:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA27269 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 08:20:02 -0500 (EST) Received: from itc-eml2.ta.israel.madge.com (at.lannet.com [194.90.94.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22288; Mon, 27 Mar 2000 08:07:49 -0500 (EST) Received: by ITC-EML2 with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 15:06:36 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA61412811E@ITC-EML2> From: Dan Romascanu To: "'Juergen Schoenwaelder'" , dromasca@lucent.com Cc: bwijnen@lucent.com, mibs@ops.ietf.org, snmpv3@lists.tis.com, iesg@ietf.org, ietf@ietf.org Subject: RE: Last Call: Textual Conventions for Additional High Capacity D ata Types to Proposed Standard Date: Mon, 27 Mar 2000 15:06:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org Juergen, I agree with your proposal. Thanks for the comment. Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [SMTP:schoenw@ibr.cs.tu-bs.de] > Sent: Mon March 27 2000 12:20 > To: dromasca@lucent.com > Cc: bwijnen@lucent.com; mibs@ops.ietf.org; snmpv3@lists.tis.com; > iesg@ietf.org; ietf@ietf.org > Subject: Re: Last Call: Textual Conventions for Additional High > Capacity D ata Types to Proposed Standard > > > >>>>> Dan Romascanu writes: > > [...] > > Dan> I suggest replacing this text by the following: > > Dan> The following textual conventions are defined to support unsigned > Dan> 64-bit data types for MIBs such as the HC-RMON MIB [HC-RMON]. > > Dan> The reason is that other MIB documents should feel free to use > Dan> the Textual Conventions described by this document freely, until > Dan> a permanent solution is standardized as part of some evolution of > Dan> the SNMP SMI. > > I think that MIB authors should think at least twice before using > these TCs. There is text in the ID on the limitations and implications > of using these TCs. The abstract actually says that these TCs may be > deprecated in the future (when a long term solution is in place). So > taking your comment into account, I suggest the following replacement > text: > > : The following textual conventions are defined to support unsigned > : 64-bit data types for MIBs such as the HC-RMON MIB [HC-RMON]. The > : textual conventions represent a limited short-term solution and > : may be deprecated as a long term solution is defined and deployed > : to replace it. > > This is basically a repetition of the warning which is already in the > TC definitions. But I think it is important so that people really > think twice whether they want to use these TCs. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 > > From owner-ietf-outbound Mon Mar 27 16:30:44 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA24859 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 16:30:02 -0500 (EST) Received: from roam.psg.com (dhcp-193-29.ietf.connect.com.au [169.208.193.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24823 for ; Mon, 27 Mar 2000 16:26:26 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Zh1e-0000lE-00; Tue, 28 Mar 2000 06:56:18 +0930 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "RL 'Bob' Morgan" Cc: ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? References: Message-Id: Date: Tue, 28 Mar 2000 06:56:18 +0930 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > I brought with me to IETF 47 a WaveLAN Turbo Bronze wireless card which I > use daily in my office at home, but it doesn't appear to work with the > WaveLAN-Silver-based wireless net here (the LEDs flash briefly as though > it's not finding the named network). as far as a bunch of us can tell, the access points are poorly configured (in many ways), and the wireless folk are not motivated to make things work which they do not sell. randy From owner-ietf-outbound Mon Mar 27 17:30:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA25679 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 17:30:03 -0500 (EST) Received: from mailhost.metro-optix.com ([63.91.47.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25627 for ; Mon, 27 Mar 2000 17:27:47 -0500 (EST) Received: by mailhost.axa100.am.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 16:23:50 -0600 Message-ID: From: David Wang To: "'ietf@ietf.org'" Subject: How IP Packets are encapsulation in DS1 Signal Date: Mon, 27 Mar 2000 16:23:42 -0600 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 Dear Friends, There are plenty of books describing how IP packets are encapsulated in Ethernet frames or ATM cells, or PPP frames. But I have not seen a book describe how IP packets be carried in DS1, Fractional DS1, DS3, Fractional DS3 signals. These signals are point to point, byte streams. I think IP packets should be directly put on those TDM time slots and send from one end point to the other. Can somebody answer my question or point out a book, web site, or a standard so I can find the answer. Thanks David From owner-ietf-outbound Mon Mar 27 18:50:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA27241 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 18:50:02 -0500 (EST) Received: from voojagig.3ui.com (static-8-15.ietf.connect.com.au [169.208.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27158 for ; Mon, 27 Mar 2000 18:40:08 -0500 (EST) From: amlan@geektown.net Received: from localhost (amlan@localhost) by voojagig.3ui.com (8.9.3/8.9.3) with ESMTP id HAA00870; Tue, 28 Mar 2000 07:38:30 +0800 X-Authentication-Warning: voojagig.3ui.com: amlan owned process doing -bs Date: Tue, 28 Mar 2000 07:38:30 +0800 (SGT) X-Sender: amlan@voojagig.3ui.com Reply-To: a.saha@ACM.ORG To: "RL 'Bob' Morgan" cc: ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? In-Reply-To: Message-ID: Phone: +65.9689.5832 (M) +65.468.8157 (H) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org [ From: rlmorgan@washington.edu ][ Date: 22:31 (+0930), Mar 27, 2000 ] > > I hate to bug the list with this, but I suspect I may > not be the only one with this problem. > > I brought with me to IETF 47 a WaveLAN Turbo Bronze > wireless card which I use daily in my office at home, > but it doesn't appear to work with the > WaveLAN-Silver-based wireless net here (the LEDs > flash briefly as though it's not finding the named > network). Other folks here with Bronze cards also > find they don't work, regardless of laptop or OS. > So are we bronze toters just out of luck? Is it a > known thing that WaveLAN Bronze cards are not > interoperable with Silver? Anything to be done to > fix? > > Thanks for any info, > > - RL "Bob" The Wavelan site does mention that once the cards' firwares are upgraded to version 6.0, which in this case is so, the base stations (aka access points) also need to be upgraded; however once they (access points) are upgraded, the version 4.0 of the firmware in the older(bronze) cards will NOT work with the upgraded base stations. I am stuck with a so-called "old" card as well. :( /amlan. From owner-ietf-outbound Mon Mar 27 20:20:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA28500 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 20:20:02 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28442 for ; Mon, 27 Mar 2000 20:16:02 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id RAA13475; Mon, 27 Mar 2000 17:09:21 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 28 Mar 2000 01:15:55 UT Received: from spud.ascend.com (spud [192.207.23.51]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id RAA29323; Mon, 27 Mar 2000 17:15:54 -0800 (PST) Received: from amalis (mh-ppp-028.ascend.com [134.112.245.38]) by spud.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id RAA11233; Mon, 27 Mar 2000 17:15:51 -0800 (PST) Message-Id: <4.2.2.20000327200953.024aa530@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 27 Mar 2000 20:15:12 -0500 To: a.saha@ACM.ORG From: "Andrew G. Malis" Subject: Re: WaveLAN Bronze and IETF wireless? Cc: "RL 'Bob' Morgan" , ietf@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org For another data point ... I had the identical problem with my bronze card (flash briefly). I got one of the silver cards and plugged it in, and it just worked with my existing Bronze 4.0 driver and application. I didn't need to update either the silver card firmware or the driver SW. This is on NT 4.0. Cheers, Andy ------- At 07:38 AM 3/28/00 +0800, amlan@geektown.net wrote: >[ From: rlmorgan@washington.edu ][ Date: 22:31 (+0930), Mar 27, 2000 ] > > > I brought with me to IETF 47 a WaveLAN Turbo Bronze > > wireless card which I use daily in my office at home, > > but it doesn't appear to work with the > > WaveLAN-Silver-based wireless net here (the LEDs > > flash briefly as though it's not finding the named > > network). Other folks here with Bronze cards also > > find they don't work, regardless of laptop or OS. > > So are we bronze toters just out of luck? Is it a > > known thing that WaveLAN Bronze cards are not > > interoperable with Silver? Anything to be done to > > fix? > >The Wavelan site does mention that once the cards' firwares are >upgraded to version 6.0, which in this case is so, the base >stations (aka access points) also need to be upgraded; however >once they (access points) are upgraded, the version 4.0 of the >firmware in the older(bronze) cards will NOT work with the >upgraded base stations. > >I am stuck with a so-called "old" card as well. :( > >/amlan. From owner-ietf-outbound Mon Mar 27 20:40:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA28909 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 20:40:02 -0500 (EST) Received: from roam.psg.com (dhcp-193-29.ietf.connect.com.au [169.208.193.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28835 for ; Mon, 27 Mar 2000 20:34:21 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Zktc-00011x-00; Tue, 28 Mar 2000 11:04:16 +0930 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Andrew G. Malis" Cc: ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? References: <4.2.2.20000327200953.024aa530@alpo.casc.com> Message-Id: Date: Tue, 28 Mar 2000 11:04:16 +0930 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > I had the identical problem with my bronze card (flash briefly). I got one > of the silver cards and plugged it in, and it just worked with my existing > Bronze 4.0 driver and application. I didn't need to update either the > silver card firmware or the driver SW. This is on NT 4.0. a number of folk spent some time swaping (recently flashed) cards. silver was the only thing that worked. and this was since shiller and gang disabled the rogue access point in hall b at about 21:00 last eve. randy From owner-ietf-outbound Mon Mar 27 21:40:30 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA29866 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 21:40:03 -0500 (EST) Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29842 for ; Mon, 27 Mar 2000 21:38:34 -0500 (EST) Received: from cathil ([12.72.131.224]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000328023756.GSVV24417.mtiwmhc23.worldnet.att.net@cathil> for ; Tue, 28 Mar 2000 02:37:56 +0000 Reply-To: From: "Robin Uyeshiro" To: Subject: 10/100 pcmcia card Date: Mon, 27 Mar 2000 16:40:33 -1000 Message-ID: <000001bf985e$fe22bb20$0902fea9@cathil> 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.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit I bought a 10/100 ethernet PCMCIA card in Adelaide that, it turns out, I don't need. If anyone would like to take it off my hands, make me an offer. I bought it for Australian $149. From owner-ietf-outbound Mon Mar 27 22:00:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA01070 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 22:00:02 -0500 (EST) Received: from trampoline.thunk.org (IDENT:root@dhcp-193-107.ietf.connect.com.au [169.208.193.107]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00946 for ; Mon, 27 Mar 2000 21:52:42 -0500 (EST) Received: (from tytso@localhost) by trampoline.thunk.org (8.9.3/8.9.3) id VAA06413; Mon, 27 Mar 2000 21:53:28 -0500 Date: Mon, 27 Mar 2000 21:53:28 -0500 Message-Id: <200003280253.VAA06413@trampoline.thunk.org> To: rlmorgan@washington.edu CC: ietf@ietf.org In-reply-to: (rlmorgan@washington.edu) Subject: Re: WaveLAN Bronze and IETF wireless? From: tytso@mit.edu Phone: (781) 391-3464 References: X-Loop: ietf@ietf.org The current theory is that the wavelan access points are configred not to fall back to 2mbps operation. Matt Blaze reported that he had a 2 mbps Silver card that didn't work. According to Angelos, if there is a single 2 mbps card in the radio network, the entire network falls back to 2 mbps, which is why there is a configuration option to lock the network at 11 mbps. So for those people who are reporting that their cards don't work, it's important to list not just whether you have a Bronze, Silver, or Gold card (which referrs to how strong crypto is used in the rather pointless WEP system, since everyone shares the same key), but also whether you have a 2mbps or 11mps card. Apparently if you have a Bronze 11mbps card, it *will* work, and if you have a Silver 2mpbs card, it won't. If someone has datapoints to prove or disprove this particular theory, do speak up, but from what we were able to determine last night, this seems to be what's going on. - Ted From owner-ietf-outbound Mon Mar 27 22:10:07 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA01295 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 22:10:02 -0500 (EST) Received: from voojagig.3ui.com (static-240-15.ietf.connect.com.au [169.208.240.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01003 for ; Mon, 27 Mar 2000 21:57:34 -0500 (EST) From: amlan@geektown.net Received: from localhost (amlan@localhost) by voojagig.3ui.com (8.9.3/8.9.3) with ESMTP id KAA00700; Tue, 28 Mar 2000 10:55:51 +0800 X-Authentication-Warning: voojagig.3ui.com: amlan owned process doing -bs Date: Tue, 28 Mar 2000 10:55:50 +0800 (SGT) X-Sender: amlan@voojagig.3ui.com Reply-To: a.saha@ACM.ORG To: Randy Bush cc: "Andrew G. Malis" , ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? In-Reply-To: Message-ID: Phone: +65.9689.5832 (M) +65.468.8157 (H) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org [ From: randy@psg.com ][ Date: 11:04 (+0930), Mar 28, 2000 ] > a number of folk spent some time swaping (recently > flashed) cards. silver was the only thing that > worked. I do not think just swapping will help. I have one of the old cards. And after updating my "old" bronze card (nothing is written on top of it, so I presume it must be bronze as it was bought long time back and is 2 Mbps max) with the version 6 of the firmware and installing the new drivers, my "old" card seems to be working just fine. By the way, this is under Linux (kernel 2.2.5). /amlan. From owner-ietf-outbound Mon Mar 27 22:20:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA01463 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 22:20: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 ESMTP id WAA01426 for ; Mon, 27 Mar 2000 22:18:06 -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 4B2391E014; Mon, 27 Mar 2000 22:18:08 -0500 (EST) Received: from smb.research.att.com (secure.research.att.com [135.207.25.14]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id WAA24886; Mon, 27 Mar 2000 22:18:05 -0500 (EST) Received: by smb.research.att.com (Postfix, from userid 54047) id A6891ACAA9; Tue, 28 Mar 2000 12:48:06 +0930 (CST) Received: from smb.research.att.com (localhost [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id A3339ABBED; Tue, 28 Mar 2000 12:48:01 +0930 (CST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Randy Bush Cc: "Andrew G. Malis" , ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Mar 2000 12:48:00 +0930 Sender: smb@research.att.com Message-Id: <20000328031806.A6891ACAA9@smb.research.att.com> X-Loop: ietf@ietf.org In message , Randy Bush writes: >> I had the identical problem with my bronze card (flash briefly). I got one >> of the silver cards and plugged it in, and it just worked with my existing >> Bronze 4.0 driver and application. I didn't need to update either the >> silver card firmware or the driver SW. This is on NT 4.0. > >a number of folk spent some time swaping (recently flashed) cards. silver >was the only thing that worked. > And I've been using a Gold Turbo card without any trouble. --Steve Bellovin From owner-ietf-outbound Mon Mar 27 22:40:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA02692 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 22:40:03 -0500 (EST) Received: from mail.neocom.net (ns2.neocom.net [205.160.234.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01627 for ; Mon, 27 Mar 2000 22:29:38 -0500 (EST) Received: from me (MAX1-41.neocom.net [63.161.80.140]) by mail.neocom.net (8.9.3/8.9.3) with SMTP id WAA20863 for ; Mon, 27 Mar 2000 22:29:34 -0500 Received: by localhost with Microsoft MAPI; Mon, 27 Mar 2000 22:28:21 -0500 Message-ID: <01BF983B.C1D94F80.matt@neocom.net> From: Matt Ashburn Reply-To: "matt@neocom.net" To: "ietf@ietf.org" Subject: RE: 10/100 pcmcia card Date: Mon, 27 Mar 2000 22:28:18 -0500 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 guess you could always sell it to another geek on GeekSwap (http://geekswap.com). -----Original Message----- From: Robin Uyeshiro [SMTP:ruyeshiro@adtech-inc.com] Sent: Monday, March 27, 2000 9:41 PM To: ietf@ietf.org Subject: 10/100 pcmcia card I bought a 10/100 ethernet PCMCIA card in Adelaide that, it turns out, I don't need. If anyone would like to take it off my hands, make me an offer. I bought it for Australian $149. From owner-ietf-outbound Mon Mar 27 22:50:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA02815 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 22:50:02 -0500 (EST) Received: from voojagig.3ui.com (static-240-15.ietf.connect.com.au [169.208.240.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02631 for ; Mon, 27 Mar 2000 22:33:41 -0500 (EST) From: amlan@geektown.net Received: from localhost (amlan@localhost) by voojagig.3ui.com (8.9.3/8.9.3) with ESMTP id LAA00788; Tue, 28 Mar 2000 11:31:56 +0800 X-Authentication-Warning: voojagig.3ui.com: amlan owned process doing -bs Date: Tue, 28 Mar 2000 11:31:56 +0800 (SGT) X-Sender: amlan@voojagig.3ui.com Reply-To: a.saha@ACM.ORG To: tytso@mit.edu cc: rlmorgan@washington.edu, ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? In-Reply-To: <200003280253.VAA06413@trampoline.thunk.org> Message-ID: Phone: +65.9689.5832 (M) +65.468.8157 (H) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org [ From: tytso@mit.edu ][ Date: 21:53 (-0500), Mar 27, 2000 ] > If someone has datapoints to prove or disprove this > particular theory, do speak up, but from what we were > able to determine last night, this seems to be what's > going on. > > - Ted Well, seems like I am able to prove otherwise, unless of course the upgrade of the firmware has upgraded the capability of my card from 2 Mbps to 11 Mbps as well ;-). I am able to be on the network with my card which when I bought it about a year ago was labeled as 2 Mbps. /amlan. From owner-ietf-outbound Mon Mar 27 23:00:08 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA02998 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 23:00:01 -0500 (EST) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02950 for ; Mon, 27 Mar 2000 22:58:47 -0500 (EST) Received: from dhcp-192-150.ietf.connect.com.au ([166.45.6.251]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTP id <01JNJM44LSSO8ZDWEI@shoe.reston.mci.net> for ietf@ietf.org; Mon, 27 Mar 2000 22:58:47 EST Date: Tue, 28 Mar 2000 13:28:42 +0930 From: Paul Krumviede Subject: Re: WaveLAN Bronze and IETF wireless? In-reply-to: <200003280253.VAA06413@trampoline.thunk.org> To: tytso@MIT.EDU Cc: ietf@ietf.org Message-id: <767383058.954250122@dhcp-192-150.ietf.connect.com.au> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b12 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7BIT --On Monday, 27 March, 2000 21:53 -0500 tytso@MIT.EDU wrote: > > The current theory is that the wavelan access points are configred not > to fall back to 2mbps operation. Matt Blaze reported that he had a 2 > mbps Silver card that didn't work. According to Angelos, if there is > a single 2 mbps card in the radio network, the entire network falls back > to 2 mbps, which is why there is a configuration option to lock the > network at 11 mbps. i'm seeing at least some of the access points fall back to 2 Mbps, with both an 11 Mbps silver card and and a bronze turbo (5.5 Mbps?) card. i don't have a 2 mbps card. > So for those people who are reporting that their cards don't work, it's > important to list not just whether you have a Bronze, Silver, or Gold > card (which referrs to how strong crypto is used in the rather pointless > WEP system, since everyone shares the same key), but also whether you > have a 2mbps or 11mps card. Apparently if you have a Bronze 11mbps > card, it *will* work, and if you have a Silver 2mpbs card, it won't. > > If someone has datapoints to prove or disprove this particular theory, > do speak up, but from what we were able to determine last night, this > seems to be what's going on. the other issue last night was that at least one access point (Hall B) wasn't willing to communicate with the default router, although this seems to be working this morning. -paul From owner-ietf-outbound Mon Mar 27 23:20:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA03309 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 23:20:02 -0500 (EST) Received: from onoe2.sm.sony.co.jp (onoe@onoe2.sm.sony.co.jp [133.138.10.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03219 for ; Mon, 27 Mar 2000 23:14:38 -0500 (EST) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id NAA23838; Tue, 28 Mar 2000 13:14:27 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.9.3/8.8.8) id NAA04994; Tue, 28 Mar 2000 13:14:24 +0900 (JST) Date: Tue, 28 Mar 2000 13:14:24 +0900 (JST) From: Atsushi Onoe Message-Id: <200003280414.NAA04994@duplo.sm.sony.co.jp> To: tytso@mit.edu Cc: rlmorgan@washington.edu, ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? In-Reply-To: Your message of "Mon, 27 Mar 2000 21:53:28 -0500" <200003280253.VAA06413@trampoline.thunk.org> References: <200003280253.VAA06413@trampoline.thunk.org> X-Mailer: Cue version 0.6 (000327-2121/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii X-Loop: ietf@ietf.org > mbps Silver card that didn't work. According to Angelos, if there is > a single 2 mbps card in the radio network, the entire network falls back > to 2 mbps, It is not accurate. An 11Mbps card will still be able to communicate with an access point in 11Mbps if the signal strength is enough. But total network throughput will decrease since the communication between the access point ant the a 2Mbps card would occupy the radio for longer period. Atsushi Onoe From owner-ietf-outbound Mon Mar 27 23:30:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id XAA03472 for ietf-outbound.10@ietf.org; Mon, 27 Mar 2000 23:30:04 -0500 (EST) Received: from adk.gr (COREDUMP.CIS.UPENN.EDU [158.130.6.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03436 for ; Mon, 27 Mar 2000 23:29:28 -0500 (EST) Received: from dsl.cis.upenn.edu (localhost [127.0.0.1]) by adk.gr (8.9.3/8.9.3) with ESMTP id XAA19129; Mon, 27 Mar 2000 23:25:51 -0500 (EST) Message-Id: <200003280425.XAA19129@adk.gr> To: Atsushi Onoe Cc: tytso@mit.edu, rlmorgan@washington.edu, ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? In-reply-to: Your message of "Tue, 28 Mar 2000 13:14:24 +0900." <200003280414.NAA04994@duplo.sm.sony.co.jp> Date: Mon, 27 Mar 2000 23:25:51 -0500 From: "Angelos D. Keromytis" X-Loop: ietf@ietf.org In message <200003280414.NAA04994@duplo.sm.sony.co.jp>, Atsushi Onoe writes: > >It is not accurate. An 11Mbps card will still be able to communicate >with an access point in 11Mbps if the signal strength is enough. >But total network throughput will decrease since the communication >between the access point ant the a 2Mbps card would occupy the radio >for longer period. According to the Lucent documentation, a network with a mix of different cards will "operate at the highest common speed." That documentation is from last October or so (when the Turbo cards came out); since then, there have been about 4 revisions of the firmware, so things may have changed. -Angelos From owner-ietf-outbound Tue Mar 28 00:41:43 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA04702 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 00:40:03 -0500 (EST) Received: from adk.gr (dhcp-192-16.ietf.connect.com.au [169.208.192.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04649 for ; Tue, 28 Mar 2000 00:34:56 -0500 (EST) Received: from dsl.cis.upenn.edu (localhost [127.0.0.1]) by adk.gr (8.9.3/8.9.3) with ESMTP id AAA21205; Tue, 28 Mar 2000 00:28:12 -0500 (EST) Message-Id: <200003280528.AAA21205@adk.gr> X-Mailer: exmh version 2.0.2 2/24/98 To: Atsushi Onoe Cc: tytso@mit.edu, rlmorgan@washington.edu, ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? In-reply-to: Your message of "Tue, 28 Mar 2000 13:14:24 +0900." <200003280414.NAA04994@duplo.sm.sony.co.jp> Date: Tue, 28 Mar 2000 00:28:12 -0500 From: "Angelos D. Keromytis" X-Loop: ietf@ietf.org As a followup: it looks like Atsushi-san was correct. The statement in the Lucent documentation (about the network operating in the maximum common speed) apparently refers to each card-pair, and to the network in terms of token-acquisition latency. Thanks to the connect.com people for clearing this up. -Angelos From owner-ietf-outbound Tue Mar 28 01:10:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA05825 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 01:10: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 ESMTP id BAA05031 for ; Tue, 28 Mar 2000 01:01:10 -0500 (EST) Received: from dhcp-194-76.ietf.connect.com.au ("port 1764"@[169.208.194.76]) by a4.jck.com (PMDF V6.0-23 #40360) with ESMTPA id <0FS40049TBEKWM@a4.jck.com> for ietf@ietf.org; Tue, 28 Mar 2000 01:01:40 -0500 (EST) Date: Tue, 28 Mar 2000 01:00:47 -0500 From: John C Klensin Subject: Re: WaveLAN Bronze and IETF wireless? In-reply-to: <4.2.2.20000327200953.024aa530@alpo.casc.com> To: "Andrew G. Malis" Cc: ietf@ietf.org Message-id: <722507718.954205247@dhcp-194-76.ietf.connect.com.au> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b12 (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 Based on my observations and some discussions with the local supplier... There was a beacon-side problem yesterday that impacted (flash-updated) Bronze (and white) cards. They flashed some of the beacons last night, but the software they used didn't fix the problem. They flashed them again this morning, and Bronze and White cards at firmware v4.52 suddenly started working, local drivers permitting (the drivers that work with firmware version 3.x and earlier don't work with firmware version 4.x and 6.x). john --On Monday, March 27, 2000 20:15 -0500 "Andrew G. Malis" wrote: > For another data point ... > > I had the identical problem with my bronze card (flash > briefly). I got one of the silver cards and plugged it in, and > it just worked with my existing Bronze 4.0 driver and > application. I didn't need to update either the silver card > firmware or the driver SW. This is on NT 4.0. From owner-ietf-outbound Tue Mar 28 01:50:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA10459 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 01: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 ESMTP id BAA10263 for ; Tue, 28 Mar 2000 01:41:51 -0500 (EST) Received: from dhcp-194-76.ietf.connect.com.au ("port 1873"@[169.208.194.76]) by a4.jck.com (PMDF V6.0-23 #40360) with ESMTPA id <0FS4004AIDABWM@a4.jck.com> for ietf@ietf.org; Tue, 28 Mar 2000 01:42:21 -0500 (EST) Date: Tue, 28 Mar 2000 01:41:39 -0500 From: John C Klensin Subject: Re: WaveLAN Bronze and IETF wireless? To: "Andrew G. Malis" Cc: ietf@ietf.org Message-id: <724959538.954207699@dhcp-194-76.ietf.connect.com.au> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b12 (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 Correction... According to the vendor's tech folks, the overnight problem was ultimately that... * they assumed, or were told, that, if they were lending or selling a hugh number of cards, nothing would be on the system besides their (new, up-to-date) cards. Consequently, the beacons were configured to talk 11Mb, no matter what. * The 1 and 2 Mb cards don't do too well when spoken to at 11Mb. * Once they realized the problem and reconfigured the beacons to negotiate speed with the cards, Lucent cards at firmware version 4.52 (or maybe 4.x) and forward, and cards compatible with them, started working. There are obviously several lessons here which are left as an exercise. john From owner-ietf-outbound Tue Mar 28 03:50:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA18393 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 03:50:02 -0500 (EST) Received: from trampoline.thunk.org (IDENT:root@dhcp-194-141.ietf.connect.com.au [169.208.194.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18297 for ; Tue, 28 Mar 2000 03:39:33 -0500 (EST) Received: (from tytso@localhost) by trampoline.thunk.org (8.9.3/8.9.3) id DAA07383; Tue, 28 Mar 2000 03:40:39 -0500 Date: Tue, 28 Mar 2000 03:40:39 -0500 Message-Id: <200003280840.DAA07383@trampoline.thunk.org> To: ietf@ietf.org Subject: 47th IETF: IETF PGP Key Signing From: tytso@mit.edu Phone: (781) 391-3464 X-Loop: ietf@ietf.org It's come to my attention that there are a number of people who don't subscribe to IETF-Announce, but who are on the IETF mailing list (I didn't think this combination was common, but it does apparently happen), who didn't get the PGP Keysigning invitation. As a result, I'm resending it to the ietf mailing list, and my apologies to those who have seen it twice. I've included at the end of this message the list of PGP keys which I have received so far. If you don't see your key on this list, and you think you sent it to me, I would greatly appreciate it if you could resend it. Many thanks. P.S. Even though the original note asks that keys be sent to me by Monday night at midnight, due to this mixup (and a brain-damaged majordomo configuration on the IETF list), I will be accepted late keys. I would appreciate keys submitted before noon tomorrow, if at all possible. - Ted ----- Begin original message Once again, we will be holding a PGP Key signing party at the IETF meeting in Adelaide. We have been scheduled to meet at 10:30pm on the evening of Wednesday, March 29, 2000. 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 midnight on *Monday* of the week of the IETF meeting. Please include a subject line of "IETF PGP KEY". Sending your key to me before the IETF meeting is appreciated, since it reduces the number of keys that I have to collect during the meeting. (In fact, why don't you send me your key right now if you know will be attending, so you won't forget?) o By 6pm on Wednesday, you will be able to ftp a complete key ring from tsx-11.mit.edu with all of the keys that were submitted; it will be available at these URL's: http://web.mit.edu/tytso/www/ietf2.pgp http://web.mit.edu/tytso/www/ietf5.pgp (For PGP 2.x and PGP 5.x, respectively; the PGP 5.x keyring will be a superset of the PGP 2.x keyring.) 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 1024 0x7B7E0210 2000-03-15 Brian Stafford (Flexion) 1024 0xB673DC11 2000-02-18 Brian Stafford (OfficeLogic International Ltd.) 1024 0x562C2749 1998-03-09 Connect Registry System 1024 0xD25D8FCE 2000-02-28 Gianni Rossi 1024 0x24C27802 1999-03-21 Gregory Neil Shapiro 1024 0xA00E1563 1998-03-07 Gregory Neil Shapiro 1024 0xB11F733D 1997-08-05 John C Klensin 1024 0x81E92D91 1996-02-01 Mark Prior 1024 0x9A8F6A79 1998-07-05 MOMOSE Tsuyoshi 1024 0x4B1E2784 1997-06-13 Pete Resnick 1024 0x7D2ED788 1999-08-31 Richard Guy Briggs (gpg-lap) 1024 0x2115A82D 1997-09-22 Richard Guy Briggs [medsec] 1024 0x5A815C1F 1998-12-09 Robert M. Enger 2048 0xFDCFA047 1999-06-28 Robert M. Enger 1024 0x5A625B66 1999-07-04 Rosemarie Scheibler 1024 0xB0007189 1999-06-16 Scheibler Rosemarie (UC-PN/ECS4) 1024 0x16F4CCE9 1999-06-23 Sendmail Security 1024 0x19A20341 1995-02-17 Tero Kivinen 2048 0x7550C281 1996-04-23 Tero Kivinen 1024 0x2DE518A2 2000-01-04 Tim Shepard 1024 0x06EE4649 2000-03-13 Tim Shepard From owner-ietf-outbound Tue Mar 28 04:10:06 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA18635 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 04:10:02 -0500 (EST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18599 for ; Tue, 28 Mar 2000 04:05:28 -0500 (EST) Received: from basil.fokus.gmd.de (basil [193.175.132.64]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA16938 for ; Tue, 28 Mar 2000 11:04:09 +0200 (MET DST) Received: (from ntl@localhost) by basil.fokus.gmd.de (8.8.8/8.8.8) id LAA26846 for ietf@ietf.org; Tue, 28 Mar 2000 11:05:28 +0200 (MET DST) Date: Tue, 28 Mar 2000 11:05:28 +0200 From: Nguyen Tuong Long Le To: ietf@ietf.org Subject: Re: How Many Routing Tables Message-ID: <20000328110528.A26836@basil.fokus.gmd.de> References: <802568AB.0069FD9F.00@intleursmtp10.uk.pw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <802568AB.0069FD9F.00@intleursmtp10.uk.pw.com>; from damjan.gautschi@ch.pwcglobal.com on Thu, Mar 23, 2000 at 08:03:37PM +0100 X-Loop: ietf@ietf.org Just as a follow-up question: Can somebody tell me how many route entries there are in edge and core routers nowadays? Thanks, -- long On Thu, Mar 23, 2000 at 08:03:37PM +0100, damjan.gautschi@ch.pwcglobal.com wrote: > Hy David - It depends! > If you're redistributing RIP into OSPF, and into BGP, fine. > If not, I don't see what you're doing. You'll have one for every protocol. > Assuming it is a Cisco router, the router will have a BGP table (build on > BGP messages), a OSPF table with the redistributed RIP routes and the OSPF > entries. Note that the router needs to be redistributing in order that OSPF > understands RIP messages. Every routing protocol (RIP being vector, OSPF > being link state) has it's own "language", way of exchanging information. > This info is carried in the fields in the packets. An OSPF packet doesn't > equal a RIP packet. Thus also the database will be different. Besides the > algorithm is not the same. > RIP defines 2 message types: Request and Response. "Uses a routing > algorithm in which routers periodically send routing updates to all > neighbours by broadcasting their entire route tables. Next hop information > relevant for routing. > OSPF has link state advertisements that it put's into the topology > database. When database is synchronised with neighbour, only changes will > be sent. Metric cost relevant for routing. > > I hope this helps > > Sincerly, > > Damjan > ---------------------------------------------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. > > From owner-ietf-outbound Tue Mar 28 08:02:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA20336 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 08:00:01 -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 ESMTP id HAA20287 for ; Tue, 28 Mar 2000 07:50:55 -0500 (EST) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12ZvSM-0004Ww-00; Tue, 28 Mar 2000 13:50:50 +0100 Date: Tue, 28 Mar 2000 13:50:47 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: tytso@MIT.EDU cc: ietf@ietf.org Subject: Re: 47th IETF: IETF PGP Key Signing In-Reply-To: <200003280840.DAA07383@trampoline.thunk.org> 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, 28 Mar 2000 tytso@MIT.EDU wrote: > It's come to my attention that there are a number of people who don't > subscribe to IETF-Announce, but > who are on the IETF mailing list (I didn't think this combination was > common, but it does apparently happen), if workgroups didn't repeat relevant IETF-Announce information, it would happen less. > who didn't get the PGP Keysigning invitation. There are people on both lists not in Adelaide, and your invite requires turning up in Adelaide, so... I'd like to suggest that each IETF meet reuse a dedicated mailing list (physical-meet@ietf.org ?), so that those who are actually physically present/planning to be physically present can use that list to swap tips on wireless access/how to get your room broken into/keysigning parties and anything else that is you-have-to-be-there location-specific. L. Then I'd _really_ enjoy the lull in mailing list activity that a meeting brings. PGP From owner-ietf-outbound Tue Mar 28 09:51:01 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA21616 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 09:50:02 -0500 (EST) Received: from marcos.networkcs.com (marcos.networkcs.com [137.66.16.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21524 for ; Tue, 28 Mar 2000 09:42:48 -0500 (EST) Received: from us.networkcs.com (us.networkcs.com [137.66.11.15]) by marcos.networkcs.com (8.9.3/8.9.3) with ESMTP id IAA42978 for ; Tue, 28 Mar 2000 08:42:48 -0600 (CST) (envelope-from salo@us.networkcs.com) Received: (from salo@localhost) by us.networkcs.com (8.9.2/8.9.2) id IAA84644 for ietf@ietf.org; Tue, 28 Mar 2000 08:42:48 -0600 (CST) (envelope-from salo) Date: Tue, 28 Mar 2000 08:42:48 -0600 (CST) From: Tim Salo Message-Id: <200003281442.IAA84644@us.networkcs.com> To: ietf@ietf.org Subject: Privacy and IETF Document Access X-Loop: ietf@ietf.org I recently noticed that ftp.ietf.org requires the use of an e-mail address (well, ok, something that looks like an e-mail address) as a password for anonymous login. (see sample below) I suggest that: o The IETF, consistent with its traditional concern about network privacy, disable this feature and allow anonymous access to documents without requiring an e-mail-like password, o Explain why e-mail addresses are being collected from anonymous ftp users, and o Explain who has had access to the list of e-mail addresses. -tjs [Geez. This is the organization that (appropriately) declined to standardize wiretapping solutions, but collects information about everyone who accesses its documents???] % ftp ftp.ietf.org Connected to www2.ietf.org. 220 www2 NcFTPd Server (licensed copy) ready. Name (ftp.ietf.org:salo): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 530-You must supply a valid email address as your password. 530-For example, "mike@nirvana.ncemrsoft.com" is okay. 530 Login failed. ftp: Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 550 Login first, then I might let you do that. 421 Disconnecting you since you didn't login successfully within 15 seconds. ftp> From owner-ietf-outbound Tue Mar 28 10:40:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA22328 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 10:40:04 -0500 (EST) Received: from voojagig.3ui.com (dhcp-194-84.ietf.connect.com.au [169.208.194.84]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22228 for ; Tue, 28 Mar 2000 10:32:45 -0500 (EST) From: amlan@geektown.net Received: from localhost (amlan@localhost) by voojagig.3ui.com (8.9.3/8.9.3) with ESMTP id XAA01014; Tue, 28 Mar 2000 23:31:04 +0800 X-Authentication-Warning: voojagig.3ui.com: amlan owned process doing -bs Date: Tue, 28 Mar 2000 23:31:04 +0800 (SGT) X-Sender: amlan@voojagig.3ui.com Reply-To: a.saha@acm.org To: Tim Salo cc: ietf@ietf.org Subject: Re: Privacy and IETF Document Access In-Reply-To: <200003281442.IAA84644@us.networkcs.com> Message-ID: Phone: +65.9689.5832 (M) +65.468.8157 (H) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org [ From: salo@networkcs.com ][ Date: 08:42 (-0600), Mar 28, 2000 ] > I recently noticed that ftp.ietf.org requires the use > of an e-mail address (well, ok, something that looks > like an e-mail address) as a password for anonymous > login. (see sample below) > > I suggest that: > > o The IETF, consistent with its traditional concern > about > network privacy, disable this feature and allow > anonymous > access to documents without requiring an > e-mail-like password, I do not think this is really a concern because the system will accept "dumbo@fool.com" as a valid password email as well. /amlan. From owner-ietf-outbound Tue Mar 28 11:20:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA23044 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 11:20:02 -0500 (EST) Received: from arcc.or.ke (root@[212.49.87.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23002 for ; Tue, 28 Mar 2000 11:18:46 -0500 (EST) Received: from 199.2.222.254 ([199.2.222.150]) by arcc.or.ke (8.9.3/8.9) with SMTP id IAA29532 for ; Sun, 26 Mar 2000 08:48:09 +0300 (EAT) Date: Sun, 26 Mar 2000 08:48:09 +0300 (EAT) Message-Id: <200003260548.IAA29532@arcc.or.ke> X-Sender: musandu@199.2.222.254 X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org From: Musandu Subject: REQUEST FOR INTERNET RELATED ACADEMIC INFORMATION X-Loop: ietf@ietf.org I wish to request that any list member who has information regarding Advanced Degree Programs (e.g Doctorate Degrees) in any University that relates to Internet Engineering or the Internet in General, furnish me with such information. Especially degrees with a distance learning option or those that are given by evaluation of an individual's research work. Feel free to send me published material on the same to the given postal address. Thanks in advance. Yours sincerely, Nyagudi Musandu Postal address: P. O Box 35427, Nairobi, KENYA ( EAST AFRICA ). From owner-ietf-outbound Tue Mar 28 12:00:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA23583 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 12:00:02 -0500 (EST) Received: from queber.acsi.net (queber.espire.net [206.222.96.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23490 for ; Tue, 28 Mar 2000 11:52:30 -0500 (EST) Received: from pntsmtp02.hq.espire.net (smtp1.espire.net [206.222.96.209]) by queber.acsi.net (8.9.1/8.9.1) with ESMTP id LAA20394; Tue, 28 Mar 2000 11:52:35 -0500 (EST) Message-Id: <200003281652.LAA20394@queber.acsi.net> Received: by PNTSMTP02.hq.espire.net with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 11:52:28 -0500 From: "Taylor, Johnny" To: David Wang Cc: ietf@ietf.org Subject: Re: How IP Packets are encapsulation in DS1 Signal Date: Tue, 28 Mar 2000 11:52:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Loop: ietf@ietf.org As for the data packet flow in DS1s, DS3s, or Fractional pipes, you have three modes: 1) Circuit Switched - Let's say you call Grandma and once she answers you two have exclusive and full use of the circuit that was established between you. You have that circuit unti lone of you hang up, at which time it goes idle until the system of switches grabs it for another call. The call could be voice, video, or data The advantage of circuit swiching is you have it the entire time and it's full duplex. The disadvantage is since you have the entire circuit you pay and it is expensive. 2) Packet Switching - Sending data in packets through a network to some remote location. The data to be sent is assembled in the PAD (Packet Assembler / Disassembler) into indivisual packets of data, involving a process of segmentation. Each packet has an unique ID as well as the destination address. Packet can take variuos routes to the destination address and are Reassembled (normally there is a form of latency due to different paths and lengths). You have an error checking and correcting occurring through this process as well since you have packets arriving at different times and out of order. 3) Message Switching - A technique of receiving a message, storing it for a while and then sending it on to the destination. Normally used when the desired recipinent is not there. The message will keep attempting delivery, freeing the calling party to handle other work. No direct connection is made in message switching between the incoming and out going message. Hopefully this helps you out. I would recommend going to www.data.com or cisco.com (packet magazine). JT From: David Wang on 03/27/2000 05:23 PM To: ietf@ietf.org@SMTP@Exchange cc: Subject: How IP Packets are encapsulation in DS1 Signal Dear Friends, There are plenty of books describing how IP packets are encapsulated in Ethernet frames or ATM cells, or PPP frames. But I have not seen a book describe how IP packets be carried in DS1, Fractional DS1, DS3, Fractional DS3 signals. These signals are point to point, byte streams. I think IP packets should be directly put on those TDM time slots and send from one end point to the other. Can somebody answer my question or point out a book, web site, or a standard so I can find the answer. Thanks David From owner-ietf-outbound Tue Mar 28 12:10:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA23737 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 12:10: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 ESMTP id LAA23551 for ; Tue, 28 Mar 2000 11:59:00 -0500 (EST) Received: from localhost (kodiak@localhost) by psi.pair.com (8.9.1/8.6.12) with ESMTP id LAA23455 for ; Tue, 28 Mar 2000 11:58:58 -0500 (EST) X-Envelope-To: Date: Tue, 28 Mar 2000 11:58:58 -0500 (EST) From: chris d koeberle X-Sender: kodiak@psi.pair.com To: ietf@ietf.org Subject: Re: Privacy and IETF Document Access In-Reply-To: Message-ID: Approved: kodiak@flail.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Tue, 28 Mar 2000 amlan@geektown.net wrote: > I do not think this is really a concern because the system will > accept "dumbo@fool.com" as a valid password email as well. If it doesn't care whether the email address is valid, why does it insist that the invalid email address be in the format of an email address? The problem is not that it insists on a valid email address, but that it appears to do so. This lack of clarity serves no recognizable purpose. -=I would imagine that if 1000 Rwandan's were hacked to death AT THE EXPO, people would sure have raised a stink.=- From owner-ietf-outbound Tue Mar 28 12:20:15 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA23870 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 12:20:02 -0500 (EST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23784 for ; Tue, 28 Mar 2000 12:12:15 -0500 (EST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 Mar 2000 09:02:51 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Tue, 28 Mar 2000 09:02:50 -0800 Message-ID: From: Christian Huitema To: "'Nguyen Tuong Long Le'" , ietf@ietf.org Subject: RE: How Many Routing Tables Date: Tue, 28 Mar 2000 09:02:43 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) X-Loop: ietf@ietf.org > Just as a follow-up question: Can somebody tell me how many > route entries there > are in edge and core routers nowadays? Route entries = local routes + BGP acquired routes. For the latter, the current value is about 78,000, according to the Telstra Internet BGP table maintained by Geoff Houston at http://www.telstra.net/ops/bgptable.html. From owner-ietf-outbound Tue Mar 28 13:30:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA24666 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 13:30:02 -0500 (EST) Received: from tea.uk.pw.com (tea.uk.pw.com [193.131.169.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24577 for ; Tue, 28 Mar 2000 13:16:39 -0500 (EST) From: damjan.gautschi@ch.pwcglobal.com Received: by tea.uk.pw.com; id TAA24785; Tue, 28 Mar 2000 19:11:22 +0100 Received: from olive.uk.pw.com(10.44.240.46) by tea.uk.pw.com via smap (4.1) id xma023703; Tue, 28 Mar 00 19:10:06 +0100 Received: from intleursmtp10.uk.pw.com by olive.uk.pw.com (PMDF V5.1-12 #U3018) with SMTP id <0FS5008MF96OC7@olive.uk.pw.com> for ietf@ietf.org; Tue, 28 Mar 2000 19:11:12 +0100 (BST) Received: by intleursmtp10.uk.pw.com(Lotus SMTP MTA v1.2 hotfix6 (702.3 8-27-1998)) id 802568B0.00640B12 ; Tue, 28 Mar 2000 19:12:44 +0100 Date: Tue, 28 Mar 2000 20:13:56 +0200 Subject: Re: How Many Routing Tables To: ietf@ietf.org Message-id: <802568B0.0065072A.00@intleursmtp10.uk.pw.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline X-Lotus-FromDomain: EMEA-CH@INTL X-Loop: ietf@ietf.org Core routers normally have the full routing table. A router in the access layer should only have 2 paths to the distribution layer. It depends what you're doing. We try to aggregate routes at the distribution layer. eg. when you're dialing into an ISP, you want one path to the core and be able to reach everything from there (internet, server,...) The size of a routing table depends on how big you're network is. For a NAP or a core router running BGP, you'll find about 59'000 network entries and 120'000 paths (internet routing table). Damjan Nguyen Tuong Long Le on 28.03.2000 11:05:28 To: ietf@ietf.org cc: Subject: Re: How Many Routing Tables Just as a follow-up question: Can somebody tell me how many route entries there are in edge and core routers nowadays? Thanks, -- long ---------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. From owner-ietf-outbound Tue Mar 28 14:20:36 2000 Received: by ietf.org (8.9.1a/8.9.1a) id OAA25237 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 14:20:04 -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 ESMTP id OAA25166 for ; Tue, 28 Mar 2000 14:11:23 -0500 (EST) Received: from rgfsparc.cr.usgs.gov (rgfsparc.cr.usgs.gov [136.177.164.192]) by rgfsparc.cr.usgs.gov (8.9.1b+Sun/8.9.1) with SMTP id NAA06077 for ; Tue, 28 Mar 2000 13:10:37 -0600 (CST) Message-Id: <200003281910.NAA06077@rgfsparc.cr.usgs.gov> Date: Tue, 28 Mar 2000 13:10:37 -0600 (CST) From: "Robert G. Ferrell" Reply-To: "Robert G. Ferrell" Subject: Re: Privacy and IETF Document Access To: ietf@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Z3codHhzVMmiwuX/iHfTyw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc X-Loop: ietf@ietf.org >If it doesn't care whether the email address is valid, why does it insist >that the invalid email address be in the format of an email address? The >problem is not that it insists on a valid email address, but that it >appears to do so. This lack of clarity serves no recognizable purpose. Folks, this is just a standard feature of anonymous FTP servers. The authentication parser does a regexp check for string@string[.string]n as a sort of half-witted attempt to weed out the complete lusers. You can take issue with the algorithm if you want, but it certainly doesn't qualify as an invasion of privacy. RGF Robert G. Ferrell, CISSP Information Security Officer National Business Center, US DoI Robert_G_Ferrell@nbc.gov ------------------------------------------------------------ Nothing I have ever said should be construed as even vaguely representing an official statement by the NBC or DoI. ------------------------------------------------------------ From owner-ietf-outbound Tue Mar 28 15:00:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA25717 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 15:00:03 -0500 (EST) Received: from acmez.gatech.edu (IDENT:gte600f@acmez.gatech.edu [130.207.165.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25661 for ; Tue, 28 Mar 2000 14:57:13 -0500 (EST) Received: from localhost (gte600f@localhost) by acmez.gatech.edu (8.9.2/8.9.2) with ESMTP id OAA06617 for ; Tue, 28 Mar 2000 14:57:14 -0500 (EST) Date: Tue, 28 Mar 2000 14:57:14 -0500 (EST) From: Anshuman Sharma To: ietf@ietf.org Subject: SLP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org Does anyone know of any work on SLP for an ADhoc environment besides Salutation. I am trying to look up how viable service discovery is in a purely adhoc environment. --------------------------------------------------- "time and space are modes by which we think...... | they are not the conditions in which we live." | | ~~Einstein | --------------------------------------------------- Anshuman Sharma Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gte600f@prism.gatech.edu anshu@abraxis.com From owner-ietf-outbound Tue Mar 28 18:10:26 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA28055 for ietf-outbound.10@ietf.org; Tue, 28 Mar 2000 18:10:03 -0500 (EST) Received: from stargate.ctp.com (stargate.ctp.com [149.44.2.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27912 for ; Tue, 28 Mar 2000 18:01:06 -0500 (EST) Received: from yorktown.ctp.com (yorktown.ctp.com [149.44.7.32]) by stargate.ctp.com (8.8.8/8.8.8) with ESMTP id SAA26433; Tue, 28 Mar 2000 18:00:38 -0500 (EST) Received: from tabasco.ctp.com (tabasco.ctp.com [149.44.13.50]) by yorktown.ctp.com (8.9.3/8.9.3) with ESMTP id RAA15538; Tue, 28 Mar 2000 17:59:30 -0500 (EST) Received: by tabasco.ctp.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 18:00:37 -0500 Message-ID: From: Sonny Ghosh To: "'ruyeshiro@adtech-inc.com'" , ietf@ietf.org Subject: RE: 10/100 pcmcia card Date: Tue, 28 Mar 2000 18:00:37 -0500 Return-Receipt-To: Sonny Ghosh 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 It appears that you are using a professional, technical community mailing list as a flea market to peddle your extra stuff. Please be advised to refrain from this kind of obnoxious behavior, as you are wasting the time of too many people and denigrating the importance of this mailing list. -----Original Message----- From: Robin Uyeshiro [mailto:ruyeshiro@adtech-inc.com] Sent: Monday, March 27, 2000 9:41 PM To: ietf@ietf.org Subject: 10/100 pcmcia card I bought a 10/100 ethernet PCMCIA card in Adelaide that, it turns out, I don't need. If anyone would like to take it off my hands, make me an offer. I bought it for Australian $149. From owner-ietf-outbound Wed Mar 29 01:30:45 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA08528 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 01:30:03 -0500 (EST) Received: from perq.cac.washington.edu (dhcp-194-163.ietf.connect.com.au [169.208.194.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07633 for ; Wed, 29 Mar 2000 01:23:27 -0500 (EST) Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.9.3/8.9.3) with ESMTP id PAA01282 for ; Wed, 29 Mar 2000 15:53:28 +0930 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Wed, 29 Mar 2000 15:53:28 +0930 (CST) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: ietf@ietf.org Subject: Re: WaveLAN Bronze and IETF wireless? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org Just to close the loop (and since everyone keeps asking me) my poor old Wavelan Turbo Bronze card now works just fine here in Adelaide, without my having to install any new firmware or drivers. Thanks to all, especially the terminal room/wireless net support folks, for making this work. - RL "Bob" From owner-ietf-outbound Wed Mar 29 02:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA10414 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 02:00:03 -0500 (EST) Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09991 for ; Wed, 29 Mar 2000 01:50:45 -0500 (EST) Received: from kaipara.live.com (dhcp-192-84.ietf.connect.com.au [169.208.192.84]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id WAA08210 for ; Tue, 28 Mar 2000 22:48:57 -0800 (PST) Message-Id: <4.3.1.20000328223458.00b88100@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 28 Mar 2000 22:47:07 -0800 To: ietf@ietf.org From: Ross Finlayson Subject: Re: Privacy and IETF Document Access In-Reply-To: References: <200003281442.IAA84644@us.networkcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 07:31 AM 3/28/00, amlan@geektown.net wrote: >I do not think this is really a concern because the system will >accept "dumbo@fool.com" as a valid password email as well. A quick reminder here: Should you ever want to use a 'bogus' or or 'example' domain name, please use the domain name "example.com", which the IANA has specifically reserved for this purpose. (Note, BTW, that the domain name "fool.com" that you used as an example is actually a real domain name used by someone else - "Motley Fool" in this case.) This is something that I'm particularly sensitive to, because - for some reason - lots of people like to use my domain name ("live.com") when fabricating bogus email addresses - and as a result shitloads of spam ends up coming my way. Ross. ps. I've found that most FTP servers will accept the string "guest@" in addition to a fully-formed email address. From owner-ietf-outbound Wed Mar 29 03:20:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA17452 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 03:20:02 -0500 (EST) Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17429 for ; Wed, 29 Mar 2000 03:19:30 -0500 (EST) Received: from cathil ([12.72.129.38]) by mtiwmhc27.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000329081859.BGIY26015.mtiwmhc27.worldnet.att.net@cathil>; Wed, 29 Mar 2000 08:18:59 +0000 Reply-To: From: "Robin Uyeshiro" To: "'Sonny Ghosh'" , Subject: RE: 10/100 pcmcia card Date: Tue, 28 Mar 2000 22:21:39 -1000 Message-ID: <000701bf9957$cf4e8fa0$0902fea9@cathil> 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.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit This is not the case. Here in Adelaide at the 47th IETF, there were problems with the wireless LAN early on, so several people were looking for PCMCIA network cards. I spent two hours going through several computer stores, some of which had sold out of network cards, and finally found a card. It turns out I didn't need the card. I thought someone else might, and actually got a couple of responses from people here in Adelaide. I apologize for the spam, but feel I must respond when someone accuses me in the reflector. -----Original Message----- From: Sonny Ghosh [mailto:SGhosh02@ctp.com] Sent: Tuesday, March 28, 2000 1:01 PM To: 'ruyeshiro@adtech-inc.com'; ietf@ietf.org Subject: RE: 10/100 pcmcia card It appears that you are using a professional, technical community mailing list as a flea market to peddle your extra stuff. Please be advised to refrain from this kind of obnoxious behavior, as you are wasting the time of too many people and denigrating the importance of this mailing list. -----Original Message----- From: Robin Uyeshiro [mailto:ruyeshiro@adtech-inc.com] Sent: Monday, March 27, 2000 9:41 PM To: ietf@ietf.org Subject: 10/100 pcmcia card I bought a 10/100 ethernet PCMCIA card in Adelaide that, it turns out, I don't need. If anyone would like to take it off my hands, make me an offer. I bought it for Australian $149. From owner-ietf-outbound Wed Mar 29 05:00:18 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA18229 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 05: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 ESMTP id EAA18163 for ; Wed, 29 Mar 2000 04:53:07 -0500 (EST) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12a2Cm-0001JG-00; Tue, 28 Mar 2000 21:03:12 +0100 Date: Tue, 28 Mar 2000 21:03:09 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: "Robert G. Ferrell" cc: ietf@ietf.org Subject: Re: Privacy and IETF Document Access In-Reply-To: <200003281910.NAA06077@rgfsparc.cr.usgs.gov> 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, 28 Mar 2000, Robert G. Ferrell wrote: > >If it doesn't care whether the email address is valid, why does it insist > >that the invalid email address be in the format of an email address? The > >problem is not that it insists on a valid email address, but that it > >appears to do so. This lack of clarity serves no recognizable purpose. > > Folks, this is just a standard feature of anonymous FTP servers. which shouldn't be called 'anonymous', then. Just because it's a standard feature doesn't make it a good idea. Speaking of invasions of privacy, I can't find where in Navigator to set the anonymous ftp email password; looks like it's been inherently linked to mail identity. Building mail clients into web browsers has subtle privacy risks. L. > The > authentication parser does a regexp check for string@string[.string]n as a sort > of half-witted attempt to weed out the complete lusers. You can take issue with > the algorithm if you want, but it certainly doesn't qualify as an invasion of > privacy. > > RGF > > Robert G. Ferrell, CISSP > Information Security Officer > National Business Center, US DoI > Robert_G_Ferrell@nbc.gov > ------------------------------------------------------------ > Nothing I have ever said should be construed as even vaguely > representing an official statement by the NBC or DoI. > ------------------------------------------------------------ PGP From owner-ietf-outbound Wed Mar 29 05:40:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA18635 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 05:40:02 -0500 (EST) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18582 for ; Wed, 29 Mar 2000 05:35:22 -0500 (EST) Received: from Software.com ([169.208.192.208]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000329103451.HJEF851310.mta1biz.bizmailsrvcs.net@Software.com>; Wed, 29 Mar 2000 04:34:51 -0600 Sender: droyer Message-ID: <38E1DB64.FAD0989E@Software.com> Date: Wed, 29 Mar 2000 02:31:00 -0800 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk CC: ietf@ietf.org Subject: Re: Privacy and IETF Document Access 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 Wood wrote: > > Folks, this is just a standard feature of anonymous FTP servers. > > which shouldn't be called 'anonymous', then. > > Just because it's a standard feature doesn't make it a good > idea. Speaking of invasions of privacy, I can't find where in > Navigator to set the anonymous ftp email password; looks like it's > been inherently linked to mail identity. Building mail clients into > web browsers has subtle privacy risks. The IETF did not write Netscape, maybe you issue can go to them? From fyi24.txt, rfc1635.txt What is Anonymous FTP? Anonymous FTP is a means by which archive sites allow general access to their archives of information. These sites create a special account called "anonymous". User "anonymous" has limited access rights to the archive host, as well as some operating restrictions. In fact, the only operations allowed are logging in using FTP, listing the contents of a limited set of directories, and retrieving files. Some sites limit the contents of a directory listing an anonymous user can see as well. Note that "anonymous" users are not usually allowed to transfer files TO the archive site, but can only retrieve files from such a site. Traditionally, this special anonymous user account accepts any string as a password, although it is common to use either the password "guest" or one's electronic mail (e-mail) address. Some archive sites now explicitly ask for the user's e-mail address and will not allow login with the "guest" password. Providing an e-mail address is a courtesy that allows archive site operators to get some idea of who is using their services. From owner-ietf-outbound Wed Mar 29 06:40:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA19332 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 06:40:02 -0500 (EST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19237 for ; Wed, 29 Mar 2000 06:33:54 -0500 (EST) Received: (qmail 11772 invoked from network); 29 Mar 2000 11:31:25 -0000 Received: from flure.pair.com (HELO asgard) (209.68.1.159) by relay1.pair.com with SMTP; 29 Mar 2000 11:31:25 -0000 X-pair-Authenticated: 209.68.1.159 From: "Thomas Wolfram" To: Cc: Subject: RE: Privacy and IETF Document Access Date: Wed, 29 Mar 2000 13:32:12 +0200 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA19237 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: Tuesday, March 28, 2000 10:03 PM > To: Robert G. Ferrell > Cc: ietf@ietf.org > Subject: Re: Privacy and IETF Document Access [...] > which shouldn't be called 'anonymous', then. > > Just because it's a standard feature doesn't make it a good > idea. Speaking of invasions of privacy, I can't find where in > Navigator to set the anonymous ftp email password; looks like it's > been inherently linked to mail identity. Building mail clients into > web browsers has subtle privacy risks. > > L. For Netscape try: ftp://anonymous@ftp.example.com resp.: ftp://user.password@ftp.example.com From owner-ietf-outbound Wed Mar 29 06:50:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA19454 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 06: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 ESMTP id GAA19371 for ; Wed, 29 Mar 2000 06:44:10 -0500 (EST) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12aGt7-0001iH-00; Wed, 29 Mar 2000 12:43:53 +0100 Date: Wed, 29 Mar 2000 12:43:51 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Doug Royer cc: ietf@ietf.org Subject: Re: Privacy and IETF Document Access In-Reply-To: <38E1DB64.FAD0989E@Software.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 Wed, 29 Mar 2000, Doug Royer wrote: > The IETF did not write Netscape, maybe you issue can go to them? > > From fyi24.txt, rfc1635.txt [..] > Some archive > sites now explicitly ask for the user's e-mail address and will not > allow login with the "guest" password. Providing an e-mail address > is a courtesy that allows archive site operators to get some idea of > who is using their services. The courtesy of today is the privacy risk of tomorrow. L. PGP From owner-ietf-outbound Wed Mar 29 07:00:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA19653 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 07: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 ESMTP id GAA19532 for ; Wed, 29 Mar 2000 06:52:27 -0500 (EST) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12aH1J-0001rx-00; Wed, 29 Mar 2000 12:52:21 +0100 Date: Wed, 29 Mar 2000 12:52:18 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Chris Yarnell cc: ietf@ietf.org Subject: Re: Privacy and IETF Document Access 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 Wed, 29 Mar 2000, Chris Yarnell wrote: > Date: Wed, 29 Mar 2000 02:27:20 -0800 (PST) > From: Chris Yarnell > To: Lloyd Wood > Subject: Re: Privacy and IETF Document Access > > Unless click the "Send email address as anonymous FTP password" option, it > should use mozilla@ as the password: Yep; missed that. thanks, L. > Wed Mar 29 02:18:53 2000 1 fear.net.kooks.net 12393 test.txt a _ o a > mozilla@ ftp 0 * c > > > which shouldn't be called 'anonymous', then. > > > > Just because it's a standard feature doesn't make it a good > > idea. Speaking of invasions of privacy, I can't find where in > > Navigator to set the anonymous ftp email password; looks like it's > > been inherently linked to mail identity. Building mail clients into > > web browsers has subtle privacy risks. PGP From owner-ietf-outbound Wed Mar 29 07:30:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id HAA20127 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 07:30:02 -0500 (EST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20029 for ; Wed, 29 Mar 2000 07:22:24 -0500 (EST) Received: (qmail 327 invoked from network); 29 Mar 2000 12:19:56 -0000 Received: from flure.pair.com (HELO asgard) (209.68.1.159) by relay1.pair.com with SMTP; 29 Mar 2000 12:19:56 -0000 X-pair-Authenticated: 209.68.1.159 From: "Thomas Wolfram" To: Cc: Subject: RE: Privacy and IETF Document Access Date: Wed, 29 Mar 2000 14:20:43 +0200 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20029 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Thomas Wolfram [mailto:thomas@WOLFRAM.NET] > Sent: Wednesday, March 29, 2000 1:32 PM > To: L.Wood@eim.surrey.ac.uk > Cc: ietf@ietf.org > Subject: RE: Privacy and IETF Document Access > ... > For Netscape try: ftp://anonymous@ftp.example.com > resp.: ftp://user.password@ftp.example.com sorry, that should read: ftp://user:password@ftp.example.com From owner-ietf-outbound Wed Mar 29 08:40:27 2000 Received: by ietf.org (8.9.1a/8.9.1a) id IAA20814 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 08:40:02 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20780 for ; Wed, 29 Mar 2000 08:36:37 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id FAA29638; Wed, 29 Mar 2000 05:29:59 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 29 Mar 2000 13:36:34 UT Received: from spud.ascend.com (spud [192.207.23.51]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id FAA10625; Wed, 29 Mar 2000 05:36:34 -0800 (PST) Received: from amalis (mh-ppp-022.ascend.com [134.112.245.32]) by spud.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id FAA03041; Wed, 29 Mar 2000 05:36:31 -0800 (PST) Message-Id: <4.2.2.20000329024955.025808e0@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 29 Mar 2000 08:34:09 -0500 To: David Wang From: "Andrew G. Malis" Subject: Re: How IP Packets are encapsulation in DS1 Signal Cc: "'ietf@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org David, >There are plenty of books describing how IP packets are encapsulated in >Ethernet frames or ATM cells, or PPP frames. But I have not seen a book >describe how IP packets be carried in DS1, Fractional DS1, DS3, Fractional >DS3 signals. These signals are point to point, byte streams. I think IP >packets should be directly put on those TDM time slots and send from one end >point to the other. Can somebody answer my question or point out a book, web >site, or a standard so I can find the answer. Sorry if I'm stating the obvious, but you can't just carry IP packets over point-to-point links without some sort of framing, so you can tell where one packet ends and the next begins. In addition to various vendor-proprietary framing methods for IP over serial links developed over the years, there have been two major methods standardized in the IETF to frame IP packets over point-to-point links, SLIP (RFC 1055) and PPP (RFCs 1661 and 1662). SLIP is actually a "non-standard standard" (see the RFC for more info). PPP was developed to address SLIP's deficiencies, some of which are discussed in the SLIP RFC itself. Cheers, Andy From owner-ietf-outbound Wed Mar 29 10:22:01 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA21770 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 10:20:02 -0500 (EST) Received: from marcos.networkcs.com (marcos.networkcs.com [137.66.16.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21729 for ; Wed, 29 Mar 2000 10:14:52 -0500 (EST) Received: from us.networkcs.com (us.networkcs.com [137.66.11.15]) by marcos.networkcs.com (8.9.3/8.9.3) with ESMTP id JAA69233 for ; Wed, 29 Mar 2000 09:14:53 -0600 (CST) (envelope-from salo@us.networkcs.com) Received: (from salo@localhost) by us.networkcs.com (8.9.2/8.9.2) id JAA16224 for ietf@ietf.org; Wed, 29 Mar 2000 09:14:53 -0600 (CST) (envelope-from salo) Date: Wed, 29 Mar 2000 09:14:53 -0600 (CST) From: Tim Salo Message-Id: <200003291514.JAA16224@us.networkcs.com> To: ietf@ietf.org Subject: Privacy and IETF Document Access (again) X-Loop: ietf@ietf.org > I recently noticed that ftp.ietf.org requires the use of an e-mail > address (well, ok, something that looks like an e-mail address) as > a password for anonymous login. ... I obviously wasn't particularly clear about my concerns in my original note. I'm concerned that by asking for an e-mail address prior to permitting access to documents, the IETF may be projecting a poor public image of the organization and its its efforts to assure online privacy. As an organization, we pride ourselves on being more concerned than most about privacy in a wired world. But, our ftp configuration could be interpreted as an indication that our actual data practices aren't much better than anyone else's. I suggest that the ftp.ietf.org configuration be changed to not ask for nor check for an e-mail address for anonymous logins. We might even consider replacing the login message with a sentence indicating that we don't think ftp servers should ask for e-mail addresses. And, in response to the e-mail that resulted from my original note (none of which addressed this issue, undoubtedly because I wasn't clear): Yes, it is common practice since the beginning of recorded history to ask for an e-mail address as a password for anonymous ftp access. That doesn't necessarily mean that this practice ought to be considered good enough for the IETF's public image or that the IETF should endorse this practice without thinking about it. Yes, you can fake an e-mail address; that isn't the point. Note, however, that while many ftp servers ask for an e-mail address as a password, many (perhaps most) log the user in even if the password string doesn't look like an e-mail address. The IETF's ftp server, however, refuses to log a person in if the password doesn't pass minimal syntax tests. (I'm not sure, but I think this behavior changed "recently". I thought the IETF ftp server used to accept anonymous users in even if they typed garbage with no "@" as a password. This belief, perhaps mistaken, is what prompted my original note.) No, I don't think this is a big privacy breach. Rather, it is a matter of projecting an appearance that the IETF takes network privacy seriously. If the IETF doesn't take these minimal steps towards respecting online privacy, how can we expect anyone else to? -tjs From owner-ietf-outbound Wed Mar 29 11:30:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA22389 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 11:30:02 -0500 (EST) Received: from watervalley.net (mail.WaterValley.Net [216.220.140.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22366 for ; Wed, 29 Mar 2000 11:29:41 -0500 (EST) Received: from [198.110.21.78] (HELO greendragon.com) by watervalley.net (Stalker SMTP Server 1.8b8) with ESMTP id S.0005263202 for ; Wed, 29 Mar 2000 10:40:07 -0600 Message-ID: <38E22F84.33581F53@greendragon.com> Date: Wed, 29 Mar 2000 11:30:04 -0500 From: William Allen Simpson X-Mailer: Mozilla 4.72 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Privacy and IETF Document Access (again) References: <200003291514.JAA16224@us.networkcs.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 Normally, I'd view this as rather cranky, since many implementations have asked for this information for rather a long time. I usually access them with the generic user "ftp", not "anonymous". I long ago gave up an expectation of anonymity. I believe that the proper security technique is through an anonymizing service. Sites that I regularly visit even have a stated privacy policy saying: your access will be monitored, if you don't like this please leave. However, we should take warning from the recent clueless Boston judge that foolishly granted "accelerated discovery" of non-defendants in the CyberPatrol reverse engineering case, when the plaintiff asked for access logs of many sites. The IETF needs a formal privacy policy. I recommend that we remove the "anonymous" user, leaving only the "ftp" or "guest" users. I recommend that we change the login message to have an explicit privacy statement, saying that the required email response will be used only for network administration purposes, destroyed after 3 days, and never revealed to any third party. Such are the exigencies of interaction with the US courts.... Do we have a WG that could write this up as a BCP? Tim Salo wrote: > I'm concerned that by asking for an e-mail address prior to permitting > access to documents, the IETF may be projecting a poor public image of the > organization and its its efforts to assure online privacy. As an > organization, we pride ourselves on being more concerned than most about > privacy in a wired world. But, our ftp configuration could be interpreted > as an indication that our actual data practices aren't much better than > anyone else's. > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ietf-outbound Wed Mar 29 12:10:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA22725 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 12:10:02 -0500 (EST) Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22678 for ; Wed, 29 Mar 2000 12:04:41 -0500 (EST) Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by beatles.cselt.it (8.9.3/8.9.3) with SMTP id TAA29498 for ; Wed, 29 Mar 2000 19:05:05 +0200 (MET DST) Message-Id: <200003291705.TAA29498@beatles.cselt.it> Date: Wed, 29 Mar 2000 19:05:05 +0200 (MET DST) From: Maurizio Codogno Reply-To: Maurizio Codogno Subject: Re: Privacy and IETF Document Access (again) To: ietf@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7F7/Ja2rUzGFwQeSyU2F7w== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc X-Loop: ietf@ietf.org > From: Tim Salo > To: ietf@ietf.org > > I recently noticed that ftp.ietf.org requires the use of an e-mail > > address (well, ok, something that looks like an e-mail address) as > > a password for anonymous login. ... > > I obviously wasn't particularly clear about my concerns in my original note. > > I'm concerned that by asking for an e-mail address prior to permitting > access to documents, the IETF may be projecting a poor public image of the > organization and its its efforts to assure online privacy. [...] > No, I don't think this is a big privacy breach. Rather, it is a matter > of projecting an appearance that the IETF takes network privacy seriously. I am pragmatic. If the current string 331 Guest login ok, send your complete e-mail address as password. is replaced with 331 Guest login ok, send your complete e-mail address or "anon@invalid" as password. and 530-You must supply a valid email address as your password. 530-For example, "mike@nirvana.ncemrsoft.com" is okay. with 530-You should supply a valid email address as your password. 530-For example, "mike@nirvana.ncemrsoft.com" is okay, 530-but "anon@invalid" is accepted too. I think that privacy concerns would be correctly addressed. ciao, .mau. From owner-ietf-outbound Wed Mar 29 18:40:50 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA25593 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 18:40:02 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25542 for ; Wed, 29 Mar 2000 18:31:30 -0500 (EST) From: Melinda.Shore@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id BAA16230 for ; Thu, 30 Mar 2000 01:31:31 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id BAA02664 for ; Thu, 30 Mar 2000 01:31:30 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Mar 2000 17:31:29 -0600 Message-ID: To: ietf@ietf.org Subject: foglamps mailing list Date: Wed, 29 Mar 2000 17:29:46 -0600 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 The mailing list for discussion of getting difficult protocols across firewalls and NATs is foglamps@egroups.com. To subscribe, send mail to foglamps-request@egroups.com, or those so inclined can use the web interface at http://www.egroups.com. Thanks, Melinda From owner-ietf-outbound Wed Mar 29 18:50:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA25673 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 18:50:02 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25621 for ; Wed, 29 Mar 2000 18:41:59 -0500 (EST) From: Melinda.Shore@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id BAA28746 for ; Thu, 30 Mar 2000 01:42:00 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id BAA27177 for ; Thu, 30 Mar 2000 01:41:59 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Mar 2000 17:40:55 -0600 Message-ID: To: ietf@ietf.org Subject: My goof (foglamps mailing list subscription) Date: Wed, 29 Mar 2000 17:40:13 -0600 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 The subscription address for the foglamps mailing list is "foglamps-subscribe@egroups.com," not the address I sent earlier. Apologies. Melinda From owner-ietf-outbound Wed Mar 29 19:00:14 2000 Received: by ietf.org (8.9.1a/8.9.1a) id TAA25805 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 19:00:04 -0500 (EST) Received: from acmex.gatech.edu (IDENT:gte600f@acmex.gatech.edu [130.207.165.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25770 for ; Wed, 29 Mar 2000 18:58:02 -0500 (EST) Received: from localhost (gte600f@localhost) by acmex.gatech.edu (8.9.2/8.9.2) with ESMTP id SAA21504 for ; Wed, 29 Mar 2000 18:58:00 -0500 (EST) Date: Wed, 29 Mar 2000 18:58:00 -0500 (EST) From: Anshuman Sharma To: ietf@ietf.org Subject: packet filtering and FPGA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org Does anyone know of any sites, or resources that might be helpful in implementing packet filtering at a hardware level using a HDL like VHDL. I need this real urgent. --------------------------------------------------- "time and space are modes by which we think...... | they are not the conditions in which we live." | | ~~Einstein | --------------------------------------------------- Anshuman Sharma Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gte600f@prism.gatech.edu anshu@abraxis.com From owner-ietf-outbound Wed Mar 29 20:00:22 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA26458 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 20:00: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 ESMTP id TAA26371 for ; Wed, 29 Mar 2000 19:53:59 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id QAA19103; Wed, 29 Mar 2000 16:52:51 -0800 (PST) Date: Wed, 29 Mar 2000 16:52:51 -0800 (PST) From: "James P. Salsman" Message-Id: <200003300052.QAA19103@shell9.ba.best.com> To: ietf@ietf.org Subject: HTML forms Cc: www-forms@W3.ORG, www-html@W3.ORG X-Loop: ietf@ietf.org Some educational software advocates and I are considering asking the IETF to suspend control of certain aspects of HTML forms from the W3C until microphone upload issues are addressed. I am very interested in any public comments and private opinions on this matter. Please follow up or reply as you see fit. This is in no way a proposal to remove control of HTML -- other than regarding form device upload issues as per: http://www.bovik.org/device-upload.html -- from the W3C. I would not be suggesting this proposal if my appeal regarding W3C process was being treated seriously; there have been no replies to my appeals, or to questions from others, and and email to the www-forms list (claimed to be "public" on the W3C site) is still not being published. Cheers, James Salsman [The following analysis appeared in the March/April edition of "Extra!" magazine, published by Fairness and Accuracy in Reporting (www.fair.org.) The author, Norman Solomon, is a widely-published media analyst. I believe the facts below can be partly explained by the closed and commercialized nature of the World Wide Web Consortium, especially in regard to HTML forms developments. These paragraphs are reproduced for their "fair" educational use. :jps] What Happened to the "Information Superhighway?" A few numbers tell a dramatic story about extreme changes in media fascination with the Internet. In 1995, media outlets were transfixed with the Internet as an amazing source of knowledge. Major newspapers in the U.S. and abroad referred to the "information superhighway" in 4,562 stories, according to the Nexis database. Meanwhile, articles mentioned "e-commerce" or "electronic commerce" only 915 times. Over the next few years, while Internet usage continued to grow by leaps and bounds, the news media increasingly downplayed "information superhighway" imagery (with a mere 842 mentions in major papers in 1999.) But media mania for electronic commerce exploded. In 1999, major newspapers mentioned e-commerce in 20,641 articles. Five years ago, there was tremendous enthusiasm for the emerging World Wide Web. The phrase "information superhighway" suggested that the Web was primarily a resource for learning and communication. Today, according to the prevalent spin, the Web is best understood as a way to make and spend money. The news media's recalibration of public expectations for the Internet has occurred in tandem with the steady commercialization of cyberspace. More and more, big money is weaving the Web, and the most heavily trafficked web-sites reflect that reality. Almost all of the Web's largest-volume sites are now owned by huge conglomerates. Establishing a pantheon of cyber-heroes, media coverage has cast businessmen like Bill Gates, Jeff Bezos, and Steve Case as great visionaries. If your hopes for the communications future are along the lines of Microsoft, Amazon.com, and America Online, you'll be mighty pleased. -- Norman Solomon From owner-ietf-outbound Wed Mar 29 22:00:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA28501 for ietf-outbound.10@ietf.org; Wed, 29 Mar 2000 22:00:02 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28469 for ; Wed, 29 Mar 2000 21:57:01 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA12016; Wed, 29 Mar 2000 18:56:57 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id SAA07719; Wed, 29 Mar 2000 18:56:58 -0800 (PST) Received: from eng.sun.com (hobo064.Eng.Sun.COM [129.146.31.64]) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2U2utG260414; Wed, 29 Mar 2000 18:56:55 -0800 (PST) Sender: Murray.Altheim@eng.sun.com Message-ID: <38E2C2C5.5785DE00@eng.sun.com> Date: Wed, 29 Mar 2000 18:58:13 -0800 From: Murray Altheim Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586) X-Accept-Language: en MIME-Version: 1.0 To: "James P. Salsman" CC: ietf@ietf.org, www-forms@W3.ORG, www-html@W3.ORG Subject: Re: HTML forms References: <200003300052.QAA19103@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: > > Some educational software advocates and I are considering > asking the IETF to suspend control of certain aspects of > HTML forms from the W3C until microphone upload issues are > addressed. Ha ha ha ha ha ha ha. Gad. Get a life. Really. I'm gone a month from www-html and the first message I get upon resubscribing is this one. Looks like it's time to unsubscribe again. Bye. Murray ........................................................................... Murray Altheim XML Technology Center Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025 But now, after that ye have known God, or rather are known of God, how turn ye again to the weak and beggarly elements, whereunto ye desire again to be in bondage? -- Galatians 4:9 From owner-ietf-outbound Thu Mar 30 00:00:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id AAA01120 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 00:00:03 -0500 (EST) Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00953 for ; Wed, 29 Mar 2000 23:52:36 -0500 (EST) Received: from bovik.org (bovik.vip.best.com [205.149.161.94]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id UAA07778; Wed, 29 Mar 2000 20:50:14 -0800 (PST) Message-ID: <38E2DCF3.6558E358@bovik.org> Date: Wed, 29 Mar 2000 20:49:55 -0800 From: James Salsman Organization: Bovik Research X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: www-html@W3.ORG, altheim@eng.sun.com, ietf@ietf.org CC: www-forms@W3.ORG Subject: Re: HTML forms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Murray, Thank you for the substance of your debate: >... Get a life.... A life is best given with education (Universal Declaration of Human Rights, Article 27.) If microphone upload were prevalent, would asynchronous audio conferencing make spoken language instruction easier enough to help at least one other person? > But now, after that ye have known God, or rather are known of God, > how turn ye again to the weak and beggarly elements, whereunto ye > desire again to be in bondage? -- Galatians 4:9 With the disclaimer that I am a strictly nonevangelical friend, here is a response in kind: And he said, Unto you it is given to know the mysteries of the kingdom of God: but to others in parables; that seeing they might not see, and hearing they might not understand. -- Luke 8:10 The whole point of microphone upload is to help teach languages where simple audio output is insufficient. Evaluation of audio input is necessary for effective speech training and accent reduction. Cheers, James From owner-ietf-outbound Thu Mar 30 02:00:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA05958 for ietf-outbound.10@ietf.org; Thu, 30 Mar 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 ESMTP id BAA05817 for ; Thu, 30 Mar 2000 01:59:17 -0500 (EST) Received: from alden.maxware.no (dhcp-192-245.ietf.connect.com.au [169.208.192.245]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id IAA20254; Thu, 30 Mar 2000 08:58:58 +0200 Message-Id: <4.3.1.0.20000330162410.00d90610@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 30 Mar 2000 16:26:24 +0930 To: "James P. Salsman" , ietf@ietf.org From: Harald Alvestrand Subject: Re: HTML forms Cc: www-forms@W3.ORG, www-html@W3.ORG In-Reply-To: <200003300052.QAA19103@shell9.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 16:52 29.03.00 -0800, James P. Salsman wrote: >Some educational software advocates and I are considering >asking the IETF to suspend control of certain aspects of >HTML forms from the W3C until microphone upload issues are >addressed. No matter what may be thought of the merits of the case, such a request would be ignored by the IETF. There is no procedure to "suspend control of aspects" of a specification, and the IETF is of the opinion that HTML is not under our control anyway. Sorry 'bout that. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no From owner-ietf-outbound Thu Mar 30 03:20:11 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA14073 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 03:20:02 -0500 (EST) Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14004 for ; Thu, 30 Mar 2000 03:15:46 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id NAA04353 for ; Thu, 30 Mar 2000 13:53:31 GMT Received: from wipro.com ([192.168.178.17]) by ecmail.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA640A for ; Thu, 30 Mar 2000 13:40:03 +0530 Message-ID: <38E30E75.3E514AE7@wipro.com> Date: Thu, 30 Mar 2000 13:51:09 +0530 From: "Abhishek Bagchi" Organization: Wipro X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: More error-status codes on SNMPv1? 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, We are working on SNMP interfaces for a product named Flash600 ( ADX, Layer2 switching, ATM) for FNC Inc. We are using SNMPv1 framework , but, unfortunately SNMPv1 supports only following error-status codes: noError(0): no error in the requested PDU. toobig(1): The get-response message is bigger than that the local implementation can handle. noSuchName(2): one of the requested objects does not match anything in the relevant MIB view that can be returned. badValue(3): The set-request asked the agent to write an inappropriate value. readOnly(4): A set-request tried to write a value that the operator is not allowed to write.Either the access specified is READ-ONLY or the the variable MIB definition does not permit write access. genErr(5): A variable cannot be retrieved for reasons outside the ones listed above. This provides very little granularity for the User to decide what went wrong. Is there any other way we can add more error-status codes without violating v1 compliance? We don't want to move over to SNMPv2 ,but, still want to add more error-status codes? Can we add more error-status codes? If so, how? Thanks & regards, Abhishek ******************************************************************** Abhishek Bagchi Wipro Technologies-Telecom Solutions #72,Electronics City,Bangalore-29, India Tel:91-80-8520408/0416 Ext-2108 Fax:91-80-8520478 --------------------------------------- Applying Thought ******************************************************************** From owner-ietf-outbound Thu Mar 30 06:30:35 2000 Received: by ietf.org (8.9.1a/8.9.1a) id GAA15568 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 06:30:02 -0500 (EST) Received: from tangelo.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15520 for ; Thu, 30 Mar 2000 06:23:14 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA06079 for ; Thu, 30 Mar 2000 05:23:13 -0600 (CST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA04758 for ietf@ietf.org; Thu, 30 Mar 2000 03:22:34 -0800 (PST) Date: Thu, 30 Mar 2000 03:22:34 -0800 (PST) From: Randy Presuhn Message-Id: <200003301122.DAA04758@dorothy.bmc.com> To: ietf@ietf.org Subject: Re: More error-status codes on SNMPv1? 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 Hi - > Message-ID: <38E30E75.3E514AE7@wipro.com> > Date: Thu, 30 Mar 2000 13:51:09 +0530 > From: "Abhishek Bagchi" > To: ietf@ietf.org > Subject: More error-status codes on SNMPv1? ... > Is there any other way we can add more error-status codes without > violating v1 > compliance? At the level of the protocol, no. > We don't want to move over to SNMPv2 ,but, still want to add more > error-status codes? > Can we add more error-status codes? If so, how? ... I would suggest using SNMPv3. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-ietf-outbound Thu Mar 30 11:22:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA17500 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 11:20:02 -0500 (EST) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17435 for ; Thu, 30 Mar 2000 11:12:17 -0500 (EST) Received: from utdallas.edu (utdppp231.utdallas.edu [129.110.40.158]) by ns0.utdallas.edu (Postfix) with ESMTP id 860651A0207 for ; Thu, 30 Mar 2000 10:11:56 -0600 (CST) Message-ID: <38E37D93.DC410DCA@utdallas.edu> Date: Thu, 30 Mar 2000 10:15:15 -0600 From: Barbara Bao X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Topology Discovery in IP Networks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Dear Friends, For my assignment, I need to know algorithms for discovering layer-3 and layer-2 network topology. Where can I find those papers? Any information and advice are highly appreciated. Barbara From owner-ietf-outbound Thu Mar 30 12:00:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA17835 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 12:00:06 -0500 (EST) Received: from camaleon.lander.es ([212.95.212.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17808 for ; Thu, 30 Mar 2000 11:59:31 -0500 (EST) Received: (qmail 10716 invoked from network); 30 Mar 2000 16:59:02 -0000 Received: from lince.lander.es (195.76.46.35) by camaleon.lander.es with SMTP; 30 Mar 2000 16:59:02 -0000 Received: (qmail 6290 invoked from network); 30 Mar 2000 16:59:01 -0000 Received: from ppp-47-166.lander.es (HELO salva) (195.76.47.166) by lince.lander.es with SMTP; 30 Mar 2000 16:59:01 -0000 Message-Id: <3.0.6.32.20000330190524.00870b50@lince.lander.es> X-Sender: svidal@lince.lander.es X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 30 Mar 2000 19:05:24 +0200 To: Harald Alvestrand From: Salvador Vidal Subject: Re: HTML forms Cc: ietf@ietf.org In-Reply-To: <4.3.1.0.20000330162410.00d90610@127.0.0.1> References: <200003300052.QAA19103@shell9.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org Hello, At 16:26 30/03/00 +0930, you wrote: >At 16:52 29.03.00 -0800, James P. Salsman wrote: >>Some educational software advocates and I are considering >>asking the IETF to suspend control of certain aspects of >>HTML forms from the W3C until microphone upload issues are >>addressed. >No matter what may be thought of the merits of the case, such a >request would be ignored by the IETF. > >There is no procedure to "suspend control of aspects" of a specification, >and the IETF is of the opinion that HTML is not under our control anyway. > >Sorry 'bout that. > > Harald > >-- >Harald Tveit Alvestrand, EDB Maxware, Norway >Harald.Alvestrand@edb.maxware.no > Diferent standars developed at diferent organizations without coordination, you must check before if Babel tower building plan have copyright! Salva > From owner-ietf-outbound Thu Mar 30 12:10:23 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA18026 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 12:10:07 -0500 (EST) Received: from khumbu.eeng.dcu.ie (khumbu.eeng.dcu.ie [136.206.35.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17999 for ; Thu, 30 Mar 2000 12:08:18 -0500 (EST) Received: from obed (eeng.dcu.ie) [136.206.35.14] by khumbu.eeng.dcu.ie with esmtp (Exim 1.82 #1) id 12aiQh-0005fz-00; Thu, 30 Mar 2000 18:08:23 +0100 Message-ID: <38E389C7.180E84A8@eeng.dcu.ie> Date: Thu, 30 Mar 2000 18:07:19 +0100 From: Nikki Cranley <94426082@eeng.dcu.ie> Reply-To: 94426082@eeng.dcu.ie X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf@ietf.org" Subject: MP4 Encoder/Decoder 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 - I was just wondering if anybody knew if there is an MP4 Systems (with the FlexMux layer) encoder and decoder and how I could get my grubby paws on either the source code or application. Thanking you all, rgds, Nikki From owner-ietf-outbound Thu Mar 30 13:00:19 2000 Received: by ietf.org (8.9.1a/8.9.1a) id NAA18499 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 13:00:03 -0500 (EST) Received: from mailhost.metro-optix.com ([63.91.47.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18441 for ; Thu, 30 Mar 2000 12:50:53 -0500 (EST) Received: by mailhost.axa100.am.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Mar 2000 11:46:53 -0600 Message-ID: From: David Wang To: "'ietf@ietf.org'" Subject: Carry IP Packet in Ethernet Frame in IEEE 802.3 LLC Encapsulation Format Date: Thu, 30 Mar 2000 11:46:53 -0600 Return-Receipt-To: David Wang 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 Dear Friends, I never see or heard any product use 802.3 LLC frame format to carry IP packet. But I am not sure I am correct. Does anyone knows that some product does use the LLC frame to carry IP packets and why? There are 2 type of Ethernet frames: Ethernet Version 2 Frame: | destination | source | type | data | fcs| IEEE 802.3 LLC frame: | destination | source | length | LLC | org code | type | data | fcs| The key difference is the 2 bytes behind the source MAC address. Using Ethernet Version 2 Frame, the type field value will large than the maximum Ethernet frame length 1518. For frames carrying IP packet the type field value is 0x0800. The interface device driver will check this field and realize that this frame carries IP packet. It will send the packet to the IP module for father processing. Thanks David From owner-ietf-outbound Thu Mar 30 15:10:28 2000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA21141 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 15:10:02 -0500 (EST) Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21106 for ; Thu, 30 Mar 2000 15:06:20 -0500 (EST) From: sthaug@nethelp.no Received: (qmail 70303 invoked by uid 1001); 30 Mar 2000 20:06:20 +0000 (GMT) To: david.wang@metro-optix.com Cc: ietf@ietf.org Subject: Re: Carry IP Packet in Ethernet Frame in IEEE 802.3 LLC EncapsulationFormat In-Reply-To: Your message of "Thu, 30 Mar 2000 11:46:53 -0600" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 30 Mar 2000 22:06:20 +0200 Message-ID: <70301.954446780@verdi.nethelp.no> X-Loop: ietf@ietf.org > I never see or heard any product use 802.3 LLC frame format to carry IP > packet. But I am not sure I am correct. Does anyone knows that some product > does use the LLC frame to carry IP packets and why? Older HP-UX (300 & 400 series) systems could do this. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-ietf-outbound Thu Mar 30 16:10:24 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA21659 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 16:10: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 ESMTP id QAA21612 for ; Thu, 30 Mar 2000 16:04:44 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id NAA06774; Thu, 30 Mar 2000 13:03:07 -0800 (PST) Date: Thu, 30 Mar 2000 13:03:07 -0800 (PST) From: "James P. Salsman" Message-Id: <200003302103.NAA06774@shell9.ba.best.com> To: Harald@Alvestrand.no Subject: Re: HTML forms Cc: ietf@ietf.org, www-forms@W3.ORG, www-html@W3.ORG In-Reply-To: <4.3.1.0.20000330162410.00d90610@127.0.0.1> X-Loop: ietf@ietf.org Harald, Thanks for your message: > There is no procedure to "suspend control of aspects" of a specification, The proposal would involve ammending the registration of the text/html media type, incorporating the W3C standards extended with two attributes of the INPUT element, DEVICE and MAXTIME. >... the IETF is of the opinion that HTML is not under our control anyway. I understand that. There might be substantial benefits from reconsidering those opinions. Within the IETF, public debate is assured on almost all controversial matters. The W3C, however, constrains meaningful debate to those willing and able to pay US$50,000 per year. I agree that there was a point in the early development of web standards when that constraint was beneficial. Now, however, with Netscape owned by a company shipping MSIE, and the stagnation or regression of the core HTML standards, along with the concerns raised in Norman Solomon's article, I believe the time has come to return certain aspects of the control of HTML to the IETF. Even if that view is not shared by the IETF, I the only way I would not be certain that a debate on the topic would be healthy for the Internet communty would be if the W3C were to take an affirmative stand on issues involving microphone upload for language instruction and asyncronous audio conferencing. Cheers, James From owner-ietf-outbound Thu Mar 30 16:50:16 2000 Received: by ietf.org (8.9.1a/8.9.1a) id QAA21994 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 16: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 ESMTP id QAA21951 for ; Thu, 30 Mar 2000 16:46:37 -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.10.1.Beta1/8.10.1.Beta1) with ESMTP id e2ULkXp20460; Thu, 30 Mar 2000 16:46:33 -0500 Message-Id: <200003302146.e2ULkXp20460@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.1 10/15/1999 To: "James P. Salsman" cc: ietf@ietf.org, www-forms@W3.ORG, www-html@W3.ORG Subject: Re: HTML forms In-reply-to: Your message of "Thu, 30 Mar 2000 13:03:07 PST." <200003302103.NAA06774@shell9.ba.best.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: text/plain; charset=us-ascii Date: Thu, 30 Mar 2000 16:46:29 -0500 X-Loop: ietf@ietf.org On Thu, 30 Mar 2000 13:03:07 PST, "James P. Salsman" said: > is assured on almost all controversial matters. The W3C, > however, constrains meaningful debate to those willing and able > to pay US$50,000 per year. I agree that there was a point in > the early development of web standards when that constraint was > beneficial. Now, however, with Netscape owned by a company Why was it beneficial then? > shipping MSIE, and the stagnation or regression of the core HTML > standards, along with the concerns raised in Norman Solomon's > article, I believe the time has come to return certain aspects And why is it non-beneficial now, given the apparent complexity of getting a product shipped (look at the current state of Mozilla)? Let's face it - anybody who intends to ship a working browser will need to have enough programmers that the $50K is the least of the problems. Yes, this cuts Mozilla out unless somebody pays for their membership. On the other hand, are there any other *real* contenders for whom $50K would be a hardship? > of the control of HTML to the IETF. Even if that view is not > shared by the IETF, I the only way I would not be certain that > a debate on the topic would be healthy for the Internet communty > would be if the W3C were to take an affirmative stand on issues > involving microphone upload for language instruction and > asyncronous audio conferencing. Umm.. Microphone upload is the *least* of the many challenges facing HTML at the current time. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Thu Mar 30 17:30:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA22537 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 17:30: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 ESMTP id RAA22508 for ; Thu, 30 Mar 2000 17:28:50 -0500 (EST) Received: from dhcp-33-30.ietf.connect.com.au [169.208.33.30] by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id HAA13336 for return ; Fri, 31 Mar 2000 07:58:48 +0930 (CST) Message-Id: <4.2.2.20000330230917.00c1b760@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 30 Mar 2000 23:18:31 +0100 To: ietf@ietf.org From: Graham Klyne Subject: A thought about patents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org As many of us are finding, it seems to become more and more difficult to develop or implement a standard without tripping over somebody-or-other's patent for some piece of technology that many of us would regard as fairly obvious or lacking in novelty. The recent announcement from the U.S. Patent and Trademark Office about overhauling their scrutiny of applications for online business patents seems to imply a tacit acknowledgement that their is a problem with the review process with respect to discovery or prior art or determination of novelty in a claimed invention. My thought is this: I'd like to see a presumption of lack of novelty if an idea gets raised in a public forum, even if it happens _after_ a patent has been applied for, unless it can be shown that the information came from leakage of proprietary information. Maybe such an approach might ameliorate the "gold rush" mentality to be the first to slap a patent on an idea or technique that is coming to be accepted art in the normal process of technology evolution. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-outbound Thu Mar 30 21:10:33 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA24710 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 21:10: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 ESMTP id VAA24664 for ; Thu, 30 Mar 2000 21:06:49 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id SAA20489; Thu, 30 Mar 2000 18:06:44 -0800 (PST) Date: Thu, 30 Mar 2000 18:06:44 -0800 (PST) From: "James P. Salsman" Message-Id: <200003310206.SAA20489@shell9.ba.best.com> To: david@kasey.umkc.edu Subject: Re: HTML forms Cc: ietf@ietf.org, www-html@W3.ORG X-Loop: ietf@ietf.org David, Thanks for your message: > Given a microphone capturing application that can > capture a spoken phrase to a named file, the current > HTML file upload form element is sufficient to upload > that voice clip. That is absolutly right, and it captures the essense of why the W3C should take an affirmative stance to standardize microphone upload. Suppose you are developing a spoken language instruction system using asyncronous audio conferencing. If you wanted to provide for students on several different platforms, you would have to provide a microphone capture application for each of them. Then, when the participants used your system, they would have to record, save to a file, select that file, and upload it as seperate operations, switching between the browser and microphone capture application each time. If microphone upload were standardized, I estimate that it would save over ten mouse and key-clicks per upload, without having to distribute a supplemental application for each platform. > MIME e-mail can carry voice clips and comments between > teacher and student perfectly well. Only a few mail user agents provide that capability. Back in late 1996 some language instructors on one of the distance education lists (DEOS?) or newsgroups were claiming that voice-email presents more trouble than it is worth, at least for some students. > Streaming microphone data as something which would be part > of a standard... The device upload spec isn't for streaming, it uses only TCP-based HTTP POST enctype="multipart/form-data" HTML form submissions; see: http://www.bovik.org/device-upload.html Cheers, James From owner-ietf-outbound Thu Mar 30 21:40:12 2000 Received: by ietf.org (8.9.1a/8.9.1a) id VAA24999 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 21:40: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 ESMTP id VAA24966 for ; Thu, 30 Mar 2000 21:38:18 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id SAA00760; Thu, 30 Mar 2000 18:37:59 -0800 (PST) Date: Thu, 30 Mar 2000 18:37:59 -0800 (PST) From: "James P. Salsman" Message-Id: <200003310237.SAA00760@shell9.ba.best.com> To: Valdis.Kletnieks@vt.edu Subject: Re: HTML forms Cc: ietf@ietf.org, www-html@W3.ORG X-Loop: ietf@ietf.org Valdis, Thank you for your reply to my message: >>... The W3C... constrains meaningful debate to those willing and able >> to pay US$50,000 per year. I agree that there was a point in >> the early development of web standards when that constraint was >> beneficial.... > > Why was it beneficial then? There was a lot of concern that a consensus would be too dificult to achieve unless there were some entry barriers. The other reasons involved mutual nondisclosure and similar features of quickly-emerging technology companies. None of those reasons should have ever been assumed to be perminant. Another benefit was that the membership fees established a great infrastructure of facilities and staff for the W3C > And why is it non-beneficial now...? Well, I've already given a couple reasons beyond those of Normon Solomon's, but consider this: The W3C has over 400 members! http://www.w3.org/Consortium/Member/List That's over US$20 million in annual membership fees. Typical W3C members don't even seem to realize they are part of the consortium. For example, TIAA-CREF and Recording for the Blind and Dyslexic are both members. But after days on the phone and over email, nobody I've reached within those organizations has any idea who their W3C Advisory Committee representative is. Recording for the Blind asks me for money every few months, and I've given to them in the past, but knowing that they spend $50K a year without any idea who their AC rep. is makes it a lot less likely for me to want to donate anything else to them. It would be different if their AC rep. stood up for their interests, but nobody at Recording for the Blind and Dyslexic with whom I've spoken had even the faintest idea what microphone upload was or how it could benefit them. Same with TIAA-CREF, supposedly representing the interests of tens of thousands of language teachers. > On the other hand, are there any other *real* contenders for whom > $50K would be a hardship? Absolutly. The foremost are probably the developers of Emacs' w3-mode, but I'm sure I could name a dozen tiny browser-developing projects of one kind or another, if you're interested. How about the developers of LWP.pm and CGI.pm -- do you expect them to plop down 50 grand anytime soon? Cheers, James From owner-ietf-outbound Thu Mar 30 22:50:20 2000 Received: by ietf.org (8.9.1a/8.9.1a) id WAA27230 for ietf-outbound.10@ietf.org; Thu, 30 Mar 2000 22: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 ESMTP id WAA27186 for ; Thu, 30 Mar 2000 22:48:23 -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.10.1.Beta1/8.10.1.Beta1) with ESMTP id e2V3mGp12778; Thu, 30 Mar 2000 22:48:16 -0500 Message-Id: <200003310348.e2V3mGp12778@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.1 10/15/1999 To: "James P. Salsman" cc: ietf@ietf.org, www-html@W3.ORG Subject: Re: HTML forms In-reply-to: Your message of "Thu, 30 Mar 2000 18:06:44 PST." <200003310206.SAA20489@shell9.ba.best.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: text/plain; charset=us-ascii Date: Thu, 30 Mar 2000 22:48:16 -0500 X-Loop: ietf@ietf.org On Thu, 30 Mar 2000 18:06:44 PST, "James P. Salsman" said: > audio conferencing. If you wanted to provide for students > on several different platforms, you would have to provide > a microphone capture application for each of them. Then, Sounds like a straw man to me. When was the last time you bought a microphone/audio card for a system that didn't include at least basic software to do this sort of thing? And I'm the one who always complains that vendors don't ship support for AIX (Macromedia Flash, RealAudio, and StarOffice being at the top of my wish list this week). > Only a few mail user agents provide that capability. Back Well, the MIME spec came "out of the box" with audio MIME types. Put the blame squarely on the MUA developers, the protocol supported it - in fact, I believe one of the early MIME 'stress test' messages included an audio clip, while RFC1341 was still at I-D status. > in late 1996 some language instructors on one of the distance > education lists (DEOS?) or newsgroups were claiming that > voice-email presents more trouble than it is worth, at least > for some students. There are those who find VCR's challenging. It isn't NTSC's or PAL's fault... On Thu, 30 Mar 2000 18:37:59 PST, "James P. Salsman" said: > There was a lot of concern that a consensus would be too dificult > to achieve unless there were some entry barriers. The other > reasons involved mutual nondisclosure and similar features of > quickly-emerging technology companies. None of those reasons And you're claiming that with MORE voices, consensus would be easier to achieve now? Also, I've heard from several people "I have browser XYZ written by 3 or 4 people, it's tiny, fast, and implements most stuff". Which, actually, was my point - it's pretty easy to write a browser that will implement MOST stuff. However, by the time you do full HTML 4, Javascript, SSL, CSS, Java, and whatever else, you're looking at a pretty big pile of code, unless you're just in the "Let's see how far into the wilderness we can push feature XYZ at the cost of other support" game. Sure, 2-3 programmers can get a basic minimal browser done - but 2-3 programmers are probably not going to implement *enough* of the esoteric stuff that they will start needing to worry about what partially-specified feature XYZ really means, unless feature XYZ is already widely acknowledged to be defined in a brain-dead manner... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Fri Mar 31 01:30:49 2000 Received: by ietf.org (8.9.1a/8.9.1a) id BAA01593 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 01:30:04 -0500 (EST) Received: from mail.bezeqint.net (mail-a.bezeqint.net [192.115.106.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01069 for ; Fri, 31 Mar 2000 01:26:23 -0500 (EST) Received: from qsm3 (PT2-6094.bezeqint.net) by mail.bezeqint.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FS900MFOWJKN6@mail.bezeqint.net> for ietf@ietf.org; Fri, 31 Mar 2000 08:26:11 +0200 (IST) Date: Fri, 31 Mar 2000 08:25:51 +0200 From: Jonathan Rosenne Subject: RE: Standards development (was HTML forms) In-reply-to: <200003302146.e2ULkXp20460@black-ice.cc.vt.edu> To: "James P. Salsman" Cc: ietf@ietf.org, www-forms@W3.ORG, www-html@W3.ORG Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit In my experience, the proper way to develop standards is to begin with a private implementation. Only with practical experience can sufficient understanding be achieved to enable the writing of a good standard. Nearly all prevalent standards have followed this course, including HTML. An example of writing the standard first is OSI. Jony > -----Original Message----- > From: www-html-request@w3.org [mailto:www-html-request@w3.org]On Behalf Of > Valdis.Kletnieks@vt.edu > Sent: Thursday, March 30, 2000 11:47 PM > To: James P. Salsman > Cc: ietf@ietf.org; www-forms@w3.org; www-html@w3.org > Subject: Re: HTML forms > > > On Thu, 30 Mar 2000 13:03:07 PST, "James P. Salsman" said: > > is assured on almost all controversial matters. The W3C, > > however, constrains meaningful debate to those willing and able > > to pay US$50,000 per year. I agree that there was a point in > > the early development of web standards when that constraint was > > beneficial. Now, however, with Netscape owned by a company > > Why was it beneficial then? > > > shipping MSIE, and the stagnation or regression of the core HTML > > standards, along with the concerns raised in Norman Solomon's > > article, I believe the time has come to return certain aspects > > And why is it non-beneficial now, given the apparent complexity of > getting a product shipped (look at the current state of Mozilla)? > Let's face it - anybody who intends to ship a working browser will > need to have enough programmers that the $50K is the least of the problems. > > Yes, this cuts Mozilla out unless somebody pays for their membership. On > the other hand, are there any other *real* contenders for whom $50K would > be a hardship? > > > of the control of HTML to the IETF. Even if that view is not > > shared by the IETF, I the only way I would not be certain that > > a debate on the topic would be healthy for the Internet communty > > would be if the W3C were to take an affirmative stand on issues > > involving microphone upload for language instruction and > > asyncronous audio conferencing. > > Umm.. Microphone upload is the *least* of the many challenges facing > HTML at the current time. > > -- > Valdis Kletnieks > Operating Systems Analyst > Virginia Tech > From owner-ietf-outbound Fri Mar 31 02:10:21 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA10063 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 02:10:02 -0500 (EST) Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10026 for ; Fri, 31 Mar 2000 02:06:51 -0500 (EST) Received: from [63.193.119.97] (adsl-63-193-119-97.dsl.snfc21.pacbell.net [63.193.119.97]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id XAA04667; Thu, 30 Mar 2000 23:05:03 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Quote: I wasn't innocent till I got older. --WIK X-Calibur: Signifying that I, Arthur, was to become King of the Britons X-Mailer: Eudora Pro 4.2.2 for Mac OS Date: Thu, 30 Mar 2000 23:05:01 -0800 To: ietf@ietf.org, www-forms@W3.ORG, www-html@W3.ORG From: Walter Ian Kaye Subject: Re: Standards development (was HTML forms) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org At 08:25a +0200 03/31/00, Jonathan Rosenne didst inscribe upon an electronic papyrus: >In my experience, the proper way to develop standards is to begin >with a private implementation. And to do so does not necessarily require building an entire browser. Since the input "widget" is just one part of a page, you only need to prototype that one widget. You can do it in any RAD environment. Make a background image that looks like part of a web page if you like, and put your widget onto it. Build in your behaviors, then upload it to the 'Net for people to try out. Bonus points if you can deploy to multiple platforms (REALbasic is good;). -Walter From owner-ietf-outbound Fri Mar 31 02:50:44 2000 Received: by ietf.org (8.9.1a/8.9.1a) id CAA10393 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 02:50: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 ESMTP id CAA10362 for ; Fri, 31 Mar 2000 02:44:02 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id XAA01363; Thu, 30 Mar 2000 23:42:43 -0800 (PST) Date: Thu, 30 Mar 2000 23:42:43 -0800 (PST) From: "James P. Salsman" Message-Id: <200003310742.XAA01363@shell9.ba.best.com> To: Valdis.Kletnieks@vt.edu Subject: Re: HTML forms Cc: ietf@ietf.org, www-html@W3.ORG In-Reply-To: <200003310348.e2V3mGp12778@black-ice.cc.vt.edu> X-Loop: ietf@ietf.org Valdis, Thank you for your reply: > When was the last time you bought a microphone/audio card for > a system that didn't include at least basic software to do > [recording to files]? Not too many months. Try any Linux on any of IBM's PCs with one of their soundcard/modem combinations; you'll see. Sure, someone has a driver somewhere, but even top-of-the-line consumer Linuxes can't (or won't) auto-detect it, for IBM's most popular consumer models. But simply providing such applications is not the primary difficulty. How many clicks and keystrokes does the recorder app on your desktop take to save a file? How many to select that file in an INPUT TYPE=FILE widget? Doesn't that tell you why, with a growing market in speech recognition-based language learning software, nobody seems to be using web file upload for microphone data upload? > Well, the MIME spec came "out of the box" with audio MIME types. None of which were suitable for spoken language instruction until RFC 2586. The majority of them are still proprietary, and even the almost-state-of-the-art-and-wildly-popular MP3 format is owned by a (litigiously overwhelmed) German firm. >> in late 1996 some language instructors on one of the distance >> education lists (DEOS?) or newsgroups were claiming that >> voice-email presents more trouble than it is worth, at least >> for some students. > > There are those who find VCR's challenging. It isn't NTSC's or PAL's > fault... We are talking about serving a population of students. And a standards organization claiming to be dedicated to platform- independence and interoperability, while simultaneously claiming that non-normative aspects of the proprietary OBJECT and EMBED elements absolve it from complicity -- complicity not only in the promulgation of noninteroperable specifications that reinforce wintel dominance, but that expose ordinary browser users to the profoundly serious security risks of raw binary executable code. For that latter reason alone I believe there is justifiable cause for the IETF to suspend the W3C's HTML type registration. Plus, there are issues pertaining to the granularity of each recording. With a web-based asynchronous audio conferencing system using microphone upload, the task of grading a plethora of spoken phrases turned in from students could be made to be much easier than trying to take care of the same number of email attachments. Cheers, James From owner-ietf-outbound Fri Mar 31 03:00:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id DAA10476 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 03: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 ESMTP id CAA10439 for ; Fri, 31 Mar 2000 02:56:20 -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.10.1.Beta1/8.10.1.Beta1) with ESMTP id e2V7uJp31128; Fri, 31 Mar 2000 02:56:20 -0500 Message-Id: <200003310756.e2V7uJp31128@black-ice.cc.vt.edu> To: Walter Ian Kaye cc: ietf@ietf.org, www-forms@W3.ORG, www-html@W3.ORG Subject: Re: Standards development (was HTML forms) In-reply-to: Your message of "Thu, 30 Mar 2000 23:05:01 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[ Date: Fri, 31 Mar 2000 02:56:19 -0500 X-Loop: ietf@ietf.org On Thu, 30 Mar 2000 23:05:01 PST, Walter Ian Kaye said: > And to do so does not necessarily require building an entire browser. > Since the input "widget" is just one part of a page, you only need to > prototype that one widget. You can do it in any RAD environment. Make > a background image that looks like part of a web page if you like, > and put your widget onto it. Build in your behaviors, then upload it > to the 'Net for people to try out. Bonus points if you can deploy to > multiple platforms (REALbasic is good;). Extra bonus points if, while designing the widget, you keep straight the distinction between "implementation and user interface" (what the user sees, using THIS GUI toolkit, on THIS system), and "protocol" (what string of bytes *on the network* is sent to/from your black-box widget). There's a distinction between protocol and API. A lot of different browsers have implemented the HTML construct, and they LOOK and BEHAVE differently for the UI, but the octets on the wire are the same. Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-outbound Fri Mar 31 04:00:37 2000 Received: by ietf.org (8.9.1a/8.9.1a) id EAA11024 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 04:00:02 -0500 (EST) Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10963 for ; Fri, 31 Mar 2000 03:54:19 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id OAA04255 for ; Fri, 31 Mar 2000 14:31:49 GMT Received: from wipro.com ([192.168.178.17]) by ecmail.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA26A3; Fri, 31 Mar 2000 14:18:21 +0530 Message-ID: <38E468F7.5932AAEE@wipro.com> Date: Fri, 31 Mar 2000 14:29:35 +0530 From: "Abhishek Bagchi" Organization: Wipro X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Beecher Adams , ietf@ietf.org CC: Shivendra Kumar , "sreedhar.jayaram@wipro.com" , Amit Srivastava Subject: Re: More error-status codes on SNMPv1? 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 Hi, Thanks for your valuable comments.Please find my comments inline. Beecher Adams wrote: > Although the error-status codes may not be extended in v1, what you could do > is implement an error details table under your private mib. When you issue > one of the standard error codes, the manager could then go query the error > details table to find out more specific information on why the error > occurred. The error-index field which is part of the get-response PDU could > be used as the index into the error table. This allows an unambigous > correlation between the error PDU and the corresponding details in the > table. This seems to be a good idea.Do you mean to say that an entry in this table will be created whenever the agent implementation populates the error index field of the response PDU with a varbind index?I feel the columner objects in this table can be the v1 specific error-status and the value of the columner object can indicate to the specific error condition . But, the questions that come to my mind are: 1.If the index to the table entry is the error-index in the response PDU , some other response PDU may have the same error-index value for a different varbind.So, there is a problem with unique indexing for the table entries. The solution to this could be to include the request ID also in the index information as the request ID is unique to any request PDU. 2.Assuming that the above problem is solved how does the mgmt entity querry this table? The most obvious way seems to be a next operation as the stn doesn't know which particular object to query in that entry.What do you feel? 3.Since every time the error-index is populated an entry is created the number of entries can swell up at times. So we have to devise a way of periodically deleting entries from this table.How do you think we decide upon this? There could be a number of other questions that may come to one's mind but right now I'm not able to think beyond these. Your valuable opinions can surely open it up a lot more. Thanks > > > Beecher Adams > Metro OptiX > 2201 Avenue K > Plano, TX 75074 > Email: beecher.adams@metro-optix.com > Phone: 214.299.4214 Fax: 214.299.4289 > > -----Original Message----- > From: Abhishek Bagchi [mailto:abhishek.bagchi@wipro.com] > Sent: Thursday, March 30, 2000 2:21 AM > To: ietf@ietf.org > Subject: More error-status codes on SNMPv1? > > Hi all, > > We are working on SNMP interfaces for a product named Flash600 ( ADX, > Layer2 switching, ATM) for FNC Inc. We are using SNMPv1 framework , but, > unfortunately SNMPv1 supports only following error-status codes: > > noError(0): no error in the requested PDU. > toobig(1): The get-response message is bigger than that the local > implementation can handle. > noSuchName(2): one of the requested objects does not match anything in > the relevant MIB view that can be returned. > badValue(3): The set-request asked the agent to write an inappropriate > value. > readOnly(4): A set-request tried to write a value that the operator is > not allowed to write.Either the access specified is > READ-ONLY or the the variable MIB definition does not permit write > access. > genErr(5): A variable cannot be retrieved for reasons outside the ones > listed above. > > This provides very little granularity for the User to decide what went > wrong. > > Is there any other way we can add more error-status codes without > violating v1 > compliance? > We don't want to move over to SNMPv2 ,but, still want to add more > error-status codes? > Can we add more error-status codes? If so, how? > > Thanks & regards, > Abhishek > > ******************************************************************** > Abhishek Bagchi > Wipro Technologies-Telecom Solutions > #72,Electronics City,Bangalore-29, > India > Tel:91-80-8520408/0416 Ext-2108 > Fax:91-80-8520478 > --------------------------------------- > Applying Thought > ******************************************************************** -- ******************************************************************** Abhishek Bagchi Wipro Technologies-Telecom Solutions #72,Electronics City,Bangalore-29, India Tel:91-80-8520408/0416 Ext-2108 Fax:91-80-8520478 --------------------------------------- Applying Thought ******************************************************************** From owner-ietf-outbound Fri Mar 31 05:10:41 2000 Received: by ietf.org (8.9.1a/8.9.1a) id FAA11585 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 05:10: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 ESMTP id FAA11538 for ; Fri, 31 Mar 2000 05:01:25 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id CAA26861; Fri, 31 Mar 2000 02:00:57 -0800 (PST) Date: Fri, 31 Mar 2000 02:00:57 -0800 (PST) From: "James P. Salsman" Message-Id: <200003311000.CAA26861@shell9.ba.best.com> To: rosenne@qsm.co.il Subject: RE: Standards development (was HTML forms) Cc: ietf@ietf.org, www-html@W3.ORG In-Reply-To: X-Loop: ietf@ietf.org Jony, Thanks for your message: > In my experience, the proper way to develop standards is to > begin with a private implementation. Private? Anyone is welcome to my Mozilla mods if they will try to port them to Gecko. Most browsers already implement file upload. The only difficulty is in interfacing form elements to various device drivers. Even though that does sound terribly difficult, it really doesn't have to be. One of the most useful extensions, as shown in the examples, is intended to launch an external file editor on a workstation, when its corresponding widget is selected. There is no reason that couldn't be used for microphone upload, with the widget ("Browse..." replaced with "Record...") launching the system's standard audio recording 'accessory' application. The concept is proven, but the browser producers do not seem at all likely to provide their implemetations without affirmative advocacy and authority of the W3C, or the IETF. The WebTV Plus had implemented 8000 (8-bit) sample per second audio microphone upload in late 1997. Though I did the spec there, to this day I don't know who in WebTV engineering did the actual implementation or the documentation you can read in the WebTV Plus FAQ. Cheers, James From owner-ietf-outbound Fri Mar 31 09:01:41 2000 Received: by ietf.org (8.9.1a/8.9.1a) id JAA13597 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 09:00:02 -0500 (EST) Received: from mailhost.metro-optix.com ([63.91.47.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13554 for ; Fri, 31 Mar 2000 08:54:49 -0500 (EST) Received: by mailhost.axa100.am.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 31 Mar 2000 07:49:37 -0600 Message-ID: From: Beecher Adams To: "'Abhishek Bagchi'" , ietf@ietf.org Cc: Shivendra Kumar , sreedhar.jayaram@wipro.com, Amit Srivastava Subject: RE: More error-status codes on SNMPv1? Date: Fri, 31 Mar 2000 07:49:36 -0600 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 See below, -----Original Message----- From: Abhishek Bagchi [mailto:abhishek.bagchi@wipro.com] Sent: Friday, March 31, 2000 3:00 AM To: Beecher Adams; ietf@ietf.org Cc: Shivendra Kumar; sreedhar.jayaram@wipro.com; Amit Srivastava Subject: Re: More error-status codes on SNMPv1? Hi, Thanks for your valuable comments.Please find my comments inline. Beecher Adams wrote: > Although the error-status codes may not be extended in v1, what you could do > is implement an error details table under your private mib. When you issue > one of the standard error codes, the manager could then go query the error > details table to find out more specific information on why the error > occurred. The error-index field which is part of the get-response PDU could > be used as the index into the error table. This allows an unambigous > correlation between the error PDU and the corresponding details in the > table. This seems to be a good idea.Do you mean to say that an entry in this table will be created whenever the agent implementation populates the error index field of the response PDU with a varbind index? Yes I feel the columner objects in this table can be the v1 specific error-status and the value of the columner object can indicate to the specific error condition . But, the questions that come to my mind are: 1.If the index to the table entry is the error-index in the response PDU , some other response PDU may have the same error-index value for a different varbind.So, there is a problem with unique indexing for the table entries. The solution to this could be to include the request ID also in the index information as the request ID is unique to any request PDU. The normal use of error-index is to indicate which varbind may have been the source of the error. I suspect many agents don't get this fancy though and don't make use of the field. I'm proposing to use this field instead as an index to an error details table. The table could be of a fixed size such as 50 entries that will wrap. It is the agents responsbility to increment the error-index for each new snmp error that occurs. This way there is no ambiguity issue. 2.Assuming that the above problem is solved how does the mgmt entity querry this table? The most obvious way seems to be a next operation as the stn doesn't know which particular object to query in that entry.What do you feel? The error details table is just a regular snmp table, in your enterprise branch. Having the index from error-index, a simple get operation can be performed. 3.Since every time the error-index is populated an entry is created the number of entries can swell up at times. So we have to devise a way of periodically deleting entries from this table.How do you think we decide upon this? Simply use a fixed size table that wraps, e.g. index = 1, then 2, then ..50, then 1, etc. There would never be more than 50 outstanding snmp errors, or again whatever number you choose. There could be a number of other questions that may come to one's mind but right now I'm not able to think beyond these. Your valuable opinions can surely open it up a lot more. Thanks > > > Beecher Adams > Metro OptiX > 2201 Avenue K > Plano, TX 75074 > Email: beecher.adams@metro-optix.com > Phone: 214.299.4214 Fax: 214.299.4289 > > -----Original Message----- > From: Abhishek Bagchi [mailto:abhishek.bagchi@wipro.com] > Sent: Thursday, March 30, 2000 2:21 AM > To: ietf@ietf.org > Subject: More error-status codes on SNMPv1? > > Hi all, > > We are working on SNMP interfaces for a product named Flash600 ( ADX, > Layer2 switching, ATM) for FNC Inc. We are using SNMPv1 framework , but, > unfortunately SNMPv1 supports only following error-status codes: > > noError(0): no error in the requested PDU. > toobig(1): The get-response message is bigger than that the local > implementation can handle. > noSuchName(2): one of the requested objects does not match anything in > the relevant MIB view that can be returned. > badValue(3): The set-request asked the agent to write an inappropriate > value. > readOnly(4): A set-request tried to write a value that the operator is > not allowed to write.Either the access specified is > READ-ONLY or the the variable MIB definition does not permit write > access. > genErr(5): A variable cannot be retrieved for reasons outside the ones > listed above. > > This provides very little granularity for the User to decide what went > wrong. > > Is there any other way we can add more error-status codes without > violating v1 > compliance? > We don't want to move over to SNMPv2 ,but, still want to add more > error-status codes? > Can we add more error-status codes? If so, how? > > Thanks & regards, > Abhishek > > ******************************************************************** > Abhishek Bagchi > Wipro Technologies-Telecom Solutions > #72,Electronics City,Bangalore-29, > India > Tel:91-80-8520408/0416 Ext-2108 > Fax:91-80-8520478 > --------------------------------------- > Applying Thought > ******************************************************************** -- ******************************************************************** Abhishek Bagchi Wipro Technologies-Telecom Solutions #72,Electronics City,Bangalore-29, India Tel:91-80-8520408/0416 Ext-2108 Fax:91-80-8520478 --------------------------------------- Applying Thought ******************************************************************** From owner-ietf-outbound Fri Mar 31 10:41:02 2000 Received: by ietf.org (8.9.1a/8.9.1a) id KAA14732 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 10:40:03 -0500 (EST) Received: from khumbu.eeng.dcu.ie (khumbu.eeng.dcu.ie [136.206.35.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14682 for ; Fri, 31 Mar 2000 10:38:21 -0500 (EST) Received: from obed (eeng.dcu.ie) [136.206.35.14] by khumbu.eeng.dcu.ie with esmtp (Exim 1.82 #1) id 12b3V7-00054P-00; Fri, 31 Mar 2000 16:38:21 +0100 Message-ID: <38E4C62F.5122EE42@eeng.dcu.ie> Date: Fri, 31 Mar 2000 16:37:19 +0100 From: Nikki Cranley <94426082@eeng.dcu.ie> Reply-To: 94426082@eeng.dcu.ie X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf@ietf.org" Subject: Lost RTCP packets 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 - Just a thought, what is the procedure when RTCP packets are lost between the client and server. These are fairly important bits of information. I am experimenting with RTP/RTCP over UDP/IP with a view to adding QoS - however I just wondered there if perhaps a hybrid stack should be used for example :- RTP/UDP/IP & RTCP/TCP/IP. Any comments or ideas about this ... Thanking you, rgds, Nikki From owner-ietf-outbound Fri Mar 31 11:10:10 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA15222 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 11:10:02 -0500 (EST) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15165 for ; Fri, 31 Mar 2000 11:04:13 -0500 (EST) Received: from exchange2.idxii.net by dfw7sosrv11.alter.net with ESMTP (peer crosschecked as: exchange2.idxii.net [206.64.6.16]) id QQiixk11227; Fri, 31 Mar 2000 16:03:59 GMT Received: by exchange2.idxii.net with Internet Mail Service (5.5.2448.0) id ; Fri, 31 Mar 2000 10:52:28 -0500 Message-ID: <4339AAD5ABE3D211AA9B006008A0F5CE13327E@exchange2.idxii.net> From: Hubert Chang To: "'sthaug@nethelp.no'" , david.wang@metro-optix.com Cc: ietf@ietf.org Subject: RE: Carry IP Packet in Ethernet Frame in IEEE 802.3 LLC Encapsula tionFormat Date: Fri, 31 Mar 2000 10:52:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" X-Loop: ietf@ietf.org Apple MAC2 did have this in 1988-1989. Hubert Chang -----Original Message----- From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] Sent: Thursday, March 30, 2000 3:06 PM To: david.wang@metro-optix.com Cc: ietf@ietf.org Subject: Re: Carry IP Packet in Ethernet Frame in IEEE 802.3 LLC EncapsulationFormat > I never see or heard any product use 802.3 LLC frame format to carry IP > packet. But I am not sure I am correct. Does anyone knows that some product > does use the LLC frame to carry IP packets and why? Older HP-UX (300 & 400 series) systems could do this. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-ietf-outbound Fri Mar 31 11:41:31 2000 Received: by ietf.org (8.9.1a/8.9.1a) id LAA15726 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 11:40:02 -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 LAA15703 for ; Fri, 31 Mar 2000 11:40:00 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Mar 31 11:39:32 EST 2000 Received: from research.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA19794; Fri, 31 Mar 2000 11:39:28 -0500 (EST) Message-ID: <38E4D2FA.1A328DAF@research.bell-labs.com> Date: Fri, 31 Mar 2000 11:31:54 -0500 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: david.wang@metro-optix.com CC: Hubert Chang , "'sthaug@nethelp.no'" , ietf@ietf.org Subject: Re: Carry IP Packet in Ethernet Frame in IEEE 802.3 LLC EncapsulationFormat References: <4339AAD5ABE3D211AA9B006008A0F5CE13327E@exchange2.idxii.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 I remember back in the NSFnet days, the IBM router's ethernet interface supported DIX, 802.3/SNAP and 802.3... We even had a bug where one of the formats gave odd-boundary frames, and the Intel596 Ethernet chips were not too happy about it .... - Ping Hubert Chang wrote: > > Apple MAC2 did have this in 1988-1989. > > Hubert Chang > > -----Original Message----- > From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] > Sent: Thursday, March 30, 2000 3:06 PM > To: david.wang@metro-optix.com > Cc: ietf@ietf.org > Subject: Re: Carry IP Packet in Ethernet Frame in IEEE 802.3 LLC > EncapsulationFormat > > > I never see or heard any product use 802.3 LLC frame format to carry IP > > packet. But I am not sure I am correct. Does anyone knows that some > product > > does use the LLC frame to carry IP packets and why? > > Older HP-UX (300 & 400 series) systems could do this. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-ietf-outbound Fri Mar 31 12:20:09 2000 Received: by ietf.org (8.9.1a/8.9.1a) id MAA16217 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 12:20:03 -0500 (EST) Received: from relay1.acec.com (relay1.acec.com [38.249.211.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16134 for ; Fri, 31 Mar 2000 12:13:33 -0500 (EST) Received: from bnatale.acecomm.com (bnatale.acec.com [192.152.208.143]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id MAA23787; Fri, 31 Mar 2000 12:12:23 -0500 (EST) Message-Id: <4.3.1.2.20000331120829.00b5a5e8@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 31 Mar 2000 12:15:02 -0500 To: Beecher Adams From: Bob Natale Subject: RE: More error-status codes on SNMPv1? Cc: "'Abhishek Bagchi'" , ietf@ietf.org, Shivendra Kumar , sreedhar.jayaram@wipro.com, Amit Srivastava In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: ietf@ietf.org At 3/31/2000:08:49 AM, Beecher Adams wrote: Hi, This thread belongs on snmpv3@lists.tislabs.com and probably not on ietf@ietf.org. Moreover, I haven't been following this thread real closely and I'm not sure who owns the following quoted material but: >The normal use of error-index is to indicate which varbind may have been the >source of the error. I suspect many agents don't get this fancy though and >don't make use of the field. Very wrong. Only a very broken agent would not use the error-index field to point to the varbind for which an error-status is being returned. >I'm proposing to use this field instead as an index to an error details table. This is a non-starter due to error in your suspicion above. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From owner-ietf-outbound Fri Mar 31 18:20:29 2000 Received: by ietf.org (8.9.1a/8.9.1a) id SAA19252 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 18: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 ESMTP id SAA19216 for ; Fri, 31 Mar 2000 18:15:03 -0500 (EST) Received: (from hta@localhost) by dokka.maxware.no (8.9.3/8.9.3) id BAA05118 for ietf@ietf.org; Sat, 1 Apr 2000 01:15:03 +0200 Date: Sat, 1 Apr 2000 01:15:03 +0200 From: Harald Tveit Alvestrand Message-Id: <200003312315.BAA05118@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). For fun, there is a special list for the rejected messages: ietf+censored-rejects@alvestrand.no - subscribe in the same fashion, by [2]mail to ietf+censored-rejects-request@alvestrand.no By public request, the current set of filters are listed at [3]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 [4]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 [5]< Harald@Alvestrand.no> References 1. mailto:ietf+censored-request@alvestrand.no?body=subscribe 2. mailto:ietf+censored-rejects-request@alvestrand.no?body=subscribe 3. http://www.alvestrand.no/cgi-bin/hta/ietf+censored-filters 4. http://www.alvestrand.no/posting-counts.html 5. mailto:harald@alvestrand.no From owner-ietf-outbound Fri Mar 31 20:00:17 2000 Received: by ietf.org (8.9.1a/8.9.1a) id UAA20186 for ietf-outbound.10@ietf.org; Fri, 31 Mar 2000 20:00:01 -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 ESMTP id TAA20089 for ; Fri, 31 Mar 2000 19:54:10 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id QAA03471; Fri, 31 Mar 2000 16:53:55 -0800 (PST) Date: Fri, 31 Mar 2000 16:53:55 -0800 (PST) From: "James P. Salsman" Message-Id: <200004010053.QAA03471@shell9.ba.best.com> To: ietf@ietf.org, www-html@W3.ORG Subject: Re: Standards development (was HTML forms) Cc: correspondent-address-supressed@bovik.org In-Reply-To: <003f01bf9b69$7aebac40$039b9b9b@inanis> X-Loop: ietf@ietf.org Dan, Thanks for your questions: > Why are you so intent on getting this put into W3C specs, > and into implementation on user agents? My goal has never been to get published in any particular organizations' specs; only to get the major browsers to implement microphone upload suitable for language instruction, on all feasible platforms. While I was working within the W3C, I didn't realize how much Microsoft and Intel were benefiting from the non-interoperable OBJECT/EMBED tags (normative or informative, platform dependence is antithetical to the stated mission of the W3C.) And even if I had brought it up then, I have no reason to believe it would have done any good; I was in enough trouble as it was with those who seem to believe that the ability to specify pre-selected defaults is good user interface design. The only public W3C argument for that position amounts to -- and this is a direct quote -- "any proposal that suggests markup that includes the word 'device', ... should ring alarm bells." My opinion on that matter is that any user interface rubric that generalizes markup form and style over function and substance should ring louder alarms. An affirmative stance taken by the W3C would be preferable for many reasons, but the IETF's 'text/html' registration could do in a pinch. I'm not willing to make that formal proposal without asking the W3C some more questions and giving them more time to consider the aspects of the device upload specification that they have never addressed in public at all, and in most cases have not addressed even within their members-only HTML Working Group discussion areas: First, the Content-device header, which would enable a server to tell whether a picture, for example, came from a scanner or a camera, or whether a sound file came from disk or a microphone. Second, the Content-type-alternates header, which would allow for some rudimentary content negotiation, for example sending a jpeg when the gif format was unsupported or vice versa. Third, the MAXTIME attribute, which would allow compressed media with nonzero durations (e.g., sound and video but not images or text) to be limited by a maximum number of seconds instead of the less useful maximum number of bytes. Forth, the various security considerations in the draft: http://www.bovik.org/device-upload.html#Security Fifth, there is the matter mentioned above, regarding the selection of a default input DEVICE, upon which the HTML Working Group chair and I have agreed to disagree. This is a vital issue because of the legacy implementations that browsers have chosen for the ACCEPT attribute, using it as a filename pattern instead of a list of MIME types. The presence of the DEVICE attribute would allow them to make a clean break from that legacy interpretation of ACCEPT, removing one of the claimed barriers to implementation. There are other minor issues too, but the first two above are very important because they were brought about by the specific requests of the IETF Application Area during the IANA Content-type header registration process. The W3C has repeatedly refused to accept revisions to the original flawed NOTE -- http://www.w3.org/TR/device-upload -- in accord with those recommendations from the IETF, even after revisions were submitted by another of the W3C's own members. If the W3C continues to refuse revisions to multipart/form-data header parameters explicitly rejected by the IETF, why shouldn't the IETF make a corresponding amendment to the text/html MIME type registration? > What's wrong with using other applications that can do > exactly the same thing? That's the heart of the matter: What will people actually use for educational applications? The best implementations of the best specification aren't worth the electrons they're written on unless they actually benefit educational applications such as spoken language instruction, along with asynchronous audio conferencing, transcription from dictation, and the high-quality transmission of device input under low-bandwidth conditions. That last problem would benefit more of the decision-making Internet community than any educational application -- imagine! high-quality async voice messaging on your portable wireless box!!! -- but is not the source of my passion for the last remaining anytime/anyplace learning hurdle: spoken language instruction. Cheers, James