Received: from ietf.org by ietf.org id aa29124; 1 Nov 96 2:41 EST Received: from dxmint.cern.ch by ietf.org id aa28845; 1 Nov 96 2:30 EST Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id IAA08657; Fri, 1 Nov 1996 08:29:33 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA16033; Fri, 1 Nov 1996 08:29:28 +0100 Message-Id: <9611010729.AA16033@dxcoms.cern.ch> Subject: Re: The cartel begins to crumble? To: Steve Peterson Date: Fri, 1 Nov 1996 08:29:28 +0100 (MET) Sender:ietf-request@ietf.org From: Brian Carpenter CERN-CN Cc: karl@mcs.net, ietf@ietf.org In-Reply-To: <3.0.32.19961031181820.00cd8be4@mailhub.ry.com> from "Steve Peterson" at Oct 31, 96 06:18:21 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. >--------- Text sent by Steve Peterson follows: ... > OK, I'll bite. I hereby claim all TLDs that no one has yet registered with > either Alternic or IANA. > > I can't do that? Why not? You can claim anything you want. I hereby claim that I'm the Emperor Napoleon. Does that make it true? Brian Carpenter   Received: from ietf.org by ietf.org id aa00006; 1 Nov 96 3:10 EST Received: from songbird.com by ietf.org id aa29928; 1 Nov 96 3:08 EST Received: (from kent@localhost) by songbird.com (8.7.4/8.7.3) id BAA20090; Fri, 1 Nov 1996 01:09:18 -0800 Sender:ietf-request@ietf.org From: Kent Crispin Message-Id: <199611010909.BAA20090@songbird.com> Subject: Re: The cartel begins to crumble? To: Brian Carpenter CERN-CN Date: Fri, 1 Nov 1996 01:09:18 -0800 (PST) Cc: ietf@ietf.org In-Reply-To: <9611010729.AA16033@dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Nov 1, 96 08:29:28 am Content-Type: text Source-Info: From (or Sender) name not authenticated. Brian Carpenter CERN-CN allegedly said: > > >--------- Text sent by Steve Peterson follows: > ... > > OK, I'll bite. I hereby claim all TLDs that no one has yet registered with > > either Alternic or IANA. > > > > I can't do that? Why not? > > You can claim anything you want. I hereby claim that I'm the > Emperor Napoleon. Does that make it true? > > Brian Carpenter That is, of course, exactly the point Steve was making...perhaps it was a bit subtle... -- Kent Crispin"No reason to get excited", kent@songbird.com,kc@llnl.govthe thief he kindly spoke... PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E   Received: from ietf.org by ietf.org id aa01028; 1 Nov 96 3:30 EST Received: from eunet.EU.net by ietf.org id aa00953; 1 Nov 96 3:28 EST Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id JAA03777; Fri, 1 Nov 1996 09:27:36 +0100 (MET) Received: by jotun.EU.net id AA03580 (5.67a/IDA-1.5); Fri, 1 Nov 1996 09:27:35 +0100 Message-Id: <199611010827.AA03580@jotun.EU.net> Sender:ietf-request@ietf.org From: Per Gregers Bilse Date: Fri, 1 Nov 1996 09:27:34 +0100 In-Reply-To: <199610312324.RAA21892@Mars.mcs.net> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Karl Denninger Subject: Re: The cartel begins to crumble? Cc: ietf@ietf.org, frezza@interramp.com Source-Info: From (or Sender) name not authenticated. On Oct 31, 17:24, Karl Denninger wrote: > The second person who claims *ANY* TLD is the one to ignore. > > Not the first. Well, what are you doing messing with my domain, then? I claimed .biz and several other potential TLDs over three years ago: On Sep 23, 10:10, Per Gregers Bilse wrote: > From bilse Thu Sep 23 10:10:11 1993 > Received: by mcsun.EU.net with SMTP > id AA03195 (5.65b/CWI-2.232); Thu, 23 Sep 1993 10:10:06 +0200 > Message-Id: <9309230810.AA03195@mcsun.EU.net> > From: Per Gregers Bilse > Date: Thu, 23 Sep 1993 10:10:05 +0200 > Organization: EUnet NOC > Sender: bilse@mcsun.EU.net > X-Mailer: Mail User's Shell (7.2.2 4/12/91) > To: hostmaster@mcsun.EU.net > Subject: Claim for new TLDs > Status: OR > > Dear hostmaster, > > In anticipation of liberalisation of TLD management in the > future, I'd hereby like to claim all new TLDs that may be > created. Of special interest is of course snappy and neat > domains, like .inc, .ftp, .gopher, .biz, and ... uhh .. .sex,-) > but I'd really like to claim all of them. Is this possible? > > Best regards, > > -- > bilse +31 20 592 5109 (dir: 5110); fax +31 20 592 5163 > >-- End of excerpt from Per Gregers Bilse On Sep 23, 10:34, hostmaster@mcsun.EU.net wrote: > From bilse Thu Sep 23 10:34:14 1993 > Received: by mcsun.EU.net with SMTP > id AA03978 (5.65b/CWI-2.232); Thu, 23 Sep 1993 10:34:09 +0200 > Message-Id: <9309230834.AA03978@mcsun.EU.net> > From: hostmaster@mcsun.EU.net > Date: Thu, 23 Sep 1993 10:34:08 +0200 > In-Reply-To: <9309230810.AA03195@mcsun.EU.net> > Organization: EUnet NOC > Sender: bilse@mcsun.EU.net > X-Mailer: Mail User's Shell (7.2.2 4/12/91) > To: Per Gregers Bilse > Subject: Re: Claim for new TLDs > Status: OR > > On Sep 23, 10:10, Per Gregers Bilse wrote: > > In anticipation of liberalisation of TLD management in the > > future, I'd hereby like to claim all new TLDs that may be > > created. Of special interest is of course snappy and neat > > domains, like .inc, .ftp, .gopher, .biz, and ... uhh .. .sex,-) > > but I'd really like to claim all of them. Is this possible? > > You can't claim any and all future domains just like that, but > you can have the ones you mention no problem; noted in > /documents/domain-claim on ns.EU.net, also visible via gopher > and ftp. If you'd like to claim more TLDs, please get back to > me with a list. > > Best regards, > > Hostmaster for the day, > > -- > bilse +31 20 592 5109 (dir: 5110); fax +31 20 592 5163 > >-- End of excerpt from hostmaster@mcsun.EU.net The domain-claim file is no longer on line. I guess you'll blatantly state that the above email is fake, and that no such claim was ever registered. What if I produce a backup tape, proving I'm right? -- ------ ___ --- Per G. Bilse, Mgr Network Operations ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse@EU.net   Received: from ietf.org by ietf.org id aa01579; 1 Nov 96 3:37 EST Received: from cnri by ietf.org id aa01495; 1 Nov 96 3:35 EST Received: from mailhost01.primenet.com by CNRI.Reston.VA.US id aa04433; 1 Nov 96 3:35 EST Received: from primenet.primenet.com (ip-20-126.phx.primenet.com [206.165.20.126]) by primenet.com (8.8.2/8.8.2) with SMTP id BAA29964 for ; Fri, 1 Nov 1996 01:34:43 -0700 (MST) Message-ID: <3279B51D.75CD@primenet.com> Date: Fri, 01 Nov 1996 01:30:21 -0700 Sender:ietf-request@ietf.org From: Stephen32 X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: ietf@CNRI.Reston.VA.US Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. unsubscribe   Received: from ietf.org by ietf.org id aa03057; 1 Nov 96 4:15 EST Received: from sigma.itu.ch by ietf.org id aa02975; 1 Nov 96 4:11 EST Received: from MR.ITU.CH by ITU.CH (PMDF V5.0-6 #16074) id <01IBBT77GY4G99G8TI@ITU.CH>; Fri, 01 Nov 1996 10:06:53 +0200 Received: with PMDF-MR; Fri, 01 Nov 1996 09:02:25 +0200 MR-Received: by mta TIES.MUAS; Relayed; Fri, 01 Nov 1996 09:02:25 +0200 MR-Received: by mta TAU; Relayed; Fri, 01 Nov 1996 09:02:30 +0200 Disclose-recipients: prohibited Date: Fri, 01 Nov 1996 09:02:25 +0200 Sender:ietf-request@ietf.org From: shaw Subject: Re: The cartel begins to crumble? In-reply-to: <199611010827.AA03580@jotun.EU.net> To: ietf , Karl Denninger Cc: Karl Denninger , frezza , bilse@eu.net Message-id: <7825021001111996/A05718/TAU/11AB0A821700*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Importance: normal Priority: normal UA-content-id: 11AB0A821700 X400-MTS-identifier: [;7825021001111996/A05718/TAU] Hop-count: 1 Source-Info: From (or Sender) name not authenticated. >On Oct 31, 17:24, Karl Denninger wrote: >> The second person who claims *ANY* TLD is the one to ignore. >> >> Not the first. > >Well, what are you doing messing with my domain, then? I >claimed .biz and several other potential TLDs over three >years ago: > OK, since we're all having so much fun, here's another claim. The Bank fur Internationalen Zahlungsausgleich (BIZ) (in English that's the Bank for International Settlements) has trademarked 'biz' in 10 countries for 20 years including in the classes for telecommunications and computer programming services. Trademark registration number 418611 through the World Intellectual Property Organization (WIPO). ;-) Robert ITU   Received: from ietf.org by ietf.org id aa03682; 1 Nov 96 4:29 EST Received: from Hugin.mainz.dk by ietf.org id aa03573; 1 Nov 96 4:28 EST Date: Fri, 01 Nov 1996 10:34:46 +0100 Sender:ietf-request@ietf.org From: Kim Wohlert Subject: RE: The cartel begins to crumble? To: 'Karl Denninger' Cc: "'ietf@ietf.org'" , "'frezza@interramp.com'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Source-Info: From (or Sender) name not authenticated. On Thursday, 31 October, 1996 21:00, Karl Denninger[SMTP:karl@mcs.net] wrote: > > >I also believe that the cost to implement this is TRIVIAL (few thousand > >dollars a year) and I'm even willing to host it (free) if that's what it > >takes to get the job done. > > Doesn't that make YOU the cartel? > >Let's say we define it like this: > > > >1)No more than 3 pending TLDs for an organization, no more than (say) > >five TLD registrations from an organization in a 30 day period. > >Affiliated (ie: significantly and operationally owned - 5% or more, > >use SEC rules on what "operational influence" is) companies count. As far as I am concerned, SEC is a US 'thing' that has absolutely no merit internationally, so you can't use those rules. Every nation will have its own definitions of "company", "operations influence" etc. > >2)Activation must be within 30 days of declaration of intent or the > >name gets released back. Activation is defined as customers being > >able to register under the domain with a published set of policies. Who will police that? You? > >3)Beyond this, fight in court. (On the premise that courts generally > >are expensive, its only worth it with a 2+ billion entry namespace > >if someone has REALLY wronged you, and I believe in the rule of law > >not dictators, self-important ones included.) What court/law? US?, California?, Armenia?, Bahamas? (continue the list youself) > >4)Prove fraud in the above and the offender gets removed entirely. > >(ie: penalties for cheating people are so obscene nobody will > >attempt it, and further, probably also passes legal scrutiny. > >The process HAS TO BE fair, recognize first-use somehow since that's > >what existing law is based on, and be reasonably-immune to abuse). Prove to whom? By what definition of fraud? And who gets to remove the offender? You? > > > >A minimalist philosophy towards the problem. No, a nationalist. > > > >I believe that the solution is for everyone to develop their own policies > >for TLDs (just like we have for SLDs now) if you wish to be one of the > >"authorities" for it, along with a dispute resolution procedure ("sue each > >other" is good enough) *AND* an explicit agreement to honor FCFS on the > >above (or something similar) guidelines. But if you want FCFS, someone has to decide what 'First' is? So in effect you are replacing one cartel with another - where is the benefit? > >- Kim -- Kim Wohlert |Internet:Kim.Wohlert@mainz.dk erik mainz a/s | Dortheavej 7 | DK-2400 Copenhagen |Phone: +45 38 34 77 88 Denmark |Fax: +45 31 19 16 25 --- "Enough about me, lets talk about you. What do you think of me?"   Received: from ietf.org by ietf.org id aa01968; 1 Nov 96 8:46 EST Received: from thunder.ncr.disa.mil by ietf.org id aa01325; 1 Nov 96 8:27 EST Received: from ncr.disa.mil ([164.117.176.106]) by thunder.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id IAA02539; Fri, 1 Nov 1996 08:11:56 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA846865527; Fri, 01 Nov 96 08:22:44 EST Date: Fri, 01 Nov 96 08:22:44 EST Sender:ietf-request@ietf.org From: David Gaon Message-Id: <9610018468.AA846865527@ncr.disa.mil> To: ietf@ietf.org, Lars Poulsen Subject: Re[2]: The cartel begins to crumble? Source-Info: From (or Sender) name not authenticated. Although the .US is available, US entities and IANA have not enforced it. Instead, they have created international or global TLDs (.com, .edu, ...) and, as expected, allowed registration willy-nilly without regards to nationality. Although creating TLDs under the .US (and hopefully eliminating the global TLDs) will solve some of the problems with crowding of TLDs, it will not solve the copyright/trademark issue. This means that companies like IBM will register in multiple domains simply to safeguard their copyright, and there will be contention by others for the use of .IBM.US Thus, the creation of TLDs perpetuates the problems rather than solve them. It appears to me that the simple solution is the creation of dsitributed directories. With the use of Directories, individuals can get a listing of all entities they wish to address that have IBM as 3 letters in their call sign or as the mnemonic of their name. The user will then selects the entry of the entity he wishes to contact and uses the corresponding network address for their mail, web, voice, fax, .... other services as they come along. He clearly does not have to retype anything, just click and go. He also has the option to store that infomration on his own machine for future use, which obviates the need for another Directory ping (saves $$$). It really is very simple and an enterprising company can make a handsome profit on it as well. What if IANA, ATT, or Joe Schmoe Directory Service do the following: - create distributed directories located strategically - for a fee (I estimate $5.00) publish on CD all the addressable port numbers they know of (voice, data, video, ...). The information is public knowledge, already in electronic form, and needs to be formatted in the directory database - the user would buy a directory utility(user agent) to run on his PC (I estimate $30.00) from the likes of Microsoft. The user agent may even be embedded and given free in the operating system. The technology is there (X.500), so it is not rocket science. I am surprised Microsoft has not done that already. Cheers David Gaon DoD/DISA/Center for Standards ______________________________ Reply Separator _________________________________ Subject: Re: The cartel begins to crumble? Author: Lars Poulsen at smtp Date: 10/31/96 7:05 PM In article <199610302337.PAA10804@server.livingston.com> megazone@livingston.com (MegaZone) writes: >I DO feel that we need new name space, it is damn crowded now. I think >a .per domain (personal sites) would be useful, so many people have personal >domains (Heck, I just applied for a .org for personal use). It would also >be nices to have some differentiation between ISPs and corporations online. >.com is already to fixed, maybe a new .isp and .cor TLDs. The *.COM TLD is crowded, but only because everyone seems to want to crowd into it ... probably exactly because it is so crowded. For people and companies located in the USA, there is already an alternative tree under the *.US TLD. This could be made even more useful by the addition of a set of industry trees adjacent to the geographical (by state) trees; how about: *..AUTO.US e.g. www.Chicago.Ford.Auto.US could hold a directory of Ford dealers in that city. .RADIO.US .TV.US e.g. www.WGBH.TV.US seems like the place to look for a program schedule from the PBS affiliate in Boston *.NETWORK.US e.g. ANS.NETWORK.US and NET-99.NETWORK.US are great places to look for ISPs. and BAY.NETWORK.US or ASCEND.NETWORK.US are well known manufacturers. Has IANA authorized anything other than state names under *.US yet ? If not, why not ? -- / Lars Poulsen Internet E-mail: lars@RNS.COM RNS / Meret Communications Phone: +1-805-562-3158 7402 Hollister Avenue Telefax: +1-805-968-8256 Santa Barbara, CA 93117 Internets: designed and built while you wait   Received: from ietf.org by ietf.org id aa05071; 1 Nov 96 9:45 EST Received: from localhost by ietf.org id aa03454; 1 Nov 96 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hernacki-nntpsrch-01.txt Date: Fri, 01 Nov 1996 09:27:39 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611010927.aa03454@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : NNTP Full-text Search Enhancements Author(s) : B. Hernacki, B. Polk Filename : draft-hernacki-nntpsrch-01.txt Pages : 15 Date : 10/31/1996 This document describes a set of enhancements to the Network News Transport Protocol [NNTP-977] that allows full-text searching of news articles across multiple newsgroups. This new search mechanism also allows search criteria to be saved into search profiles. Articles arriving on the server are checked against the profiles, and the articles that match are collected together for the client. The availability of the extensions described here will be advertised by the server using the extension negotiation-mechanism described in the new NNTP protocol specification currently being developed [NNTP-NEW]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hernacki-nntpsrch-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-hernacki-nntpsrch-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-hernacki-nntpsrch-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961031151159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hernacki-nntpsrch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-hernacki-nntpsrch-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961031151159.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05086; 1 Nov 96 9:45 EST Received: from localhost by ietf.org id aa03470; 1 Nov 96 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-eastlake-muse-01.txt Date: Fri, 01 Nov 1996 09:27:43 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611010927.aa03470@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mail Ubiquitous Security Extensions (MUSE) Author(s) : D. Eastlake Filename : draft-eastlake-muse-01.txt Pages : 20 Date : 10/31/1996 Secure electronic mail can provide authentication of the source of mail and confidentiality for its contents. These features are becoming increasingly important as the Internet grows exponentially and email is increasingly used for critical, sensitive, and confidential communications. However, use of secure mail is not widespread due to the problems of key distribution and lack of migration to secure mail enabled user agents. This draft proposes partial solutions to these two problems by using coarser grained identity to permit authentication and confidentiality without user agent change, and DNS security for key distribution. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eastlake-muse-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-eastlake-muse-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-eastlake-muse-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961031162257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-eastlake-muse-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-eastlake-muse-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961031162257.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06790; 1 Nov 96 10:06 EST Received: from doorstep.unety.net by ietf.org id aa06577; 1 Nov 96 10:03 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id IAA26992; Fri, 1 Nov 1996 08:58:08 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC7D3.03A82A40@webster.unety.net>; Fri, 1 Nov 1996 08:59:39 -0600 Message-ID: <01BBC7D3.03A82A40@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "ietf@ietf.org" , "James E. [Jed] Donnelley" , 'Phil Karn' Subject: RE: Folling the crumbling cartel - a note about thread following Date: Fri, 1 Nov 1996 08:59:38 -0600 Encoding: 231 TEXT Source-Info: From (or Sender) name not authenticated. On Tuesday, October 29, 1996 10:26 PM, Phil Karn[SMTP:karn@qualcomm.com] wrote: @ >The "cartel" discussion started, as I expect we all know, with @ >Bill @ Frezza's article: @ @ Bill Frezza appears to be a journalistic gadfly who specializes in attacking @ large, successful technology organizations. He has written a series of @ articles @ attacking Qualcomm CDMA that, in my opinion, are best characterized as @ "vicious", @ as opposed to merely "uninformed" or "muckraking". @ @ He is best not taken too seriously. @ @ Phil @@@@@@@@@@@@@@@ Dear Phil...we have all come a long way...in a short time... I hope that you take this work seriously.... JF @@@@@@@@@@@@@@@ Saturday, October 26, 1996 Root-64 Weekly Status Report Several people have expressed interest in some sort of weekly summary. This will help busy people get an overview of the progress being made without getting involved in the daily discussions. This past week was very busy, the NSF and the FNC (Federal Networking Council) met and based on the early reports from that meeting, the FNC is recommending that the NSF work hard to divest itself from the top level domain issues and the management of the popular root name servers. Hopefully, the NSF will see that projects like the Root-64 Project will help accelerate this process. Attached is the growing list of root name servers which are being deployed around the world. This list helps to illustrate that the commercial world as well as non profit organizations are willing to step in as the NSF and the U.S. Government withdraw support. Additional root name servers will provide the stability needed to grow the Internet beyond the current R&D architecture supported by the NSF. As shown below, the major recent changes are: England: Keith Mitchell - keith@linx.org has expressed interest in the project and appears to have a very strategic location and facilties in the U.K. to provide support for not only the U.K. but surrounding regions. France: Laurent BERNARD - lbernard@artinternet.fr is very enthusiastic about getting involved from his Paris based ISP. He has volunteered to help develop a root DNS FAQ, which hopefully may also be available in French. Australia: Andrew Khoo - andrew@aussie.net has indicated that his management is supportive of the project and would like more information to help them bring a root name server to Australia. ISOC/IAHC: The Internet Society, under Don Heath's (heath@linus.isoc.org) direction, is starting to make progress. They have appointed a committee to discuss all of the issues of the top level domains. Only one of the members of the committee, Perry Metzger, was active in the "newdom" discussions this past year. It is still not clear if they intend to host a root name server. That may be one of the topics that their committee discusses. It is still too early to tell. @@@@@ 0 - Legacy Internet, R&D, Education, Etc. 0 - IANA - U.S.- Southern California - NS1.ISI.EDU - 128.9.0.107 1 - InterNIC - U.S. - Virginia - NS.INTERNIC.NET - 198.41.0.4 2 - NANOG - ??? 3 - ISP/C - ??? 4 - MERIT - ??? 5 - IETF - U.S. - California - NS.ISC.ORG - 192.5.5.241 6 - ISOC - Contact Don Heath - heath@linus.isoc.org IAHC - Contact ??? 1 - Perry Metzger - perry@piermont.com 2 - David Crocker - 3 - Jeff Houston 4 - Hank Nusbacher 5 - David Maher 6 - Sally Abel 7 - Robert Shaw 8 - WIPO representative 9 - ??? 7 - WIA - ??? 1 - North America (U.S., Mexico, Canada) 0 - U.S. - Northwestern - AlterNIC - MX.ALTERNIC.NET - 204.94.42.1 1 - U.S. - Illinois - MCS Net - ROOT-NS.MCS.NET - 192.160.127.86 2 - U.S. - Michigan - AGN Net - SIMBA.AGN.NET - 160.79.1.3 3 - U.S. - Wisconsin - SPARKNET.NET - ROOT-NS.THENIC.NET - 207.67.22.81 4 - U.S. - Maryland - TERP.UMD.EDU - 128.8.10.90 5 - Canada - Ontario - TORONTO.ALTERNIC.NET - 207.107.232.106 6 - Mexico - http://www.nic.mx ??? 7 - U.S. - Southeastern - C.PSI.NET - 192.33.4.12 2 - South America, Central America and the Caribbean 0 - U.S. Virgin Islands - USVI.NET - 204.199.0.4 1 - British Virgin Islands - ??? 2 - Brazil - ??? 3 - Argentina ??? 4 - Venezula - Contact Peter de Blanc - pdeblanc@usvi.net 5 - Bolivia ??? 6 - Costa Rica??? 7 - Panama ??? 3 - England, Europe, Scandanavia and Russia 0 - RIPE - Netherlands - http://www.eu.net ??? 1 - Sweden - NIC.NORDU.NET - 192.36.148.17 2 - England - Contact Keith Mitchell - keith@linx.org 3 - France - Contact Laurent BERNARD - lbernard@artinternet.fr 4 - Germany - ??? 5 - Switzerland - ??? 6 - Italy - ??? 7 - Ukraine - NS.WW.NET - 193.124.73.100 4 - Japan, Korea, China and The Pacific Rim 0 - APNIC - http://www.apnic.net ??? 1 - Japan - http://www.nic.ad.jp ??? 2 - Korea - http://www.krnic.net ??? 3 - 4 - Taiwan - http://www.twnic.net ??? 5 - China - http://www.cnc.ac.cn ??? 6 - Philippines - http://www.ph.net ??? 7 - Hong Kong - http://www.cuhk.hk/hkwww.html ??? 5 - Asia, Africa and the Middle East 0 - 1 - India - http://www.iisc.ernet.in/innic.html ??? 2 - Pakistan - http://www.ar.pk/public/pknic.html ??? 3 - Bangladesh - http://www.bangla.org/bdinet ??? 4 - Israel - ??? 5 - Saudi Arabia - ??? 6 - South Africa - ??? 7 6 - Australia, New Zealand, Southeast Asia and the South Pacific 0 - Australia - Contact Andrew Khoo - andrew@aussie.net 1 - New Zealand - http://servius.waikato.ac.nz/isocnz ??? 2 - Singapore - http://www.nic.net.sg ??? 3 - Thailand - http://www.thnic.net ??? 4 - Indonesia - http://www.iptek.net.id/ipteknet_eng.html ??? 5 - Guam - http://ns.gov.gu ??? 6 - Malaysia - NS.ALPHAQUE.COM - 202.185.254.12 7 - 7 - Vehicles, Boats, Spaceships, Ham Radio, etc. 0 - NS.NASA.GOV - 192.203.230.10 1 - NS.NIC.DDN.MIL - 192.112.36.4 2 - AOS.ARL.ARMY.MIL - 128.63.2.53 3 - NS.UNETY.NET - 207.32.128.1 4 - 5 - 6 - 7 - @@@@ A variety of people are starting to write software, scripts, documentation, etc. that will be needed to coordinate the updates for all of the root name servers. For people that want a Java view of the servers, the temporary web site, http://www.unety.net/Java/root.html has a demo. Chris Sevcik - chris@sparknet.net has been exploring some interesting ideas about a web sites, etc. Chris has pointed out the need for a web site that helps document who the contacts are for the above root name servers. Alexis Yushin - alexis@dawn.ww.net of Ukraine has expressed interest in moving the discussion forward on the technology needed to keep the world wide collection of root name servers in synch. I would encourage everyone to work with Alexis on these important projects. John Palmer - newdom@Taka.AGN.NET reported that their "whois" database is up and working for the .EARTH and .USA top level domains. John provided both URLs as just another example of how the new TLDs can coexist with the "popular" TLDs. http://www.earth/whois.html http://www.agn.net/whois.html Peter deBlanc -pdeblanc@usvi.net reports that he is making good progress in Venezula and hopes to have some news in early November. South America is clearly an area where more progress is needed. If anyone wants to explore those regions, cruise on down there. The NANOG group met in Ann Arbor this week. I did receive a response from them, but I do not anticipate any news until the results of their meetings are digested. The operator of the OLD newdom mailing list has suggested closing the list. Several of the members of that list have now subscribed to the NEW newdom list. Richard J. Sexton, the operator of the new list wants to remind everyone that there is a web site for people to subscribe. Please circultate this URL . On the International front, there are meetings next week in Geneva, Switzerland. Stay tuned to the following web site for more info http://www.wia.org It should be clear from that web site that many stakeholders are now involved in the Internet, and some of them will want to take part in helping to provide stability via the deployment of root name servers. Stay tuned for next week's report...inputs are welcome...;-) P.S. As far as I know, none of the above work was funded by the NSF, or the U.S. government. All of the work is being done by private citizens and companies who volunteer their time and resources to these efforts. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8) -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa07147; 1 Nov 96 10:13 EST Received: from doorstep.unety.net by ietf.org id aa07019; 1 Nov 96 10:13 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id JAA27040; Fri, 1 Nov 1996 09:07:18 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC7D4.4C698AC0@webster.unety.net>; Fri, 1 Nov 1996 09:08:51 -0600 Message-ID: <01BBC7D4.4C698AC0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "ietf@ietf.org" , "James E. [Jed] Donnelley" , 'Phil Karn' Cc: 'New Newdom' Subject: Serious Business Date: Fri, 1 Nov 1996 09:08:49 -0600 Encoding: 76 TEXT Source-Info: From (or Sender) name not authenticated. On Tuesday, October 29, 1996 10:26 PM, Phil Karn[SMTP:karn@qualcomm.com] wrote: @ >The "cartel" discussion started, as I expect we all know, with @ >Bill @ Frezza's article: @ @ Bill Frezza appears to be a journalistic gadfly who specializes in attacking @ large, successful technology organizations. He has written a series of @ articles @ attacking Qualcomm CDMA that, in my opinion, are best characterized as @ "vicious", @ as opposed to merely "uninformed" or "muckraking". @ @ He is best not taken too seriously. @ @ Phil @ @@@@@@@ Dear Phil, I also hope that you take this statement from Paul Vixie... ...."seriously"... ...this is all very serious business...and just think, much of it started out right there in the E Aisle in Building 6... ...not long ago...(in Earth years)....;-) JF @@@@@@@ ---------- From:Paul A Vixie[SMTP:paul@vix.com] Sent:Thursday, October 31, 1996 12:56 PM To:newdom@vrx.net Subject:requirements for participation I have told the IANA and I have told InterNIC -- now I'll tell you kind folks. If IANA's proposal stagnates past January 15, 1997, without obvious progress and actual registries being licensed or in the process of being licensed, I will declare the cause lost. At that point it will be up to a consortium of Internet providers, probably through CIX if I can convince them to take up this cause, to tell me what I ought to put into the "root.cache" file that I ship with BIND. I am willing to wait for the lawyers to do what they think is necessary but I am only willing to wait *so*long*. At some point it will become necessary for the people who own the majority of the fabric to decide what names should be available to their customers. I do not expect "root-64" or Alternic et al to be any more relevant then, than it is now. A thing badly begun is *very* hard to repair later. You guys are just rabble in my opinion, and I do not think that your efforts will sway the people I intend to listen to. But there are limits to my support for the now-ISOC process. Now you know. Oh, and one more thing: I'm not in the registry business and won't ever be. I might charge folks to write software to help run registries but I won't ever collect any money in exchange for registering a name. If the Internet Software Consortium decided to get funding in exchange for names, I would cease all projects funded by ISC grants. I am **NOT** in this for the money. @@@@@ -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa07195; 1 Nov 96 10:14 EST Received: from Kitten.mcs.com by ietf.org id aa07094; 1 Nov 96 10:13 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id JAA18373; Fri, 1 Nov 1996 09:12:38 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 09:12 CST Received: (from karl@localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id JAA06591; Fri, 1 Nov 1996 09:12:36 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611011512.JAA06591@Mercury.mcs.net> Subject: Re: The cartel begins to crumble? To: Per Gregers Bilse Date: Fri, 1 Nov 1996 09:12:36 -0600 (CST) Cc: karl@mcs.net, ietf@ietf.org, frezza@interramp.com In-Reply-To: <199611010827.AA03580@jotun.EU.net> from "Per Gregers Bilse" at Nov 1, 96 09:27:34 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. Operational registries Per Gregers, nothing more or less. We have it (and had it first), you did not. I can declare myself emporer of the known universe, but unless I do something to demonstrate that I'm serious (ie: find a way to actually govern and enforce it across every person on the planet) all I get is laughed at. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > On Oct 31, 17:24, Karl Denninger wrote: > > The second person who claims *ANY* TLD is the one to ignore. > > > > Not the first. > > Well, what are you doing messing with my domain, then? I > claimed .biz and several other potential TLDs over three > years ago: > > On Sep 23, 10:10, Per Gregers Bilse wrote: > > From bilse Thu Sep 23 10:10:11 1993 > > Received: by mcsun.EU.net with SMTP > > id AA03195 (5.65b/CWI-2.232); Thu, 23 Sep 1993 10:10:06 +0200 > > Message-Id: <9309230810.AA03195@mcsun.EU.net> > > From: Per Gregers Bilse > > Date: Thu, 23 Sep 1993 10:10:05 +0200 > > Organization: EUnet NOC > > Sender: bilse@mcsun.EU.net > > X-Mailer: Mail User's Shell (7.2.2 4/12/91) > > To: hostmaster@mcsun.EU.net > > Subject: Claim for new TLDs > > Status: OR > > > > Dear hostmaster, > > > > In anticipation of liberalisation of TLD management in the > > future, I'd hereby like to claim all new TLDs that may be > > created. Of special interest is of course snappy and neat > > domains, like .inc, .ftp, .gopher, .biz, and ... uhh .. .sex,-) > > but I'd really like to claim all of them. Is this possible? > > > > Best regards, > > > > -- > > bilse +31 20 592 5109 (dir: 5110); fax +31 20 592 5163 > > > >-- End of excerpt from Per Gregers Bilse > > > On Sep 23, 10:34, hostmaster@mcsun.EU.net wrote: > > From bilse Thu Sep 23 10:34:14 1993 > > Received: by mcsun.EU.net with SMTP > > id AA03978 (5.65b/CWI-2.232); Thu, 23 Sep 1993 10:34:09 +0200 > > Message-Id: <9309230834.AA03978@mcsun.EU.net> > > From: hostmaster@mcsun.EU.net > > Date: Thu, 23 Sep 1993 10:34:08 +0200 > > In-Reply-To: <9309230810.AA03195@mcsun.EU.net> > > Organization: EUnet NOC > > Sender: bilse@mcsun.EU.net > > X-Mailer: Mail User's Shell (7.2.2 4/12/91) > > To: Per Gregers Bilse > > Subject: Re: Claim for new TLDs > > Status: OR > > > > On Sep 23, 10:10, Per Gregers Bilse wrote: > > > In anticipation of liberalisation of TLD management in the > > > future, I'd hereby like to claim all new TLDs that may be > > > created. Of special interest is of course snappy and neat > > > domains, like .inc, .ftp, .gopher, .biz, and ... uhh .. .sex,-) > > > but I'd really like to claim all of them. Is this possible? > > > > You can't claim any and all future domains just like that, but > > you can have the ones you mention no problem; noted in > > /documents/domain-claim on ns.EU.net, also visible via gopher > > and ftp. If you'd like to claim more TLDs, please get back to > > me with a list. > > > > Best regards, > > > > Hostmaster for the day, > > > > -- > > bilse +31 20 592 5109 (dir: 5110); fax +31 20 592 5163 > > > >-- End of excerpt from hostmaster@mcsun.EU.net > > > The domain-claim file is no longer on line. > > I guess you'll blatantly state that the above email is fake, > and that no such claim was ever registered. What if I produce > a backup tape, proving I'm right? > > -- > ------ ___ --- Per G. Bilse, Mgr Network Operations > ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. > ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL > --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 > --- ------- 24hr emergency number: +31 20 421 0865 > --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse@EU.net >   Received: from ietf.org by ietf.org id aa07591; 1 Nov 96 10:20 EST Received: from Kitten.mcs.com by ietf.org id aa07481; 1 Nov 96 10:19 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id JAA18670; Fri, 1 Nov 1996 09:17:51 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 09:17 CST Received: (from karl@localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id JAA08564; Fri, 1 Nov 1996 09:17:49 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611011517.JAA08564@Mercury.mcs.net> Subject: Re: The cartel begins to crumble? To: Kim Wohlert Date: Fri, 1 Nov 1996 09:17:48 -0600 (CST) Cc: karl@mcs.net, ietf@ietf.org, frezza@interramp.com In-Reply-To: from "Kim Wohlert" at Nov 1, 96 10:34:46 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > On Thursday, 31 October, 1996 21:00, Karl Denninger[SMTP:karl@mcs.net] > wrote: > > > > > > >I also believe that the cost to implement this is TRIVIAL (few thousand > > >dollars a year) and I'm even willing to host it (free) if that's what it > > >takes to get the job done. > > > > > Doesn't that make YOU the cartel? Again, the difference here is that I'm looking for consensus, not ramming things down people's throats. And I'm not DOING anything; the machine makes and enforces the rules (which we agree on) :-) > > >Let's say we define it like this: > > > > > >1)No more than 3 pending TLDs for an organization, no more than (say) > > >five TLD registrations from an organization in a 30 day period. > > >Affiliated (ie: significantly and operationally owned - 5% or more, > > >use SEC rules on what "operational influence" is) companies count. > > As far as I am concerned, SEC is a US 'thing' that has absolutely no > merit internationally, so you can't use those rules. > > Every nation will have its own definitions of "company", "operations > influence" etc. Ok, what if we say "any influence" and define it. Ie: overlapping boards of directors, etc. > > >2)Activation must be within 30 days of declaration of intent or the > > >name gets released back. Activation is defined as customers being > > >able to register under the domain with a published set of policies. > > Who will police that? You? The computer polices it. You file with the computer for the domains, the computer checks for working NS records in the zone and actual registrations. None there in 30 days, poof. > > >3)Beyond this, fight in court. (On the premise that courts generally > > >are expensive, its only worth it with a 2+ billion entry namespace > > >if someone has REALLY wronged you, and I believe in the rule of law > > >not dictators, self-important ones included.) > > What court/law? US?, California?, Armenia?, Bahamas? (continue the list > youself) The combatents have to select the venue, as they do now in any other arena. Its none of my (or your) business what venue two combatants want to sue each other in. Nor should we ATTEMPT to define it, as that inserts bias in the form of cost into the process. > > >4)Prove fraud in the above and the offender gets removed entirely. > > >(ie: penalties for cheating people are so obscene nobody will > > >attempt it, and further, probably also passes legal scrutiny. > > >The process HAS TO BE fair, recognize first-use somehow since that's > > >what existing law is based on, and be reasonably-immune to abuse). > > Prove to whom? By what definition of fraud? And who gets to remove the > offender? You? I believe the policy is difficult to mis-interpret. If you believe it is easy to misinterpret, then let's refine it until we're satisfied that it is IMPOSSIBLE to misinterpret. > No, a nationalist. Where do you get the idea that this has anything to do with the US? > > >I believe that the solution is for everyone to develop their own policies > > >for TLDs (just like we have for SLDs now) if you wish to be one of the > > >"authorities" for it, along with a dispute resolution procedure ("sue each > > >other" is good enough) *AND* an explicit agreement to honor FCFS on the > > >above (or something similar) guidelines. > > But if you want FCFS, someone has to decide what 'First' is? So in > effect you are replacing one cartel with another - where is the benefit? Again, define a process. Quit sniping at people and start looking at the PROBLEM. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id ab08246; 1 Nov 96 10:35 EST Received: from ng.netgate.net by ietf.org id aa08082; 1 Nov 96 10:32 EST Received: from [205.214.160.111] (d75.netgate.net [205.214.160.111]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id HAA14857; Fri, 1 Nov 1996 07:39:06 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <9610018468.AA846865527@ncr.disa.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 1 Nov 1996 07:26:54 -0800 To: David Gaon Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re[2]: The cartel begins to crumble? Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 5:22 AM -0800 11/1/96, David Gaon wrote: > It appears to me that the simple solution is the creation of > dsitributed directories. > With the use of Directories, individuals can get a listing of all > entities they wish to address that have IBM as 3 letters in their call > sign or as the mnemonic of their name. The user will then selects the David, There is great appeal to trying to solve registration and mapping problems by moving the task to a 'directory'. Such a suggestion crops up pretty regularly in discussions about difficult lookup tasks. It almost never really solves the problem. The difference I make between a mapping service, like the DNS, and a 'directory' service is that of determinism. You put in a precise query to a mapping service and you get zero or one information node back. You put in a query to a directory service and you might get any number of nodes back. Then you figure out which one you really want...maybe. A mapping service MUST be reasonably quick and completely deterministic. A directory service does not need to be either. Hence, a directory service MUST NOT be in the critical path of an infrastructure service. It's fine as an adjunct, but it simply isn't the direction to go for a service that returns addresses, especially when the lookup activity is in the middle of mainline system processing such as a mail forwarder. d/ ps.Even if one COULD use a directory, your suggestion doesn't solve the current problem. Say you and I each list acme.biz in our different directories and someone queries the distributed service, finding both entries. How do they choose? -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa08898; 1 Nov 96 10:39 EST Received: from atlas.xylogics.com by ietf.org id aa08684; 1 Nov 96 10:38 EST Received: from huey.xylogics.com (huey.xylogics.com [132.245.32.139]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id KAA02773; Fri, 1 Nov 1996 10:36:26 -0500 (EST) Received: by huey.xylogics.com id AA18153 (4.1/UK-doug-951219); Fri, 1 Nov 96 10:36:25 EST Sender:ietf-request@ietf.org From: Gary Scott Malkin Date: Fri, 1 Nov 96 10:36:25 EST Message-Id: <18153.9611011536@huey.xylogics.com> To: jed@llnl.gov Cc: ietf@ietf.org In-Reply-To: "James E. [Jed] Donnelley"'s message of Thu, 31 Oct 1996 17:37:30 -0800 Subject: The cartel begins to crumble? - .com crowding Source-Info: From (or Sender) name not authenticated. > >The *.COM TLD is crowded, but only because everyone seems to want to > >crowd into it ... probably exactly because it is so crowded. > > I think this is about right. A specific angle on this is that > I (and I suspect I am not alone) often will try Actually, I think that most people register under .com because they don't know that anything else exists. I don't think I've ever seen any URL advertised on TV that wasn't a .com. I think we could solve some of the crowding simply by insisting that a .com name truely be a company/corporation (i.e., not the name of a movie, or someones pet project). ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 238-6237 Pick two!   Received: from ietf.org by ietf.org id aa09971; 1 Nov 96 11:02 EST Received: from thunder.ncr.disa.mil by ietf.org id aa09775; 1 Nov 96 11:00 EST Received: from ncr.disa.mil ([164.117.176.106]) by thunder.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id KAA05585; Fri, 1 Nov 1996 10:45:08 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA846874750; Fri, 01 Nov 96 10:52:15 EST Date: Fri, 01 Nov 96 10:52:15 EST Sender:ietf-request@ietf.org From: David Gaon Message-Id: <9610018468.AA846874750@ncr.disa.mil> To: Dave Crocker Cc: ietf@ietf.org Subject: Re[3]: The cartel begins to crumble? Source-Info: From (or Sender) name not authenticated. David Croker All you say is true if the implementation of directory lookup is in the router. I am suggesting that the determination of the ""exact network address of the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is left to the user and is done offline (with respect to the communications infrastructure). The user, on deciding whom he wants to reach, either types in the corresponding port number in his e-mail or web access, or he passes it to his application (e-mail) which inserts it in the appropriate field. As for forwarder application, instead of sending mail to ietf@isetf.org, the user sends it to the exact address corresponding to that port. In inception of the forwarder, the translation of exact member addresses is done once (clearly updated later), but again done outside the main stream process of the application. Thus the task of the router is minimised and is as fast or even faster than present implementation depending on what is doing the name translation. Yes indeed, the user has to query the directory, search, and decide, but so what, eventually he will accumulate (in his application's cache) the port addresses of those he communicates with. Cheers David Gaon DoD/DISA/Center for Standards ______________________________ Reply Separator _________________________________ Subject: Re[2]: The cartel begins to crumble? Author: Dave Crocker at smtp Date: 11/1/96 10:31 AM At 5:22 AM -0800 11/1/96, David Gaon wrote: > It appears to me that the simple solution is the creation of > dsitributed directories. > With the use of Directories, individuals can get a listing of all > entities they wish to address that have IBM as 3 letters in their call > sign or as the mnemonic of their name. The user will then selects the David, There is great appeal to trying to solve registration and mapping problems by moving the task to a 'directory'. Such a suggestion crops up pretty regularly in discussions about difficult lookup tasks. It almost never really solves the problem. The difference I make between a mapping service, like the DNS, and a 'directory' service is that of determinism. You put in a precise query to a mapping service and you get zero or one information node back. You put in a query to a directory service and you might get any number of nodes back. Then you figure out which one you really want...maybe. A mapping service MUST be reasonably quick and completely deterministic. A directory service does not need to be either. Hence, a directory service MUST NOT be in the critical path of an infrastructure service. It's fine as an adjunct, but it simply isn't the direction to go for a service that returns addresses, especially when the lookup activity is in the middle of mainline system processing such as a mail forwarder. d/ ps. Even if one COULD use a directory, your suggestion doesn't solve the current problem. Say you and I each list acme.biz in our different directories and someone queries the distributed service, finding both entries. How do they choose? -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa13326; 1 Nov 96 11:59 EST Received: from pinky.junction.net by ietf.org id aa13222; 1 Nov 96 11:58 EST Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id JAA18182; Fri, 1 Nov 1996 09:11:54 -0800 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id IAA11634; Fri, 1 Nov 1996 08:53:00 -0800 Date: Fri, 1 Nov 1996 08:53:00 -0800 (PST) Sender:ietf-request@ietf.org From: Michael Dillon To: Jim Fleming cc: "ietf@ietf.org" , "James E. [Jed] Donnelley" , 'Phil Karn' , 'New Newdom' Subject: Re: Serious Business In-Reply-To: <01BBC7D4.4C698AC0@webster.unety.net> Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Fri, 1 Nov 1996, Jim Fleming wrote: > @ Bill Frezza appears to be a journalistic gadfly who specializes in attacking > @ large, successful technology organizations. He has written a series of > @ articles > @ attacking Qualcomm CDMA that, in my opinion, are best characterized as > @ "vicious", > @ as opposed to merely "uninformed" or "muckraking". > ...this is all very serious business...and just think, much of > it started out right there in the E Aisle in Building 6... Is that the building at AT&T where you worked together with Bill Frezza back in the early 80's on videotex/NAPLPS systems? Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com   Received: from ietf.org by ietf.org id aa15163; 1 Nov 96 12:12 EST Received: from doorstep.unety.net by ietf.org id aa14935; 1 Nov 96 12:10 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA27445; Fri, 1 Nov 1996 11:04:47 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC7E4.B54E5060@webster.unety.net>; Fri, 1 Nov 1996 11:06:19 -0600 Message-ID: <01BBC7E4.B54E5060@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Dave Crocker' , David Gaon Cc: "ietf@ietf.org" Subject: RE: Re[2]: The cartel begins to crumble? Date: Fri, 1 Nov 1996 11:06:17 -0600 Encoding: 233 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 01, 1996 9:26 AM, Dave Crocker[SMTP:dcrocker@brandenburg.com] wrote: @ At 5:22 AM -0800 11/1/96, David Gaon wrote: @ > It appears to me that the simple solution is the creation of @ > dsitributed directories. @ > With the use of Directories, individuals can get a listing of all @ > entities they wish to address that have IBM as 3 letters in their call @ > sign or as the mnemonic of their name. The user will then selects the @ @David, @ @There is great appeal to trying to solve registration and mapping @ problems by moving the task to a 'directory'. Such a suggestion crops up @ pretty regularly in discussions about difficult lookup tasks. It almost @ never really solves the problem. @ @The difference I make between a mapping service, like the DNS, and @ a 'directory' service is that of determinism. You put in a precise query @ to a mapping service and you get zero or one information node back. You @ put in a query to a directory service and you might get any number of nodes @ back. Then you figure out which one you really want...maybe. @ @A mapping service MUST be reasonably quick and completely @ deterministic. A directory service does not need to be either. Hence, a @ directory service MUST NOT be in the critical path of an infrastructure @ service. It's fine as an adjunct, but it simply isn't the direction to go @ for a service that returns addresses, especially when the lookup activity @ is in the middle of mainline system processing such as a mail forwarder. @ @ d/ @ @ ps.Even if one COULD use a directory, your suggestion doesn't solve @ the current problem. Say you and I each list acme.biz in our different @ directories and someone queries the distributed service, finding both @ entries. How do they choose? @ @ -------------------- @ Dave Crocker +1 408 246 8253 @ Brandenburg Consulting fax: +1 408 249 6205 @ 675 Spruce Dr. dcrocker@brandenburg.com @ Sunnyvale CA 94086 USA http://www.brandenburg.com @ @ Internet Mail Consortium http://www.imc.org, info@imc.org @ @@@@@@@@@ Dave, The DNS "mapping" system is evolving. As noted in my notes below, there are new features being developed like the SRV records which may not be "completely deterministic", thus things like PRIORITY and WEIGHT are being proposed. As noted below, I feel that people should try to step back and look at the IPv4/DNS Core Transport system as a unit and try to start using the DNS system for functions that can help bring stability to the core network. I agree with you that people should differentiate between those services which are assumed to be part of the critcal mass and those which are built around the edges. In my mind, DNS is certainly part of the core, even though it may not be deterministic. ...actually, nothing in the core is totally deterministic, of course, that is the way it was designed and part of its beauty... JF ---------- From:Jim Fleming[SMTP:JimFleming@unety.net.] Sent:Thursday, October 31, 1996 11:44 PM To:'New Newdom' Subject:DNS Evolution As some people know, I am an advocate of Internet evolution not revolution. If one steps back and looks at the current Internet, they will find a growing IPv4 core with a distributed Domain Name System (DNS) that could be used for many more functions that require symbolic names to be mapped to binary numbers. If one draws a circle and labels it the IPv4/DNS Transport Core, then everything inside that circle can be solidified via standards and evolved to a point where no additional services or features are needed, just new ways to use the old capabilities. This is similar to what happens with processor instruction sets and operating system interfaces, they reach a point where enough is enough and then creativity takes over. Einstein is often reported to have said, "Everything should be as simple as possible, but no simpler". (or something like that) In my opinion, that sort of test should be applied to the IPv4/DNS Transport Core and evolution should then begin in a layer around the outside of those core capabilities. One area where evolution can occur is alternate uses for DNS or alternate applications. Most people assume that DNS can only be used to convert domain names to IP addresses, but if you look at it from a purely bits and bytes point of view, it can be used for many "mapping" or "lookup" applications. In my opinion, the success of the Root 64 project and extensions to the top level domains will depend on a highly synchronized set of commercial root name servers operated by people with a complete understanding of the overall system and the registries needed to feed the system. Some of the synchronizartion will be achieved simply via people working together in "round table" forums where changes are made only after consensus is reached via open discussions. The rest of the synchronization will be achieved via software automation. In my opinion, a view of the evolving IPv4/DNS Transport Core should be developed and solidified and the DNS should be used to the maximum amount possible to assist in the root name server synchronization task. Before the "core" is solidified, one has to ask, "When is enough, enough?" or "When is the core as simple as possible but no simpler?". While I am sure that everyone would love to rush in the last list of features before the requirements are set and the code is written, there is a point at which, enough is enough. Because I tend to be a minimalist when it comes to computer systems (that comes from hacking UNIX kernels since 1976), I generally do not like to see a lot of time wasted while people wait for the next release, or that killer feature which will make life easier. There are always more future features, but sometimes pressing people to use what they have, causes cleaner solutions. Having said that, I will also admit that there could be some new feature which could help to make life simpler and actually help to *accelerate* some evolutionary transitions, if everyone is willing to wait for the feature to be tested and widely deployed. This happened several times in the early days of UNIX at Bell Labs, but the day did come when enough was enough. Because I would like to see DNS used to its max in helping to solve the distributed global syncronization problem of the root name servers, I think that all of the current features of DNS should be assesed as well as those that are clearly on the horizon. Arnt Gulbrandsen and Paul Vixie have published some notes that might be of interest to people working with top level domain issues and root name server deployments. @@@@@ ftp://ds.internic.net/rfc/rfc2052.txt In a nutshell, the notes describe an experimental extension that will allow SRV records to be added to encode DNS information that goes beyond the current mundane world of domain name to IP address mappings. The following example SRV records help to illustrate most of the proposed features... @@@ ; HTTP - server is the main server, new-fast-box is the backup ; (On new-fast-box, the HTTP daemon runs on port 8000) ;Service.Proto.Name TTL Class SRV Priority Weight Port Target http.tcpSRV0080server.any-name.com. SRV1008000new-fast-box.any-name.com. @@@ When a SRV-cognizant client wants to retrieve http://www.any-name.com/ it does a lookup of http.tcp.www.any-name.com the psuedo host.domain, "http.tcp" is found in the "www.any-name.com" domain and instead of just obtaining an IP address, port information is also obtained along with priority and weight information. The client digests all of this and continues the resolution to the final IP address. @@@@@ Before the requirements and design of the root name server synchronization system are solidified, the SRV capabilities should probably be assessed to make sure that the "system is as simple as possible, but no simpler". It seems to me that two views could be taken of the SRV capabilities: 1. The intended functionality described above. 2. The ability to store and retrieve a new type of record, with binary fields that could be used for many purposes, along with a target host name. I am not certain if either view will be helpful to provide the last "killer" DNS feature needed to pull together the entire root name server system into a coherent solution. It just seemed to me, that when I read the notes, there was a gut level feeling that the SRV records could be helpful in the final root name server synchronization system. Because time is short and more code must be written and tested, I think that these capabilities require a quick look, if for no other reason, than the ability to say, "we wanted to use these capabilities, but ran out of time and had to stick to the solidified set of features provided by the IPv4 Transport Core as of October 1996.". It seems to me that system evolution decisions require an ability to know what features are worth waiting for, balanced against some willingness to wait only so long before "enough is enough".... ...it is good to have as many people as possible take one last look...before things rapidly move forward in high gear... @@@@ -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa15489; 1 Nov 96 12:15 EST Received: from doorstep.unety.net by ietf.org id aa15247; 1 Nov 96 12:14 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA27453; Fri, 1 Nov 1996 11:07:43 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC7E5.1F1DB760@webster.unety.net>; Fri, 1 Nov 1996 11:09:16 -0600 Message-ID: <01BBC7E5.1F1DB760@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Michael Dillon' Cc: "ietf@ietf.org" , "James E. [Jed] Donnelley" , 'Phil Karn' , 'New Newdom' Subject: RE: Serious Business Date: Fri, 1 Nov 1996 11:09:15 -0600 Encoding: 38 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 01, 1996 2:53 AM, Michael Dillon[SMTP:michael@memra.com] wrote: @ On Fri, 1 Nov 1996, Jim Fleming wrote: @ @ > @ Bill Frezza appears to be a journalistic gadfly who specializes in attacking @ > @ large, successful technology organizations. He has written a series of @ > @ articles @ > @ attacking Qualcomm CDMA that, in my opinion, are best characterized as @ > @ "vicious", @ > @ as opposed to merely "uninformed" or "muckraking". @ @ > ...this is all very serious business...and just think, much of @ > it started out right there in the E Aisle in Building 6... @ @ Is that the building at AT&T where you worked together with Bill Frezza @ back in the early 80's on videotex/NAPLPS systems? @ @ @ Michael Dillon - ISP & Internet Consulting @ Memra Software Inc. - Fax: +1-604-546-3049 @ http://www.memra.com - E-mail: michael@memra.com @ @ @ No, Bill Frezza worked primarily in Holmdel, NJ. Phil Karn and I worked together at Bell Labs Indian Hill, in Naperville, IL. "ihnss" was located there...if you go back that far... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa16934; 1 Nov 96 12:26 EST Received: from jekyll.piermont.com by ietf.org id aa16809; 1 Nov 96 12:25 EST Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id MAA02841; Fri, 1 Nov 1996 12:24:12 -0500 (EST) Message-Id: <199611011724.MAA02841@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol To: pinchas@sprynet.com cc: ietf@ietf.org Subject: Re: The Cartel Begins to Crumble In-reply-to: Your message of "Wed, 30 Oct 1996 12:53:45 PST." <3277C059.7617@sprynet.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 01 Nov 1996 12:24:08 -0500 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Phillip Charles Oliff writes: > One final observation, as the Internet grows, the efforts of the > IETF will seem insignificant as compared to the industry giants. > It seems that the computer industry has a short memory and will > soon forget about our efforts if not properly reminded. I believe that most of the firms that have seriously flouted standards in the past (Wang comes to mind) have been punished in the marketplace. Perry   Received: from ietf.org by ietf.org id aa16933; 1 Nov 96 12:26 EST Received: from coral.llnl.gov by ietf.org id aa16775; 1 Nov 96 12:25 EST Received: from [128.115.96.72] (jedsmac.llnl.gov [128.115.96.72]) by coral.llnl.gov (8.7.5/8.7.3/LLNL-Jun96) with ESMTP id JAA01109; Fri, 1 Nov 1996 09:23:55 -0800 (PST) X-Sender: jed@coral.llnl.gov Message-Id: In-Reply-To: <18153.9611011536@huey.xylogics.com> References: "James E. [Jed] Donnelley"'s message of Thu, 31 Oct 1996 17:37:30 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Nov 1996 10:01:59 -0800 To: Gary Scott Malkin Sender:ietf-request@ietf.org From: "James E. [Jed] Donnelley" Subject: Re: The cartel begins to crumble? - .com crowding Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. In responce to: >> >The *.COM TLD is crowded, but only because everyone seems to want to >> >crowd into it ... probably exactly because it is so crowded. Gary Malkin wrote: >Actually, I think that most people register under .com because they >don't know that anything else exists. I don't think I've ever seen >any URL advertised on TV that wasn't a .com. I think we could solve >some of the crowding simply by insisting that a .com name truely be >a company/corporation (i.e., not the name of a movie, or someones >pet project). I certainly think that publicizing alternative TLDs is a good idea. I wouldn't go so far as to "insist." However, I can see some justification for it. At least what a corporation is can be quite well defined. There would certainly be lot of grandfathering to deal with. Actually I was only addressing the issue of why companies all want to be in the .com domain. I see no justification for individuals or projects or services or ... to be there. I think the .per (or whatever it was) for personal domains is a great (!) idea. Where do I sign up? I am not as sure about projects, services, etc. If it would be adequate to take some pressure off of the .com domain by introducing a few (centrally managed ;-) new TLDs, then I am all for it. Perhaps it would be useful to hear a summary of progress on this front in the current administrative structure. I can't give that summary. --Jed http://www-atp.llnl.gov/atp/jed-signature.html   Received: from ietf.org by ietf.org id aa17377; 1 Nov 96 12:34 EST Received: from doorstep.unety.net by ietf.org id aa17305; 1 Nov 96 12:33 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA27513; Fri, 1 Nov 1996 11:27:05 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC7E7.D3329160@webster.unety.net>; Fri, 1 Nov 1996 11:28:37 -0600 Message-ID: <01BBC7E7.D3329160@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Gary Scott Malkin' , "jed@llnl.gov" Cc: "ietf@ietf.org" , 'New Newdom' Subject: RE: The cartel begins to crumble? - .com crowding Date: Fri, 1 Nov 1996 11:28:36 -0600 Encoding: 64 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 01, 1996 9:36 AM, Gary Scott Malkin[SMTP:gmalkin@xylogics.com] wrote: @ > >The *.COM TLD is crowded, but only because everyone seems to want to @ > >crowd into it ... probably exactly because it is so crowded. @ > @ > I think this is about right. A specific angle on this is that @ > I (and I suspect I am not alone) often will try @ @ Actually, I think that most people register under .com because they @ don't know that anything else exists. I don't think I've ever seen @ any URL advertised on TV that wasn't a .com. I think we could solve @ some of the crowding simply by insisting that a .com name truely be @ a company/corporation (i.e., not the name of a movie, or someones @ pet project). @ @ ---------------------------------------------------------------------- @ Gary Malkin Cheap, Fast, Good @ (617) 238-6237 Pick two! @ @ That will happen as a result of the free market processes working as well as other laws, such as supply and demand. With the introduction of new top level domains, the supply is being opened up. The demand may not be impacted, it appears to continue to grow. Just look at the 2,000+ registrations that have been made in the new .USA top level domain and that is only during the past few months. Marketing people anticipate that the .COM extension may become both a classic as well as a top level domain to avoid, when leading edge companies realize that they can now make a statement via the top level domain they choose. Of course, many names will run in parallel with .COM for quite some time. The convention of registring a name in both .COM and one of the new top level domains can further help to ease this transition. For example, the following two names both direct people to the proper place... http://www.internet-mall.com http://www.internet.mall ...if you do not believe me, give it a try, assuming of course that you are on the leading edge of the Internet...;-) P.S. With the NEW web server techniques, the server can of course determine which of the above a person typed, and "leading edge" people can be presented with leading edge information and opportunities. If marketing people use that as a selector, then people might be compelled to move to the new format, so they do not miss something...of course, classic DNS users could also be given a classic message... ...Hmmm...maybe an ASCII only web site...just like RFCs... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa23878; 1 Nov 96 13:32 EST Received: from cnri by ietf.org id aa23761; 1 Nov 96 13:30 EST Received: from verdi.nethelp.no by CNRI.Reston.VA.US id aa16426; 1 Nov 96 13:30 EST Received: (qmail 8905 invoked by uid 1001); 1 Nov 1996 18:29:18 +0000 (GMT) To: ietf@CNRI.Reston.VA.US Subject: RE: Folling the crumbling cartel - a note about thread following Sender:ietf-request@ietf.org From: sthaug@nethelp.no X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 01 Nov 1996 19:29:18 +0100 Message-ID: <8903.846872958@verdi.nethelp.no> Source-Info: From (or Sender) name not authenticated. JimFleming@unety.net (Jim Fleming) wrote: > Dear Phil...we have all come a long way...in a short time... > > I hope that you take this work seriously.... It's not at all clear what your message is supposed to prove. You have listed a number of name servers. If your claim is that all these servers know about your "alternative" TLDs, you're flat out wrong. On top of the list, it says: "Attached is the growing list of root name servers which are being deployed around the world." Most of the refrences given are URLs, which really says nothing about name servers at all. From the host name/IP addresses which are *not* URLs, I made the following list: Name IP address Other name Alternative Auth rootsanswer ----------------------------------------------------------------------------- NS.INTERNIC.NET 198.41.0.4 a.root-servers.net NoYes NS1.ISI.EDU 128.9.0.107 b.root-servers.net NoYes C.PSI.NET 192.33.4.12 c.root-servers.net NoYes TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes NS.NASA.GOV 192.203.230.10 e.root-servers.net NoConn refused NS.ISC.ORG 192.5.5.241 f.root-servers.net NoYes NS.NIC.DDN.MIL 192.112.36.4 g.root-servers.net NoYes AOS.ARL.ARMY.MIL 128.63.2.53 h.root-servers.net NoYes NIC.NORDU.NET 192.36.148.17 i.root-servers.net NoYes ROOT-NS.THENIC.NET 207.67.22.81 NoNo MX.ALTERNIC.NET 204.94.42.1 YesNo answer ROOT-NS.MCS.NET 192.160.127.8 YesNo route SIMBA.AGN.NET 160.79.1.3 YesNo TORONTO.ALTERNIC.NET 207.107.232.106 YesYes USVI.NET 204.199.0.4 YesYes * NS.WW.NET 193.124.73.100 YesYes NS.ALPHAQUE.COM 202.185.254.12 YesYes NS.UNETY.NET 207.32.128.1 YesYes Comments: * Gives authoritative answer for ".", but returns localhost! "No route": Doesn't answer ping "No answer": Doesn't answer "dig ns ." "Conn refused": Connection refused, so apparently no name server running ---------------------------------------------------------------------------- Not surprisingly, a.root-servers.net - i.root-servers.net do not support your alternative roots. (I assume NS.NASA.GOV doesn't, even if I was unable to verify this.) Of the 9 name servers you have listed which are *not* the traditional root name servers: - 8 support your alternative roots (I *assume* MX.ALTERNIC.NET and ROOT-NS.MCS.NET do, even if I was unable to verify this). - One of these does not give authoritative answers. - One of these returns "localhost" as the authoritative name server for ".". - One of these answers to ping, but doesn't answer DNS requests. - Three of the servers are out side North America (Ukraine, Malaysia and U.S. Virgin Island). Quite frankly, I can't see that you have shown anything whatsoever about growing support for your alternative roots around the world. Furthermore, I can't see any reason why I should "take this work seriously". Steinar Haug, Nethelp consulting, sthaug@nethelp.no Former 'no' TLD responsible   Received: from cnri by ietf.org id aa27201; 1 Nov 96 14:40 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18077; 1 Nov 96 14:40 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Fri, 1 Nov 1996 18:09:14 GMT Received: from PO10.ANDREW.CMU.EDU by MIT.EDU with SMTP id AA09375; Fri, 1 Nov 96 13:09:12 EST Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.2/8.8.0) id NAA00774; Fri, 1 Nov 1996 13:09:08 -0500 Received: via switchmail; Fri, 1 Nov 1996 13:09:07 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 1 Nov 1996 13:07:39 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 1 Nov 1996 13:07:37 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54 via MS.5.6.hogtown.andrew.cmu.edu.sun4_51; Fri, 1 Nov 1996 13:07:35 -0500 (EST) Message-Id: Date: Fri, 1 Nov 1996 13:07:35 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu, cat-ietf@mit.edu Subject: ietf-sasl mailing list A new mailing list, ietf-sasl@imc.org, has been created to discuss and resolve pending issues with the SASL (previously IMAP authentication) draft. Subscriptions to ietf-sasl-request@imc.org Thanks to the Internet Mail Consortium for hosting the list. -- _.John Gardiner MyersInternet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.org by ietf.org id aa28787; 1 Nov 96 15:11 EST Received: from nirvana.genesyslab.com by ietf.org id aa28679; 1 Nov 96 15:09 EST Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id MAA20969; Fri, 1 Nov 1996 12:08:34 -0800 (PST) Received: (from egoshin@localhost) by giant.genesyslab.com (8.7.5/8.7.3) id MAA09393; Fri, 1 Nov 1996 12:08:10 -0800 (PST) Date: Fri, 1 Nov 1996 12:08:10 -0800 (PST) Sender:ietf-request@ietf.org From: Leonid Egoshin Message-Id: <199611012008.MAA09393@giant.genesyslab.com> To: Valdis.Kletnieks@vt.edu, gaond@ncr.disa.mil Subject: Re: Re[3]: The cartel begins to crumble? Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. >From: Valdis.Kletnieks@vt.edu > >On Fri, 01 Nov 1996 10:52:15 EST, David Gaon said: >> I am suggesting that the determination of the ""exact network address of >> the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is left >> to the user and is done offline (with respect to the communications >> infrastructure). The user, on deciding whom he wants to reach, either >> types in the corresponding port number in his e-mail or web access, or he >> passes it to his application (e-mail) which inserts it in the appropriate >> field. >> As for forwarder application, instead of sending mail to ietf@isetf.org, >> the user sends it to the exact address corresponding to that port. In >> inception of the forwarder, the translation of exact member addresses is >> done once (clearly updated later), but again done outside the main stream >> process of the application. >> Thus the task of the router is minimised and is as fast or even faster than >> present implementation depending on what is doing the name translation. >> >Sounds good at first glance, but let's look at this a little bit closer... > >What about mail to ietf@ietf.org, as you use for your example? OK, >*you* can do the resolution of *that* address "offline" - but once >your mail gets to the mailing list, *EACH RECIPIENT* has to be looked >up someplace. > >This is the *true* bottleneck. We have machines that process an >amazing amount of mail per day. Hell, I'm the administrator of an >RS6000-250, which is only a 66mz PowerPC chip, that handles over 500K >messages/day some days. Eric Thomas has been pumping well over 2M/day >through a P90 running NT. I haven't talked to my friends at AOL (you >DTW's know who you are ;) lately about what THEY do... Offline is offline - you can do resolving on another host. And at second, I think the large part of CPU time is the name-server/resolver side, not mail transfer side. - Leonid Yegoshin, LY22   Received: from ietf.org by ietf.org id aa28950; 1 Nov 96 15:14 EST Received: from cnri by ietf.org id aa28840; 1 Nov 96 15:12 EST Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa19038; 1 Nov 96 15:12 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id OAA07004; Fri, 1 Nov 1996 14:11:41 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 14:11 CST Received: (from karl@localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id OAA27288; Fri, 1 Nov 1996 14:11:38 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611012011.OAA27288@Mercury.mcs.net> Subject: Re: Folling the crumbling cartel - a note about thread following To: sthaug@nethelp.no Date: Fri, 1 Nov 1996 14:11:38 -0600 (CST) Cc: ietf@CNRI.Reston.VA.US In-Reply-To: <8903.846872958@verdi.nethelp.no> from "sthaug@nethelp.no" at Nov 1, 96 07:29:18 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > JimFleming@unety.net (Jim Fleming) wrote: > > > Dear Phil...we have all come a long way...in a short time... > > > > I hope that you take this work seriously.... > > It's not at all clear what your message is supposed to prove. You have > listed a number of name servers. If your claim is that all these servers > know about your "alternative" TLDs, you're flat out wrong. > > On top of the list, it says: "Attached is the growing list of root name > servers which are being deployed around the world." > > Most of the refrences given are URLs, which really says nothing about > name servers at all. From the host name/IP addresses which are *not* > URLs, I made the following list: > > Name IP address Other name Alternative Auth > rootsanswer > ----------------------------------------------------------------------------- > NS.INTERNIC.NET 198.41.0.4 a.root-servers.net NoYes > NS1.ISI.EDU 128.9.0.107 b.root-servers.net NoYes > C.PSI.NET 192.33.4.12 c.root-servers.net NoYes > TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes > NS.NASA.GOV 192.203.230.10 e.root-servers.net NoConn refused > NS.ISC.ORG 192.5.5.241 f.root-servers.net NoYes > NS.NIC.DDN.MIL 192.112.36.4 g.root-servers.net NoYes > AOS.ARL.ARMY.MIL 128.63.2.53 h.root-servers.net NoYes > NIC.NORDU.NET 192.36.148.17 i.root-servers.net NoYes Does someone care to tell me under what authority NSI is running COM, ORG and NET on servers owned by the US Government (three of the above) and two publically funded universities (2 more of the above)? :-) 1/2 of your operating infrastructure effectively paid for (at least in part) with public funds... not bad for a for-profit company! > ROOT-NS.THENIC.NET 207.67.22.81 NoNo > > MX.ALTERNIC.NET 204.94.42.1 YesNo answer > ROOT-NS.MCS.NET 192.160.127.8 YesNo route That IP address is wrong. The right one is 192.160.127.86. If you ping the right address (or dig to it) you'll find that it does work. > SIMBA.AGN.NET 160.79.1.3 YesNo > TORONTO.ALTERNIC.NET 207.107.232.106 YesYes > USVI.NET 204.199.0.4 YesYes * > NS.WW.NET 193.124.73.100 YesYes > NS.ALPHAQUE.COM 202.185.254.12 YesYes > NS.UNETY.NET 207.32.128.1 YesYes > > Comments: > > * Gives authoritative answer for ".", but returns localhost! > "No route": Doesn't answer ping > "No answer": Doesn't answer "dig ns ." > "Conn refused": Connection refused, so apparently no name server running > ---------------------------------------------------------------------------- > > Not surprisingly, a.root-servers.net - i.root-servers.net do not support > your alternative roots. (I assume NS.NASA.GOV doesn't, even if I was > unable to verify this.) > > Of the 9 name servers you have listed which are *not* the traditional > root name servers: > > - 8 support your alternative roots (I *assume* MX.ALTERNIC.NET and > ROOT-NS.MCS.NET do, even if I was unable to verify this). > - One of these does not give authoritative answers. > - One of these returns "localhost" as the authoritative name server > for ".". > - One of these answers to ping, but doesn't answer DNS requests. > - Three of the servers are out side North America (Ukraine, Malaysia > and U.S. Virgin Island). > > Quite frankly, I can't see that you have shown anything whatsoever about > growing support for your alternative roots around the world. Furthermore, > I can't see any reason why I should "take this work seriously". > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > Former 'no' TLD responsible Well, you could start by making sure you're looking in the right place! :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa29578; 1 Nov 96 15:23 EST Received: from thunder.ncr.disa.mil by ietf.org id aa29370; 1 Nov 96 15:21 EST Received: from ncr.disa.mil ([164.117.176.106]) by thunder.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id PAA10034; Fri, 1 Nov 1996 15:06:01 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA846890402; Fri, 01 Nov 96 15:17:47 EST Date: Fri, 01 Nov 96 15:17:47 EST Sender:ietf-request@ietf.org From: David Gaon Message-Id: <9610018468.AA846890402@ncr.disa.mil> To: Valdis.Kletnieks@vt.edu, Leonid Egoshin Cc: ietf@ietf.org Subject: Re[5]: The cartel begins to crumble? Source-Info: From (or Sender) name not authenticated. Leonid Thanks, I believe you have captured my intent. But I suggest to Vladis Kletnieks that whoever creates the mailing list will in fact resolve the names to port addresses and enter only the last, or parties interested in joining the list will actually offer their network port address through their mail (header or body) since this will be available. Cheers David Gaon DoD/DISA/Center for Standards ______________________________ Reply Separator _________________________________ Subject: Re: Re[3]: The cartel begins to crumble? Author: Leonid Egoshin at smtp Date: 11/1/96 3:08 PM >From: Valdis.Kletnieks@vt.edu > >On Fri, 01 Nov 1996 10:52:15 EST, David Gaon said: >> I am suggesting that the determination of the ""exact network address of >> the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is left >> to the user and is done offline (with respect to the communications >> infrastructure). The user, on deciding whom he wants to reach, either >> types in the corresponding port number in his e-mail or web access, or he >> passes it to his application (e-mail) which inserts it in the appropriate >> field. >> As for forwarder application, instead of sending mail to ietf@isetf.org, >> the user sends it to the exact address corresponding to that port. In >> inception of the forwarder, the translation of exact member addresses is >> done once (clearly updated later), but again done outside the main stream >> process of the application. >> Thus the task of the router is minimised and is as fast or even faster than >> present implementation depending on what is doing the name translation. >> >Sounds good at first glance, but let's look at this a little bit closer... > >What about mail to ietf@ietf.org, as you use for your example? OK, >*you* can do the resolution of *that* address "offline" - but once >your mail gets to the mailing list, *EACH RECIPIENT* has to be looked >up someplace. > >This is the *true* bottleneck. We have machines that process an >amazing amount of mail per day. Hell, I'm the administrator of an >RS6000-250, which is only a 66mz PowerPC chip, that handles over 500K >messages/day some days. Eric Thomas has been pumping well over 2M/day >through a P90 running NT. I haven't talked to my friends at AOL (you >DTW's know who you are ;) lately about what THEY do... Offline is offline - you can do resolving on another host. And at second, I think the large part of CPU time is the name-server/resolver side, not mail transfer side. - Leonid Yegoshin, LY22   Received: from ietf.org by ietf.org id aa00420; 1 Nov 96 15:35 EST Received: from cnri by ietf.org id aa00299; 1 Nov 96 15:33 EST Received: from verdi.nethelp.no by CNRI.Reston.VA.US id aa19588; 1 Nov 96 15:33 EST Received: (qmail 9291 invoked by uid 1001); 1 Nov 1996 20:32:54 +0000 (GMT) To: karl@mcs.net Cc: ietf@CNRI.Reston.VA.US Subject: Re: Folling the crumbling cartel - a note about thread following Sender:ietf-request@ietf.org From: sthaug@nethelp.no In-Reply-To: Your message of "Fri, 1 Nov 1996 14:11:38 -0600 (CST)" References: <199611012011.OAA27288@Mercury.mcs.net> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 01 Nov 1996 21:32:54 +0100 Message-ID: <9289.846880374@verdi.nethelp.no> Source-Info: From (or Sender) name not authenticated. > Does someone care to tell me under what authority NSI is running COM, ORG > and NET on servers owned by the US Government (three of the above) and two > publically funded universities (2 more of the above)? :-) > > 1/2 of your operating infrastructure effectively paid for (at least in part) > with public funds... not bad for a for-profit company! I'm not the right person to comment on this - but I see that you prefer to discuss other things than the claimed 'growing support'. > > ROOT-NS.MCS.NET 192.160.127.8 YesNo route > > That IP address is wrong. The right one is 192.160.127.86. If you ping > the right address (or dig to it) you'll find that it does work. My fault. Note that in my table I assumed it supported the alternative roots, so my count of 8 servers for the alternative roots is unchanged. > > Quite frankly, I can't see that you have shown anything whatsoever about > > growing support for your alternative roots around the world. Furthermore, > > I can't see any reason why I should "take this work seriously". > > Well, you could start by making sure you're looking in the right place! :-) I still can't see that anything you've said here supports the notion that there is growing support for your alternative roots around the world. Steinar Haug, Nethelp consulting, sthaug@nethelp.no   Received: from ietf.org by ietf.org id aa00712; 1 Nov 96 15:37 EST Received: from localhost by ietf.org id aa00235; 1 Nov 96 15:32 EST To: IETF-Announce: ; Subject: Internet-Draft CUTOFF Date Date: Fri, 01 Nov 1996 15:32:19 -0500 Sender:ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9611011532.aa00235@ietf.org> The cut-off for Internet-Draft submissions prior to the San Jose IETF meeting is Tuesday, November 26, 1996 at 5pm ET. Internet-Drafts received after this time will not be announced nor made available in the Internet-drafts Directories. We will begin processing Internet-Draft submissions the week following the IETF meeting. Thank you for your understanding and cooperation. Please do not hesitate to contact me if you have any questions or concerns. Kind Regards, Cynthia Clark Internet-Drafts Administrator   Received: from ietf.org by ietf.org id aa01207; 1 Nov 96 15:47 EST Received: from cnri by ietf.org id aa01065; 1 Nov 96 15:45 EST Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa19932; 1 Nov 96 15:45 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id OAA28128; Fri, 1 Nov 1996 14:39:30 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC802.B4CACCE0@webster.unety.net>; Fri, 1 Nov 1996 14:41:03 -0600 Message-ID: <01BBC802.B4CACCE0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "ietf@CNRI.Reston.VA.US" , "'sthaug@nethelp.no'" Cc: 'New Newdom' Subject: RE: Folling the crumbling cartel - a note about thread following Date: Fri, 1 Nov 1996 14:41:01 -0600 Encoding: 140 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 01, 1996 12:29 PM, sthaug@nethelp.no wrote: @ JimFleming@unety.net (Jim Fleming) wrote: @ @ > Dear Phil...we have all come a long way...in a short time... @ > @ > I hope that you take this work seriously.... @ @ It's not at all clear what your message is supposed to prove. You have @ listed a number of name servers. If your claim is that all these servers @ know about your "alternative" TLDs, you're flat out wrong. @ No, I do not claim this. Root name servers are a separate issue from the alternative top level domains. Many people know that the "popular" root name servers, commonly defaulted into "root.cache" files, do not support all of the top level domains. The operators of those name servers, still choose to recognize only a subset of the TLDs. @ On top of the list, it says: "Attached is the growing list of root name @ servers which are being deployed around the world." @ @ Most of the refrences given are URLs, which really says nothing about @ name servers at all. From the host name/IP addresses which are *not* @ URLs, I made the following list: @ Unfortunately, you did not have all of the context of the list. I apologize for mixing entries. Some of the entries are pointers to "notes" about people and organizations that may or may not be likely candidates to help host a root name server. Since the list is a "living notebook" using a static medium like an ASCII file, it is difficult to show the hyper-dynamics of the information. One thing that should not go unmentioned from your great analysis below is that one to the "popular" root name servers, NS.NASA.GOV, is not the most stellar server to specify in one's "root.cache" file. This helps to point out that ISPs should not just blindly load some file from their O/S vendor or some "NIC", without looking at the file and fully understanding the contents and the ramifications. In my opinion, I do not think that the NASA server should even be in the set of "popular" root name servers because of the following reasons. 1. As you have shown, it is not accessible. 2. It is in North America, and more International coverage should be encouraged. 3. It is funded by U.S. taxpayers and as people have seen recently as well as during the past few years, the U.S. Government (mostly via the NSF) wants the Internet infrastructure to be shifted to the commercial sector. Root name servers should be no exception. @ Name IP address Other name Alternative Auth @ rootsanswer @ ----------------------------------------------------------------------------- @ NS.INTERNIC.NET 198.41.0.4 a.root-servers.net NoYes @ NS1.ISI.EDU 128.9.0.107 b.root-servers.net NoYes @ C.PSI.NET 192.33.4.12 c.root-servers.net NoYes @ TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes @ NS.NASA.GOV 192.203.230.10 e.root-servers.net NoConn refused @ NS.ISC.ORG 192.5.5.241 f.root-servers.net NoYes @ NS.NIC.DDN.MIL 192.112.36.4 g.root-servers.net NoYes @ AOS.ARL.ARMY.MIL 128.63.2.53 h.root-servers.net NoYes @ NIC.NORDU.NET 192.36.148.17 i.root-servers.net NoYes @ @ ROOT-NS.THENIC.NET 207.67.22.81 NoNo @ @ MX.ALTERNIC.NET 204.94.42.1 YesNo answer @ ROOT-NS.MCS.NET 192.160.127.8 YesNo route @ SIMBA.AGN.NET 160.79.1.3 YesNo @ TORONTO.ALTERNIC.NET 207.107.232.106 YesYes @ USVI.NET 204.199.0.4 YesYes * @ NS.WW.NET 193.124.73.100 YesYes @ NS.ALPHAQUE.COM 202.185.254.12 YesYes @ NS.UNETY.NET 207.32.128.1 YesYes @ @ Comments: @ @ * Gives authoritative answer for ".", but returns localhost! @ "No route": Doesn't answer ping @ "No answer": Doesn't answer "dig ns ." @ "Conn refused": Connection refused, so apparently no name server running @ ---------------------------------------------------------------------------- @ @ Not surprisingly, a.root-servers.net - i.root-servers.net do not support @ your alternative roots. (I assume NS.NASA.GOV doesn't, even if I was @ unable to verify this.) @ (see my notes above on the NASA server) @ Of the 9 name servers you have listed which are *not* the traditional @ root name servers: @ @ - 8 support your alternative roots (I *assume* MX.ALTERNIC.NET and @ ROOT-NS.MCS.NET do, even if I was unable to verify this). @ - One of these does not give authoritative answers. @ - One of these returns "localhost" as the authoritative name server @ for ".". @ - One of these answers to ping, but doesn't answer DNS requests. @ - Three of the servers are out side North America (Ukraine, Malaysia @ and U.S. Virgin Island). @ Yes, the idea behind the Root 64 Project is to develop broader coverage around the world. The Root 128 Project focuses on just the U.S. Many people feel that the U.S.-centric attitudes of Internet Infrastructure administration need to be down played and more emphasis needs to be placed on the International nature of the Internet. One of the major complaints that some people reported from a recent Harvard conference was a lack of participation from the International community. @ Quite frankly, I can't see that you have shown anything whatsoever about @ growing support for your alternative roots around the world. Furthermore, @ I can't see any reason why I should "take this work seriously". @ @ Steinar Haug, Nethelp consulting, sthaug@nethelp.no @ Former 'no' TLD responsible @ @ Thanks for your comments and analysis. You may want to consider helping the evolution of this effort via the NEW newdom mailing list. If Norway every decides to support a true root name server, you sound like a good person to contact to get an expert opinion and help in that region. Thanks again for the great feedback. I am sure that everyone on the newdom list will appreciate your comments. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa01231; 1 Nov 96 15:47 EST Received: from ritig1.rit.reuters.com by ietf.org id aa01063; 1 Nov 96 15:45 EST Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM) id AA22599; Fri, 1 Nov 1996 15:47:40 -0500 Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V5.0-7 #7805) id <01IBC4WOQI0W001VZE@RITIG4.RIT.REUTERS.COM> for ietf@ietf.org; Fri, 01 Nov 1996 15:41:59 -0500 (EST) Received: with PMDF-MR; Fri, 01 Nov 1996 20:41:12 -0500 (EST) Mr-Received: by mta REC.MUAS; Relayed; Fri, 01 Nov 1996 20:41:12 -0500 Mr-Received: by mta RE6; Relayed; Fri, 01 Nov 1996 20:41:13 -0500 Mr-Received: by mta RITIG4; Relayed; Fri, 01 Nov 1996 20:41:53 -0500 Disclose-Recipients: prohibited Date: Fri, 01 Nov 1996 20:41:12 -0500 (EST) Sender:ietf-request@ietf.org From: Misha Wolf Subject: Tenth Int'l Unicode Conference - Call for Papers - Final Reminder To: ietf Message-Id: <0912412001111996/A51806/RE6/11AB0D290B00*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Priority: urgent Ua-Content-Id: 11AB0D290B00 X400-Mts-Identifier: [;0912412001111996/A51806/RE6] Hop-Count: 2 Source-Info: From (or Sender) name not authenticated. Please forward this information to your colleagues, friends and contacts C A L L F O R P A P E R S - F I N A L R E M I N D E R !!! The deadline for submissions is 8 November 1996 !!! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Tenth International Unicode Conference and Global Computing Showcase Europe, Software + the Internet: Going Global with Unicode** March 10-11, 1997 Mainz, Germany **************************************************************************** With the Internet comes change: businesses world-wide expect accurate access to text, independent of location or language. Users demand software that runs everywhere. To meet these needs requires global computing. The Tenth International Unicode** Conference will address all issues and topics relating to global computing with Unicode. Conference attendees will include managers, software engineers, systems analysts, and product marketing personnel responsible for the development of software supporting Unicode/ISO 10646 as well as those involved in all aspects of the globalization of software and the Internet. All proposals for papers will be reviewed for inclusion in the Conference Program and book of Conference Proceedings. THEME/TOPICS Global computing with Unicode is the overall theme of the Conference. Presentations should be geared towards a technical audience. Suggested topics of interest include, but are not limited to: - The Internet and Unicode - The World Wide Web (WWW) and Unicode - Java and Unicode - Character set issues on the Internet and WWW - Compression of Unicode data - Testing Unicode applications - Library and archival concerns - Unicode in UNIX - Unicode in databases - Unicode in large scale networks - The results of using Unicode applications (case studies, solutions) - Business topics and market forecasts - Language processing issues with Unicode data - Migrating legacy applications to Unicode - Cross platform issues - Usability evaluations of Unicode applications SESSIONS The Conference Program will provide a wide range of sessions including: - Keynote presentations - Technical presentations - Panel sessions - Open discussion sessions - Workshops/Tutorials All sessions except the Workshops/Tutorials will be of 40 minute duration. In some cases, two consecutive 40 minute program slots may be devoted to a single session. The Workshops/Tutorials will each last three hours. They should be designed to stimulate discussion and participation, using slides and demonstrations. DEADLINES: Submissions due: 8 November 1996 Notification date: 22 November 1996 Camera ready papers due: 17 January 1997 PUBLICITY If your submission is accepted, your abstract, biography, name, title and affiliation, as well as any URLs you provide, will be included on the Conference Web pages and will be seen by many people. SUBMISSIONS Submissions must contain: 1 An abstract of 150-250 words, consisting of statement of purpose, paper description, and your conclusions or final summary 2 A brief biography 3 The details listed below: TITLE OF SESSION: _______________________________________________ TYPE OF SESSION: [ ] Keynote presentation [ ] Technical presentation [ ] Panel session [ ] Open discussion session [ ] Workshop/Tutorial TARGET AUDIENCE (you may select more than one category): [ ] Manager [ ] Software Engineer [ ] Systems Analyst [ ] Marketer [ ] Other: ____________________________________ NAME: Dr/Mr/Mrs/Ms: _______________________________________________ TITLE/POSITION: _______________________________________________ ORGANIZATION/AFFILIATION: _______________________________________________ ORGANIZATION'S WWW URL: _______________________________________________ OWN WWW URL: _______________________________________________ E-MAIL ADDRESS: _______________________________________________ ADDRESS FOR PAPER MAIL: _______________________________________________ _______________________________________________ TELEPHONE: _______________________________________________ FAX: _______________________________________________ For e-mail submissions, please submit in ASCII, uncoded, non-compressed text and use the following subject line: Proposal for IUC 10 Submissions should be sent to the following address by e-mail, post, or fax: Tenth International Unicode Conference c/o Global Meeting Services 3627 Princess Avenue N.Vancouver, B.C. Canada V7N 2E4 voice: +1 604 983-9157 fax: +1 604 983-9158 e-mail: papers@unicode.org or: barbara_jarzyna@mindlink.bc.ca EXHIBIT OPPORTUNITIES: The Conference will have an Exhibition area for corporations or individuals who wish to display and promote their products, technology and/or services. The Exhibition will take place from 5-8pm on March 10, coinciding with the Conference Reception. Every effort will be made to provide maximum exposure and advertising. Exhibit space is limited. For further information or to reserve a place, please contact Global Meeting Services at the above location. CONFERENCE VENUE The Conference will take place at the: Mainz Hilton Rheinstrasse 68 55116 Mainz Germany CONFERENCE UPDATES For further information on the Tenth International Unicode Conference, visit or . THE UNICODE STANDARD The Unicode Standard is a 16-bit character encoding encompassing the world's principal scripts which provides the foundation for the internationalization and localization of software. With its simple and efficient approach to special and modified characters, the Unicode Standard defines a new degree of data portability between platforms and across borders. Software (especially modern, distributed systems) can be adapted for particular countries far more easily than when existing character sets are used. The Unicode Standard is code-for-code identical to the International Standard ISO/IEC 10646. For further information on the Unicode Standard, visit the Unicode Web site at or e-mail . ** 'Unicode' is a trademark of Unicode, Inc.   Received: from ietf.org by ietf.org id aa01332; 1 Nov 96 15:48 EST Received: from cnri by ietf.org id aa01212; 1 Nov 96 15:47 EST Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa19971; 1 Nov 96 15:47 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id OAA09359; Fri, 1 Nov 1996 14:46:15 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 14:46 CST Received: (from karl@localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id OAA29233; Fri, 1 Nov 1996 14:46:13 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611012046.OAA29233@Mercury.mcs.net> Subject: Re: Folling the crumbling cartel - a note about thread following To: sthaug@nethelp.no Date: Fri, 1 Nov 1996 14:46:13 -0600 (CST) Cc: karl@mcs.net, ietf@CNRI.Reston.VA.US In-Reply-To: <9289.846880374@verdi.nethelp.no> from "sthaug@nethelp.no" at Nov 1, 96 09:32:54 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > Does someone care to tell me under what authority NSI is running COM, ORG > > and NET on servers owned by the US Government (three of the above) and two > > publically funded universities (2 more of the above)? :-) > > > > 1/2 of your operating infrastructure effectively paid for (at least in part) > > with public funds... not bad for a for-profit company! > > I'm not the right person to comment on this - but I see that you prefer > to discuss other things than the claimed 'growing support'. From zero operational root nameservers to 80% of the number that the IANA has control over for how many years is not "growing support"? The ISPs which are switching their named root cache files to this list is not "growing support"? I will note that we've been running on this alternative set for a couple of months now, and have seen ZERO negative impact from doing so. What we have seen is a measurable (~40%) decrease in average nameserver query response times -- which in my book counts as an operational BENEFIT. Of course, the fact that the "root" servers in the Alternic world only serve "." and not the zones COM, NET and ORG pretty much guaranteed better response. The only reason its not a LOT better is that you still have to go back to those same machines for these zones..... > My fault. Note that in my table I assumed it supported the alternative > roots, so my count of 8 servers for the alternative roots is unchanged. You also claimed miscellaneous configuration and other problems within the alternative world. Of course, bad data in = bad conclusions out. Further, how abotu the fact that the IANA roots were de-sync'd for several days (and this isn't the first time) very recently (is this fixed yet?) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa02967; 1 Nov 96 16:09 EST Received: from nirvana.genesyslab.com by ietf.org id aa02616; 1 Nov 96 16:07 EST Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id NAA21817; Fri, 1 Nov 1996 13:06:35 -0800 (PST) Received: (from egoshin@localhost) by giant.genesyslab.com (8.7.5/8.7.3) id NAA10870; Fri, 1 Nov 1996 13:06:11 -0800 (PST) Date: Fri, 1 Nov 1996 13:06:11 -0800 (PST) Sender:ietf-request@ietf.org From: Leonid Egoshin Message-Id: <199611012106.NAA10870@giant.genesyslab.com> To: Valdis.Kletnieks@vt.edu Subject: Re: Re[3]: The cartel begins to crumble? Cc: gaond@ncr.disa.mil, ietf@ietf.org Source-Info: From (or Sender) name not authenticated. >From: Valdis.Kletnieks@vt.edu >On Fri, 01 Nov 1996 12:08:10 PST, Leonid Egoshin said: >> Offline is offline - you can do resolving on another host. >> And at second, I think the large part of CPU time is the name-server/resolver >> side, not mail transfer side. > >That's *exactly* the point. As it is *now*, mail systems spend more >time calling the DNS than anything else. Waiting for it to be done >"offline" is only making it worse. The whole *reason* that my machine >runs a LOCAL caching DNS is so it DOESNT have to traverse the net and >ask another host. And as it is, I often end up having "mail undeliverable" >popping up because the host has in fact been decommissioned, but they forgot >to drop the TTL value beforehand, so it stays in my cache for a week before >I finally get a "host unknown". > Oh, no, Valdis. Some time ago I made corrections in BIND to track lost name-servers and don't wait it again (it was serios in Russia). It had dramatic influence on processing mail queue. But I had no time to rewrite sendmail - - in my mind the reason of mail queue processing is not in DNS resolving but in strategy of mail queue processing: sendmail fork one copy for one mail in queue and process delivery to remote sites in consequence (I don't know about modern versions, sorry). And you have choice - have many copies of sendmail for many mails in queue or restrict delivering time of each attempt to very short time :-( Excuse me for particular technical details in this mail-list, but I think it can illustrate tesis that directory service isn't bad idea and some technical decisions is possible. >David Gaon said: > >> But I suggest to Vladis Kletnieks that whoever creates the mailing >> list will in fact resolve the names to port addresses and enter only >> the last, or parties interested in joining the list will actually >> offer their network port address through their mail (header or body) >> since this will be available. > [emotional reply of Valdis removed] but I agree with Valdis - it IS NEED the addition level of reference for high level protocols - please remember for exam the problem of IP renumbering during provider change. Especially if some server save addresses as it is in the case of mail lists or URL references. - Leonid Yegoshin, LY22   Received: from ietf.org by ietf.org id aa02966; 1 Nov 96 16:09 EST Received: from jekyll.piermont.com by ietf.org id aa02679; 1 Nov 96 16:07 EST Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id QAA03177; Fri, 1 Nov 1996 16:06:02 -0500 (EST) Message-Id: <199611012106.QAA03177@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol To: Karl Denninger cc: Paul Hoffman , ietf@ietf.org, frezza@interramp.com Subject: Re: The cartel begins to crumble? In-reply-to: Your message of "Thu, 31 Oct 1996 17:24:16 CST." <199610312324.RAA21892@Mars.mcs.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 01 Nov 1996 16:06:01 -0500 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Karl Denninger writes: > > If I come along and say, "Ignore Karl, *I'm* selling subdomains of .biz and > > you can use my DNS server", I can fool people into giving me money just as > > easily as you can. And there might be two "mcdonalds.biz" domains, and mail > > to "info@mcdonalds.biz" can go to either place based on which DNS server an > > ISP happens to point to; same for Web accesses to "www.mcdonalds.biz". > > The second person who claims *ANY* TLD is the one to ignore. > > Not the first. Or so you would like. If you open up the door, who's to say you'll like what the people who walk through decide to do? Perry   Received: from ietf.org by ietf.org id aa04488; 1 Nov 96 16:15 EST Received: from cnri by ietf.org id aa04027; 1 Nov 96 16:13 EST Received: from verdi.nethelp.no by CNRI.Reston.VA.US id aa20639; 1 Nov 96 16:13 EST Received: (qmail 9416 invoked by uid 1001); 1 Nov 1996 21:12:52 +0000 (GMT) To: karl@mcs.net Cc: ietf@CNRI.Reston.VA.US Subject: Re: Folling the crumbling cartel - a note about thread following Sender:ietf-request@ietf.org From: sthaug@nethelp.no In-Reply-To: Your message of "Fri, 1 Nov 1996 14:46:13 -0600 (CST)" References: <199611012046.OAA29233@Mercury.mcs.net> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 01 Nov 1996 22:12:52 +0100 Message-ID: <9414.846882772@verdi.nethelp.no> Source-Info: From (or Sender) name not authenticated. > From zero operational root nameservers to 80% of the number that the IANA > has control over for how many years is not "growing support"? > > The ISPs which are switching their named root cache files to this list is > not "growing support"? My comments were in the context of Jim Fleming's note, which talks about "the growing list of root name servers which are being deployed around the world". I count 3 alternative roots outside North America. I don't know how much this list has grown lately. I'm quite willing to believe that a number of ISPs are switching their named root cache files. I haven't seen any good estimates for numbers here, though. > You also claimed miscellaneous configuration and other problems within the > alternative world. Of course, bad data in = bad conclusions out. As you've already pointed out, I had the wrong IP address for one of your alternative root servers. When you talk about 'miscellaneous configuration and other problems', I assume you're referring to Name IP address Other name Alternative Auth rootsanswer ----------------------------------------------------------------------------- MX.ALTERNIC.NET 204.94.42.1 YesNo answer USVI.NET 204.199.0.4 YesYes * * Gives authoritative answer for ".", but returns localhost! I'd say these problems are quite real, and can hardly be called 'bad data in'. A name server which returns 'localhost' as the authoritative list of name servers for "." isn't particularly usable. And I still can't get an answer to a DNS query from MX.ALTERNIC.NET, even if it answers to ping. > Further, how abotu the fact that the IANA roots were de-sync'd for several > days (and this isn't the first time) very recently (is this fixed yet?) I agree, there have been operational problems with the IANA roots, and I certainly would prefer to see fewer of them. That doesn't mean that I agree with your way of 'solving it'. Time will show who is right. Steinar Haug, Nethelp consulting, sthaug@nethelp.no   Received: from ietf.org by ietf.org id aa05119; 1 Nov 96 16:25 EST Received: from Kitten.mcs.com by ietf.org id aa04992; 1 Nov 96 16:24 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id PAA11908; Fri, 1 Nov 1996 15:23:10 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 15:23 CST Received: (from karl@localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id PAA02754; Fri, 1 Nov 1996 15:23:07 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611012123.PAA02754@Mercury.mcs.net> Subject: Re: The cartel begins to crumble? To: perry@piermont.com Date: Fri, 1 Nov 1996 15:23:07 -0600 (CST) Cc: karl@mcs.net, paulh@imc.org, ietf@ietf.org, frezza@interramp.com In-Reply-To: <199611012106.QAA03177@jekyll.piermont.com> from "Perry E. Metzger" at Nov 1, 96 04:06:01 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > Karl Denninger writes: >> > If I come along and say, "Ignore Karl, *I'm* selling subdomains of .biz and >> > you can use my DNS server", I can fool people into giving me money just as >> > easily as you can. And there might be two "mcdonalds.biz" domains, and mail >> > to "info@mcdonalds.biz" can go to either place based on which DNS server an >> > ISP happens to point to; same for Web accesses to "www.mcdonalds.biz". > > > > The second person who claims *ANY* TLD is the one to ignore. > > > > Not the first. > > Or so you would like. > > If you open up the door, who's to say you'll like what the people who > walk through decide to do? > > Perry I truly believe that there can be consensus found on what "reasonable" claims and registry density might be. I posted one such possible starting point to these lists in the last 24 hours. Why don't we debate and try to find consensus on *that* point? If we can, then the entire argument related to this drops to the floor as irrelavent, yes? And if THAT happens, then we all have one goal left - leveraging the hold-outs in the root-server game (or rendering them impotent). -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa06269; 1 Nov 96 16:42 EST Received: from callandor.cybercash.com by ietf.org id aa06039; 1 Nov 96 16:39 EST Received: by callandor.cybercash.com; id QAA04498; Fri, 1 Nov 1996 16:34:15 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma004486; Fri, 1 Nov 96 16:33:58 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA13582; Fri, 1 Nov 96 16:36:28 EST Date: Fri, 1 Nov 1996 16:36:28 -0500 (EST) Sender:ietf-request@ietf.org From: "Donald E. Eastlake 3rd" To: David Gaon Cc: ietf@ietf.org Subject: "directories versus DNS" In-Reply-To: <9610018468.AA846890402@ncr.disa.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Fri, 1 Nov 1996, David Gaon wrote: > Date: Fri, 01 Nov 96 15:17:47 EST > From: David Gaon > To: Valdis.Kletnieks@vt.edu, Leonid Egoshin > Cc: ietf@ietf.org > Subject: Re[5]: The cartel begins to crumble? > > Leonid > > Thanks, I believe you have captured my intent. > > But I suggest to Vladis Kletnieks that whoever creates the mailing > list will in fact resolve the names to port addresses and enter only > the last, or parties interested in joining the list will actually > offer their network port address through their mail (header or body) > since this will be available. > > Cheers > > David Gaon > DoD/DISA/Center for Standards But you can't store IP numbers or something like that because the keep changing (and, it seems likely, will change more often in the future). So what do you store? If your directory leads to an intermediate value you need to map to IP addresses, you've just re-invented DNS. So what was the gain? Donald   Received: from ietf.org by ietf.org id aa06265; 1 Nov 96 16:42 EST Received: from cnri by ietf.org id aa06114; 1 Nov 96 16:40 EST Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa21187; 1 Nov 96 16:40 EST Received: from sayshell.UU.NET by rodan.UU.NET with SMTP (peer crosschecked as: sayshell.UU.NET [153.39.251.30]) id QQbnzq24927; Fri, 1 Nov 1996 16:39:25 -0500 (EST) Message-Id: X-Mailer: exmh version 1.6.9 8/22/96 To: Karl Denninger cc: sthaug@nethelp.no, ietf@CNRI.Reston.VA.US Sender:ietf-request@ietf.org From: "Louis A. Mamakos" Subject: Re: Folling the crumbling cartel - a note about thread following References: <199611012011.OAA27288@Mercury.mcs.net> In-reply-to: Your message of "Fri, 01 Nov 1996 14:11:38 CST." <199611012011.OAA27288@Mercury.mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Nov 1996 16:39:25 -0500 X-Orig-Sender: louie@uu.net Source-Info: From (or Sender) name not authenticated. > > TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes > Does someone care to tell me under what authority NSI is running COM, ORG > and NET on servers owned by the US Government (three of the above) and two > publically funded universities (2 more of the above)? :-) When I set up the root server on TERP.UMD.EDU many years ago, it was done as a public service with no expectation of renumeration. At the time, that machine was richly connected to the Internet, being one of the routers between the ARPANET and the then NSFNET phase-1 backbone. > 1/2 of your operating infrastructure effectively paid for (at least in part) > with public funds... not bad for a for-profit company! While we can decend in this rat-hole, I think that the cost is that of administration of the name space, and not running the servers. There are very likely no shortage of qualified organizations who would be happy to run root/TLD name servers at no cost. Certainly UUNET is willing to do so. -- Louis A. Mamakos, Manager, Strategic Technologies louie@uu.net, uunet!louie UUNET Technologies, Inc. Voice: +1 703 206 5823 3060 Williams Drive Fax: +1 703 208 5390 Fairfax, VA 22031   Received: from ietf.org by ietf.org id aa07233; 1 Nov 96 16:53 EST Received: from jekyll.piermont.com by ietf.org id aa06904; 1 Nov 96 16:50 EST Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id QAA03325; Fri, 1 Nov 1996 16:49:34 -0500 (EST) Message-Id: <199611012149.QAA03325@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol To: Karl Denninger cc: Per Gregers Bilse , ietf@ietf.org, frezza@interramp.com Subject: Re: The cartel begins to crumble? In-reply-to: Your message of "Fri, 01 Nov 1996 09:12:36 CST." <199611011512.JAA06591@Mercury.mcs.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 01 Nov 1996 16:49:33 -0500 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Karl Denninger writes: > Operational registries Per Gregers, nothing more or less. > > We have it (and had it first), you did not. > > I can declare myself emporer of the known universe, but unless I do > something to demonstrate that I'm serious (ie: find a way to actually govern > and enforce it across every person on the planet) all I get is laughed at. Karl; As it stands, your "operational registries" are invisible to most of the planet. By your own standards of enforceability, you are doing the equivalent of declaring yourself emperor of the universe. Perry   Received: from ietf.org by ietf.org id aa07232; 1 Nov 96 16:53 EST Received: from cnri by ietf.org id aa06954; 1 Nov 96 16:51 EST Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa21507; 1 Nov 96 16:51 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id PAA13219; Fri, 1 Nov 1996 15:50:24 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 15:50 CST Received: (from karl@localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id PAA04316; Fri, 1 Nov 1996 15:50:22 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611012150.PAA04316@Mercury.mcs.net> Subject: Re: Folling the crumbling cartel - a note about thread following To: "Louis A. Mamakos" Date: Fri, 1 Nov 1996 15:50:21 -0600 (CST) Cc: karl@mcs.net, sthaug@nethelp.no, ietf@CNRI.Reston.VA.US In-Reply-To: from "Louis A. Mamakos" at Nov 1, 96 04:39:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > > TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes > > > Does someone care to tell me under what authority NSI is running COM, ORG > > and NET on servers owned by the US Government (three of the above) and two > > publically funded universities (2 more of the above)? :-) > > When I set up the root server on TERP.UMD.EDU many years ago, it was done > as a public service with no expectation of renumeration. At the time, > that machine was richly connected to the Internet, being one of the > routers between the ARPANET and the then NSFNET phase-1 backbone. > > > 1/2 of your operating infrastructure effectively paid for (at least in part) > > with public funds... not bad for a for-profit company! > > While we can decend in this rat-hole, I think that the cost is that of > administration of the name space, and not running the servers. There are > very likely no shortage of qualified organizations who would be happy to > run root/TLD name servers at no cost. Certainly UUNET is willing to do > so. And for a private company to decide to do that (including MCSNet, which it does) I think that is a perfectly-valid decision to make. Its your money. Spend it as you believe to be wise. Including giving another firm the technical means to make $20,000,000 a year (without renumerating any part of that to you) if you wish. Proper infrastructure is NOT cheap if you intend to provide quality root nameservice (or any nameservice for that matter). You certainly aren't going to do it without some kind of redundancy in your connectivity, and even if you buy two T1s it runs into the tens of thousands of dollars a year. Yes, it looks like chickenfeed when you look at a $20M business annually, but frankly, lots of people have gotten in serious trouble for converting a lot less value then that to private profit and use. Without these nameservers NSI wouldn't have a business to run. You can register anything you want, but if you can't publish it, the TLD is useless. Again, I don't even have a problem with public institutions necessarily providing root nameservers - as long as they're open on a non-discriminatory basis (ie: no IANA "you can't list that without paying our tax" games). When it comes to those same public institutions underwriting the operational costs of a for-profit company, I believe there's a severe problem. When it comes to US *government* institutions doing so, it can be more than just a policy problem -- depending on the exact particulars of the case, of course. > Louis A. Mamakos, Manager, Strategic Technologies louie@uu.net, uunet!louie > UUNET Technologies, Inc. Voice: +1 703 206 5823 -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa07351; 1 Nov 96 16:53 EST Received: from Kitten.mcs.com by ietf.org id aa07149; 1 Nov 96 16:52 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id PAA13275; Fri, 1 Nov 1996 15:51:33 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 15:51 CST Received: (from karl@localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id PAA04458; Fri, 1 Nov 1996 15:51:30 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611012151.PAA04458@Mercury.mcs.net> Subject: Re: The cartel begins to crumble? To: perry@piermont.com Date: Fri, 1 Nov 1996 15:51:30 -0600 (CST) Cc: karl@mcs.net, bilse@eu.net, ietf@ietf.org, frezza@interramp.com In-Reply-To: <199611012149.QAA03325@jekyll.piermont.com> from "Perry E. Metzger" at Nov 1, 96 04:49:33 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > > Karl Denninger writes: > > Operational registries Per Gregers, nothing more or less. > > > > We have it (and had it first), you did not. > > > > I can declare myself emporer of the known universe, but unless I do > > something to demonstrate that I'm serious (ie: find a way to actually govern > > and enforce it across every person on the planet) all I get is laughed at. > > Karl; > > As it stands, your "operational registries" are invisible to most of > the planet. By your own standards of enforceability, you are doing the > equivalent of declaring yourself emperor of the universe. > > Perry Really? They're not invisible to anyone who supports the eDNS servers. And their existing IS published. Widely. And has been for months. Give the straw men up Perry, and debate the issues at hand. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa08412; 1 Nov 96 17:12 EST Received: from cnri by ietf.org id aa08315; 1 Nov 96 17:10 EST Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa21999; 1 Nov 96 17:10 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id QAA28402; Fri, 1 Nov 1996 16:04:48 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC80E.9F53FEC0@webster.unety.net>; Fri, 1 Nov 1996 16:06:21 -0600 Message-ID: <01BBC80E.9F53FEC0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "karl@mcs.net" , "'sthaug@nethelp.no'" Cc: "ietf@CNRI.Reston.VA.US" Subject: RE: Folling the crumbling cartel - a note about thread following Date: Fri, 1 Nov 1996 16:06:19 -0600 Encoding: 78 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 01, 1996 2:32 PM, sthaug@nethelp.no wrote: @ > Does someone care to tell me under what authority NSI is running COM, ORG @ > and NET on servers owned by the US Government (three of the above) and two @ > publically funded universities (2 more of the above)? :-) @ > @ > 1/2 of your operating infrastructure effectively paid for (at least in part) @ > with public funds... not bad for a for-profit company! @ @ I'm not the right person to comment on this - but I see that you prefer @ to discuss other things than the claimed 'growing support'. @ @ > > ROOT-NS.MCS.NET 192.160.127.8 YesNo route @ > @ > That IP address is wrong. The right one is 192.160.127.86. If you ping @ > the right address (or dig to it) you'll find that it does work. @ @ My fault. Note that in my table I assumed it supported the alternative @ roots, so my count of 8 servers for the alternative roots is unchanged. @ @ > > Quite frankly, I can't see that you have shown anything whatsoever about @ > > growing support for your alternative roots around the world. Furthermore, @ > > I can't see any reason why I should "take this work seriously". @ > @ > Well, you could start by making sure you're looking in the right place! :-) @ @ I still can't see that anything you've said here supports the notion @ that there is growing support for your alternative roots around the world. @ @ Steinar Haug, Nethelp consulting, sthaug@nethelp.no @ @ In the last two days, I have received a confirmation from four ISPs in the United States who are not listed above. One of the leaders of Japan's Internet community has asked if they can add a root name server to the list. I continue to get interest from Australia and some of the other "wired" places on the planet. Also, keep in mind that I am just one reference point. Paul Vixie indicated recently that there is no shortage of people that want to operate root name servers. I am not sure if he is making a list. Also, Eugene Kashpureff mentioned having a long list of interested parties that he is working as part of the AlterNIC. Quite frankly, one of my major concerns is that too many people will want to provide root name servers. In the United States, this is probably most easily handled with a Root 128 group, that just includes U.S. root name servers. The Root 64 name server grouping is intended to focus the attention on a broader International distribution. The Root 64 group will likely be a harder group to fill, but could end up being viewed as more fair in its deliberations because of the diversity of opinions from around the world. Only time will tell as to how these various "roots" (or routes) evolve in cyberspace. One thing for sure, many years from now Root 64 might be sitting next to Route 66 on a web page as just another chapter in the history of man's attempt to create highways to connect people. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa09492; 1 Nov 96 17:26 EST Received: from cnri by ietf.org id aa09366; 1 Nov 96 17:25 EST Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa22276; 1 Nov 96 17:25 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id QAA28454; Fri, 1 Nov 1996 16:19:32 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC810.AE47E5C0@webster.unety.net>; Fri, 1 Nov 1996 16:21:05 -0600 Message-ID: <01BBC810.AE47E5C0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: Karl Denninger , "'Louis A. Mamakos'" Cc: "ietf@CNRI.Reston.VA.US" , 'New Newdom' , "sthaug@nethelp.no" Subject: RE: Folling the crumbling cartel - a note about thread following Date: Fri, 1 Nov 1996 16:21:03 -0600 Encoding: 45 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 01, 1996 3:39 PM, Louis A. Mamakos[SMTP:louie@uu.net] wrote: @ > > TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes @ @ > Does someone care to tell me under what authority NSI is running COM, ORG @ > and NET on servers owned by the US Government (three of the above) and two @ > publically funded universities (2 more of the above)? :-) @ @ When I set up the root server on TERP.UMD.EDU many years ago, it was done @ as a public service with no expectation of renumeration. At the time, @ that machine was richly connected to the Internet, being one of the @ routers between the ARPANET and the then NSFNET phase-1 backbone. @ @ > 1/2 of your operating infrastructure effectively paid for (at least in part) @ > with public funds... not bad for a for-profit company! @ @ While we can decend in this rat-hole, I think that the cost is that of @ administration of the name space, and not running the servers. There are @ very likely no shortage of qualified organizations who would be happy to @ run root/TLD name servers at no cost. Certainly UUNET is willing to do @ so. @ @ -- @ Louis A. Mamakos, Manager, Strategic Technologies louie@uu.net, uunet!louie @ UUNET Technologies, Inc. Voice: +1 703 206 5823 @ 3060 Williams Drive Fax: +1 703 208 5390 @ Fairfax, VA 22031 @ @ At the risk of claiming that there is a "growing" group of parties interested in running root name servers, I would suggest that you might want to deploy a server and join either the Root 64 collection or the Root 128 collection (for U.S. only). -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa09791; 1 Nov 96 17:30 EST Received: from nirvana.genesyslab.com by ietf.org id aa09547; 1 Nov 96 17:29 EST Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id OAA22929; Fri, 1 Nov 1996 14:28:41 -0800 (PST) Received: (from egoshin@localhost) by giant.genesyslab.com (8.7.5/8.7.3) id OAA12175; Fri, 1 Nov 1996 14:28:18 -0800 (PST) Date: Fri, 1 Nov 1996 14:28:18 -0800 (PST) Sender:ietf-request@ietf.org From: Leonid Egoshin Message-Id: <199611012228.OAA12175@giant.genesyslab.com> To: Valdis.Kletnieks@vt.edu Subject: Re: Re[3]: The cartel begins to crumble? Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. >From: Valdis.Kletnieks@vt.edu > >The basic problem is that if I say "it has to be at least as fast as DNS", >then it falls to the proponents of LDAP or X.500 or WHOIS++ or whatever, >to demonstrate that at least in principle, it will resolve queries just as >fast, when scaled to the size needed. And yes, I'm familiar with the >work that the U of Michigan crew has done to speed up LDAP - it's almost >fast enough *within an organization* but still has problems scaling... Ok, but what about the next - we can separate all protocols which used DNS on two groups - protocols for search and for mapping only. For exam in first group can be whois,finger,www(during first looking attempt) and mail (my be not real mail, but some tools for search right address); and in second group can be other which requered distinct and speed mapping. And both - DNS and directory service can coexist. And this division would service like www..com and other outside of DNS (or something another notation instead of .com). Probably this direction can solve the problem of decentralisation of service with correct mapping... - Leonid Yegoshin, LY22   Received: from ietf.org by ietf.org id aa09977; 1 Nov 96 17:30 EST Received: from bast.livingston.com by ietf.org id aa09722; 1 Nov 96 17:29 EST Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.7.5/8.6.9) with ESMTP id OAA19719 for ; Fri, 1 Nov 1996 14:29:49 -0800 (PST) Received: (from megazone@localhost) by server.livingston.com (8.7.1/8.6.9) id OAA26244 for ietf@ietf.org; Fri, 1 Nov 1996 14:28:44 -0800 (PST) Message-Id: <199611012228.OAA26244@server.livingston.com> Subject: Offline lookups? No way - was Cartel et al To: ietf@ietf.org Date: Fri, 1 Nov 1996 14:28:44 -0800 (PST) Sender:ietf-request@ietf.org From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe Content-Type: text Source-Info: From (or Sender) name not authenticated. Once upon a time David Gaon shaped the electrons to say... > the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is lef > to the user and is done offline (with respect to the communications > infrastructure). The user, on deciding whom he wants to reach, either That's why this will never work. Machines get renumbered ALL THE TIME. That is why DNS is so damn useful in the first place - just remember the name, and DNS will find the current number. The CD would be out of date before it shipped. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com Snail mail: 6920 Koll Center Parkway #220, Pleasanton, CA 94566   Received: from ietf.org by ietf.org id aa10514; 1 Nov 96 17:38 EST Received: from jekyll.piermont.com by ietf.org id aa10280; 1 Nov 96 17:36 EST Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id RAA03512; Fri, 1 Nov 1996 17:35:33 -0500 (EST) Message-Id: <199611012235.RAA03512@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol To: Karl Denninger cc: bilse@eu.net, ietf@ietf.org, frezza@interramp.com Subject: Re: The cartel begins to crumble? In-reply-to: Your message of "Fri, 01 Nov 1996 15:51:30 CST." <199611012151.PAA04458@Mercury.mcs.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 01 Nov 1996 17:35:32 -0500 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Karl Denninger writes: > > As it stands, your "operational registries" are invisible to most of > > the planet. By your own standards of enforceability, you are doing the > > equivalent of declaring yourself emperor of the universe. > > Really? They're not invisible to anyone who supports the eDNS servers. Did I say that? I merely said they are invisible to virtually everyone (that is, well over 99%) of the people using the internet. I'm happy, however, to shift the discussion to the large issues of TLDs and DNS management. Perry   Received: from ietf.org by ietf.org id aa10568; 1 Nov 96 17:38 EST Received: from servo.qualcomm.com by ietf.org id aa10458; 1 Nov 96 17:37 EST Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id OAA09605; Fri, 1 Nov 1996 14:36:17 -0800 (PST) Date: Fri, 1 Nov 1996 14:36:17 -0800 (PST) Sender:ietf-request@ietf.org From: Phil Karn Message-Id: <199611012236.OAA09605@servo.qualcomm.com> To: ERIC@vm.se.lsoft.com CC: ietf@ietf.org In-reply-to: <9610311326.aa10929@ietf.org> (message from Eric Thomas on Thu, 31 Oct 1996 19:03:36 +0100) Subject: Re: English is it -> was: Re: The cartel begins to crumble? Source-Info: From (or Sender) name not authenticated. I have an extra item for your list. Americans are among the most assertive and outspoken people in the world, and American IETFers are among the most assertive and outspoken Americans. Our passions can easily intimidate those of other cultures (especially Asians) into offended silence. As a result, simple misunderstandings can erupt into major battles or at least long-term resentment. The IETF is an English-speaking, US-centric organization because the Internet originated in the US. This is likely to remain so for a long time. So while it is certainly a good idea for American IETFers to be more sensitive to those from non-English speaking countries, it would also be a good idea for non-US IETF members who have honest disagreements to try to be more assertive than they ordinarily are back home. Sure, people may take offense from time to time, but this is rarely fatal. More often it's an unavoidable side-effect of clearing the air and making real progress. Phil   Received: from ietf.org by ietf.org id aa10853; 1 Nov 96 17:43 EST Received: from cnri by ietf.org id aa10758; 1 Nov 96 17:41 EST Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa22608; 1 Nov 96 17:41 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id QAA16037; Fri, 1 Nov 1996 16:40:36 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 16:40 CST Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.Beta.3) id QAA12841; Fri, 1 Nov 1996 16:40:31 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611012240.QAA12841@Jupiter.Mcs.Net> Subject: Re: Folling the crumbling cartel - a note about thread following To: Valdis.Kletnieks@vt.edu Date: Fri, 1 Nov 1996 16:40:31 -0600 (CST) Cc: karl@mcs.net, ietf@CNRI.Reston.VA.US In-Reply-To: <199611012235.RAA36628@black-ice.cc.vt.edu> from "Valdis.Kletnieks@vt.edu" at Nov 1, 96 05:35:10 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > response. The only reason its not a LOT better is that you still have > > to go back to those same machines for these zones..... > > Are you saying that when you get as overloaded as they are, you'll be > just as sluggish? I'll bet that if *I* ran my own root nameserver on > my RT in my basement, I'd see a BLINDING speedup for the small section of > things that I was root for. > > I'd worry if you can only get 40% faster serving a very small segment of *.BIZ > addresses in existence, compared to having to serve *.COM. Are you sure you > want to brag about that? No, we're 40% faster *across the board*. Since COM, NET and ORG are the majority of records, this is in fact remarkable. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa11906; 1 Nov 96 18:01 EST Received: from cnri by ietf.org id aa11673; 1 Nov 96 17:59 EST Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa23011; 1 Nov 96 17:59 EST Received: from sayshell.UU.NET by rodan.UU.NET with SMTP (peer crosschecked as: sayshell.UU.NET [153.39.251.30]) id QQbnzv10613; Fri, 1 Nov 1996 17:57:58 -0500 (EST) Message-Id: X-Mailer: exmh version 1.6.9 8/22/96 To: Jim Fleming cc: Karl Denninger , "ietf@CNRI.Reston.VA.US" , 'New Newdom' , "sthaug@nethelp.no" Sender:ietf-request@ietf.org From: "Louis A. Mamakos" Subject: Re: Folling the crumbling cartel - a note about thread following References: <01BBC810.AE47E5C0@webster.unety.net> In-reply-to: Your message of "Fri, 01 Nov 1996 16:21:03 CST." <01BBC810.AE47E5C0@webster.unety.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Nov 1996 17:57:58 -0500 X-Orig-Sender: louie@uu.net Source-Info: From (or Sender) name not authenticated. > At the risk of claiming that there is a "growing" group > of parties interested in running root name servers, I > would suggest that you might want to deploy a server > and join either the Root 64 collection or the Root 128 > collection (for U.S. only). While I can't speak on behalf of all of UUNET, I can certainly offer my opinion. I don't think that UUNET would be interested in running a "rogue" root name server. The willingness of our running a root name server is so that our customer would derive some benifit (as well as the public at large) by having robust connectivity to a reliably and competently operated name server. Having a nameserver which doesn't participate in the commonly accepted namespace is counter-productive and results in unhappy customers and users who can't get to where they want to go (or vice versa). I won't expound on this further, as the pursuasive arguments have already been made on the list. Having a disjoint namespace is just counterproductive and creates another set of problems. > e-mail: > JimFleming@unety.net > JimFleming@unety.net.s0.g0 (EDNS/IPv8) But I guess this argument is wasted on those who have "left the fold" as it were.. How is this EDNS/IPv8 thing useful, other than those who've joined the private club? The success of the Internet is that there is the underlying universal interoperability between all those that join "The Internet." -- Louis A. Mamakos, Manager, Strategic Technologies louie@uu.net, uunet!louie UUNET Technologies, Inc. Voice: +1 703 206 5823 3060 Williams Drive Fax: +1 703 208 5390 Fairfax, VA 22031   Received: from ietf.org by ietf.org id aa12078; 1 Nov 96 18:04 EST Received: from cnri by ietf.org id aa11993; 1 Nov 96 18:03 EST Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa23115; 1 Nov 96 18:03 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id RAA17156; Fri, 1 Nov 1996 17:02:08 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 17:02 CST Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.Beta.3) id RAA13532; Fri, 1 Nov 1996 17:02:05 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611012302.RAA13532@Jupiter.Mcs.Net> Subject: Re: Folling the crumbling cartel - a note about thread following To: "Louis A. Mamakos" Date: Fri, 1 Nov 1996 17:02:05 -0600 (CST) Cc: JimFleming@unety.net, karl@mcs.net, ietf@CNRI.Reston.VA.US, newdom@vrx.net, sthaug@nethelp.no In-Reply-To: from "Louis A. Mamakos" at Nov 1, 96 05:57:58 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > At the risk of claiming that there is a "growing" group > > of parties interested in running root name servers, I > > would suggest that you might want to deploy a server > > and join either the Root 64 collection or the Root 128 > > collection (for U.S. only). > > While I can't speak on behalf of all of UUNET, I can certainly > offer my opinion. I don't think that UUNET would be interested > in running a "rogue" root name server. The willingness of our > running a root name server is so that our customer would derive some > benifit (as well as the public at large) by having robust connectivity > to a reliably and competently operated name server. > > Having a nameserver which doesn't participate in the commonly > accepted namespace is counter-productive and results in unhappy > customers and users who can't get to where they want to go (or > vice versa). > > I won't expound on this further, as the pursuasive arguments have > already been made on the list. Having a disjoint namespace is just > counterproductive and creates another set of problems. > > > e-mail: > > JimFleming@unety.net > > JimFleming@unety.net.s0.g0 (EDNS/IPv8) > > But I guess this argument is wasted on those who have "left the fold" > as it were.. How is this EDNS/IPv8 thing useful, other than > those who've joined the private club? The success of the Internet is > that there is the underlying universal interoperability between all those > that join "The Internet." > > -- > Louis A. Mamakos, Manager, Strategic Technologies louie@uu.net, uunet!louie > UUNET Technologies, Inc. Voice: +1 703 206 5823 Really? And you get to define what the namespace of "The Internet" is, right? Or, more correctly, the IANA gets to define it? Why? The nameservers you claim to be "rogue" don't corrupt the IANA information. If they did, or if they do in the future try to delegate a domain (ie: .COM) that is already taken by another claimant, you'll find me (along with a bunch of other people who support eDNS now) screaming just as loudly about that set of brokenness -- and then removing them from the cache list. Your claim is that the other DNS root servers don't participate in the "commonly accepted namespace". Care to verify that by providing us with an example of a TLD which is in the IANA roots and missing from eDNS? Or is the concept of *enhancing* service for UUNET's customers lost here? No legacy names are broken by supporting eDNS. Not one. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa14276; 1 Nov 96 18:13 EST Received: from cnri by ietf.org id aa14060; 1 Nov 96 18:11 EST Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa23241; 1 Nov 96 18:11 EST Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 1 Nov 1996 15:09:58 -0800 Sender:ietf-request@ietf.org From: bmanning@isi.edu Posted-Date: Fri, 1 Nov 1996 15:09:20 -0800 (PST) Message-Id: <199611012309.AA02894@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 1 Nov 1996 15:09:21 -0800 Subject: Why Jim thinks his root servers are better than the operational ones To: sthaug@nethelp.no Date: Fri, 1 Nov 1996 15:09:20 -0800 (PST) Cc: karl@mcs.net, ietf@CNRI.Reston.VA.US In-Reply-To: <9414.846882772@verdi.nethelp.no> from "sthaug@nethelp.no" at Nov 1, 96 10:12:52 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 367 Source-Info: From (or Sender) name not authenticated. > I agree, there have been operational problems with the IANA roots, and > I certainly would prefer to see fewer of them. That doesn't mean that I > agree with your way of 'solving it'. Time will show who is right. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > Would that be fewer operational problems or fewer IANA sactioned roots? :) -- --bill   Received: from ietf.org by ietf.org id aa14338; 1 Nov 96 18:14 EST Received: from cnri by ietf.org id aa14257; 1 Nov 96 18:13 EST Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa23306; 1 Nov 96 18:13 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id RAA28721; Fri, 1 Nov 1996 17:07:17 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC817.59D73660@webster.unety.net>; Fri, 1 Nov 1996 17:08:49 -0600 Message-ID: <01BBC817.59D73660@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "'Louis A. Mamakos'" Cc: "ietf@CNRI.Reston.VA.US" , Karl Denninger , 'New Newdom' , "sthaug@nethelp.no" Subject: RE: Folling the crumbling cartel - a note about thread following Date: Fri, 1 Nov 1996 17:08:48 -0600 Encoding: 97 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 01, 1996 4:57 PM, Louis A. Mamakos[SMTP:louie@UU.NET] wrote: @ @ > At the risk of claiming that there is a "growing" group @ > of parties interested in running root name servers, I @ > would suggest that you might want to deploy a server @ > and join either the Root 64 collection or the Root 128 @ > collection (for U.S. only). @ @ While I can't speak on behalf of all of UUNET, I can certainly @ offer my opinion. I don't think that UUNET would be interested @ in running a "rogue" root name server. The willingness of our @ running a root name server is so that our customer would derive some @ benifit (as well as the public at large) by having robust connectivity @ to a reliably and competently operated name server. @ If you define a "rogue" root name server as one that supports all of the top level domain registries, currently operating then I guess we have to disagree. I would call that a rich or robust root name server, but you chose the word rogue. If UUNET is only interested in running a name server that supports some subset that UUNET selects, then you might want to describe how you arrive at that subset decision and anyone (mostly ISPs) that uses your root name server should be informed that you are operating a limited root name server. Limited root name servers may have merit if society really feels that limiting access to the .XXX and .SEX top level domains is something that people want. Unfortunately, once UUNET starts down the road of picking and choosing top level domain names, then you enter the world of censorship issues. @ Having a nameserver which doesn't participate in the commonly @ accepted namespace is counter-productive and results in unhappy @ customers and users who can't get to where they want to go (or @ vice versa). @ I agree, that is why I am advocating that the group of Root 64 name server owners and operators be allowed to come to a market consensus based in large part from the new top level domain registries that are emerging. That process will develop what you refer to as the "commonly accepted namespace". @ I won't expound on this further, as the pursuasive arguments have @ already been made on the list. Having a disjoint namespace is just @ counterproductive and creates another set of problems. @ I agree...except as noted above regarding potential social benefits or desires, and I prefer not to ge there either... @ > e-mail: @ > JimFleming@unety.net @ > JimFleming@unety.net.s0.g0 (EDNS/IPv8) @ @ But I guess this argument is wasted on those who have "left the fold" @ as it were.. How is this EDNS/IPv8 thing useful, other than @ those who've joined the private club? The success of the Internet is @ that there is the underlying universal interoperability between all those @ that join "The Internet." @ No one has left the fold. The Internet is capable of supporting many communities and experimental efforts. That is one way it evolves. I would hope that you do not look at people's business cards and note their FAX number and say, "OH I see that you have left the fold"... Also.....some people have discovered that the use of zip-codes helps to improve the performance of their mail delivery...I would hope that when you see a letter with a zip-code that you do not think a person or company has "left the fold"... @ -- @ Louis A. Mamakos, Manager, Strategic Technologies louie@uu.net, uunet!louie @ UUNET Technologies, Inc. Voice: +1 703 206 5823 @ 3060 Williams Drive Fax: +1 703 208 5390 @ Fairfax, VA 22031 @ ....Hmmm...have you left the fold with that FAX number above...? ...what about that zip-code... ...Oh...the conclusions we could draw...;-) -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa16021; 1 Nov 96 18:35 EST Received: from tipper.oit.unc.edu by ietf.org id aa15922; 1 Nov 96 18:33 EST Received: from tipper.oit.unc.edu (tipper.oit.unc.edu [152.2.22.85]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id SAA10527 for ; Fri, 1 Nov 1996 18:33:37 -0500 Date: Fri, 1 Nov 1996 18:33:36 -0500 (EST) Sender:ietf-request@ietf.org From: Simon Spero To: ietf@ietf.org Subject: Carpools and Cartels In-Reply-To: <199611012106.QAA03177@jekyll.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. [Never one to miss the opportunity for a segue, Are there any carpools going from SF to San Jose during the IETF?] In comp.protocols.tcp-ip.domains, Karl made an interesting claim as to ownership of .biz based on his newgrouping of various usenet biz.* groups. My immediate response was to ask whether that precendent would give UNC & Duke control of the .net domain... --- If I can get my key back, it's Key Recovery If you can get my key back, it's Key Escrow   Received: from ietf.org by ietf.org id aa16575; 1 Nov 96 18:39 EST Received: from cnri by ietf.org id aa16433; 1 Nov 96 18:38 EST Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa23677; 1 Nov 96 18:38 EST Received: from sayshell.UU.NET by rodan.UU.NET with SMTP (peer crosschecked as: sayshell.UU.NET [153.39.251.30]) id QQbnzy17707; Fri, 1 Nov 1996 18:37:25 -0500 (EST) Message-Id: X-Mailer: exmh version 1.6.9 8/22/96 To: Jim Fleming cc: "ietf@CNRI.Reston.VA.US" , Karl Denninger , 'New Newdom' , "sthaug@nethelp.no" Sender:ietf-request@ietf.org From: "Louis A. Mamakos" Subject: Re: Folling the crumbling cartel - a note about thread following References: <01BBC817.59D73660@webster.unety.net> In-reply-to: Your message of "Fri, 01 Nov 1996 17:08:48 CST." <01BBC817.59D73660@webster.unety.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Nov 1996 18:37:23 -0500 X-Orig-Sender: louie@uu.net Source-Info: From (or Sender) name not authenticated. > If you define a "rogue" root name server as one that supports > all of the top level domain registries, currently operating then > I guess we have to disagree. I would call that a rich or robust > root name server, but you chose the word rogue. Please, feel free to select any adjective you choose to describe the "other" name servers. > If UUNET is only interested in running a name server that > supports some subset that UUNET selects, then you might > want to describe how you arrive at that subset decision and > anyone (mostly ISPs) that uses your root name server should > be informed that you are operating a limited root name server. As I mentioned before, UUNET has not spoken one way or the other on this issue. As I'm not an officer of the company (just a stockholder), I can't make unlateral statements. But in any case, like it or not, UUNET and other organizations on the internet get to choose which root name servers they use for their purposes. You are just the first to come along with an alternative name space. > Limited root name servers may have merit if society really > feels that limiting access to the .XXX and .SEX top level domains > is something that people want. Unfortunately, once UUNET > starts down the road of picking and choosing top level domain > names, then you enter the world of censorship issues. And when the next group of people come along that disagree with your procedures and policies, and create their own .XXX and .SEX domain - then what? Who's "right?" And, please, don't start thumping on the "censorship" drum. That's just a damn red herring, and you know it. There is nothing which prevents any organziation from running their own caching name servers and choosing to do what they please. That certainly includes UUNET's customers and MCI's customers and my network at home. Many ISP's run caching name servers as a service to their customers, and they chose to do so in a way which provides robust service and hopfully minimized phone calls to the customer support staff. That an organziation chooses to recognize the "generally accepted" set of name servers is perfectly reasonable. > @ Having a nameserver which doesn't participate in the commonly > @ accepted namespace is counter-productive and results in unhappy > @ customers and users who can't get to where they want to go (or > @ vice versa). > @ > > I agree, that is why I am advocating that the group of Root 64 > name server owners and operators be allowed to come to a > market consensus based in large part from the new top level > domain registries that are emerging. That process will develop > what you refer to as the "commonly accepted namespace". Feel free to beat the bush and gain supporters. Unilaterally creating TLDs, though, is another matter. Who mediates? What if I want the .SEX domain? Why is my claim any less valid than yours? > No one has left the fold. The Internet is capable of supporting many > communities and experimental efforts. That is one way it evolves. I'm certainly not trying to stifle experiments. However, there is a large poplulation of users on the Internet which expect it to be run as a production service they can depend on, and experiments are mostly incompatible with that. While we certainly are involved in experimental projects, there is a clear distinction between them and a production service which our engineering and operations staff are here to support. My personal opinion is that it would be unwise to have an alternative namespaces to choose from as part of a production service. You might disagree with that opinion. Further, I think there are some good reasons not to have 64 or 128 root name servers. You'll make the packet sizes large enough to require TCP transport as the UDP responses are too large to be returned unfragmented. It was this issue which prompted the re-naming of the root name servers into the "ROOT-SERVERS.NET" domain, so that the common substring could be omitted by the "compression" algorithm used to encode the DNS packets. I'm guessing that you'd propose to not return the full set, and then change the way that the DNS works? > I would hope that you do not look at people's business cards and > note their FAX number and say, "OH I see that you have left the fold"... Yes, but when I see a card with "Internet: louie@UU.NET", I'd expect to be able to use that email address on the thing which is generally accepted to be "The Internet" and have it work. While I also have a "uunet!louie" address listed for an older, alternative email transport, I rarely get many messages sent to me that way and longer. > Also.....some people have discovered that the use of zip-codes > helps to improve the performance of their mail delivery...I would > hope that when you see a letter with a zip-code that you do not > think a person or company has "left the fold"... Now you're just being silly. Finally, I doubt this has relevance to the IETF mailing list any longer, and I know that I have work to do.. -- Louis A. Mamakos, Manager, Strategic Technologies louie@uu.net, uunet!louie UUNET Technologies, Inc. Voice: +1 703 206 5823 3060 Williams Drive Fax: +1 703 208 5390 Fairfax, VA 22031   Received: from ietf.org by ietf.org id aa17793; 1 Nov 96 18:54 EST Received: from cnri by ietf.org id aa17690; 1 Nov 96 18:52 EST Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa23938; 1 Nov 96 18:52 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id RAA28872; Fri, 1 Nov 1996 17:46:48 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBC81C.DED103A0@webster.unety.net>; Fri, 1 Nov 1996 17:48:20 -0600 Message-ID: <01BBC81C.DED103A0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "'Louis A. Mamakos'" Cc: "ietf@CNRI.Reston.VA.US" , Karl Denninger , 'New Newdom' , "sthaug@nethelp.no" Subject: RE: Folling the crumbling cartel - a note about thread following Date: Fri, 1 Nov 1996 17:48:19 -0600 Encoding: 28 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 01, 1996 5:37 PM, Louis A. Mamakos[SMTP:louie@UU.NET] wrote: @ @ @ Further, I think there are some good reasons not to have 64 or 128 @ root name servers. You'll make the packet sizes large enough to @ require TCP transport as the UDP responses are too large to be @ returned unfragmented. It was this issue which prompted the @ re-naming of the root name servers into the "ROOT-SERVERS.NET" @ domain, so that the common substring could be omitted by the @ "compression" algorithm used to encode the DNS packets. @ @ I'm guessing that you'd propose to not return the full set, and then @ change the way that the DNS works? @ These are common misconceptions which can be cleared up as you get more involved in the actual nuts and bolts of the DNS and the Internet. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa18493; 1 Nov 96 18:58 EST Received: from sunflower.singnet.com.sg by ietf.org id aa18288; 1 Nov 96 18:57 EST Received: from LOCALNAME (ts900-6009.singnet.com.sg [165.21.162.93]) by sunflower.singnet.com.sg (8.6.12/8.6.9) with SMTP id HAA20054; Sat, 2 Nov 1996 07:56:20 +0800 Date: Sat, 2 Nov 1996 07:56:20 +0800 Message-Id: <199611012356.HAA20054@sunflower.singnet.com.sg> X-Sender: kcheekai@singnet.com.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: daniel@sems.co.jp, ietf@ietf.org Sender:ietf-request@ietf.org From: Koo Chee Kai Subject: Re: Sorry to intrude. Source-Info: From (or Sender) name not authenticated. Try sending a mail to ietf-request@IETF.CNRI.Reston.VA.US with the subject as "unsubscribe" Good luck. At 01:07 PM 10/31/96 -0800, Daniel Minoru Saito wrote: >I hate to protrude into this nice little conversation in regards to `The >cartel begins to crumble...` but if anyone could show me the way out of >this listserver. It isn`t the type of conversation that I was looking >for. > >I tried various times requesting the listserver to UNSUBSCRIBE me but no >luck. > >So I have three options: > >1.) Ask politely on the listserver newsgroup in how to get out. >2.) Be a complete ASSHOLE in my efforts and get kicked out. >3.) Hack into the listserver and then crash the whole listserver at >listproc@wugate.wustl.edu. >   Received: from ietf.org by ietf.org id aa20163; 1 Nov 96 19:14 EST Received: from ng.netgate.net by ietf.org id aa19770; 1 Nov 96 19:11 EST Received: from [205.214.160.111] (d14.netgate.net [205.214.160.46]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA20602; Fri, 1 Nov 1996 16:20:50 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <199611011517.JAA08564@Mercury.mcs.net> References: from "Kim Wohlert" at Nov 1, 96 10:34:46 am Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 1 Nov 1996 15:45:38 -0800 To: Karl Denninger Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: The cartel begins to crumble? Cc: Kim Wohlert , ietf@ietf.org, frezza@interramp.com Source-Info: From (or Sender) name not authenticated. At 7:17 AM -0800 11/1/96, Karl Denninger wrote: >Again, the difference here is that I'm looking for consensus, not ramming >things down people's throats. And I'm not DOING anything; the machine makes >and enforces the rules (which we agree on) :-) Karl, The service/proposal that you outlined in a previous note looks interesting. It's detailed and clear. I don't have an opinion, yet, about its completeness, adequacy or viability but it does have meat on it and is worth some chewing. For starters, I'd like to explore the underlying principles. You stated some of those already but I'd like to make sure I heard things correctly: 1. There IS a central authority. It is a machine that accepts registrations in a strict and mechanical first-come/first-served fashion. 2. Limits would be applied to the number of "new" registrations and organization could get within a window of time, to avoid registration stuffing. 3. Registrations would have to go into service within a window of time or be forfitted. Some questions: 4. How does financial responsibility get evaluated and enforced? Do they have the money to administer a TLD? -- yes I know that the computer operations part can be kept trivial but what about the rest, such as oversight and enforcement? 5. What are the operations requirements for iTLD registries? Are there performance requirements they must meet, at the risk of having the award taken back? 6. How is continuity of support ensured when a registry goes away? If the unthinkable happens and the registry operator for .BIZ disappears then how do we make sure that the unfortunate end users do not have their much relied-upon domain name cease to function? 7. ... I know there are more, basic questions to ask, but this is a good place to stop. Item 1 asserts that all new registrations are acceptable to make under only and exactly this one award policy. That leads to the question of alternate (i.e., multiple) award policies. Is there a basis for believing that the first-come/first-served policy is inadequate in some/all cases? If only for some, how do we distinguish? You say that you want the award service put in place by consensus rather than fiat. Sounds good to me. But that leads to a question about the consensus process. The historical award process was by fiat, in that a single office (IANA) made the specific awards, but it was supported by a (then) broad base of Internet organizations, so there was an important consensus process that caused the "delegation" to the IANA. (For those not familiar with the history, i'd say this summary is technically accurate but misses the flavor. In the old days, none of this stuff was valuable or desired, but it was necessary. I.e., the administrative work was at best distasteful; IANA stepped in to do the work because it needed to be done. It hardly covered anyone in glory. Times change, of course, except for the continued lack of glory...) Anyhow, the world is a different place; the Internet has grown; the breadth of input and participation needs also to grow. We should describe an acceptable consensus process. For starters, I'd like to see a summary of the consensus process that is in place for the mechanism you are describing. This is intended as a dialogue, so I'll stop here and look for responses. d/ ps. Full disclusure: I'm on the newly-formed IAHC. I was named by IANA but have no particular affiliation; i.e., I don't "represent" any particular group other than the pure brainwashing that 25 years of working in the Internet technical community has no doubt accomplished. My explicit agenda is to see that the enhancement to TLD registry administration is achieved well and soon. Period. -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa20166; 1 Nov 96 19:14 EST Received: from ng.netgate.net by ietf.org id aa19857; 1 Nov 96 19:12 EST Received: from [205.214.160.111] (d14.netgate.net [205.214.160.46]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA20718; Fri, 1 Nov 1996 16:21:57 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <9610018468.AA846874750@ncr.disa.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 1 Nov 1996 15:55:21 -0800 To: David Gaon Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re[3]: The cartel begins to crumble? Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 7:52 AM -0800 11/1/96, David Gaon wrote: > I am suggesting that the determination of the ""exact network address of > the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is >left > to the user and is done offline (with respect to the communications > infrastructure). The user, on deciding whom he wants to reach, either > types in the corresponding port number in his e-mail or web access, >or he I believe you are confusing naming with addressing. Machines need names that are separate from their addresses in order to allow the address to change. imc.org changed addresses last week. The only reason this was invisible to the many users who go through it (primarily through the mailing lists it hosts) was because they use the string imc.org rather than a specific IP address. Hence, the late binding of the string to the address is an important aspect to Internet operation. It isn't as simple as doing this "offline"; it needs to be a performant part of the Internet active Internet. Hence, the more ambitious requirements for a directory service, they you suggest, are not appropriate to the task, in my view. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa21113; 1 Nov 96 19:28 EST Received: from cnri by ietf.org id aa20980; 1 Nov 96 19:26 EST Received: from pinky.junction.net by CNRI.Reston.VA.US id aa24566; 1 Nov 96 19:26 EST Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id QAA24231; Fri, 1 Nov 1996 16:39:58 -0800 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id QAA15721; Fri, 1 Nov 1996 16:21:02 -0800 Date: Fri, 1 Nov 1996 16:21:00 -0800 (PST) Sender:ietf-request@ietf.org From: Michael Dillon To: "'Louis A. Mamakos'" cc: "ietf@CNRI.Reston.VA.US" Subject: RE: Folling the crumbling cartel - a note about thread following In-Reply-To: <01BBC81C.DED103A0@webster.unety.net> Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Fri, 1 Nov 1996, Jim Fleming wrote: > @ I'm guessing that you'd propose to not return the full set, and then > @ change the way that the DNS works? > @ > > These are common misconceptions which can be cleared up > as you get more involved in the actual nuts and bolts of the > DNS and the Internet. These kind of insults are commonly used by agents provocateurs in order to goad their opponents into doing or saying something stupid in order to further the vested interests of the agent provocateur. I'm not sure exactly what Fleming is up to here but it is clear that he has an agenda. I believe this agenda is influenced by the CPSR (Computer Professionals for Social Resposibility) and by the anti-authoritarian sentiments that sparked much of the 60's revolutionary attitude. It appears that Fleming believes the IETF and ISOC are a CIS-controlled oligarchy; an old boys club that is attempting to stifle the people of the world in using the greatest communications tool ever created. While the IETF and ISOC are most certainly not lily-white, I don't happen to share Fleming's sinister beliefs. But I think it fair to warn all of you on the IETF list that prolonged and insistent attacks on Fleming will only make him appear heroic to the uninitiated. So, don't lose your cool and reply to him emotionally. Just say enough to correct his errors for the large audience of lurkers and then let him be. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com   Received: from ietf.org by ietf.org id aa22234; 1 Nov 96 19:36 EST Received: from cs.columbia.edu by ietf.org id aa21805; 1 Nov 96 19:34 EST Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.2/8.6.6) with ESMTP id TAA08481 for ; Fri, 1 Nov 1996 19:31:52 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.2/8.6.6) with SMTP id TAA02029 for ; Fri, 1 Nov 1996 19:31:52 -0500 (EST) X-Orig-Sender: hgs@cs.columbia.edu Message-ID: <327A9678.11E2@cs.columbia.edu> Date: Fri, 01 Nov 1996 19:31:52 -0500 Sender:ietf-request@ietf.org From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: The cartel begins to crumble? References: <199611012149.QAA03325@jekyll.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Wouldn't the likely outcome of this be that almost all second-level .com domains would simply become TLDs? Certainly makes life easier for the CompuServe crowd - just type "go ibm"... -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs   Received: from ietf.org by ietf.org id aa22332; 1 Nov 96 19:37 EST Received: from Kitten.mcs.com by ietf.org id aa22101; 1 Nov 96 19:36 EST Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id SAA21229; Fri, 1 Nov 1996 18:35:08 -0600 (CST) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 1 Nov 96 18:34 CST Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.Beta.3) id SAA15592; Fri, 1 Nov 1996 18:34:44 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611020034.SAA15592@Jupiter.Mcs.Net> Subject: Re: The cartel begins to crumble? To: Dave Crocker Date: Fri, 1 Nov 1996 18:34:43 -0600 (CST) Cc: karl@mcs.net, Kim.Wohlert@mainz.dk, ietf@ietf.org, frezza@interramp.com In-Reply-To: from "Dave Crocker" at Nov 1, 96 03:45:38 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > Karl, > >The service/proposal that you outlined in a previous note looks > interesting. It's detailed and clear. I don't have an opinion, yet, about > its completeness, adequacy or viability but it does have meat on it and is > worth some chewing. For starters, I'd like to explore the underlying > principles. You stated some of those already but I'd like to make sure I > heard things correctly: > > 1. There IS a central authority. It is a machine that accepts > registrations in a strict and mechanical first-come/first-served fashion. Correct. > 2. Limits would be applied to the number of "new" registrations and > organization could get within a window of time, to avoid registration > stuffing. Correct. "Registration stuffing" is an interesting phrase; I like it. Basically we're trying to prevent ballot-box-stuffing games and the like; the intent here is that if you want to really run a registry that's fine, but denying someone else the same ability is not. > 3. Registrations would have to go into service within a window of time or > be forfitted. Correct. You don't want to have too long of a period (to prevent stuffing again) nor do you want an organization to be able to reclaim a name they try to get and then forfeit (again, prevention of denial-of-service attack games) > Some questions: > > 4. How does financial responsibility get evaluated and enforced? Do they > have the money to administer a TLD? -- yes I know that the computer > operations part can be kept trivial but what about the rest, such as > oversight and enforcement? I don't know how you CAN do that. And why is it relavent? My argument has been all along that this is a customer <> registry issue. You're not protected *now* if your provider dies, and in fact the disruption that can cause could be, in some cases, severely damaging or even terminal to your business (non-portable addresses made THAT a reality.) But we live with it today, don't we? The non-portable address problem has caused some of our incoming customers REAL headaches. We have had people who just can't change providers BECAUSE we can't route those addresses from 207.x.x.x, and nothing we can do fixes this problem for them. They're screwed, absolutely and completely, and some of them went out and did really crazy things (like embedding some of these addresses into remote devices which are then shipped to offices around the US, etc). Changing providers could be a $100,000+ event for these people. Yet we, as providers, are asked to "accept" this tying arrangement (frankly, I think it stinks -- but that's another thread.) There are people who will only buy computers from IBM. There will be people who won't speculate here either. And they'll likely pay for it. So be it; that's the nature of a free market. If I buy a computer and it breaks, and I bought from Joe's Clones, and he's gone, I eat the hardware in many if not most cases. That's the nature of business risk. As long as people aren't practicing fraud (and if they are, there are laws about this already) I just don't understand the problem here. I believe in full disclosure. Given that, let people do their own evaluations of the risk/reward equation. The solution to ignorance is education. > 5. What are the operations requirements for iTLD registries? Are there > performance requirements they must meet, at the risk of having the award > taken back? I believe it has been agreed-upon that registries should be able to demonstrate multi-homed connectivity. You can meet this requirement in many ways; you can have it yourself, OR one of your servers could be on someone else's network. I believe its also reasonable to require at least DS-1 speeds on external connections to these machines. I don't believe we can reasonably go beyond that. Even today's DNS root servers frequently suck through no fault of the owners (backbone fun and games within some of the nationals cause a good part of it). > 6. How is continuity of support ensured when a registry goes away? If the > unthinkable happens and the registry operator for .BIZ disappears then how > do we make sure that the unfortunate end users do not have their much > relied-upon domain name cease to function? Zones are transferrable. Its easily arguable that this is a self-healing problem to a large extent. A dead registry is going to be a tangible, and valuable, asset (assuming it has registrants in it -- if not the entire discussion is moot and irrelavent). If it has value, it'll be auctioned. In the meantime, how difficult is it for anyone to pull the zone on a somewhat-regular basis and stash it? named-xfer works just fine..... so a simple operational requirement is that you have *someone* who does this on the network *somewhere*, and in the event you disappear the zone can be published on someone else's servers until the status of that asset is determined (see below). Changing the delegations in the root is reasonably trivial in this event. This is basically what I had said in my draft; the contents of the zone file are deemed PD information. REGISTRANT data is another matter; I doubt very much if anyone would approve of their credit-card number being public domain! However, the NS lines are simple and tough to argue as not being public information. In the case of failure and a needed update during the interim, the guy who has the NSs pointed to calls the shots (since he's obviously the one who is actually providing the DNS service for that SLD). >Item 1 asserts that all new registrations are acceptable to make > under only and exactly this one award policy. That leads to the question > of alternate (i.e., multiple) award policies. Is there a basis for > believing that the first-come/first-served policy is inadequate in some/all > cases? If only for some, how do we distinguish? I don't see how it can be. It can be argued that someone will try to grab .IBM (other than IBM corporation, of course). The problem is that as soon as you set up ANYTHING that looks like a tribunal, you're asking for all the problems that NSI has now. You just can't DO that without the consent and delegation from *ALL* the national governments involved. There ARE cases where administrative law is delegated to agencies, but that's US-centric (or some country-centric). Moving the thing to Switzerland doesn't fix this, any more than moving it to Japan or the UAE! Stay the dickens away from the legalities. The cleaner your hands, the less likelihood that someone will sue the people who maintain the mutual-exclusion server operator. If someone REALLY thinks they've been wronged, there are the same solutions available to them that there are for anyone else who believes that the issue is serious enough to go chase the "guilty" party. If you get involved in this then the whole issue of jurisdiction comes into play instantly, differing laws, etc. I believe the only defensible path here is to not play at all. >You say that you want the award service put in place by consensus > rather than fiat. Sounds good to me. But that leads to a question about > the consensus process. The historical award process was by fiat, in that a > single office (IANA) made the specific awards, but it was supported by a > (then) broad base of Internet organizations, so there was an important > consensus process that caused the "delegation" to the IANA. The problem was that at that time it was agreed that the IANA was working in the public trust and no money was changing hands. Its easy to argue for public trusteeship (and consensus) in that event. >Anyhow, the world is a different place; the Internet has grown; the > breadth of input and participation needs also to grow. We should describe > an acceptable consensus process. For starters, I'd like to see a summary > of the consensus process that is in place for the mechanism you are > describing. See above! And let's continue talking; I'm nowhere near out of ideas :-) > ps. Full disclusure: I'm on the newly-formed IAHC. I was named by IANA > but have no particular affiliation; i.e., I don't "represent" any > particular group other than the pure brainwashing that 25 years of working > in the Internet technical community has no doubt accomplished. My explicit > agenda is to see that the enhancement to TLD registry administration is > achieved well and soon. Period. Good. That's an open, and up-front start. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa23234; 1 Nov 96 19:48 EST Received: from cnri by ietf.org id aa23053; 1 Nov 96 19:47 EST Received: from ng.netgate.net by CNRI.Reston.VA.US id aa24937; 1 Nov 96 19:47 EST Received: from [205.214.160.111] (d17.netgate.net [205.214.160.49]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA22845; Fri, 1 Nov 1996 16:56:21 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <01BBC81C.DED103A0@webster.unety.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 1 Nov 1996 16:31:32 -0800 To: Jim Fleming Sender:ietf-request@ietf.org From: Dave Crocker Subject: RE: Folling the crumbling cartel - a note about thread following Cc: "ietf@CNRI.Reston.VA.US" , 'New Newdom' Source-Info: From (or Sender) name not authenticated. At 3:48 PM -0800 11/1/96, Jim Fleming wrote: >These are common misconceptions which can be cleared up >as you get more involved in the actual nuts and bolts of the >DNS and the Internet. Wow. Jim, you are suggesting that things will become clearer to Louis as he becomes more involved in the DNS and the Internet? Forgive me, but Louis has been involved in the direct operation of the Internet for many, many years. Longer than, say, yourself, I suspect. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa23214; 1 Nov 96 19:48 EST Received: from ng.netgate.net by ietf.org id aa23067; 1 Nov 96 19:47 EST Received: from [205.214.160.111] (d17.netgate.net [205.214.160.49]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA22888; Fri, 1 Nov 1996 16:56:29 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <01BBC7E4.B54E5060@webster.unety.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 1 Nov 1996 16:37:02 -0800 To: Jim Fleming Sender:ietf-request@ietf.org From: Dave Crocker Subject: RE: Re[2]: The cartel begins to crumble? Cc: David Gaon , "ietf@ietf.org" Source-Info: From (or Sender) name not authenticated. At 9:06 AM -0800 11/1/96, Jim Fleming wrote: >The DNS "mapping" system is evolving. As noted in my notes >below, there are new features being developed like the SRV >records which may not be "completely deterministic", thus >things like PRIORITY and WEIGHT are being proposed. Jim, et al, The DNS has been 'evolving' ever since its inception. Interestingly, almost none of that evolution has ever succeeded. Many, many enhancements have been proposed. Perhaps the most ambitious was Hessiod as part of Project Athena at MIT, 10 years ago. One can be frustrated by this lack of infrastructure enhancement, or one can be thankful. Frustrated because most of the suggestions over the years have been for obviously and significantly useful features and it's a darn shame we don't have them available. Thankful because the DNS has remained pretty stable... d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa24445; 1 Nov 96 19:57 EST Received: from zephyr.isi.edu by ietf.org id aa24037; 1 Nov 96 19:56 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 1 Nov 1996 16:55:07 -0800 Message-Id: <199611020055.AA27922@zephyr.isi.edu> To: ietf@ietf.org, imr@isi.edu Subject: Internet Monthly Report for July, 1996 Cc: imr-ed@isi.edu Date: Fri, 01 Nov 96 16:55:07 PST Sender:ietf-request@ietf.org From: IMR Editor Source-Info: From (or Sender) name not authenticated. July 1996 INTERNET MONTHLY REPORTS ------------------------ The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the participating organizations. Each organization is expected to submit a 1/2 page report on the first business day of the month describing the previous month's activities. These reports should be submitted via network mail to "IMR@ISI.EDU". ````````````````````````````````````````````````````````````````````` The Internet Monthly Report mailing list is now managed by MajorDomo at ISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be ADDED or DELETED from the Internet Monthly report list should be sent to "majordomo@isi.edu" with the message body either "subscribe imr" or "unsubscribe imr". Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_imrs". For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs or URL: http://www.isi.edu/in-notes/imr/ IMR Editor [Page 1] Internet Monthly Report July 1996 TABLE OF CONTENTS INTERNET ARCHITECTURE BOARD IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3 INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3 Internet Projects INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 11 Registration Services . . . . . . . . . . . . . . . . . page 11 Directory Services. . . . . . . . . . . . . . . . . . . page 13 US Domain Registry. . . . . . . . . . . . . . . . . . . page 13 MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 16 CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 20 TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 24 IMR Editor [Page 2] Internet Monthly Report July 1996 INTERNET ARCHITECTURE BOARD The minutes of the IAB back to 1990 are available for anonymous ftp access on host ftp.isi.edu, directory /pub/IAB, or via the IAB World-Wide Web page with URL http://www.iab.org/iab/. Brian Carpenter IAB Chair INTERNET ENGINEERING REPORTS ---------------------------- IETF Monthly Report for July, 1996 1. The IETF met in Montreal, Quebec, Canada from June 24-28, 1996. While we're still working on the numbers, this was the best attended meeting in the IETF's history with over 1200 registrants. Closing out the year, the IETF will be returning to San Jose, California from December 9-13, 1996. Following that, the IETF travels to Memphis, Tennessee where Federal Express will be the host. This meeting will be held April 7-11, 1997. We are currently working on returning to Europe in August, 1997. Once all the arrangements have been made, notifications will be sent to the IETF Announcement list. Remember that information on future IETF meetings can be always be found in the file 0mtg- sites.txt which is located on the IETF shadow directories. This information can also be viewed from the IETF Home Page on the Web. The URL is: http://www.ietf.org 2. The minutes of the IESG teleconferences have been publicly available on the IETF Shadow directories since 1991. These files are placed in the /ftp/iesg directory. The following IESG minutes have been added: June 13, 1996 (iesg.96-06-13) July 11, 1996 (iesg.96-07-11) 3. The IESG approved or recommended the following 16 Protocol Actions during the month of July, 1996: o Definitions of Managed Objects for IEEE 802.12 Interfaces be published as a Proposed Standard. IMR Editor [Page 3] Internet Monthly Report July 1996 o OSI NSAPs and IPv6 be published as an Experimental Protocol. o The Simple Public-Key GSS-API Mechanism (SPKM) be published as a Proposed Standard. o Uniform Resource Agents (URAs) be published as an Experimental Protocol. o A Method for the Transmission of IPv6 Packets over FDDI Networks be published as a Proposed Standard. o Definitions of Managed Objects for Data Link Switching using SNMPv2 be published as a Proposed Standard. o Support for Multicast over UNI 3.0/3.1 based ATM Networks. be published as a Proposed Standard. o RTP Payload Format of Sun's CellB Video Encoding be published as a Proposed Standard. o RTP Payload Format for JPEG-compressed Video be published as a Proposed Standard. o RTP payload format for H.261 video streams be published as a Proposed Standard. o RTP Payload Format for MPEG1/MPEG2 Video be published as a Proposed Standard. o PPP Stac LZS Compression Protocol be published as an Informational RFC. o TCP Selective Acknowledgment Options be published as a Proposed Standard. o IP Version 6 over PPP be published as a Proposed Standard. o Remote Network Monitoring Management Information Base version 2 be published as a Proposed Standard. o Remote Network Monitoring MIB Protocol Identifiers be published as a Proposed Standard. 4. The IESG issued 21 Last Calls to the IETF during the month of July, 1996: o Interoperation Between DHCP and BOOTP for consideration as a Draft Standard. IMR Editor [Page 4] Internet Monthly Report July 1996 o Clarifications and Extensions for the Bootstrap Protocol for consideration as a Draft Standard. o The PPP SNA Control Protocol (SNACP) for consideration as a Proposed Standard. o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4 for consideration as a Proposed Standard. o INTERNET MESSAGE ACCESS PROTOCOL - OBSOLETE SYNTAX for consideration as an Informational RFC. o IMAP4 COMPATIBILITY WITH IMAP2BIS for consideration as an Informational RFC. o IMAP/POP AUTHorize Extension for Simple Challenge/Response for consideration as a Proposed Standard. o Service Location Protocol for consideration as a Proposed Standard. o TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms for consideration as a Proposed Standard. o Entity MIB for consideration as a Proposed Standard. o SMTP Service Extension for Returning Enhanced Error Codes for consideration as a Proposed Standard. o Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies for consideration as a Draft Standard. o Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types for consideration as a Draft Standard. IMR Editor [Page 5] Internet Monthly Report July 1996 o MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text for consideration as a Draft Standard. o Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures for consideration as a Best Current Practices RFC. o Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples for consideration as a Draft Standard. o A Proposed Extension to HTTP : Digest Access Authentication for consideration as a Proposed Standard. o "Data: URL scheme" for consideration as a Proposed Standard. o The PPP Internetwork Packet Exchange Control Protocol (IPXCP) for consideration as a Draft Standard. o Remote Authentication Dial In User Service (RADIUS) for consideration as a Proposed Standard. o RADIUS Accounting for consideration as an Informational RFC. 5. A total of 99 Internet-Draft actions were taken during the month of July, 1996: (Revised draft (o), New Draft (+) ) (avt) o RTP payload format for H.261 video streams (ion) o NBMA Next Hop Resolution Protocol (NHRP) (pppext) o PPP Stac LZS Compression Protocol (avt) o RTP Payload Format of Sun's CellB Video Encoding (822ext) o Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies IMR Editor [Page 6] Internet Monthly Report July 1996 (avt) o RTP Payload Format for JPEG-compressed Video (mailext) o Common Internet Message Headers (mailext) o The Supersedes and Expires e-mail headers (intserv) o Specification of Guaranteed Quality of Service (pppext) o PPP Extensible Authentication Protocol (EAP) (822ext) o Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (822ext) o Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples (822ext) o Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures (rmonmib) o Remote Network Monitoring Management Information Base version 2 (entmib) o Entity MIB (none) o Common NNTP Extensions (none) o TELNET CHARSET Option (vgmib) o Definitions of Managed Objects for IEEE 802.12 Repeater Devices (atommib) o Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management (radius) o RADIUS Accounting (radius) o Remote Authentication Dial In User Service (RADIUS) (asid) o A MIME Content-Type for Directory Information (none) o Simple Authentication and Session Layer (idmr) o Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (rip) o Protocol Analysis for Triggered RIP (none) o The Model Primary Content Type for Multipurpose Internet Mail Extensions IMR Editor [Page 7] Internet Monthly Report July 1996 (none) o INTERNET REGISTRY IP ALLOCATION GUIDELINES (cat) o Extended Generic Security Service APIs: XGSS-APIs Access control and delegation extensions (rsvp) o RSVP Management Information Base (http) o Hypertext Transfer Protocol -- HTTP/1.1 (intserv) o Intgrated Services Management Information Base (none) + Local Mail Transfer Protocol (none) o IMAP4 QUOTA extension (none) o IMAP4 ACL extension (pppext) o The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) (idmr) o Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol Specification (ids) o X.500 Implementations Catalog-96 (dhc) o Interaction between DHCP and DNS (none) o "Data: URL scheme" (asid) + WHOIS++ URL Specification (idmr) o Distance Vector Multicast Routing Protocol (none) o Server Cache Synchronization Protocol (SCSP) - NBMA (ion) + Multicast Server Architectures for MARS-based ATM multicasting. (none) o IMAP/POP AUTHorize Extension for Simple Challenge/Response (http) o Proposed HTTP State Management Mechanism (rsvp) o RSVP Diagnostic Messages (none) o SMTP Service Extension for Returning Enhanced Error Codes (none) o UTF-8, a transformation format of Unicode and ISO 10646 (none) o Top Level Domain Classification and Catagorization IMR Editor [Page 8] Internet Monthly Report July 1996 (none) o Source directed access control on the Internet. (mhtml) o MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) (ipsec) o HMAC-MD5 IP Authentication with Replay Prevention (ipsec) o HMAC-SHA IP Authentication with Replay Prevention (mhtml) o Sending HTML in E-mail, an informational supplement to RFC ???: MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML) (oncrpc) o RPC: Remote Procedure Call Protocol Specification Version 2 (none) o Payload Format Issues for Redundant Encodings in RTP (none) o YAAP: Yet Another Authentication Protocol (none) o Dialup Roaming Requirements (none) + Proposal for establishing the IETF as an independent organization (none) + Scheduling Wide-area Transport Protocol SWTP (none) o Large Responses to DNS Queries (DNS MORE) (none) + Management Information Base for Frame Relay DTE Extensions for SVC's and Data Compression over Frame Relay (none) + GPS^IP (ion) + Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) (none) + SMTP Service Extension for Command Pipelining (none) + Enhanced Remote Authentication Dial In User Service (RADIUS) Dynamic Filter Change (none) + Enhanced Remote Authentication Dial In User Service (RADIUS) Resource Management Extension (none) + Framework for IP Provider Metrics (find) + The Common Indexing Protocol (CIP) (none) o Adopt MacBinary II Mac File Encoding for FTP Transfers IMR Editor [Page 9] Internet Monthly Report July 1996 (none) o IMAP4 non-synchroniziong literals (none) o IMAP4 OPTIMIZE-1 extension (none) + A Professional Profile for Audio and Video over RTP? (ion) + Multiprotocol Interconnect over Frame Relay (none) + SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over Ethernet (intserv) + Integrated Services Management Information Base Guaranteed Service Extensions (none) + Simple Scheduling Transfer Protocol (none) + A Proposal for an IETF "Problems To Be Solved" Database (none) + MacBinary and Binhex 4.0 considered harmful (none) + Vertical Aggregation: A Strategy for FIB Reduction (none) + Issues affecting MARS Cluster Size (svrloc) + Service Location Modifications for IPv6 (none) + Making Postscript and Acrobat Files International (none) + Compression Payload for Use with IP Security (none) + Internet Calendar Access Protocol (ICAP) (none) + Requirements for IETF Mailing Lists (none) + An Application/Properties Profile for Calendar Information (none) + OnOff Switch Input Object Widget for HTML Forms (none) + A MIME Content-Type for Tagged Property Value Storage (none) + VENUS - Very Extensive Non-Unicast Service (oncrpc) + RPCSEC_GSS Protocol Specification (pppext) + Microsoft Point-To-Point Compression (MPPC) Protocol (none) + A Clarification of SMIv2 IMR Editor [Page 10] Internet Monthly Report July 1996 (none) + A Lexical Specification for the SNMPv2 MIB Module Language (none) + Internet Discussion Forum Protocol (IDFP) (none) + Dedicated Token Ring Interface MIB (none) + Multicast pruning a necessity (none) + Reducing the ISDN costs of Network Applications that use TCP/IP. (none) + Virtual Tunnel Protocol Layer 2 Protocol Extension Steve Coya INTERNET PROJECTS ----------------- INTERNIC -------- REGISTRATION SERVICES The Following report covers the months of July, August, and September: I. Significant Events * HostReg and CReg templates are now being processed automatically; previously they had to be processed manually; now about 50% are being processed automatically. * The auto-registration software now sorts requests into six groups: (1) COM, (2) ORG, (3) NET, (4) GOV, (5) EDU and (6) TLD; this eliminates a manual step in the process and allows the ability to put an increased priority on GOV, EDU and TLD requests. * Plans to initiate a night shift are under development to assist in reducing the manual processing backlog. * Informal training was provided for Billing CSRs regarding how to register as a contact. IMR Editor [Page 11] Internet Monthly Report July 1996 * Selection and training of a second shift for processing support was completed; a full day training class was held on Saturday, September 10th; final staffing arrangements were completed for a night shift with a start date of September 30th. * A "SWAT Team" of existing staff was used to reduce the backlog. * Fax processing has become an overwhelming problem, requiring over four full-time equivalent employees. * Duane Stone and Carley Johnson represented the InterNIC DomReg Section at Network World Interop. * Testing of a share-ware Fax Server solution is going very well; it would make faxes available as e-mail; the fax viewer works very well on Sparc 5s and also supports sending faxes out; the MTS and Ack/Nak interfaces still need to be completed. * DomReg software enhancements have reduced the number of requests that need to be processed manually from about 1,000 to 700 (30% improvement). * A method for gathering performance measurements was finalized and documented. II. Current Status July: Email: 198,486 Postal/Fax: 4,930 Phone: 56,166 Gopher connections: 11,514 retrievals: 39,979 WAIS connections: 57,972 retrievals: 34,246 FTP connections: 61,089 retrievals: 129,768 Mailserv: 4,128 Telnet: 87,392 Http: 3,626,502 Whois client: 576,170 Whois server: 6,183,846 Rich Landers IMR Editor [Page 12] Internet Monthly Report July 1996 INTERNIC DIRECTORY AND DATABASE SERVICES The new Netfind Seed database is up on our machines. In addition, InterNIC Directory and Database Services will become the new home of the netfind-servers mailing list. We have set up a Web page giving starting points for browsing information on the US government. While most of the entries are related to the Federal government, there is also a pointer to some information on state and local governments. A reminder - if you would like to help the Internet community find a resource that you offer, send mail to admin@ds.internic.net and we will send information about listing your resource in the Directory of Directories. If you prefer, you can enter information about your resource in our WWW suggestion form. The form can be reached through our Directory of Directories Web page at: http://ds.internic.net:80/ds/dsdirofdirs.html by Rick Huber THE US DOMAIN REGISTRY ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The US Domain now has an online line registration form. Some of the processing of the requests to the third level domain name is now automated. In particular, most requests to register names in localities already delegated are automatically forwarded to the administrator for that locality. The US Domain administrator no longer makes direct registrations of hosts, and only makes delegations of third or fourth level domain names (such as localities). A new policy has been added to the criteria for delegating domain names under the US Domain: It is the intention that the delegation of third level (for example, locality) domain names be wide spread to many registries. It is undesirable for one person or organization to manage a large part of the third level names in any particular geographic or logical area. IMR Editor [Page 13] Internet Monthly Report July 1996 No individual or organization shall have more than 500 delegations total in the US Domain as a whole, or more than 50 delegation in any particuilar second level (for example, a state). To obtain a copy of the list of other delegated localities and subdomains not administered by the US Domain Registrar, get the file "us-domain-delegated.txt". URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt For further information about the US Domain, send a message to: US-DOMAIN@ISI.EDU, or see our WEB page: http://www.isi.edu/us-domain US DOMAIN ADMINISTRATIVE INFORMATION ------------------------------------ EMAIL/FAX 2899 PHONE 560 ---------------------------- Total Contacts 3459 DELEGATIONS 84 FORWARDED DELEGATIONS:1373 OTHER US DOMAIN MSGS: 2002 --------------------------- Total 3459 OTHER US DOMAIN MESSAGES INCLUDE: referrals to other subdomains or to/from the InterNic, phone calls, modifications, application requests, discussion and clarification of the requests, questions about names, resolving technical problems with zone files and name servers, and whois listings. In addition, and not listed below, another 226 localities have been delegated in Arizona, Arkansas, California, Colorado, Connecticut, Delaware, Hawaii, Massachusetts, Maryland, Missouri, Montana, Michigan Mississippi, North Carolina, New Jersey, New York, Virginia, Vermont, Washington this month. IMR Editor [Page 14] Internet Monthly Report July 1996 MAJOR SUBDOMAINS DELEGATED K12 CC TEC STATE LIB MUS GEN DST COG =================================================================== 51 35 33 47 38 23 23 9 4 =================================================================== ----------------------- THIRD LEVEL DELEGATIONS ----------------------- LOCALITIES ========== DRAPER.UT.US WINCHESTER.KY.US BRYN-ATHYN.PA.US SULLIGENT.AL.US EL-PASO.CO.US SAN-FRANCISCO.CA.US SAN-JOSE.CA.US DERRY.NH.US WHEATON.IL.US BOLTON.MA.US STIGLER.OK.US DEERING.NH.US DOUGLAS.CO.US NEWBURGH.IN.US YELM.WA.US TUMWATER.WA.US THURSTON.WA.US LACEY.WA.US DELHI.OH.US MUSTANG.OK.US RICHMOND-HEIGHTS.MO.US LOS-ANGELES.CA.US SPOKANE.WA.US GUTHRIE.OK.US LANSING.KS.US HUNTINGDON-VALLEY.PA.US BETHAYRES.PA.US OTHER US DOMAIN DELEGATIONS THIS MONTH -------------------------------------- AMHA.SHELBURNE.VT.US SEBAGOLAKEASSC.GEN.ME.US JENKSUSA.K12.OK.US PC2ASSCS.RAYMOND.ME.US CI.PINOLE.CA.US CITY.PEARL.MS.US CI.HARTINGTON.NE.US CI.ROCKY-MOUNT.NC.US GALLIVAN.BOSTON.MA.US LEXTECH.LEXINTON.MA.US CI.CARBONDALE.IL.US CI.PASCO.WA.US NET.BOSTON.MA.US MITRGIRLSCTS.GEN.MI.US GRAM.MUS.MI.US CI.QUINCY.MA.US CHAOS.GEN.CA.US HEALTH.CO.COLUMBIA.NY.US BAPS.K12.OK.US CI.JOHNSBURG.IL.US CI.ELLENSBURG.WA.US CLINTON.I099.K12.OK.US CI.ANTIOCH.CA.US CI.LA-VERNE.CA.US INWAYNET.ATLANTA.GA.US AMERISOFT.SEEKONK.MA.US CALHOUN.CC.AL.US SNUGGLEBUNNY.WAHOO.NE.US IMR Editor [Page 15] Internet Monthly Report July 1996 CI.MARYSVILLE.WA.US RCID.DST.FL.US CO.STOKES.NC.US WWW.CI.WEBSTER.NY.US CI.HOPKINSVILLE.KY.US MCALESTER.K12.OK.US CI.BEDFORD.TX.US TOWN.BEL-AIR.MD.US CO.SCHOHARIE.NY.US CO.GLOUCESTER.NJ.US SPL.LIB.AL.US CI.HUNTERSVILLE.NC.US CI.STAYTON.OR.US CI.LOS-ALTOS.CA.US CI.SIGNAL-HILL.CA.US CO.CALHOUN.MI.US KIB.CO.KODIAK.AK.US JSCC.CC.AL.US CO.BRANCH.MI.US AASR.GEN.MI.US YRC.GEN.MI.US KT.GEN.MI.US RAM.GEN.MI.US CI.SONARA.CA.US THETA.BOSTON.MA.US CI.LONGVIEW.WA.US ----------------------------------------------------------- URL: http://www.isi.edu/us-domain/ Shanthi Ranganathan (US-Domain@ISI.EDU) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MERIT INTERNET ENGINEERING -------------------------- This report summarizes July 1996 activities of Merit's Internet Engineering group on behalf of the Routing Arbiter (RA) service and other projects. The Routing Arbiter project has updated its packet loss and latency measurement code to correct recently discovered measurement biases (see http://www.ra.net/statistics/rs.html). Previously, the packet loss and latency measurements were carried out using the standard Sun ping, which sent five ICMP echo request packets to each of the Route Servers' BGP peers every fifteen minutes. The response time (or lack of response) was logged in a file and later downloaded and processed. Periodically, aberrant measures were seen. For example, there was often packet loss/or and high latency when the machine ping'd its own interface. Packet loss data indicated higher loss and latency results than did other measures. IMR Editor [Page 16] Internet Monthly Report July 1996 Because Merit did not have the source code for the Sun ping, the engineering staff could not perform a detailed analysis to determine the cause of the problem. Staff did find, however, that the Cornell ping, to which they did have source code, did not display the same anomalies and provided much more credible measurements. As a result, a new data collection methodology has been implemented using the Cornell ping as a basis for the measurements. The data from all the Route Servers now shows improved Internet performance in comparison with the previous months' data. To provide data for further study, the primary Route Server at the Washington, D.C. NAP (MAE-East) is running the old and new pings in parallel. Comparing the two sets of results should shed additional light on the source of bias between the two measurement methodologies, and potentially permit an adjustment to deflate the previous measurements. Merit has been exploring options for resolving an important operational problem of the Route Servers, i.e., how to detect whether or not peers of the Route Servers have direct layer-2 reachability to each other. Though this issue was raised at one of the ATM NAPs, it would be problematic for any non-broadcast-media NAP, and is an important issue with respect to the reliability of both routing and the Route Servers. Currently, Merit and the Information Sciences Institute, its partner in the RA project, are evaluating the feasibility of obtaining layer-2 reachability information directly from Route Server peers via ICMP-level queries (traceroute with strict source routing). This is ultimately the source of the desired information and can be initiated by the Route Server without requiring SNMP access coordination and community string dissemination. Merit has implemented an incremental update client for the copies it maintains of the databases in the Internet Routing Registry. This client will poll primary IRR sites for updates on a regular basis (most likely every ten minutes). Currently, these sites only provide updated copies of the registries on a daily basis, so this technology will significantly improve the timeliness of the IRR data provided by RAWhoisd, the whois.ra.net whois server. The incremental update client has been in final test for the last weeks of July and will be deployed in early August. Initially, only the RIPE registry will provide incremental updates. However, we hope that all IRR registries will eventually adopt this technology. IMR Editor [Page 17] Internet Monthly Report July 1996 A new RA tool prototype, known as NetNow, combines a variety of real- time network statistics to provide an easy-to-use, graphical display of ongoing core Internet network conditions. See: http://www.ra.net/tools/ A map of the United States shows the four Network Access Points, and a menu bar lists the major U.S. Internet Service Providers. Names on the map and provider list are color-coded to indicate whether conditions are normal at the NAP or on the provider's backbone, or whether there are problems such as high packet loss or latency, excessive route flapping, unreachable networks, or scheduled maintenance outages. Information about the NAPs is collected by ICMP pings to Route Server peers and SNMP queries to the Route Servers. The ISP backbones are monitored by sending ICMP pings from each NAP across each provider backbone to every other NAP (creating a mesh). In the near future, pings will also be sent across the major ISP backbones to popular end sites. This process will test inter-provider connectivity and provide some statistics on the performance of provider tail circuits. A new software package called "Scion" is being developed by Merit's NetSCARF (Network Statistics Collection And Reporting Facility) project. Scion can be used by ISPs to collect network statistics and automatically display performance reports on the World Wide Web. Version 1.2 of the code is available from: http://www.merit.edu/~netscarf The Scion code, derived from the initial NSFNET project's statistics collection and reporting activities, is easy to install and runs automatically. Every fifteen minutes, Scion's optimized SNMP library queries ISP routers for the values of variables such as sysUpTim and ifLastChange. The library uses SNMP Version 1, and can be configured to use SNMPv2u, the User-based Security model for SNMPv2. Scion's SNMP API is unique, in that it allows the developer to specify a list of nodes, a community string (or userid/authentication password/privacy password in the case of SNMPv2u), and a list of management objects to retrieve. All queries are then transmitted back-to-back, without waiting for any replies. The data collection activity is thus very fast, and the results highly synchronized. Other publicly available SNMP libraries force applications to wait for a response (or timeout) for a given query before the next query can be issued to a different node. IMR Editor [Page 18] Internet Monthly Report July 1996 The raw SNMP statistics are pre-processed each evening, and the processed data delivered to CGI scripts, using what the developers believe to be the first public domain implementation of the OpStats (RFC 1856) client/server model. Finally, ISP performance reports based on the 'cooked' data are displayed on the Web via the CGI scripts. ISPs can use the Scion code to automatically produce HTML graphs showing system uptime, interface uptime, and total network traffic measured in packets. An advanced statistics Web page allows users to specify customized graphing parameters. The source and pre-compiled executables are available for the BSDi and SunOS platforms. Release 2, scheduled for October 1996, will include ports to Windows NT, AIX, and perhaps Solaris and LINUX. A technical overview of the software package has been written by project manager Bill Norton and lead architect Andy Adams, and appears in the July ConneXions (Vol. 10 No. 7). Norton gave a talk about NetSCARF and Scion at the Network Management Area Open Meeting at the Montreal IETF (June '96) and at a network statistics BOF following the May NANOG meeting. A new mailing list, netscarf@merit.edu, is a forum for community discussion and input to the project. Further information is available at the URL above. Susan R. Harris (srh@merit.edu) IMR Editor [Page 19] Internet Monthly Report July 1996 CALENDAR -------- Last update 07/9/96 The information below has been submitted to the IETF Secretariat as a means of notifying readers of future events. Readers are requested to send in dates of events that are appropriate for this calendar section. Please send submissions, corrections, etc., to: Please note: The Secretariat does not maintain on-line information for the events listed below. FYI - The EMail World & Internet World originally scheduled for Sept. 10-12, 1996 has been moved to Oct. 15-17, 1996. Boston, MA. A copy of this calendar is available as follows: VIA FTP - ------- IETF Information is available by anonymous FTP from several sites. US East Coast Address: ds.internic.net (198.49.45.10) US West Coast Address: ftp.isi.edu (128.9.0.32) Europe Address: nic.nordu.net (192.36.148.17) Pacific Rim Address: munnari.oz.au (128.250.1.21) Africa Address: ftp.is.co.za (196.4.160.8) cd ietf ls *0mtg* Gopher - ------- Available on the Gopher Server running on IETF.CNRI.RESTON.VA.US (132.151.1.35) under "Internet Engineering Task Force (IETF) / IETF Meetings / Scheduling Calendar". WWW - ------- Click on the link for "meetings" and you should find an entry "listing of other Internet related events". ************************************************************************ IMR Editor [Page 20] Internet Monthly Report July 1996 1996 - ----------- Oct. 1-3 Email World & Internet Expo Toronto, Ontario, CA Oct. 2-4 Object World Tokyo Tokyo, Japan Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL Oct. 7-11 ATM Forum Montreux, Switzerland Oct. 7-11 NetWorld+Interop Paris, France Oct. 7-11 Performance 96 Conference Lausanne, Switzerland Oct. 9-11 Object World Frankfurt Frankfurt, Germany Oct. 15 Commercenet New Orleans, LA Oct. 15-17 EMail World & Internet Expo Boston, MA Oct. 17-20 IEEE Symposium on Planning & Design of Broadband Networks Quebec, Canada Oct. 21-25 ICECCS'96 (held jointly with 6th CSESAW, 4th IEEE RTAW) Montreal, Canada Oct. 28-31 2nd USENIX Seattle, WA Oct. 28-Nov. 1 NetWorld+Interop London, England Oct. 29-Nov. 1 ICNP-96 Int'l Conf. on Network Protocols Columbus, Ohio Oct. 29-Nov. 1 2nd USENIX Symp. Operating Sys. Design & Implement. (OSIDI II) Seattle, WA Nov. 1996 OMG TC (Groupe Bull) Nice, France Nov. 4-7 APPN Implementers Workshop Raleigh, NC Nov. 4-8 ANSI X3T10 '96 Western Digital Palm Springs, CA Nov. 10-12 2nd annual of ACM's MobiCom '96 Rye, New York Nov. 11-15 IEEE 802 '96 Hotel Vancouver Vancouver, BC Canada Nov. 12-15 3rd Int'l Conf. on Multimedia Modeling Toulouse, France Nov. 13 Commercenet Santa Clara, CA Nov. 18-20 2nd USENIX Workshop on Electronic Commerce Oakland, CA Nov. 18-22 ACM Multimedia '96 Boston, MA Nov. 18-22 IEEE Globecom 96 London, England Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA Nov. 25-29 NetWorld+Interop Sydney, Australia Dec. 2-4 Web World San Diego, CA Dec. 2-6 ANSI X3T11 Rochester, MN Dec. 2-6 ATM Forum Vancover, BC Dec. 4-6 Vir. Reality & VRML World '96 Boston, MA Dec. 9-12 Internet World '96 Baltimore, MD Dec. 9-13 37th IETF San Jose, CA Dec. 9-13 OIW (Firm) Dec. 10-13 Fall Internet World '96 New York, NY Dec. 13 Commercenet Albuquerque, NM IMR Editor [Page 21] Internet Monthly Report July 1996 1997 - ----------- Jan. 6-10 ANSI X3T10 '97 Jan. 6-10 USENIX '97 Annual Technical Conf. Anaheim, CA Jan. 6-10 USELINUX: Linux Appl. Dev. Anaheim, CA Jan. 7-10 13th Annual Hawaii Int'l Conf on Systems Sciences Maui, Hawaii Jan. 28-30 IEEE 802.10 Interim meeting Orlando, FL Feb. 3-7 ANSI X3T11 TBA Feb. 10-11 ISOC Symposium on Network and Distributed System Security San Diego, CA Feb. 17-19 Internet Expo & EMail World San Jose, CA Mar. 1-5 ACM '97: The Next 50 yrs. of Computing San Jose, CA Mar. 10-13 UniForum San Francisco, CA Mar. 10-14 OIW (Firm) Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque Mar. 11-15 ANSI X3T10 '97 Apr. 7-11 38th IETF Memphis, TN Apr. 7-11 ANSI X3T11 TBA Apr. 7-11 IEEE Infocom '97 Kobe, Japan Apr. 9-11 ISADS 97 - 3rd Intl Symposium on Autonmous Decentralized Sys. Berlin, Germany Apr. 22-24 Internet Expo & EMail World Chicago, IL May 5-9 ANSI X3T10 '97 Jun. 8-12 ICC '97 Montreal Jun. 9-13 OIW (Firm) Jun. 9-13 ANSI X3T11 TBA Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI Jul. 14-18 ANSI X3T10 '97 Aug. 11-15 ANSI X3T11 TBA Aug. 11-15 (tenative) 39th IETF Munich, Germany Aug. 12-14 (tenative) Internet Expo & EMail World Boston, MA Sep. 8-12 ANSI X3T10 '97 Sep. 8-12 OIW (Firm) Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France Oct. 6-10 ANSI X3T11 TBA Nov. 3-7 ANSI X3T10 '97 Dec. 8-12 OIW (Firm) TELECOM '97 Asia (Venue and Dates to be Determined) IMR Editor [Page 22] Internet Monthly Report July 1996 1998 - ----------- SPRING 1998 TELECOM '97 Africa Midrand, South Africa Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and Budapest, Hungary 1999 - ----- Oct. 8-14 TELECOM '99 Geneva, Switzerland IMR Editor [Page 23] Internet Monthly Report July 1996 TERENA List of Meetings ======================= This list of meetings is provided for information. Many of the meetings are closed or by invitation; if in doubt, please contact the chair of the meeting or the TERENA Secretariat. If you have additions/corrections/comments, please mail . ********************************************************************** MEETING/DATE LOCATION ============ ======== TERENA General Assembly ----------------------- GA6 24-25 October Bled GA7 15-16 May 1997 Edinburgh TERENA Executive Committee -------------------------- 17 December Amsterdam TERENA Technical Committee -------------------------- 13 November Brussels 22 January 1997 Amsterdam TERENA Office Meeting --------------------- 16 October Amsterdam JENC8 ----- Conference Committee 8 November (provisional) Edinburgh Programme Committee 4 December Amsterdam IMR Editor [Page 24] Internet Monthly Report July 1996 INSIGHT Training Workshop ------- 28-29 October Bled CEEnet ------ 26 October Bled PHARE Research Networking ------ 25 October Bled ----------------------------------------------------------------- ================================================================= EEMA ---- Electronic Commerce '96 Wembley, London 15-17 October Regional Conference 29 November - 1 December Malta Electronic Communications Olympia, London 10-12 December EWOS ---- TA35, 3-4 December Brussels TA36, 25-26 February 1997 " TA37, 13-14 May 1997 " TA38, 16-17 September 1997 " TA39, 2-3 December 1997 " SC - 24 September " SC - 17 December " Workshops 35: 21-25 October Brussels 36: 20-24 January 1997 " 37: 7-11 April 1997 " 38: 16-20 June 1997 " 39: 27-31 October 1997 " IMR Editor [Page 25] Internet Monthly Report July 1996 ETSI ---- Seminar/Workshop 1-3 October Nice, France GA24 10-11 December Nice, France TA25 23-25 October " IETF ---- 9-13 December San Jose, CA 7-11 April 1997 Memphis, Tenn. 11-15 August 1997 Munich, Germany RIPE ---- RIPE26 20-22 January 1997 Amsterdam RIPE27 May 1997 Dublin NATO Workshop ------------- 5-9 May 1997 Edinburgh +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TERENA CONFERENCES ------------------ Call for Papers JENC8 - 8th Joint European Networking Conference ------------------------------------------------ "Diversity and Integration: The New European Networking Landscape" 12-15 May 1997 Edinburgh, Scotland This conference will be the European Forum to get up-to-date information, to debate and assess the new deregulated tele- communication environment in Europe, new leading-edge applications, and the network/internetwork support infrastructure which is currently being developed IMR Editor [Page 26] Internet Monthly Report July 1996 Subject Areas: * Emerging Network Technologies and Network Engineering * User Support, Training and Education * Security and Management Issues * Information Systems and Distributed Applications * Economic and Political Issues Deadline for paper submission 10 November 1996 to: For information please contact the JENC8 Secretariat at: TERENA Secretariat Singel 466-468 1017 AW Amsterdam, The Netherlands tel: +31 20 6391131 fax: +31 20 6393289 email: http://www.terena.nl/jenc8 or JENC8 Local Organization c/o Concorde Services Ltd Unit 5, SECC Glasgow, G3 8YW, Scotland email: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ OTHER CONFERENCES: ----------------- Performance '96 --------------- International Conference on Performance Theory, Measurement and Evaluation of Computer and Communications Systems Organized by IFIPWG7.3 7-11 October Ecole Polytechnique Federal de Lausanne, Lausanne, Switzerland Deadline paper submission 15 March 1996 Further information on WWW Page: http://lrcwww.epfl.ch/perf96/ IMR Editor [Page 27] Internet Monthly Report July 1996 PROMS'96 Third International Workshop on Protocols for Multimedia Systems ---------------------------------------------------------------- 15-18 October Madrid, Spain This workshop is intended to contribute to scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their usage on broadband networks. Papers to be submitted by 7 June. For information contact Arturo Azcorra at 6th CEN/CENELEC/ETSI Conference 1996 -------------------------------- 5-6 November Sheraton Brussels Hotel, Brussels, Belgium Theme of this conference is "Standards on Trial: Case Studies in European Standardization" Deadline for abstracts is 13 Sept. For further information: c/o CENELAC, Tel: +32 2 519 6871 Fax: +32 2 519 6919 IDATE96 18th International Conference of IDATE -------------------------------------- 6-8 November Montpellier, France An opportunity for professional contacts with major industrial group leaders, users and clients, researchers and academics, administrators and politians. Full details of the conference available on the Web: http://www.idate.fr CEN/TC304 - Character Set Technology Workshop --------------------------------------------- 11-12 November Bled, Slovenia Providing multilingual support in middleware: Implementing the Universal Character Set ISO 10646 in the European Information Society For information look up URL: http://www.e5.ijs.si/i18n/ws-bled.html IMR Editor [Page 28] Internet Monthly Report July 1996 "The Telematics Revolution, Consequences for Individuals and Organisations" ---------------------------------------------- 13 November University of Technology, Eindhoven, the Netherlands Theme of the conference is that progress of information and telecommunication technologies do create a huge number of questions, be it social, jurisdictional, economic or technical. Parallel sessions will deal with: interactive scientific visual- isation, tele-learning, user aspects of multimedia, distant consultation and using of laboratories. For all information and to receive brochure, contact Mr. Marc Fleskens at email address IEEE Global Internet 1996 ------------------------- 20-21 November Queen Elizabeth II Conference Centre, London This mini-conference will provide an open forum for the communications and computer networking communities to review the state-of-the-art technologies and applications of the evolving Global Internet. Deadline paper submissions 15 May to: http://gaia.cs.umass.edu:80/tccc/internet96/ or email Jon Crowcroft WEB INTERNATIONALIZATION & MULTILINGUISM SYMPOSIUM -------------------------------------------------- 20-22 November Sevilla, Spain Organized by Sadiel and the WWW Consortium, with the support of the European Commission. The object of this symposium is the advancement of the internationalization and multilingualism of the Web, as well as to seek agreement on the relevant standards. Registration from 15 September. For further information see: http://www.w3.org/pub/WWW/International/Sevilla-96 IMR Editor [Page 29] Internet Monthly Report July 1996 EITC'96 - European IT Conference -------------------------------- 25-27 November Congress Centre, Brussels, Belgium "Doing Business in the Information Society" Electronic commerce, provides the focus for sessions on IT applications, enabling technologies and international initiatives. Post-Conference Workshops to be held on 28 November. For information contact European Commission, DGIII or WWW: http://www.cordis.lu/esprit/src/eitc96.htm ASIAN'96 - Asian Computing Science Conference --------------------------------------------- 2-5 December Singapore Themes of this conference is: - Programming (sematics, languages, systems, ...) - Concurrency & Parallelism (algorithms, formalisms, systems ...) - Networking & Security (algorithms, protocols, formalisms, ...) Additional information available from: http://www.escs.nus.sg/~asian96 Multimedia Computing and Networking 1997 ---------------------------------------- 10-12 February 1997 San Jose, CA, USA The object of this conference is to bring together researchers, developers, and practitioners working in all facets of multimedia computing and networking. Paper submission by 16 July 1996. For further information email COREC -"Interregional Cooperation in RTD - Challenges and Opportunities for Regions in Economic Conversion" --------------------------------------------------------- 16-17 December Bremen, Germany Background is the experience of the community initiative STRIDE and other programmes of the European Commission.The conference will deal questions of RTD-programmes and policies, their European Dimension and impact on regional development. For information contact Mr. Wolfgang Petzold at: email IMR Editor [Page 30] Internet Monthly Report July 1996 IEEE INFOCOM '97 16th Annual Joint Conference of the IEEE Computer & Communications Societies ---------------------------------------- 7-11 April 1997 Kobe, Japan Paper submissions by 14 June 1997. For further information contact http://www.ics.uci.edu/~infocom/ http:// arpeggio.ics.es.osaka-u.ac.jp/infocom.html ISADS 97 3rd International Symposium on Autonomous Decentralized Systems --------------------------------------------------------------- 9-11 April 1997 Berlin, Germany Supported by Hitachi, DeTeBerkom, NEC, Digital, GMD-FOCUS, Hewlett Packard, IBM. The focus will be on advancements and innovations in ADS platforms and applications. Integration of telecommunication and computing aspects into a uniform concept for providing an open distributed processing environment. For information see WWW: http://www.fokus.gmd.de/ws/isads97/ EEMA'97 10th Annual Conference of European Electronic Messaging Association ------------------------------------------------------------------- 16-19 June 1997 Maastricht Exhibition and Congress Centre, Maastricht, Netherlands Issues of the conference will be: Global Security; Corporate Directories; Messaging Products & Services; Electronic Commerce; Global Messaging Enterprise; European Initiatives; Mobile Messaging Technology; Messaging Technology & Management Strategy; Intranet; World Wide Web & Infobots. For information contact WWW: http://www.eema.org/ IMR Editor [Page 31] Internet Monthly Report July 1996 INET'97 The Internet: The Global Frontiers ---------------------------------- 24-27 June 1997 Kuala Lumpur, Malaysia The conference will address the traditional and evolving frontiers of the Internet as well as its significant impact on education, commerce and societies throughout the world. Abstracts of papers to be submitted by 10 October. -for details of submission procedure email -for program information email ==================================================== This meeting list is also available on our WWW page: http://www.terena.nl/news/ ==================================================== IMR Editor [Page 32]   Received: from ietf.org by ietf.org id aa24478; 1 Nov 96 19:58 EST Received: from zephyr.isi.edu by ietf.org id aa23916; 1 Nov 96 19:53 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 1 Nov 1996 16:52:43 -0800 Message-Id: <199611020052.AA27805@zephyr.isi.edu> To: IETF-Announce: ; To: Internet-Monthly-Report-People: ; Subject: Internet Monthly Report for July, 1996 Cc: imr-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Date: Fri, 01 Nov 96 16:52:43 PST Sender:ietf-announce-request@ietf.org From: IMR Editor --NextPart The Internet Monthly Report for July, 1996 is now available at the following location: URL= ftp://ftp.isi.edu/in-notes/imr/imr9607.txt The Internet Monthly Report (IMR) is normally distributed via EMail to the IMR list and the IETF list. For most readers this is the most convenient way to receive the report. However, there are some mail systems or mail gateways that do not accommodate large messages (some issues of the IMR are more than 100,000 characters). Readers that do not receive the IMR via the normal distribution may obtain copies via FTP or EMail retrieval. Requests to be added or deleted from the IMR report list: The Internet Monthly Report list is managed by MajorDomo atISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be added or deleted from the Internet Monthly report list should be sent to majordomo@isi.edu with the message body either subscribe imr or unsubscribe imr. Requests to be added or deleted from the IETF list should be sent to ietf-request@ietf.org. Internet Monthly Report availability via WWW, FTP and EMAIL: IMR Retrieval using WWW ----------------------- The URL below may be used in web browsers to access the IMRs. You will see a list of names in the form IMR9607.TXT. For example, IMR9607.TXT is the report for July 1996. URL: ftp://ftp.isi.edu/in-notes/imr IMR Retrieval using EMAIL via the RFC-INFO Service -------------------------------------------------- The EMail retrieval system RFC-Info will send a large report in segments in separate EMail messages not exceeding 50,000 characters each. Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_imrs. For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs IMR Retrieval using FTP ----------------------- IMRs are available via anonymous FTP from FTP.ISI.EDU, with the pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of the IMR. For example IMR9607.TXT is the report for July 1996). Login with FTP username anonymous and password ftp. IMR retrieval using MIME ------------------------ Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retreive the current IMR. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="rfc-info@isi.edu" Content-Type: text/plain Retrieve: imr Doc-ID: imr9607 --OtherAccess Content-Type: Message/External-body; name="imr9607.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes/imr" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa27459; 1 Nov 96 20:16 EST Received: from zephyr.isi.edu by ietf.org id aa27194; 1 Nov 96 20:14 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 1 Nov 1996 17:13:50 -0800 Message-Id: <199611020113.AA29508@zephyr.isi.edu> To: ietf@ietf.org, imr@isi.edu Subject: Internet Monthly Report for August, 1996 Cc: imr-ed@isi.edu Date: Fri, 01 Nov 96 17:13:50 PST Sender:ietf-request@ietf.org From: IMR Editor Source-Info: From (or Sender) name not authenticated. August 1996 INTERNET MONTHLY REPORTS ------------------------ The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the participating organizations. Each organization is expected to submit a 1/2 page report on the first business day of the month describing the previous month's activities. These reports should be submitted via network mail to "IMR@ISI.EDU". ````````````````````````````````````````````````````````````````````` The Internet Monthly Report mailing list is now managed by MajorDomo at ISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be ADDED or DELETED from the Internet Monthly report list should be sent to "majordomo@isi.edu" with the message body either "subscribe imr" or "unsubscribe imr". Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_imrs". For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs or URL: http://www.isi.edu/in-notes/imr/ IMR Editor [Page 1] Internet Monthly Report August 1996 TABLE OF CONTENTS INTERNET ARCHITECTURE BOARD IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3 INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3 Internet Projects INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 13 Registration Services . . . . . . . . . . . . . . . . . page 13 Directory Services. . . . . . . . . . . . . . . . . . . page 14 US Domain Registry. . . . . . . . . . . . . . . . . . . page 15 MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 19 UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 20 CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 21 TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 25 IMR Editor [Page 2] Internet Monthly Report August 1996 INTERNET ARCHITECTURE BOARD The minutes of the IAB back to 1990 are available for anonymous ftp access on host ftp.isi.edu, directory /pub/IAB, or via the IAB World-Wide Web page with URL http://www.iab.org/iab/. Brian Carpenter IAB Chair INTERNET ENGINEERING REPORTS ---------------------------- IETF Monthly Report for August, 1996 1. The IETF met in Montreal, Quebec, Canada from June 24-28, 1996. It was another record setter as over 1200 attendees registered. Much of this was probably due to the IETF meeting along side INET '96. The IETF returns to San Jose, California on December 9-13, 1996. Our local host will be cisco Systems. The Secretariat will open for registrations the first part of October. The IETF opens 1997 Memphis, Tennessee where Federal Express will be the host. This meeting will be held April 7-11, 1997. Following Memphis, the IETF is we returning to Europe and will met in Munich, Germany August 11-15, 1997, hosted by Digi/ISOC.DE. The Secretariat is still working on the final meeting of 1997. Once all the arrangements have been made, notifications will be sent to the IETF Announcement list. Remember that information on future IETF meetings can be always be found in the file 0mtg- sites.txt which is located on the IETF shadow directories. This information can also be viewed from the IETF Home Page on the Web. The URL is: http://www.ietf.org 2. The minutes of the IESG teleconferences have been publicly available on the IETF Shadow directories since 1991. These files are placed in the /ftp/iesg directory. The following IESG minutes have been added: July 25, 1996 (iesg.96-07-25) August 8, 1996 (iesg.96-08-08) IMR Editor [Page 3] Internet Monthly Report August 1996 3. The IESG approved or recommended the following 26 Protocol Actions during the month of August, 1996: o UTF-8, a transformation format of Unicode and ISO 10646 be published as an Informational RFC. o Observations on the use of Components of the Class A Address Space within the Internet be published as an Informational RFC. o The PPP Internetwork Packet Exchange Control Protocol (IPXCP) be published as a Draft Standard. o Domain Name System Security Extensions be published as a Proposed Standard. o Hypertext Transfer Protocol -- HTTP/1.1 be published as a Proposed Standard. o A Proposed Extension to HTTP : Digest Access Authentication be published as a Proposed Standard. o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 be published as a Proposed Standard. o IMAP4 COMPATIBILITY WITH IMAP2BIS be published as an Informational RFC. o INTERNET MESSAGE ACCESS PROTOCOL - OBSOLETE SYNTAX be published as an Informational RFC. o IMAP4 COMPATIBILITY WITH IMAP2BIS be published as an Informational RFC. oThe PPP SNA Control Protocol (SNACP) be published as a Proposed Standard. o Source directed access control on the Internet be published as an Informational RFC. o Local Mail Transfer Protocol be published as an Informational RFC. o TELNET CHARSET Option be published as an Experimental Protocol. o IP over HIPPI be published as a Draft Standard. o Traffic Flow Measurement: Architecture be published as an Experimental Protocol. IMR Editor [Page 4] Internet Monthly Report August 1996 o Traffic Flow Measurement: Meter MIB be published as an Experimental Protocol. o Service Location Protocol be published as a Proposed Standard. o Entity MIB be published as a Proposed Standard. o SMTP Service Extension for Returning Enhanced Error Codes be published as a Proposed Standard. o Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies be published as a Draft Standard. o Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types be published as a Draft Standard. o MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text be published as a Draft Standard. o Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures be published as a Best Current Practices RFC. o Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples be published as a Draft Standard. o Remote Authentication Dial In User Service (RADIUS) be published as a Proposed Standard. o RADIUS Accounting be published as an Informational RFC. 4. The IESG issued six Last Calls to the IETF during the month of August, 1996: o HTTP State Management Mechanism for consideration as a Proposed Standard. o IMAP4 QUOTA extension for consideration as a Proposed Standard. o IMAP4 non-synchroniziong literals for consideration as a Proposed Standard. IMR Editor [Page 5] Internet Monthly Report August 1996 o IMAP4 ACL extension for consideration as a Proposed Standard. o HMAC-MD5 IP Authentication with Replay Prevention for consideration as a Proposed Standard. o HMAC-SHA IP Authentication with Replay Prevention for consideration as a Proposed Standard. 5. One new Working Group was formed this period. MBONE Deployment (mboned) and one Working Group was concluded: Internet User Glossary (userglos) 6. A total of 117 Internet-Draft actions were taken during the month of August, 1996: (Revised draft (o), New Draft (+) ) (rsvp) o Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification (dnssec) o Domain Name System Security Extensions (none) o Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard (oncrpc) o Authentication Mechanisms for ONC RPC (none) o Group Key Management Protocol (GKMP) Architecture (none) o Group Key Management Protocol (GKMP) Specification (cat) o Generic Security Service Application Program Interface, Version 2 (wts) o The Secure HyperText Transfer Protocol (idr) o A Border Gateway Protocol 4 (BGP-4) (dhc) o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (cat) o Generic Security Service API Version 2 : C-bindings IMR Editor [Page 6] Internet Monthly Report August 1996 (intserv) o Specification of Guaranteed Quality of Service (rip) o RIPng for IPv6 (ion) + IP Broadcast over ATM Networks. (entmib) o Entity MIB (isdnmib) o ISDN Management Information Base (uri) + The Handle System (none) o TELNET CHARSET Option (mixer) o Mapping between X.400 and RFC-822/MIME Message Bodies (none) o Application Level Internet Payment Syntax (html) o Internationalization of the Hypertext Markup Language (ipsec) o Simple Key-Management For Internet Protocols (SKIP) (none) o INTERNET REGISTRY IP ALLOCATION GUIDELINES (madman) o Mail Monitoring MIB (madman) o Network Services Monitoring MIB (mixer) o A MIME body part for FAX (mixer) o A MIME body part for ODA (http) o Hypertext Transfer Protocol -- HTTP/1.1 (http) + HTTP/1.2 EXTENSION PROTOCOL (PEP) (intserv) o Specification of the Controlled-Load Network Element Service (hubmib) o Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) (none) + PEM Compression Encryption Module (ipsec) o Encoding of an Unsigned Diffie-Hellman Public Value (ipsec) o X.509 Encoding of Diffie-Hellman Public Values (ipsec) o SKIP Algorithm Discovery Protocol IMR Editor [Page 7] Internet Monthly Report August 1996 (ipsec) o SKIP Extensions for IP Multicast (mixer) o Carrying PostScript in X.400 and MIME (none) o Extending NAT (none) o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (wts) o Security Extensions For HTML (dhc) o Extensions for DHCPv6 (dnsind) o Selection and Operation of Secondary DNS Servers (ipsec) o SKIP extension for Perfect Forward Secrecy (PFS) (dnssec) o Secure Domain Name System Dynamic Update (dnssec) o Detached Domain Name System Information (none) o VEMMI URL Specification (http) o Transparent Content Negotiation in HTTP (atommib) o Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks (asid) o Lightweight Directory Access Protocol: Standard and Pilot Attribute Definitions (fddimib) o FDDI Management Information Base (asid) o Lightweight Directory Access Protocol (v3) (none) o Tools in the War on Mail Loops (none) o Public Information Retrieval Protocol (PIRP) (none) o Notice-Requested-Upon-Delivery-To (NRUDT) (none) o The qmail-send Bounce Message Format (QSBMF) (none) o Easily Parsed LIST Format (EPLF) (none) o Netstrings (none) o The Hash Convention For Mail System Status Codes (HCMSSC) (atommib) o Definitions of Managed Objects for ATM Management IMR Editor [Page 8] Internet Monthly Report August 1996 (atommib) o Definitions of Managed Objects for the SONET/SDH Interface Type (pier) o Router Renumbering Guide (none) o Source directed access control on the Internet. (mhtml) o MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) (ipsec) o HMAC-MD5 IP Authentication with Replay Prevention (ipsec) o HMAC-SHA IP Authentication with Replay Prevention (mhtml) o Sending HTML in E-mail, an informational supplement to RFC ???: MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML) (none) o New Registries and the Delegation of International Top Level Domains (rtfm) o Traffic Flow Measurement: Experiences with NeTraMet (ids) o Use of DNS Aliases for Network Services (ids) o Finding Stuff (Providing information to support service discovery) (pier) o Network Renumbering Overview: Why would I want it and what is it anyway? (none) o SMTP Extension for Message Submission/Relay (oncrpc) o Binding Protocols for ONC RPC Version 2 (oncrpc) o RPC: Remote Procedure Call Protocol Specification Version 2 (none) o The Public Key Login Protocol (none) o User-Agent Display Attributes (none) o IPv6 Router Alert Option (none) o Resolution of Uniform Resource Identifiers using the Domain Name System (none) o Redundant MARS architectures and SCSP (ion) o Multiprotocol Interconnect over Frame Relay (none) o Reducing the ISDN costs of Network Applications that use TCP/IP. IMR Editor [Page 9] Internet Monthly Report August 1996 (mboned) + Multicast pruning a necessity (none) + S/Ident: Security Extensions for the Ident Protocol (asid) + Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names (asid) + An Approach for Using Domains in LDAP Distinguished Names (ediint) + Requirements for Inter-operable Internet EDI (rip) + RIPng Protocol Applicability Statement (none) + Virtual Tunneling Protocol (VTP) (atommib) + Accounting Information for ATM Networks (fddimib) + FDDI Management Information Base in the SNMPv2 SMI (none) + Interworking Between CDPD and Mobile IP Networks (none) o TCP and UDP over IPv6 Jumbograms (none) + Dedicated Token Ring Concentrator MIB (none) + RTP Payload Format for Bundled MPEG (none) + Quick Mail Transfer Protocol (QMTP) (none) + The Owner Hack (none) o Key words for use in RFCs to Indicate Requirement Levels (intserv) + The Use of RSVP with IETF Integrated Services (mhtml) + Content-ID and Message-ID Uniform Resource Locators (none) + IP Cluster (stdguide) + Guide for Internet Standards Writers (none) + Political Disclosure Transmission Protocol (DISCLOSE) (bmwg) + Benchmarking Terminology for Local Area Switching Devices (none) + Sink-Assisted Routing Protocol (SARP) For General IP Multicasting (none) + SELECTING PAYMENT MECHANISMS OVER HTTP Or, Seven Examples of UPP Over PEP (as used in JEPI) IMR Editor [Page 10] Internet Monthly Report August 1996 (none) o "irc: URL scheme" (none) + New Registries assignment, new iTLD formats and implementation of International Top Level Domains (none) + Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI (none) + Proposed Mechanism for Self-Labeling of Content (dhc) + DHCP Options for Service Location Protocol (none) + Creation of and Registration in the ".NUM" Top Level Domain (none) + Application/Directory Profile for LDAP and X.500 Knowledge (none) + WebNFS Server Specification (none) + The PORT Resource Record (none) + Mobile Network Tracing (none) + Ruby in the Hypertext Markup Language (none) + WebNFS Client Specification 7. There were 30 RFCs published during the month of August, 1996: RFC St WG Title ------- -- -------- ------------------------------------- RFC1888 E (ipngwg) OSI NSAPs and IPv6 RFC1963 I (pppext) PPP Serial Data Transport Protocol (SDTP) RFC1967 I (pppext) PPP LZS-DCP Compression Protocol (LZS-DCP) RFC1970 PS (ipngwg) Neighbor Discovery for IP Version 6 (IPv6) RFC1971 PS (addrconf) IPv6 Stateless Address Autoconfiguration RFC1972 PS (ipngwg) A Method for the Transmission of IPv6 Packets over Ethernet Networks RFC1974 I (pppext) PPP Stac LZS Compression Protocol RFC1975 I (pppext) PPP Magnalink Variable Resource Compression RFC1976 I (pppext) PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) RFC1977 I (pppext) PPP BSD Compression Protocol RFC1978 I (pppext) PPP Predictor Compression Protocol RFC1979 I (pppext) PPP Deflate Protocol RFC1980 I (none) A Proposed Extension to HTML: Client-Side Image Maps IMR Editor [Page 11] Internet Monthly Report August 1996 RFC1981 PS (ipngwg) Path MTU Discovery for IP version 6 RFC1983 I (userglos) Internet Users' Glossary RFC1984 I (none) IAB and IESG Statement on Cryptographic Technology and the Internet RFC1985 PS (none) SMTP Service Extension for Remote Message Queue Starting RFC1986 E (none) Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP) RFC1987 I (none) Ipsilon's General Switch Management Protocol Specification Version 1.1 RFC1988 I (none) Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework RFC1989 DS (pppext) PPP Link Quality Monitoring RFC1990 DS (pppext) The PPP Multilink Protocol (MP) RFC1991 I (none) PGP Message Exchange Formats RFC1992 I (nimrod) The Nimrod Routing Architecture RFC1993 I (pppext) PPP Gandalf FZA Compression Protocol RFC1994 DS (pppext) PPP Challenge Handshake Authentication Protocol (CHAP) RFC1995 PS (dnsind) Incremental Zone Transfer in DNS RFC1996 PS (dnsind) A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) RFC1997 PS (idr) BGP Communities Attribute RFC1998 I (idr) An Application of the BGP Community Attribute in Multi-home Routing St(atus): ( S) Internet Standard (PS) Proposed Standard (DS) Draft Standard ( B) Best Current Practice ( E) Experimental ( I) Informational Steve Coya IMR Editor [Page 12] Internet Monthly Report August 1996 INTERNET PROJECTS ----------------- INTERNIC -------- REGISTRATION SERVICES The following report covers the months of July, August, and September: I. Significant Events * HostReg and CReg templates are now being processed automatically; previously they had to be processed manually; now about 50% are being processed automatically. * The auto-registration software now sorts requests into six groups: (1) COM, (2) ORG, (3) NET, (4) GOV, (5) EDU and (6) TLD; this eliminates a manual step in the process and allows the ability to put an increased priority on GOV, EDU and TLD requests. * Plans to initiate a night shift are under development to assist in reducing the manual processing backlog. * Informal training was provided for Billing CSRs regarding how to register as a contact. * Selection and training of a second shift for processing support was completed; a full day training class was held on Saturday, September 10th; final staffing arrangements were completed for a night shift with a start date of September 30th. * A "SWAT Team" of existing staff was used to reduce the backlog. * Fax processing has become an overwhelming problem, requiring over four full-time equivalent employees. * Duane Stone and Carley Johnson represented the InterNIC DomReg Section at Network World Interop. * Testing of a share-ware Fax Server solution is going very well; it would make faxes available as e-mail; the fax viewer works very well on Sparc 5s and also supports sending faxes out; the MTS and Ack/Nak interfaces still need to be completed. IMR Editor [Page 13] Internet Monthly Report August 1996 * DomReg software enhancements have reduced the number of requests that need to be processed manually from about 1,000 to 700 (30% improvement). * A method for gathering performance measurements was finalized and documented. II. Current Status August: Email: 221,961 Postal/Fax: 2,475 Phone: 33,497 Gopher connections: 9,684 retrievals: 27,815 WAIS connections: 48,124 retrievals: 29,125 FTP connections: 66,003 retrievals: 132,917 Mailserv: 1,338 Telnet: 103,564 Http: 3,742,911 Whois client: 1,245,005 Whois server: 7,275,885 Rich Landers INTERNIC DIRECTORY AND DATABASE SERVICES InterNIC Directory and Database Services is now the "official" source for the Netfind seed database and the Netfind source code. The seed database is updated monthly and is available at: http://ds.internic.net/wp/netfind-seeddb.html The Netfind source code is available at: http://ds.internic.net/wp/netfind-src.html The latest version is 5.0.1. The netfind code comes with version 1.60 beta5 of MIT's pthreads for building pthread support if pthreads are not native. GNU make and gcc (both available from the GNU software FTP archive) are necessary to build MIT's pthreads. Netfind 5.0.1 is not currently backward compatible with SunOS 4.* and lightweight process threads (LWP). For those still wishing to IMR Editor [Page 14] Internet Monthly Report August 1996 provide netfind servers on SunOS platforms, v4.7 of the netfind code has been modified to use the new seed database. The modified version 4.7 is also available from the above web page. A reminder - if you would like to help the Internet community find a resource that you offer, send mail to admin@ds.internic.net and we will send information about listing your resource in the Directory of Directories. If you prefer, you can enter information about your resource in our WWW suggestion form. The form can be reached through our Directory of Directories Web page at: http://ds.internic.net:80/ds/dsdirofdirs.html by Rick Huber THE US DOMAIN REGISTRY ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The US Domain now has an online line registration form. Some of the processing of the requests to the third level domain name is now automated. In particular, most requests to register names in localities already delegated are automatically forwarded to the administrator for that locality. The US Domain administrator no longer makes direct registrations of hosts, and only makes delegations of third or fourth level domain names (such as localities). A new policy has been added to the criteria for delegating domain names under the US Domain: It is the intention that the delegation of third level (for example, locality) domain names be wide spread to many registries. It is undesirable for one person or organization to manage a large part of the third level names in any particular geographic or logical area. No individual or organization shall have more than 500 delegations total in the US Domain as a whole, or more than 50 delegation in any particuilar second level (for example, a state). About the special domains under the state codes. The K12, CC, TEC, LIB, STATE, DST, COG and GEN domain under each state are established for special purposes (see RFC 1480). IMR Editor [Page 15] Internet Monthly Report August 1996 In addition to the constaint to use them only for the defined purpose, each of these special domains is also to delegated only to a manager within the state, and the operation of the delegated registry should be non-profit. The LIB domain should be managed by a govermental or educational library organization. Further, it is most appropriate for the K12, CC, and TEC, domains to be managed by an educational organization (for example, a university or a department of education). The STATE domain is most appropriately managed by an agency of the state government. DST and COG should be managed by a goverment agency. The GEN domain may be delegated to any organization that will provide the registration service for free (and remember the purpose of the GEN domain is to register statewide non-profit organizations). To obtain a copy of the list of other delegated localities and subdomains not administered by the US Domain Registrar, get the file "us-domain-delegated.txt". URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt For further information about the US Domain, send a message to: US-DOMAIN@ISI.EDU, or see our WEB page: http://www.isi.edu/us-domain US DOMAIN ADMINISTRATIVE INFORMATION ------------------------------------ EMAIL/FAX 2975 PHONE 525 ---------------------------- Total Contacts 3500 DELEGATIONS 122 FORWARDED DELEGATIONS:1014 OTHER US DOMAIN MSGS: 2364 --------------------------- Total 3500 IMR Editor [Page 16] Internet Monthly Report August 1996 OTHER US DOMAIN MESSAGES INCLUDE: referrals to other subdomains or to/from the InterNic, phone calls, modifications, application requests, discussion and clarification of the requests, questions about names, resolving technical problems with zone files and name servers, and whois listings. In addition, and not listed below, another 315 localities have been delegated in Arizona, Arkansas, California, Colorado, Connecticut, Massachusetts, Maryland, Missouri, Montana, Michigan , Mississippi, North Carolina, New Jersey, New York, Virginia, Vermont, this month. MAJOR SUBDOMAINS DELEGATED K12 CC TEC STATE LIB MUS GEN DST COG =================================================================== 51 35 33 47 38 23 23 9 4 =================================================================== ----------------------- THIRD LEVEL DELEGATIONS ----------------------- LOCALITIES ========== CLOVERDALE.IN.US MARINETTE.WI.US CAPE-FEAR.NC.US PARK-RIDGE.IL.US PENDLETON.OR.US PURGATORY.CO.US STOW.OH.US KEWAUNEE.WI.US OAK-LAWN.IL.US COLORADO-CITY.AZ.US MOHAVE-VALLEY.AZ.US SHERIDAN.IN.US PICAYUNE.MS.US CLARK.KY.US MANCHESTER.MO.US CLEARLAKE.CA.US PICO-RIVERA.CA.US DOWNEY.CA.US PINE-BLUFF.AR.US MONTICELLO.AR.US STAFFORD.VA.US NOVATO.CA.US GOLDEN.CO.US PAWHUSKA.OK.US URBANA.IL.US ELIZEBETH-CITY.NC.US FAYETTEVILLE.AR.US COLUMBUS.IN.US HAZEN.AR.US DES-ARC.AR.US CARLISLE.AR.US BEEBE.AR.US TROUTDALE.OR.US ASHLEY-FALLS.MA.US HYANNIS-PORT.MA.US EDGARTOWN.MA.US SOUTH-EGREMONT.MA.US LANESBORO.MA.US NEW-BERN.NC.US LINDSAY.CA.US IMR Editor [Page 17] Internet Monthly Report August 1996 OFALLON.MO.US ELDON.MO.US FARMINGTON.MO.US SIKESTON.MO.US WEST-LOS-ANGELES.CA.US WLA.CA.US GREENCASTLE.IN.US COUNCIL-BLUFFS.IA.US BEAVER-DAM.WI.US BOSTON.MA.US OTHER US DOMAIN DELEGATIONS THIS MONTH -------------------------------------- CI.SPRINGBORO.OH.US CI.OGALLALA.NE.US CI.COLUMBUS.NE.US CI.TOMAHAWK.WI.US CI.MERRILL.WI.US CO.LINCOLN.WI.US CO.CHATHAM.NC.US CI.WESTMINSTER.MD.US CI.GARLAND.TX.US CI.FOUNTAIN-HILLS.AZ.US CI.MUSKEGO.WI.US CO.WAYNE.MI.US CO.WAYNE.NY.US CI.MCMINNVILLE.OR.US CI.SHOW-LOW.AZ.US CO.JACKSON.OR.US CI.GREENVILLE.NC.US CI.FORTUNA.CA.US CI.FOUNTAIN-VALLEY.CA.US CI.DALY-CITY.CA.US TWP.BURLINGTON.NJ.US CO.LINCOLN.NC.US CI.ST-JOSEPH.MO.US CO.EATON.MI.US CI.TAUNTON.MA.US CI.MARION.IN.US CO.DELAWARE.NY.US CI.WASHINGTON.PA.US KUWAIT.INFO.NW.DC.US CORONER.CO.FRANKLIN.OH.US CHESAPEAKE.LIB.VA.US ABE.APALACHIN.NY.US WIDOMAKER.WILLIAMSBURG.VA.US TMOK.GEN.RI.US CUG.COLUMBIA.IL.US QZ.LITTLE-NECK.NY.US BEIGE.AFFTON.MO.US PALMER.LIB.MA.US HCSOT.TEC.NJ.US BHSALUM.BELLEFONTAINE.OH.US LIVERMORE.LIB.CA.US MPWMD.DST.CA.US WFRPC.DST.FL.US 43RD.CI.CHICAGO.IL.US GREECEFEST.GREECE.NY.US HEALTH.CO.CHENANGO.NY.US BPC.COLUMBIA.IL.US STERLINGCOLLEGE.CRAFTSBURY.VT.US TOWNSHIP.ORION.MI.US LAMAN.LIB.AR.US SHERRIF.CO.PULASKI.AR.US IASI.TEC.AL.US WWCC.CC.WY.US NOCK.WASHINGTON.DC.US MARC.WASHINGTON.DC.US MBEVILL.CC.AL.US HEALTH.CO.ONONDAGA.NY.US STA.DST.CA.US CRRL.LIB.VA.US ACID.WATERLOO.IL.US WWW.CHICAGO.IL.US INFO.CHICAGO.IL.US IMR Editor [Page 18] Internet Monthly Report August 1996 METRO.CHICAGO.IL.US BLUERIDGESCHOOL.DYKE.VA.US KTI.BIRMINGHAM.MI.US COLUMBUS.MARSHFIELD.WI.US GEORGETOWN.NW.DC.US GEORGETOWN.WASHINGTON.DC.US MARC.NW.DC.US WMR-SCCA.GEN.MI.US GRMUSEUM.MUS.MI.US SCHULTE.JEFFERSONTOWN.KY.US ----------------------------------------------------------- URL: http://www.isi.edu/us-domain/ Shanthi Ranganathan (US-Domain@ISI.EDU) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MERIT INTERNET ENGINEERING -------------------------- This report summarizes August 1996 activities of Merit's Internet Engineering group on behalf of the Routing Arbiter (RA) service and other projects. An incremental update client has recently been implemented for the Routing Arbiter Database by Jerry Winters of the RADB staff. The new client polls the RIPE registry's mirroring site every 30 minutes for database updates; previously, updates were only provided once each day. The technology thus significantly improves the timeliness of the Internet Routing Registry (IRR) data provided by RAWhoisd, the whois.ra.net whois server. Winters has been testing a server that will allow Merit to support its own database mirroring site, much like RIPE's. This would mean that other IRR organizations, such as MCI, CA*net, and RIPE, could update their database copies with new RADB data as frequently as every five minutes, rather than every 24 hours. The Merit mirroring site would also support a hot backup system for the production RADB database system. As part of Merit's ongoing research on routing technologies and protocols, IPv6 routing support has been added to the Multi- Threaded Routing Toolkit (MRT). The development work is being carried out by Masaki Hirabaru, an Associate Professor of Information Science at Japan's Nara Institute of Science and Technology, who is working at Merit for part of the 1996 academic year. Hirabaru is developing a wide-area IPv6 testing environment for MRT using the 6bone, a virtual network that links sites in North America, Europe, and Japan. The 6bone is layered on top of portions of the physical, IPv4-based Internet to support routing of IPv6 packets, as that function has not yet been integrated into IMR Editor [Page 19] Internet Monthly Report August 1996 many production routers. The 6bone comprises islands of IPv6 hosts connected by virtual point-to-point links, called tunnels. The tunnel endpoints are typically workstation-class machines with operating system support for IPv6. Support for RIPng and the IPv6 policy language has also been implemented in MRT, including implementation of IPv6 access-lists and router descriptions. In addition, Hirabaru and MRT developer Craig Labovitz have been working with IPv6 operating system development groups to fix several bugs in the IPv6 kernel software. Susan R. Harris (srh@merit.edu) UCL ---- Mark Handley and Jon Crowcroft attended SIGCOMM 96 and ran a tworkshop day on future multicast research problems (see http://www.cs.ucl.ac.uk/staff/jon/sigbone.html for further information) John Crowcroft (j.crowcroft@CS.UCL.AC.UK) IMR Editor [Page 20] Internet Monthly Report August 1996 CALENDAR -------- Last update 07/9/96 The information below has been submitted to the IETF Secretariat as a means of notifying readers of future events. Readers are requested to send in dates of events that are appropriate for this calendar section. Please send submissions, corrections, etc., to: Please note: The Secretariat does not maintain on-line information for the events listed below. FYI - The EMail World & Internet World originally scheduled for Sept. 10-12, 1996 has been moved to Oct. 15-17, 1996. Boston, MA. A copy of this calendar is available as follows: VIA FTP - ------- IETF Information is available by anonymous FTP from several sites. US East Coast Address: ds.internic.net (198.49.45.10) US West Coast Address: ftp.isi.edu (128.9.0.32) Europe Address: nic.nordu.net (192.36.148.17) Pacific Rim Address: munnari.oz.au (128.250.1.21) Africa Address: ftp.is.co.za (196.4.160.8) cd ietf ls *0mtg* Gopher - ------- Available on the Gopher Server running on IETF.CNRI.RESTON.VA.US (132.151.1.35) under "Internet Engineering Task Force (IETF) / IETF Meetings / Scheduling Calendar". WWW - ------- Click on the link for "meetings" and you should find an entry "listing of other Internet related events". ************************************************************************ IMR Editor [Page 21] Internet Monthly Report August 1996 1996 - ----------- Oct. 1-3 Email World & Internet Expo Toronto, Ontario, CA Oct. 2-4 Object World Tokyo Tokyo, Japan Oct. 6-9 Asia Pacific Distributed Solutions Event Queensland, Australia Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL Oct. 7-11 ATM Forum Montreux, Switzerland Oct. 7-11 NetWorld+Interop Paris, France Oct. 7-11 Performance 96 Conference Lausanne, Switzerland Oct. 9-11 Object World Frankfurt Frankfurt, Germany Oct. 13-16 IEEE Local Computer Ntwrks (LCN) Minneapolis, MN Oct. 14-17 MEDNET '96 European Congress of the Internet in Medicine Brighton, UK Oct. 15 Commercenet New Orleans, LA Oct. 15-17 EMail World & Internet Expo Boston, MA Oct. 15-18 3rd Int'l on Protocols for Multimedia Systems Madrid, Spain Oct. 16-18 Internet World Monterrey '96 Monterrey, Mexico Oct. 16-19 5th Int'l Conference on Computer Communications & Ntwrks Rockville, MD Oct. 17-20 IEEE Symposium on Planning & Design of Broadband Networks Quebec, Canada Oct. 21-25 ICECCS'96 (held jointly with 6th CSESAW, 4th IEEE RTAW) Montreal, Canada Oct. 28-31 2nd USENIX Seattle, WA Oct. 28-Nov. 1 NetWorld+Interop London, England Oct. 29-31 Internet Professional '96 Paris, France Oct. 29-Nov. 1 ICNP-96 Int'l Conf. on Network Protocols Columbus, Ohio Oct. 29-Nov. 1 2nd USENIX Symp. Operating Sys. Design & Implement. (OSIDI II) Seattle, WA Nov. 1996 OMG TC (Groupe Bull) Nice, France Nov. 4-7 APPN Implementers Workshop Raleigh, NC Nov. 4-8 ANSI X3T10 '96 Western Digital Palm Springs, CA Nov. 6-8 Web Developer Mexico '96 Mexico Ciy, Mexico Nov. 10-12 2nd annual of ACM's MobiCom '96 Rye, New York Nov. 11-15 IEEE 802 '96 Hotel Vancouver Vancouver, BC Canada Nov. 12-15 3rd Int'l Conf. on Multimedia Modeling Toulouse, France Nov. 13 Commercenet Santa Clara, CA Nov. 18-20 2nd USENIX Workshop on Electronic Commerce Oakland, CA Nov. 18-22 ACM Multimedia '96 Boston, MA Nov. 18-22 IEEE Globecom 96 London, England Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA Nov. 20-21 IEEE Global Internet '96 London, UK Nov. 25-29 NetWorld+Interop Sydney, Australia IMR Editor [Page 22] Internet Monthly Report August 1996 Dec. 2-4 Web World San Diego, CA Dec. 2-6 ANSI X3T11 Rochester, MN Dec. 2-6 ATM Forum Vancover, BC Dec. 4-6 Vir. Reality & VRML World '96 Boston, MA Dec. 9-12 Internet World '96 Baltimore, MD Dec. 9-13 37th IETF San Jose, CA Dec. 9-13 OIW (Firm) Dec. 10-13 Fall Internet World '96 New York, NY Dec. 12 Internet Security for System & Network Administrators Pittsburgh, PA Dec. 13 Commercenet Albuquerque, NM 1997 - ----------- Jan. 6-10 ANSI X3T10 '97 Jan. 6-10 USENIX '97 Annual Technical Conf. Anaheim, CA Jan. 6-10 USELINUX: Linux Appl. Dev. Anaheim, CA Jan. 7-10 13th Annual Hawaii Int'l Conf on Systems Sciences Maui, Hawaii Jan. 7-10 Internet World Canada '97 Toronto, Canada Jan. 21-23 Internet World Shanghai-China Shanghai, China Jan. 21-25 Internet World Singapore Intl Singapore Jan. 28-30 IEEE 802.10 Interim meeting Orlando, FL Feb. 3-7 ANSI X3T11 TBA Feb. 10-11 ISOC Symposium on Network and Distributed System Security San Diego, CA Feb. 17-19 Internet Expo & EMail World San Jose, CA Mar. 1-5 ACM '97: The Next 50 yrs. of Computing San Jose, CA Mar. 10-13 UniForum San Francisco, CA Mar. 10-14 OIW (Firm) Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque Mar. 11-14 Spring Internet World '97 Los Angeles, CA Mar. 11-15 ANSI X3T10 '97 Mar. 17-19 1st Euromicro Working Conf. on Software Maintenance & Reengineering Berlin, Germany Mar. 19-21 Internet World Asia '97 Kuala Lumpur, Malaysia Apr. 7-11 38th IETF Memphis, TN Apr. 7-11 ANSI X3T11 TBA Apr. 7-11 IEEE Infocom '97 Kobe, Japan Apr. 9-11 ISADS 97 - 3rd Intl Symposium on Autonmous Decentralized Sys. Berlin, Germany Apr. 22-24 Internet Expo & EMail World Chicago, IL May 5-9 ANSI X3T10 '97 May 12-16 IFIP/IEEE San Diego, CA May 28-30 Web Developer '97 Chicago, IL IMR Editor [Page 23] Internet Monthly Report August 1996 Jun. 3-5 Internet World Mexico '97 Mexico City, Mexico Jun. 8-12 ICC '97 Montreal Jun. 9-13 OIW (Firm) Jun. 9-13 ANSI X3T11 TBA Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI Jul. 14-18 ANSI X3T10 '97 Aug. 11-15 ANSI X3T11 TBA Aug. 11-15 (tenative) 39th IETF Munich, Germany Aug. 12-14 (tenative) Internet Expo & EMail World Boston, MA Sep. 8-12 ANSI X3T10 '97 Sep. 8-12 OIW (Firm) Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France Oct. 6-10 ANSI X3T11 TBA Nov. 3-7 ANSI X3T10 '97 Dec. 8-12 OIW (Firm) TELECOM '97 Asia (Venue and Dates to be Determined) 1998 - ----------- SPRING 1998 TELECOM '97 Africa Midrand, South Africa Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and Budapest, Hungary 1999 - ----- Oct. 8-14 TELECOM '99 Geneva, Switzerland IMR Editor [Page 24] Internet Monthly Report August 1996 TERENA List of Meetings ======================= This list of meetings is provided for information. Many of the meetings are closed or by invitation; if in doubt, please contact the chair of the meeting or the TERENA Secretariat. If you have additions/corrections/comments, please mail . ********************************************************************** MEETING/DATE LOCATION ============ ======== TERENA General Assembly ----------------------- GA6 24-25 October Bled GA7 15-16 May 1997 Edinburgh TERENA Executive Committee -------------------------- 17 December Amsterdam TERENA Technical Committee -------------------------- 13 November Brussels 22 January 1997 Amsterdam TERENA Office Meeting --------------------- 16 October Amsterdam JENC8 ----- Conference Committee 8 November (provisional) Edinburgh Programme Committee 4 December Amsterdam IMR Editor [Page 25] Internet Monthly Report August 1996 INSIGHT Training Workshop ------- 28-29 October Bled CEEnet ------ 26 October Bled PHARE Research Networking ------ 25 October Bled ----------------------------------------------------------------- ================================================================= EEMA ---- Electronic Commerce '96 Wembley, London 15-17 October Regional Conference 29 November - 1 December Malta Electronic Communications Olympia, London 10-12 December EWOS ---- TA35, 3-4 December Brussels TA36, 25-26 February 1997 " TA37, 13-14 May 1997 " TA38, 16-17 September 1997 " TA39, 2-3 December 1997 " SC - 24 September " SC - 17 December " Workshops 35: 21-25 October Brussels 36: 20-24 January 1997 " 37: 7-11 April 1997 " 38: 16-20 June 1997 " 39: 27-31 October 1997 " IMR Editor [Page 26] Internet Monthly Report August 1996 ETSI ---- Seminar/Workshop 1-3 October Nice, France GA24 10-11 December Nice, France TA25 23-25 October " IETF ---- 9-13 December San Jose, CA 7-11 April 1997 Memphis, Tenn. 11-15 August 1997 Munich, Germany RIPE ---- RIPE26 20-22 January 1997 Amsterdam RIPE27 May 1997 Dublin NATO Workshop ------------- 5-9 May 1997 Edinburgh +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TERENA CONFERENCES ------------------ Call for Papers JENC8 - 8th Joint European Networking Conference ------------------------------------------------ "Diversity and Integration: The New European Networking Landscape" 12-15 May 1997 Edinburgh, Scotland This conference will be the European Forum to get up-to-date information, to debate and assess the new deregulated tele- communication environment in Europe, new leading-edge applications, and the network/internetwork support infrastructure which is currently being developed IMR Editor [Page 27] Internet Monthly Report August 1996 Subject Areas: * Emerging Network Technologies and Network Engineering * User Support, Training and Education * Security and Management Issues * Information Systems and Distributed Applications * Economic and Political Issues Deadline for paper submission 10 November 1996 to: For information please contact the JENC8 Secretariat at: TERENA Secretariat Singel 466-468 1017 AW Amsterdam, The Netherlands tel: +31 20 6391131 fax: +31 20 6393289 email: http://www.terena.nl/jenc8 or JENC8 Local Organization c/o Concorde Services Ltd Unit 5, SECC Glasgow, G3 8YW, Scotland email: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ OTHER CONFERENCES: ----------------- Performance '96 --------------- International Conference on Performance Theory, Measurement and Evaluation of Computer and Communications Systems Organized by IFIPWG7.3 7-11 October Ecole Polytechnique Federal de Lausanne, Lausanne, Switzerland Deadline paper submission 15 March 1996 Further information on WWW Page: http://lrcwww.epfl.ch/perf96/ IMR Editor [Page 28] Internet Monthly Report August 1996 PROMS'96 Third International Workshop on Protocols for Multimedia Systems ---------------------------------------------------------------- 15-18 October Madrid, Spain This workshop is intended to contribute to scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their usage on broadband networks. Papers to be submitted by 7 June. For information contact Arturo Azcorra at 6th CEN/CENELEC/ETSI Conference 1996 -------------------------------- 5-6 November Sheraton Brussels Hotel, Brussels, Belgium Theme of this conference is "Standards on Trial: Case Studies in European Standardization" Deadline for abstracts is 13 Sept. For further information: c/o CENELAC, Tel: +32 2 519 6871 Fax: +32 2 519 6919 IDATE96 18th International Conference of IDATE -------------------------------------- 6-8 November Montpellier, France An opportunity for professional contacts with major industrial group leaders, users and clients, researchers and academics, administrators and politians. Full details of the conference available on the Web: http://www.idate.fr CEN/TC304 - Character Set Technology Workshop --------------------------------------------- 11-12 November Bled, Slovenia Providing multilingual support in middleware: Implementing the Universal Character Set ISO 10646 in the European Information Society For information look up URL: http://www.e5.ijs.si/i18n/ws-bled.html IMR Editor [Page 29] Internet Monthly Report August 1996 "The Telematics Revolution, Consequences for Individuals and Organisations" ---------------------------------------------- 13 November University of Technology, Eindhoven, the Netherlands Theme of the conference is that progress of information and telecommunication technologies do create a huge number of questions, be it social, jurisdictional, economic or technical. Parallel sessions will deal with: interactive scientific visual- isation, tele-learning, user aspects of multimedia, distant consultation and using of laboratories. For all information and to receive brochure, contact Mr. Marc Fleskens at email address IEEE Global Internet 1996 ------------------------- 20-21 November Queen Elizabeth II Conference Centre, London This mini-conference will provide an open forum for the communications and computer networking communities to review the state-of-the-art technologies and applications of the evolving Global Internet. Deadline paper submissions 15 May to: http://gaia.cs.umass.edu:80/tccc/internet96/ or email Jon Crowcroft WEB INTERNATIONALIZATION & MULTILINGUISM SYMPOSIUM -------------------------------------------------- 20-22 November Sevilla, Spain Organized by Sadiel and the WWW Consortium, with the support of the European Commission. The object of this symposium is the advancement of the internationalization and multilingualism of the Web, as well as to seek agreement on the relevant standards. Registration from 15 September. For further information see: http://www.w3.org/pub/WWW/International/Sevilla-96 IMR Editor [Page 30] Internet Monthly Report August 1996 EITC'96 - European IT Conference -------------------------------- 25-27 November Congress Centre, Brussels, Belgium "Doing Business in the Information Society" Electronic commerce, provides the focus for sessions on IT applications, enabling technologies and international initiatives. Post-Conference Workshops to be held on 28 November. For information contact European Commission, DGIII or WWW: http://www.cordis.lu/esprit/src/eitc96.htm ASIAN'96 - Asian Computing Science Conference --------------------------------------------- 2-5 December Singapore Themes of this conference is: - Programming (sematics, languages, systems, ...) - Concurrency & Parallelism (algorithms, formalisms, systems ...) - Networking & Security (algorithms, protocols, formalisms, ...) Additional information available from: http://www.escs.nus.sg/~asian96 Multimedia Computing and Networking 1997 ---------------------------------------- 10-12 February 1997 San Jose, CA, USA The object of this conference is to bring together researchers, developers, and practitioners working in all facets of multimedia computing and networking. Paper submission by 16 July 1996. For further information email COREC -"Interregional Cooperation in RTD - Challenges and Opportunities for Regions in Economic Conversion" --------------------------------------------------------- 16-17 December Bremen, Germany Background is the experience of the community initiative STRIDE and other programmes of the European Commission.The conference will deal questions of RTD-programmes and policies, their European Dimension and impact on regional development. For information contact Mr. Wolfgang Petzold at: email IMR Editor [Page 31] Internet Monthly Report August 1996 IEEE INFOCOM '97 16th Annual Joint Conference of the IEEE Computer & Communications Societies ---------------------------------------------------------------------------- 7-11 April 1997 Kobe, Japan Paper submissions by 14 June 1997. For further information contact http://www.ics.uci.edu/~infocom/ http:// arpeggio.ics.es.osaka-u.ac.jp/infocom.html ISADS 97 3rd International Symposium on Autonomous Decentralized Systems --------------------------------------------------------------- 9-11 April 1997 Berlin, Germany Supported by Hitachi, DeTeBerkom, NEC, Digital, GMD-FOCUS, Hewlett Packard, IBM. The focus will be on advancements and innovations in ADS platforms and applications. Integration of telecommunication and computing aspects into a uniform concept for providing an open distributed processing environment. For information see WWW: http://www.fokus.gmd.de/ws/isads97/ EEMA'97 10th Annual Conference of European Electronic Messaging Association ------------------------------------------------------------------- 16-19 June 1997 Maastricht Exhibition and Congress Centre, Maastricht, Netherlands Issues of the conference will be: Global Security; Corporate Directories; Messaging Products & Services; Electronic Commerce; Global Messaging Enterprise; European Initiatives; Mobile Messaging Technology; Messaging Technology & Management Strategy; Intranet; World Wide Web & Infobots. For information contact WWW: http://www.eema.org/ IMR Editor [Page 32] Internet Monthly Report August 1996 INET'97 The Internet: The Global Frontiers ---------------------------------- 24-27 June 1997 Kuala Lumpur, Malaysia The conference will address the traditional and evolving frontiers of the Internet as well as its significant impact on education, commerce and societies throughout the world. Abstracts of papers to be submitted by 10 October. -for details of submission procedure email -for program information email ==================================================== This meeting list is also available on our WWW page: http://www.terena.nl/news/ ==================================================== IMR Editor [Page 33]   Received: from ietf.org by ietf.org id aa27444; 1 Nov 96 20:16 EST Received: from zephyr.isi.edu by ietf.org id aa27137; 1 Nov 96 20:13 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 1 Nov 1996 17:12:23 -0800 Message-Id: <199611020112.AA29438@zephyr.isi.edu> To: IETF-Announce: ; To: Internet-Monthly-Report-People: ; Subject: Internet Monthly Report for August, 1996 Cc: imr-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Date: Fri, 01 Nov 96 17:12:23 PST Sender:ietf-announce-request@ietf.org From: IMR Editor --NextPart The Internet Monthly Report for August, 1996 is now available at the following location: URL= ftp://ftp.isi.edu/in-notes/imr/imr9608.txt The Internet Monthly Report (IMR) is normally distributed via EMail to the IMR list and the IETF list. For most readers this is the most convenient way to receive the report. However, there are some mail systems or mail gateways that do not accommodate large messages (some issues of the IMR are more than 100,000 characters). Readers that do not receive the IMR via the normal distribution may obtain copies via FTP or EMail retrieval. Requests to be added or deleted from the IMR report list: The Internet Monthly Report list is managed by MajorDomo atISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be added or deleted from the Internet Monthly report list should be sent to majordomo@isi.edu with the message body either subscribe imr or unsubscribe imr. Requests to be added or deleted from the IETF list should be sent to ietf-request@ietf.org. Internet Monthly Report availability via WWW, FTP and EMAIL: IMR Retrieval using WWW ----------------------- The URL below may be used in web browsers to access the IMRs. You will see a list of names in the form IMR9608.TXT. For example, IMR9608.TXT is the report for August 1996. URL: ftp://ftp.isi.edu/in-notes/imr IMR Retrieval using EMAIL via the RFC-INFO Service -------------------------------------------------- The EMail retrieval system RFC-Info will send a large report in segments in separate EMail messages not exceeding 50,000 characters each. Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_imrs. For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs IMR Retrieval using FTP ----------------------- IMRs are available via anonymous FTP from FTP.ISI.EDU, with the pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of the IMR. For example IMR9608.TXT is the report for August 1996). Login with FTP username anonymous and password ftp. IMR retrieval using MIME ------------------------ Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retreive the current IMR. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="rfc-info@isi.edu" Content-Type: text/plain Retrieve: imr Doc-ID: imr9608 --OtherAccess Content-Type: Message/External-body; name="imr9608.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes/imr" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa29530; 2 Nov 96 0:36 EST Received: from merit.edu by ietf.org id aa29396; 2 Nov 96 0:33 EST Received: from LapTop.Simpson.DialUp.Mich.Net (pm036-11.dialip.mich.net [141.211.7.53]) by merit.edu (8.7.6/merit-2.0) with SMTP id WAA02447 for ; Fri, 1 Nov 1996 22:51:02 -0500 (EST) Date: Sat, 2 Nov 96 03:19:20 GMT Sender:ietf-request@ietf.org From: William Allen Simpson Message-ID: <2159.wsimpson@greendragon.com> To: ietf@ietf.org Subject: Evaluating TLD proposal Source-Info: From (or Sender) name not authenticated. I had gotten rather far behind, and just read Sep thru Oct IETF list. But at least this way, I am reasonably assured of not duplicating anyone else's comments.... Having actually read many/most of the TLD proposals in the past, and written one myself, I have a few comments that might focus this discussion, which has gone rather far afield: I think that Denninger has some valid points. I just wish that he would have tried to resolve the issues _within_ the IETF, rather than attempting a go-around. OTOH, the IANA didn't use IETF process, either! I particularly object to some of the language in the current draft-postel-iana-itld-admin-02.txt: 3.2 The Board of Trustees acts for the ISOC, the IAB for the IETF, and the IANA for itself. While the organizations RFC is fresh as we speak, and I have not yet checked it, historically the IANA reports to the IAB, not unto itself. And the IESG (rather than the IAB) speaks for the IETF. Many of the objections to the Postel draft probably arise from this attempt to shrug off oversight. The IANA needs oversight, just like everything else. Checks and Balances! Denninger also raises the valid point that the proposed fees and such for the new registries do not apply to the existing registries. That is excrable. If the IANA is to be supported by fees, then the largest existing load should start right out by paying its fair share! I also have raised the issue in the past that this fee structure is not the best we could devise. What is the purpose of an "application fee"? Why have both a quarterly/yearly fee, and a percentage fee? Instead, I have recommended that the applicant post a "performance bond". As in other corporate contracts, this bond would be used to pay for rebidding and conversion to another contractor in the event that the initial contractor defaults. It could earn interest. It could be refundable at the termination of a successful contract. And I would make the quarterly fee entirely based on the number of domain registrants. As noted, this is relatively simple to verify. It makes more sense than administering 2 fees, one fixed and one variable, or worrying about percentages. This fee would be changed yearly to reflect the needed funds for the IANA and IETF Secretariate. I would not use any fee to directly fund root name servers, which for engineering reasons should be located at (and funded by) the major topological exchanges as they are built. Oh, and I find the draft (for a third revision) to have rather a lot of English problems for a native speaker ;-) WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from ietf.org by ietf.org id aa19130; 2 Nov 96 2:18 EST Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa17629; 2 Nov 96 2:14 EST Sender:ietf-request@ietf.org From: Masataka Ohta Message-Id: <199611020712.QAA01510@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA01510; Sat, 2 Nov 1996 16:12:14 +0900 Subject: Re: English is it -> was: Re: The cartel begins to crumble? To: Phil Karn Date: Sat, 2 Nov 96 16:12:13 JST Cc: ERIC@vm.se.lsoft.com, ietf@ietf.org In-Reply-To: <199611012236.OAA09605@servo.qualcomm.com>; from "Phil Karn" at Nov 1, 96 2:36 pm X-Mailer: ELM [version 2.3 PL11] Source-Info: From (or Sender) name not authenticated. Phil; > Americans are among the most assertive and outspoken people in the > world, and American IETFers are among the most assertive and outspoken > Americans. Our passions can easily intimidate those of other cultures > (especially Asians) into offended silence. As a result, simple > misunderstandings can erupt into major battles or at least long-term > resentment. Sorry for my insufficient effort to be as assertive and outspoken as people in US. I'll try harder. But, to confirm your statement, let's have an experiment to use Japanese for the discussion and compare who are more assertive and outspoken, you or me. Note that your misspelling and grammatical errors are tolerated. Are you ready? Now, let's begin. Deha, hajimemashou. Watasiha Azia jin ga tokuni otonasii toha omoimasenyo. Tanni amerika jin ya youroppa jin yori eigoga dekinai hitoga ooito iu dakeno kotodeha? Nihon no nyuusu guruupu demo, kappatu ni ikenwo iu hitoha ikurademo imasu. Masataka Ohta   Received: from ietf.org by ietf.org id aa27082; 2 Nov 96 3:25 EST Received: from cnri by ietf.org id aa26985; 2 Nov 96 3:22 EST Received: from [204.250.49.77] by CNRI.Reston.VA.US id aa04022; 2 Nov 96 3:22 EST Received: from [204.250.49.20] by mail.coupon.net with ESMTP (Apple Internet Mail Server 1.1.1); Sat, 2 Nov 1996 00:20:48 -0800 Message-Id: In-Reply-To: References: Your message of "Fri, 01 Nov 1996 16:21:03 CST." <01BBC810.AE47E5C0@webster.unety.net> <01BBC810.AE47E5C0@webster.unety.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 2 Nov 1996 00:20:24 -0800 To: "Louis A. Mamakos" , Jim Fleming Sender:ietf-request@ietf.org From: Simon Higgs Subject: Re: Folling the crumbling cartel - a note about thread following Cc: Karl Denninger , "ietf@CNRI.Reston.VA.US" , 'New Newdom' , "sthaug@nethelp.no" Source-Info: From (or Sender) name not authenticated. At 5:57 PM -0500 11/1/96, Louis A. Mamakos wrote: > While I can't speak on behalf of all of UUNET, I can certainly > offer my opinion. I don't think that UUNET would be interested > in running a "rogue" root name server. Didn't Rick Adams... nah... must've been a dream. Simon -- "The only thing to prevent what's past is to put a stop to it before it happens." -- attributed to Sir Boyle Roche, eighteenth-century member of Parliament from Tralee, famed for his word-mangling   Received: from ietf.org by ietf.org id aa29685; 2 Nov 96 4:11 EST Received: from nic.hq.cic.net by ietf.org id aa29592; 2 Nov 96 4:09 EST Received: from localhost (dorian@localhost) by nic.hq.cic.net (8.8.2/CICNet) with SMTP id EAA08433; Sat, 2 Nov 1996 04:08:22 -0500 (EST) Date: Sat, 2 Nov 1996 04:08:22 -0500 (EST) Sender:ietf-request@ietf.org From: "Dorian R. Kim" X-Orig-Sender: dorian@cic.net Reply-To: "Dorian R. Kim" To: Masataka Ohta cc: ietf@ietf.org Subject: Re: English is it -> was: Re: The cartel begins to crumble? In-Reply-To: <199611020712.QAA01510@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Sat, 2 Nov 1996, Masataka Ohta wrote: > Sorry for my insufficient effort to be as assertive and outspoken as > people in US. I'll try harder. Mr. Ohta, please permit me to observe that you don't seem to one of those to whom Mr. Karn was referring to. While tentativeness because of unfamiliar language is part of the reason, differences across cultures of the mode and tone of formal exchange is one of possible reason why some people might feel less inclined to step up to the mic at meetings. -dorian, a non-native speaker of English or American.   Received: from ietf.org by ietf.org id aa00212; 2 Nov 96 4:15 EST Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa00135; 2 Nov 96 4:14 EST Sender:ietf-request@ietf.org From: Masataka Ohta Message-Id: <199611020912.SAA01892@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA01892; Sat, 2 Nov 1996 18:11:53 +0859 Subject: Re: English is it -> was: Re: The cartel begins to crumble? To: dorian@cic.net Date: Sat, 2 Nov 96 18:11:52 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ietf@ietf.org In-Reply-To: ; from "Dorian R. Kim" at Nov 2, 96 4:08 am X-Mailer: ELM [version 2.3 PL11] Source-Info: From (or Sender) name not authenticated. dorian; > While tentativeness because of unfamiliar language is part of the reason, > differences across cultures of the mode and tone of formal exchange is one of > possible reason why some people might feel less inclined to step up to the mic > at meetings. > > -dorian, a non-native speaker of English or American. dakara, chanto youroppa jintono chigaimo nobete arudeshouga. nihongo no bubun yondekara forou site hosiin desukedo? anata nihon no nyuusu guruupu deno ronchou, mitakoto arimasu? Masataka Ohta   Received: from ietf.org by ietf.org id aa25963; 2 Nov 96 17:04 EST Received: from aun.uninett.no by ietf.org id aa23649; 2 Nov 96 16:54 EST Received: from dale.uninett.no (actually trhm8.or.uninett.no) by aun.uninett.no with SMTP (PP); Sat, 2 Nov 1996 22:52:41 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id WAA02315 for ; Sat, 2 Nov 1996 22:33:18 +0100 Sender:ietf-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: ietf@ietf.org Subject: Directories, names and addresses (Re: Re[3]: The cartel begins to crumble?) In-reply-to: Your message of "Fri, 01 Nov 1996 12:08:10 PST." <199611012008.MAA09393@giant.genesyslab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2311.846970398.1@dale.uninett.no> Date: Sat, 02 Nov 1996 22:33:18 +0100 Message-ID: <2313.846970398@dale.uninett.no> X-Orig-Sender: hta@dale.uninett.no Source-Info: From (or Sender) name not authenticated. Someone is losing their sense of reality if they're talking as if we could insert directory lookups in the middle of a mail forward path. Get real. A NAME is not an ADDRESS. SEARCH CRITERIA are not NAMES. The DNS is for NAME to ADDRESS lookup (plus some auxillary functions). A directory service is for SEARCH CRITERIA to NAME lookup. Having a real directory MIGHT help the NAME ALLOCATION problem because it's not so important that my NAME is "the only one of its kind". But E-mail addresses and URLs are NAMES, NOT search critera; the reason why we want them to be strings, not numbers, is because they are easier to REMEMBER (IMHO, of course). Harald A   Received: from ietf.org by ietf.org id aa27464; 3 Nov 96 7:20 EST Received: from mail.u-net.net by ietf.org id aa27269; 3 Nov 96 7:16 EST Received: from sgml.u-net.com ([193.119.188.188]) by mail.u-net.net with SMTP id <40581-18389>; Sun, 3 Nov 1996 12:11:45 +0000 X-Sender: mtbryan-sgml@mail.u-net.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To:Misha Wolf , ietf Sender:ietf-request@ietf.org From:Martin Bryan Subject: Re: Tenth Int'l Unicode Conference - Call for Papers - Final Reminder Message-Id: <96Nov3.121145+0000_gmt.40581-18389+467@mail.u-net.net> Date:Sun, 3 Nov 1996 12:11:45 +0000 Source-Info: From (or Sender) name not authenticated. Gerhard At 20:41 1/11/96 -0500, Man-Sze wrote: >Character sets are becoming ubiquitous - the Icelanders should be pleased. >Man-Sze > > Tenth International Unicode Conference > and > Global Computing Showcase > > Europe, Software + the Internet: Going Global with Unicode** > > March 10-11, 1997 > > Mainz, Germany > I have had a couple of mailings re this conference, but had written it off due to the budget limitations, but now that Man-Sze has flagged it wonder whether you feel it is a conference we should be reporting on next year? Martin ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/   Received: from ietf.org by ietf.org id aa20337; 4 Nov 96 4:14 EST Received: from josef.ifi.unizh.ch by ietf.org id aa20071; 4 Nov 96 4:03 EST Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00455-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 10:01:50 +0100 Subject: Re: English is it -> was: Re: The cartel begins to crumble? To: Phil Karn Date: Mon, 4 Nov 1996 10:01:47 +0100 (MET) Cc: ERIC@vm.se.lsoft.com, ietf@ietf.org In-Reply-To: <199611012236.OAA09605@servo.qualcomm.com> from "Phil Karn" at Nov 1, 96 02:36:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 650 Sender:ietf-request@ietf.org From: Martin J Duerst X-Orig-Sender: mduerst@ifi.unizh.ch Message-ID: <"josef.ifi..123:04.10.96.09.01.51"@ifi.unizh.ch> Source-Info: From (or Sender) name not authenticated. Phil Karn wrote: >The IETF is an English-speaking, US-centric organization because the >Internet originated in the US. Definitely not so for "English-speaking"! English is the major language in business, in science, in diplomacy, and so on. The Internet is no exception at all. Regards,Martin. ---- Dr.sc. Martin J. Du"rst ' , . p y f g c R l / = Institut fu"r Informatik a o e U i D h T n S - der Universita"t Zu"rich ; q j k x b m w v z Winterthurerstrasse 190 (the Dvorak keyboard) CH-8057 Zu"rich-Irchel Tel: +41 1 257 43 16 S w i t z e r l a n d Fax: +41 1 363 00 35 Email: mduerst@ifi.unizh.ch ----   Received: from ietf.org by ietf.org id aa22289; 4 Nov 96 6:14 EST Received: from dxmint.cern.ch by ietf.org id aa22201; 4 Nov 96 6:11 EST Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id MAA10858; Mon, 4 Nov 1996 12:10:16 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA01706; Mon, 4 Nov 1996 12:10:15 +0100 Message-Id: <9611041110.AA01706@dxcoms.cern.ch> Subject: Re: Evaluating TLD proposal To: William Allen Simpson Date: Mon, 4 Nov 1996 12:10:15 +0100 (MET) Sender:ietf-request@ietf.org From: Brian Carpenter CERN-CN Cc: ietf@ietf.org In-Reply-To: <2159.wsimpson@greendragon.com> from "William Allen Simpson" at Nov 2, 96 03:19:20 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Bill, > I particularly object to some of the language in the current > draft-postel-iana-itld-admin-02.txt: > > 3.2 The Board of Trustees acts for the ISOC, the IAB for the IETF, > and the IANA for itself. > > While the organizations RFC is fresh as we speak, and I have not yet > checked it, historically the IANA reports to the IAB, not unto itself. Correct, which is why the IAB is in the appeals chain defined by the draft. > And the IESG (rather than the IAB) speaks for the IETF. Well, both the IESG and the IAB are appointed by the IETF NomCom, so I don't think you can really complain here. The IAB specifically decided not to appoint any of its own members to the IAHC, to avoid conflict of interest. However, we also had some feeling that next time around (if there is a next time) an open nomination process would be better. > > Many of the objections to the Postel draft probably arise from this > attempt to shrug off oversight. The IANA needs oversight, just like > everything else. Checks and Balances! I think this is generally agreed, and the IAHC is a first attempt at broadening the scope of the oversight outside the geek community. We are certainly not done with this topic yet. > > Denninger also raises the valid point that the proposed fees and such > for the new registries do not apply to the existing registries. That is > excrable. If the IANA is to be supported by fees, then the largest > existing load should start right out by paying its fair share! I think many people would agree to that, but how do you retro-fit it into existing contracts and business plans? Brian Carpenter   Received: from ietf.org by ietf.org id aa23082; 4 Nov 96 6:47 EST Received: from josef.ifi.unizh.ch by ietf.org id aa23014; 4 Nov 96 6:46 EST Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00993-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 12:43:10 +0100 Subject: Re: The cartel begins to crumble? - .com crowding To: Gary Scott Malkin Date: Mon, 4 Nov 1996 12:43:09 +0100 (MET) Cc: jed@llnl.gov, ietf@ietf.org In-Reply-To: <18153.9611011536@huey.xylogics.com> from "Gary Scott Malkin" at Nov 1, 96 10:36:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2221 Sender:ietf-request@ietf.org From: Martin J Duerst X-Orig-Sender: mduerst@ifi.unizh.ch Message-ID: <"josef.ifi..396:04.10.96.11.43.20"@ifi.unizh.ch> Source-Info: From (or Sender) name not authenticated. Gary Malkin wrote: >> >The *.COM TLD is crowded, but only because everyone seems to want to >> >crowd into it ... probably exactly because it is so crowded. >> >> I think this is about right. A specific angle on this is that >> I (and I suspect I am not alone) often will try > >Actually, I think that most people register under .com because they >don't know that anything else exists. I don't think I've ever seen >any URL advertised on TV that wasn't a .com. Well, advertisements on TV are called COMmercialls, aren't they :-? >I think we could solve >some of the crowding simply by insisting that a .com name truely be >a company/corporation (i.e., not the name of a movie, or someones >pet project). I guess the main reason for somebody registering (as a compay) under .com is that if e.g. you are looking for IBM, you will look at ibm.com. If we have .biz (which I assume stands for business), I would have to try with ibm.com and ibm.biz. That may be good for some higher "equal opportunity" aim, but it's a pain for everyday use. And in case IBM also registers ibm.biz, that only shows how unnecessary .biz actually is. Also, if registration on TLDs is opened on a first-come-first-served base, .ibm will soon be reserved, even if there are quite heavy requirements on TLD registration. Companies such as IBM certanily have no problem finding out how they already meet the requirements. This would be the equivalent to just abolishing the concept of TLDs altogether. Also, most of the current TLDs are country TLDs. All around the world, except for the US, this works well. The traditional .com, .mil, .edu,... domains are there for backwards compatibility. Ideally, they would be .com.us, .mil.us, .edu.us, as there is .co.jp and .ac.jp (don't know for .mil.jp :-) in Japan. .com and .org might have some justification for multinational companies and international organizations, and there might be other cases where a deviation from the rule TLD==country can be justified, but the idea of creating additional junk TLDs for commercial US interests (whoever gets the money) is only justifying the prejudices people elsewhere in the world have about the US and some of its inhabitants.. Regards,Martin.   Received: from ietf.org by ietf.org id aa24869; 4 Nov 96 8:13 EST Received: from relay5.UU.NET by ietf.org id aa24672; 4 Nov 96 8:09 EST Received: from uucp5.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp5.UU.NET [192.48.96.36]) id QQbojk06407; Mon, 4 Nov 1996 08:03:55 -0500 (EST) Received: from excel.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Mon, 4 Nov 1996 08:03:55 -0500 Received: from cc:Mail by excel.xl.com id AA847123737 Mon, 04 Nov 96 08:08:57 Date: Mon, 04 Nov 96 08:08:57 Sender:ietf-request@ietf.org From: sholland Encoding: 2286 Text Message-Id: <9610048471.AA847123737@excel.xl.com> To: daniel@sems.co.jp, ietf@ietf.org, Koo Chee Kai Subject: Re[2]: Sorry to intrude. Source-Info: From (or Sender) name not authenticated. Count me in on that action too. I want outta this listserver. I already tried the normal way and it didn't work. So kick me off please!!!!!!! Sue ______________________________ Reply Separator _________________________________ Subject: Re: Sorry to intrude. Author: Koo Chee Kai at Internet Date: 11/2/96 8:30 AM Received: by ccmail Received: from uunet by xl.com (UUPC/extended 1.11) with UUCP; Sat, 02 Nov 1996 08:28:29 EST Received: from ietf.org by relay1.UU.NET with SMTP (peer crosschecked as: ietf.org [132.151.1.19]) id QQboam04663; Fri, 1 Nov 1996 22:05:48 -0500 (EST) Received: from ietf.org by ietf.org id aa18339; 1 Nov 96 18:58 EST Received: from sunflower.singnet.com.sg by ietf.org id aa18288; 1 Nov 96 18:57 EST Received: from LOCALNAME (ts900-6009.singnet.com.sg [165.21.162.93]) by sunflower .singnet.com.sg (8.6.12/8.6.9) with SMTP id HAA20054; Sat, 2 Nov 1996 07:56:20 +0 800 Date: Sat, 2 Nov 1996 07:56:20 +0800 Message-Id: <199611012356.HAA20054@sunflower.singnet.com.sg> X-Sender: kcheekai@singnet.com.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: daniel@sems.co.jp, ietf@ietf.org Sender: ietf-request@ietf.org From: Koo Chee Kai X-ccAdmin: NOBODY@uunet Subject: Re: Sorry to intrude. Source-Info: From (or Sender) name not authenticated. Try sending a mail to ietf-request@IETF.CNRI.Reston.VA.US with the subject as "unsubscribe" Good luck. At 01:07 PM 10/31/96 -0800, Daniel Minoru Saito wrote: >I hate to protrude into this nice little conversation in regards to `The >cartel begins to crumble...` but if anyone could show me the way out of >this listserver. It isn`t the type of conversation that I was looking >for. > >I tried various times requesting the listserver to UNSUBSCRIBE me but no >luck. > >So I have three options: > >1.) Ask politely on the listserver newsgroup in how to get out. >2.) Be a complete ASSHOLE in my efforts and get kicked out. >3.) Hack into the listserver and then crash the whole listserver at >listproc@wugate.wustl.edu. >   Received: from ietf.org by ietf.org id aa25496; 4 Nov 96 8:30 EST Received: from dfw-ix12.ix.netcom.com by ietf.org id aa25411; 4 Nov 96 8:28 EST Received: from wdenton.Columbiasc.NCR.COM ([153.78.216.140]) by dfw-ix12.ix.netcom.com (8.6.13/8.6.12) with SMTP id FAA16986; Mon, 4 Nov 1996 05:27:19 -0800 Message-ID: <327DEF50.25A3@columbiasc.ncr.com> Date: Mon, 04 Nov 1996 08:27:44 -0500 Sender:ietf-request@ietf.org From: Neil Denton Organization: NCR Corporation X-Mailer: Mozilla 2.02 (Win95; I) MIME-Version: 1.0 To: ietf@ietf.org CC: daniel@sems.co.jp, Koo Chee Kai Subject: Re: Re[2]: Sorry to intrude. References: <9610048471.AA847123737@excel.xl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. KICK ME TOO! PLEASE. I'm NOT GETTING PERSONAL MAIL. I Speak english.....but this is outrageous. KICK ME! KICK ME! Neil sholland wrote: > > > > Count me in on that action too. I want outta this listserver. I already tried > the normal way and it didn't work. So kick me off please!!!!!!! > > Sue > > ______________________________ Reply Separator _________________________________ > Subject: Re: Sorry to intrude. > Author: Koo Chee Kai at Internet > Date: 11/2/96 8:30 AM > > Received: by ccmail > Received: from uunet by xl.com (UUPC/extended 1.11) with UUCP; > Sat, 02 Nov 1996 08:28:29 EST > Received: from ietf.org by relay1.UU.NET with SMTP > (peer crosschecked as: ietf.org [132.151.1.19]) > id QQboam04663; Fri, 1 Nov 1996 22:05:48 -0500 (EST) > Received: from ietf.org by ietf.org id aa18339; 1 Nov 96 18:58 EST > Received: from sunflower.singnet.com.sg by ietf.org id aa18288; > 1 Nov 96 18:57 EST > Received: from LOCALNAME (ts900-6009.singnet.com.sg [165.21.162.93]) by > sunflower .singnet.com.sg (8.6.12/8.6.9) with SMTP id HAA20054; Sat, 2 Nov 1996 > 07:56:20 +0 800 > Date: Sat, 2 Nov 1996 07:56:20 +0800 > Message-Id: <199611012356.HAA20054@sunflower.singnet.com.sg> > X-Sender: kcheekai@singnet.com.sg > X-Mailer: Windows Eudora Light Version 1.5.2 > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > To: daniel@sems.co.jp, ietf@ietf.org > Sender: ietf-request@ietf.org > From: Koo Chee Kai > X-ccAdmin: NOBODY@uunet > Subject: Re: Sorry to intrude. > Source-Info: From (or Sender) name not authenticated. > > Try sending a mail to > > ietf-request@IETF.CNRI.Reston.VA.US > > with the subject as "unsubscribe" > > Good luck. > > > At 01:07 PM 10/31/96 -0800, Daniel Minoru Saito wrote: > >I hate to protrude into this nice little conversation in regards to `The > >cartel begins to crumble...` but if anyone could show me the way out of > >this listserver. It isn`t the type of conversation that I was looking > >for. > > > >I tried various times requesting the listserver to UNSUBSCRIBE me but no > >luck. > > > >So I have three options: > > > >1.) Ask politely on the listserver newsgroup in how to get out. > >2.) Be a complete ASSHOLE in my efforts and get kicked out. > >3.) Hack into the listserver and then crash the whole listserver at > >listproc@wugate.wustl.edu. > > >   Received: from cnri by ietf.org id aa26554; 4 Nov 96 8:53 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09408; 4 Nov 96 8:53 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Mon, 4 Nov 1996 13:15:34 GMT Received: from clbull.frcl.bull.fr by MIT.EDU with SMTP id AA24807; Mon, 4 Nov 96 08:15:26 EST Received: from emsc.frcl.bull.fr (emsc.frcl.bull.fr [129.182.42.100]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id OAA16138 for ; Mon, 4 Nov 1996 14:14:45 +0100 Received: by emsc.frcl.bull.fr (AIX 3.2/UCB 5.64/4.03) id AA28133; Mon, 4 Nov 1996 14:04:12 +0100 From: Denis Pinkas Message-Id: <9611041304.AA28133@emsc.frcl.bull.fr> Subject: INFOSEC'COM 97 To: IETF CAT WG Date: Mon, 4 Nov 1996 14:04:11 +0100 (NFT) X-Mailer: ELM [version 2.4 PL20] Mime-Version: 2.4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable INFOSEC'COM International Congress on=20 Information Systems and Telecommunications Security 12 . 13 June 1997 - CNIT Paris-La Defense - FRANCE Invitation to submit Presentations The International Congress on Information Systems and Telecommunications=20 Security presents the state of the art, innovations, prospects and new=20 openings in the fields of information systems and telecommunications=20 security. The information presented is novel and the presentations by the= =20 speakers are both diversified and of a high standard. As such, they are=20 mostly intended for specialists in the field (information systems securit= y=20 managers, computer manufacturers, software publishers, consultants, ...). This Congress will take place in Paris (CNIT La Defense) alongside the=20 INFOSEC trade fair (from June 11 to June 13) where the exhibitors will=20 demonstrate their know-how in the area of information systems security=20 products and services. To make things even more attractive, June happens to be the most pleasant= =20 period of the year to visit Paris.=20 The Programmes Committee will carefully study all submitted proposals for= =20 lectures and select those that will be included in the programme.=20 Selection is based on the following criteria: originality and novelty of=20 the lecture, relevance of the topic, quality of the speaker, the=20 scientific contents of the presentation, ...=20 The Congress focuses on the latest breakthroughs and prospects for the=20 various security techniques, both in terms of theory and practice. For 1997, the Programmes Committee will essentially, though not=20 exclusively, emphasise the following themes: * Security organisation and engineering * Security issues in the area of information outsourcing * Cryptographic technologies update * Practical implementation of trusted third parties, their missions=20 guarantees, relationships between trusted third parties, ... * Internet and information superhighways: "firewalls", integrated=20 offerings by network operators and software publishers, the role of=20 access suppliers, the war against viruses, ... * Electronic commerce security * Radiocommunications security * Sector-specific issues (banking, health services, ...) * Legal trends in the field of security, for instance on Internet,=20 copyrights, intellectual property, protection of youth, taxes, ... * Etc. Programme s Committee Walter FUMY - SIEMENS AG (D) Marc GIRAULT - SEPT (F) Hans GLISS - DATENSCHUTZ-BERATER (D) Andr=E9 GRISSONNANCHE - AGC (F) Fr=E9d=E9ric HUYNH - CLUSIF (F) Jean-Philippe JOUAS - CSC (F) Jean-Marc LAMERE - FFSA (F) Jo=EBl LEBIDOIS - THOMSON CSF (F) Jean MENTHONNEX - EPI Conseil (CH) Christopher MITCHELL - UNIVERSITY OF LONDON (UK) Denis PINKAS - BULL (F) Philippe ROSE - LE MONDE INFORMATIQUE (F) Gilles RUGGIU - BERTIN ET CIE (F) Pieter VAN DIJKEN - SHELL INT. PETROLEUM (NL) Michael WALKER - VODAFONE (UK) GENERAL INFORMATION DATES=09 - Congress: 12.13 June 1997 - Exhibition: 11.12.13 June 1997 SITE C.N.I.T. Paris-La Defense - 4 Place de la Defense -=20 92090 PARIS LA DEFENSE - France OFFICIAL LANGUAGES French and English - Simultaneous interpretation. ACCOMMODATION=20 CIP Hotel will help you to book a room. Tel : 33 (0)1 44 70 29 36 or 33 (0)1 44 70 25 02 Fax : 33 (0)1 44 70 24 48 ASSISTANCE M.C.I. could help you in organizing your stay in Paris. TRAVEL DISCOUNTS AIR INTER, AIR LIBERTE, TAT EUROPEAN AIRLINES and SNCF. HOW TO GET THERE Information will be given in: Programme and Participant's Card. REGISTRATION FEE (participant) : FF 4.980 (taxes incl.) Price will include: access to conference-rooms, participant's file,=20 proceedings, 2 lunches, 4 coffee-breaks, visit and catalogue of the=20 INFOSEC exhibition. REGULATION HOW TO SUBMIT A PROPOSAL Send the "Project for Paper" by December 3, 1996 Or use Electronic mail: clusif@clusif.asso.fr Overtly "commercial" presentations are inappropriate. ACCEPTANCE Authors will be notified of rejection or acceptance by December 31 . But=20 the Programmes Committee reserves the right to reconsider its decision=20 upon presentation of the full paper due no later than February 28 :=20 paper in French or English + 2 abstracts (French and English) + biography= =20 + photo. Authors will have to certify their paper will not be published prior to=20 June 12, 1997.=20 PRESENTATION PROPOSAL Approximately 25 minutes. BENEFITS FOR SPEAKERS Free admission offered (congress and exhibition). PATRONAGE CLUSIF - Club de la Securite Informatique Francais ORGANISATION=20 MCI - Manifestations & Communications Internationales 19 Rue d'Athenes - 75009 PARIS - FRANCE T=E9l : 33 (0)1 44 53 72 20 - Fax : 33 (0)1 44 53 72 22   Received: from cnri by ietf.org id aa27055; 4 Nov 96 9:01 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09579; 4 Nov 96 9:01 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Mon, 4 Nov 1996 13:33:25 GMT Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP id AA23387; Mon, 4 Nov 96 08:33:24 EST Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Mon, 4 Nov 1996 13:33:22 GMT Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id IAA02391; Mon, 4 Nov 1996 08:33:23 -0500 Message-Id: <199611041333.IAA02391@winkl.cam.ov.com> To: cat-ietf@mit.edu Cc: linn@cam.ov.com Subject: Fwd: Internet-Draft CUTOFF Date Date: Mon, 04 Nov 1996 08:33:21 -0500 From: John Linn [For the benefit of any CAT-related document editors who are not also subscribers to the general IETF announcement list. --jl] ------- Forwarded Message Received: from ietf.org by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Fri, 1 Nov 1996 21:06:28 GMT Received: from ietf.org by ietf.org id aa00358; 1 Nov 96 15:34 EST Received: from localhost by ietf.org id aa00235; 1 Nov 96 15:32 EST To: ;@IETF-Announce Subject: Internet-Draft CUTOFF Date Date: Fri, 01 Nov 1996 15:32:19 -0500 Sender: ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9611011532.aa00235@ietf.org> The cut-off for Internet-Draft submissions prior to the San Jose IETF meeting is Tuesday, November 26, 1996 at 5pm ET. Internet-Drafts received after this time will not be announced nor made available in the Internet-drafts Directories. We will begin processing Internet-Draft submissions the week following the IETF meeting. Thank you for your understanding and cooperation. Please do not hesitate to contact me if you have any questions or concerns. Kind Regards, Cynthia Clark Internet-Drafts Administrator ------- End of Forwarded Message   Received: from ietf.org by ietf.org id aa28479; 4 Nov 96 9:46 EST Received: from localhost by ietf.org id aa27743; 4 Nov 96 9:29 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kahle-mail-archive-00.txt Date: Mon, 04 Nov 1996 09:29:24 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611040929.aa27743@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Restricting the External Archiving of Email Author(s) : B. Kahle Filename : draft-kahle-mail-archive-00.txt Pages : 2 Date : 10/31/1996 This draft proposes a mail header field "Restrict:" with a defined value of "no-external-archive" that gives information to a receiving mail transport agent or mail user agent that this message should not be archived by individuals or organizations not associated with the list owner. With the increasing number of search engines that gather information and offer wide access, some writers and would like to restrict how their words are distributed. Mailing lists may begin (or have already begun) to be systematically archived for searching and historical reference. This draft is designed for mailing lists, but it can also be applied to messages in Usenet newsgroups as well. The legal issues around this are deep and difficult, and this draft does not address these legal issues. However, it would be useful to respectful mail receivers if there was a standard method for mail creators (authors or list owners) to express their desires about whether or not their mail can be archived. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kahle-mail-archive-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-kahle-mail-archive-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kahle-mail-archive-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961031150346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kahle-mail-archive-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kahle-mail-archive-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961031150346.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa28482; 4 Nov 96 9:46 EST Received: from localhost by ietf.org id aa27759; 4 Nov 96 9:29 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ngtrans-routing-aspects-02.txt Date: Mon, 04 Nov 1996 09:29:26 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611040929.aa27759@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Routing Aspects Of IPv6 Transition Author(s) : R. Callon, D. Haskin Filename : draft-ietf-ngtrans-routing-aspects-02.txt Pages : 13 Date : 11/01/1997 This internet draft gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document "Transition Mechanisms for IPv6 Hosts and Routers" [1]. Readers should be familiar with the transition mechanisms before reading this document. The proposals contained in this document are based on the work of the Ngtrans working group. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ngtrans-routing-aspects-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ngtrans-routing-aspects-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ngtrans-routing-aspects-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961101150715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ngtrans-routing-aspects-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ngtrans-routing-aspects-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961101150715.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa29935; 4 Nov 96 10:04 EST Received: from fnal.fnal.gov by ietf.org id aa29823; 4 Nov 96 10:02 EST Received: from gungnir.fnal.gov ("port 35003"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IBFXS7QNGK003R2T@FNAL.FNAL.GOV> for ietf@ietf.org; Mon, 04 Nov 1996 09:01:30 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA22606; Mon, 04 Nov 1996 09:01:03 -0600 Date: Mon, 04 Nov 1996 09:01:03 -0600 Sender:ietf-request@ietf.org From: Matt Crawford Subject: Re: The cartel begins to crumble? In-reply-to: "01 Nov 1996 15:23:07 CST." <"199611012123.PAA02754"@Mercury.mcs.net> X-Orig-Sender: crawdad@gungnir.fnal.gov To: ietf@ietf.org Message-id: <199611041501.JAA22606@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ > The second person who claims *ANY* TLD is the one to ignore. This sounds like a fair rule to apply at any level of the hierarchy. I'll apply it one level higher than Karl & company.   Received: from ietf.org by ietf.org id aa01690; 4 Nov 96 10:34 EST Received: from BUTTHEAD.FSM.NET by ietf.org id aa01607; 4 Nov 96 10:32 EST Received: from localhost by supernet.com.co (SMI-8.6/SMI-SVR4) id KAA06676; Mon, 4 Nov 1996 10:27:12 +0500 Date: Mon, 4 Nov 1996 10:27:11 +0500 (GMT) Sender:ietf-request@ietf.org From: "Jesus Maria Arango - Ing. Comunicaciones FSM LTDA." X-Sender: jarango@butthead To: Martin J Duerst cc: Gary Scott Malkin , jed@llnl.gov, ietf@ietf.org Subject: Re: The cartel begins to crumble? - .com crowding In-Reply-To: <"josef.ifi..396:04.10.96.11.43.20"@ifi.unizh.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. My personal experience with the .com TLD being crowded is that some country domains are not well administered. For example, it takes quite long to get (if you ever get one) a domain under .com.co for Colombia, So I just rather apply to the registration services in the U.S. I think that the Internic should be more careful when asigning country domains to institutions who are not planning to make go use of it. I wish that the colombian domain (.co) would be taken off from the actual holder, which happens to be a burocratic university in Bogota. ***************************************** * Jesus Arango * * Ingeniero de Comunicaciones * * Supernet - FSM LTDA. - Cablesistema * * E-Mail: jarango@fsm.net * * Internic POC Handle: JA406 * * Tel: (574) 268-9000 * * Fax: (574) 268-1281 * ****************************************   Received: from ietf.org by ietf.org id aa08106; 4 Nov 96 12:27 EST Received: from doorstep.unety.net by ietf.org id aa08023; 4 Nov 96 12:25 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA10045; Mon, 4 Nov 1996 11:19:41 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCA42.526C4460@webster.unety.net>; Mon, 4 Nov 1996 11:21:28 -0600 Message-ID: <01BBCA42.526C4460@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: Martin J Duerst , "'Valdis.Kletnieks@vt.edu'" Cc: "ietf@ietf.org" Subject: RE: The cartel begins to crumble? - .com crowding Date: Mon, 4 Nov 1996 11:21:26 -0600 Encoding: 25 TEXT Source-Info: From (or Sender) name not authenticated. On Monday, November 04, 1996 10:52 AM, Valdis.Kletnieks@vt.edu wrote: @ On Mon, 04 Nov 1996 12:43:09 +0100, Martin J Duerst said: @ > ibm.com. If we have .biz (which I assume stands for business), @ @ A good point made in passing. Remember that not all the world is @ English-speaking, and may not easily recognize that 'biz' is a phonetic @ mangling of 'business'. At least COMmercial, NETwork, MILitary, and @ EDUcational can be easily puzzled out.... @ @ Some people in Ukraine are working on new top level domains for .KOM and .CET which evidently are equivalents to .COM and .NET. More discussion on this appears on the newdom mailing list from time to time . -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa11646; 4 Nov 96 13:43 EST Received: from localhost by ietf.org id aa11417; 4 Nov 96 13:37 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: ietf-rsvp@ietf.org Subject: 37th IETF - List of Registered Attendees Date: Mon, 04 Nov 1996 13:37:34 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9611041337.aa11417@ietf.org> The following is a list of registered attendees as of Sunday, November 3, 1996. NOTE: Early Registration Cut-off is this Friday, November 8. If you register ON or BEFORE November 8, your registration fee will be $250.00, if you register AFTER November 8, your registration fee will be $270.00. 1 Aboba, Bernard Microsoft Corporation 2 Adam, Daniel Microsoft Corporation 3 Adams, Robert Cisco Systems 4 Agbleze, Mawuse FTP Software, Inc. 5 Ahmed, Masuma Terayon Corporation 6 Ahuja, Ratinder Cisco Systems 7 Aibara, Reiji Hiroshima University 8 Alaettinoglu, Cengiz Information Sciences Institute 9 Alden, Roland 10 Alexander, Steve Silicon Graphics, Inc. 11 Allen, Edward Bay Networks, Inc. 12 Allen, Jeff Bunyip Information Systems 13 Allen, Terry Fujitsu Software Corp. 14 Allocchio, Claudio National Institute for Nuclear Physics, Italy 15 Almes, Guy Advanced Network and Services, Inc. 16 Alterman, Louise Lucent Technologies 17 Ambler, Christopher Image Online Design, Inc. 18 Amidon, Keith Hewlett-Packard 19 Andersson, Loa Eriksson 20 Angelopoulos, Spiros Sterling Software 21 Aprille, Thomas Lucent Technologies, Bell Laboratories 22 Arango, Jesus Supernet S.A. 23 Armstrong, Susie Qualcomm Inc. 24 Arneson, David Digital 25 Arunkumar, Nagaraj 3Com Corporation 26 Asano, Kazuo Fujitsu Laboratories Ltd. 27 Aspinwall, Russell Calyx UK Ltd. 28 Back, Nigel BT Laboratories 29 Bailey, Chase Cisco Systems 30 Bailey, Ed IBM Corporation 31 Baker, Fred cisco Systems 32 Bakker, Steven DANTE 33 Balenson, David Trusted Information Systems 34 Bannister, Joseph USC/ISI 35 Bantel, Richard Lucent Technologies 36 Barnes, Jim Bay Networks 37 Bathina, Raghu Trancell Systems, Inc. 38 Beaulieu, Marcia Corporation for National Research Initiatives 39 Bedell, J. Patrick 40 Bellovin, Steven AT&T Research 41 Berkhout, Vincent DANTE 42 Bernardi, Marco CSELT 43 Berson, Steven Information Sciences Institute 44 Beyer, Mark Netmanage, Inc. 45 Bhoajaraj, Sandya Hewlett-Packard 46 Bhogavilli, Suresh Information Sciences Institute 47 Bierman, Andy Cisco Systems, Inc. 48 Binder, Richard Corporation for National Research Initiatives 49 Blanchet, Marc Viagenie inc. 50 Blondel, P.F.C. S.A.R.A. 51 Blumenthal, Uri IBM Corporation 52 Borden, Marty Bay Networks, Inc. 53 Borinski, Stan Realogic, Inc. 54 Boroumand, Javad USC-ISI 55 Boroumand, Sepideh NASA GSFC/HSTX 56 Bos, Erik-Jan SURFnet bv 57 Boulianne, Luc McGill University 58 Bound, Jim Digital Equipment Corporation 59 Bowen, Rich NetEdge Systems, Inc. 60 Boyle, Jim The MITRE Corporation 61 Braden, Robert Information Sciences Institute 62 Bradescu, Roxana Sun Microsystems, Inc. 63 Breed, Charles Pretty Good Privacy, Inc. 64 Breslau, Lee Xerox PARC 65 Briceno, Marc DigiCash, Inc. 66 Bridgham, David Epilogue Technology Corporation 67 Brim, Scott Cornell University 68 Brockners, Frank University of Cologne - ZPR 69 Brody, Lawrence AT&T 70 Brown, Anne Nortel Technology 71 Brown Klinger, Sheila Lucent Technologies 72 Buchko, Steven Newbridge Networks Inc. 73 Burgan, Jeffrey Bay Networks, Inc. 74 Burle, Marlene Conferon, Incorporated 75 Bush, Randy NSRC 76 Cabeca, Linda Bay Networks, Inc. 77 Cai, Yiqun Northern Telecom 78 Cain, Patrick BBN Corporation 79 Cajano, Alessandro Telecom Italia 80 Calcari, Susan InterNIC/University of Wisconsin 81 Callaghan, Brent Sun Microsystems, Inc. 82 Callon, Ross Cascade Communications 83 Calvert, Kenneth Georgia Institute of Technology 84 Cansever, Derya GTE Laboratories, Inc. 85 Carlson, Richard Argonne National Laboratory 86 Carney, Michael Sun Microsystems, Inc. 87 Carpenter, Brian CERN 88 Carrel, David Cisco Systems 89 Carter, Stephen Novell, Inc. 90 Casner, Stephen Precept Software, Inc. 91 Caswell, Peter US Robotics 92 Chen, Yao-Min Fujitsu Laboratories of America 93 Cherenson, Andrew Liquid Audio, Inc. 94 Chiotasso, Chris BGS Systems, Inc. 95 Chiu, Alex Sun Microsystems 96 Chow, Jeff AMD 97 Christy, Greg Cisco Systems 98 Chu, H. K. Jerry SunSoft 99 Clark, Cynthia Corporation for National Research Initiatives 100 Clark, David Massachusetts Institute of Technology 101 Clauberg, Axel University of Cologne 102 Colella, Richard America Online 103 Comay, David Sun Microsystems, Inc. 104 Compton, Kip Continental Cablevision, Inc. 105 Cook, Gordon Cook Report on Internet 106 Copeland, Ken U.S. Dept. of Veterans Affairs 107 Corson, Scott University of Maryland 108 Coya, Stephen Corporation for National Research Initiatives 109 Craren, Michael 3COM 110 Crawford, Matt Fermilab 111 Crawley, Eric Bay Networks, Inc. 112 Crowe, David NERO Network 113 Curtin, Bill DISA 114 Daigle, Leslie Bunyip Information Systems 115 Dam, Tru Network Systems Corporation 116 Dang, Winston University of Hawaii 117 Daniel, Ron Los Alamos National Laboratory 118 Daoud, Edward Fujitsu 119 Davie, Bruce Cisco Systems 120 Dawkins, Spencer Nortel 121 De Winter, Jack Wildbear Consulting, Inc. 122 Delagi, Bruce Apple Computer, Inc. 123 Demirtjis, Ann Sprint 124 Demizu, Noritoshi Sony Computer Science Lab, Inc 125 Dittler, Hans Braintec Network Consulting 126 Doi, Yuusuke KEIO University 127 Donelan, Sean Data Research Associates, Inc. 128 Donner, Paul 129 Doraswamy, Naganand FTP Software, Inc. 130 Dosedal, Anke Cisco Systems 131 Droms, Ralph Bucknell University 132 Droz, Patrick IBM Research Laboratory 133 Duniho, Michael National Security Agency 134 Dunn, Jeffrey Hewlett-Packard 135 Dunstan, Adam Bay Networks, Inc. 136 Dupont, Francis INRIA Rocquencourt 137 Earhart, Rob Carnegie Mellon University 138 Eastlake, Donald CyberCash, Inc. 139 Eisler, Mike Sun Soft Inc. 140 Ellehauge, Peter Dansk Data Elektronik A/S 141 Ellerbee, Jeff ichat Inc. 142 Ellis, Gehrett Corporation for National Research Initiatives 143 Elz, Robert University of Melbourne 144 Emery, Nick AltaVista Internet Software 145 England, Kent Six Sigma Networks 146 Erickson, Rodger Wall Data 147 Erlinger, Michael The Aerospace Corporation 148 Estrin, Deborah Information Sciences Institute 149 Fair, Erik Apple Computer, Inc. 150 Fajman, Roger National Institutes of Health 151 Farinacci, Dino Cisco Systems, Inc. 152 Fasano, Paolo CSELT 153 Faynberg, Igor Lucent Technologies 154 Ferguson, Paul Cisco Systems 155 Fernandez, Antonio Bellcore 156 Ferracin, Joseph SITA/ITS 157 Fink, Robert Lawrence Berkeley Laboratory 158 Finkelstein, David Xcert Software Inc. 159 Flanigan, William Defense Information Systems Agency 160 Fleshman, Michael Clearview Systems, Inc. 161 Ford, Warwick 162 Forster, James Cisco Systems 163 Forsythe, Margaret Epilogue Technology Corp. 164 Fowler, Dave Newbridge Networks Inc. 165 Fox, Barbara Microsoft Corporation 166 Fox, Craig Cisco Systems 167 Fox, Daniel Bay Networks 168 Frankhauser, Martine SITA 169 Fuller, Vince BBN Corporation 170 Fumeno, Takanori Telecoment Inc. 171 Gadre, Jay Bell Atlantic 172 Galvin, James CommerceNet 173 Ganguly, Anik Campbell Services Inc. 174 Gilliam, William Hewlett-Packard 175 Gilmore, John Electronic Frontier Foundation 176 Girod, Lewis Massachusetts Institute of Technology 177 Glass, Steven FTP Software, Inc. 178 Glatting, Dennis CyberSafe Corporation 179 Goel, Vab Sprint 180 Goland, Yaron Microsoft 181 Gold, Harry NCCOSC 182 Goller, Sean Carnegie Mellon University 183 Gonzalez, Ricardo Hypertech Corporation 184 Goto, Yukinori Institute of Systems & Information Technology 185 Goyal, Mukul Sun Microsystems, Inc. 186 Gray, Eric 187 Greene, Barry Cisco Systems 188 Greene, Maria Ascom Nexion, Inc. 189 Grill, Thomas E-Systems 190 Gudmundsson, Olafur Trusted Information Systems 191 Gupta, Rajeev Trillium Digital Systems, Inc. 192 Gurajapu, Suresh Trancell Systems, Inc. 193 Haller, Neil Bellcore 194 Halpern, Joel Newbridge Networks Inc. 195 Halpin, James U.S. Robotics 196 Hambridge, Sally Intel Corporation 197 Hamilton, Martin Univeristy of Technology, Loughborough 198 Handelman, Sigmund IBM Corporation 199 Hanna, Donal Netskills 200 Harrison, Sari Apple Computer Inc. 201 Hasegawa, Yusaku Nara Institute of Science & Technology 202 Haskin, Dimitry Bay Networks, Inc. 203 Heard, C.M. VVNET, Inc. 204 Hedberg, Roland SUNET 205 Heffernan, Andy cisco Systems 206 Heidemann, John USC/ISI 207 Hernacki, Brian Netscape Communications, Inc. 208 Herron, Andrew Microsoft Corporation 209 Herzog, Shai IBM 210 Hien, Nguyen IBM Corporation 211 Hildenbrand, Bruce Sun Microsystems 212 Hilton, Rhonda Cable Television Laboratories 213 Hinden, Robert Ipsilon Networks, Inc. 214 Hirabaru, Masaki Merit Network, Inc. 215 Hirai, Chiaki Hitachi Ltd. 216 Hoffman, Paul Internet Mail Consortium 217 Holcomb, Jeff Apple Computer, Inc. 218 Holdrege, Matt Ascend Communications 219 Holmstead, Stephen Hewlett Packard 220 Hopkins, Gerry Bell Atlantic 221 Hopprich, John Cisco Systems 222 Hornby, Peter Unisys Corporation 223 Horneffer, Martin University of Cologne 224 Horowitz, Marc Cygnus Support 225 Hosein, Javed Bay Networks, Inc. 226 Huddle, Scott MCI Telecommunications Corporation 227 Hunt, Bill VPNE Technologies 228 Hur, Matt Cyber Safe Corporation 229 Huss, Claude Matsushita Electric Works US R&D Laboratories 230 Huston, Geoff Telstra 231 Ilgun, Koral Advanced Computer Communications 232 Inbar, Ofer The Left Bank Operation, Inc. 233 Inoue, Yoshinobu Fujitsu Laboratories Ltd. 234 Irlam, Gordon Cygnus Support 235 Ishiyama, Masahiro Toshiba Corporation 236 Iuso, Francesco Telecom Italia 237 Iversen, Ruben Dan Net 238 Iwata, Atsushi NEC Corporation 239 Jackowski, Steven NetManage, Inc. 240 Jacobs, Stuart GTE Laboratories 241 Jacobsen, Ole ConneXions 242 Jennings, Barbara Sandia National Laboratories 243 Jensen, Del Novell, Inc. 244 Jiang, Jonathan Bellcore 245 Jinzenji, Hiroshi NTT Human Interface Labs 246 Johnson, Jeff Cisco Systems 247 Johnson, Keith Federal Express Corporation 248 Johnson, Richard Cisco Systems 249 Johnson, Terry Develcon Electronics Ltd. 250 Jokubaitis, Vito AT&T 251 Jones, Ken Bay Networks, Inc. 252 Jork, Markus Digital Equipment GmbH 253 Joseph, Mark Attachmate Corporation 254 Kaat, Marijke SURFnet Expertise Center 255 Kalra, Sanjay Cisco Systems 256 Kapil, Vivek Nortel Technology 257 Kapur, Arun Quadritek Systems, Inc. 258 Kashima, Hiroaki Fujitsu Ltd. 259 Kastenholz, Frank FTP Software, Inc. 260 Kato, Akira The University of Tokyo Computer Center 261 Kaufman, Charlie Iris Associates 262 Kemp, David National Security Agency 263 Kennedy, John Novell Inc. 264 Kennedy, L. Sean BBN Corporation 265 Kent, Stephen BBN Corporation 266 Kern, Ed DIGEX 267 Keromytis, Angelos University of Pennsylvania 268 Kessens, David USC/ISI 269 Key, Kenneth Cisco Systems 270 Khalsa, Kirpal Lotus ccMail 271 Kim, Dorian CICNet, Inc. 272 Kim, Hyogon Bellcore 273 Kirchhoff, Julie Corporation for National Research Initiatives 274 Kirstein, Peter University College London 275 Kiyoshima, Naoki Ultra-high Speed Network & Computer Tech. Labs 276 Klensin, John MCI Telecommunications Corporation 277 Koch, Harald Secure Computing Canada Ltd. 278 Koester, Greg Bay Networks 279 Komiya, Masakatsu Japan Satellite Systems Inc. 280 Koskelainen, Petri Nokia Research Center 281 Krawczyk, John Bay Networks, Inc. 282 Krechmer, Ken Action Consulting 283 Kristol, David Lucent Technologies, Bell Laboratories 284 Krol, Edward University of Illinois Urbana 285 Krupczak, Cheryl Empire Technologies, Inc. 286 Kuang, Fidelia Apple Computer Inc. 287 Kuehne, Mirjam RIPE NCC 288 Kumar, Sanjay First Virtual Corporation 289 Kumar, Vinay ICAST Communications, Inc. 290 Kurakami, Hiroshi NTT Multimedia Networks Labs 291 Kurn, David Tandem Computers Inc. 292 Kuroda, Yasutsugu Fujutsu Laboratory Ltd. 293 Kwan, Stuart Microsoft Corporation 294 Kwan, William Jupiter Technology, Inc. 295 Lamond, Keith British Telecom North America 296 Lang, Ruth SRI International 297 Langlois, Sylvain Electricite de France 298 Lanphier, Rob Progressive Networks 299 Larsson, Jorgen Telia AB 300 Lasker, Valerie Precept Software, Inc. 301 LaVange, Don Novell, Inc. 302 Lavu, Lava George Mason University 303 Lawler, John VPNet Technologies, Inc. 304 Lear, Eliot Silicon Graphics, Inc. 305 Lee, WeeSan USC/ISI 306 Leech, Marcus Nortel Technology 307 Leinen, Simon SWITCH 308 Lemaire, Thomas 3Com Corporation 309 Lenggenhager, Thomas SWITCH 310 Lenharth, William University of New Hampshire 311 Leong, Ivan Pacific Internet Pte. Ltd. 312 Leroy, David FORE Systems 313 Leu, Brian Semaphore Communications Corp. 314 LeValley, Jim Macmillan Technical Publishing 315 Lewis, Edward Trusted Information System 316 Li, Hongqing Lucent Technologies 317 Li, Tony Juniper Networks Inc. 318 Li, Yan-Fa Hewlett-Packard 319 Liau, Wendy Oracle Corporation 320 Lichtensteiger, Reta Mitsubishi Electric ITA 321 Lim, Koon Sang Logic Group of Companies 322 Ling, Wenken Bay Networks, Inc. 323 Linn, John OpenVision Technologies 324 Liu, Eric Cable & Wireless 325 Liu, Yuan-Kwei NASA Ames Research Center 326 Lord, Anne UUNET PIPEX 327 Lu, Hui-Lan Lucent Technologies 328 Lu, Vivian NetEdge Systems, Inc. 329 Luciani, James Bay Networks, Inc. 330 Lundblade, Laurence Qualcomm Inc. 331 Macker, Joseph US Naval Research Laboratory 332 Mader, Keith Bay Networks, Inc. 333 Maeda, Kaori Hiroshima City University 334 Mahdavi, Jamshid Pittsburgh Supercomputing Center 335 Maher, Maryann USC/ISI 336 Malamud, Carl MIT Media Lab 337 Malis, Andrew Ascom Nexion, Inc. 338 Malkin, Gary Bay Networks 339 Mallory, Tracy 3Com Corporation 340 Mamros, Shawn FTP Software, Inc. 341 Mankin, Allison Information Sciences Institute 342 Mannie, Eric Brussels University 343 Manning, Bill Information Sciences Institute 344 Markham, Tom Secure Computing Corp. 345 Martillo, Joachim Telford Tools, Inc. 346 Martin, Antony DRA 347 Martin, Cynthia Defense Information Systems Agency 348 Martin, John TERENA 349 Masinter, Larry Xerox Corporation 350 Maston, Michael Cisco Systems 351 Mather, Tim Apple Computer 352 Mathis, Matt Pittsburgh Supercomputing Center 353 Matsuhira, Naoki Fujitsu Laboratories Ltd. 354 Matsune, Mio Network Information Service Co 355 Matsushita, Nobuo Bell Labs, Lucent Technologies 356 Maughan, Douglas National Security Agency 357 Maw, Tim Stentor Resource Centre Inc. 358 Maxham, Mark Apple Computer, Inc. 359 Mazzucato, Sandro Bunyip Information Systems 360 McBurnett, Neal Lucent Technologies, Bell Labs 361 McCloghrie, Keith cisco Systems 362 McCooey, Jeremy University of New Hampshire 363 McDonald, Daniel Sun Microsystems, Inc. 364 McGarvey, John IBM 365 McManis, Chuck Free Gate Corporation 366 McMillan, Tom 3Com Primary Access 367 McPherson, Danny MCI Telecommunications Corporation 368 Medrinsky, Ari Cyber Safe Corporation 369 Mende, Robert Silicon Graphics, Inc. 370 Merchant, Shashank Advanced Micro Devices 371 Meyer, David University of Oregon 372 Miller, Thomas Siemens 373 Miller, W. Marcus Lawrence Livermore National Labs 374 Mills, Cynthia GTE Laboratories, Inc. 375 Milnes, Brian Lycos, Inc. 376 Minami, Masaki Keio University 377 Minshall, Greg Ipsilon Networks, Inc. 378 Mistry, Danny Nortel Technology 379 Moats, Ryan AT&T Bell Laboratories InterNIC 380 Mogul, Jeffrey Digital Equipment Corporation 381 Mohta, Pushpendra CERFnet 382 Monsour, Robert Hi/fn, Inc. 383 Moore, Mike Hewlett-Packard 384 Moore, Robert IBM Corporation 385 Morris, David barili systems limited 386 Morris, Jonathan Manchester Metropolitan University 387 Morse Johnson, Kelly Cisco Systems 388 Mouradian, George AT&T Bell Laboratories 389 Moy, Diana U.S. Robotics 390 Moy, John Cascade Communications Corporation 391 Mundy, Russ Trusted Information Systems 392 Murai, Jun Keio University 393 Murphy, Sandra Trusted Information Systems 394 Murray, Cecil Campbell Services Inc. 395 Mutz, Andrew Hewlett-Packard 396 Myers, John Carnegie Mellon University 397 Myjak, Michael University of Central Florida 398 Nagami, Ken-ichi Toshiba Corporation 399 Nakamura, Osamu Keio University 400 Napjus, Erikas Carnegie Mellon University 401 Narayan, Vishy NASA Ames Research Center 402 Narayana, Raj Cable & Wireless 403 Narten, Thomas IBM Corporation 404 Nassi, Ike AppleSoft 405 Neer, Merle NRaD 406 Nemeth, Evi University of Colorado 407 Neuman, Clifford Information Sciences Institute 408 Newman, Chris Innosoft International, Inc. 409 Nguyen, Hai Raytheon E-Systems 410 Nicklass, Orly RAD Data Communications 411 Nicklow, Doug Lycos, Inc. 412 Nikander, Pekka 413 Noerenberg, John Qualcomm Inc. 414 Nowicki, William Silicon Graphics, Inc. 415 O'Leary, Peter Clear Blue Network Systems, Inc. 416 Obraczka, Katia USC/ISI 417 Oehler, Michael National Security Agency 418 Ohichi, Tsuyoshi Fujitsu Ltd. 419 Ohta, Masataka Tokyo Institute of Technology 420 Onishi, Steven Bay Networks, Inc. 421 Oran, David Cisco Systems 422 Ordille, Joann Bell Labs, Lucent Technologies 423 Ostrowski, Stephen 3Com 424 Ozaki, Satoshi Toshiba Corporation 425 Paez-Ramirez, Alonso BT Labs 426 Pang, Joseph Starlight Networks 427 Pareth, Sameer C2Net 428 Parker, Steve SunSoft, Inc. 429 Partan, Andrew WNA 430 Partington, Heath US Robotics Inc. 431 Patrick, Michael Motorola ISG 432 Perkins, Charles IBM Corporation 433 Perlman, Radia Novell, Inc. 434 Petke, Richard CompuServe, Inc. 435 Piper, Derrell Cisco Systems 436 Postel, Jon Information Sciences Institute 437 Presuhn, Randy BMC Software, Inc. 438 Pullen, J. Mark C3I Center 439 Rabin, Tal IBM 440 Rajagopalan, Bala Bellcore 441 Rajagopal, Murali Fujitsu 442 Ramanan, P.S. Sprint Corporation 443 Randall, Karen AT&T Universal Card Services Corporation 444 Rank, Edward Bay Networks 445 Ray, Cathe Sun Microsystems, Inc. 446 Reed, Benjamin IBM Corporation 447 Reeder, David Portland State University 448 Resnick, Pete Qualcomm Inc. 449 Rex, Martin SAP AG 450 Reynolds, Joyce K. Information Sciences Institute 451 Richard, Pat Xcert Software Inc. 452 Richardson, John Intel Corporation 453 Rogerson, Duncan University of London 454 Romanow, Allyn Sun Microsystems, Inc. 455 Roque Marques, Pedro Universidade de Lisboa 456 Rose, Marshall T. First Virtual Holdings Inc. 457 Rossen, Ken MCI Systemhouse 458 Routhier, Shawn Epilogue Technology Corporation 459 Royce, Kathy Bay Networks, Inc. 460 Ruth, Greg GTE Laboratories, Inc. 461 Rutkowski, Anthony General Magic, Inc. 462 Ryan, Gerard Bell Labs 463 Ryutov, Tatyana USC/ISI 464 Saito, Takeshi Toshiba Corporation 465 Sakamoto, Hiromitsu NEC Corporation 466 Salo, Timothy Minnesota Supercomputer Center 467 Samanick, John Defense Information Systems Agency 468 Saperia, Jon BGS Systems, Inc. 469 Sarkezians, Hasmik US Robotics 470 Sarmiento, Ramiro Sun Microsystems, Inc. 471 Sawyer, Wilson Bay Networks/LANcity 472 Scano, John 3Com 473 Schey, John Europay International 474 Schiller, Jeffrey Massachusetts Institute of Technology 475 Schmechel, Christopher Sun Microsystems, Inc. 476 Schneider, Mark National Security Agency 477 Schneider, Wolfgang GMD 478 Schnell, Steven Sprint Government Systems Division 479 Scott, Gregor Defense Information Systems Agency 480 Sedayao, Jeff Intel Corporation 481 Seto, Koichiro Hitachi Cable 482 Shand, Mike Digital Equipment Co. Ltd. 483 Shew, Stephen Nortel Technology 484 Shieh, Shuching Bay Networks, Inc. 485 Shimojo, Shinji Osaka University Computer Center 486 Shirey, Rob BBN Corporation 487 Shirley, Fred Sanders 488 Shmulevsky, Mark ADP, Inc. 489 Shobatake, Yasuro Toshiba Corporation 490 Siller, Curtis Lucent Technologies 491 Simpson, William Computer Systems Consulting Services 492 Sloane, Timon timonWare Inc. 493 Smith, Andrew NeoSoft, Inc. 494 Smith, Carl Sun Microsystems, Inc. 495 Smith, Michael TIAA-CREF 496 Smith, Philip UUNET PIPEX 497 Smith, Timothy IBM Corporation 498 Solensky, Frank FTP Software, Inc. 499 Sollins, Karen Massachusetts Institute of Technology 500 Solo, Dave BBN Corporation 501 Solomon, Jim Motorola 502 Spatscheck, Oliver University of Arizona 503 Speer, Michael Sun Microsystems, Inc. 504 Sridhar, T. Future Communications Software 505 Srinivasan, Suresh Thomson Technology Services Group 506 Srinivasan, Andre Oracle Corporation 507 St. Johns, Michael @Home Network 508 Staubach, Peter Sun Microsystems, Inc. 509 Steenstrup, Martha BBN Corporation 510 Stephens, Tom Microsoft Corporation 511 Stibler, Stephen IBM Corporation 512 Stockman, Bernhard Telia AB 513 Stuart, Wayne Cisco Systems 514 Sumikawa, Munechika Nara Institute of Science and Technology 515 Sumner, Mark Motorola 516 Suzuki, Muneyoshi NTT Multimedia Networks Labs 517 Swallow, George Cisco Systems 518 Swink, Michael Sprint 519 Takamatsu, Satoshi NTT 520 Takihiro, Masatoshi Hitachi Ltd. 521 Tallerico, David The MITRE Corporation 522 Talpade, Rajesh Georgia Institute of Technology 523 Tanaka, Kei Internet Initiative Japan Inc. 524 Tang, Cheng Hewlett-Packard 525 Taniguchi, Kunihiro NECUSA 526 Taylor, Peter Mailbase, Newcastle University 527 Tecot, Ed Apple Computer, Inc. 528 Teplitsky, Jacob Fore Systems 529 Teraoka, Fumio Sony Computer Science Laboratory, Inc. 530 Terpstra, Marten Bay Networks, Inc. 531 Tesink, Kaj Bellcore 532 Thatcher, Michael Thatcher Consulting Services 533 Thayer, Rodney Sable Technology Corporation 534 Thomas, Matt Digital Equipment Corporation 535 Thomas, Richard Nortel Technology 536 Thomson, Susan Bellcore 537 Tomimura, Eiji Sumitome Electric USA, Inc. 538 Tominaga, Akihiro Keio University 539 Topolcic, Claudio BBN Corporation 540 Touch, Joseph USC/ISI 541 Tow, Agnes AT&T 542 Tracy, Michael Sunsoft 543 Tramposch, Albert World Intellectual Property Organization 544 Travis, Ward Cisco Systems 545 Trest, Mike ATMNET 546 Trostle, Jonathan CyberSafe Corporation 547 Ts'o, Theodore Massachusetts Institute of Technology 548 Tsuchiya, Kazuaki Hitachi, Ltd. 549 Tung, Brian Information Sciences Institute 550 Turaj, Nancy The MITRE Corporation 551 Turner, Randy Sharp Laboratories of America 552 Uehara, Keisuke KEIO University 553 Umeda, Masayoshi Nippon Telegraph and Telephone Corporation 554 Vaudreuil, Gregory Octel Network Services 555 Veach, Ross CICNet, Inc. 556 Veenstra, Jack AT&T 557 Verina, Maria ICGEB 558 Verrilli, Colin IBM Corporation 559 Villanueva, Deric WRQ 560 Vohra, Quaizar University of New Hampshire 561 von Kaenel, Juerg IBM 562 Vozza, Vincenzo Telecom Italia 563 Vu, Anh Fore Systems 564 Vu, Joseph Fore Systems 565 Wada, Hiromi Matsushita Electric Industrial Company, Ltd. 566 Wahl, Mark Critical Angle, Inc. 567 Wall, Matt Carnegie Mellon University 568 Wallace, Dick Concord Communications, Inc. 569 Watanabe, Ken Hitachi, Ltd. 570 Watt, James Newbridge Networks Inc. 571 Weaver, Elfed Defense Research Agency 572 Webber, Bob PictureTel Corporation 573 Weiler, Samuel Carnegie Mellon University 574 Weiss, Howard SPARTA, Inc. 575 Wellens, Chris InterWorking Labs, Inc. 576 Wells, Amy Tracy InterNIC Net Scout 577 West, Jim Ciena Optical Communications 578 Whipple, Mark Octel Services 579 White, Gerry LANcity Corporation 580 White, Paul University College London 581 Williams, Carl Sun Microsystems, Inc. 582 Windrim, Mark Newstar Technologies 583 Winter, Brian US Robotics Inc. 584 Won, King Network General Corp. 585 Woodcock, Bill Zocalo Engineering 586 Wright, Graham Hummingbird Communications 587 Wright, Russ Lawrence Berkeley Laboratory 588 Wroclawski, John Massachusetts Institute of Technology 589 Yamamoto, Kazuhiko Nara Institute of Science Technology 590 Yao, Kwang Hewlett-Packard 591 Yarnell, Jeff Kaspia Systems, Inc. 592 Yavatkar, Raj Intel Corporation 593 Yen, Leemay 3Com Corporation 594 Ylonen, Tatu SSH Communications Security 595 Yu, I-Hsiang GTE Laboratories Inc. 596 Zhang, Lixia UCLA 597 Zhang, Zhaohui Bay Networks, Inc. 598 Ziegast, Eric GTE Interactive Media 599 Ziemba, Paul Fore Systems 600 Zorn, Glen Microsoft Corporation   Received: from ietf.org by ietf.org id aa14011; 4 Nov 96 14:20 EST Received: from proxy1.ba.best.com by ietf.org id aa13922; 4 Nov 96 14:18 EST Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.7.6/8.7.3) with ESMTP id LAA08649 for ; Mon, 4 Nov 1996 11:12:32 -0800 (PST) Received: from bill.scli.com ([206.79.9.179]) by shellx.best.com (8.6.12/8.6.5) with SMTP id LAA27866 for ; Mon, 4 Nov 1996 11:11:37 -0800 Received: by bill.scli.com with Microsoft Mail id <01BBCA59.C85F27C0@bill.scli.com>; Mon, 4 Nov 1996 14:09:24 -0800 Message-ID: <01BBCA59.C85F27C0@bill.scli.com> Sender:ietf-request@ietf.org From: Bill Hunt To: "ietf@ietf.org" Subject: Cartel Nonsense Date: Mon, 4 Nov 1996 14:09:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. I do hope this discussion eventually gets back to something remotely relevent, but I'm afraid I won't be here to find out as I am unsubscribing in another letter. I suspect the original subject had a deeper meaning than intended, as fed-up members such as myself drop off the list. Bill Hunt bill@vpnet.com ---------- From:Masataka Ohta[SMTP:mohta@necom830.hpcl.titech.ac.jp] Sent:Saturday, November 02, 1996 10:11 AM To:dorian@cic.net Cc:mohta@necom830.hpcl.titech.ac.jp; ietf@ietf.org Subject:Re: English is it -> was: Re: The cartel begins to crumble? dorian; > While tentativeness because of unfamiliar language is part of the reason, > differences across cultures of the mode and tone of formal exchange is one of > possible reason why some people might feel less inclined to step up to the mic > at meetings. > > -dorian, a non-native speaker of English or American. dakara, chanto youroppa jintono chigaimo nobete arudeshouga. nihongo no bubun yondekara forou site hosiin desukedo? anata nihon no nyuusu guruupu deno ronchou, mitakoto arimasu? Masataka Ohta   Received: from ietf.org by ietf.org id aa19594; 4 Nov 96 16:34 EST Received: from cnri by ietf.org id aa19268; 4 Nov 96 16:27 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22218; 4 Nov 96 16:27 EST Received: from ruebert.ieee.org by venera.isi.edu (5.65c/5.61+local-25) id ; Mon, 4 Nov 1996 13:26:11 -0800 Received: (from daemon@localhost) by ruebert.ieee.org (8.7.5/8.7.3) id QAA03288; Mon, 4 Nov 1996 16:28:35 -0500 (EST) Date: Mon, 4 Nov 1996 16:28:35 -0500 (EST) Message-Id: <199611042128.QAA03288@ruebert.ieee.org> To: ietf@isi.edu Sender:ietf-request@ietf.org From: majordomo@majordomo.ieee.org Subject: Welcome to comsoc-conferences Reply-To: majordomo@majordomo.ieee.org Precedence: bulk Organization: IEEE Service Center, Piscataway, NJ Source-Info: From (or Sender) name not authenticated. -- Welcome to the comsoc-conferences mailing-list! If you ever want to remove yourself from this mailing list, send the following command in email to "majordomo@majordomo.ieee.org" with the following command in the body of your email message: unsubscribe comsoc-conferences ietf@isi.edu Here's the general information for the list you've subscribed to, in case you don't already have it: #### No info available for comsoc-conferences.   Received: from ietf.org by ietf.org id aa20437; 4 Nov 96 16:54 EST Received: from callandor.cybercash.com by ietf.org id aa20425; 4 Nov 96 16:53 EST Received: by callandor.cybercash.com; id QAA11872; Mon, 4 Nov 1996 16:48:10 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma011853; Mon, 4 Nov 96 16:47:53 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA23674; Mon, 4 Nov 96 16:50:32 EST Date: Mon, 4 Nov 1996 16:50:31 -0500 (EST) Sender:ietf-request@ietf.org From: "Donald E. Eastlake 3rd" To: majordomo@majordomo.ieee.org Cc: ietf@ietf.org Subject: Welcome to comsoc-conferences (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. unsubscribe comsoc-conferences ietf@isi.edu end I'm on the IETF mailing list to read IETF discussions and get IETF announcements. People who want to get IEEE or ACM or ... meeting announcements should subscribe to those lists themselves. I don't know who tried to subscribe the ietf list to the ieee announcement service but it was wrong. There are many computer and networking conferences, meetings, call for papers, etc., every day. If they were all announced on the IETF list, the list would be essentially useless. Unsolicited email is not the way to advertise on the Internet. There are plenty of web pages, appropriate newsgroups, and narrow mailing lists. By being on the IETF list I am soliciting IETF meeting annoucements, not IEEE or other organziations annoucnements. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html ---------- Forwarded message ---------- Date: Mon, 4 Nov 1996 16:28:35 -0500 (EST) From: majordomo@majordomo.ieee.org To: ietf@isi.edu Subject: Welcome to comsoc-conferences -- Welcome to the comsoc-conferences mailing-list! If you ever want to remove yourself from this mailing list, send the following command in email to "majordomo@majordomo.ieee.org" with the following command in the body of your email message: unsubscribe comsoc-conferences ietf@isi.edu Here's the general information for the list you've subscribed to, in case you don't already have it: #### No info available for comsoc-conferences.   Received: from ietf.org by ietf.org id aa22628; 4 Nov 96 17:54 EST Received: from apollo.it.hq.nasa.gov by ietf.org id aa22565; 4 Nov 96 17:53 EST Received: from wirehead.it.hq.nasa.gov (WireHead.it.hq.nasa.gov [131.182.119.88]) by apollo.it.hq.nasa.gov (8.6.12/8.6.12) with ESMTP id WAA20797; Mon, 4 Nov 1996 22:52:17 GMT Received: from localhost (cshenton@localhost) by wirehead.it.hq.nasa.gov (8.6.12/8.6.12) with SMTP id WAA14884; Mon, 4 Nov 1996 22:51:41 GMT Message-Id: <199611042251.WAA14884@wirehead.it.hq.nasa.gov> X-Authentication-Warning: wirehead.it.hq.nasa.gov: cshenton owned process doing -bs X-Authentication-Warning: wirehead.it.hq.nasa.gov: Host localhost didn't use HELO protocol To: majordomo@majordomo.ieee.org Cc: ietf@ietf.org Subject: Re: Welcome to comsoc-conferences (fwd) In-Reply-To: Your message of "Mon, 4 Nov 1996 16:51:05 -0500 (EST)" References: <199611042151.QAA10185@ruebert.ieee.org> X-Mailer: Mew version 1.03 on Emacs 19.31.8 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 04 Nov 1996 17:51:41 -0500 Sender:ietf-request@ietf.org From: Chris Shenton Source-Info: From (or Sender) name not authenticated. unsubscribe comsoc-conferences ietf-announce@cnri.reston.va.us end They subscribed ietf-announce Looks like they subscribed a bunch of other lists too... :-( Members of list 'comsoc-conferences': c.dessoye 0002912712@mcimail.com 100010.3371@compuserve.com 100045.3451@compuserve.com 100046.3710@compuserve.com 100125.3213@compuserve.com 100130.3723@compuserve.com 100141.536@compuserve.com 100141.676@compuserve.com 100144.3104@compuserve.com 100263.17@compuserve.com 100277.152@compuserve.com 100304.2136@compuserve.com 100327.2041@compuserve.com 100331.1340@compuserve.com 100333.1654@compuserve.com 100335.347@compuserve.com 100336.2470@compuserve.com 100342.1167@compuserve.com 100432@compuserve.com 100436.230@compuserve.com 100437.1126@compuserve.com 100440.3230@compuserve.com 100543.175@compuserve.com 100543.662@compuserve.com 100550.1756@compuserve.com 100572.1156@compuserve.com 100601.2536@compuserve.com 100606.3360@compuserve.com 100633.2467@compuserve.com 100735.3315@compuserve.com 100765.3267@compuserve.com 160317.273@compuserve.com 2416755@mcimail.com 3@AM.ITU.CH 4312323@mcimail.com 4395849@mcimail.com 519-5060@mcimail.com 6053253@mcimail.com 6110721@mcimail.com 638.1781@mcimail.com 638171@mcimail.com 6621920@mcimail.com 70624.557@compuserve.com 70670.3674@compuserve.com 71154.2522@compuserve.com 71221.621@compuserve.com 7124754@mcimail.com 71650.1046@compuserve.com 72662.1562@compuserve.com 72662.5050@compuserve.com 73064.71@compuserve.com 73252.1364@compuserve.com 735-2328@mcimail.com 73521.2256@compuserve.com 7409947@mcimail.com 74431.515@compuserve.com 74431.610@compuserve.com 74431.744@compuserve.com 74431.751@compuserve.com 74551.1064@compuserve.com 74667.1275@compuserve.com 74777.2215@compuserve.com 74777.3561@compuserve.com 75006.3504@compuserve.com 75162.2575@compuserve.com 75372.34642@compuserve.com 75410.2346@compuserve.com a.pelaez@ieee.org msalerno@lynxtech.com msemilof@cmp.com mss@gummo.doc.ic.ac.uk mthyfaul@cmp.com mtw@dial-switch.ch mukasa@ast.lab.kdd.co.jp a.hirsch@magnet.at multicomm@cc.bellcore.com f.wickenburg@magnet.at abpg4@singnet.com.sg fad@prism.uvsq.fr acray@mcgraw-hill.com adoughe@Gateway.Uswnvg.COM murase@nwk.cl.nec.co.jp Faouzi.Daoud@prism.uvsq.fr fdida@masi.ibp.fr mustafa@ece.concordia.ca filali@irit.fr nab01531@niftyserve.or.jp flegal@pobox.oleane.com nadism@mbunix.mitre.org naets@ebu.ch neteurop@dial.pipex.com fly@juicer.magna.com.au fmarain@innet.be aevagora@cmp.com netmgt@ncri.com fogarty@eurescom.d400.de forte@informatik.uni-kl.de fourneau@masi.ibp.fr fujikawa@nikkeibp.co.jp networks@cw.telecom.at newaves@aoi.com fulvio.faraci@MacPost.cselt.stet.it g-troup@dworkin.wustl.edu news.announce.conferences g.weisman@ieee.org nhe@postman.dg13.cec.be niau@systems.co.za afad@alain.demon.co.uk gabriela.wuerth@aut.alcatel.at niitsu@krsun.nslab.ntt.jp nkc@bellcore.com nmf-members@nmf.org gaddisgm@mcgraw-hill.com ag112120@dircon.co.uk ahmadi@engn.uwindsor.ca ahmed@ece.concordia.ca aidarous@bnr.ca nmsig@nemo.ncsl.nist.gov noiseworks@attmail.com gae@alfalinea.innet.it.ptc.org gaha@prodigy.com gca@economist.com aitec@geo2.poptel.org.uk akabanovsky@pyr.com gcomlist1@manjaro.ece.iit.edu akikaz@ascii.co.jp geradsd@agcs.com akses@tfi.be noms96@joker.bellcore.com Germind@Mgn.com nsm-info@gateway.mitre.org aledo@micronet.it alexander.higgins@ITU.CH alg@comm.toronto.edu am79@dial.pipex.com nzzspi@dm.rs.ch oliveira@eurecom.fr anderse@dsu.su.se.ptc.org announcements.chi@Xerox.com opd@dial.eunet.ch osimcast@bbn.com aow-nmsig@stc.ipa.go.jp OSIMIS@cs.ucl.ac.uk giga@tele.pitt.edu gk@datanews.be globecom@signet.com.sg godsdog@digmedia.com arby@pi.se goran.frojdh@aftonbladet.se gordon@elronet.co.il aref@alhayatdemon.co.uk.ptc.org gotz@cc.bellcore.com arl@arl.wustl.edu OVForum@andrew.cmu.edu oyamada@krsun.nslab.ntt.jp grand@hntpz.hinet.net.ptc.org panflet@cix.compulink.co.uk gsissa@inet.it arpanet-bboard@mc.lcs.mit.edu guthery@austin.sar.slb.com atm-list@csc.com Guy.Pujolle@prism.uvsq.fr atm@bbn.com audrey@yankee.co.uk aurore.lester-smith@infoboard.be guyd@computing.emap.co.uk auscom@02email.com.au.ptc.org guyd@post.emap.co.uk avibliz@eltonet.co.il.ptc.org G_F_Wetzel@cbgw1.att.com badri@cs.rutgers.edu Paolooberto@cselt.stet.it hansjoerg.schmid@alcatel.ch banafss@mcgraw-hill.com harneks@isd.toi.ernet.in baranyi@mtesz.hu barrere@irit.fr bashore@ix.netcom.com hdreifus@aol.com hegering@lrz-muenchen.de batnir@agcs.com heikki.nenonen@aamulehti.mailnet.fi paulcov@bnr.ca heinz@pct.de paulmcc@mcs.com hhodara@snap.org pbrown@cmp.com bborda@phillips.com hikaru@kopenews.nslab.ntt.jp pclarke@ifields.demon.co.uk.ptc.org hipparch@sophia.inria.fr bcs-hci-request@mailbase.ac.uk hlu@arch4.att.com benzekri@irit.fr pcollier@gotha.vtcom.fr per.roijer@sds.se hori@nikkeibp.co.jp horlait@masi.ibp.fr perform@tay1.dec.com hrt@telmo.fi Bernier1@aol.com petero@pi.net besier@eurescom.d400.de betourne@irit.fr peter_hankin@rhk.com huggard@irish-computer.ie bgelpke@access.ch bhumip@gte.com ian@icompub.demon.co.uk pf@hightech.presse.co.at icad-request@santafe.edu phill@intercom.com.au ie-list@cs.ucl.ac.uk pla@ccmail.idg.dk bich@cc.bellcore.com ieee.announce@bellcore.com ieeetcpc@ccvm.sunysb.edu ieee_rtc_list@cs.tamu.edu ietf-announce@cnri.reston.va.us billinghurst@wireworks.ptc.org bjr@d-comm.com plateau@imag.imag.fr BM-List1@cs.ucdavis.edu ietf-madman@innosoft.com bobchap@ibm.net pne@dial.pipex.com pogran@bbn.com ifip-emailmgt@ics.uci.edu poseyma@mcgraw-hill.com bolles@radiomail.net bottomac@mcgraw-hill.com ifip-nm@bbn.com prabhu@ee.uta.edu pradeep@dstc.uts.edu.au igorf@arch4.att.com bran@silcom.com prs@masi.ibp.fr iimc@thumper.bellcore.com brants@evert.com ikbsbb@inf.rl.ac.uk prs@uvsq.fr braudyb@aol.com ilka@prz.tu-berlin.de brg@hebdo.ch ptravis@cmp.com inet.kfho271@niftyserve.or.jp iplpdn@cnri.reston.va.us pxk12334@niftyserve.or.jp pyramid@pyr.com ipmb0024@mx.ivnet.com.tw brunosv@cpqd.br bryan@yankee.co.uk bumblis@mcc.com bur_goode@vnet.ibm.com byte.me@applelink.apple.com iroberts@cmp.com c.desmond@ieee.org isadsoc@fokus.gmd.de isinm97_oc@ctr.columbia.edu quevenco@adp01.iaea.or.at.ptc.org c.dessoye@ieee.org cabukv@informa.mk caillng@mobitel.telia.se isogai@softbank.co.jp candewilde@aol.com quevenco@adp01.iaea.or.at it@jp.dk radio74@iprolink.ch cara.cunningham@idg.com itc@fokus.gmd.de j.cheong@trl.oz.au radio@sovam.com j.n.slater@herts.ac.uk rafiq@crisv2.univ-pau.fr carera@jec.it.ptc.org jali@worldaccess.nl ralph@city.ac.uk Carl.@eleceng.ucl.ac.uk rappaport@sbee.sunysb.edu jandre@imtn.tpd.dsccc.com castanet@labri.u-bordeaux.fr jard@irisa.fr raymonmj@mcgraw-hill.com javan@comm.toronto.edu cboeke@phillips.com jbraue@mcgraw-hill.com raynal@irisa.fr raynaud@irit.fr cbonafield@nwc.com jcoons@dataquest.com ccrc@dworkin.wustl.edu rcas@cris.com cellular@comnets.rwth-aachen.de rcotro@micronet.it jeffc@wrn.org rdantu@tddcae99.fnts.com jeremiah_caron@wcmh.com cellular@dfv.rwth-aachen.de reda@iprolink.ch jerry@ece.concordia.ca rem-cof-request@es.net chapel@scmp.com chee-eng@mcgraw-hill.com chigir-i@ascii.co.jp rem-conf@es.net reres@comm.polymtl.ca jezequel@irisa.fr reres@laas.fr reres@uklirb.informatik.uni-kl.de chipweek@vogel.anet.cz jgallont@cid.infosel.com.mx revesz@idg.hu jim_kent@rhk.com rfumi@technet.it.ptc.org jjohnson@mcgraw-hill.com richard.wilson@rbp.co.uk chris-finn@telechoice.com jkeator@npr.org richard@alex.ptc.org richard@ptc.org chris@yankee.co.uk jlevenberg@mcimail.com chrish@media.emap.co.uk rlfike@aol.com rlouw@wn.apc.org christos@ece.miami.edu jmoberg@telepost.no jne@glasgow-caledonian.ac.uk chuanyi@ecse.rpi.edu roberto.kung@issy.cnet.fr cip@bnn.com roberto.saracco@cselt.stet.it joel_jakubson@rhk.com cjs1@psp.att.com johan.hjelm@baf.bonnier.se claireg@romtec.co.uk robert_s@idg.se clytle@sed.stel.com john.francis@ITU.CH cnom@maestro.bellcore.com johnston@auntie.bbcnc.org.uk rob_garretson@idg.com jonas@fti.se commsoft@cc.bellcore.com rocks@earn.cvut.cz comp.arch.storage comp.client-server jorgen@mogul.no comp.graphics.research comp.graphics.visualization comp.graphics comp.lang.visual rogerdean@attmail.com comp.mail.multi-media josh@ccnet.com comp.multimedia jouni.roksa@tbx.telebox.fl.ptc.org comp.org.acm Ron.Horn.0090874@nt.com jphang@hk.super.net rpreston@cmp.com js@hightech.presse.co.at comp.org.ieee comp.org.usenix jsaganger@nn.apc.org comp.os.research jsavage@ix.netcom.com jschenke@cmp.com rune.Wikstol@s.hk.telenor.ptc.org comp.parallel juanole@laas.fr just4net@aol.com samar.shamoon@ITU.CH jweil@cris.com comp.protocols.iso@bellcore.com jwhite@acp.com.au saracco@cselt.stet.it sb.all@ieee.org karen@icompub.demon.co.uk sbw@ccrl.nj.nec.com karlm@wrn.org comp.realtime scott_linke@aus.hp.com seb@cc.bellcore.com kdd@gte.com comptime@singnet.com.sg ke@voa.gov shchori@ccsg.tak.ac.il.ptc.org sheppard@elsevier.co.uk shomer@cix.compulink.co.uk keith@yankee.co.uk kevin@brs95787.demon.co.uk comsoc-chapters@ieee.org khart@cmp.com comsoc-gicb@ieee.org comsoc.bog@tab.ieee.org kjl@cc.bellcore.com comswtc@gmu.edu klaus.baumer@telekom.dbp.de sidou@eurecom.fr corpcom@osf.org sig-dsm@doc.imperial.ac.uk cost237-transport@comp.lancs.ac.uk klynch@cmp.com sig11@roses.stanford.edu courtiat@laas.fr sigmedia@bellcore.com kmiller@businessweek.com simon@blah.com knecht@mvuss.att.com cousin@irisa.fr simon@cui.unige.ch craig@bbn.com simon@vsat.demon.co.uk kseo@bbn.com crblackman@cityscape.co.uk sjefred@orapp.no kusaura@krsun.nslab.ntt.jp smarty@hol.gr labetoul@eurecom.fr smds@cnri.reston.va.us ctc-members@redbank.tinac.com lanworks@delphi.com larryg@arch4.att.com cybsys-l@bingvmb.cc.binghamton.edu smithma@mcgraw-hill.com larsendg@mcgraw-hill.com laura.cerchio@cselt.stet.it d.frazier@cablelabs.com danny-briere@telechoice.com snmp@psi.com david@icompub.demon.co.uk snmsigl@nemo.ncsl.nist.gov sofia@idg.se DCrosby@VTRLMEL1.TRL.OZ.AU sound@acm.org lawendel@micronet.it declank@cartermill.com ssaunders@mcgraw-hill.com dgreenfield@mcgraw-hill.com staples@bnr.ca lbmoniz@telepac.pt   Received: from ietf.org by ietf.org id aa24277; 4 Nov 96 18:32 EST Received: from cnri by ietf.org id aa24186; 4 Nov 96 18:30 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa25472; 4 Nov 96 18:30 EST Received: from ruebert.ieee.org by venera.isi.edu (5.65c/5.61+local-25) id ; Mon, 4 Nov 1996 15:29:05 -0800 Received: (from daemon@localhost) by ruebert.ieee.org (8.7.5/8.7.3) id SAA26693; Mon, 4 Nov 1996 18:31:29 -0500 (EST) Date: Mon, 4 Nov 1996 18:31:29 -0500 (EST) Message-Id: <199611042331.SAA26693@ruebert.ieee.org> To: ietf@isi.edu Sender:ietf-request@ietf.org From: majordomo@majordomo.ieee.org Subject: Majordomo results Reply-To: majordomo@majordomo.ieee.org Precedence: bulk Organization: IEEE Service Center, Piscataway, NJ Source-Info: From (or Sender) name not authenticated. -- >>>> unsubscribe comsoc-conferences ietf@isi.edu **** unsubscribe: 'ietf@isi.edu' is not a member of list 'comsoc-conferences'.   Received: from ietf.org by ietf.org id aa28407; 4 Nov 96 21:59 EST Received: from cnri by ietf.org id aa28270; 4 Nov 96 21:51 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa28904; 4 Nov 96 21:51 EST Received: from dworkin.wustl.edu by venera.isi.edu (5.65c/5.61+local-25) id ; Mon, 4 Nov 1996 18:50:41 -0800 Received: (from milind@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA05570; Mon, 4 Nov 1996 20:48:59 -0600 Date: Mon, 4 Nov 1996 20:48:59 -0600 Sender:ietf-request@ietf.org From: "Milind M. Buddhikot" Message-Id: <199611050248.UAA05570@dworkin.wustl.edu> To: BM-List1@cs.ucdavis.edu, giga@tele.pitt.edu, announcements.chi@xerox.com, arl@arl.wustl.edu, atm@bbn.com, ccrc@dworkin.wustl.edu, cgs@mit.edu, cip@bbn.com, commsoft@cc.bellcore.com, comsoc-gicb@ieee.org, end2end-interest@isi.edu, ftroup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, hipparch@sophia.inria.fr, icad-request@santafe.edu, ietf@isi.edu, iplpdn@CNRI.Reston.VA.US, ir-l%uccvma.bitnet@cunyvm.cuny.edu, isadsoc@fokus.gmd.de, enternet@bbn.com, klaus@informatik.rwth.aachen.de, prs@masi.ibp.fr, rem-conf-request@es.net, reres@laas.fr, s-comput%tcsvm.BITNET@wugate.wustl.edu, sig11@roses.stanford.edu, sigmedia@bellcore.com, simon@cui.unige.ch, sip-request@catarina.usc.edu, smds@CNRI.Reston.VA.US, sound@acm.org, tccc@cs.umass.edu, tcplw@bsdi.com, tf-mm@i4serv.informatik.rwth.aachen.de, uist.chi@xerox.com, wittig@vnet.ibm.com, osimcast@bbn.com, ieeetcpc@ccvm.sunysb.edu, comsoc.tac@tab.ieee.org Subject: CFP for NOSSDAV97 Source-Info: From (or Sender) name not authenticated. Hi: Enclosed please find a Call-for-Papers (CFP) for the 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video to be held in St. Louis, Missouri (USA) from May 19-21, 1997. Please feel free to circulate the CFP by any means you deem appropriate. Also, please excuse any multiple copies of this CFP you may receive due to your memberships in multiple mailing lists. Thanks and regards. Milind ***************************************************************************** * * * NOSSDAV'97 * * * * Call-for-Papers * * * * * * The 7th International Workshop on Network and Operating System * * Support for Digital Audio and Video (NOSSDAV 97) * * * * URL: http://www.arl.wustl.edu/NOSSDAV97/nossdav.html * * * * May 19 - 21 1997 * * * * Hosted by: * * The Applied Research Laboratory * * Department of Computer Science * * Washington University in St. Louis, Missouri * * * * Sponsored by IEEE Communications Society * * In cooperation with ACM SIGCOMM and SIGMM * ****************************************************************************** Objectives The 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 97) is the international workshop concerned with state of the art technology in networking and operating system support for multimedia systems. For seven years, NOSSDAV has proven to be an outstanding forum for researchers involved in building innovative multimedia systems, networks and applications on both the research and industrial front. Other topics that will be examined include "middleware" for multimedia, media toolkits, mobile communications, Virtual Reality (VR), real-time systems, software agents, digital libraries, and other digital media besides audio and video. A key aspect of the workshop is that it provides extensive discussion periods during which attendees can informally discuss their current work and future research directions. Traditionally, NOSSDAV has emphasized on high quality experimental research that prototypes systems to explore innovative solutions to the problems in the diverse areas of multimedia computing. NOSSDAV97 will continue this tradition. Relevant topics for the workshop include: * APIs and Continuous Media (CM) programming abstractions for multimedia * Cell-based system architectures * Communication protocols for multimedia * Distributed multimedia systems * End-to-end admission control * High-speed/ATM networks * Micro-kernel and OS support for real-time communications * Mobile multimedia systems * Multicast protocols and media scaling * Multimedia network interfaces * Multimedia-oriented desk, local and wide area networks * Multimedia and the Internet * Multimedia storage, server, and I/O architectures * Quality of service and synchronization frameworks * Resource management and reservation in the OS and network * Software agents for multimedia systems * TV set-top device communication * VOD system architecture * VR systems * Workstation and PDA architectures for multimedia Submissions Two types of submissions are solicited: position papers and research papers. For the purpose of paper review, position papers are restricted to three single-spaced pages. Research papers are restricted to an extended abstract no longer than five formatted postscript pages. To complete your submission, please send the following items by electronic mail to NOSSDAV97@arl.wustl.edu (1) The research or position paper in POSTSCRIPT form. (2) The title of the paper, a list of authors with complete contact information in the form of email address and phone number, and an abstract summarizing the paper in PLAIN TEXT. Only if electronic submission is impossible, papers may be sent to the following mailing address. Dr. Gurudatta M. Parulkar ATTN: NOSSDAV 97 Washington University Department of Computer Science Applied Research Laboratory Campus Box 1045 St. Louis, Missouri 63130 USA The paper abstracts will be circulated among the NOSSDAV97 program committee members to solicit reviewers. Please note that the proceedings of the workshop will be published as a book by Springer-Verlag and the best papers will be forwarded to selected journals for publication. Important Dates Submission Deadline: 15 January 1997 (A FIRM DEADLINE) Acceptance Notification: 15 March 1997 Final Paper Due: 15 April 1997 (A FIRM DEADLINE) Workshop: 19 - 21 May 1997 Program Chair Dr. Gurudatta M. Parulkar Director, Applied Research Lab Department of Computer Science Washington University, St. Louis MO. USA guru@arl.wustl.edu, TEL: (314) 935-7534 Local Arrangements Chair John D. DeHart Senior Research Associate, Applied Research Lab Department of Computer Science Washington University, St. Louis MO. USA jdd@arl.wustl.edu, TEL: (314) 935-7534 Other Correspondance: NOSSDAV97@arl.wustl.edu TEL: (314) 935-7534 Program Committee Andrew T. Campbell, Columbia University Domenico Ferrari, Universita` Cattolica, Italy Kevin Jeffay, Univ of North Carolina Mike Jones, Microsoft, Inc. Chuck Kalmanek, AT&T Research S. Keshav, Cornell University Jim Kurose, University of Masachusetts Monica Lam, Stanford University Ian Leslie, Cambridge University, UK Tom Little, Boston University Derek McAuley, University of Glasgow, UK Steve McCanne, Univ of California, Berkeley A. Desai Narasimhalu, National University of Singapore Gerald Neufeld, Univ of British Columbia, Canada Duane Northcutt, Sun Microsystems Joe Pasquale, Univ of California, San Diego Bernhard Plattner, ETH, Zurich Steve Pink, SICS, Sweden P Venkat Rangan, Univ of California, San Diego KK Ramakrishnan, AT&T Research Henning Schulzrinne, Columbia University Brian Smith, Cornell University Doug Shepherd, University of Lancaster, UK Ralf Steinmetz, University of Darmstadt, Germany James Sterbenz, GTE Dan Swinehart, Xerox PARC Harrick Vin, Univ of Texas, Austin Raj Yavatkar, Intel Radu Popescue-Zeletin, GMD FOKUS, Germany Hui Zhang, CMU Publicity Chair Milind M. Buddhikot Graduate Research Assistant Department of Computer Science Washington University, St. Louis MO, USA milind@dworkin.wustl.edu TELE (314) 935 4302 Publications Chair Vykky A. Klingenberg Technical Assistant, Applied Research Laboratory Department of Computer Science Washington University, St. Louis MO, USA vykky@arl.wustl.edu TELE (314) 935 7534 LOCATION As is traditional, the workshop will take place at an elite resort, away from the hustle and bustle of daily life. Innsbrook Estates Executive Conference Center is located on 3,200 acres of the most gorgeous rolling Missouri woodland, dotted by crystal clear lakes. For accommodations, there are 1, 2, and 3-bedroom condominiums which are fully equipped with living and dining areas, fireplaces, cable television and kitchens to offer conferees all the comforts of home in a lakeside or wooded hideaway. You want to relax after a day of lectures? There is an eighteen hole golf-course, a junior-olympic swimming pool, lighted tennis courts, mini-fitness center with a sauna and hot tub, softball, volleyball, horseback riding, miniature golf course, fishing, lake swimming, canoeing, and sailing, just to name a few of the amenities. A relaxing excursion to a scenic location away from the conference site is also being planned.   Received: from ietf.org by ietf.org id aa11823; 5 Nov 96 6:29 EST Received: from cnri by ietf.org id aa11458; 5 Nov 96 6:18 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa06828; 5 Nov 96 6:18 EST Received: from MAILBOX.ADM.RL.AF.MIL by venera.isi.edu (5.65c/5.61+local-25) id ; Tue, 5 Nov 1996 03:17:28 -0800 Received: from shaggy (SHAGGY.C3D.RL.AF.MIL [128.132.39.57]) by mailbox.adm.rl.af.mil (8.7.6/8.7.6) with SMTP id GAA11875 for ; Tue, 5 Nov 1996 06:18:43 -0500 (EST) Message-Id: Read-Receipt-To: Chester "J." Maciag Priority: Normal To: ietf@isi.edu Reply-To: maciagc@rl.af.mil Mime-Version: 1.0 Sender:ietf-request@ietf.org From: "Chester J. Maciag" Date: Tue, 05 Nov 96 07:20:50 EST Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. unsubscribe comsoc-conferences ietf@isi.edu ----------------------------------------------------------------------- Chester J. Maciag Network Security Engineer Rome Laboratory Communication Networks Branch 525 Brooks Rd, Rome NY 13441 (315) 330-1875 DSN 587-1875 FAX: (315) 330-8012 or (315) 330-7137   Received: from ietf.org by ietf.org id aa13294; 5 Nov 96 7:56 EST Received: from mail.cno.com.br by ietf.org id aa13099; 5 Nov 96 7:53 EST Received: by mail.cno.com.br (AIX 3.2/UCB 5.64/4.03) id AA18006; Tue, 5 Nov 1996 10:52:18 -0400 Received: from unknown(10.1.0.25) by mail.cno.com.br via smap (V1.3) id sma019027; Tue Nov 5 10:52:00 1996 Received: from canario.dpabr.cno.com.br by dsbr01.dpabr.cno.com.br (AIX 3.2/UCB 5.64/4.03) id AA42029; Tue, 5 Nov 1996 09:52:05 -0400 Message-Id: In-Reply-To: <"josef.ifi..123:04.10.96.09.01.51"@ifi.unizh.ch> References: Conversation <199611012236.OAA09605@servo.qualcomm.com> with last message <"josef.ifi..123:04.10.96.09.01.51"@ifi.unizh.ch> Priority: Normal To: ietf@ietf.org Mime-Version: 1.0 Sender:ietf-request@ietf.org From: Luiz Sergio Canario Subject: Re: English is it -> was: Re: The cartel begins to crumble? Date: Tue, 05 Nov 96 10:54:44 EST Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Phil Karn wrote: >The IETF is an English-speaking, US-centric organization because the >Internet originated in the US. Definitely not so for "English-speaking"! English is the major language in business, in science, in diplomacy, and so on. The Internet is no exception at all. Regards,Martin. As a no English-speaking and not an American at all, I am feeling excluded of all the discussion around Iternet. May be we, no english-speaking and no Americans, should found another mail-list to discuss our point of views about Internet. Or maybe we should, each one of us, use our native language. Sory for my english, but unfortunely I am not an English-speaking nor an American. Luiz Sergio Canario   Received: from ietf.org by ietf.org id aa14486; 5 Nov 96 8:23 EST Received: from ns.aic.net by ietf.org id aa13926; 5 Nov 96 8:20 EST Received: by aic.net (8.7.3/8.7.3) id QAA10529; Tue, 5 Nov 1996 16:14:44 +0300 (GMT) Message-Id: <199611051314.QAA10529@aic.net> Subject: Re: English is it -> was: Re: The cartel begins to crumble? To: Luiz Sergio Canario Date: Tue, 5 Nov 1996 16:14:43 +0300 (GMT) Cc: ietf@ietf.org In-Reply-To: from "Luiz Sergio Canario" at Nov 5, 96 10:54:44 am Sender:ietf-request@ietf.org From: edd@acm.org Reply-To: edd@amnic.net Organization: AM Network Information Center @ AIC Network Operations X-Tel: +37 42 28 14 25 X-FAX: +37 42 28 50 82 X-InterNIC-ID: ET22 Content-Type: text Source-Info: From (or Sender) name not authenticated. > As a no English-speaking and not an American at all, I am feeling > excluded of all the discussion around Iternet. May be we, no > english-speaking and no Americans, should found another mail-list to > discuss our point of views about Internet. > Or maybe we should, each one of us, use our native language. Well, I can't agree. Internet and 99% of associated "things" originated in the US. In fact, 90% of the Internet is in the U.S.A. These facts are enough - the official language of the Internet IS the English language. This is fact. > Sory for my english, but unfortunely I am not an English-speaking nor > an American. Nor I am American nor English is my native language. Even my alphabet isn't latin. But it doesn't matter. The point here is to understand that the English is the language of the Internet and associated WG's. Of course we (you and me) are free to use our mother tongues where it IS appropriate... After all, English is relatively easy to learn language (compared to others)... Just my 2c, -edd -- Edgar der Danieliantz, edd@acm.org AM Hostmaster / Armenia NIC   Received: from ietf.org by ietf.org id aa17315; 5 Nov 96 9:32 EST Received: from luggage.tecc.co.uk by ietf.org id aa16973; 5 Nov 96 9:28 EST Received: from auntie.bbcnc.org.uk by luggage.tecc.co.uk id aa16234; 5 Nov 96 14:24 GMT To: ietf@ietf.org Subject: Re: English is it -> was: Re: The cartel begins to crumble? In-reply-to: Your message of "Tue, 05 Nov 1996 10:54:44 EST." Date: Tue, 05 Nov 1996 14:24:35 +0000 Sender:ietf-request@ietf.org From: Gordon Joly Message-ID: <9611051424.aa16234@luggage.tecc.co.uk> Source-Info: From (or Sender) name not authenticated. According to today's Guardian, published in the UK (London and Manchester 96/11/05, G2, page 2, "Brain Storms" by Victor Keegan); "Information overload is an English disease, or rather a disease in English. Sixty percent of all radio broadcasts, 70 per cent of addressed mail and 85 per cent of all international telephone calls (and 80 per cent of data transfers) are in English" I would assume that all figures are global rather than local to Europe. Gordon Joly. -- Gordon.Joly@bbc.co.uk http://www.bbc.co.uk/ +44 181 752 5454 BBC Multimedia Centre, G374, 201 Wood Lane, LONDON W12 7TS   Received: from ietf.org by ietf.org id aa18216; 5 Nov 96 9:43 EST Received: from sibyl.intellinet.com by ietf.org id aa17907; 5 Nov 96 9:41 EST Received: from intellinet.intellinet.com (mars.intellinet.com [204.182.227.16]) by intellinet.com (8.6.12/8.6.9) with SMTP id IAA12569; Tue, 5 Nov 1996 08:40:59 -0600 Message-Id: <2.2.32.19961105134359.0073caa8@pop.intellinet.com> X-Sender: ads@pop.intellinet.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 08:43:59 -0500 To: ietf@ietf.org Sender:ietf-request@ietf.org From: Amoja Sumler Subject: Re: Welcome to comsoc-conferences (fwd) Cc: majordomo@majordomo.ieee.org Source-Info: From (or Sender) name not authenticated. unsubscribe comsoc-conferences ietf-announce@cnri.reston.va.us end Amoja Danekal Sumler TCP/IP Consultant (Internet Overlord) Intellinet ___ _ _ _ _ _ ____ _ |_ _|_ __ | |_ ___| | (_)_ __ ___| |_ | _ \ _ _| | ___ ___ | || '_ \| __/ _ \ | | | '_ \ / _ \ __| | |_) | | | | |/ _ \/ __| | || | | | || __/ | | | | | | __/ |_ | _ <| |_| | | __/\__ \ |___|_| |_|\__\___|_|_|_|_| |_|\___|\__| |_| \_\\__,_|_|\___||___/ http://www.intellinet.com/~ads/ Member of P.O.E. SUPPORT THE SHAPINGS!!   Received: from ietf.org by ietf.org id aa19501; 5 Nov 96 9:48 EST Received: from dragonfly.cisco.com by ietf.org id aa19212; 5 Nov 96 9:47 EST Received: from groeck-pc.cisco.com (groeck-pc.cisco.com [171.69.28.33]) by dragonfly.cisco.com (8.6.12/8.6.5) with SMTP id GAA07228; Tue, 5 Nov 1996 06:46:09 -0800 Message-Id: <2.2.32.19961105144734.008b35a0@dragonfly.cisco.com> X-Sender: groeck@dragonfly.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 06:47:34 -0800 To: Gordon Joly Sender:ietf-request@ietf.org From: Guenter Roeck Subject: Re: English is it -> was: Re: The cartel begins to crumble? Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. Would it eventually be possible to stop this mail thread, or at least move to another list ? Thanks, Guenter At 02:24 PM 11/5/96 +0000, Gordon Joly wrote: > >According to today's Guardian, published in the UK (London and >Manchester 96/11/05, G2, page 2, "Brain Storms" by Victor Keegan); > >"Information overload is an English disease, or rather a disease in >English. Sixty percent of all radio broadcasts, 70 per cent of >addressed mail and 85 per cent of all international telephone calls >(and 80 per cent of data transfers) are in English" > >I would assume that all figures are global rather than local to >Europe. > >Gordon Joly. > >-- >Gordon.Joly@bbc.co.uk http://www.bbc.co.uk/ +44 181 752 5454 >BBC Multimedia Centre, G374, 201 Wood Lane, LONDON W12 7TS > >   Received: from ietf.org by ietf.org id aa20075; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa19504; 5 Nov 96 9:48 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mboned@ns.uoregon.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mboned-admin-ip-space-00.txt Date: Tue, 05 Nov 1996 09:48:25 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050948.aa19504@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF. Title : Administratively Scoped IP Multicast Author(s) : D. Meyer Filename : draft-ietf-mboned-admin-ip-space-00.txt Pages : 2 Date : 11/04/1996 This document defines the "administratively scoped IP multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operational Requirements area of the Internet Engineering Task Force. Submit comments to or the author. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mboned-admin-ip-space-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-admin-ip-space-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mboned-admin-ip-space-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104143933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mboned-admin-ip-space-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mboned-admin-ip-space-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104143933.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19968; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa19155; 5 Nov 96 9:47 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-freed-charset-reg-01.txt Date: Tue, 05 Nov 1996 09:47:13 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050947.aa19155@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Character Set Registration Procedures Author(s) : N. Freed, J. Postel Filename : draft-freed-charset-reg-01.txt Pages : 10 Date : 11/04/1996 MIME [RFC MIME-IMB, RFC MIME-IMT, RFC MIME-HEADERS] and various other modern Internet protocols are capable of using many different character sets. This in turn means that the ability to label different character sets is essential. This registration procedure exists solely to associate a specific name or names with a given character set and to give an indication of whether or not a given character set can be used in MIME text objects. In particular, the general applicability and appropriateness of a given registered character set is a protocol issue, not a registration issue, and is not dealt with by this registration procedure. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-freed-charset-reg-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-freed-charset-reg-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-freed-charset-reg-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104143146.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-freed-charset-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-freed-charset-reg-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104143146.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19797; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa17813; 5 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mhtml@segate.sunet.se Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mhtml-spec-05.txt Date: Tue, 05 Nov 1996 09:40:30 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050940.aa17813@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) Author(s) : J. Palme, A. Hopman Filename : draft-ietf-mhtml-spec-05.txt Pages : 15 Date : 11/04/1996 Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate using HTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content-Location" and "Content-Base". Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-spec-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-spec-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-spec-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104110143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-spec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-spec-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104110143.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19819; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa17972; 5 Nov 96 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-transition-00.txt Date: Tue, 05 Nov 1996 09:42:16 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050942.aa17972@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : Classical IP to NHRP Transition Author(s) : J. Luciani Filename : draft-ietf-ion-transition-00.txt Pages : 5 Date : 11/04/1996 This document describes methods and procedures for the graceful transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over ATM. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-transition-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-transition-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-transition-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104112348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-transition-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-transition-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104112348.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19838; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa17780; 5 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zigmond-media-url-00.txt Date: Tue, 05 Nov 1996 09:40:25 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050940.aa17780@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Uniform Resource Locators for Television and Telephony Author(s) : D. Zigmond Filename : draft-zigmond-media-url-00.txt Pages : 3 Date : 11/04/1996 World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as televisions and both cellular and wireline telephones. On these devices, some of the URL schemes described in [1] are inappropriate. For example, many of these devices lack local storage, so the "file" scheme is of little use. However, these devices usually have access to other sources of information, such as television broadcasts and voice telephone services. This draft proposes three new URL schemes for accessing such information on appropriate devices. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zigmond-media-url-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-zigmond-media-url-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-zigmond-media-url-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104104400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zigmond-media-url-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zigmond-media-url-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104104400.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19821; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa17796; 5 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mhtml@segate.sunet.se Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mhtml-info-05.txt Date: Tue, 05 Nov 1996 09:40:27 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050940.aa17796@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : Sending HTML in E-mail, an informational supplement to RFC ???: MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML) Author(s) : J. Palme Filename : draft-ietf-mhtml-info-05.txt Pages : 11 Date : 11/04/1996 The memo "MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)" (draft-ietf-mhtml-spec-05.txt) specifies how to send packaged aggregate HTML objects in MIME e-mail. This memo is an accompanying informational document, intended to be an aid to developers. This document is not an Internet standard. Issues discussed are implementation methods, caching strategies, problems with rewriting of URIs, making messages suitable both for mailers which can and which cannot handle Multipart/related and handling recipients which do not have full Internet connectivity. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-info-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-info-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-info-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104105833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-info-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-info-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104105833.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19802; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa18607; 5 Nov 96 9:45 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-dawson-csp-00.txt Date: Tue, 05 Nov 1996 09:45:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050945.aa18607@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIME Calendaring and Scheduling Content Type Profile Author(s) : F. Dawson Filename : draft-dawson-csp-00.txt Pages : 61 Date : 11/04/1996 The use of mail enabled applications such as calendaring and scheduling has grown considerably in the last decade. Enterprise and inter-enterprise business has become dependent on rapid scheduling of events and actions using this information technology. The store-and-forward characteristic of electronic messaging technologies has been shown to be complementary to the asynchronous nature of group communications. However, the longer term growth of mail enabled applications, such as calendaring and scheduling, is currently limited by the lack of Internet standards for the message content types that these groupware applications are based on. This specification is intended to progress the level of interoperability possible between dissimilar calendaring and scheduling applications that communicate using an SMTP or MIME transport. This specification defines a usage profile for the MIME Calendaring and Scheduling Content Type [MIME-CAL]. Any MIME based calendaring and scheduling application that supports this MIME Calendaring and Scheduling Content Type profile will be able to interoperate with other MIME based calendaring and scheduling applications using a broad range of scheduling functions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dawson-csp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-dawson-csp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-dawson-csp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104115138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dawson-csp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-dawson-csp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104115138.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19993; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa19186; 5 Nov 96 9:47 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: madman@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-madman-nsm-mib-03.txt Date: Tue, 05 Nov 1996 09:47:19 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050947.aa19186@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mail and Directory Management Working Group of the IETF. Title : Network Services Monitoring MIB Author(s) : N. Freed Filename : draft-ietf-madman-nsm-mib-03.txt Pages : 22 Date : 11/04/1996 A networked application is a realization of some well defined service on one or more host computers that is accessible via some network, uses some network for its internal operations, or both. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-madman-nsm-mib-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-madman-nsm-mib-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-madman-nsm-mib-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104143440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-madman-nsm-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-madman-nsm-mib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104143440.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa20092; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa19599; 5 Nov 96 9:48 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-harrington-ngtrans-v4comp-00.txt Date: Tue, 05 Nov 1996 09:48:48 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050948.aa19599@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Limiting the role of IPv4-compatible Addresses in IPv6 Author(s) : D. Harrington Filename : draft-harrington-ngtrans-v4comp-00.txt Pages : 7 Date : 11/04/1996 This draft presents a proposal to limit IPv4-compatible IPv6 addresses to tunnelling interfaces in the transition from IPv4 to IPv6. The reasons and context for restricting the usage in this manner will be presented. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-harrington-ngtrans-v4comp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-harrington-ngtrans-v4comp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-harrington-ngtrans-v4comp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104161257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-harrington-ngtrans-v4comp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-harrington-ngtrans-v4comp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104161257.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19841; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa18589; 5 Nov 96 9:45 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-dawson-csct-00.txt Date: Tue, 05 Nov 1996 09:45:09 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050945.aa18589@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIME Calendaring and Scheduling Content Type Author(s) : F. Dawson Filename : draft-dawson-csct-00.txt Pages : 68 Date : 11/04/1996 There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This document has been defined to provide the a definition of a MIME message format for openly exchanging calendaring and scheduling information across the Internet. This memo is meant to serve as the basis for registration of such a MIME media type per [RFC1521]. The proposed media type value is "TEXT/CALENDAR". This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below. This MIME media type provides a standard content type for capturing calendar event and todo information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems or using HTTP. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dawson-csct-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-dawson-csct-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-dawson-csct-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104114347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dawson-csct-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-dawson-csct-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104114347.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19782; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa17737; 5 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: int-serv@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-intserv-guaranteed-mib-01.txt Date: Tue, 05 Nov 1996 09:38:58 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050938.aa17737@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Services Working Group of the IETF. Title : Integrated Services Management Information Base Guaranteed Service Extensions Author(s) : F. Baker Filename : draft-ietf-intserv-guaranteed-mib-01.txt Pages : 14 Date : 11/04/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-intserv-guaranteed-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-guaranteed-mib-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104103014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-intserv-guaranteed-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104103014.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19791; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa17948; 5 Nov 96 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-3des-md5-00.txt Date: Tue, 05 Nov 1996 09:42:11 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050942.aa17948@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Combined 3DES-CBC, HMAC and Replay Prevention Security Transform Author(s) : N. Doraswamy Filename : draft-ietf-ipsec-esp-3des-md5-00.txt Pages : 13 Date : 11/04/1996 This draft describes a combination of privacy, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. [IB93] [IBK93] Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-3des-md5-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104110923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-3des-md5-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104110923.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19814; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa18002; 5 Nov 96 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-abela-ulm-00.txt Date: Tue, 05 Nov 1996 09:42:21 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050942.aa18002@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Universal Format for Logger Messages Author(s) : J. Abela Filename : draft-abela-ulm-00.txt Pages : 7 Date : 11/04/1996 This document presents a format to describe system events for logging purpose. Some of the features presented here are in use with the common syslog facility, but most of them are lost in the crowd of syslog format freedom. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-abela-ulm-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-abela-ulm-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-abela-ulm-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104113231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-abela-ulm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-abela-ulm-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104113231.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19785; 5 Nov 96 9:51 EST Received: from localhost by ietf.org id aa18634; 5 Nov 96 9:45 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: namedroppers@internic.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsind-2ndry-04.txt Date: Tue, 05 Nov 1996 09:45:18 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050945.aa18634@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS IXFR, Notification, and Dynamic Update Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Selection and Operation of Secondary DNS Servers Author(s) : R. Elz, R. Bush, S. Bradner, M. Patton Filename : draft-ietf-dnsind-2ndry-04.txt Pages : 12 Date : 11/04/1996 The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. Both the physical and topological location of each server are material considerations when selecting secondary servers. The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsind-2ndry-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-2ndry-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnsind-2ndry-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104134302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsind-2ndry-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsind-2ndry-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104134302.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa21150; 5 Nov 96 9:54 EST Received: from localhost by ietf.org id aa17713; 5 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-mib-03.txt Date: Tue, 05 Nov 1996 09:38:51 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050938.aa17713@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : RSVP Management Information Base Author(s) : F. Baker, J. Krawczyk Filename : draft-ietf-rsvp-mib-03.txt Pages : 73 Date : 11/04/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-mib-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-mib-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-mib-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104102505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-mib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104102505.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa21234; 5 Nov 96 9:54 EST Received: from server.txport.com by ietf.org id aa20711; 5 Nov 96 9:53 EST Received: from j_oyarbide.txport.com by txport.com (4.1/SMI-4.1) id AA04407; Tue, 5 Nov 96 08:52:39 CST Received: by j_oyarbide.txport.com with Microsoft Mail id <01BBCAFF.17345F00@j_oyarbide.txport.com>; Tue, 5 Nov 1996 09:52:43 -0500 Message-Id: <01BBCAFF.17345F00@j_oyarbide.txport.com> Sender:ietf-request@ietf.org From: Jorge Alejandro Oyarbide To: Luiz Sergio Canario Cc: "ietf@ietf.org" Subject: RE: NON SENSE. English is the best language for this.... Date: Tue, 5 Nov 1996 09:52:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Source-Info: From (or Sender) name not authenticated. I disagree completly with those that don`t want English as the language = for discussing these issues... I`m not an american in fact I come from = El Salvador ( now Canadian ),and I consider that English is the best = language for discussion. Is impossible to make global discussions in all = the different languages that exist in the world; there allways be some = body saying I speak Chinese or Japanese or Spanish, or else an of course = it will be better for them to doit in their language but how far can = that go.... and what about the others that don`t speak those languages. Is common sense... what you want, a 1000 different discussion groups = and a huge central office translating what ever they concluded ?. Please = don't be ridiculous. Please land and be realistic and stop this Non = Sense. English is international an most countries speak it. That is not the = case for the other langauges. If it was then this topic could have some = sense. Ps.. this is my personal opinion an not my company`s... :) Bye... ---------- De :edd@acm.org[SMTP:edd@acm.org] Date d'envoi=A0:mardi 5 novembre 1996 11:14 A=A0:Luiz Sergio Canario Cc=A0:ietf@ietf.org Objet=A0:Re: English is it -> was: Re: The cartel begins to crumble? > As a no English-speaking and not an American at all, I am feeling=20 > excluded of all the discussion around Iternet. May be we, no=20 > english-speaking and no Americans, should found another mail-list to=20 > discuss our point of views about Internet.=20 > Or maybe we should, each one of us, use our native language. Well, I can't agree. Internet and 99% of associated "things" originated in the US. In fact, 90% of the Internet is in the U.S.A. These facts are enough - the official language of the Internet=20 IS the English language. This is fact. > Sory for my english, but unfortunely I am not an English-speaking nor=20 > an American. Nor I am American nor English is my native language. Even my alphabet = isn't latin. But it doesn't matter. The point here is to understand that the English is the language of the Internet and associated WG's. Of course we (you and me) are free to use our mother tongues where it IS = appropriate... After all, English is relatively easy to learn language (compared to = others)... Just my 2c, -edd -- Edgar der Danieliantz, edd@acm.org AM Hostmaster / Armenia NIC   Received: from ietf.org by ietf.org id aa21854; 5 Nov 96 9:59 EST Received: from localhost by ietf.org id aa17725; 5 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: int-serv@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-intserv-mib-03.txt Date: Tue, 05 Nov 1996 09:38:54 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050938.aa17725@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Services Working Group of the IETF. Title : Integrated Services Management Information Base Author(s) : F. Baker, J. Krawczyk Filename : draft-ietf-intserv-mib-03.txt Pages : 12 Date : 11/04/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-intserv-mib-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-mib-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-intserv-mib-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104102728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-intserv-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-intserv-mib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104102728.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ab21854; 5 Nov 96 9:59 EST Received: from localhost by ietf.org id aa19140; 5 Nov 96 9:47 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-freed-pvcsc-01.txt Date: Tue, 05 Nov 1996 09:47:03 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050947.aa19140@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIME Parameter Value and Encoded Words: Character Sets, Language, and Continuations Author(s) : N. Freed, K. Moore Filename : draft-freed-pvcsc-01.txt Pages : 10 Date : 11/04/1996 This memo defines extensions to the RFC MIME-IMB media type and RFC 1806 disposition parameter value mechanisms to provide (1) a means to specify parameter values in character sets other than US-ASCII, (2) to specify the language to be used should the value be displayed, and (3) a continuation mechanism for long parameter values to avoid problems with header line wrapping. This memo also defines an extension to the encoded words defined in RFC MIME-HEADERS to allow the specification of the language to be used for display as well as the character set. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-freed-pvcsc-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-freed-pvcsc-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-freed-pvcsc-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104135336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-freed-pvcsc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-freed-pvcsc-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104135336.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ac21854; 5 Nov 96 9:59 EST Received: from localhost by ietf.org id aa19577; 5 Nov 96 9:48 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: http-wg@cuckoo.hpl.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-http-state-mgmt-04.txt, .ps Date: Tue, 05 Nov 1996 09:48:42 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611050948.aa19577@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : HTTP State Management Mechanism Author(s) : D. Kristol, L. Montulli Filename : draft-ietf-http-state-mgmt-04.txt, .ps Pages : 19 Date : 11/04/1996 This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set-Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.) Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-http-state-mgmt-04.txt". Or "get draft-ietf-http-state-mgmt-04.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-http-state-mgmt-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-http-state-mgmt-04.txt". Or "FILE /internet-drafts/draft-ietf-http-state-mgmt-04.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104150350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-state-mgmt-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-http-state-mgmt-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104150350.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22618; 5 Nov 96 10:10 EST Received: from localhost by ietf.org id aa22401; 5 Nov 96 10:07 EST To: IETF-Announce: ; cc: mhtml@segate.sunet.se Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 05 Nov 1996 10:07:12 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611051007.aa22401@ietf.org> The IESG has received a request from the MIME Encapsulation of Aggregate HTML Documents Working Group to consider the following three documents for the status of Proposed Standard: 1. MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) 2. Content-ID and Message-ID Uniform Resource Locators 3. The MIME Multipart/Related Content-type 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 18, 1996. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from ietf.org by ietf.org id aa01511; 5 Nov 96 12:33 EST Received: from relay.bt.net by ietf.org id aa01235; 5 Nov 96 12:29 EST Received: from ripley.ukcore.bt.net (actually 194.72.139.129) by relay.bt.net with SMTP (PP); Tue, 5 Nov 1996 16:51:54 +0000 Comments: Authenticated sender is Sender:ietf-request@ietf.org From: Jag Minhas Organization: BTnet Network Operations Centre To: Jorge Alejandro Oyarbide Date: Tue, 5 Nov 1996 16:48:46 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: NON SENSE. English is the best language for this.... Reply-to: jag@bt.net CC: "ietf@ietf.org" Priority: normal X-mailer: Pegasus Mail for Windows (v2.40) Message-ID: <9611051229.aa01235@ietf.org> Source-Info: From (or Sender) name not authenticated. > Well, I can't agree. Internet and 99% of associated "things" > originated in the US. >In fact, 90% of the Internet is in the U.S.A. Really? I wonder how that fact was derived? Best regards - Jag   Received: from ietf.org by ietf.org id aa08136; 5 Nov 96 13:47 EST Received: from server.txport.com by ietf.org id aa08048; 5 Nov 96 13:45 EST Received: from j_oyarbide.txport.com by txport.com (4.1/SMI-4.1) id AA07475; Tue, 5 Nov 96 12:44:05 CST Received: by j_oyarbide.txport.com with Microsoft Mail id <01BBCB1F.6C636AA0@j_oyarbide.txport.com>; Tue, 5 Nov 1996 13:44:10 -0500 Message-Id: <01BBCB1F.6C636AA0@j_oyarbide.txport.com> Sender:ietf-request@ietf.org From: Jorge Alejandro Oyarbide To: "edd@amnic.net" , "'Valdis.Kletnieks@vt.edu'" Cc: "ietf@ietf.org" Subject: RE: English is it -> was: Re: The cartel begins to crumble? Date: Tue, 5 Nov 1996 13:44:09 -0500 Return-Receipt-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Source-Info: From (or Sender) name not authenticated. Do we need an official language ?? Can we just go with common sense ?? ---------- De :Valdis.Kletnieks@vt.edu[SMTP:Valdis.Kletnieks@vt.edu] Date d'envoi=A0:mardi 5 novembre 1996 10:44 A=A0:edd@amnic.net Cc=A0:ietf@ietf.org Objet=A0:Re: English is it -> was: Re: The cartel begins to crumble?=20 On Tue, 05 Nov 1996 16:14:43 +0300, you said: > These facts are enough - the official language of the Internet=20 > IS the English language. This is fact. Umm.. is this "official" official, being codified in an RFC or similar, = or merely a "de facto" official? I ran a quick 'grep -i english *.txt' on a mirror of the RFCs, and although I found a lot of references to "Bill English" as an author, and a lot of references as to how English should be handled in the context of a specific protocol (for instance, there were at least 20 hits against X.400/X.500 RFC's, and a lot against MIME and charset issues), the only reference I found to English as part of the Internet standards process itself was in RFC2026, where the "sample copyright template" talks about translating to languages other than English. English is no more the "official" language of the Internet than Windows 95 is the "official" operating system. No matter *what* Bill Gates wishes were true... --=20 Valdis Kletnieks Computer Systems Engineer Virginia Tech <>   Received: from ietf.org by ietf.org id aa08280; 5 Nov 96 13:48 EST Received: from localhost by ietf.org id aa07876; 5 Nov 96 13:42 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu Sender:ietf-announce-request@ietf.org From: The IESG Subject: Protocol Action: The PPP NetBIOS Frames Control Protocol (NBFCP) to Proposed Standard Date: Tue, 05 Nov 1996 13:41:59 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611051342.aa07876@ietf.org> The IESG has approved the Internet-Draft "The PPP NetBIOS Frames Control Protocol (NBFCP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. Technical Summary Multiple higher-level protocols may operate over PPP links. For a protocol to be carried over a PPP link, a control protocol is required. This control protocol is used to negotiate the operations of that protocol. The PPP NetBIOS Frames Control Protocol is used to configure and control PPP links to carry NetBIOS traffic. Working Group Summary This protocol was developed in the PPPEXT working group. Development was without rancor Protocol Quality The protocol has been reviewed by Frank Kastenholz and Jeff Burgan.   Received: from ietf.org by ietf.org id aa08890; 5 Nov 96 13:56 EST Received: from doorstep.unety.net by ietf.org id aa08790; 5 Nov 96 13:54 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id MAA15186 for ; Tue, 5 Nov 1996 12:48:39 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCB17.EAE3BAE0@webster.unety.net>; Tue, 5 Nov 1996 12:50:26 -0600 Message-ID: <01BBCB17.EAE3BAE0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "'ietf@ietf.org'" Subject: FW: Popular Root Name Servers Date: Tue, 5 Nov 1996 12:50:25 -0600 Encoding: 237 TEXT Source-Info: From (or Sender) name not authenticated. ---------- From:Jim Fleming[SMTP:JimFleming@unety.net.] Sent:Tuesday, November 05, 1996 11:54 AM To:'Multiple recipients of list DOMAIN-POLICY'; 'New Newdom' Cc:'bobm@NIC.DDN.MIL'; 'jamesf@ARL.MIL'; 'koda@ISI.EDU'; 'marcel@NSIPO.NASA.GOV'; 'markk@NETSOL.COM'; 'matti@COMEDIA.SE'; 'paul@VIX.COM'; 'psinet-domain-admin@PSI.COM'; 'sneeri@NI.UMD.EDU' Subject:Popular Root Name Servers To: Vixie, Paul (PV15) paul@VIX.COM Kosters, Mark A. (MAK21) markk@NETSOL.COM Koda, Jim (JK7) koda@ISI.EDU Sneeringer, Gerry (GS307) sneeri@NI.UMD.EDU Fielding, James L. (JLF) jamesf@ARL.MIL Administration, PSINet Domain (PDA4) psinet-domain-admin@PSI.COM Rendahl, Matti [President] (MR164) matti@COMEDIA.SE Schlapfer, Marcel (MS4039) marcel@NSIPO.NASA.GOV McCollum, Robert W. (RM584) bobm@NIC.DDN.MIL Re: Popular Root Name Servers Greetings, As the owners/operators/administrators/etc. of some of the most popular root name servers in the world, you collectively control what top level domains (TLDs) are supported on the global Internet and are "visible" to most of the people. As you may be aware, many people have worked for many months to bring change to the top level domain administration of the Internet. Here are some of the highlights of those changes: 1. The creation/addition of more top level domains. 2. The creation/addition of more commercially supported registries for TLDs, IP addresses, and other Internet resources. 3. The expansion of the root name server base to more areas of the world and to more commercial companies. These changes are essential to help grow the Internet and to assist in transitioning the Internet from a U.S. government funded R&D project to a commercial enterprise that can help the world communicate. As the operators of the popular root name servers, you play a key role in making sure that these transitions are smooth and that people are not allowed to fragment the Internet. I encourage all of you to actively participate in the discussions regarding these transitions. If for any reason you do not feel that your server should be part of this global expansion, then I suggest that you use the open forums for discussion to inform everyone. As with many R&D projects, systems that are used early in the development sometimes outlive their usefulness and there is no easy way for people to transition out of the picture. In my opinion, now is the time to make that transition as other companies transition their servers into the picture. Two of the more popular mailing lists for these discussions have been included on the address. If you know of other more appropriate lists or forums, I hope that you make suggestions. In summary, your servers play a key role in the current Internet Infrastructure. It is important for everyone to fully understand what role they will play in the future to make sure that transitions are smooth and orderly. Your comments are always welcome. Jim Fleming ------------------------------------------------------ SERVER NS.ISC.ORG 192.5.5.241 Internet Software Consortium (ISC) Hostname: F.ROOT-SERVERS.NET Address: 192.5.5.241 System: DEC ALPHA running BIND 4.9.5 Host Administrator: Vixie, Paul (PV15) paul@VIX.COM +1 415 747 0204 Domain Server Record last updated on 09-Oct-96. ------- SERVER NS.INTERNIC.NET 198.41.0.4 Network Solutions, Inc. (NS45-HST) 505 Huntmar Park Drive Herndon, VA 22070 Hostname: A.ROOT-SERVERS.NET Address: 198.41.0.4 System: SUN running SUNOS Host Administrator: Kosters, Mark A. (MAK21) markk@NETSOL.COM (703) 742-4795 (FAX) (703) 742-4811 Record last updated on 31-Aug-95. ------- SERVER NS1.ISI.EDU 128.9.0.107 University of Southern California (ISI2) Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Hostname: B.ROOT-SERVERS.NET Address: 128.9.0.107 System: ? running ? Host Administrator: Koda, Jim (JK7) koda@ISI.EDU 310) 822-1511 Record last updated on 12-Aug-95. ------- SERVER TERP.UMD.EDU 128.8.10.90 University of Maryland (UMD-TERP) Computer Science Center College Park, MD 20742 Hostname: D.ROOT-SERVERS.NET Address: 128.8.10.90 System: MICROVAX-II running UNIX Coordinator: Sneeringer, Gerry (GS307) sneeri@NI.UMD.EDU (301) 405-2996 domain server Record last updated on 12-Aug-95. ------- SERVER AOS.ARL.ARMY.MIL 128.63.2.53 Army Research Laboratory (BRL-AOS) Aberdeen Proving Ground, MD 21005-5066 Hostname: H.ROOT-SERVERS.NET Address: 128.63.2.53 System: SUN running UNIX Host Administrator: Fielding, James L. (JLF) jamesf@ARL.MIL (410)278-8929 (DSN) 298-8929 (410)278-6664 (FAX) (410)278-5077 domain server Record last updated on 17-Aug-95. ------- SERVER C.PSI.NET 192.33.4.12 Performance Systems International Inc. (C-NYSER) Hostname: C.ROOT-SERVERS.NET Address: 192.33.4.12 System: SUN running UNIX Coordinator: Administration, PSINet Domain (PDA4) psinet-domain-admin@PSI.COM (703) 904-4100 domain server Record last updated on 17-Apr-96. ------- SERVER NIC.NORDU.NET 192.36.148.17 [No name] (NORDU) Hostname: I.ROOT-SERVERS.NET Address: 192.36.148.17 System: SUN-4/60 running UNIX Coordinator: Rendahl, Matti [President] (MR164) matti@COMEDIA.SE +46 8 612 49 26 +46 70 533 13 56 (FAX) +46 8 612 49 36 Record last updated on 24-Aug-95. ------- SERVER NS.NASA.GOV 192.203.230.10 Moffett Field (NS-NASA) NASA Ames Research Center, Mail Stop 233-8 Moffett Field, CA 94035-1000 USA Hostname: E.ROOT-SERVERS.NET Address: 192.203.230.10 System: SUN running SUNOS Host Administrator, Coordinator: Schlapfer, Marcel (MS4039) marcel@NSIPO.NASA.GOV 1-415-604-0955 (FAX) 1-415-604-0036 domain server Record last updated on 25-Oct-96. ------- SERVER NS.NIC.DDN.MIL 192.112.36.4 GSI (DIIS-NS) Suite 200 14200 Park Meadow Dr. Chantilly, VA 22021 Hostname: G.ROOT-SERVERS.NET Address: 192.112.36.4 System: SUN running UNIX Coordinator: McCollum, Robert W. (RM584) bobm@NIC.DDN.MIL (703) 802-8476 (FAX) (703) 802-8376 Root Domain Server Record last updated on 18-Aug-95. -------   Received: from ietf.org by ietf.org id aa09768; 5 Nov 96 14:20 EST Received: from zephyr.isi.edu by ietf.org id aa09586; 5 Nov 96 14:14 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 5 Nov 1996 11:13:24 -0800 Message-Id: <199611051913.AA02512@zephyr.isi.edu> To: IETF-Announce: ; Subject: BCP 12, RFC 2050 on Internet Registry IP Allocation Guidelines Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 05 Nov 96 11:13:23 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. BCP 12: RFC 2050: Title: INTERNET REGISTRY IP ALLOCATION GUIDELINES Author: K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel Date: November 1996 Mailbox: kimh@internic.net, markk@internic.net, davidc@APNIC.NET, dfk@RIPE.NET, Postel@ISI.EDU Pages: 13 Characters: 28,975 Updates/Obsoletes: 1466 URL: ftp://ds.internic.net/rfc/rfc2050.txt This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space. This RFC is a product of the CIDR Deployment Working Group of the IETF. IESG Note: By approving this document as a Best Current Practice,the IESG asserts its belief that this policy described herein is an accurate representation of the current practice of the IP address registries with respect to address assignment. This does not constitute endorsement or recommendation of this policy by the IESG. The IESG will reevaluate its approval of this document in December 1997 taking into consideration the results of the discussions that will be take place in the IRE Working Group between now and then. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961105104950.RFC@ISI.EDU> SEND /rfc/rfc2050.txt --OtherAccess Content-Type: Message/External-body; name="rfc2050.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961105104950.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09829; 5 Nov 96 14:21 EST Received: from cnri by ietf.org id aa09720; 5 Nov 96 14:19 EST Received: from verdi.nethelp.no by CNRI.Reston.VA.US id aa17616; 5 Nov 96 14:19 EST Received: (qmail 6493 invoked by uid 1001); 5 Nov 1996 19:17:52 +0000 (GMT) To: ietf@CNRI.Reston.VA.US Subject: RE: NON SENSE. English is the best language for this.... Sender:ietf-request@ietf.org From: sthaug@nethelp.no X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 05 Nov 1996 20:17:51 +0100 Message-ID: <6491.847221471@verdi.nethelp.no> Source-Info: From (or Sender) name not authenticated. > > Well, I can't agree. Internet and 99% of associated "things" > > originated in the US. > > >In fact, 90% of the Internet is in the U.S.A. > > Really? I wonder how that fact was derived? Certainly not by any scientific method. Even if you don't define what 'the Internet' includes, let's take a look at host count statistics. 1. Network Wizards results for the whole Internet, July 1996 (http://www.nw.com/zone/WWW/report.html): 12,881,000 hosts 2. RIPE NCC hostcount for all European top level domains, July 1996 (http://www.ripe.net/): 3,017,784 hosts I'll let people draw their own conclusions. Steinar Haug, Nethelp consulting, sthaug@nethelp.no   Received: from ietf.org by ietf.org id aa10444; 5 Nov 96 14:38 EST Received: from doorstep.unety.net by ietf.org id aa10253; 5 Nov 96 14:33 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id NAA15294; Tue, 5 Nov 1996 13:27:54 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCB1D.674229A0@webster.unety.net>; Tue, 5 Nov 1996 13:29:42 -0600 Message-ID: <01BBCB1D.674229A0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'System Administrator' Cc: "'ietf@ietf.org'" , 'New Newdom' Subject: RE: When? (was Re: NEWDOM: Re: TODO) Date: Tue, 5 Nov 1996 13:29:41 -0600 Encoding: 100 TEXT Source-Info: From (or Sender) name not authenticated. On Tuesday, November 05, 1996 5:47 AM, System Administrator[SMTP:root@Taka.AGN.NET] wrote: @ > @ > Perry, if you can assure me either that the delay will be considerably less @ > than 6 months or that we may have some assurance of being accepted I will @ > gladly shut up and sit patiently. I am not unreasonable on this issue. @ > Given an assurance of being accepted and the proposed date of addition to @ > the root servers will allow us to patiently wait for that day. Until then, @ > we're in limbo, and frankly, that's not a good place to be. Please don't @ > let it get any more out of hand than it already is. @ > @ > Bottom line, we have an operational registry - when can we be placed in the @ > root servers? @ > @ @ Ditto. @ @ We were the first with both USA and EARTH and have had an operational @ registry for 7 months now. @ @ Consider this: If the 6 months time frame is correct, IANA will lose all @ control of this and AlterNic will become the de-facto TLD registry. @ (This is not a bad thing, IMHO) @ @ John @ @ Re: When? (was Re: NEWDOM: Re: TODO) bmanning@ISI.EDU Tue, 5 Nov 1996 08:41:34 -0800 (PST) > > On Mon, 4 Nov 1996, Christopher Ambler wrote: > > Bottom line, we have an operational registry - when can we be placed > > in the root servers? > > No, you have an *experimental* registry. It might never be added to the > root servers. > > --apb (Alan Barrett) > Hi, You will note that the two, "operational" and *experimental* are not mutually exclusive. I get the impression that the biggest hurdle is that folks who are running operational registries presume that this is the only criteria for being injected into the Internet root servers. It clearly is not. For the nonce, the best they can expect is to be placed in the Alternic or the outerInternets root servers. One hopes that the IAHC is able to quickly resolve the process issues and provide guidance on what other critera must be met. --bill ------------------------------------------------------------------------------ To Subscribe or Unsubscribe send e-mail to newdom-request@ar.com with the word 'subscribe' or 'unsubscribe' in the body of your message. A HTML Archive of this list is at http://www.ar.com/lists/newdom/ @@@@@@ People should note carefully that some of the discussion on the OLD newdom does not make it to the NEW newdom and vice versa. This is partly because some people are not allowed to post to the OLD newdom list. This has the effect of making people who *only* read the OLD newdom list think that the discussion that is being held represents an OPEN forum when people know it is not. It is a shame that there is no easy way to alert the readers of the OLD newdom list about the censorship that is going on. If the goal of the list operators is to create a list where only certain people are allowed to speak, why don't they let people know, and then the readers can understand how to interpret the comments made on that list. It is disturbing to find out that governing bodies can draw conclusions about people's views based on one's lack of participation in a process when some of those individuals are not allowed to participate in the process and that is not taken into account. The IETF and other organizations can claim all they want that they are an "open" forum. Maybe a better way to put it would be an open hallway with many closed doors and only certain people have the keys... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa12831; 5 Nov 96 15:04 EST Received: from zephyr.isi.edu by ietf.org id aa12222; 5 Nov 96 14:59 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 5 Nov 1996 10:48:27 -0800 Message-Id: <199611051848.AA00605@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2022 on Multicast over UNI 3.0/3.1 based ATM Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 05 Nov 96 10:48:27 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2022: Title: Support for Multicast over UNI 3.0/3.1 based ATM Networks Author: G. Armitage Date: November 1996 Mailbox: gja@thumper.bellcore.com Pages: 82 Characters: 189,219 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2022.txt Mapping the connectionless IP multicast service over the connection oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task. This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. This RFC is a product of the IP/ATM working group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961105103453.RFC@ISI.EDU> SEND /rfc/rfc2022.txt --OtherAccess Content-Type: Message/External-body; name="rfc2022.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961105103453.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13775; 5 Nov 96 15:17 EST Received: from zephyr.isi.edu by ietf.org id aa13513; 5 Nov 96 15:14 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 5 Nov 1996 12:13:28 -0800 Message-Id: <199611052013.AA07058@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2056 on URLs for Z39.50 Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 05 Nov 96 12:13:27 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2056: Title: Uniform Resource Locators for Z39.50 Author: R. Denenberg, J. Kunze, D. Lynch Date: November 1996 Mailbox: ray@rden.loc.gov, jak@ckm.ucsf.edu, DenisL@SilverPlatter.com Pages: 7 Characters: 14,204 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2056.txt Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. This RFC is a product of the Uniform Resource Identifiers Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961105120210.RFC@ISI.EDU> SEND /rfc/rfc2056.txt --OtherAccess Content-Type: Message/External-body; name="rfc2056.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961105120210.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa18827; 5 Nov 96 16:23 EST Received: from cnri by ietf.org id aa18668; 5 Nov 96 16:19 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa20180; 5 Nov 96 16:19 EST Received: from ruebert.ieee.org by venera.isi.edu (5.65c/5.61+local-25) id ; Tue, 5 Nov 1996 13:18:00 -0800 Received: (from root@localhost) by ruebert.ieee.org (8.7.5/8.7.3) id QAA12359; Tue, 5 Nov 1996 16:18:17 -0500 (EST) Date: Tue, 5 Nov 1996 16:18:17 -0500 (EST) Message-Id: <199611052118.QAA12359@ruebert.ieee.org> Sender:ietf-request@ietf.org From: Communications Society Marketing To: ietf@isi.edu Subject: Apology regarding comsoc-conferences subscriptions Precedence: bulk X-Sender: postmaster@ieee.org X-Loopdetect: postmaster@ieee.org Organization: IEEE Communications Society Source-Info: From (or Sender) name not authenticated. Dear Communications Industry Professional, Please accept our apology for creating a list with your email address on it yesterday. In our attempts to make use of these exciting new technologies, our enthusiasm took us beyond our full understanding of the ramifications of what we were attempting. In a effort to fix the resulting problem, we have removed ALL addresses from this list, including yours. If you are interested in learning about important upcoming IEEE Communications Society events, such as the dates, locations and paper submission details and deadlines, please follow the instructions below to subscribe to this list. In the coming months we will be sending short announcements to you with pointers to Internet locations. There you can get the information you want about IEEE Communications Society events, such as visiting our Conference Calendar listing at http://www.ieee.org/comsoc/confs/ where you can find details on communications industry conferences, workshops and symposia scheduled in the next two years. Again, we're sorry for the messages you received yesterday regarding this list and assure you that, unless YOU subscribe to it, you will not be on it. Thank you, Clark DesSoye, Marketing Manager, IEEE Communications Society Instructions for subscribing to the 'comsoc-conferences' Mailing-List: Simply send an E-Mail message to: majordomo@majordomo.ieee.org containing one of the following lines in the body: subscribe comsoc-conferences -or- subscribe comsoc-conferences e-mail_address The first format will subscribe YOUR e-mail address as it appears in the headers of your message. Use the 2nd format to subscribe an alternate address.   Received: from ietf.org by ietf.org id aa19921; 5 Nov 96 16:46 EST Received: from cnri by ietf.org id ab19791; 5 Nov 96 16:41 EST Received: from thunder.ncr.disa.mil by CNRI.Reston.VA.US id aa20651; 5 Nov 96 16:41 EST Received: from ncr.disa.mil ([164.117.176.106]) by thunder.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id QAA29345; Tue, 5 Nov 1996 16:25:49 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA847240807; Tue, 05 Nov 96 16:34:40 EST Date: Tue, 05 Nov 96 16:34:40 EST Sender:ietf-request@ietf.org From: "C.Joe Pasquariello" Message-Id: <9610058472.AA847240807@ncr.disa.mil> To: ISOC-Advisory-Council@isoc.org Cc: ISOC-Trustees@isoc.org, IETF@CNRI.Reston.VA.US, "ISOC Exec. Dir." Subject: ISOC Advisory Council - Officer Election Announcement Source-Info: From (or Sender) name not authenticated. Greetings to the Council et al ! 'Enclosed' below is: - the proposed schedule and other particulars for filling the two vacant officer positions on the ISOC Advisory Council, and - a copy of the current Advisory Council mail list. In view of the recent issuance of the RFC on ISOC/IETF Relationships, I am copying the IETF list - for your information - and also with the view of identifying any possible additional nominees. An Advisory Council meeting is planned for Thursday PM of the IETF meeting week - prior to the IETF Plenary. The meeting will be open to any interested IETFers. cheers, C.Joe P--> Chair, ISOC Advisory Council ------------------------------------- |Camillo J. PASQUARIELLO, SES | |Associate Director | |US/DoD/DISA/Center for Standards | |10701 Parkridge Blvd | |Reston, VA 20191-4357 | |Tel: (703) 735-3305 | |FAX: (703) 735-3255 | |EMail: PasquarC@ncr.disa.mil | ------------------------------------- NB: 1. This and other documents of the ISOC Advisory Council are posted on the ISOC gopher server at . 2. IF YOU RECEIVE THIS MESSAGE, AND ARE NOT YOUR ORGANIZATION'S PRIMARY REPRESENTATIVE OR ALTERNATE TO ISOC, PLEASE ADVISE - SO WE CAN TAKE ACTION TO KEEP OUR COUNCIL MAILING LIST [cy below] CURRENT. [cc addressees excepted]. THANX! ==================== Election Announcement Follows ===================== Title: ISOC Advisory Council - Election Notice Author: C.Joe PASQUARIELLO Date: 1996.11.05 Body: Advisory Council Document: 96-005 Revision: Basic Supersedes: Status: For comment & execution Maintainer: Council Chair ================================================================= Dear Members of the Advisory Council - As we discussed in Montreal, there are two vacancies for Council Officers to be filled. I am pleased to report that the following members have indicated their willingness to serve. OF COURSE, OTHER NOMINEES WOULD BE WELCOME TOO: - Prof.Dr. Srisakdi Charmonman; Thailand; Assumption University - Micheal E.Conn; USA; MCI Corp. - Ole J. Jacobsen; USA; InterOp Company - Stefano Trumpy; Italy, CNUCE Accordingly we will need conduct an election as we did in 1994, via Email, with weighted voting - two votes per member organization. I propose the following procedure and schedule: - 15 Nov: Nominations closed. Each candidate submit short CV and statement. - 18 Nov: Call for votes by ISOC Staff - 30 Nov: Voting Closed - 02 Dec: ISOC staff announce selections [wk] - 09 Dec: New Officers seated at the December Council and Board of Trustees Meetings As of the December meeting, the Chair will also rotate to Nick Trio, USA; IBM Corp. Without objection, I propose we proceed according to the above. Pls advise if you have comments or suggestions on this, THX & Best Regards, /s/ C.Joe Pasquariello Chair ISOC Advisory Council =================== End Announcement ======================= ============ Council Mailing List A.O. 5 Nov 96 Follows =================== "Bernard Aboba " "James Allard" "Guy Almes" "Robert Anderson (alt.)" "Fred Aronson" "Toshiya Asaba (alt.)" "Cliff Bamford" "Keith Basil" "Andrew Bjerring" "Mark R. Boolootian" "Charles Brownstein" "Martin Burack" "David Cantrell" "Vint Cerf " "Srisakdi Charmonman" "Chris Chaundy" "Steve Cisler" "Michael Clore" "Avi Cohen" "Jim Conklin (alt.)" "Michael Conn" "David Conrad" "Jim Dolgonas (alt.)" "T. Michael Elliott" "Benjamin Epstein" "Francois Fluckiger" "Dave Frederickson " "Ira Fuchs" "Kaye Gapen (alt.)" "Antonia Ghiselli (alt.)" "Bill Godwin (alt.)" "Ben Golding (alt.)" "Masaki Itoh" "Terry Gray" "Frode Greisen (alt.)" "Erik Grimmelmann" "Mark Haas" "Anthony Hearn" "Anita Holmgren" "Steve Holmgren (alt.)" "Ryoichi Hosoya" "Richard Hronicek" "Geoff Huston" "Ole Jacobsen (alt.)" "Ron Johnson (alt.)" "Walter Johnston" "Dr. D. F. Hartley" "Cyndi Jung (alt.)" "Kevin Kahn (alt.)" "Robert Kahn" "Tomaz Kalin (alt.)" "Rafiq Khan (alt.)" "Kenneth King" "Tatsuo Kobayashi (alt.)" "Tracy LaQuey Parker" "Mark Laubach" "Yuet Lee (alt.)" "Stephan Leicht" "Jean Le Mezec" "Bob Lemley" "Donald Lindberg" "Robert Lucky (alt.)" "Richard Mandelbaum" "Olivier Martin (alt.)" "Daniel Masys (alt.)" "Alexander McKenzie" "Klara Mikus (alt.)" "Kees Neggers" "Seppo Noppari (alt.)" "Richard Nuttall" "Jeffrey Ogden (alt.)" "C. Joe Pasquariello" "Adam Peake" "Ole Carsen Pedersen" "Abraham Peled" "Paul Peters" "Richard Pethia" "John Phillips" "Randolph Pitzer (alt.)" "Larry Rapagnani" "Peter Rastl" "Steve Russell" "Nobuo Sakata" "Martin Schoffstall" "William Schrader (alt.)" "Paul Severino (alt.)" "Shawn Sexton " "Ehud Shapiro" "Robert Shaw" "Tony Shaw (alt.)" "W. David Sincoskie" "Hermann Steinringer (alt.)" "Glenn Stewart (alt.)" "Leonard Swatski (alt.)" "Olle Thylander (alt.)" "Nicholas Trio" "Stefano Trumpy" "Klaus Ullmann" "Enzo Valente" "Peter Villemoes" "Hans Wallberg" "Bernie White" "Ray White" "Kanokwan Wongwatanasin (alt.)" "Yoshihiro Yamakowa" ================ End AC Mail List =======================   Received: from ietf.org by ietf.org id aa20523; 5 Nov 96 16:56 EST Received: from po2.glue.umd.edu by ietf.org id aa20237; 5 Nov 96 16:53 EST Received: from bandwidth.eng.umd.edu (gravman@bandwidth.eng.umd.edu [129.2.98.136]) by po2.glue.umd.edu (8.8.2/8.7.3) with ESMTP id QAA02542 for ; Tue, 5 Nov 1996 16:52:58 -0500 (EST) Received: from localhost (gravman@localhost) by bandwidth.eng.umd.edu (8.8.2/8.6.4) with SMTP id QAA04746 for ; Tue, 5 Nov 1996 16:52:54 -0500 (EST) X-Authentication-Warning: bandwidth.eng.umd.edu: gravman owned process doing -bs Date: Tue, 5 Nov 1996 16:52:54 -0500 (EST) Sender:ietf-request@ietf.org From: Gravman X-Sender: gravman@bandwidth.eng.umd.edu To: ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. unsubscribe   Received: from ietf.org by ietf.org id aa16213; 5 Nov 96 21:50 EST Received: from zephyr.isi.edu by ietf.org id aa15912; 5 Nov 96 21:48 EST Received: by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 5 Nov 1996 18:45:36 -0800 Sender:ietf-request@ietf.org From: Bill Manning Message-Id: <199611060245.AA00743@zephyr.isi.edu> Subject: Re: When? (was Re: NEWDOM: Re: TODO) To: Jim Fleming Date: Tue, 5 Nov 1996 18:45:36 -0800 (PST) Cc: root@taka.agn.net, ietf@ietf.org, newdom@vrx.net In-Reply-To: <01BBCB1D.674229A0@webster.unety.net> from "Jim Fleming" at Nov 5, 96 01:29:41 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1189 Source-Info: From (or Sender) name not authenticated. > People should note carefully that some of the discussion > on the OLD newdom does not make it to the NEW newdom > and vice versa. This is partly because some people are not > allowed to post to the OLD newdom list. > As Jim clearly points out, there is more than one mailing list labeled "newdom". It seems his current favorite is the one hosted from vrx.com. The original was hosted from iiia.org until the list owner shut it down due to perceived threats of legal action from some members of said list. The main thrust of the list then moved to ar.net, where things went along just fine, until some of the same set of people apparently became disruptive enough that they were expelled. Things are now split between the ar.net and vrx.com lists. The folks that seemed to cause the largest amount of problems on the iiia.org and ar.net are now attempting to socialize their beliefs in a wide variety of fora, generally espousing broader vision and more "open-ness" than is found in the regular fora of Internet protocols or operations types. It seems clear that they have near zero clue and have the attention span and patience of my two year old. --bill   Received: from ietf.org by ietf.org id aa16920; 5 Nov 96 21:59 EST Received: from Kitten.mcs.com by ietf.org id aa16665; 5 Nov 96 21:58 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id UAA05388; Tue, 5 Nov 1996 20:57:15 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id UAA12374; Tue, 5 Nov 1996 20:57:14 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id UAA02378; Tue, 5 Nov 1996 20:57:13 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611060257.UAA02378@Jupiter.Mcs.Net> Subject: Re: When? (was Re: NEWDOM: Re: TODO) To: Bill Manning Date: Tue, 5 Nov 1996 20:57:13 -0600 (CST) Cc: JimFleming@unety.net, root@taka.agn.net, ietf@ietf.org, newdom@vrx.net In-Reply-To: <199611060245.AA00743@zephyr.isi.edu> from "Bill Manning" at Nov 5, 96 06:45:36 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. >The folks that seemed to cause the largest >amount of problems on the iiia.org and ar.net are >now attempting to socialize their beliefs in a wide >variety of fora, generally espousing broader vision >and more "open-ness" than is found in the regular fora >of Internet protocols or operations types. It seems ^^^^^^^^ >clear that they have near zero clue and have the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >attention span and patience of my two year old. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > --bill And people wonder why folks are going around the "old guard". Personal attacks and insults will get you nowhere Bill. However, they will get you, and the organizations you are affiliated with, particularly the IANA, ignored by those of us intent on making progress and actually *doing something*. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa16968; 5 Nov 96 21:59 EST Received: from apnic-ttc.apnic.net by ietf.org id aa16839; 5 Nov 96 21:58 EST Received: by apnic-ttc.apnic.net; id LAA16850; Wed, 6 Nov 1996 11:52:39 +0900 Received: from unknown(10.0.10.4) by apnic-ttc.apnic.net via smap (g3.0.3) id xma016840; Wed, 6 Nov 96 11:52:14 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.8.2/8.7.1) with ESMTP id LAA00336; Wed, 6 Nov 1996 11:51:07 +0900 (JST) Message-Id: <199611060251.LAA00336@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Jim Fleming cc: 'System Administrator' , "'ietf@ietf.org'" , 'New Newdom' , davidc@apnic.net reply-to: newdom@vrx.net Subject: Re: When? (was Re: NEWDOM: Re: TODO) In-reply-to: Your message of "Tue, 05 Nov 1996 13:29:41 CST." <01BBCB1D.674229A0@webster.unety.net> Date: Wed, 06 Nov 1996 11:51:07 +0900 Sender:ietf-request@ietf.org From: "David R. Conrad" Source-Info: From (or Sender) name not authenticated. Hi, >People should note carefully that some of the discussion >on the OLD newdom does not make it to the NEW newdom >and vice versa. This is partly because some people are not >allowed to post to the OLD newdom list. Simply because those people were either to be constructive and/or they were abusive. For those that aren't aware, Jim Fleming was seen as one such individual. Unfortunately, the choices a list administrator has are somewhat limited when it comes to trying to curb individuals who (for whatever reason) are viewed as being incapable of working and playing well with others. >The IETF and other organizations can claim all they want >that they are an "open" forum. Maybe a better way to >put it would be an open hallway with many closed doors >and only certain people have the keys... The IETF is among the most open forums of which I am aware. Have you ever been to an IETF? Also, given that newdom is not an IETF working group, what exactly does the fact you were kicked off from newdom have to do with the IETF? Finally, given that multiple mailing lists exist for discussions on DNS and TLD related issues, can we PLEASE not spam the IETF list with newdom gunk (note reply-to)? Thanks, -drc   Received: from ietf.org by ietf.org id aa17431; 5 Nov 96 22:05 EST Received: from doorstep.unety.net by ietf.org id aa17361; 5 Nov 96 22:04 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id UAA16710; Tue, 5 Nov 1996 20:58:20 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCB5C.544294E0@webster.unety.net>; Tue, 5 Nov 1996 21:00:09 -0600 Message-ID: <01BBCB5C.544294E0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Bill Manning' Cc: "ietf@ietf.org" , "newdom@vrx.net" , "root@taka.agn.net" Subject: RE: When? (was Re: NEWDOM: Re: TODO) Date: Tue, 5 Nov 1996 21:00:07 -0600 Encoding: 73 TEXT Source-Info: From (or Sender) name not authenticated. On Tuesday, November 05, 1996 12:45 PM, Bill Manning[SMTP:bmanning@ISI.EDU] wrote: @ > People should note carefully that some of the discussion @ > on the OLD newdom does not make it to the NEW newdom @ > and vice versa. This is partly because some people are not @ > allowed to post to the OLD newdom list. @ > @ @As Jim clearly points out, there is more than @one mailing list labeled "newdom". It seems @his current favorite is the one hosted from @vrx.com. The original was hosted from iiia.org @until the list owner shut it down due to perceived @threats of legal action from some members of @said list. @ @The main thrust of the list then moved to ar.net, @where things went along just fine, until some of @the same set of people apparently became disruptive @enough that they were expelled. @ @Things are now split between the ar.net and vrx.com @lists. The folks that seemed to cause the largest @amount of problems on the iiia.org and ar.net are @now attempting to socialize their beliefs in a wide @variety of fora, generally espousing broader vision @and more "open-ness" than is found in the regular fora @of Internet protocols or operations types. It seems @clear that they have near zero clue and have the @attention span and patience of my two year old. @ @ --bill @ @ As usual, this is a one-sided view. The NEW newdom list (hosted by vrx.net) has been largely cultivated by people that want to get something specific accomplished. Things were going fine and we were having discussions about Root 64 and other specifc objectives. Because of this specific progress, people started moving from the OLD newdom list and helping to work toward specific results. The discussion on the OLD newdom list diminished to a point where the list operator suggested closing the list. That announcement caused a group of people to switch lists resulting in a degeneration of the progress being made. As in the past, I suggest that everyone return to working on specific projects with specific goals and objectives. While this might anger some of the people trying to derail these efforts, we can not allow that to slow things down. In the end, the entire global Internet will be able to judge the results, and the archives will clearly show who contributed and who did not. Computer historians can pick through those archives and document what occurred. Our task at hand is to document the future.... ...we have a lot of work to do... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa19358; 5 Nov 96 22:25 EST Received: from presence.lglobal.com by ietf.org id aa18762; 5 Nov 96 22:24 EST Received: from [207.107.12.74] (voyager9.lglobal.com [207.107.12.74]) by presence.lglobal.com (8.6.12/8.6.12) with SMTP id WAA02122; Tue, 5 Nov 1996 22:32:02 -0500 X-Sender: allisat@mail.lglobal.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Nov 1996 22:27:19 -0500 To: Bill Manning Sender:ietf-request@ietf.org From: Bob Allisat Subject: Re: When? (was Re: NEWDOM: Re: TODO) Cc: Jim Fleming , root@taka.agn.net, ietf@ietf.org, newdom@vrx.net Source-Info: From (or Sender) name not authenticated. Jim Fleming wrote: > People should note carefully that some of the discussion > on the OLD newdom does not make it to the NEW newdom > and vice versa. This is partly because some people are not > allowed to post to the OLD newdom list. Bill Manning replied: : Things are now split between the ar.net and vrx.com : lists. The folks that seemed to cause the largest : amount of problems on the iiia.org and ar.net are : now attempting to socialize their beliefs in a wide : variety of fora, generally espousing broader vision : and more "open-ness" than is found in the regular fora : of Internet protocols or operations types. It seems : clear that they have near zero clue and have the : attention span and patience of my two year old. Bill, there's no need to resort to insults. We have moved beyond that. As for me personally having "zero clue" I'd have to agree. Of all the commentators here I have the very least "clue". Jim, on the other hand has plenty clue. I am, on the other hand, the very definition of "clueless". I don't know a router from a rooter from a roto-tiller. RFC's hold no religious state for me. I don't give two hoots for Postel/IANA. ISOC is a gang of elitists in my opinion. Internic is a shameless money grab without re- demption. NSI is merely a front organization for the NSA/CIA super spooks behind SAIC. It's all crooked. And in the world according to Bob, you, Mr. Manning, are no better or worse than the guy behind the counter at the corner store or the streetcar operator or me. We are all equals. But I'm *not* your two year old! Never forget that Bill. You and me are the same. Equals. Respect. Internationally Yours, Bob Allisat tor@wtv.net Director, (416) 588-0670 World Televirtual Network http://www.wtv.net PO Box 191 Station E Toronto Ontario Canada M6H 4E2   Received: from ietf.org by ietf.org id aa29217; 5 Nov 96 23:26 EST Received: from rip.psg.com by ietf.org id aa28962; 5 Nov 96 23:25 EST Received: by rip.psg.com id m0vKzDf-0007zeC; Tue, 5 Nov 96 20:04 PST (Smail3.1.29.1#1) Message-Id: Date: Tue, 5 Nov 96 20:04 PST Sender:ietf-request@ietf.org From: Randy Bush To: ietf@ietf.org Subject: Re: English is it -> was: Re: The cartel begins to crumble? References: BAD MSG: <199611051314.QAA10529@aic.net> ource-Info: From (or Sender) name not authenticated. While I find this whole discussion without merit, it is worth celebrating that > In fact, 90% of the Internet is in the U.S.A. is quite false. This is the year that the *majority* of nodes are finally outside the US. This is indeed worth celebrating. We now return to the normal bickering andthe new-dumb mailing list. randy   Received: from ietf.org by ietf.org id aa06811; 6 Nov 96 3:56 EST Received: from bells.cs.ucl.ac.uk by ietf.org id aa06693; 6 Nov 96 3:54 EST Received: from speedy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Nov 1996 08:52:42 +0000 To: newdom@vrx.net cc: "'ietf@ietf.org'" Subject: Re: When? (was Re: NEWDOM: Re: TODO) In-reply-to: Your message of "Wed, 06 Nov 1996 11:51:07 +0900." <199611060251.LAA00336@moonsky.jp.apnic.net> Date: Wed, 06 Nov 1996 08:52:38 +0000 Message-ID: <969.847270358@cs.ucl.ac.uk> Sender:ietf-request@ietf.org From: Jon Crowcroft Source-Info: From (or Sender) name not authenticated. please desist from bothering the ietf list with newdom stuff the ietf is for internet engineering and standards, not religion, politics and economics....(or linguistics...) jon.   Received: from ietf.org by ietf.org id aa10348; 6 Nov 96 5:42 EST Received: from ns.aic.net by ietf.org id aa10247; 6 Nov 96 5:39 EST Received: by aic.net (8.7.3/8.7.3) id NAA14980; Wed, 6 Nov 1996 13:33:47 +0300 (GMT) Message-Id: <199611061033.NAA14980@aic.net> Subject: Re: English is it -> was: Re: The cartel begins to crumble? To: Valdis.Kletnieks@vt.edu Date: Wed, 6 Nov 1996 13:33:47 +0300 (GMT) Cc: ietf@ietf.org In-Reply-To: <199611051544.KAA06532@black-ice.cc.vt.edu> from "Valdis.Kletnieks@vt.edu" at Nov 5, 96 10:44:51 am Sender:ietf-request@ietf.org From: edd@acm.org Reply-To: edd@amnic.net Organization: AM Network Information Center @ AIC Network Operations X-Tel: +37 42 28 14 25 X-FAX: +37 42 28 50 82 X-InterNIC-ID: ET22 Content-Type: text Source-Info: From (or Sender) name not authenticated. Dear Valdis, > On Tue, 05 Nov 1996 16:14:43 +0300, you said: > > These facts are enough - the official language of the Internet > > IS the English language. This is fact. > > Umm.. is this "official" official, being codified in an RFC or similar, or > merely a "de facto" official? The second one, you know > English is no more the "official" language of the Internet than > Windows 95 is the "official" operating system. No matter *what* > Bill Gates wishes were true... Well, it seems you completely misunderstood me. First of all, please do not mention Bill. He doesn't have anything to do here. I hate M$ and I don't use their products at all... About officiality - as I said, it is de facto standard, *IMHO*. Best regards. Edgar   Received: from ietf.org by ietf.org id aa10744; 6 Nov 96 5:45 EST Received: from ns.aic.net by ietf.org id aa10671; 6 Nov 96 5:44 EST Received: by aic.net (8.7.3/8.7.3) id NAA15004; Wed, 6 Nov 1996 13:41:05 +0300 (GMT) Message-Id: <199611061041.NAA15004@aic.net> Subject: Re: English is it -> was: Re: The cartel begins to crumble? To: Jorge Alejandro Oyarbide Date: Wed, 6 Nov 1996 13:41:05 +0300 (GMT) Cc: edd@amnic.net, Valdis.Kletnieks@vt.edu, ietf@ietf.org In-Reply-To: <01BBCB1F.6C636AA0@j_oyarbide.txport.com> from "Jorge Alejandro Oyarbide" at Nov 5, 96 01:44:09 pm Sender:ietf-request@ietf.org From: edd@acm.org Reply-To: edd@amnic.net Organization: AM Network Information Center @ AIC Network Operations X-Tel: +37 42 28 14 25 X-FAX: +37 42 28 50 82 X-InterNIC-ID: ET22 Content-Type: text Source-Info: From (or Sender) name not authenticated. > Do we need an official language ?? Can we just go with common sense ?? Yes, yes, and yes! It seems you forgot that English ISN'T my native language? Just for your information: my native language is in use for more than 2000 years. 2000 years ago where were no English, no Spanish (and, indeed, no Internet :-) Yours, Edgar   Received: from ietf.org by ietf.org id aa11996; 6 Nov 96 6:02 EST Received: from cnri by ietf.org id aa11729; 6 Nov 96 6:01 EST Received: from ns.aic.net by CNRI.Reston.VA.US id aa06517; 6 Nov 96 6:00 EST Received: by aic.net (8.7.3/8.7.3) id NAA15093; Wed, 6 Nov 1996 13:58:10 +0300 (GMT) Message-Id: <199611061058.NAA15093@aic.net> Subject: Re: NON SENSE. English is the best language for this.... To: sthaug@nethelp.no Date: Wed, 6 Nov 1996 13:58:10 +0300 (GMT) Cc: ietf@CNRI.Reston.VA.US In-Reply-To: <6491.847221471@verdi.nethelp.no> from "sthaug@nethelp.no" at Nov 5, 96 08:17:51 pm Sender:ietf-request@ietf.org From: edd@acm.org Reply-To: edd@amnic.net Organization: AM Network Information Center @ AIC Network Operations X-Tel: +37 42 28 14 25 X-FAX: +37 42 28 50 82 X-InterNIC-ID: ET22 Content-Type: text Source-Info: From (or Sender) name not authenticated. > > > > Well, I can't agree. Internet and 99% of associated "things" > > > originated in the US. > > > > >In fact, 90% of the Internet is in the U.S.A. > > > > Really? I wonder how that fact was derived? > > Certainly not by any scientific method. Even if you don't define what > 'the Internet' includes, let's take a look at host count statistics. Great. I was wrong in the second statement, but do you disagree with the first one??? Seems it's better to stop this thread. I do right now. Amenaayn bareekneer, -edd   Received: from ietf.org by ietf.org id aa14506; 6 Nov 96 7:16 EST Received: from cnri by ietf.org id aa14270; 6 Nov 96 7:11 EST Received: from [131.112.32.132] by CNRI.Reston.VA.US id aa07637; 6 Nov 96 7:11 EST Sender:ietf-request@ietf.org From: Masataka Ohta Message-Id: <199611061157.UAA11400@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA11400; Wed, 6 Nov 1996 20:57:41 +0900 Subject: Re: NON SENSE. English is the best language for this.... To: edd@amnic.net Date: Wed, 6 Nov 96 20:57:40 JST Cc: sthaug@nethelp.no, ietf@CNRI.Reston.VA.US In-Reply-To: <199611061058.NAA15093@aic.net>; from "edd@acm.org" at Nov 6, 96 1:58 pm X-Mailer: ELM [version 2.3 PL11] Source-Info: From (or Sender) name not authenticated. edd; > > > > Well, I can't agree. Internet and 99% of associated "things" > > > > originated in the US. > > > > > > >In fact, 90% of the Internet is in the U.S.A. > > > > > > Really? I wonder how that fact was derived? > > > > Certainly not by any scientific method. Even if you don't define what > > 'the Internet' includes, let's take a look at host count statistics. > > Great. I was wrong in the second statement, but do you disagree with the > first one??? Regardless of whether you are right or it's actually 70%, you described the problem, not an excuse not to solve the problem. Masataka Ohta   Received: from ietf.org by ietf.org id aa15634; 6 Nov 96 7:59 EST Received: from cnri by ietf.org id aa15560; 6 Nov 96 7:57 EST Received: from milou.inria.fr by CNRI.Reston.VA.US id aa08456; 6 Nov 96 7:57 EST Received: by milou.inria.fr (8.7.6/8.6.12) id NAA20440; Wed, 6 Nov 1996 13:56:11 +0100 (MET) Message-Id: <199611061256.NAA20440@milou.inria.fr> To: end2end-interest@isi.edu, sigcomm96ex@aland.bbn.com, sigcommex@acm.org, ietf@CNRI.Reston.VA.US Subject: SIGCOMM '97 Tutorials Date: Wed, 06 Nov 1996 13:56:09 +0100 Sender:ietf-request@ietf.org From: Walid Dabbous Source-Info: From (or Sender) name not authenticated. Sorry for multiple copies... We solicit tutorial proposals for SIGCOMM'97. Each tutorial is intented to cover a single topic in detail, and should be a full day in length. There should be 4 tutorials in two tracks. Topics of interest include but are not limited to: Multicast (applications, transmission control, routing) IntServ (guaranteed/controlled load services, WFQ/CBQ, RSVP) Internet over New Media (satellite, cable, etc) Multimedia over internet Web/cash applications Tutorial submissions should include an extended abstract and outline (2-4 pages), and an indication of length, objectives and intended audience. Proposals should be sent by e-mail asap to dabbous@sophia.inria.fr. Submission deadline is January 31st, 1997 More information on the tutorials will be available later on the SIGCOMM'97 tutorials web page http://www.inria.fr/rodeo/sigcomm97/tutorials.html Walid Dabbous INRIA U.R. de Sophia Antipolis | Email : dabbous@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 4 93 65 77 18 06902 Sophia Antipolis CEDEX France | Fax : +33 4 93 65 77 65   Received: from ietf.org by ietf.org id aa17289; 6 Nov 96 8:34 EST Received: from cnri by ietf.org id aa17222; 6 Nov 96 8:31 EST Received: from domen.uninett.no by CNRI.Reston.VA.US id aa09064; 6 Nov 96 8:31 EST Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <05135-0@domen.uninett.no>; Wed, 6 Nov 1996 14:30:39 +0100 X-Mailer: exmh version 1.6.7 5/3/96 Sender:ietf-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: sthaug@nethelp.no cc: ietf@CNRI.Reston.VA.US Subject: Re: NON SENSE. English is the best language for this.... In-reply-to: Your message of "Tue, 05 Nov 1996 20:17:51 +0100." <6491.847221471@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 14:30:36 +0100 Message-ID: <5132.847287036@domen.uninett.no> X-Orig-Sender: Harald.T.Alvestrand@uninett.no Source-Info: From (or Sender) name not authenticated. If we add up the .com, .net, .edu, .mil, .gov, .org and .us domains, we get 8.224.279 out of the 12.880.699 hosts counted by Network Wizards. That is 64 percent. I've heard estimates that up to 20% of all .com hosts are outside the US, and wouldn't care even to guess about the proportion under .net (in some countries, orgs register under .net because they don't like the policy of the country-domain admin. What fun!) If we assumed that 20% of .com and .net were outside the US, we would get 911.309 more non-US hosts, giving 56% of the Internet left inside the United States. I don't have a number for non-US people writing RFCs, but have heard a guesstimate of one fifth. One fact beats 20 guesses... harald A   Received: from ietf.org by ietf.org id aa22484; 6 Nov 96 9:45 EST Received: from localhost by ietf.org id aa20705; 6 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-claffy-icp-v2-00.txt Date: Wed, 06 Nov 1996 09:37:31 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611060937.aa20705@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Cache Protocol (ICP), version 2 Author(s) : D. Wessels, K. Claffy Filename : draft-claffy-icp-v2-00.txt Pages : 7 Date : 11/05/1996 This draft document describes the Internet Cache Protocol (ICP) currently implemented in a few World-Wide Web proxy cache packages. ICP was initially developed by Peter Danzig, et. al. at the Univerisity of Southern California. It evolved as an important part of hierarchical caching on the Harvest research project. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-claffy-icp-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-claffy-icp-v2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-claffy-icp-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961105100913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-claffy-icp-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-claffy-icp-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961105100913.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22481; 6 Nov 96 9:45 EST Received: from localhost by ietf.org id aa20947; 6 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-macker-mdp-framework-00.txt Date: Wed, 06 Nov 1996 09:37:53 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611060937.aa20947@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Multicast Dissemination Protocol (MDP) Framework Author(s) : J. Macker, W. Dang Filename : draft-macker-mdp-framework-00.txt Pages : 14 Date : 11/05/1996 This document outlines a simple protocol framework for reliable multicast dissemination of data files. The general framework was originally developed and used by the Image Multicaster (IMM) application within the Internet MBone for dissemination of satellite imagery. This document describes the potential for more general use of the protocol framework, its operational modes, some performance issues, and the basic application data units (ADUs) presently used. This is not intended to be a detailed protocol specification document, but rather a broad description of the basic architectural approach. Further detailed description of the protocol implementation may be provided in future documents. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-macker-mdp-framework-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-macker-mdp-framework-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-macker-mdp-framework-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961105174324.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-macker-mdp-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-macker-mdp-framework-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961105174324.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22483; 6 Nov 96 9:45 EST Received: from localhost by ietf.org id aa20897; 6 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-lyon-itp-nodes-00.txt Date: Wed, 06 Nov 1996 09:37:47 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611060937.aa20897@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transaction Internet Protocol Author(s) : J. Lyon Filename : draft-lyon-itp-nodes-00.txt Pages : 12 Date : 11/05/1996 In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. that is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lyon-itp-nodes-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-lyon-itp-nodes-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-lyon-itp-nodes-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961105102740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lyon-itp-nodes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lyon-itp-nodes-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961105102740.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22482; 6 Nov 96 9:45 EST Received: from localhost by ietf.org id aa20775; 6 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-martins-ilps-00.txt Date: Wed, 06 Nov 1996 09:37:36 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611060937.aa20775@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Location Path System (ILPS) Author(s) : L. Martins Filename : draft-martins-ilps-00.txt Pages : 6 Date : 11/05/1996 This document presents a new, uniform method of mapping IP addresses, service identifiers and service-specific info. It does the ame work that is done by DNS and URLs. I realize this would be extremally hard to implement, as there is already an immense working base of DNS, but the idea provides so much benefits that I thought I did not have the right not to post it (so maybe the URN folks use it for something). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-martins-ilps-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-martins-ilps-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-martins-ilps-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961105101506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-martins-ilps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-martins-ilps-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961105101506.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa25528; 6 Nov 96 10:20 EST Received: from ng.netgate.net by ietf.org id aa25340; 6 Nov 96 10:17 EST Received: from [205.214.160.103] (d34.netgate.net [205.214.160.68]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id HAA24571; Wed, 6 Nov 1996 07:26:15 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <199611060251.LAA00336@moonsky.jp.apnic.net> References: Your message of "Tue, 05 Nov 1996 13:29:41 CST." <01BBCB1D.674229A0@webster.unety.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Nov 1996 22:20:17 -0800 To: "David R. Conrad" Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: When? (was Re: NEWDOM: Re: TODO) Cc: Jim Fleming , 'System Administrator' , "'ietf@ietf.org'" , 'New Newdom' , davidc@apnic.net Source-Info: From (or Sender) name not authenticated. At 6:51 PM -0800 11/5/96, David R. Conrad wrote: >Finally, given that multiple mailing lists exist for discussions on >DNS and TLD related issues, can we PLEASE not spam the IETF list with >newdom gunk (note reply-to)? David, I'm on the IAHC and want to try to track all the relevant mailing lists. Should I subscribe to both newdom lists? Thanks. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa27204; 6 Nov 96 10:31 EST Received: from localhost by ietf.org id aa26430; 6 Nov 96 10:25 EST To: IETF-Announce: ; Subject: WG ACTION: Application Configuration Access Protocol (acap) Date: Wed, 06 Nov 1996 10:25:36 -0500 Sender:ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9611061025.aa26430@ietf.org> A new working group has been formed in the Applications Area of the IETF. For additional information, contact the Area Directors or the WG Chair. Application Configuration Access Protocol (acap) ------------------------------------------------ Chair(s): Chris Newman Applications Area Director(s): Keith Moore Harald Alvestrand Mailing lists: General Discussion:ietf-acap+@andrew.cmu.edu To Subscribe: ietf-acap-request+@andrew.cmu.edu Archive: anonymous IMAP: cyrus.andrew.cmu.edu:archive.ietf-acap Description of Working Group: The goal of this working group is to define, specify, and develop the Application Configuration Access Protocol as a general access mechanism for per-user and per-server structured lists of information. In addition, the Working Group will specify how to use the protocol to store specific structured lists, initially application configuration options and addressbooks. The Application Configuration Access Protocol is a proposed solution to the problems of client configuration for users of the internet. Given the increasing prevalence of network access points and rapidly increasing numbers of users with diverse needs and settings, there is a phenomenon of internet application users who typically connect from more than one physical location and/or operating system to use the same set of internet services and applications. These users must recreate sets of personal configuration information for each system, session, and location that they use. This may include information such as application options and preferences; personal or shared user data such as addressbooks, bookmarks, or subscription lists; or shared data for internal client use, such as authorization group lists. The products of this working group will be: * a formal specification for the protocol * formal specifications of datasets used by the protocol and related extensions to the protocol * an RFC intended to move to a Standard in a timely manner * a specification for extensibility of the protocol in the form of a framework document * additional informational and/or experimental RFCs as necessary to amplify and/or extend ACAP. Note on goals and milestones: because the work of the ACAP WG is based on the previous work done on IMSP, there is justification for a somewhat more aggressive schedule than is customary. Goals and Milestones: Jul 96 Submission of "ACAP vs. Other Protocols" Informational Document for discussion Sep 96 Submission of revised proposed WG charter to area directors Sep 96 Submission of "ACAP vs. Other Protocols" as Internet Draft Oct 96 Second internet-draft of ACAP protocol specification Dec 96 working group meeting at San Jose IETF Jan 97 Working implementations of client and server library Feb 97 Final internet-draft of ACAP protocol submitted to IESG for consideration as Proposed Standard Mar 97 Additional dataset specifications defined as directed by WG.   Received: from ietf.org by ietf.org id aa03762; 6 Nov 96 12:25 EST Received: from doorstep.unety.net by ietf.org id aa03629; 6 Nov 96 12:22 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA19494; Wed, 6 Nov 1996 11:16:12 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCBD4.2C2750E0@webster.unety.net>; Wed, 6 Nov 1996 11:18:01 -0600 Message-ID: <01BBCBD4.2C2750E0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Dave Crocker' Cc: "'ietf@ietf.org'" Subject: IAHC Date: Wed, 6 Nov 1996 11:18:00 -0600 Encoding: 71 TEXT Source-Info: From (or Sender) name not authenticated. On Wednesday, November 06, 1996 12:20 AM, Dave Crocker[SMTP:dcrocker@brandenburg.com] wrote: @ At 6:51 PM -0800 11/5/96, David R. Conrad wrote: @ >Finally, given that multiple mailing lists exist for discussions on @ >DNS and TLD related issues, can we PLEASE not spam the IETF list with @ >newdom gunk (note reply-to)? @ @David, I'm on the IAHC and want to try to track all the relevant @ mailing lists. Should I subscribe to both newdom lists? @ David, According to the following, the IAHC is going to have 9 members. Have all of those members been appointed yet...? If so, can you tell everyone who they are and who made the appointments...? @@@@ http://www.isoc.org/whatsnew/iahc.html "The IAHC will be composed of representatives of the large international Internet community. The International Telecommunication Union (ITU), the World Intellectual Property Organization (WIPO), and the International Trademark Association (INTA) will designate one each. ISOC, IANA, and the Internet Architecture Board (IAB) will each appoint two members for a total of nine." @@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Also, According to "The IAHC will work in an open electronic forum soliciting advice, comments, and counsel from a wide array of interested parties." Can you explain where the IAHC is holding discussions...? Was there a meeting in Washington, D.C. this week...? If so, are the meeting notes on line...? Also, According to the following schedule, the formation of the IAHC triggers the establishment of "Day 1". Can you explain when Day 1 occurred...?...(if it did) @@@@ http://info.isoc.org/whatsnew/itlds.html Schedule of Events Day 1IAHC formed Day 30IAHC finalizes procedures and publicly announces Day 31Begin accepting applications Day 90Acceptance of applications ceases Day 135IAHC announces registry selection and iTLDs Day 136ISOC begins contracting with selected registries Day XISOC notifies IANA that contract is complete Day X + 1IANA introduces new iTLDs to root zone file Day X + 90Registry begins operations @@@@@@@@@@@@@@@@@@@@@@@@@@@@@ -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa08329; 6 Nov 96 15:02 EST Received: from typhoon.dial.pipex.net by ietf.org id aa07854; 6 Nov 96 14:58 EST Received: from Unknown by typhoon.dial.pipex.net (8.8.2/) id TAA06910; Wed, 6 Nov 1996 19:56:32 GMT Message-Id: <199611061956.TAA06910@typhoon.dial.pipex.net> Comments: Authenticated sender is Sender:ietf-request@ietf.org From: dzshobrook@dial.pipex.com To: ietf@ietf.org Date: Mon, 4 Nov 1996 20:49:06 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Priority: normal X-mailer: Pegasus Mail for Windows (v2.40) Source-Info: From (or Sender) name not authenticated. unsubscribe fp65@dial.pipex.com   Received: from ietf.org by ietf.org id aa08323; 6 Nov 96 15:02 EST Received: from typhoon.dial.pipex.net by ietf.org id aa07871; 6 Nov 96 14:58 EST Received: from Unknown by typhoon.dial.pipex.net (8.8.2/) id TAA06964; Wed, 6 Nov 1996 19:56:38 GMT Message-Id: <199611061956.TAA06964@typhoon.dial.pipex.net> Comments: Authenticated sender is Sender:ietf-request@ietf.org From: dzshobrook@dial.pipex.com To: ietf@ietf.org Date: Mon, 4 Nov 1996 20:49:06 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Priority: normal X-mailer: Pegasus Mail for Windows (v2.40) Source-Info: From (or Sender) name not authenticated. unsubscribe dzshobrook@dial.pipex.com   Received: from ietf.org by ietf.org id aa09200; 6 Nov 96 15:20 EST Received: from ns1.vrx.net by ietf.org id aa09061; 6 Nov 96 15:18 EST Received: from C109.reach.net (C109.reach.net [204.50.58.141]) by ns1.vrx.net (8.7.5/8.6.9) with SMTP id PAA10950; Wed, 6 Nov 1996 15:16:36 -0500 (EST) Date: Wed, 6 Nov 1996 15:16:36 -0500 (EST) Message-Id: <199611062016.PAA10950@ns1.vrx.net> X-Sender: alterrich@vrx.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bill Manning Sender:ietf-request@ietf.org From: "Richard J. Sexton" Subject: Re: When? (was Re: NEWDOM: Re: TODO) Cc: ietf@ietf.org, newdom@vrx.net Source-Info: From (or Sender) name not authenticated. At 06:45 PM 11/5/96 -0800, you wrote: >> People should note carefully that some of the discussion >> on the OLD newdom does not make it to the NEW newdom >> and vice versa. This is partly because some people are not >> allowed to post to the OLD newdom list. >> > >As Jim clearly points out, there is more than >one mailing list labeled "newdom". It seems >his current favorite is the one hosted from >vrx.com. Thats actualy vrx.NET, Bill, ALthough it might work if you type .com, I recall going to a bit of effort to help the fumble fingered. > The original was hosted from iiia.org >until the list owner shut it down due to perceived >threats of legal action from some members of >said list. I agree with this. > >The main thrust of the list then moved to ar.net, >where things went along just fine, until some of >the same set of people apparently became disruptive >enough that they were expelled. Allisat and Fleming were expell. I quit out of disgust. >Things are now split between the ar.net and vrx.com >lists. The folks that seemed to cause the largest >amount of problems on the iiia.org and ar.net are >now attempting to socialize their beliefs in a wide >variety of fora, generally espousing broader vision >and more "open-ness" than is found in the regular fora >of Internet protocols or operations types. It seems >clear that they have near zero clue and have the >attention span and patience of my two year old. > >--bill Not the way I saw it. After Allisat, Fleming and I left, Fleming kept mailing about 5 poeple; I set up newdom@vrx instead of havig to reply and cc all those poeple. Oddly, it proved popular, and to my great surprise, the poeple kicked of newdom@ar.com seemed to be the ones that people wanted to read. About a week or so ago, RIck Wesson sent either me of Fleming mail sugegsting he may as well shut down his list. Are you really complaining about "too much open-ness" in your parapgraph above, Bill? -- Richard J. Sexton richard@Alter.NIC   Received: from ietf.org by ietf.org id aa09900; 6 Nov 96 15:26 EST Received: from zephyr.isi.edu by ietf.org id aa09279; 6 Nov 96 15:21 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 6 Nov 1996 12:20:17 -0800 Message-Id: <199611062020.AA11084@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2039 on WWW Track MIBs Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 06 Nov 96 12:20:16 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2039: Title: Applicablity of Standards Track MIBs to Management of World Wide Web Servers Author: C. Kalbfleisch Date: November 1996 Mailbox: cwk@onramp.net Pages: 14 Characters: 31,966 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2039.txt Requirements for management of a World Wide Web (WWW) server are presented. The applicable existing standards track MIBs are then examined. Finally, an analysis of the additional groups of MIB attributes that are needed to meet the requirements is presented. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961106121513.RFC@ISI.EDU> SEND /rfc/rfc2039.txt --OtherAccess Content-Type: Message/External-body; name="rfc2039.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961106121513.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17068; 6 Nov 96 18:56 EST Received: from nsipo.arc.nasa.gov by ietf.org id aa16792; 6 Nov 96 18:50 EST Received: Wed, 6 Nov 1996 15:48:48 -0800 (PST) from localhost (RFC1413 sender feinler@localhost) by nsipo.arc.nasa.gov (8.7.1/1.5) id PAA12758 Date: Wed, 6 Nov 1996 15:48:47 -0800 (PST) Sender:ietf-request@ietf.org From: Jake Feinler To: Masataka Ohta cc: Brian Carpenter CERN-CN , ietf@ietf.org Subject: Re: The cartel begins to crumble? In-Reply-To: <199610310251.LAA11198@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Having been the originator of the idea of .com, .edu, .gov, .mil, etc I have been watching this discussion with some amusement. I can only say to those whose first language is not English that you are not alone in feeling some trepidation. I feel great sympathy for ** ANY** speakers who are willing to step up to the microphone in IETF meetings, especially if the topic is naming and addressing! That is not an exercise for the faint of heart. In the heat of battle and the exchange of ideas, it behooves us all to remember that we are engaged in an international discussion among peers and be a little kinder and gentler with each other. As this discussion is pointing out, what is satire in one background can be insult in another. Also I might point out that the naming system has held up reasonably well over several years because of the many ideas and heated discussions that led to a workable consensus. My suggestion would be to continue this process of evolution of the naming system until better solutions are found, and go easy on flames and bashing. IETF is not perfect in its approach to problem solving, but hey, it's held up as a viable open technical forum for more than 20 years (thanks to the dedication of many) and has produced the phenomenon of the Internet, so has to be doing something right. If you have good ideas get them in there...global feedback and concensus are what have made the Internet great...it's a chaotic democracy not a cartel conspiracy. Signed, Tattered but still unfurled Jake Feinler P.S. These are my own musings and do not represent any organizations with which I am now or have been affiliated. On Thu, 31 Oct 1996, Masataka Ohta wrote: > Brian; > > > Just in case my words in French were misinterpreted - > > No. As I replied in Japanese, that was fine. > > > Having worked for 20 years about half in my native > > language and half in a foreign language, I feel great > > sympathy for non-English speakers who are willing > > to step up to the microphone in IETF meetings. > > You are wrong. > > We are OK. > > You should and I do feel sympathy for those who can't step up to the > microphone in IETF meetings even though they are there and have > their own opinion. > >Masataka Ohta >   Received: from ietf.org by ietf.org id aa18981; 6 Nov 96 20:01 EST Received: from borax.Stanford.EDU by ietf.org id aa18749; 6 Nov 96 19:56 EST Received: from macii-morgan.stanford.edu (macii-morgan.Stanford.EDU [36.53.0.167]) by borax.stanford.edu (8.7.5/8.7.3) with SMTP id QAA19739; Wed, 6 Nov 1996 16:55:21 -0800 (PST) Date: Wed, 6 Nov 96 16:55:28 -0800 Sender:ietf-request@ietf.org From: RL Bob Morgan To: Simon Spero Subject: Re: Carpools and Cartels Cc: ietf@ietf.org Message-ID: In-Reply-To: Your message of Fri, 1 Nov 1996 18:33:36 -0500 (EST) Content-Type: TEXT/plain; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. > [Never one to miss the opportunity for a segue, Are > there any carpools going from SF to San Jose during the IETF?] If you're going from San Francisco or thereabouts to San Jose for the IETF meeting, I recommend CalTrain. $4.75 one-way SF to SJ. More info should be at http://server.berkeley.edu/Transit/Carriers/CalTrain (which unfortunately doesn't seem to be up right at this moment). It's a 10-15 minute walk to the Fairmont, or there are buses. - RL "Bob" Morgan Stanford   Received: from ietf.org by ietf.org id aa20685; 6 Nov 96 21:00 EST Received: from tipper.oit.unc.edu by ietf.org id aa20564; 6 Nov 96 20:57 EST Received: from hilly.oit.unc.edu (ppp6.mcnc.org [128.109.64.16]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id UAA09676; Wed, 6 Nov 1996 20:55:50 -0500 Message-Id: <1.5.4.32.19961107015503.0067a168@tipper.oit.unc.edu> X-Sender: ses@tipper.oit.unc.edu X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 20:55:03 -0500 To: RL Bob Morgan Sender:ietf-request@ietf.org From: Simon E Spero Subject: Re: Carpools and Cartels Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 04:55 PM 11/6/96 -0800, RL "Bob" Morgan wrote: >If you're going from San Francisco or thereabouts to San Jose for the IETF >meeting, I recommend CalTrain. $4.75 one-way SF to SJ. More info should be at >http://server.berkeley.edu/Transit/Carriers/CalTrain (which unfortunately >doesn't seem to be up right at this moment). It's a 10-15 minute walk to the >Fairmont, or there are buses. Yeah (this past year I was living in Mtn View about 20 yards from the Caltrain line; some nights I can hear it still :-) Trouble is it stops running a bit too early for IETF hours :-) Simon   Received: from ietf.org by ietf.org id aa22707; 6 Nov 96 22:15 EST Received: from cnri by ietf.org id aa22485; 6 Nov 96 22:11 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa29916; 6 Nov 96 22:11 EST Received: from engine3.dnet.net.id by venera.isi.edu (5.65c/5.61+local-25) id ; Wed, 6 Nov 1996 19:10:51 -0800 Received: from NETwork.dnet.net.id ([202.148.1.203]) by engine3.dnet.net.id (post.office MTA v1.9.3 ID# 0-13255) with ESMTP id AAA29915 for ; Thu, 7 Nov 1996 10:11:48 +0000 Sender:ietf-request@ietf.org From: Rachmat Kosasih To: ietf@isi.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Date: Thu, 7 Nov 1996 10:13:36 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19961107101148.AAA29915@NETwork.dnet.net.id> Source-Info: From (or Sender) name not authenticated. unsubscribe comsoc-conferences ietf@isi.edu __________________________________________________________ Rachmat Kosasih Dyviacom Intrabumi,p.t. Network Engineer Menara Mulia lt.11 Suite 1108 ph: +62-21-525-7520 Jl. Jend. Gatot Soebroto Kav 9 - 11 fx: +62-21-525-7634 Jakarta - 12930 mailto:rk@dnet.net.id Indonesia __________________________________________________________   Received: from ietf.org by ietf.org id aa29960; 6 Nov 96 23:15 EST Received: from Kitten.mcs.com by ietf.org id aa29684; 6 Nov 96 23:10 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id WAA08482; Wed, 6 Nov 1996 22:09:51 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id WAA15808; Wed, 6 Nov 1996 22:09:45 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id WAA28072; Wed, 6 Nov 1996 22:09:45 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611070409.WAA28072@Jupiter.Mcs.Net> Subject: Re: Carpools and Cartels To: RL Bob Morgan Date: Wed, 6 Nov 1996 22:09:44 -0600 (CST) Cc: ses@tipper.oit.unc.edu, ietf@ietf.org In-Reply-To: from "RL Bob Morgan" at Nov 6, 96 04:55:28 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > > > [Never one to miss the opportunity for a segue, Are > > there any carpools going from SF to San Jose during the IETF?] > > If you're going from San Francisco or thereabouts to San Jose for the IETF > meeting, I recommend CalTrain. $4.75 one-way SF to SJ. More info should be at > http://server.berkeley.edu/Transit/Carriers/CalTrain (which unfortunately > doesn't seem to be up right at this moment). It's a 10-15 minute walk to the > Fairmont, or there are buses. > > - RL "Bob" Morgan > Stanford Is there a canonical source for info on the SJ IETF meeting (hotels, etc)? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa00969; 6 Nov 96 23:35 EST Received: from newdev.harvard.edu by ietf.org id aa00846; 6 Nov 96 23:30 EST Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id XAA00652; Wed, 6 Nov 1996 23:27:57 -0500 (EST) Date: Wed, 6 Nov 1996 23:27:57 -0500 (EST) Sender:ietf-request@ietf.org From: Scott Bradner Message-Id: <199611070427.XAA00652@newdev.harvard.edu> To: Bob.Morgan@stanford.edu, karl@mcs.net Subject: Re: Carpools and Cartels Cc: ietf@ietf.org, ses@tipper.oit.unc.edu Source-Info: From (or Sender) name not authenticated. > Is there a canonical source for info on the SJ IETF meeting (hotels, etc)? http://www.ietf.org its all there under "meetings" Scott   Received: from ietf.org by ietf.org id aa06154; 7 Nov 96 1:09 EST Received: from vm.biu.ac.il by ietf.org id aa06086; 7 Nov 96 1:06 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 0797; Thu, 07 Nov 96 08:04:25 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1207; Thu, 7 Nov 1996 08:02:53 +0200 Date: Thu, 07 Nov 96 07:59:34 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Test To: ietf@ietf.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611070106.aa06086@ietf.org> Source-Info: From (or Sender) name not authenticated. Plz ignore.   Received: from ietf.org by ietf.org id aa09825; 7 Nov 96 4:23 EST Received: from vm.biu.ac.il by ietf.org id aa09728; 7 Nov 96 4:19 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 0959; Thu, 07 Nov 96 11:17:40 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1924; Thu, 7 Nov 1996 11:17:40 +0200 Date: Thu, 07 Nov 96 11:16:55 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: RE: The cartel begins to crumble? To: ietf@ietf.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611070420.aa09728@ietf.org> Source-Info: From (or Sender) name not authenticated. In article <199611020034.SAA15592@Jupiter.Mcs.Net>, karl@mcs.net (Karl Denninger) says: > 2. Limits would be applied to the number of "new" registrations and > organization could get within a window of time, to avoid registration > stuffing. ISPs act on behalf of their clients. They register dozens of DNs per day. How do we handle the ISPs and PSPs? I work for IBM Israel which as a number of PSPs that it services. As soon as they talk to a client, that day they submit the request for cola.co.il (after they talk to Pepsi) or for jeans.co.il (after they talk to Levi's). There is *no* way to verify whether indeed they have an actual client behind them with such a domain. We have seen PSPs request 30 DNs a day with just names out of the air. You cannot limit a company from doing registrations - either timewise of amountwise. This is their business and you can't make artifical rules to slow them down. The way out of this is to eliminate the ability to trade in DNs. If the rule was that a DN is not transferrable, then there would be no value to doing a large DN grab. See the Israeli DN policy at www.isoc.org.il If we find that a company trades in DNs, they lose all existing DNs. >Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity >http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo >Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ >Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal Hank Nussbacher Israel [the views expressed above are solely my own].   Received: from ietf.org by ietf.org id aa09905; 7 Nov 96 4:23 EST Received: from vm.biu.ac.il by ietf.org id aa09775; 7 Nov 96 4:21 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 0960; Thu, 07 Nov 96 11:19:02 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1926; Thu, 7 Nov 1996 11:19:02 +0200 Date: Thu, 07 Nov 96 11:18:40 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: Evaluating TLD proposal To: ietf@ietf.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611070423.aa09775@ietf.org> Source-Info: From (or Sender) name not authenticated. In article <2159.wsimpson@greendragon.com>, wsimpson@greendragon.com (William Allen Simpson) says: >Denninger also raises the valid point that the proposed fees and such >for the new registries do not apply to the existing registries. That is >excrable. If the IANA is to be supported by fees, then the largest >existing load should start right out by paying its fair share! Speaking only for myself, as only one member of the IAHC, I will work to make sure that any annual fees (if any) get applied across the board and not just to new TLDs. >I also have raised the issue in the past that this fee structure is not >the best we could devise. What is the purpose of an "application fee"? >Why have both a quarterly/yearly fee, and a percentage fee? > >Instead, I have recommended that the applicant post a "performance >bond". As in other corporate contracts, this bond would be used to pay >for rebidding and conversion to another contractor in the event that the >initial contractor defaults. It could earn interest. It could be >refundable at the termination of a successful contract. > >And I would make the quarterly fee entirely based on the number of >domain registrants. As noted, this is relatively simple to verify. It >makes more sense than administering 2 fees, one fixed and one variable, >or worrying about percentages. I initially agreed with you but over the weekend I thought about it and came to the conclusion that annual or quarterly fees is not a good idea. Scenerio: Company ABC gets the .inc domain. They run for a year and have 10,000 DNs. The IAHC fee per domain would be $1 per DN per year (just a number off the top of my head) and ABC gets billed $10K. One month later no money. Second bill goes out. No money two months later. Finally ABC lets it be known that it has no intention of paying the yearly fee and has spoken to almost all his customers and if their compname.inc disappears they (the individual companies) would sue IAC/ISOC/IETF/ITU/etc. I do not see the IAHC getting into a game of road-chicken to see who would blink first. This is but one scenerio. Having to collect a yearly fee may not be the wisest move. But that remains to be seen. > >This fee would be changed yearly to reflect the needed funds for the >IANA and IETF Secretariate. I would not use any fee to directly fund >root name servers, which for engineering reasons should be located at >(and funded by) the major topological exchanges as they are built. I would fund the root namservers located at the NAPs. The NAP is a commercial operation but the service itself of a root DNS is not. Again, I can be convinced otherwise if you can come up with good reasons why not to fund roots with the new TLD funds. > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 >BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Hank Nussbacher Israel   Received: from ietf.org by ietf.org id aa10418; 7 Nov 96 4:26 EST Received: from vm.biu.ac.il by ietf.org id aa09875; 7 Nov 96 4:23 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 0962; Thu, 07 Nov 96 11:20:10 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1930; Thu, 7 Nov 1996 11:20:11 +0200 Date: Thu, 07 Nov 96 11:19:43 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: The cartel begins to crumble? To: ietf@ietf.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611070426.aa09875@ietf.org> Source-Info: From (or Sender) name not authenticated. In article <199611020034.SAA15592@Jupiter.Mcs.Net>, karl@mcs.net (Karl Denninger) says: >The non-portable address problem has caused some of our incoming customers >REAL headaches. We have had people who just can't change providers BECAUSE >we can't route those addresses from 207.x.x.x, and nothing we can do fixes >this problem for them. They're screwed, absolutely and completely, and some >of them went out and did really crazy things (like embedding some of these >addresses into remote devices which are then shipped to offices around the >US, etc). > >Changing providers could be a $100,000+ event for these people. Yet we, as >providers, are asked to "accept" this tying arrangement (frankly, I think it >stinks -- but that's another thread.) PIX. That is your solution. Cisco sells it and solves all your address translation problems for far less than $100K. I do not work for Cisco. >Zones are transferrable. Its easily arguable that this is a self-healing >problem to a large extent. A dead registry is going to be a tangible, and >valuable, asset (assuming it has registrants in it -- if not the entire >discussion is moot and irrelavent). Company A sells DNs in their new .biz domain for a $200 one time fee (forever). Three years later they go bankrupt. Company B comes along and is willing to take over the .biz domain but cannot charge any existing customers since they have a piece of paper stating that their domain is cost free forever. An orphaned registry is only valuable if it has enough critical mass and many paying customers. >Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Hank Nussbacher Israel   Received: from ietf.org by ietf.org id aa10547; 7 Nov 96 4:27 EST Received: from vm.biu.ac.il by ietf.org id aa10301; 7 Nov 96 4:26 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 0963; Thu, 07 Nov 96 11:21:15 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1932; Thu, 7 Nov 1996 11:21:15 +0200 Date: Thu, 07 Nov 96 11:20:58 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: IAHC To: ietf@ietf.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611070426.aa10301@ietf.org> Source-Info: From (or Sender) name not authenticated. In article <199611012302.RAA13532@Jupiter.Mcs.Net>, karl@mcs.net (Karl Denninger) says: >And you get to define what the namespace of "The Internet" is, right? > >Or, more correctly, the IANA gets to define it? Disclaimer: I speak only for myself and am a member of the newly formed IAHC which will hopefully resolve this issue. I think the IANA has backed out of this so you have nothing to fear. It is now in the hands of a committee made up of people from ISOC, IETF, ITU, INTA, WIPA and what-have-you. The IANA has a minority voice. So just give us a bit of time, some good input and we will have the new iTLDs awarded in no time. >Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Hank Nussbacher Israel   Received: from ietf.org by ietf.org id aa10630; 7 Nov 96 4:28 EST Received: from vm.biu.ac.il by ietf.org id aa10502; 7 Nov 96 4:27 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 0964; Thu, 07 Nov 96 11:22:23 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1934; Thu, 7 Nov 1996 11:22:23 +0200 Date: Thu, 07 Nov 96 11:21:54 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: More iTLD thread To: ietf@ietf.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611070428.aa10502@ietf.org> Source-Info: From (or Sender) name not authenticated. In article <01BBC802.B4CACCE0@webster.unety.net>, JimFleming@unety.net (Jim Fleming) says: >In my opinion, I do not think that the NASA server should even be in >the set of "popular" root name servers because of the following reasons. > 1. As you have shown, it is not accessible. > 2. It is in North America, and more International coverage should > be encouraged. > 3. It is funded by U.S. taxpayers and as people have seen recently > as well as during the past few years, the U.S. Government > (mostly via the NSF) wants the Internet infrastructure to be > shifted to the commercial sector. Root name servers should > be no exception. Total agreement. The root nameservers should be funded via money raised in establishing any new iTLDs. That includes hardware, software and manpower to run a true root nameserver. There should be 4-5 in Europe, 2-3 in the Far East and about 6-7 in North America all funded via new iTLDs. > >Many people feel that the U.S.-centric attitudes of Internet Infrastructure >administration need to be down played and more emphasis needs to be >placed on the International nature of the Internet. One of the major complaints >that some people reported from a recent Harvard conference was a lack >of participation from the International community. As a former American who moved to Israel 15 years ago I have to agree with you. Americans are very geo-centric and have a hard time understanding the mentalities of other countries. >-- >Jim Fleming >UNETY Systems, Inc. >Naperville, IL Hank Nussbacher Israel   Received: from ietf.org by ietf.org id aa10876; 7 Nov 96 4:29 EST Received: from vm.biu.ac.il by ietf.org id aa10607; 7 Nov 96 4:29 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 0965; Thu, 07 Nov 96 11:23:24 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1936; Thu, 7 Nov 1996 11:23:24 +0200 Date: Thu, 07 Nov 96 11:22:57 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: The cartel begins to crumble? To: ietf@ietf.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611070429.aa10607@ietf.org> Source-Info: From (or Sender) name not authenticated. In article <199610310251.LAA11198@necom830.hpcl.titech.ac.jp>, mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) says: >You should and I do feel sympathy for those who can't step up to the >microphone in IETF meetings even though they are there and have >their own opinion. Speaking at a microphone at an IETF does not set a standard. Helping draft an RFC via email and being able to take the time to reply clearly, slowly and thoughtfully, even if it takes you 3x times as long as a native English speakers, is the ulminate equalizer. Only the loudest people grab the mike. There are many native English speakers who are in the same boat as you. > > Masataka Ohta Hank Nussbacher   Received: from ietf.org by ietf.org id aa11076; 7 Nov 96 4:33 EST Received: from vm.biu.ac.il by ietf.org id aa10954; 7 Nov 96 4:32 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 0968; Thu, 07 Nov 96 11:29:19 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1942; Thu, 7 Nov 1996 11:29:19 +0200 Date: Thu, 07 Nov 96 11:28:29 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: IAHC To: ietf@ietf.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611070432.aa10954@ietf.org> Source-Info: From (or Sender) name not authenticated. >According to the following, the IAHC is going to have 9 members. >Have all of those members been appointed yet...? Yes. > >If so, can you tell everyone who they are and who made the >appointments...? A press release will be issued this week. > >@@@@ http://www.isoc.org/whatsnew/iahc.html > >"The IAHC will be composed of representatives of the large >international Internet community. The International Telecommunication >Union (ITU), the World Intellectual Property Organization >(WIPO), and the International Trademark Association (INTA) will >designate one each. ISOC, IANA, and the Internet Architecture >Board (IAB) will each appoint two members for a total of nine." Here you have the answer to your 2nd question as to who made the appointments. > >@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > >Also, > >According to >"The IAHC will work in an open electronic forum soliciting advice, >comments, and counsel from a wide array of interested parties." > >Can you explain where the IAHC is holding discussions...? A new list will be out there hopefully within a few days. > >Was there a meeting in Washington, D.C. this week...? Yes. > If so, are the meeting notes on line...? No. > >Also, > >According to the following schedule, the formation of the IAHC >triggers the establishment of "Day 1". > >Can you explain when Day 1 occurred...?...(if it did) The timeline has been revised with firm dates and that too should be out there on the Internet very soon. > >@@@@ http://info.isoc.org/whatsnew/itlds.html > >Schedule of Events > >Day 1 IAHC formed >Day 30 IAHC finalizes procedures and publicly announces >Day 31 Begin accepting applications >Day 90 Acceptance of applications ceases >Day 135 IAHC announces registry selection and iTLDs >Day 136 ISOC begins contracting with selected registries >Day X ISOC notifies IANA that contract is complete >Day X + 1 IANA introduces new iTLDs to root zone file >Day X + 90 Registry begins operations > >@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > >-- >Jim Fleming >UNETY Systems, Inc. >Naperville, IL > >e-mail: >JimFleming@unety.net >JimFleming@unety.net.s0.g0 (EDNS/IPv8) Hank Nussbacher Israel   Received: from ietf.org by ietf.org id aa14259; 7 Nov 96 5:11 EST Received: from smtpgw.ed.nce.sita.int by ietf.org id aa13902; 7 Nov 96 5:10 EST Return-Path: Received: from rdsita.rd-sita.fr by smtpgw.ed.nce.sita.int (8.7.5/SitaNet-1.5) id LAA18341; Thu, 7 Nov 1996 11:07:48 +0100 (MET) Received: from slarsen.ed.nce.sita.int (pc-edstl.ed.nce.sita.int) by rdsita.rd-sita.fr (5.0/SMI-SVR4) id AA23578; Thu, 7 Nov 1996 11:08:22 --100 Message-Id: <3281B628.4333@ed.nce.sita.int> Date: Thu, 07 Nov 1996 11:12:56 +0100 Sender:ietf-request@ietf.org From: Steen Larsen Reply-To: steen.larsen@ed.nce.sita.int Organization: SITA R&D Nice X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: Hank Nussbacher Cc: ietf@ietf.org Subject: Trading domain names References: <9611070420.aa09728@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Hank Nussbacher wrote: > > ...... > The way out of this is to eliminate the ability to trade in DNs. If > the rule was that a DN is not transferrable, then there would be > no value to doing a large DN grab. See the Israeli DN policy > at www.isoc.org.il If we find that a company trades in DNs, they > lose all existing DNs. At first this looks like a good idea. But there would be lots of loopholes around this. One obvious way is to create a Delaware, British Virgin Islands, etc. company that owns the domain name. Instead of trading the name you simply trade the company. Well, maybe your idea isn't so bad anyway, using the loophole costs money. That could be a limiting factor stopping people from grabbing hundreds of domain names for future re-sale. Best regards Steen -- Steen Koefoed Larsen Disclaimer: This letter may contain pure garbage that differs from the opinion of myself and the companies I work for. SITA -- Societe Internationale de Telecommunications Aeronautiqes R & D Nice, Heraklion - 1041 Route des Dolines, F-06560 Valbonne Phone: +33 4 92.96.63.67, Fax: +33 4 92.96.64.92, SITATEX: NCEEMXS E-mail@home: steenkl@dircon.co.uk, GSM Mobile: +45 40512486 *** Syntax? Why not - they tax everything else! ***   Received: from ietf.org by ietf.org id aa18919; 7 Nov 96 7:28 EST Received: from fxiod01.is.chrysler.com by ietf.org id aa18427; 7 Nov 96 7:18 EST Received: by fxiod01.is.chrysler.com; id AA20219; Thu, 7 Nov 96 07:17:51 EST Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod01.is.chrysler.com via smap (V3.1.1) id xma020214; Thu, 7 Nov 96 07:17:48 -0500 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA24649; Thu, 7 Nov 1996 07:07:11 -0500 (EST) Message-Id: <3.0b36.32.19961107070838.00b52c50@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Thu, 07 Nov 1996 07:17:16 -0500 To: Hank Nussbacher , ietf@ietf.org Sender:ietf-request@ietf.org From: Robert Moskowitz Subject: Re: More iTLD thread Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. At 11:21 AM 11/7/96 IDT, Hank Nussbacher wrote: >In article <01BBC802.B4CACCE0@webster.unety.net>, JimFleming@unety.net (Jim >Fleming) says: >>In my opinion, I do not think that the NASA server should even be in >>the set of "popular" root name servers because of the following reasons. >> 1. As you have shown, it is not accessible. >> 2. It is in North America, and more International coverage should >> be encouraged. >> 3. It is funded by U.S. taxpayers and as people have seen recently >> as well as during the past few years, the U.S. Government >> (mostly via the NSF) wants the Internet infrastructure to be >> shifted to the commercial sector. Root name servers should >> be no exception. > >Total agreement. The root nameservers should be funded via money >raised in establishing any new iTLDs. That includes hardware, software >and manpower to run a true root nameserver. There should be 4-5 in >Europe, 2-3 in the Far East and about 6-7 in North America all funded >via new iTLDs. As a member of the FNCAC (carefully watch which hat I am wearing :), I am not sure I agree. If there is a reachablity problem with the NASA server, that might have to be fixed. But the US gov may want a level of assurance that their systems can resolve names. Afterall, currently they have the largest # of TLDs! Robert Moskowitz Chrysler Corporation (810) 758-8212   Received: from ietf.org by ietf.org id aa19342; 7 Nov 96 7:42 EST Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa19249; 7 Nov 96 7:40 EST Sender:ietf-request@ietf.org From: Masataka Ohta Message-Id: <199611071158.UAA14489@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA14489; Thu, 7 Nov 1996 20:57:54 +0859 Subject: Re: The cartel begins to crumble? To: Hank Nussbacher Date: Thu, 7 Nov 96 20:57:53 JST Cc: ietf@ietf.org In-Reply-To: <9611070429.aa10607@ietf.org>; from "Hank Nussbacher" at Nov 7, 96 11:22 am X-Mailer: ELM [version 2.3 PL11] Source-Info: From (or Sender) name not authenticated. > Speaking at a microphone at an IETF does not set a standard. Helping > draft an RFC via email and being able to take the time to reply > clearly, slowly and thoughtfully, even if it takes you 3x times > as long as a native English speakers, is the ulminate equalizer. Wrong. You ignore the importance of the face to face meetings. If you disagree, we should stop having face to face meetings spending a lot of travel expenses, which is a very good equalizer. > Only the loudest people grab the mike. There are many native > English speakers who are in the same boat as you. Exactly. And that's the problem. Note that *I* have no difficulty to grab the mike. Masataka Ohta   Received: from ietf.org by ietf.org id aa23549; 7 Nov 96 9:40 EST Received: from localhost by ietf.org id aa22622; 7 Nov 96 9:32 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-procrules-00.txt, .ps Date: Thu, 07 Nov 1996 09:32:46 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611070932.aa22622@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules Author(s) : R. Braden, L. Zhang Filename : draft-ietf-rsvp-procrules-00.txt, .ps Pages : 26 Date : 11/05/1996 This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-procrules-00.txt". Or "get draft-ietf-rsvp-procrules-00.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-procrules-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-procrules-00.txt". Or "FILE /internet-drafts/draft-ietf-rsvp-procrules-00.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961105152159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-procrules-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-procrules-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961105152159.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23535; 7 Nov 96 9:40 EST Received: from localhost by ietf.org id aa22595; 7 Nov 96 9:32 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: namedroppers@internic.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsind-clarify-02.txt Date: Thu, 07 Nov 1996 09:32:41 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611070932.aa22595@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS IXFR, Notification, and Dynamic Update Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Clarifications to the DNS Specification Author(s) : R. Elz, R. Bush Filename : draft-ietf-dnsind-clarify-02.txt Pages : 8 Date : 11/06/1996 This draft considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. Four separate issues are considered: + IP packet header address usage from multi-homed servers, + TTLs in sets of records with the same name, class, and type, + the issue of what is an authoritative, or canonical, name, + and the issue of what makes a valid DNS label. The first two of these are areas where the correct behaviour has been somewhat unclear, we seek to rectify that. The other two are already adequately specified, however the specifications seem to be sometimes ignored. We seek to reinforce the existing specification. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsind-clarify-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-clarify-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnsind-clarify-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961106135015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsind-clarify-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsind-clarify-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961106135015.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23555; 7 Nov 96 9:40 EST Received: from localhost by ietf.org id aa22553; 7 Nov 96 9:32 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ota-http-version-00.txt Date: Thu, 07 Nov 1996 09:32:11 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611070932.aa22553@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Version management with meta-level links via HTTP/1.1 Author(s) : K. Ota, K. Takahashi, K. Sekiya Filename : draft-ota-http-version-00.txt Pages : 5 Date : 11/06/1996 This draft describes version management of the resources with some extensions to HTTP/1.1. The main point of our approach is to use meta-level links, which is not an anchor of HTML format, but an attribute of the resource. So, the contents need not to be an HTML format. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ota-http-version-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ota-http-version-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ota-http-version-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961106103826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ota-http-version-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ota-http-version-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961106103826.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23536; 7 Nov 96 9:40 EST Received: from localhost by ietf.org id aa22570; 7 Nov 96 9:32 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mobile-ip@smallworks.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-liyunzhou-mobileip-ppm-00.txt, .ps Date: Thu, 07 Nov 1996 09:32:25 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611070932.aa22570@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proximity Proxies for Mobile Nodes and Mobility Agents (PPM) Author(s) : Y. Li Filename : draft-liyunzhou-mobileip-ppm-00.txt, .ps Pages : 23 Date : 11/06/1996 This document aims to explore an approach for the interoperability testing of Mobile IP implementations across the Internet. It proposes client/server proximity proxies, two intermediate entities between the mobile node and the mobility agent. This model can be used to solve the problem addressed in the hierarchical foreign agents model. The document proposes to build a tunnel between proximity proxies using Tunnel Request and Tunnel Reply messages, and enable routing policies to the tunnel by using Proxy Update message and adding a bit in Agent Advertisement message. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-liyunzhou-mobileip-ppm-00.txt". Or "get draft-liyunzhou-mobileip-ppm-00.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-liyunzhou-mobileip-ppm-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-liyunzhou-mobileip-ppm-00.txt". Or "FILE /internet-drafts/draft-liyunzhou-mobileip-ppm-00.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961106110438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-liyunzhou-mobileip-ppm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-liyunzhou-mobileip-ppm-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961106110438.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa24152; 7 Nov 96 9:45 EST Received: from localhost by ietf.org id aa22613; 7 Nov 96 9:32 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-spec-14.txt, .ps Date: Thu, 07 Nov 1996 09:32:44 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611070932.aa22613@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification Author(s) : R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin Filename : draft-ietf-rsvp-spec-14.txt, .ps Pages : 104 Date : 11/06/1996 This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-spec-14.txt". Or "get draft-ietf-rsvp-spec-14.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-spec-14.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-spec-14.txt". Or "FILE /internet-drafts/draft-ietf-rsvp-spec-14.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961106115231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-spec-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-spec-14.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961106115231.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa24668; 7 Nov 96 9:52 EST Received: from [207.32.128.130] by ietf.org id aa24534; 7 Nov 96 9:50 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id IAA24263; Thu, 7 Nov 1996 08:41:59 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCC87.CC6A7240@webster.unety.net>; Thu, 7 Nov 1996 08:43:50 -0600 Message-ID: <01BBCC87.CC6A7240@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Hank Nussbacher' , "ietf@ietf.org" Cc: 'New Newdom' Subject: RE: More iTLD thread Date: Thu, 7 Nov 1996 08:43:48 -0600 Encoding: 83 TEXT Source-Info: From (or Sender) name not authenticated. On Thursday, November 07, 1996 5:21 AM, Hank Nussbacher[SMTP:HANK@vm.biu.ac.il] wrote: @ In article <01BBC802.B4CACCE0@webster.unety.net>, JimFleming@unety.net (Jim @ Fleming) says: @ >In my opinion, I do not think that the NASA server should even be in @ >the set of "popular" root name servers because of the following reasons. @ > 1. As you have shown, it is not accessible. @ > 2. It is in North America, and more International coverage should @ > be encouraged. @ > 3. It is funded by U.S. taxpayers and as people have seen recently @ > as well as during the past few years, the U.S. Government @ > (mostly via the NSF) wants the Internet infrastructure to be @ > shifted to the commercial sector. Root name servers should @ > be no exception. @ @ Total agreement. The root nameservers should be funded via money @ raised in establishing any new iTLDs. That includes hardware, software @ and manpower to run a true root nameserver. There should be 4-5 in @ Europe, 2-3 in the Far East and about 6-7 in North America all funded @ via new iTLDs. @ @ > @ >Many people feel that the U.S.-centric attitudes of Internet Infrastructure @ >administration need to be down played and more emphasis needs to be @ >placed on the International nature of the Internet. One of the major complaints @ >that some people reported from a recent Harvard conference was a lack @ >of participation from the International community. @ @ As a former American who moved to Israel 15 years ago I have to agree @ with you. Americans are very geo-centric and have a hard time understanding @ the mentalities of other countries. @ @ >-- @ >Jim Fleming @ >UNETY Systems, Inc. @ >Naperville, IL @ @ Hank Nussbacher @ Israel @ @ I think that many of the people that have been working on these issues for many months on the "newdom" mailing list will appreciate your comments. One of the modest goals proposed and being discussed on that mailing list is the documenting of 64 root name servers scattered around the world. With Root 64, ISPs and system administrators would be able to make a better engineering decision on which name servers they wish to include in their "root.cache" file. Also discussed on that list is a "round table" decision making model, where the owners of those root name servers, in concert with the ISPs and top level domain registries, will work together to decide which top level domains to support. In my opinion, the round table model allows natural market forces to control the evolution as opposed to a few people. Customers have input into the process by the economic support of the ISPs and registries via their registration fees. If you are interested in following those discussions on the newdom list, there is a web site with more information. Thanks again for your comments. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa26232; 7 Nov 96 10:09 EST Received: from localhost by ietf.org id aa26021; 7 Nov 96 10:07 EST To: ietf@ietf.org Subject: Re: The cartel begins to crumble? Sender:ietf-request@ietf.org From: Bill Wohler Date: Thu, 07 Nov 1996 10:07:26 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611071007.aa26021@ietf.org> Source-Info: From (or Sender) name not authenticated. karl@mcs.net (Karl Denninger) writes: >> OK, I'll bite. I hereby claim all TLDs that no one has yet registered with >> either Alternic or IANA. >More reduction to the absurd. If there isn't central control, it isn't absurd at all. Take the real-life example of the thousands of domains that have already gotten nuked once billing began. And there was even control in place--somewhat. What, besides ethics, keeps me from running the equivalent of: newtld `echo 1*3[a-z] | egrep -v '(edu|com|gov|...)'` Considering the amount of spam and other sludge on the net, I would hardly leave this to ethics of the netizens of the planet. I am not warm to opening up the TLDs, but we may have to do this in the future. One must be ensured that the root servers contain all the TLDs, and that all the root servers contain the same data. -- Bill Wohler ph: +1-415-854-1857 fax: +1-415-854-3195 Say it with MIME. Maintainer of comp.mail.mh and news.software.nn FAQs. If you're passed on the right, you're in the wrong lane.   Received: from ietf.org by ietf.org id aa26368; 7 Nov 96 10:10 EST Received: from localhost by ietf.org id aa26299; 7 Nov 96 10:09 EST To: ietf@ietf.org Sender:ietf-request@ietf.org From: "Dale R. Worley" Subject: Standards conformance (was: The Cartel Begins to Crumble) Date: Thu, 07 Nov 1996 10:09:45 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611071009.aa26299@ietf.org> Source-Info: From (or Sender) name not authenticated. In article <199611011724.MAA02841@jekyll.piermont.com> perry@piermont.com ("Perry E. Metzger") writes: I believe that most of the firms that have seriously flouted standards in the past (Wang comes to mind) have been punished in the marketplace. It's a very complicated issue, but in the long run, that seems to be true. The minicomputer industry in Massachusetts, USA was dominated by four companies (Digital, Wang, Data General, and Prime) which built and sold proprietary systems for twenty years or so. And they were able to charge a high markup on their hardware, but sold their software at low prices. Around the end of the 1980's, Unix became popular enough that many customers switched from proprietary operating systems. The four minicomputer companies attempted to resist the change, because they would have to sell Unix-based systems for considerably less than they sold equivalent proprietary systems. The marketplace took its revenge. Wang and Prime are effectively dead, though they remain in business. Data General concentrates on other lines of business than computer sales. Only Digital remains as a mass seller of computer systems, but is much smaller than it was. Massachusetts suffered severe economic stress. So successfully flouting popular standards seems to be possible, but over long periods of time, it is probably not sustainable. Dale -- Dale R. Worley Ariadne Internet Services Voice: +1 617-899-7949 Fax: +1 617-899-7946 E-mail: worley@ariadne.com "Internet-based electronic commerce solutions to real business problems."   Received: from ietf.org by ietf.org id aa00400; 7 Nov 96 11:22 EST Received: from Kitten.mcs.com by ietf.org id aa00202; 7 Nov 96 11:20 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA29529; Thu, 7 Nov 1996 10:19:04 -0600 (CST) Received: from Mercury.mcs.net (karl@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA11379; Thu, 7 Nov 1996 10:19:03 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA18711; Thu, 7 Nov 1996 10:19:02 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611071619.KAA18711@Mercury.mcs.net> Subject: Re: The cartel begins to crumble? To: Hank Nussbacher Date: Thu, 7 Nov 1996 10:19:02 -0600 (CST) Cc: ietf@ietf.org In-Reply-To: <9611070426.aa09875@ietf.org> from "Hank Nussbacher" at Nov 7, 96 11:19:43 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > >Zones are transferrable. Its easily arguable that this is a self-healing > >problem to a large extent. A dead registry is going to be a tangible, and > >valuable, asset (assuming it has registrants in it -- if not the entire > >discussion is moot and irrelavent). > > Company A sells DNs in their new .biz domain for a $200 one time > fee (forever). Three years later they go bankrupt. Company B > comes along and is willing to take over the .biz domain but > cannot charge any existing customers since they have a piece of > paper stating that their domain is cost free forever. > > An orphaned registry is only valuable if it has enough critical > mass and many paying customers. Bad assumption. If a TLD is desirable, it will have NEW customers. If it has no customers, there is no disruption when it disappears. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa00401; 7 Nov 96 11:22 EST Received: from Kitten.mcs.com by ietf.org id aa00180; 7 Nov 96 11:19 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA29449; Thu, 7 Nov 1996 10:17:13 -0600 (CST) Received: from Mercury.mcs.net (karl@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA11044; Thu, 7 Nov 1996 10:17:12 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA18637; Thu, 7 Nov 1996 10:17:10 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611071617.KAA18637@Mercury.mcs.net> Subject: Re: The cartel begins to crumble? To: Hank Nussbacher Date: Thu, 7 Nov 1996 10:17:10 -0600 (CST) Cc: ietf@ietf.org In-Reply-To: <9611070420.aa09728@ietf.org> from "Hank Nussbacher" at Nov 7, 96 11:16:55 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > In article <199611020034.SAA15592@Jupiter.Mcs.Net>, karl@mcs.net (Karl > Denninger) says: > > 2. Limits would be applied to the number of "new" registrations and > > organization could get within a window of time, to avoid registration > > stuffing. > > ISPs act on behalf of their clients. They register dozens of DNs > per day. How do we handle the ISPs and PSPs? I work for IBM Israel > which as a number of PSPs that it services. As soon as they talk to > a client, that day they submit the request for cola.co.il (after > they talk to Pepsi) or for jeans.co.il (after they talk to Levi's). > There is *no* way to verify whether indeed they have an actual > client behind them with such a domain. We have seen PSPs request 30 > DNs a day with just names out of the air. I'm talking about *TLDs*, not second-level delegations. Frankly, we request 30 DNs a day sometimes. Its not unusual at all. > You cannot limit a company from doing registrations - either > timewise of amountwise. This is their business and you can't > make artifical rules to slow them down. Nobody is trying to in THAT case. > The way out of this is to eliminate the ability to trade in DNs. If > the rule was that a DN is not transferrable, then there would be > no value to doing a large DN grab. See the Israeli DN policy > at www.isoc.org.il If we find that a company trades in DNs, they > lose all existing DNs. How do you prove it? Are you willing to get sued if you're wrong, and potentially be liable not only for real lost business (millions of US $) but ALSO punitive damages? Why does ANYONE want that kind of liability. Three standards to adhere to: 1)Verifyability 2)Objectivity 3)Serves the purpose You need to meet all three. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa00550; 7 Nov 96 11:24 EST Received: from Kitten.mcs.com by ietf.org id aa00466; 7 Nov 96 11:23 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA29791; Thu, 7 Nov 1996 10:22:53 -0600 (CST) Received: from Mercury.mcs.net (karl@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA12167; Thu, 7 Nov 1996 10:22:52 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA19008; Thu, 7 Nov 1996 10:22:51 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611071622.KAA19008@Mercury.mcs.net> Subject: Re: IAHC To: Hank Nussbacher Date: Thu, 7 Nov 1996 10:22:50 -0600 (CST) Cc: ietf@ietf.org In-Reply-To: <9611070426.aa10301@ietf.org> from "Hank Nussbacher" at Nov 7, 96 11:20:58 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > In article <199611012302.RAA13532@Jupiter.Mcs.Net>, karl@mcs.net (Karl > Denninger) says: > >And you get to define what the namespace of "The Internet" is, right? > > > >Or, more correctly, the IANA gets to define it? > > Disclaimer: I speak only for myself and am a member of the newly formed > IAHC which will hopefully resolve this issue. > > I think the IANA has backed out of this so you have nothing to fear. It > is now in the hands of a committee made up of people from ISOC, IETF, > ITU, INTA, WIPA and what-have-you. The IANA has a minority voice. > > So just give us a bit of time, some good input and we will have the new > iTLDs awarded in no time. How did the COMMITTEE get the authority? There was no open process. There were no public nominations. There ARE people on the committee (one in particular comes to mind) who have made a practice of insinuating that people are committing CRIMINAL acts by supporting eDNS (specifically, allegations of "fraud") There is no "resume", or curriculum vitae, on the members available. There is no public process, mechanism for public comment, nor public record of discussions and vote(s) within the committee. None of this speaks highly towards this being an "open" process. Quite to the contrary. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa00985; 7 Nov 96 11:30 EST Received: from cnri by ietf.org id aa00913; 7 Nov 96 11:29 EST Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14017; 7 Nov 96 11:29 EST Received: from hydra_nt_server (hydrainc.com) by venera.isi.edu (5.65c/5.61+local-25) id ; Thu, 7 Nov 1996 08:22:39 -0800 Received: from [206.233.77.6] by hydra_nt_server (NTMail 3.00.06) id aa006198 Thu, 7 Nov 96 16:17:16 -0800 (GMT) Received: by 206.233.77.2.hydrainc.com with Microsoft Mail id <01BBCC83.8A77A6E0@206.233.77.2.hydrainc.com>; Thu, 7 Nov 1996 08:13:21 -0800 Message-Id: <01BBCC83.8A77A6E0@206.233.77.2.hydrainc.com> Sender:ietf-request@ietf.org From: Pratima JanakiRam To: "ietf@isi.edu" Subject: RE: Date: Thu, 7 Nov 1996 08:13:18 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. unsubscribe comsoc-conferences ietf@isi.edu   Received: from ietf.org by ietf.org id aa01178; 7 Nov 96 11:33 EST Received: from Kitten.mcs.com by ietf.org id aa01035; 7 Nov 96 11:31 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA00216; Thu, 7 Nov 1996 10:30:38 -0600 (CST) Received: from Mercury.mcs.net (karl@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA13732; Thu, 7 Nov 1996 10:30:36 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA19324; Thu, 7 Nov 1996 10:30:35 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611071630.KAA19324@Mercury.mcs.net> Subject: Re: More iTLD thread To: rgm3@chrysler.com Date: Thu, 7 Nov 1996 10:30:33 -0600 (CST) Cc: HANK@vm.biu.ac.il, ietf@ietf.org In-Reply-To: <3.0b36.32.19961107070838.00b52c50@pop3hub.is.chrysler.com> from "Robert Moskowitz" at Nov 7, 96 07:17:16 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > At 11:21 AM 11/7/96 IDT, Hank Nussbacher wrote: > >Total agreement. The root nameservers should be funded via money > >raised in establishing any new iTLDs. That includes hardware, software > >and manpower to run a true root nameserver. There should be 4-5 in > >Europe, 2-3 in the Far East and about 6-7 in North America all funded > >via new iTLDs. > > As a member of the FNCAC (carefully watch which hat I am wearing :), I am > not sure I agree. If there is a reachablity problem with the NASA server, > that might have to be fixed. But the US gov may want a level of assurance > that their systems can resolve names. Afterall, currently they have the > largest # of TLDs! > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 I happen to agree with Robert. The only way you solve the root mess (really fix it) is to have enough geographic AND line-of-use diversity that everyone is comfortable. Root-64 is one way to do that (there's not enough of a cohesive policy statement as of yet for me to know if I like the details in that devil or not at this point). IMHO you need to take into account: 1)Net topology (ie: you want multiple roots "close" to you for performance reasons). 2)Increased count of servers in total (you want fast service, and since the number of queries is growing, you need to have more of them. This implies that you MUST have confederations of servers, since there is that ugly packet-size restriction on the responses for the "additional info" field). The funny part of it is that I'm not at all certain that the user has to stay within the confederation. That is, what happens if you choose 100 root nameservers to list, and each belongs to a confederation that includes no more than 13. Leave aside the synchronization issue, and assume all have the same data in them. I'd be quite interested in knowing if BIND will spit up under these circumstances..... and intend to test it. I believe the answer is "no, it will not". -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa02211; 7 Nov 96 11:57 EST Received: from ng.netgate.net by ietf.org id aa01963; 7 Nov 96 11:55 EST Received: from [205.214.160.114] (d89.netgate.net [205.214.160.125]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id IAA25566; Thu, 7 Nov 1996 08:57:07 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <9611070426.aa10301@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Nov 1996 08:42:46 -0800 To: Hank Nussbacher Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: IAHC Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 12:20 AM -0800 11/7/96, Hank Nussbacher wrote: >I think the IANA has backed out of this so you have nothing to fear. It >is now in the hands of a committee made up of people from ISOC, IETF, >ITU, INTA, WIPA and what-have-you. The IANA has a minority voice. (also speaking strictly personally, though also serving as a member of the IAHC...) Let me emphasize Hank's point: A number of the members of the committee are participating explicitly as "representatives" of specific organizations. I believe none of the 5 "Internet" appointees are participating with an explicit representational responsibility more specific than "Internet". For example I was appointed by IANA but am not serving as its representative. (I couldn't, even if I wanted to, since I have had no involvement in its operation, ever. =46urther, I am not consulting IANA about the details of my participation an= d they are not requesting me to.) I think that organizational representations on the IAHC are fine. In the case of those from the Internet "side" it's simply that the appropriate scope of the "organization" is Internet-generic, rather than being limited to any one of its component groups. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa02772; 7 Nov 96 12:03 EST Received: from Kitten.mcs.com by ietf.org id aa02674; 7 Nov 96 12:02 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id LAA01612; Thu, 7 Nov 1996 11:00:56 -0600 (CST) Received: from Mercury.mcs.net (karl@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id LAA20049; Thu, 7 Nov 1996 11:00:54 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id LAA21173; Thu, 7 Nov 1996 11:00:48 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611071700.LAA21173@Mercury.mcs.net> Subject: Re: The cartel begins to crumble? To: Bill Wohler Date: Thu, 7 Nov 1996 11:00:48 -0600 (CST) Cc: ietf@ietf.org In-Reply-To: <9611071007.aa26021@ietf.org> from "Bill Wohler" at Nov 7, 96 10:07:26 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > karl@mcs.net (Karl Denninger) writes: > >> OK, I'll bite. I hereby claim all TLDs that no one has yet registered with > >> either Alternic or IANA. > > >More reduction to the absurd. > > If there isn't central control, it isn't absurd at all. Take the > real-life example of the thousands of domains that have already gotten > nuked once billing began. And there was even control in > place--somewhat. Let's be real. Right now you can register a SLD without nameservers operating from IANA's "sponsored" iTLDs! You CANNOT do that in .BIZ, .CORP, or .NPO. I do not believe you can do it in MOST of the eDNS namespace. What prevents people from doing this is simple -- a rule that you have to have an OPERATIONAL registry online, and really be taking registrations within 30 days or you lose the delegation PERMANENTLY. Second, I do support *rational* limits on the number of delegations an organziation or related set of organizations can hold (say, 20), with no more than 3-5 in the pipe at any given time. All this has been clearly explained in other messages I've posted here and elsewhere on this topic. As for synchronizing the roots, what's wrong with a zone transfer? The Alternic eDNS has been using it -- it WORKS. Unlike FTPing a file around, which has this ugly habit of failing without telling anyone, the eDNS servers to date have remained synchronized (within a few hours of an update, of course). > Bill Wohler ph: +1-415-854-1857 fax: +1-415-854-3195 -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa03592; 7 Nov 96 12:12 EST Received: from drwho.aspect.com.au by ietf.org id aa03473; 7 Nov 96 12:11 EST Return-Path: Phill.Kelley@aspect.com.au Received: from cbrgw.aspect.com.au (cbrgw.aspect.com.au [137.76.6.10]) by drwho.aspect.com.au (8.6.12/8.7) with ESMTP id CAA09965 for ; Fri, 8 Nov 1996 02:52:21 +1100 Received: from [137.76.60.51] (cbrxs1a1.cbr.aspect.com.au [137.76.60.51]) by cbrgw.aspect.com.au (8.6.12/8.7) with ESMTP id CAA14602 for ; Fri, 8 Nov 1996 02:52:13 +1100 X-Sender: kelleyp@cbrgw.aspect.com.au (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Nov 1996 23:13:00 -0800 To: ietf@ietf.org Sender:ietf-request@ietf.org From: Phill Kelley Subject: The price of chatter Source-Info: From (or Sender) name not authenticated. G'Day! I have been out of my home town for the past week and have just called long-distance to clear my email. There were some 170 messages which the wonderful "check your own bill" service on the hotel TV tells me cost $US35 to download. Over 100 of the messages were from the IETF list. I subscribed to the IETF list primarily because I wanted a simple way of keeping up with new RFCs. I must admit to not being overly interested in tracking the drafts but I took it that this came with the territory. I will also admit that I have even gained useful information from watching a number of the discussions as the regular contributors have stated their positions. However, recently I have formed the view that, increasingly, the majority of the general subject matter has little relevance to my needs. I have observed that many subscribers to the list simply decide to unsubscribe. Given that those are the people who write to this list instead of ietf-request, I assume that these visible departures are merely the tip of the iceberg. Before I follow this group who have voted with their e-feet, I want to ask if it is possible to be subscribed only to the RFC announcements, without the RFC drafts and without the general discussion? Regards, PK   Received: from ietf.org by ietf.org id aa05463; 7 Nov 96 12:35 EST Received: from [207.32.128.130] by ietf.org id aa05250; 7 Nov 96 12:33 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA24665; Thu, 7 Nov 1996 11:22:23 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCC9E.360AD800@webster.unety.net>; Thu, 7 Nov 1996 11:24:16 -0600 Message-ID: <01BBCC9E.360AD800@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: Hank Nussbacher , "ietf@ietf.org" Cc: 'New Newdom' Subject: RE: More iTLD thread Date: Thu, 7 Nov 1996 11:24:15 -0600 Encoding: 56 TEXT Source-Info: From (or Sender) name not authenticated. On Thursday, November 07, 1996 6:17 AM, Robert Moskowitz[SMTP:rgm3@chrysler.com] wrote: @ At 11:21 AM 11/7/96 IDT, Hank Nussbacher wrote: @ >In article <01BBC802.B4CACCE0@webster.unety.net>, JimFleming@unety.net (Jim @ >Fleming) says: @ >>In my opinion, I do not think that the NASA server should even be in @ >>the set of "popular" root name servers because of the following reasons. @ >> 1. As you have shown, it is not accessible. @ >> 2. It is in North America, and more International coverage should @ >> be encouraged. @ >> 3. It is funded by U.S. taxpayers and as people have seen recently @ >> as well as during the past few years, the U.S. Government @ >> (mostly via the NSF) wants the Internet infrastructure to be @ >> shifted to the commercial sector. Root name servers should @ >> be no exception. @ > @ >Total agreement. The root nameservers should be funded via money @ >raised in establishing any new iTLDs. That includes hardware, software @ >and manpower to run a true root nameserver. There should be 4-5 in @ >Europe, 2-3 in the Far East and about 6-7 in North America all funded @ >via new iTLDs. @ @ As a member of the FNCAC (carefully watch which hat I am wearing :), I am @ not sure I agree. If there is a reachablity problem with the NASA server, @ that might have to be fixed. But the US gov may want a level of assurance @ that their systems can resolve names. Afterall, currently they have the @ largest # of TLDs! @ @ @ Robert Moskowitz @ Chrysler Corporation @ (810) 758-8212 @ @ @ I also think that ISPs need some level of assurance that their systems can resolve names. While they might currently enjoy the luxury of using U.S. Government machines, it is prudent for them to be aware that those machines are largely run by volunteers who may not have "signed up" for the commercial requirements of the Internet. There are also privacy issues that people do not seem to be concerned about. Some people, especially outside of the U.S. may not want the U.S. Government tracking all of the names people are looking up. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa07750; 7 Nov 96 13:05 EST Received: from black-ice.cc.vt.edu by ietf.org id aa07641; 7 Nov 96 13:03 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id MAA72100; Thu, 7 Nov 1996 12:58:03 -0500 Message-Id: <199611071758.MAA72100@black-ice.cc.vt.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: Karl Denninger Cc: Hank Nussbacher , ietf@ietf.org Subject: Re: The cartel begins to crumble? In-Reply-To: Your message of "Thu, 07 Nov 1996 10:19:02 CST." <199611071619.KAA18711@Mercury.mcs.net> Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <199611071619.KAA18711@Mercury.mcs.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1085719768P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 07 Nov 1996 12:58:03 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_-1085719768P Content-Type: text/plain; charset=us-ascii On Thu, 07 Nov 1996 10:19:02 CST, Karl Denninger said: > If a TLD is desirable, it will have NEW customers. > > If it has no customers, there is no disruption when it disappears. Almost but not quite right. Something can be desirable for the "latest and greatest" followers, but not have any staying power. See pet rocks for an example. Would *you* buy the assets of a now-bankrupt producer of pet rocks, hoping that continued revenue would keep you afloat? -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_-1085719768P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMoIjKdQBOOoptg9JAQEcpAP+P2cXO1q/wge6cIYBE2Yhy1x0N/TIh7tr NOocu9B2mcvBk4PsHKWB+xPYHkAvncyAU45X6IaR1F6ejCtzcmLB0XRj3oh0Y1JZ riLAjUkthzxHVijImO8rqOlzPVBUWQaaTbsR1HPP2PTIGGeZJ/juXsLT1WTtsGwU lP4Q+BJM6tg= =7/Ib -----END PGP MESSAGE----- --==_Exmh_-1085719768P--   Received: from ietf.org by ietf.org id aa12092; 7 Nov 96 13:49 EST Received: from eunet.EU.net by ietf.org id aa11946; 7 Nov 96 13:47 EST Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id TAA10094; Thu, 7 Nov 1996 19:46:51 +0100 (MET) Received: by jotun.EU.net id AA28484 (5.67a/IDA-1.5); Thu, 7 Nov 1996 19:46:50 +0100 Message-Id: <199611071846.AA28484@jotun.EU.net> Sender:ietf-request@ietf.org From: Per Gregers Bilse Date: Thu, 7 Nov 1996 19:46:50 +0100 In-Reply-To: <199611071622.KAA19008@Mercury.mcs.net> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Karl Denninger Subject: Re: IAHC Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. On Nov 7, 10:22, Karl Denninger wrote: > How did the COMMITTEE get the authority? > >[...] > > None of this speaks highly towards this being an "open" process. > > Quite to the contrary. How does your, Fleming's, et als "process" line up? -- ------ ___ --- Per G. Bilse, Mgr Network Operations ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse@EU.net   Received: from ietf.org by ietf.org id aa14044; 7 Nov 96 14:09 EST Received: from taunivm.tau.ac.il by ietf.org id aa13805; 7 Nov 96 14:07 EST Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 5940; Thu, 07 Nov 96 21:06:21 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0339; Thu, 7 Nov 1996 21:06:21 +0200 Date: Thu, 07 Nov 96 21:04:07 IST Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: More iTLD thread To: Robert Moskowitz , Hank Nussbacher , ietf@ietf.org In-Reply-To: Message of Thu, 07 Nov 1996 07:17:16 -0500 from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071408.aa13805@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 07 Nov 1996 07:17:16 -0500 you said: >>Total agreement. The root nameservers should be funded via money >>raised in establishing any new iTLDs. That includes hardware, software >>and manpower to run a true root nameserver. There should be 4-5 in >>Europe, 2-3 in the Far East and about 6-7 in North America all funded >>via new iTLDs. > >As a member of the FNCAC (carefully watch which hat I am wearing :), I am >not sure I agree. If there is a reachablity problem with the NASA server, >that might have to be fixed. But the US gov may want a level of assurance >that their systems can resolve names. Afterall, currently they have the >largest # of TLDs! You don't agree that new iTLD money should fund the root servers or you don't agree to have a wide geographical spread (can be even 20)? Nothing wrong with NASA getting a few bucks to fund the root server in my opinion. If they choose to relinquish the money - the more root servers we can add and fund. -Hank > > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 >   Received: from ietf.org by ietf.org id aa14189; 7 Nov 96 14:11 EST Received: from eunet.EU.net by ietf.org id aa14101; 7 Nov 96 14:10 EST Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id UAA11254; Thu, 7 Nov 1996 20:09:34 +0100 (MET) Received: by jotun.EU.net id AA28589 (5.67a/IDA-1.5); Thu, 7 Nov 1996 20:09:34 +0100 Message-Id: <199611071909.AA28589@jotun.EU.net> Sender:ietf-request@ietf.org From: Per Gregers Bilse Date: Thu, 7 Nov 1996 20:09:34 +0100 In-Reply-To: <199611071700.LAA21173@Mercury.mcs.net> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Karl Denninger Subject: Re: The cartel begins to crumble? Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. On Nov 7, 11:00, Karl Denninger wrote: > What prevents people from doing this is simple -- a rule that you have > to have an OPERATIONAL registry online, and really be taking registrations > within 30 days or you lose the delegation PERMANENTLY. Says who? > Second, I do support *rational* limits on the number of delegations an > organziation or related set of organizations can hold (say, 20), with no > more than 3-5 in the pipe at any given time. "Rational"? Surely, you mean "subjective". > All this has been clearly explained in other messages I've posted here and > elsewhere on this topic. All of which is your private opinion. You need some recognized authority to set/enforce whatever rules one will end up with, it isn't enough that you just say so. -- ------ ___ --- Per G. Bilse, Mgr Network Operations ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse@EU.net   Received: from ietf.org by ietf.org id aa15368; 7 Nov 96 14:24 EST Received: from taunivm.tau.ac.il by ietf.org id aa15150; 7 Nov 96 14:22 EST Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 6004; Thu, 07 Nov 96 21:21:40 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0499; Thu, 7 Nov 1996 21:21:40 +0200 Date: Thu, 07 Nov 96 21:15:45 IST Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: RE: More iTLD thread To: Jim Fleming , 'Hank Nussbacher' , "ietf@ietf.org" cc: 'New Newdom' In-Reply-To: Message of Thu, 7 Nov 1996 08:43:48 -0600 from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071422.aa15150@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 7 Nov 1996 08:43:48 -0600 you said: >Also discussed on that list is a "round table" decision >making model, where the owners of those root name >servers, in concert with the ISPs and top level domain >registries, will work together to decide which top level >domains to support. That will just cause a balkanization of the Internet. We need for the roots to have all the iTLDs. The main problem has been the NSI monopoly and the cramming in .com. Give the IAHC some time (4 months) and we will solve your problems so that everyone benefits. > >In my opinion, the round table model allows natural >market forces to control the evolution as opposed to >a few people. Customers have input into the process >by the economic support of the ISPs and registries >via their registration fees. The round table model can easily be usurped as well as sued. >If you are interested in following those discussions >on the newdom list, there is a web site with more >information. I am aware of all the arguments but won't have time to monitor all the newdom lists. The IAHC will have a list out there very soon for you and others to submit proposals. > > > >Thanks again for your comments. > Any time. -Hank > > >-- >Jim Fleming >UNETY Systems, Inc. >Naperville, IL > >e-mail: >JimFleming@unety.net >JimFleming@unety.net.s0.g0 (EDNS/IPv8) >   Received: from ietf.org by ietf.org id aa16858; 7 Nov 96 14:33 EST Received: from [207.32.128.130] by ietf.org id aa16755; 7 Nov 96 14:32 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id NAA25110; Thu, 7 Nov 1996 13:25:01 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCCAF.5772B920@webster.unety.net>; Thu, 7 Nov 1996 13:26:54 -0600 Message-ID: <01BBCCAF.5772B920@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Dave Crocker' , Hank Nussbacher Cc: 'Donald Heath' , "ietf@ietf.org" , 'New Newdom' Subject: RE: IAHC Date: Thu, 7 Nov 1996 13:26:52 -0600 Encoding: 191 TEXT Source-Info: From (or Sender) name not authenticated. On Thursday, November 07, 1996 10:42 AM, Dave Crocker[SMTP:dcrocker@brandenburg.com] wrote: @ At 12:20 AM -0800 11/7/96, Hank Nussbacher wrote: @ >I think the IANA has backed out of this so you have nothing to fear. It @ >is now in the hands of a committee made up of people from ISOC, IETF, @ >ITU, INTA, WIPA and what-have-you. The IANA has a minority voice. @ @ (also speaking strictly personally, though also serving as a member @ of the IAHC...) @ @ Let me emphasize Hank's point: @ @ A number of the members of the committee are participating explicitly as @ "representatives" of specific organizations. I believe none of the 5 @ "Internet" appointees are participating with an explicit representational @ responsibility more specific than "Internet". For example I was appointed @ by IANA but am not serving as its representative. (I couldn't, even if I @ wanted to, since I have had no involvement in its operation, ever. @ Further, I am not consulting IANA about the details of my participation and @ they are not requesting me to.) @ @ I think that organizational representations on the IAHC are fine. In the @ case of those from the Internet "side" it's simply that the appropriate @ scope of the "organization" is Internet-generic, rather than being limited @ to any one of its component groups. @ @ d/ @ @ -------------------- @ Dave Crocker +1 408 246 8253 @ Brandenburg Consulting fax: +1 408 249 6205 @ 675 Spruce Dr. dcrocker@brandenburg.com @ Sunnyvale CA 94086 USA http://www.brandenburg.com @ @ Internet Mail Consortium http://www.imc.org, info@imc.org @ @ @ Dave, These are all wonderful comments...please consider the following... Can you explain why this is November 7, 1996 and as far as I know, there has not been any formal announcement of the members of the IAHC ? Don Heath, the President of the ISOC has stated that he does not want to use the open forums of the Internet for IAHC deliberations because he does not want to "waste people's time". He prefers to announce conclusions that have been reached by the IAHC. Has Don considered that he is causing a lot of people's time to be wasted while everyone dances around the issue of who is on the IAHC, how they were selected, who selected them, what is their agenda, etc. etc. ? Now, most people know that Don is relatively new to the Internet and just recently became President of the ISOC last Summer. Have any of the members of the IAHC, who are familiar with the Internet, pointed out to Don that time will be SAVED using this wonderful tool to host an open forum ? Rather than having IHAC members flying to Washington, D.C. or wherever, the Internet can be used to bring those members together with other experts in the field to discuss the issues. Speaking of Washington, D.C., rumor has it that there was an IAHC meeting this week. Is that true ? Did you attend ? If so, are there meeting notes ? Do you have a list of the IHAC members ? In summary, why hasn't the Internet been used as a tool to get things moving with the IAHC ? Why haven't the organizations that have appointed members used the Internet to notify people? You point out that you were selected by the IANA (Jon Postel and Joyce Reynolds). Why hasn't the IANA used the Internet to notify people ? I must say that I take my hat off to Brian Carpenter of the IAB, who after some discussion finally came forward with their appointments. I guess my bottom line question is... Is there any reason why this is taking so long and why the Internet is NOT being used effectively...? ---------- From: Brian Carpenter CERN-CN[SMTP:brian@dxcoms.cern.ch] Sent: Thursday, November 07, 1996 2:38 AM To: Jim Fleming Cc: iab@isi.edu; newdom@vrx.net Subject: Re: IAB and the IAHC Jim, >--------- Text sent by Jim Fleming follows: > > On Thursday, November 07, 1996 2:13 AM, Brian Carpenter CERN-CN[SMTP:brian@dxcoms.cern.ch] wrote: > @ Jim, > @ > @ Please address the iab at our email address, iab@iab.org > @ in future. > @ > @ > Can members of the IAB clarify the role of the IAB > @ > and the IAHC...? > @ > @ The IAB is collegial. Please don't ask for the members > @ to reply as individuals. > @ > > I see. Should we conclude that you are speaking > for all of the members ? I always try to indicate clearly when something is my personal opinion or when it is an IAB consensus. But my previous message was purely factual in any case. > > @ The role of the IAB with respect to the IAHC is > @ explained in draft-postel-iana-itld-admin-02.txt > @ > @ > > @ > Did the IAB approve the members of the IAHC...? > @ > @ We appointed two members, as explained in > @ draft-postel-iana-itld-admin-02.txt > @ > > Can you tell people who those members are...? It's no secret: The IAB considered more than 14 possible candidates from 10 different countries for the two slots it was requested to fill on the IAHC, and after intensive discussion and several rounds of ballotting, the two candidates nominated by the IAB are Geoff Huston Hank Nussbacher -- Brian Carpenter ---------- From: Brian Carpenter CERN-CN[SMTP:brian@dxcoms.cern.ch] Sent: Thursday, November 07, 1996 3:09 AM To: Jim Fleming Cc: iab@isi.edu; newdom@vrx.net Subject: Re: IAB and the IAHC Jim, > > Thanks for the update. I am a little surprised that > people have not announced the complete list of > IAHC members via the Internet. I have made this point myself to Don Heath who is acting as convenor of the IAHC. > > Also, can we assume that the 14 candidates, and 10 > countries, and the minutes of the discussions > as well as the balloting will all be made part of > the public record according to the guidelines in...? > > @@@@@ ftp://ds.internic.net/rfc/rfc2026.txt > No, we decided to keep the names confidential, in line with the guidelines in rfc2027, which were thoroughly discussed in poised95. My personal opinion: if we ever have to do it again, we should also make an open call for nominations, again as in rfc2027. We were under deadline pressure this time, so we couldn't consider this. Brian Carpenter @@@@@@ -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa16927; 7 Nov 96 14:34 EST Received: from taunivm.tau.ac.il by ietf.org id aa16797; 7 Nov 96 14:33 EST Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 5968; Thu, 07 Nov 96 21:11:13 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0414; Thu, 7 Nov 1996 21:11:13 +0200 Date: Thu, 07 Nov 96 21:09:57 IST Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: The cartel begins to crumble? To: Karl Denninger , Hank Nussbacher cc: ietf@ietf.org In-Reply-To: Message of Thu, 7 Nov 1996 10:19:02 -0600 (CST) from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071433.aa16797@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 7 Nov 1996 10:19:02 -0600 (CST) you said: >> >Zones are transferrable. Its easily arguable that this is a self-healing >> >problem to a large extent. A dead registry is going to be a tangible, and >> >valuable, asset (assuming it has registrants in it -- if not the entire >> >discussion is moot and irrelavent). >> >> Company A sells DNs in their new .biz domain for a $200 one time >> fee (forever). Three years later they go bankrupt. Company B >> comes along and is willing to take over the .biz domain but >> cannot charge any existing customers since they have a piece of >> paper stating that their domain is cost free forever. >> >> An orphaned registry is only valuable if it has enough critical >> mass and many paying customers. > >Bad assumption. > >If a TLD is desirable, it will have NEW customers. > >If it has no customers, there is no disruption when it disappears. What do you do with the 100 or so unlucky customers that did sign up and pay with the "undesirable" TLD that went down the sinkhole? Do we need to care about them, or just forget it as noise and move on? Hank > >-- >-- >Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity >http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo >Voice: +1 312 803-MCS1 x219| Email to "info@mcs.net" WWW: http://www.mcs.net/ >Fax: +1 312 248-9865 | 2 FULL DS-3 Internet links; 400Mbps B/W Internal >   Received: from ietf.org by ietf.org id aa17670; 7 Nov 96 14:49 EST Received: from black-ice.cc.vt.edu by ietf.org id aa17574; 7 Nov 96 14:48 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id OAA17494; Thu, 7 Nov 1996 14:47:05 -0500 Message-Id: <199611071947.OAA17494@black-ice.cc.vt.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: Phill Kelley Cc: ietf@ietf.org Subject: Re: The price of chatter In-Reply-To: Your message of "Wed, 06 Nov 1996 23:13:00 PST." Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-803792452P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 07 Nov 1996 14:47:03 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_-803792452P Content-Type: text/plain; charset=us-ascii On Wed, 06 Nov 1996 23:13:00 PST, you said: > Before I follow this group who have voted with their e-feet, I want to ask > if it is possible to be subscribed only to the RFC announcements, without > the RFC drafts and without the general discussion? Well.. ietf-announce carries a blurb when new drafts are posted. I dont know of anyplace where *only* RFC announcements are made. I've seen 109 postings to the ietf-announce list since Oct 23, for whatever that is worth. That compares to 252 on the main IETF list in the same timespan. -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_-803792452P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMoI8tdQBOOoptg9JAQEIFgQAkdzv/GH3mNcHPbmoam11I+UvfTyy/fOU rc4o0Qy5K0L/r89MB+SwAF/50UwjJ66rDsZt0iRIRapeirmlJ/H/dWm0tERumfs4 ObIYZo/Qk4DhBJK0BCMhtT6zlvH9i0A5FNl/5G1hKkKTN0EucrDxPZVwx9uGvbug zn/w90JsaVg= =neOI -----END PGP MESSAGE----- --==_Exmh_-803792452P--   Received: from ietf.org by ietf.org id aa18109; 7 Nov 96 14:54 EST Received: from taunivm.tau.ac.il by ietf.org id aa18027; 7 Nov 96 14:53 EST Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 6043; Thu, 07 Nov 96 21:31:34 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0604; Thu, 7 Nov 1996 21:31:14 +0200 Date: Thu, 07 Nov 96 21:24:03 IST Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: IAHC To: Karl Denninger , Hank Nussbacher cc: ietf@ietf.org In-Reply-To: Message of Thu, 7 Nov 1996 10:22:50 -0600 (CST) from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071453.aa18027@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 7 Nov 1996 10:22:50 -0600 (CST) you said: >How did the COMMITTEE get the authority? From ISOC, IANA, IAB, IETF, INTA, WIPO, ITU and hopefully soon from the FNC. All have agreed to have the IAHC get this done fast and well. > >There was no open process. We haven't started yet. >There were no public nominations. We are not running for office. >There ARE people on the committee (one in particular comes to mind) who have > made a practice of insinuating that people are committing CRIMINAL > acts by supporting eDNS (specifically, allegations of "fraud") If you can send me private mail about this incident I will try to talk to the individual in question. Nothing will get accomplished by name calling and threats. >There is no "resume", or curriculum vitae, on the members available. By Monday (hopefully) it will be out there for you to review. >There is no public process, mechanism for public comment, nor public record > of discussions and vote(s) within the committee. There will be a public process. Give us till Monday to get the charter and framework out there and you may be pleasently suprised. We are here to get this done in the best possible way including soliciting actual proposals. > >None of this speaks highly towards this being an "open" process. > >Quite to the contrary. To form a committee and get off the ground and bootstrap ourselves takes 7-10 days. Can you give us that leeway? Hank > >-- >-- >Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity >http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo >Voice: +1 312 803-MCS1 x219| Email to "info@mcs.net" WWW: http://www.mcs.net/ >Fax: +1 312 248-9865 | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa18925; 7 Nov 96 15:03 EST Received: from vm.biu.ac.il by ietf.org id aa18570; 7 Nov 96 15:00 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 1478; Thu, 07 Nov 96 21:57:47 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 2964; Thu, 7 Nov 1996 21:57:47 +0200 Date: Thu, 07 Nov 96 21:43:34 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: RE: IAHC To: Jim Fleming , 'Dave Crocker' cc: 'Donald Heath' , "ietf@ietf.org" , 'New Newdom' In-Reply-To: Message of Thu, 7 Nov 1996 13:26:52 -0600 from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071500.aa18570@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 7 Nov 1996 13:26:52 -0600 you said: >Can you explain why this is November 7, 1996 and as far as >I know, there has not been any formal announcement of the >members of the IAHC ? We are in the bootstrap process. We have existed as a group for about 9 days and members have to send in their resume, it has to be reworded, and a polished press release, charter and operational framework has to be written before we can announce ourselves. Give us 3 more days. We exchange about 40 pieces of mail a day between 10 people. We are working around the clock (literally) to get this up and for the IAHC to be successful. > >Don Heath, the President of the ISOC has stated that he does >not want to use the open forums of the Internet for IAHC deliberations >because he does not want to "waste people's time". He prefers >to announce conclusions that have been reached by the IAHC. It was decided within the IAHC to have a public IAHC discussion list and to solicit proposals from the greater Internet community. Give us 3 days before jumping to any conclusions. >Has Don considered that he is causing a lot of people's time >to be wasted while everyone dances around the issue of who >is on the IAHC, how they were selected, who selected them, >what is their agenda, etc. etc. ? > >Now, most people know that Don is relatively new to the >Internet and just recently became President of the ISOC >last Summer. Have any of the members of the IAHC, who are >familiar with the Internet, pointed out to Don that time will be >SAVED using this wonderful tool to host an open forum ? Can you hold off on the critisim for just 72 hours? Once we make our official announcements, I will then hope to see you begin tearing them apart. >Rather than having IHAC members flying to Washington, D.C. >or wherever, the Internet can be used to bring those members >together with other experts in the field to discuss the issues. Much has been done via email and extensive conference calls. >Speaking of Washington, D.C., rumor has it that there was >an IAHC meeting this week. > Is that true ? A partial IAHC meeting. > Did you attend ? No I did not. I could not. > If so, are there meeting notes ? Not yet. > Do you have a list of the IHAC members ? It will be there within 72 hours. > >In summary, why hasn't the Internet been used as a tool to >get things moving with the IAHC ? Why haven't the organizations >that have appointed members used the Internet to notify people? >You point out that you were selected by the IANA (Jon Postel >and Joyce Reynolds). Why hasn't the IANA used the Internet >to notify people ? The Internet has been used exclusively to get this running. The committee is still finishing off its charter and framework. All you are doing is jumping the gun. Patience - it is a virtue. >I must say that I take my hat off to Brian Carpenter of the IAB, >who after some discussion finally came forward with their >appointments. > >I guess my bottom line question is... >Is there any reason why this is taking so long and >why the Internet is NOT being used effectively...? It is being used. There will be a web site to house all the competing proposals and a discussion list and public review and almost everything you are asking for and more. 72 hours. Hank > >---------- >From: Brian Carpenter CERN-CN[SMTP:brian@dxcoms.cern.ch] >Sent: Thursday, November 07, 1996 2:38 AM >To: Jim Fleming >Cc: iab@isi.edu; newdom@vrx.net >Subject: Re: IAB and the IAHC > >Jim, > >>--------- Text sent by Jim Fleming follows: >> >> On Thursday, November 07, 1996 2:13 AM, Brian Carpenter > CERN-CN[SMTP:brian@dxcoms.cern.ch] wrote: >> @ Jim, >> @ >> @ Please address the iab at our email address, iab@iab.org >> @ in future. >> @ >> @ > Can members of the IAB clarify the role of the IAB >> @ > and the IAHC...? >> @ >> @ The IAB is collegial. Please don't ask for the members >> @ to reply as individuals. >> @ >> >> I see. Should we conclude that you are speaking >> for all of the members ? > >I always try to indicate clearly when something is my >personal opinion or when it is an IAB consensus. But my >previous message was purely factual in any case. >> >> @ The role of the IAB with respect to the IAHC is >> @ explained in draft-postel-iana-itld-admin-02.txt >> @ >> @ > >> @ > Did the IAB approve the members of the IAHC...? >> @ >> @ We appointed two members, as explained in >> @ draft-postel-iana-itld-admin-02.txt >> @ >> >> Can you tell people who those members are...? > >It's no secret: >The IAB considered more than 14 possible candidates >from 10 different countries for the two slots >it was requested to fill on the IAHC, and after >intensive discussion and several rounds of ballotting, >the two candidates nominated by the IAB are > > Geoff Huston > Hank Nussbacher > > > -- Brian Carpenter > >---------- >From: Brian Carpenter CERN-CN[SMTP:brian@dxcoms.cern.ch] >Sent: Thursday, November 07, 1996 3:09 AM >To: Jim Fleming >Cc: iab@isi.edu; newdom@vrx.net >Subject: Re: IAB and the IAHC > >Jim, >> >> Thanks for the update. I am a little surprised that >> people have not announced the complete list of >> IAHC members via the Internet. > >I have made this point myself to Don Heath who is >acting as convenor of the IAHC. > >> >> Also, can we assume that the 14 candidates, and 10 >> countries, and the minutes of the discussions >> as well as the balloting will all be made part of >> the public record according to the guidelines in...? >> >> @@@@@ ftp://ds.internic.net/rfc/rfc2026.txt >> >No, we decided to keep the names confidential, in >line with the guidelines in rfc2027, which were >thoroughly discussed in poised95. > >My personal opinion: if we ever have to do it again, we should >also make an open call for nominations, again as in rfc2027. >We were under deadline pressure this time, so we couldn't >consider this. > > Brian Carpenter > >@@@@@@ > > >-- >Jim Fleming >UNETY Systems, Inc. >Naperville, IL > >e-mail: >JimFleming@unety.net >JimFleming@unety.net.s0.g0 (EDNS/IPv8) >   Received: from ietf.org by ietf.org id aa19328; 7 Nov 96 15:04 EST Received: from vm.biu.ac.il by ietf.org id aa18910; 7 Nov 96 15:03 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 1484; Thu, 07 Nov 96 22:00:47 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 2974; Thu, 7 Nov 1996 22:00:47 +0200 Date: Thu, 07 Nov 96 21:58:09 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: The cartel begins to crumble? To: karl@mcs.net, Hank Nussbacher cc: ietf@ietf.org In-Reply-To: Message of Thu, 7 Nov 1996 13:52:55 -0600 (CST) from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071504.aa18910@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 7 Nov 1996 13:52:55 -0600 (CST) you said: >> >Bad assumption. >> > >> >If a TLD is desirable, it will have NEW customers. >> > >> >If it has no customers, there is no disruption when it disappears. >> >> What do you do with the 100 or so unlucky customers that did sign >> up and pay with the "undesirable" TLD that went down the sinkhole? >> Do we need to care about them, or just forget it as noise and move on? >> Hank > >What do you do with the unlucky customers that sign up with someone for >service now when the firm fails? There is a difference between that and what can be seen as an international resource like an iTLD. If I were to dial 001 to get to the USA and that stopped working - that is not the same ballgame as isp.com going down or even Sprint failing. -Hank >-- >-- >Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity >http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo >Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ >Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa21092; 7 Nov 96 15:29 EST Received: from taunivm.tau.ac.il by ietf.org id aa20516; 7 Nov 96 15:21 EST Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 6081; Thu, 07 Nov 96 21:37:58 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0739; Thu, 7 Nov 1996 21:37:58 +0200 Date: Thu, 07 Nov 96 21:32:47 IST Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: The cartel begins to crumble? To: Karl Denninger , Hank Nussbacher cc: ietf@ietf.org In-Reply-To: Message of Thu, 7 Nov 1996 10:17:10 -0600 (CST) from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071524.aa20516@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 7 Nov 1996 10:17:10 -0600 (CST) you said: >> The way out of this is to eliminate the ability to trade in DNs. If >> the rule was that a DN is not transferrable, then there would be >> no value to doing a large DN grab. See the Israeli DN policy >> at www.isoc.org.il If we find that a company trades in DNs, they >> lose all existing DNs. > >How do you prove it? In one case, a customer taped his phone conversation with the company trying to sell the DN. >Are you willing to get sued if you're wrong, and potentially be liable no >only for real lost business (millions of US $) but ALSO punitive damages? So what is your solution to the person who will buy up 25,000 personal names or 10,000 corporate domain names? I would assume that a number of the awardees of new iTLDs will want to offer DNs in their TLD free of charge for a year or so so as to create critical mass. How do you stop the college senior from massive name grabbing? Tell him there is a limit per day? Not let him? Do you have the right to refuse a customer? Hank >Why does ANYONE want that kind of liability. > >Three standards to adhere to: > >1) Verifyability >2) Objectivity >3) Serves the purpose > >You need to meet all three. > >-- >-- >Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity >http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo >Voice: +1 312 803-MCS1 x219| Email to "info@mcs.net" WWW: http://www.mcs.net/ >Fax: +1 312 248-9865 | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa21448; 7 Nov 96 15:32 EST Received: from hal.iodesign.com by ietf.org id aa21212; 7 Nov 96 15:31 EST Received: (chris@localhost) by hal.iodesign.com (8.6.8.1/SCA-6.6) id UAA00510; Thu, 7 Nov 1996 20:17:01 GMT Return-Path: Message-Id: <199611072017.UAA00510@hal.iodesign.com> Sender:ietf-request@ietf.org From: Christopher Ambler X-Mailer: SCO OpenServer Mail Release 5.0 To: HANK@vm.biu.ac.il, JimFleming@unety.net, dcrocker@brandenburg.com Subject: RE: IAHC Cc: heath@linus.isoc.org, ietf@ietf.org, newdom@vrx.net Date: Thu, 7 Nov 96 12:17:01 PST Source-Info: From (or Sender) name not authenticated. Please, Jim, calm down for a couple days, okay? Nobody is more anxious than I am to see the IAHC fully formed and working, as a prospective registry owner. I've waited over a year now for IANA, I can surely find something to occupy my time for 72 hours while the IAHC bootstraps themselves. -- Christopher Ambler President, Image Online Design, Inc.   Received: from ietf.org by ietf.org id aa21672; 7 Nov 96 15:33 EST Received: from [207.32.128.130] by ietf.org id aa21416; 7 Nov 96 15:32 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id NAA25220; Thu, 7 Nov 1996 13:55:44 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCCB3.A20269A0@webster.unety.net>; Thu, 7 Nov 1996 13:57:37 -0600 Message-ID: <01BBCCB3.A20269A0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Hank Nussbacher' , "ietf@ietf.org" Cc: 'New Newdom' Subject: RE: More iTLD thread Date: Thu, 7 Nov 1996 13:57:35 -0600 Encoding: 105 TEXT Source-Info: From (or Sender) name not authenticated. On Thursday, November 07, 1996 3:15 PM, Hank Nussbacher[SMTP:HANK@taunivm.tau.ac.il] wrote: @ On Thu, 7 Nov 1996 08:43:48 -0600 you said: @ >Also discussed on that list is a "round table" decision @ >making model, where the owners of those root name @ >servers, in concert with the ISPs and top level domain @ >registries, will work together to decide which top level @ >domains to support. @ @ That will just cause a balkanization of the Internet. We need @ for the roots to have all the iTLDs. The main problem has @ been the NSI monopoly and the cramming in .com. Give the IAHC @ some time (4 months) and we will solve your problems so that @ everyone benefits. I do not think that you 4 months. Have you read Paul Vixie's postion statement giving you a January 15, 1997 deadline before he goes "ballistic" (whatever Paul means by that). In my opionion, the main problem has been an inability of the IANA to "manage" the processes and procedures that they put on their plate. They mislead people that they had the authority and the ability to manage the transition. Now they have passed the "hot potatoe" to the ISOC and you, as a member of the IAHC. Some claim that the people are at fault for believing that the IANA had authority and blindly following their lead. The same thing can happen with the IAHC. People have to decide whether they think that you have any real authority and whether you will accomplish anything as part of the non-profit operation of the ISOC which is limited by IRS rules. NSI and other companies continue to build their infrastructure and make money. For some reason, people continue to look to the IANA, the ISOC and the IETF for leadership. When the leadership does not materialize, delays occur, and a new set of leaders are selected to "have their turn". Anyone that has been on this carnival ride can see that the pattern is repeating. Sure, new people will sign up and debate all of the same topics debated over the past year. Many people can have fun and pontificate about the fact that they think they are making multi-billion dollar decisions. Business people can not tolerate these processes. People are losing money by waiting and being mislead by people who clearly have no intention of standing up for their actions. In my opinion, the only people who can solve these problems are the people who own and operate the companies and systems that serve the customers. Those people need to move forward and not waste 4 more months of valuable time. @ > @ >In my opinion, the round table model allows natural @ >market forces to control the evolution as opposed to @ >a few people. Customers have input into the process @ >by the economic support of the ISPs and registries @ >via their registration fees. @ @ The round table model can easily be usurped as well as sued. @ Anyone with a root name server can participate. With a simple synchronization plan an agreement will be reached on what top level domains are supported. Who are people going to sue...? All of the root name servers, ISPs, and registries ? Have you considered that it might be easier for people to sue the ISOC and the members of the IAHC...? that is a much smaller number of people If litigation is going to drive all decisions, then people might as well turn this whole thing over to the respective governments, because no company will get involved unless the liabilities are widely distributed or buffered by governments. @ >If you are interested in following those discussions @ >on the newdom list, there is a web site with more @ >information. @ @ I am aware of all the arguments but won't have time to monitor @ all the newdom lists. The IAHC will have a list out there very @ soon for you and others to submit proposals. @ How long have you been following "all of the arguments" ? Can you provide people with your background and expertise in this area ? -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa23679; 7 Nov 96 15:50 EST Received: from Kitten.mcs.com by ietf.org id aa23117; 7 Nov 96 15:48 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id OAA09351; Thu, 7 Nov 1996 14:06:21 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id OAA28271; Thu, 7 Nov 1996 14:06:18 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id OAA17202; Thu, 7 Nov 1996 14:06:17 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611072006.OAA17202@Jupiter.Mcs.Net> Subject: Re: The cartel begins to crumble? To: Hank Nussbacher Date: Thu, 7 Nov 1996 14:06:17 -0600 (CST) Cc: karl@mcs.net, HANK@taunivm.tau.ac.il, ietf@ietf.org In-Reply-To: <199611072002.OAA27472@Mailbox.mcs.com> from "Hank Nussbacher" at Nov 7, 96 09:58:09 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > On Thu, 7 Nov 1996 13:52:55 -0600 (CST) you said: > >> >Bad assumption. > >> > > >> >If a TLD is desirable, it will have NEW customers. > >> > > >> >If it has no customers, there is no disruption when it disappears. > >> > >> What do you do with the 100 or so unlucky customers that did sign > >> up and pay with the "undesirable" TLD that went down the sinkhole? > >> Do we need to care about them, or just forget it as noise and move on? > >> Hank > > > >What do you do with the unlucky customers that sign up with someone for > >service now when the firm fails? > > There is a difference between that and what can be seen as an international > resource like an iTLD. If I were to dial 001 to get to the USA and that > stopped working - that is not the same ballgame as isp.com going down or > even Sprint failing. -Hank Again, a registry that has real penetration doesn't have this problem. If there were 100 people in the USA and 001 didn't work you'd hear about it, but it wouldn't be an international disaster. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa23654; 7 Nov 96 15:50 EST Received: from Kitten.mcs.com by ietf.org id aa23329; 7 Nov 96 15:49 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id OAA10689; Thu, 7 Nov 1996 14:36:39 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id OAA04051; Thu, 7 Nov 1996 14:36:36 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id OAA18018; Thu, 7 Nov 1996 14:36:35 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611072036.OAA18018@Jupiter.Mcs.Net> Subject: Re: The cartel begins to crumble? To: Hank Nussbacher Date: Thu, 7 Nov 1996 14:36:34 -0600 (CST) Cc: karl@mcs.net, HANK@taunivm.tau.ac.il, ietf@ietf.org In-Reply-To: <199611072027.OAA02441@Mailbox.mcs.com> from "Hank Nussbacher" at Nov 7, 96 10:20:11 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > On Thu, 7 Nov 1996 14:04:54 -0600 (CST) you said: > >(1) You have to have operational nameservers for the domain you are > > requesting. That is ALREADY a requirement of many of the eDNS > > registries (ours included). The check for those authoritative NS > > lines is automatic. > > > > We have stopped *hundreds* of attempted grabs in the eDNS tlds we > > run ALREADY, and doing so took no manpower. The computer did the > > work for us. > > So you discriminate between those with the technical knowledge > to be able to set up a NS and add a few SOAs vs those who don't > have a clue and simply call up and want to grab a name? Domains are used to provide mapping between hosts and monikers which people give them. A domain set up without nameservers does not fill the essential purpose for which it is requested to be delegated. If you want to call that "discrimination", be my guest. That your debate with me on this point degenerated into a perjorative phrase this quickly says much (in my opinion anyway). I refer you to the THOUSANDS of ISPs who *do* have a clue and *can* do this for you if you are incapable of doing so. > > > >(2) You have to pay (presumably) for the registrations you file. This > > is a check and balance in and of itself. > > $50 per domain is nothing for a valuable DN. > > Hank Sure. But $50 X 250,000 is more money than I believe people will gamble to try to "corner" a particular part of this market. BTW, that's $12.5 Million in US terms. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id ab23692; 7 Nov 96 15:50 EST Received: from Kitten.mcs.com by ietf.org id aa23138; 7 Nov 96 15:48 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id OAA09291; Thu, 7 Nov 1996 14:04:56 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id OAA27926; Thu, 7 Nov 1996 14:04:55 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id OAA17158; Thu, 7 Nov 1996 14:04:54 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611072004.OAA17158@Jupiter.Mcs.Net> Subject: Re: The cartel begins to crumble? To: Hank Nussbacher Date: Thu, 7 Nov 1996 14:04:54 -0600 (CST) Cc: karl@mcs.net, HANK@vm.biu.ac.il, ietf@ietf.org In-Reply-To: <199611071938.NAA22466@Mailbox.mcs.com> from "Hank Nussbacher" at Nov 7, 96 09:32:47 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > On Thu, 7 Nov 1996 10:17:10 -0600 (CST) you said: > >> The way out of this is to eliminate the ability to trade in DNs. If > >> the rule was that a DN is not transferrable, then there would be > >> no value to doing a large DN grab. See the Israeli DN policy > >> at www.isoc.org.il If we find that a company trades in DNs, they > >> lose all existing DNs. > > > >How do you prove it? > > In one case, a customer taped his phone conversation with the company > trying to sell the DN. Try that in the US and you may run afoul of CRIMINAL statutes, depending on the state you're calling from and to. It would be a *real* bad idea to attempt to do this in many countries -- the United States included. > >Are you willing to get sued if you're wrong, and potentially be liable no > >only for real lost business (millions of US $) but ALSO punitive damages? > > So what is your solution to the person who will buy up 25,000 > personal names or 10,000 corporate domain names? I would assume that > a number of the awardees of new iTLDs will want to offer DNs in > their TLD free of charge for a year or so so as to create critical > mass. How do you stop the college senior from massive name > grabbing? Tell him there is a limit per day? Not let him? Do you > have the right to refuse a customer? > > Hank (1) You have to have operational nameservers for the domain you are requesting. That is ALREADY a requirement of many of the eDNS registries (ours included). The check for those authoritative NS lines is automatic. We have stopped *hundreds* of attempted grabs in the eDNS tlds we run ALREADY, and doing so took no manpower. The computer did the work for us. (2) You have to pay (presumably) for the registrations you file. This is a check and balance in and of itself. (3) If you damage someone, you are asking to get sued (somewhere). If you do for the purpose of *EXTORTION*, you could end up with criminal charges laid against you. I don't care if someone registers 25,000 personal names. If there is enough diversity in the registry and TLD busines, it is *irrelavent* provided that you enforce actual physical service provision. Operating nameservers to serve 25,000 zones is not trivial. Trying to do so to serve 250,000 zones is SERIOUSLY non-trivial (which is about what "critical mass" is if you have significant diversity; with 1,000 TLDs, someone grabbing 250,000 entries only gets 250 in any registry!) Try running a nameserver that has 2.5 million zones in it (even just the NS lines for them). Come check back with us when you have achieved a stable operating configuration for this :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa23705; 7 Nov 96 15:50 EST Received: from Kitten.mcs.com by ietf.org id aa23126; 7 Nov 96 15:48 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id OAA09119; Thu, 7 Nov 1996 14:00:06 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id NAA26918; Thu, 7 Nov 1996 13:59:59 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id NAA17027; Thu, 7 Nov 1996 13:59:58 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611071959.NAA17027@Jupiter.Mcs.Net> Subject: Re: IAHC To: Hank Nussbacher Date: Thu, 7 Nov 1996 13:59:58 -0600 (CST) Cc: karl@mcs.net, HANK@vm.biu.ac.il, ietf@ietf.org In-Reply-To: <199611071931.NAA20932@Mailbox.mcs.com> from "Hank Nussbacher" at Nov 7, 96 09:24:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > On Thu, 7 Nov 1996 10:22:50 -0600 (CST) you said: > >How did the COMMITTEE get the authority? > > >From ISOC, IANA, IAB, IETF, INTA, WIPO, ITU and hopefully soon from > >the FNC. All have agreed to have the IAHC get this done fast and well. In other words, from people who (1) haven't spent nickel 1 on the infrastructure out there to date, (2) have no claim on this in the first place (especially the ITU and WIPO; its nice to PRETEND they do, but they don't) and I've yet to see any OPEN documents according to ISOC and IETF operating procedures that back up THAT claim. Further, the IAB has not responded to our formal complaint regarding the IANA attempts to circumvent procedure. > >There was no open process. > > We haven't started yet. The process started when the "committee" as "formed". > >There were no public nominations. > > We are not running for office. On the contrary. If you wish to claim the right to influence public policy, you darn well are in public office. Instead of running for that office, and listing criteria and taking nominations, we are just supposed to let people *APPOINT* a crew to do this? > >There ARE people on the committee (one in particular comes to mind) who have > > made a practice of insinuating that people are committing CRIMINAL > > acts by supporting eDNS (specifically, allegations of "fraud") > > If you can send me private mail about this incident I will try to > talk to the individual in question. Nothing will get accomplished > by name calling and threats. Read the history and archives of the lists which have been discussing this topic. Perry Metzger, to be specific. I've called nobody a name; his postings speak for themselves and require no embellishment. > >There is no "resume", or curriculum vitae, on the members available. > > By Monday (hopefully) it will be out there for you to review. > > >There is no public process, mechanism for public comment, nor public record > > of discussions and vote(s) within the committee. > > There will be a public process. Give us till Monday to get > the charter and framework out there and you may be pleasently > suprised. We are here to get this done in the best possible way > including soliciting actual proposals. > > > > >None of this speaks highly towards this being an "open" process. > > > >Quite to the contrary. > > To form a committee and get off the ground and bootstrap ourselves > takes 7-10 days. Can you give us that leeway? > > Hank Sure. But I won't give you 4 (or more) months. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa23663; 7 Nov 96 15:50 EST Received: from Kitten.mcs.com by ietf.org id aa23113; 7 Nov 96 15:48 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id NAA08831; Thu, 7 Nov 1996 13:52:58 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id NAA25478; Thu, 7 Nov 1996 13:52:57 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id NAA16825; Thu, 7 Nov 1996 13:52:55 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611071952.NAA16825@Jupiter.Mcs.Net> Subject: Re: The cartel begins to crumble? To: Hank Nussbacher Date: Thu, 7 Nov 1996 13:52:55 -0600 (CST) Cc: karl@mcs.net, HANK@vm.biu.ac.il, ietf@ietf.org In-Reply-To: <199611071911.NAA16764@Mailbox.mcs.com> from "Hank Nussbacher" at Nov 7, 96 09:09:57 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > >Bad assumption. > > > >If a TLD is desirable, it will have NEW customers. > > > >If it has no customers, there is no disruption when it disappears. > > What do you do with the 100 or so unlucky customers that did sign > up and pay with the "undesirable" TLD that went down the sinkhole? > Do we need to care about them, or just forget it as noise and move on? > Hank What do you do with the unlucky customers that sign up with someone for service now when the firm fails? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa25963; 7 Nov 96 16:18 EST Received: from zephyr.isi.edu by ietf.org id aa25866; 7 Nov 96 16:16 EST Received: from zen.isi.edu (zen-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 7 Nov 1996 13:15:33 -0800 Date: Thu, 7 Nov 1996 13:15:26 -0800 Sender:ietf-request@ietf.org From: postel@isi.edu Posted-Date: Thu, 7 Nov 1996 13:15:26 -0800 Message-Id: <199611072115.AA03933@zen.isi.edu> Received: by zen.isi.edu (5.65c/4.0.3-6) id ; Thu, 7 Nov 1996 13:15:26 -0800 To: ietf@ietf.org Subject: RE: IAHC Source-Info: From (or Sender) name not authenticated. Hello: The two people appointed by the IANA to the committee for new registries and new international top level domains, the "ad hoc" committee of draft-postel-iana-itld-admin-02.txt, now called the IAHC are: Dave Crocker Perry E. Metzger There maybe some perception that the IANA is distancing itself from this activity. This is not true. The IANA proposed a process that involved setting up a committee, pushed hard to get the committee appointed, now that the committee has finally been appointed, fully supports it, and urges that it move swiftly (with due process, openness, and public input) to reach some conclusions. Thank you. --jon.   Received: from ietf.org by ietf.org id aa26509; 7 Nov 96 16:25 EST Received: from vm.biu.ac.il by ietf.org id aa26356; 7 Nov 96 16:23 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 1505; Thu, 07 Nov 96 22:17:11 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 3011; Thu, 7 Nov 1996 22:17:11 +0200 Date: Thu, 07 Nov 96 22:06:20 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: RE: More iTLD thread To: Jim Fleming , "ietf@ietf.org" cc: 'New Newdom' In-Reply-To: Message of Thu, 7 Nov 1996 13:57:35 -0600 from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071623.aa26356@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 7 Nov 1996 13:57:35 -0600 you said: >I do not think that you 4 months. Have you read Paul Vixie's >postion statement giving you a January 15, 1997 deadline >before he goes "ballistic" (whatever Paul means by that). Once you see our timetable you will understand why we need 4 months to solicition proposals, create or adopt the official one, place it in the public for review, solicit comments, modify the doc, have the award process, get the submissions, judge them and assign the new iTLDs. That entire process cannot be condensed to 2 months. But wait 72 hours to see the milestones and I believe you will agree. We have been talking to Paul. >Some claim that the people are at fault for believing that >the IANA had authority and blindly following their lead. >The same thing can happen with the IAHC. People have >to decide whether they think that you have any real >authority and whether you will accomplish anything as >part of the non-profit operation of the ISOC which is >limited by IRS rules. Will you give us a chance before deciding on your own? Or are we condemned to death before we even open our mouth? >Anyone that has been on this carnival ride can see that >the pattern is repeating. Sure, new people will sign up and >debate all of the same topics debated over the past year. >Many people can have fun and pontificate about the >fact that they think they are making multi-billion dollar >decisions. I did not come here to join the debate that I have followed silently for the past year. I am here to get the new iTLDs out there, to do it as fast as is humanly possible and to walk away. >Business people can not tolerate these processes. >People are losing money by waiting and being mislead >by people who clearly have no intention of standing up >for their actions. In my opinion, the only people who can >solve these problems are the people who own and operate >the companies and systems that serve the customers. >Those people need to move forward and not waste 4 >more months of valuable time. That is your opinion. >Can you provide people with your background >and expertise in this area ? It will be in the announcement. What you won't find there is that I set the existing policy for the Israeli domain name space, I selected the TLDs, and I still arbitrate cases when the registrar has a question. You can find more about it at www.isoc.org.il. Hank >-- >Jim Fleming >UNETY Systems, Inc. >Naperville, IL > >e-mail: >JimFleming@unety.net >JimFleming@unety.net.s0.g0 (EDNS/IPv8) >   Received: from ietf.org by ietf.org id aa26862; 7 Nov 96 16:29 EST Received: from vm.biu.ac.il by ietf.org id aa26411; 7 Nov 96 16:24 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 1507; Thu, 07 Nov 96 22:23:37 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 3015; Thu, 7 Nov 1996 22:23:38 +0200 Date: Thu, 07 Nov 96 22:20:11 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: The cartel begins to crumble? To: karl@mcs.net, Hank Nussbacher cc: ietf@ietf.org In-Reply-To: Message of Thu, 7 Nov 1996 14:04:54 -0600 (CST) from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071627.aa26411@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 7 Nov 1996 14:04:54 -0600 (CST) you said: >(1) You have to have operational nameservers for the domain you are > requesting. That is ALREADY a requirement of many of the eDNS > registries (ours included). The check for those authoritative NS > lines is automatic. > > We have stopped *hundreds* of attempted grabs in the eDNS tlds we > run ALREADY, and doing so took no manpower. The computer did the > work for us. So you discriminate between those with the technical knowledge to be able to set up a NS and add a few SOAs vs those who don't have a clue and simply call up and want to grab a name? > >(2) You have to pay (presumably) for the registrations you file. This > is a check and balance in and of itself. $50 per domain is nothing for a valuable DN. Hank   Received: from ietf.org by ietf.org id aa27195; 7 Nov 96 16:34 EST Received: from [207.32.128.130] by ietf.org id aa27105; 7 Nov 96 16:32 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id PAA25452; Thu, 7 Nov 1996 15:03:03 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCCBD.094F5560@webster.unety.net>; Thu, 7 Nov 1996 15:04:55 -0600 Message-ID: <01BBCCBD.094F5560@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Per Gregers Bilse' , Karl Denninger Cc: "ietf@ietf.org" , 'New Newdom' Subject: The Internet Tree Date: Thu, 7 Nov 1996 15:04:54 -0600 Encoding: 180 TEXT Source-Info: From (or Sender) name not authenticated. On Thursday, November 07, 1996 12:46 PM, Per Gregers Bilse[SMTP:bilse@eu.net] wrote: @ On Nov 7, 10:22, Karl Denninger wrote: @ > How did the COMMITTEE get the authority? @ > @ >[...] @ > @ > None of this speaks highly towards this being an "open" process. @ > @ > Quite to the contrary. @ @ How does your, Fleming's, et als "process" line up? @ @ -- @ ------ ___ --- Per G. Bilse, Mgr Network Operations @ ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. @ ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL @ --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 @ --- ------- 24hr emergency number: +31 20 421 0865 @ --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse@EU.net @ @ The process I have proposed is VERY simple. It is driven by standard business partnership practices, economics and a direct correlation with customer opinions via their decisions in an open, competitive market place. At the "bottom" of the process are the ROOTs, just like on a tree. Someone has to step forward to handle the thankless job of providing public service machines that hand out references to the authoritative servers for the top level domains. Working up from the roots, are the registries. (We could call this the trunk of the tree) These organizations bring legitimacy to a top level domain by maintaining data bases and the facilities needed to allow people to register second level domains. The registries (trunk) primarily service the ISPs (the branches of the tree). The ISPs bring the marketplace to the registries and help to promote one top level domain over another. Via the advice of an ISP, customers can be steered to registries for various business, political or technical reasons. If a registry does not do a good job, the ISPs should be allowed to vote via "standard business partnership practices". In the current system, the ISPs have no choice, they have to play the InterNIC game. This puts ISPs at the mercy of the InterNIC, which can be dangerous because the InterNIC handles more than just domain names. Continuing...we have roots, a trunk and branches. It is now time to add the most important part, the leaves. These are the customers, they attach to the branches (ISPs) and their opinions are funneled via free market dynamics to the trunk (registries) and then to the roots (root name servers). Now, you are probably asking, "How does this work?" In my mind it is quite simple, firstly there are not that many people or companies that really want to be root name server providers. It is a dirty job and there is not much to be gained. Let's assume that we find enough people to help with that part of the infrastructure. (As an aside, it appears that some of the volunteers that run the current 9 "popular" root name servers may not want this thankless job, especially now that they see that ISPs rely on them for operations) From an operational stand point, all of the people operating root name servers around the world need to coordinate via some simple mailing lists and decision making procedures as to which top level domains they support in their root name servers. Keep in mind that these root name server operators DO NOT invent the top level domains. TLDs must be born from the womb of a registry with the help of the ISPs and their customers. Once gestation occurs, a registry presents a formal proposal to ALL of the root name server operators fro their consideration and discussion. These root name server operators help to facilitate the discussion along with the registries and ISPs in OPEN forums. At some point in time, the registry making the proposal must decide based on the discussion and any consensus reached whether to "advance" the top level domain for a vote by the root name server operators. They vote it up or down by including it in their collection of top level domains they support. There is checks and balance in the system because ISPs still get to decide which root name servers they want to use to provide service. The customers of an ISP can decide which ISP to use, based on the ISP's choice of root name servers. All of this should be done in the open and ISPs should make an active choice, as opposed to the current approach of having them bLindLY follow their O/S vendors suggestion. A public accounting of who is using what servers and which roots support which top level domains and which registries handle a top level domain will help everyone see the complete picture and market forces can be allowed to steer this thundering mass of economic infrastructure. Because this approach follows the "natural" lines of a free market and capitalism, no one individual or company will be able to control the decision making process. Furthermore, because of the various levels of organisms in the system, (roots, trunks, branches, leaves) it will be extremely difficult for casual or foolish entries to be made to the collection of top level domains. Some people have expressed concern to me that this last point may not ALLOW them to easily get into this game. I feel that is a feature, because any system as large as the Internet should not support the introduction of change at such a critical point as TLDs without many voices being heard. Even though this started as a discussion about the IAHC, we should all keep in mind that there are MANY more voices on the Internet than those represented by the ISOC. There are also more to come. The ISOC and IAHC are just small voices in the above "tree". If the system is designed properly, they will take their place in the tree and progress will quickly be made. As I have suggested before, the ISOC is an excellent candidate to help with the thankless task of providing a root name server. If they do that then they have ONE vote in the forum of world root name servers. They would also have to accept proposals from registries (new or old) and help with the deliberations. I hope that the ISOC looks at the big picture and realizes that the system is evolving and there is a natural place to fit into the "tree". I also hope that registries and ISPs study the big picture and work themselves into the market place and the Internet Tree. If everyone does this then customers (leaves) can flourish on the Internet Tree and all will be well. ...enjoy the Internet Tree of Life... ...without it...we will perish... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa29019; 7 Nov 96 16:45 EST Received: from [204.250.49.14] by ietf.org id aa28751; 7 Nov 96 16:44 EST Received: from mail.coupon.net (204.250.49.77) by mail.higgs.net with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 7 Nov 1996 13:42:40 -0800 Received: from [204.250.49.20] by mail.coupon.net with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 7 Nov 1996 13:42:36 -0800 Message-Id: In-Reply-To: <199611071922.OAA25726@ns1.vrx.net> References: Message of Thu, 7 Nov 1996 08:43:48 -0600 from Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Nov 1996 13:42:26 -0800 To: Jon Postel Sender:ietf-request@ietf.org From: Simon Higgs Subject: [Question] IAHC = IDNB ??? Cc: ietf@ietf.org, newdom@vrx.net, newdom@ar.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Source-Info: From (or Sender) name not authenticated. Hi all, I'm trying to update draft-higgs-tld-cat for the IAHC committee's review and have a protocol question. What is the difference between the Internet Domain Name Board (IDNB) mentioned in some older RFC's and the IAHC? They both appear to be performing the same executive domain name functions. Thanks, Simon -- Madness takes its toll. Please have exact change.   Received: from ietf.org by ietf.org id aa29024; 7 Nov 96 16:45 EST Received: from [207.32.128.130] by ietf.org id aa28796; 7 Nov 96 16:44 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id PAA25567; Thu, 7 Nov 1996 15:34:54 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCCC1.7C657940@webster.unety.net>; Thu, 7 Nov 1996 15:36:47 -0600 Message-ID: <01BBCCC1.7C657940@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Hank Nussbacher' , "ietf@ietf.org" Cc: 'New Newdom' Subject: RE: More iTLD thread Date: Thu, 7 Nov 1996 15:36:45 -0600 Encoding: 27 TEXT Source-Info: From (or Sender) name not authenticated. On Thursday, November 07, 1996 4:06 PM, Hank Nussbacher[SMTP:HANK@VM.BIU.AC.IL] wrote: @ On Thu, 7 Nov 1996 13:57:35 -0600 you said: @ >I do not think that you 4 months. Have you read Paul Vixie's @ >postion statement giving you a January 15, 1997 deadline @ >before he goes "ballistic" (whatever Paul means by that). @ @ Once you see our timetable you will understand why we need @ 4 months to solicition proposals, create or adopt the official @ one, place it in the public for review, solicit comments, @ modify the doc, have the award process, get the submissions, @ judge them and assign the new iTLDs. That entire process cannot @ be condensed to 2 months. But wait 72 hours to see the milestones @ and I believe you will agree. We have been talking to Paul. What exactly do you think that you are awarding...? Why haven't the discussions with "Paul" been in an open forum...? -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa29961; 7 Nov 96 16:59 EST Received: from ns2.harborcom.net by ietf.org id aa29670; 7 Nov 96 16:54 EST Received: from swoosh.dunn.org (swoosh.dunn.org [206.158.7.243]) by ns2.harborcom.net (8.7.6/8.6.12) with SMTP id QAA21804; Thu, 7 Nov 1996 16:53:28 -0500 (EST) Date: Thu, 7 Nov 1996 16:51:27 -0500 () Sender:ietf-request@ietf.org From: Bradley Dunn To: Phill Kelley cc: ietf@ietf.org Subject: Re: The price of chatter In-Reply-To: Message-ID: X-X-Sender: bradley@harborcom.net MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Wed, 6 Nov 1996, Phill Kelley wrote: > I have been out of my home town for the past week and have just called > long-distance to clear my email. There were some 170 messages which the > wonderful "check your own bill" service on the hotel TV tells me cost $US35 > to download. Four letters for you: IMAP -BD   Received: from ietf.org by ietf.org id aa01212; 7 Nov 96 17:03 EST Received: from [207.32.128.130] by ietf.org id aa00962; 7 Nov 96 17:02 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id PAA25651; Thu, 7 Nov 1996 15:53:14 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCCC4.0C4F4AC0@webster.unety.net>; Thu, 7 Nov 1996 15:55:07 -0600 Message-ID: <01BBCCC4.0C4F4AC0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Hank Nussbacher' , "ietf@ietf.org" Cc: 'New Newdom' Subject: RE: More iTLD thread Date: Thu, 7 Nov 1996 15:55:06 -0600 Encoding: 138 TEXT Source-Info: From (or Sender) name not authenticated. On Thursday, November 07, 1996 4:06 PM, Hank Nussbacher[SMTP:HANK@VM.BIU.AC.IL] wrote: @ On Thu, 7 Nov 1996 13:57:35 -0600 you said: @ @ >Can you provide people with your background @ >and expertise in this area ? @ @ It will be in the announcement. What you won't find there is @ that I set the existing policy for the Israeli domain name @ space, I selected the TLDs, and I still arbitrate cases when @ the registrar has a question. You can find more about it @ at www.isoc.org.il. @ Hank That really worries me. You seem to have a bias already that one person or a small group can make important decisions. That happened in Australia and they are not allowed to use "dictionary" words below COM.AU. Have you followed that situation ? You might want to consider a BIGGER picture. It might be good if you develop a plan that gets many people involved and focuses on the people that own and operate the equipment. I offer the following as help in looking at a broad picture. You will note that you are listed twice. That is more than can be said for anyone else. As a participant for the IAHC, all you have to do is help the ISOC deploy a root name server to allow them to become part of the critical Internet Infrastructure. Once they do that then they can become actively part of the support of top level domains, by their additions and deletions to THEIR data base. They will participate as an equal with the other root name server operators. @@@@@ 0 - Legacy Internet, R&D, Education, Etc. 0 - IANA - U.S.- Southern California - NS1.ISI.EDU - 128.9.0.107 1 - InterNIC - U.S. - Virginia - NS.INTERNIC.NET - 198.41.0.4 2 - NANOG - ??? 3 - ISP/C - ??? 4 - MERIT - ??? 5 - IETF - U.S. - California - NS.ISC.ORG - 192.5.5.241 6 - ISOC - Contact Don Heath - heath@linus.isoc.org IAHC - Contact ??? 1 - Perry Metzger - perry@piermont.com 2 - David Crocker - IAB 3 - Geoff Huston 4 - Hank Nussbacher - HANK@VM.BIU.AC.IL 5 - David Maher 6 - Sally Abel 7 - Robert Shaw 8 - WIPO representative 9 - ??? 7 - WIA - ??? 1 - North America (U.S., Mexico, Canada) 0 - U.S. - Northwestern - AlterNIC - MX.ALTERNIC.NET - 204.94.42.1 1 - U.S. - Illinois - MCS Net - ROOT-NS.MCS.NET - 192.160.127.86 2 - U.S. - Michigan - AGN Net - SIMBA.AGN.NET - 160.79.1.3 3 - U.S. - Wisconsin - SPARKNET.NET - ROOT-NS.THENIC.NET - 207.67.22.81 4 - U.S. - Maryland - TERP.UMD.EDU - 128.8.10.90 5 - Canada - Ontario - TORONTO.ALTERNIC.NET - 207.107.232.106 6 - Mexico - http://www.nic.mx ??? 7 - U.S. - Southeastern - C.PSI.NET - 192.33.4.12 2 - South America, Central America and the Caribbean 0 - U.S. Virgin Islands - USVI.NET - 204.199.0.4 1 - British Virgin Islands - ??? 2 - Brazil - ??? 3 - Argentina ??? 4 - Venezula - Contact Peter de Blanc - pdeblanc@usvi.net 5 - Bolivia ??? 6 - Costa Rica??? 7 - Panama ??? 3 - England, Europe, Scandanavia and Russia 0 - RIPE - Netherlands - http://www.eu.net ??? 1 - Sweden - NIC.NORDU.NET - 192.36.148.17 2 - England - Contact Keith Mitchell - keith@linx.org 3 - France - Contact Laurent BERNARD - lbernard@artinternet.fr 4 - Germany - ??? 5 - Switzerland - ??? 6 - Italy - ??? 7 - Ukraine - NS.WW.NET - 193.124.73.100 4 - Japan, Korea, China and The Pacific Rim 0 - APNIC - http://www.apnic.net ??? 1 - Japan - http://www.nic.ad.jp ??? 2 - Korea - http://www.krnic.net ??? 3 - 4 - Taiwan - http://www.twnic.net ??? 5 - China - http://www.cnc.ac.cn ??? 6 - Philippines - http://www.ph.net ??? 7 - Hong Kong - http://www.cuhk.hk/hkwww.html ??? 5 - Asia, Africa and the Middle East 0 - 1 - India - http://www.iisc.ernet.in/innic.html ??? 2 - Pakistan - http://www.ar.pk/public/pknic.html ??? 3 - Bangladesh - http://www.bangla.org/bdinet ??? 4 - Israel - ??? Hank Nussbacher - HANK@VM.BIU.AC.IL ??? 5 - Saudi Arabia - ??? 6 - South Africa - ??? 7 6 - Australia, New Zealand, Southeast Asia and the South Pacific 0 - Australia - Contact Andrew Khoo - andrew@aussie.net 1 - New Zealand - http://servius.waikato.ac.nz/isocnz ??? 2 - Singapore - http://www.nic.net.sg ??? 3 - Thailand - http://www.thnic.net ??? 4 - Indonesia - http://www.iptek.net.id/ipteknet_eng.html ??? 5 - Guam - http://ns.gov.gu ??? 6 - Malaysia - NS.ALPHAQUE.COM - 202.185.254.12 7 - 7 - Vehicles, Boats, Spaceships, Ham Radio, etc. 0 - NS.NASA.GOV - 192.203.230.10 1 - NS.NIC.DDN.MIL - 192.112.36.4 2 - AOS.ARL.ARMY.MIL - 128.63.2.53 3 - NS.UNETY.NET - 207.32.128.1 4 - 5 - 6 - 7 - @@@@ -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa02829; 7 Nov 96 17:26 EST Received: from mail.his.com by ietf.org id aa02635; 7 Nov 96 17:24 EST Received: from 205.252.80.251 (tiernojo.his.com [205.252.80.251]) by mail.his.com (8.6.9/8.6.12) with SMTP id RAA23126; Thu, 7 Nov 1996 17:17:29 -0500 Message-ID: <328260F4.3BB4@his.com> Date: Thu, 07 Nov 1996 17:22:42 -0500 Sender:ietf-request@ietf.org From: "Tierno S. Bah" Reply-To: tiernojo@his.com Organization: AfriQ*Access, Inc. X-Mailer: Mozilla 3.01 (Macintosh; I; 68K) MIME-Version: 1.0 To: HANK@vm.biu.ac.il CC: newdom@ns1.vrx.net, ietf@ietf.org Subject: Re: More iTLD thread References: <9611070428.aa10502@ietf.org> <32824D67.5DD0@his.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Hank Nussbacher wrote: > > There should be 4-5 [true root nameservers] in > Europe, 2-3 in the Far East and about 6-7 in North America all funded > via new iTLDs. What about Central, South America? What about Africa? > As a former American who moved to Israel 15 years ago I have to agree > with you. Americans are very geo-centric and have a hard time understanding > the mentalities of other countries. Judging by your deliberate way of shrinking the world by excluding Africa and C-S America, one might think that the above diagnosis (geo-centrism & narrow-mindedness) applies to you. Either you caught them in the USA, or you developed them on you own. However, at the risk of becoming a shadow of itself, the Internet shall span and integrate the entire planet Earth, i.e., all five (5) continents. Otherwise, it may suffer the same fate that has discredited previous threshold technologies, which fell short of their initial universal promise, becoming instead tools of arrogance and hegemony... Already, Internet engineers and multinationals, not unlike the 19th century European explorers (Livingston, Cecil Rhodes, de Sanderval etc.), are crusing Africa, tricking or colluding with complacent PSTN offcials, and surrepticiously taking over functions that are arguably sovereign attributes of States, such as country registration with the InterNIC, DNS and IP addresses management ... As the saying goes, "The more things change, the more they remain the same". When all the hype and excitement have subsided, the continents, countries and people you so flagrantly rule out may well see in the Internet something deja vu and questionable, because it will have left them more disenfranchised than ever before. - Tierno Bah -- Voice: 301-680-1971 Fax: 301-680-0567 ************************************************************************* Midho yhawi e tulde gandun am On my little knowledge I stand No mi yheewira nibhe majjere am. To gauge the depth of my ignorance. (T.S. Mombeya) ************************************************************************* -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCPAzHtEI4AAAEEANx5MlMCbiXdbWCJq9PsuL9zEBwJ+4LUQwn6BjWO/0pQ05iv gNsUeZiG2YfepjrH0ZJTjaJ89JESQThpjvwi1F/4e7ZuVQuYaRxHhV6nsSVJ9c3p rjk0kD++sT3esvxd9KK/B64DhNov5rl4lzMLcMmBrmB8YgL+G832steTFXWBABEB AAGwAYe0IFRpZXJubyBTLiBCYWggPHRpZXJub2pvQGhpcy5jb20+sAED =ZPmR -----END PGP PUBLIC KEY BLOCK-----   Received: from ietf.org by ietf.org id aa03211; 7 Nov 96 17:29 EST Received: from vm.biu.ac.il by ietf.org id aa03141; 7 Nov 96 17:28 EST Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 1507; Thu, 07 Nov 96 22:23:37 IDT Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 3015; Thu, 7 Nov 1996 22:23:38 +0200 Date: Thu, 07 Nov 96 22:20:11 IDT Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: The cartel begins to crumble? To: karl@mcs.net, Hank Nussbacher cc: ietf@ietf.org In-Reply-To: Message of Thu, 7 Nov 1996 14:04:54 -0600 (CST) from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611071728.aa03141@ietf.org> Source-Info: From (or Sender) name not authenticated. On Thu, 7 Nov 1996 14:04:54 -0600 (CST) you said: >(1) You have to have operational nameservers for the domain you are > requesting. That is ALREADY a requirement of many of the eDNS > registries (ours included). The check for those authoritative NS > lines is automatic. > > We have stopped *hundreds* of attempted grabs in the eDNS tlds we > run ALREADY, and doing so took no manpower. The computer did the > work for us. So you discriminate between those with the technical knowledge to be able to set up a NS and add a few SOAs vs those who don't have a clue and simply call up and want to grab a name? > >(2) You have to pay (presumably) for the registrations you file. This > is a check and balance in and of itself. $50 per domain is nothing for a valuable DN. Hank   Received: from ietf.org by ietf.org id aa04472; 7 Nov 96 17:46 EST Received: from ietf.org by ietf.org id aa03925; 7 Nov 96 17:40 EST To: IETF-Announce: ; Subject: 37th IETF - List of Registered Attendees Date: Thu, 07 Nov 1996 17:40:12 -0500 Sender:ietf-announce-request@ietf.org From: Marcia Beaulieu Message-ID: <9611071740.aa03925@ietf.org> *******Early Registration Cut-off is TOMORROW, Friday, November 8, 1996***** If you register ON or BEFORE November 8, your registration fee will be $250.00, if you register AFTER November 8, your registration fee will be $270.00. The following is a list of registered attendees as of Thursday, November 7 at 5:00pm (EST). 1 Aboba, Bernard Microsoft Corporation 2 Adam, Daniel Microsoft Corporation 3 Adams, Robert Cisco Systems 4 Agbleze, Mawuse FTP Software, Inc. 5 Ahmed, Masuma Terayon Corporation 6 Ahuja, Ratinder Cisco Systems 7 Aibara, Reiji Hiroshima University 8 Alaettinoglu, Cengiz Information Sciences Institute 9 Alden, Roland 10 Alexander, Steve Silicon Graphics, Inc. 11 Allen, Edward Bay Networks, Inc. 12 Allen, Jeff Bunyip Information Systems 13 Allen, Terry Fujitsu Software Corp. 14 Allocchio, Claudio National Institute for Nuclear Physics, Italy 15 Almes, Guy Advanced Network and Services, Inc. 16 Alterman, Louise Lucent Technologies 17 Amano, Akira Hiroshima City University 18 Ambler, Christopher Image Online Design, Inc. 19 Amidon, Keith Hewlett-Packard 20 Anatov, Vadim Pluris, Inc. 21 Andersson, Loa Eriksson 22 Angelopoulos, Spiros Sterling Software 23 Aprille, Thomas Lucent Technologies, Bell Laboratories 24 Arango, Jesus Supernet S.A. 25 Ariaans, J.L. Unisource Business Networks Netherlands B.V. 26 Armitage, Grenville Bellcore 27 Armstrong, Susie Qualcomm Inc. 28 Arneson, David Digital 29 Aronson, Jules National Library of Medicine 30 Arunkumar, Nagaraj 3Com Corporation 31 Asano, Kazuo Fujitsu Laboratories Ltd. 32 Aspinwall, Russell Calyx UK Ltd. 33 Atkinson, Randall Cisco Systems 34 Audet, Francois Nortel 35 Auerbach, Karl Precept Software, Inc. 36 Austein, Robert Epilogue Technology Corporation 37 Back, Nigel BT Laboratories 38 Bailey, Chase Cisco Systems 39 Bailey, Ed IBM Corporation 40 Baker, Fred cisco Systems 41 Bakker, Steven DANTE 42 Balenson, David Trusted Information Systems 43 Bannister, Joseph USC/ISI 44 Bantel, Richard Lucent Technologies 45 Bare, Ballard Hewlett-Packard 46 Barnes, Jim Bay Networks 47 Barrett, Alan UUNET Internet Africa 48 Bates, Tony Cisco Systems 49 Bathina, Raghu Trancell Systems, Inc. 50 Beaulieu, Marcia Corporation for National Research Initiatives 51 Bedell, J. Patrick 52 Behrle, Jeremy Cisco Systems 53 Bellovin, Steven AT&T Research 54 Berger, Lou FORE Systems 55 Berkhout, Vincent DANTE 56 Bernardi, Marco CSELT 57 Berson, Steven Information Sciences Institute 58 Beyer, Mark Netmanage, Inc. 59 Bhoajaraj, Sandya Hewlett-Packard 60 Bhogavilli, Suresh Information Sciences Institute 61 Bierman, Andy Cisco Systems, Inc. 62 Billau, Roger Re/Spec Inc. 63 Binder, Richard Corporation for National Research Initiatives 64 Bird, Lester Novell, Inc. 65 Blake, Steven IBM Corporation 66 Blanchet, Marc Viagenie inc. 67 Blondel, P.F.C. S.A.R.A. 68 Blumenthal, Uri IBM Corporation 69 Bolot, Jean-Chrysostome INRIA Sophia Antipolis 70 Borden, Marty Bay Networks, Inc. 71 Borinski, Stan Realogic, Inc. 72 Borman, David Berkeley Software Design, Inc. 73 Boroumand, Javad USC-ISI 74 Boroumand, Sepideh NASA GSFC/HSTX 75 Bos, Erik-Jan SURFnet bv 76 Bosch, Brad Computer Associates 77 Boudreaux, John Daleen Technologies, Inc. 78 Boulianne, Luc McGill University 79 Bound, Jim Digital Equipment Corporation 80 Bowen, Rich NetEdge Systems, Inc. 81 Boyle, Jim The MITRE Corporation 82 Braden, Robert Information Sciences Institute 83 Bradescu, Roxana Sun Microsystems, Inc. 84 Bradner, Scott Harvard University 85 Breed, Charles Pretty Good Privacy, Inc. 86 Breslau, Lee Xerox PARC 87 Briceno, Marc DigiCash, Inc. 88 Bridgham, David Epilogue Technology Corporation 89 Brim, Scott Cornell University 90 Brochu, Alain Plaintree Systems 91 Brockners, Frank University of Cologne - ZPR 92 Brody, Lawrence AT&T 93 Brown, Anne Nortel Technology 94 Brown Klinger, Sheila Lucent Technologies 95 Brownlee, Nevil University of Auckland 96 Buchko, Steven Newbridge Networks Inc. 97 Buclin, Bertrand AT&T International 98 Burgan, Jeffrey Bay Networks, Inc. 99 Burke, Robert NetSpeed 100 Burle, Marlene Conferon, Incorporated 101 Bush, Randy NSRC 102 Cabeca, Linda Bay Networks, Inc. 103 Cai, Yiqun Northern Telecom 104 Cain, Patrick BBN Corporation 105 Cajano, Alessandro Telecom Italia 106 Calcari, Susan InterNIC/University of Wisconsin 107 Calhoun, Pat US Robotics Access Corporation 108 Callaghan, Brent Sun Microsystems, Inc. 109 Callon, Ross Cascade Communications 110 Calvert, Kenneth Georgia Institute of Technology 111 Cansever, Derya GTE Laboratories, Inc. 112 Caradec, Jean-Philippe Hewlett-Packard France 113 Card, James Nokia Telecommunications 114 Carlos, Sennen Network General Corporation 115 Carlson, John University of Washington 116 Carlson, Richard Argonne National Laboratory 117 Carney, Michael Sun Microsystems, Inc. 118 Carpenter, Brian CERN 119 Carrel, David Cisco Systems 120 Carter, Stephen Novell, Inc. 121 Carugo, Marco CNET France Telecom 122 Casner, Stephen Precept Software, Inc. 123 Caswell, Peter US Robotics 124 Cerveny, William Advanced Network and Services, Inc. 125 Chambliss, Warren Hewlett-Packard 126 Chandika, Naga Apple Computer 127 Chang, Shu-jen NIST 128 Chang, Sunny Apple Computer 129 Chefurka, Paul Plaintree Systems Inc. 130 Chen, Yao-Min Fujitsu Laboratories of America 131 Cherenson, Andrew Liquid Audio, Inc. 132 Chiotasso, Chris BGS Systems, Inc. 133 Chiu, Alex Sun Microsystems 134 Cho, Young-So E.T.R.I. 135 Chokhani, Santosh CynaCom Solutions, Inc. 136 Chon, Kilnam KAIST 137 Chong Fong, Yoshiko Asia Pacific Network Information Center 138 Choresh, Eyal LanOptics Ltd. 139 Chow, Jeff AMD 140 Christy, Greg Cisco Systems 141 Chu, H. K. Jerry SunSoft 142 Chung, Shiyun Fujitsu Business Communication Systems 143 Civanlar, Reha AT&T Research 144 Clark, Cynthia Corporation for National Research Initiatives 145 Clark, David Massachusetts Institute of Technology 146 Clark, Henry BBN Corporation 147 Clauberg, Axel University of Cologne 148 Clement, Taryn NCCOSC, San Diego 149 Cobo, Luis Pontificia Universidad Catolica del Peru 150 Cohen, Danny Myricom, Inc. 151 Cohen, Josh Netscape Communications 152 Cole, Robert Hewlett-Packard Laboratories 153 Colella, Richard America Online 154 Collins, John Rutgers University Computing Services 155 Comay, David Sun Microsystems, Inc. 156 Compton, Kip Continental Cablevision, Inc. 157 Conklin, Jim CREN 158 Cook, Gordon Cook Report on Internet 159 Copeland, Ken U.S. Dept. of Veterans Affairs 160 Corbato, Steven University of Washington 161 Corson, Scott University of Maryland 162 Corwin, BPS Inc. 163 Coya, Stephen Corporation for National Research Initiatives 164 Craren, Michael 3COM 165 Crawford, Matt Fermilab 166 Crawley, Eric Bay Networks, Inc. 167 Crowe, David NERO Network 168 Curran, John BBN Corporation 169 Curtin, Bill DISA 170 Dabbous, Walid INRIA 171 Dacuycuy, LaVergne Fujitsu Business Communication Systems 172 Daigle, Leslie Bunyip Information Systems 173 Dam, Tru Network Systems Corporation 174 Dang, Winston University of Hawaii 175 Daniel, Ron Los Alamos National Laboratory 176 Daoud, Edward Fujitsu 177 Davie, Bruce Cisco Systems 178 Dawkins, Spencer Nortel 179 de la Salle, Pierre Compuware 180 De Winter, Jack Wildbear Consulting, Inc. 181 Del Torto, Dave PGP, Inc. 182 Delagi, Bruce Apple Computer, Inc. 183 DeMatteis, Cheryl The Aerospace Corporation 184 Demirtjis, Ann Sprint 185 Demizu, Noritoshi Sony Computer Science Lab, Inc 186 Dinha, Francis NewCom Technologies,Inc. 187 Diot, Christophe INRIA 188 Dittler, Hans Braintec Network Consulting 189 Doi, Yuusuke KEIO University 190 Donelan, Sean Data Research Associates, Inc. 191 Donner, Paul 192 Doraswamy, Naganand FTP Software, Inc. 193 Dosedal, Anke Cisco Systems 194 Doyle, Robert Berkeley Networks 195 Dreyer, Jon Sun Microsystems 196 Droms, Ralph Bucknell University 197 Droz, Patrick IBM Research Laboratory 198 Dumitru, Don Microsoft Corporation 199 Duncan, Ian Newbridge Networks Inc. 200 Duniho, Michael National Security Agency 201 Dunn, Jeffrey Hewlett-Packard 202 Dunstan, Adam Bay Networks, Inc. 203 Dupont, Francis INRIA Rocquencourt 204 Durand, Alain Institut de Mathmatiques Appliquees de Grenoble 205 Duros, Emmanuel INRIA 206 Dyer, John Terena 207 Earhart, Rob Carnegie Mellon University 208 Eastlake, Donald CyberCash, Inc. 209 Eisler, Mike Sun Soft Inc. 210 Elkins, Michael Trusted Information Systems, Inc. 211 Ellehauge, Peter Dansk Data Elektronik A/S 212 Ellerbee, Jeff ichat Inc. 213 Ellesson, Ed IBM Corporation 214 Ellis, Gehrett Corporation for National Research Initiatives 215 Elz, Robert University of Melbourne 216 Emery, Nick AltaVista Internet Software 217 Engel, David Optical Data Systems, Inc. 218 England, Kent Six Sigma Networks 219 Erickson, Rodger Wall Data 220 Eriksson, Johnny KTHNOC 221 Erlinger, Michael The Aerospace Corporation 222 Estrin, Deborah Information Sciences Institute 223 Fair, Erik Apple Computer, Inc. 224 Fajman, Roger National Institutes of Health 225 Falk, Bennett Sybase 226 Fang, Hsin National Institute of Standards and Technology 227 Farinacci, Dino Cisco Systems, Inc. 228 Fasano, Paolo CSELT 229 Faynberg, Igor Lucent Technologies 230 Ferenz, David Price Waterhouse LLC 231 Ferguson, Dennis Juniper Networks 232 Ferguson, Paul Cisco Systems 233 Fernandez, Antonio Bellcore 234 Ferracin, Joseph SITA/ITS 235 Fink, Robert Lawrence Berkeley Laboratory 236 Finkelstein, David Xcert Software Inc. 237 Firenze, Mary NetManage, Inc. 238 Flanigan, William Defense Information Systems Agency 239 Fleshman, Michael Clearview Systems, Inc. 240 Ford, Warwick 241 Forster, James Cisco Systems 242 Forsythe, Margaret Epilogue Technology Corp. 243 Fowler, Dave Newbridge Networks Inc. 244 Fox, Barbara Microsoft Corporation 245 Fox, Craig Cisco Systems 246 Fox, Daniel Bay Networks 247 Francis, Paul NTT Software Lab 248 Frankhauser, Martine SITA 249 Fraser, Barbara CERT Coordination Center 250 Frei, Randy Com21 251 Fritz, Thomas barili systems limited 252 Fu, James Nokia Telecommunications Inc. 253 Fujikawa, Kazutoshi Boston University 254 Fujikawa, Kenji Kyoto University 255 Fukushima, Hidehiro Hitachi Ltd. 256 Fuller, Vince BBN Corporation 257 Fumeno, Takanori Telecoment Inc. 258 Furuseth, Hallvard University of Oslo 259 Gadre, Jay Bell Atlantic 260 Gahrns, Mike Microsoft Corporation 261 Galvin, James CommerceNet 262 Ganguly, Anik Campbell Services Inc. 263 Garcia, Francisco Hewlett-Packard Laboratories 264 Garrett, Mark Bellcore 265 Gastonde, Sunil Cisco Systems 266 Gilliam, William Hewlett-Packard 267 Gilmore, John Electronic Frontier Foundation 268 Girod, Lewis Massachusetts Institute of Technology 269 Glass, Steven FTP Software, Inc. 270 Glatting, Dennis CyberSafe Corporation 271 Goel, Vab Sprint 272 Goland, Yaron Microsoft 273 Gold, Harry NCCOSC 274 Goldsmith, Eric Applied Innovation, Inc. 275 Goller, Sean Carnegie Mellon University 276 Golshan, Ali 3Com Corporation 277 Gonzalez, Ricardo Hypertech Corporation 278 Gorden, Bengt KTHNOC 279 Goto, Yukinori Institute of Systems & Information Technology 280 Govindan, Ramesh Information Sciences Institute 281 Goyal, Mukul Sun Microsystems, Inc. 282 Gray, Eric 283 Gray, Terry University of Washington 284 Greene, Barry Cisco Systems 285 Greene, Jeremy Xedia Corporation 286 Greene, Maria Ascom Nexion, Inc. 287 Grill, Thomas E-Systems 288 Gudmundsson, Olafur Trusted Information Systems 289 Gupta, Rajeev Trillium Digital Systems, Inc. 290 Gupta, Vipul Sun Microsystems, Inc. 291 Gurajapu, Suresh Trancell Systems, Inc. 292 Haller, Neil Bellcore 293 Halpern, Joel Newbridge Networks Inc. 294 Halpin, James U.S. Robotics 295 Hambridge, Sally Intel Corporation 296 Hamilton, Martin University of Technology, Loughborough 297 Handelman, Sigmund IBM Corporation 298 Haney, Craig Cando Consulting 299 Hanna, Donal Netskills 300 Hansen, Karen Ohio University 301 Hardie, Ted NASA Science Internet 302 Harrington, Dan Lucent Technologies 303 Harrison, Sari Apple Computer Inc. 304 Hasegawa, Yusaku Nara Institute of Science & Technology 305 Haskin, Dimitry Bay Networks, Inc. 306 Hawkinson, John BBN Planet 307 Heard, C.M. VVNET, Inc. 308 Hedberg, Roland SUNET 309 Heffernan, Andy cisco Systems 310 Heffner, Wendy U.C. Berkeley 311 Heidemann, John USC/ISI 312 Hernacki, Brian Netscape Communications, Inc. 313 Herron, Andrew Microsoft Corporation 314 Herzog, Shai IBM 315 Hetzel, Dorn HLC/Epoch Networks 316 Hien, Nguyen IBM Corporation 317 Hildenbrand, Bruce Sun Microsystems 318 Hilton, Rhonda Cable Television Laboratories 319 Hinden, Robert Ipsilon Networks, Inc. 320 Hirabaru, Masaki Merit Network, Inc. 321 Hirai, Chiaki Hitachi Ltd. 322 Hobby, Russ University of California, Davis 323 Hoffman, Don Sun Microsystems, Inc. 324 Hoffman, Paul Internet Mail Consortium 325 Hofmann, Jeanette WZB 326 Holcomb, Jeff Apple Computer, Inc. 327 Holdrege, Matt Ascend Communications 328 Hole, Steve The Esys Corporation 329 Holmstead, Stephen Hewlett Packard 330 Honce, Jhon Hughes STX 331 Honnur, Virupaksh Cisco Systems 332 Hopkins, Gerry Bell Atlantic 333 Hopprich, John Cisco Systems 334 Hornby, Peter Unisys Corporation 335 Horneffer, Martin University of Cologne 336 Horowitz, Marc Cygnus Support 337 Hoschka, Philipp INRIA-Rodeo 338 Hosein, Javed Bay Networks, Inc. 339 Hoshi, Tohru Hitachi, Ltd. 340 Huang, Chia-Li Nokia Telecommunications 341 Huber, Rick AT&T Bell Laboratories InterNIC 342 Huddle, Scott MCI Telecommunications Corporation 343 Huitema, Christian Bellcore 344 Huizer, Erik SURFnet Expertise Center 345 Hunt, Bill VPNet Technologies, Inc. 346 Hur, Matt Cyber Safe Corporation 347 Huss, Claude Matsushita Electric Works US R&D Laboratories 348 Huston, Geoff Telstra 349 Hyman, Marco 350 Ilgun, Koral Advanced Computer Communications 351 Inbar, Ofer The Left Bank Operation, Inc. 352 Inoue, Takash Furukawa Electric Technologies 353 Inoue, Yoshinobu Fujitsu Laboratories Ltd. 354 Irlam, Gordon Cygnus Support 355 Ishiguro, Kunihiro DML 356 Ishiyama, Masahiro Toshiba Corporation 357 Iuso, Francesco Telecom Italia 358 Iversen, Ruben Dan Net 359 Iwata, Atsushi NEC Corporation 360 Jackowski, Steven NetManage, Inc. 361 Jacobs, Stuart GTE Laboratories 362 Jacobsen, Ole ConneXions 363 Jennings, Barbara Sandia National Laboratories 364 Jensen, Del Novell, Inc. 365 Jiang, Jonathan Bellcore 366 Jinzenji, Hiroshi NTT Human Interface Labs 367 Johnson, Jeff Cisco Systems 368 Johnson, Keith Federal Express Corporation 369 Johnson, Richard Cisco Systems 370 Johnson, Terry Develcon Electronics Ltd. 371 Johnson, Tony Network Systems Corporation 372 Jokubaitis, Vito AT&T 373 Jones, Ken Bay Networks, Inc. 374 Jork, Markus Digital Equipment GmbH 375 Joseph, Mark Attachmate Corporation 376 Juliano, Bryan NASA/Ames 377 Kaat, Marijke SURFnet Expertise Center 378 Kalbfleisch, Carl On-Ramp Technologies, Inc. 379 Kalra, Sanjay Cisco Systems 380 Kapil, Vivek Nortel Technology 381 Kapur, Arun Quadritek Systems, Inc. 382 Kashima, Hiroaki Fujitsu Ltd. 383 Kassi-Lahlou, Mohammed France Telecom 384 Kastenholz, Frank FTP Software, Inc. 385 Kato, Akira The University of Tokyo Computer Center 386 Katsube, Yasuhiro Toshiba Corporation 387 Kaufman, Charlie Iris Associates 388 Kawano, Tetsuo NTT Software Laboratories 389 Kellenbenz, Jerry Apple Computer, Inc. 390 Kemp, David National Security Agency 391 Kennedy, John Novell Inc. 392 Kennedy, L. Sean BBN Corporation 393 Kent, Stephen BBN Corporation 394 Kermode, Roger MIT Media Lab 395 Kern, Ed DIGEX 396 Keromytis, Angelos University of Pennsylvania 397 Kessens, David USC/ISI 398 Key, Kenneth Cisco Systems 399 Khalsa, Kirpal Lotus ccMail 400 Khare, Rohit W3 Consortium 401 Kim, Charlie Apple Computer, Inc. 402 Kim, Dae Sik ETRI 403 Kim, David Apple Computer 404 Kim, Dorian CICNet, Inc. 405 Kim, Hyogon Bellcore 406 Kim, Young-kyun National Computerization Agency 407 Kirani, Shekhar Starfish Software 408 Kirchhoff, Julie Corporation for National Research Initiatives 409 Kirstein, Peter University College London 410 Kiyoshima, Naoki Ultra-high Speed Network & Computer Tech. Labs. 411 Klensin, John MCI Telecommunications Corporation 412 Knuutila, Timo Nokia Research Center 413 Kobayashi, Masayuki CSR co., Ltd. 414 Koch, Harald Secure Computing Canada Ltd. 415 Koester, Greg Bay Networks 416 Komiya, Masakatsu Japan Satellite Systems Inc. 417 Kondo, Kuniaki Dream Train Inernet, Inc. 418 Kopsa, Ray Cygnet 419 Korver, Brian Terisa Systems, Inc. 420 Koskelainen, Petri Nokia Research Center 421 Kosters, Mark InterNIC 422 Krawczyk, John Bay Networks, Inc. 423 Krechmer, Ken Action Consulting 424 Kristol, David Lucent Technologies, Bell Laboratories 425 Krol, Edward University of Illinois Urbana 426 Krupczak, Cheryl Empire Technologies, Inc. 427 Kuang, Fidelia Apple Computer Inc. 428 Kuehne, Mirjam RIPE NCC 429 Kumar, Sanjay First Virtual Corporation 430 Kumar, Vinay ICAST Communications, Inc. 431 Kumarasamy, Jay Novell, Inc. 432 Kunze, John UCSF Center for Knowledge Management 433 Kurakami, Hiroshi NTT Multimedia Networks Labs 434 Kurn, David Tandem Computers Inc. 435 Kuroda, Yasutsugu Fujutsu Laboratory Ltd. 436 Kwan, Stuart Microsoft Corporation 437 Kwan, William Jupiter Technology, Inc. 438 Lahey, Kevin NASA/Ames Research Center 439 Lamond, Keith British Telecom North America 440 Lang, Ruth SRI International 441 Langeveld, Henk Sun Microsystems 442 Langlois, Sylvain Electricite de France 443 Lanphier, Rob Progressive Networks 444 Larsson, Jorgen Telia AB 445 Lasker, Valerie Precept Software, Inc. 446 Latzko, Alex Rutgers University Computing Services 447 LaVange, Don Novell, Inc. 448 Laviano, Vincent George Mason University 449 Lavu, Lava George Mason University 450 Lawler, John VPNet Technologies, Inc. 451 Lear, Eliot Silicon Graphics, Inc. 452 Lechner, Mikel NEC Technologies 453 Lee, C.J. Novell, Inc. 454 Lee, Dongho Kwangwoon University 455 Lee, WeeSan USC/ISI 456 Leech, Marcus Nortel Technology 457 Leinen, Simon SWITCH 458 Lemaire, Thomas 3Com Corporation 459 Lenggenhager, Thomas SWITCH 460 Lenharth, William University of New Hampshire 461 Leong, Ivan Pacific Internet Pte. Ltd. 462 Leroy, David FORE Systems 463 Leu, Brian Semaphore Communications Corp. 464 LeValley, Jim Macmillan Technical Publishing 465 Levi, Steven Microsoft Corporation 466 Levinson, Ed XIson, Inc. 467 Lewis, Edward Trusted Information System 468 Li, Hongqing Lucent Technologies 469 Li, Jian Sprint 470 Li, Tony Juniper Networks Inc. 471 Li, Yan-Fa Hewlett-Packard 472 Liau, Wendy Oracle Corporation 473 Lichtensteiger, Reto Mitsubishi Electric ITA 474 Lim, Koon Sang Logic Group of Companies 475 Ling, Lin SunSoft 476 Ling, Wenken Bay Networks, Inc. 477 Linn, John OpenVision Technologies 478 Liu, Eric Cable & Wireless 479 Liu, Yuan-Kwei NASA Ames Research Center 480 Lord, Anne UUNET PIPEX 481 Love, E. Paul Internet Consulting of Vermont 482 Lu, Hui-Lan Lucent Technologies 483 Lu, Vivian NetEdge Systems, Inc. 484 Luciani, James Bay Networks, Inc. 485 Lund, Craig Mercury Computer Systems, Inc. 486 Lundblade, Laurence Qualcomm Inc. 487 Luotonen, Ari Netscape Communications 488 Lutz, Raymond Cognisys Inc. 489 Macker, Joseph US Naval Research Laboratory 490 Mader, Keith Bay Networks, Inc. 491 Madison, Eric ACSI 492 Maeda, Kaori Hiroshima City University 493 Mahdavi, Jamshid Pittsburgh Supercomputing Center 494 Maher, Maryann USC/ISI 495 Malamud, Carl MIT Media Lab 496 Malcolm, Andrew SCO 497 Malis, Andrew Ascom Nexion, Inc. 498 Malkin, Gary Bay Networks 499 Mallory, Tracy 3Com Corporation 500 Mamros, Shawn FTP Software, Inc. 501 Mankin, Allison Information Sciences Institute 502 Mannie, Eric Brussels University 503 Manning, Bill Information Sciences Institute 504 Marine, April NASA NIC 505 Markham, Tom Secure Computing Corp. 506 Marsh, Ian Swedish Institute of Computer Science 507 Martillo, Joachim Telford Tools, Inc. 508 Martin, Antony DRA 509 Martin, Cynthia Defense Information Systems Agency 510 Martin, John TERENA 511 Maruyama, Mitsuru NTT Software Laboratories 512 Masinter, Larry Xerox Corporation 513 Maston, Michael Cisco Systems 514 Mather, Tim Apple Computer 515 Mathis, Matt Pittsburgh Supercomputing Center 516 Matsuhira, Naoki Fujitsu Laboratories Ltd. 517 Matsukata, Jun National Center for Science Information Systems 518 Matsune, Mio Network Information Service Co 519 Matsushita, Nobuo Bell Labs, Lucent Technologies 520 Maughan, Douglas National Security Agency 521 Maw, Tim Stentor Resource Centre Inc. 522 Maxham, Mark Apple Computer, Inc. 523 Mazzucato, Sandro Bunyip Information Systems 524 McBurnett, Neal Lucent Technologies, Bell Labs 525 McCann, Jack Digital Equipment Corporation 526 McCloghrie, Keith cisco Systems 527 McCollum, Bob SAIC 528 McCooey, Jeremy University of New Hampshire 529 McDonald, Daniel Sun Microsystems, Inc. 530 McGarvey, John IBM 531 McManis, Chuck Free Gate Corporation 532 McMaster, Donna Cisco Systems 533 McMillan, Tom 3Com Primary Access 534 McPherson, Danny MCI Telecommunications Corporation 535 Mealling, Michael Network Solutions, Inc. 536 Medrinsky, Ari Cyber Safe Corporation 537 Medued, Patrick Computer Associates 538 Mehta, Mehul Apple Computer 539 Mende, Robert Silicon Graphics, Inc. 540 Merchant, Shashank Advanced Micro Devices 541 Metzger, Perry Piermont Information Systems 542 Meyer, David University of Oregon 543 Meyer, Gerry Shiva Limited 544 Miller, Quentin Microsoft Corporation 545 Miller, Thomas Siemens 546 Miller, W. Marcus Lawrence Livermore National Labs 547 Millington, Linda Control Data Systems, Inc. 548 Mills, Cynthia GTE Laboratories, Inc. 549 Milnes, Brian Lycos, Inc. 550 Minami, Masaki Keio University 551 Minshall, Greg Ipsilon Networks, Inc. 552 Mistry, Danny Nortel Technology 553 Moats, Ryan AT&T Bell Laboratories InterNIC 554 Mogul, Jeffrey Digital Equipment Corporation 555 Mohta, Pushpendra CERFnet 556 Monsour, Robert Hi/fn, Inc. 557 Montenegro, Gabriel Sun Microsystems, Inc. 558 Moore, Keith University of Tennessee 559 Moore, Mike Hewlett-Packard 560 Moore, Richard Michigan State University 561 Moore, Robert IBM Corporation 562 Morgan, Bob Stanford University 563 Morla, Kim Pontificia Universidad Catolica del Peru 564 Morris, David barili systems limited 565 Morris, Jonathan Manchester Metropolitan University 566 Morse Johnson, Kelly Cisco Systems 567 Moscaritolo, Vinnie Apple Computer 568 Moskowitz, Robert Chrysler Corporation 569 Mouradian, George AT&T Laboratories 570 Moy, Diana U.S. Robotics 571 Moy, John Cascade Communications Corporation 572 Muller, Claude Hewlett-Packard Laboratories 573 Mundy, Russ Trusted Information Systems 574 Murai, Jun Keio University 575 Murphy, Patrick U.S. Geological Survey 576 Murphy, Sandra Trusted Information Systems 577 Murray, Cecil Campbell Services Inc. 578 Mutz, Andrew Hewlett-Packard 579 Myers, John Carnegie Mellon University 580 Myjak, Michael University of Central Florida 581 Na, Jung-jung National Computerization Agency 582 Nagami, Ken-ichi Toshiba Corporation 583 Nahm, Stephen Sun Microsystems, Inc. 584 Nakamura, Osamu Keio University 585 Napjus, Erikas Carnegie Mellon University 586 Narayan, Vishy NASA Ames Research Center 587 Narayana, Raj Cable & Wireless 588 Narten, Thomas IBM Corporation 589 Nassi, Ike AppleSoft 590 Natale, Bob American Computer and Electronics Corporation 591 Neely, W. Shields National Semiconductor 592 Neer, Merle NRaD 593 Nelson, JoAnn NASA Science Internet 594 Nemeth, Evi University of Colorado 595 Nerenberg, Lyndon The Esys Corporation 596 Nesser, Philip Nesser & Nesser Consulting 597 Nessett, Dan 3Com Corporation 598 Neuman, Clifford Information Sciences Institute 599 Newman, Chris Innosoft International, Inc. 600 Ng, Fo Hong Kong Supernet 601 Nguyen, Hai Raytheon E-Systems 602 Niazi, S. Chin Apple Computer Inc. 603 Nicklass, Orly RAD Data Communications 604 Nicklow, Doug Lycos, Inc. 605 Nielsen, Henrik World Wide Web Consortium 606 Niinomi, Tadafusa Fujitsu Laboratories Ltd. 607 Nikander, Pekka 608 Nishida, Takeshi NEC USA 609 Noerenberg, John Qualcomm Inc. 610 Nowicki, William Silicon Graphics, Inc. 611 O'Leary, David Cisco Systems 612 O'Leary, Peter Clear Blue Network Systems, Inc. 613 Obraczka, Katia USC/ISI 614 Oehler, Michael National Security Agency 615 Ogawa, Jun Fujitsu Lab. 616 Ohta, Masataka Tokyo Institute of Technology 617 Okamoto, Toshio Toshiba Corporation 618 Onishi, Steven Bay Networks, Inc. 619 Ooka, Toshio Sumitomo Electric USA, Inc. 620 Oran, David Cisco Systems 621 Ordille, Joann Bell Labs, Lucent Technologies 622 Orman, Hilarie DARPA/ITO 623 Ostrowski, Stephen 3Com 624 Overby, Mary UNC-CH 625 Ozaki, Satoshi Toshiba Corporation 626 Paez-Ramirez, Alonso BT Labs 627 Pang, Joseph Starlight Networks 628 Pareth, Sameer C2Net 629 Paridaens, Oliver Universite Libre de Bruxelles 630 Parker, Steve SunSoft, Inc. 631 Partan, Andrew WNA 632 Partington, Heath US Robotics Inc. 633 Patrick, Michael Motorola ISG 634 Patton, Michael 635 Perkins, Charles IBM Corporation 636 Perkins, Colin University College London 637 Perlman, Radia Novell, Inc. 638 Petke, Richard CompuServe, Inc. 639 Petronelli, Paul PALM Associates, Inc. 640 Pfenning, Thomas Microsoft Corporation 641 Picoto, Carlos University of Lisbon 642 Pierce, Greg Network Solutions, Inc. 643 Pilger, Alexander Siemens AG 644 Pink, Stephen Swedish Institute of Computer Science 645 Piper, Derrell Cisco Systems 646 Plzak, Ray SAIC 647 Postel, Jon Information Sciences Institute 648 Presuhn, Randy BMC Software, Inc. 649 Prior, Mark connect.com.au pty ltd 650 Pullen, J. Mark C3I Center 651 Pusateri, Tom Juniper Networks 652 Rabin, Tal IBM 653 Raghu, Jagannath Shomiti Systems, Inc. 654 Rajagopalan, Bala Bellcore 655 Rajagopal, Murali Fujitsu 656 Ramalingam, Jayakumar Novell, Inc. 657 Ramanan, P.S. Sprint Corporation 658 Randall, Karen AT&T Universal Card Services Corporation 659 Rank, Edward Bay Networks 660 Ravikanth, Ravadurgam Nokia Research Center 661 Ray, Cathe Sun Microsystems, Inc. 662 Reed, Benjamin IBM Corporation 663 Reeder, David Portland State University 664 Reitsma, Rob Unisource Business Networks 665 Rekhter, Yakov Cisco Systems 666 Renwick, John Ascend Communications 667 Rescorla, Eric Terisa Systems, Inc. 668 Resnick, Pete Qualcomm Inc. 669 Rex, Martin SAP AG 670 Reynolds, Joyce K. Information Sciences Institute 671 Richard, Pat Xcert Software Inc. 672 Richardson, John Intel Corporation 673 Rickard Bollentin, WendyOnTheInternet Magazine 674 Ridenour, Howard Apple Computer Inc. 675 Riordan, John Swiss Telecom 676 Robinson, David Sun Microsystems, Inc. 677 Rodney, Steve Racal - Datacom 678 Rogerson, Duncan University of London 679 Romanow, Allyn Sun Microsystems, Inc. 680 Romkey, John Blue Forest Research 681 Ronen, Elazar Radlinx Ltd. 682 Roque Marques, Pedro Universidade de Lisboa 683 Rose, Marshall T. First Virtual Holdings Inc. 684 Roselinsky, Milt Advanced Computer Communications 685 Rossen, Ken MCI Systemhouse 686 Routhier, Shawn Epilogue Technology Corporation 687 Royce, Kathy Bay Networks, Inc. 688 Ruth, Greg GTE Laboratories, Inc. 689 Rutkowski, Anthony General Magic, Inc. 690 Ryan, Gerard Bell Labs 691 Ryutov, Tatyana USC/ISI 692 Saito, Takeshi Toshiba Corporation 693 Sakamoto, Hiromitsu NEC Corporation 694 Sales, Bernard Alcatel Telecom 695 Salo, Timothy Minnesota Supercomputer Center 696 Salomon, Marc University of California 697 Samanick, John Defense Information Systems Agency 698 Samberg, Larry Maker Communications 699 Sandick, Hal IBM Corporation 700 Saperia, Jon BGS Systems, Inc. 701 Sarkezians, Hasmik US Robotics 702 Sarmiento, Ramiro Sun Microsystems, Inc. 703 Sawyer, Wilson Bay Networks/LANcity 704 Scano, John 3Com 705 Schertler, Mark Terisa Systems 706 Schey, John Europay International 707 Schiller, Jeffrey Massachusetts Institute of Technology 708 Schmechel, Christopher Sun Microsystems, Inc. 709 Schneider, Mark National Security Agency 710 Schneider, Wolfgang GMD 711 Schnell, Steven Sprint Government Systems Division 712 Scholl, Reinhard Siemens AG 713 Schulman, Martin Cisco Systems 714 Scott, Gregor Defense Information Systems Agency 715 Sedayao, Jeff Intel Corporation 716 Seto, Koichiro Hitachi Cable 717 Shand, Mike Digital Equipment Co. Ltd. 718 Shew, Stephen Nortel Technology 719 Shieh, Shuching Bay Networks, Inc. 720 Shimojo, Shinji Osaka University Computer Center 721 Shionozaki, Atsushi Sony Computer Science Laboratory 722 Shirey, Rob BBN Corporation 723 Shirley, Fred Sanders 724 Shmulevsky, Mark ADP, Inc. 725 Shobatake, Yasuro Toshiba Corporation 726 Sikora, John AT&T Bell Laboratories 727 Siller, Curtis Lucent Technologies 728 Simpson, William Computer Systems Consulting Services 729 Singh, Jasdip InterNIC 730 Sloane, Timon timonWare Inc. 731 Smith, Andrew NeoSoft, Inc. 732 Smith, Carl Sun Microsystems, Inc. 733 Smith, Michael TIAA-CREF 734 Smith, Philip UUNET PIPEX 735 Smith, Timothy IBM Corporation 736 So, Benny Novell, Inc. 737 Solensky, Frank FTP Software, Inc. 738 Sollins, Karen Massachusetts Institute of Technology 739 Solo, Dave BBN Corporation 740 Solomon, Jim Motorola 741 Sommerfeld, Bill Hewlett-Packard 742 Spatscheck, Oliver University of Arizona 743 Speer, Michael Sun Microsystems, Inc. 744 Spell, Charlie Cisco Systems 745 Spreitzer, Mike Xerox PARC 746 Sridhar, T. Future Communications Software 747 Srinivasan, Suresh Thomson Technology Services Group 748 Srinivasan, Andre Oracle Corporation 749 St. Johns, Michael @Home Network 750 Staubach, Peter Sun Microsystems, Inc. 751 Steenstrup, Martha BBN Corporation 752 Stefferud, Einar Network Management Associates 753 Stephens, Tom Microsoft Corporation 754 Stibler, Stephen IBM Corporation 755 Stockman, Bernhard Telia AB 756 Stuart, Wayne Cisco Systems 757 Sumikawa, Munechika Nara Institute of Science and Technology 758 Sumner, Mark Motorola 759 Sundell, Kenneth Ericsson Telecom AB 760 Suzuki, Muneyoshi NTT Multimedia Networks Labs 761 Swallow, George Cisco Systems 762 Swan, Matti Helsinki Telephone Company Ltd 763 Sweeney, Steven Apple Computer 764 Swink, Michael Sprint 765 Takada, Toshiaki Dream Train Internet, Inc. 766 Takamatsu, Satoshi NTT 767 Takeuchi, Shohei NEC Corporation 768 Takihiro, Masatoshi Hitachi Ltd. 769 Tallerico, David The MITRE Corporation 770 Talpade, Rajesh Georgia Institute of Technology 771 Tanaka, Kei Internet Initiative Japan Inc. 772 Tang, Cheng Hewlett-Packard 773 Taniguchi, Kunihiro NECUSA 774 Taylor, Peter Mailbase, Newcastle University 775 Tecot, Ed Apple Computer, Inc. 776 Teplitsky, Jacob Fore Systems 777 Teraoka, Fumio Sony Computer Science Laboratory, Inc. 778 Terpstra, Marten Bay Networks, Inc. 779 Tesink, Kaj Bellcore 780 Thatcher, Michael Thatcher Consulting Services 781 Thayer, Rodney Sable Technology Corporation 782 Thomas, Matt Digital Equipment Corporation 783 Thomas, Richard Nortel Technology 784 Thomas, Robert Berkeley Networks 785 Thomson, Susan Bellcore 786 Thurlow, Robert Sun Microsystems Inc. 787 Tirilok, Prem Computer Associates 788 Tomimura, Eiji Sumitome Electric USA, Inc. 789 Tominaga, Akihiro Keio University 790 Topolcic, Claudio BBN Corporation 791 Touch, Joseph USC/ISI 792 Tow, Agnes AT&T 793 Tracy, Michael Sunsoft 794 Traina, Paul Juniper Networks, Inc. 795 Tramposch, Albert World Intellectual Property Organization 796 Travis, Ward Cisco Systems 797 Trest, Mike ATMNET 798 Trostle, Jonathan CyberSafe Corporation 799 Ts'o, Theodore Massachusetts Institute of Technology 800 TSE, Hiu Wa Hong Kong Supernet Ltd. 801 Tsuchiya, Kazuaki Hitachi, Ltd. 802 Tsukada, Koji Hitachi, Ltd. 803 Tung, Brian Information Sciences Institute 804 Turaj, Nancy The MITRE Corporation 805 Turner, Randy Sharp Laboratories of America 806 Uehara, Keisuke KEIO University 807 Umeda, Masayoshi Nippon Telegraph and Telephone Corporation 808 Varnis, Harry Network Systems Corporation 809 Vaudreuil, Gregory Octel Network Services 810 Veach, Ross CICNet, Inc. 811 Veenstra, Jack AT&T 812 Vegesna, Srinivas Cisco Systems 813 Verina, Maria ICGEB 814 Verrilli, Colin IBM Corporation 815 Villanueva, Deric WRQ 816 Vinores, Cindy SunSoft 817 Vohra, Quaizar University of New Hampshire 818 von Kaenel, Juerg IBM 819 Vozza, Vincenzo Telecom Italia 820 Vu, Anh Fore Systems 821 Vu, Joseph Fore Systems 822 Vu, Trinh Secure Computing Corp. 823 Wada, Hiromi Matsushita Electric Industrial Company, Ltd. 824 Wahl, Mark Critical Angle, Inc. 825 Wall, Matt Carnegie Mellon University 826 Wallace, Dick Concord Communications, Inc. 827 Wallace, Leland Apple Computer Inc. 828 Ward, Carol NASA Ames Research Center 829 Watanabe, Ken Hitachi, Ltd. 830 Watt, James Newbridge Networks Inc. 831 Weaver, Elfed Defense Research Agency 832 Webber, Bob PictureTel Corporation 833 Weiler, Samuel Carnegie Mellon University 834 Weinrib, Abel Intel Corporation 835 Weise, Bernd DeteBerkom GmbH 836 Weiss, Howard SPARTA, Inc. 837 Wellens, Chris InterWorking Labs, Inc. 838 Wells, Amy Tracy InterNIC Net Scout 839 Wessels, Duane Nat'l Lab for Applied Netwrk Research 840 West, Jim Ciena Optical Communications 841 Whipple, Mark Octel Services 842 White, Gerry LANcity Corporation 843 White, Paul University College London 844 Wiebe, Walter Federal Networking Council 845 Williams, Carl Sun Microsystems, Inc. 846 Williamson, Scott Network Solutions, Inc. 847 Windrim, Mark Newstar Technologies 848 Winkler, Linda Argonne National Laboratory 849 Winter, Brian US Robotics Inc. 850 Won, King Network General Corp. 851 Woodcock, Bill Zocalo Engineering 852 Wright, Graham Hummingbird Communications 853 Wright, Russ Lawrence Berkeley Laboratory 854 Wroclawski, John Massachusetts Institute of Technology 855 Yamamoto, Kazuhiko Nara Institute of Science Technology 856 Yao, Kwang Hewlett-Packard 857 Yarnell, Jeff Kaspia Systems, Inc. 858 Yavatkar, Raj Intel Corporation 859 Yen, Leemay 3Com Corporation 860 Ying, Wen-Ping AT&T Wireless Services 861 Ylonen, Tatu SSH Communications Security 862 Yoshida, Shin Sumitomo Electric U.S.A., Inc. 863 Yoshida, Toshiaki Werk mikro systems, Ltd. 864 Yu, I-Hsiang GTE Laboratories Inc. 865 Zhang, Lixia UCLA 866 Zhang, Yi 3Com 867 Zhang, Zhaohui Bay Networks, Inc. 868 Zhao, Bill AT&T 869 Ziegast, Eric GTE Interactive Media 870 Ziemba, Paul Fore Systems 871 Zorn, Glen Microsoft Corporation   Received: from ietf.org by ietf.org id aa04473; 7 Nov 96 17:46 EST Received: from ietf.org by ietf.org id aa04052; 7 Nov 96 17:42 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: ietf-rsvp@ietf.org Subject: IETF MAILING: RSVP: December 9-13, 1996/San Jose, CA Date: Thu, 07 Nov 1996 17:42:29 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9611071742.aa04052@ietf.org> ***********Early Registration cut-off is November 8, 1996*********** REGISTRATION FORM 37th Internet Engineering Task Force - Page 1 of 2 December 9-13, 1996 San Jose, California, USA Please print or type: Name (Mr/Dr/Ms)__________________________________________________________ Title____________________________________________________________________ Organization_____________________________________________________________ Address__________________________________________________________________ _________________________________________________________________________ City_____________________________State_____________Postal Code___________ Country__________________________________________________________________ Telephone______________________________Fax_______________________________ Email____________________________________________________________________ Do you plan to attend the Sunday, DECEMBER 8th NEWCOMER'S ORIENTATION at 1530? YES___ NO___ Do you plan to attend the Sunday, DECEMBER 8th reception at 17:00? YES___ NO___ The IETF Proceedings are available electronically. Would you still like a hard copy? YES___ NO ___ US$250.00 Registration postmarked on or BEFORE, Friday, November 8, 1996. US$270.00 (US$250.00 + US$20.00 late fee) Registration postmarked after Friday, November 8, 1996. Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check (U.S. dollars, drawn on a U.S. Bank), payable to: Corporation for National Research Initiatives Account No.____________________________ Expiration Date__________________ Cardholder Name__________________________________________________________ Cardholder Signature_____________________________________________________ Registration Forms can be sent via electronic mail, facsimile, or postal mail: Electronic: ietf-rsvp@ietf.org Facsimile: +1-703-758-5913 Postal: Corporation for National Research Initiatives Accounting Department - 37th IETF Meeting 1895 Preston White Drive, Suite 100 Reston, VA 20191-5434 USA REGISTRATION FORM 37th Internet Engineering Task Force - Page 2 of 2 December 9-13, 1996 San Jose, California, USA IMPORTANT: 1. Payment MAY, but does NOT have to, accompany the Form. 2. As long as your Form is postmarked by the deadline date of November 8, 1996, you are locked in to pay the lower registration fee of $250.00 (e.g., send us your form via e-mail by the deadline date and pay the $250.00 fee later via postal mail). When paying by company check, be sure that your Accounting Department knows that you qualified yourself for the lower rate. 3. Payment is accepted on-site. 4. Register ONE person per form. Substitutions are NOT allowed. 5. Include a completed Registration Form with payment. 6. Purchase orders are NOT accepted. 7. DD Form 1556 IS accepted. 8. We CANNOT invoice for payment. 9. Registration Forms will be accepted via electronic mail and facsimile until 1300ET on Wednesday, December 4, 1996. 10. Requests for refunds must be received by 1700ET, Thursday, December 5, 1996. No refunds will be processed beyond this point. 11. REFUND POLICY: Refunds are subject to a US$20.00 service charge. Late fees WILL NOT be refunded. 12. Your registration fee includes Sunday evening reception (cash bar), and a daily continental breakfast and coffee breaks. For additional information or assistance, please contact +1-703-620-8990, +1-703-758-5913 (Fax) or ietf-rsvp@ietf.org. Direct all inquiries to: 37th IETF Meeting - San Jose, California, USA   Received: from ietf.org by ietf.org id aa04484; 7 Nov 96 17:46 EST Received: from ietf.org by ietf.org id aa04266; 7 Nov 96 17:43 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Geoff Huston Subject: 2nd Nominations Call Date: Thu, 07 Nov 1996 17:43:47 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611071743.aa04266@ietf.org> IETF CALL FOR NOMINATIONS ------------------------- It is the task of the IETF Nominations Committee to seek qualified candidates to fill half of the positions on the IESG and the IAB each year. 1. Open Positions ----------------- The positions which expire at the Spring 1997 IETF meeting are: IESG : Area Directors for: *Applications current incumbent is Harald Alvestrand *Operational Requirements current incumbent is Scott Bradner Internet current incumbent is Frank Kastenholz *Network Management current incumbent is Deirdre Kostick Transport current incumbent is Allison Mankin * There will be some changes to the IESG structure which will see the Network Management areas of activity being relocated within the Applications AD and a new Operations and Management AD. The Nominations Committee is seeking to fill the resultant 4 open slots on the IESG. IAB : 6 positions are to be nominated. These positions are currenly filled by: J Allard Elise Gerich Erik Huizer Robert Moskowitz Yakov Rekhter Chris Weider 2. Nominations -------------- Nominations are sought for these positions. Any member of the IETF community may nominate any member of the IETF community for any open position, as listed above. A self-nomination is permitted. All nominations must be directed by email to nomcom@telstra.net Nominations should include the name of the individual being nominated, the position to which the individual is being nominated and the basis of the nomination. The process is intended to seek the best leadership possible from within the IETF community, so qualities of leadership and extensive experience working within the IETF are considered desireable ` qualities for nominated individuals. IETF Nominations close on November 22 1996. 3. Milestones for the Nominations Committee ------------------------------------------- IETF Nominations October 23 - November 22 Evaluation of Nominated Individuals by the Nominations Committee October 23 - December 18 Obtain final consent for nomination from nominated individuals December 18 - December 23 Potential iteration of nominations (if final consent not obtained) December 23 - January 17 Prepare nominations and testaments December 23 - January 24 Pass nominations to confirming bodies January 27 (The absolute deadline for termination of this activity is 5 March 1997. This schedule attempts to complete the process well in advance of that date. 4. The IETF Nominations Committee --------------------------------- Those drawn from the hat to serve on the 1997 committee are: Guy Almes almes@betelgeuse.advanced.org Jim Bound bound@zk3.dec.com Matt Crawford crawdad@fnal.gov Phill Gross 0006423401@mcimail.com Bob Hinden hinden@ipsilon.com Dorian Kim dorian@cic.net Bill Manning bmanning@ISI.EDU Marshall Rose mrose.dbc@dbc.mtview.ca.us Mike StJohns stjohns@stjohns.eos.home.net Glen Zorn glennz@microsoft.com Plus the following non-voting members: Geoff Huston (chair) gih@telstra.net Joyce K. Reynolds (IESG liaison) jkrey@isi.edu Radia Perlman (IAB liaison) Radia_Perlman@novell.com Christian Huitema (ISOC liaison) huitema@bellcore.com collectively these folk can be addressed as nomcom@telstra.net 5. Documents ------------ The documents used by the committee are the POISED95 documents: RFC 2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", J. Galvin, 05/15/1996. RFC2028 The Organizations Involved in the IETF Standards Process", R. Hovey, S. Bradner, 06/11/1996.   Received: from ietf.org by ietf.org id aa05961; 7 Nov 96 18:00 EST Received: from zephyr.isi.edu by ietf.org id aa05830; 7 Nov 96 17:57 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 7 Nov 1996 14:56:45 -0800 Message-Id: <199611072256.AA15816@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2009 on GPS-Based Addressing and Routing Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 07 Nov 96 14:56:45 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2009: Title: GPS-Based Addressing and Routing Author: T. Imielinski, J. Navas Date: November 1996 Mailbox: {imielins,navas}@cs.rutgers.edu Pages: 27 Characters: 66,229 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2009.txt In this document we propose a family of protocols and addressing methods to integrate GPS into the Internet Protocol to enable the creation of location dependent services. IANA Note: This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. Please note that these addresses and names are not registered, assigned, allocated, or delegated to the use suggested here. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961107143612.RFC@ISI.EDU> SEND /rfc/rfc2009.txt --OtherAccess Content-Type: Message/External-body; name="rfc2009.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961107143612.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07484; 7 Nov 96 18:24 EST Received: from [207.32.128.130] by ietf.org id aa07414; 7 Nov 96 18:22 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id RAA26002; Thu, 7 Nov 1996 17:13:17 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCCCF.3AF74200@webster.unety.net>; Thu, 7 Nov 1996 17:15:10 -0600 Message-ID: <01BBCCCF.3AF74200@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Christopher Ambler' , "dcrocker@brandenburg.com" , "HANK@vm.biu.ac.il" Cc: "heath@linus.isoc.org" , "ietf@ietf.org" , "newdom@vrx.net" Subject: RE: IAHC Date: Thu, 7 Nov 1996 17:15:08 -0600 Encoding: 39 TEXT Source-Info: From (or Sender) name not authenticated. On Thursday, November 07, 1996 2:17 PM, Christopher Ambler[SMTP:chris@hal.iodesign.com] wrote: @ Please, Jim, calm down for a couple days, okay? @ @ Nobody is more anxious than I am to see the IAHC fully formed and working, @ as a prospective registry owner. I've waited over a year now for IANA, I @ can surely find something to occupy my time for 72 hours while the IAHC @ bootstraps themselves. @ @ -- @ Christopher Ambler @ President, Image Online Design, Inc. @ @ One thing you could do is work on a root name server. The Internet Infrastructure can use some more companies willing to donate bandwidth and equipment to help provide this important public service. I bet if you were nice, you could volunteer to operate that root name server on behalf of the ISOC. Maybe that would be a donation. The ISOC and the IAHC seem to be missing some key points. Their main objective should be to deploy a root name server, to help organize and sort out the situation with the 9 popular root name servers that seem to follow the ISOC direction, help to coordinate the global collection of root name servers and their interfaces to registries which have already started to operate. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa12937; 7 Nov 96 19:38 EST Received: from ng.netgate.net by ietf.org id aa12835; 7 Nov 96 19:36 EST Received: from [205.175.103.54] (conf1-54.conf.uwash.com [205.175.103.54]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA22404; Thu, 7 Nov 1996 16:44:51 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <199611071619.KAA18711@Mercury.mcs.net> References: <9611070426.aa09875@ietf.org> from "Hank Nussbacher" at Nov 7, 96 11:19:43 am Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Nov 1996 14:53:28 -0800 To: Karl Denninger Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: The cartel begins to crumble? Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 8:19 AM -0800 11/7/96, Karl Denninger wrote: >If a TLD is desirable, it will have NEW customers. I'd guess that any scheme that is adopted needs to handle the TRANSITION very, very carefully. Disruption of service is a fundamentally Bad Thing, as I'd predict you will agree. So, yes. If no one is using a TLD, who cares. But the instant there is even ONE user of a TLD, what is our "social" responsibility to ensure continuity of service (i.e., permanence of domain names)? We can certainly be cavalier and leave the whole matter to freemarket commercial forces, but we can also choose to require continuity. Personally, I would wish for the latter, if feasible. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa15822; 7 Nov 96 20:05 EST Received: from callandor.cybercash.com by ietf.org id aa15731; 7 Nov 96 20:02 EST Received: by callandor.cybercash.com; id TAA18129; Thu, 7 Nov 1996 19:56:43 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma018125; Thu, 7 Nov 96 19:56:31 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA13371; Thu, 7 Nov 96 19:59:03 EST Date: Thu, 7 Nov 1996 19:59:02 -0500 (EST) Sender:ietf-request@ietf.org From: "Donald E. Eastlake 3rd" To: Simon Higgs Cc: Jon Postel , ietf@ietf.org Subject: Re: [Question] IAHC = IDNB ??? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. The IDNB was to help settle disputes over who is to manage a domain that exists or is already specifically provided for, primarily the national TLDs. IAHC has to do with created new TLDs and handling registries for the global TLDs. In my opinion, both are simply creations of the IANA who, to the extent not constrained by standards/bcp actions of the IESG, has plenary authority over number/name assignment/registration within the IETF, using IETF in its broad sense, (subject to the possibility of being removed and a new IANA being appointed by the IAB). And what authorithy does the IETF, using IETF in its broad sense, have? Why, none at all except to the extent that people follow it, just like every other authority. Donald On Thu, 7 Nov 1996, Simon Higgs wrote: > Date: Thu, 7 Nov 1996 13:42:26 -0800 > From: Simon Higgs > To: Jon Postel > Cc: ietf@ietf.org, newdom@vrx.net, newdom@ar.com > Subject: [Question] IAHC = IDNB ??? > > Hi all, > > I'm trying to update draft-higgs-tld-cat for the IAHC committee's > review and have a protocol question. What is the difference between the > Internet Domain Name Board (IDNB) mentioned in some older RFC's and the > IAHC? They both appear to be performing the same executive domain name > functions. > > Thanks, > > Simon > > -- > Madness takes its toll. Please have exact change. > > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html   Received: from ietf.org by ietf.org id aa24005; 7 Nov 96 21:37 EST Received: from [207.32.128.130] by ietf.org id aa23882; 7 Nov 96 21:36 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id UAA26688; Thu, 7 Nov 1996 20:29:53 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCCEA.B212A300@webster.unety.net>; Thu, 7 Nov 1996 20:31:46 -0600 Message-ID: <01BBCCEA.B212A300@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Dave Crocker' , Karl Denninger Cc: "ietf@ietf.org" Subject: US Top Level Domain Date: Thu, 7 Nov 1996 20:31:44 -0600 Encoding: 138 TEXT Source-Info: From (or Sender) name not authenticated. On Thursday, November 07, 1996 4:53 PM, Dave Crocker[SMTP:dcrocker@brandenburg.com] wrote: @ At 8:19 AM -0800 11/7/96, Karl Denninger wrote: @ >If a TLD is desirable, it will have NEW customers. @ @ I'd guess that any scheme that is adopted needs to handle the @ TRANSITION very, very carefully. Disruption of service is a fundamentally @ Bad Thing, as I'd predict you will agree. @ @ So, yes. If no one is using a TLD, who cares. But the instant @ there is even ONE user of a TLD, what is our "social" responsibility to @ ensure continuity of service (i.e., permanence of domain names)? We can @ certainly be cavalier and leave the whole matter to freemarket commercial @ forces, but we can also choose to require continuity. Personally, I would @ wish for the latter, if feasible. @ @ d/ @ Did that kind of thinking go into the US Top Level Domain transitions...? @@@@@@ While many people have been discussing NEW top level domains the delegation of large blocks of city domains across the United States have been quietly made to a few companies that now appear to have a lock on those names, even though the companies may not be in the same state where the city is located. (It is interesting to note that companies in New York "own" many of the cities in New Jersey) The US domain has historically been FREE. Now a few companies are able to charge fees and evidently there is no requirement that a percentage of those fees be sent back to the IANA, ISI, or the University of Southern California where the US domain is managed. This is not much different than the top level domain situation. Many people have claimed that fees and special selection procedures are required to delegate top level domains to registries. People also claim that procedures are needed to protect consumers in case a registry fails. As can be seen in the case of the (now valuable) US top level domain, none of the procedures proposed in the infamous "Draft Postel" were required to commercialize what used to be FREE. There does not seem to be much concern about registries failing, and a first come first serve policy seems to be in place. As can be seen below, the US domain is no longer a special place oriented toward city governments. Without any input from the city governments, their names were given to ISPs that now are establishing commercial registries. One solution to this situation is the creation of the .USA top level domain. More information on top level domains can be found at... http://www.agn.net/USA-DOMAIN.html The precendents are now becoming clear, while some people have been working for many months to come to a consensus on future TLD directions others have been making forward progress. Now the market place will be allowed to decide where all this heads. @@@@@@@@@@@@@@@@@@@@@@@@ ---------- From: US Domain Registration[SMTP:usdomreg@ISI.EDU] Sent: Thursday, November 07, 1996 1:06 PM To: Cc: usdomreg@ISI.EDU Subject: Re: Specific US Domain Name Hi, The locality names in the US part of the domain name system (such as Tacoma.WA.US) are to be used for all types of things in that locality, including businesses, individuals, clubs, and governments. For example, a business like Joe's Market might have the domain name Joes-Mkt.TACOMA.WA.US, or an individual, say Fred Jones, cold have the domain name FHones.Tacoma.WA.US, and the city government could have the domain name ci.Tacoma.WA.US. It is typically not appropriate for the city government to control the domain name management and operation of the nameservers for all the Internet users in that locality. The management and operation of locality domain names are often delegated to Internet service providers (ISPs). These organizations usually have the resources and experience to do this work. Sometimes ISPs are delegated several localities to manage. This has generally worked out well. In the past some of the ISPs were able to provide these domain name management services for free, but this is no longer the case. Most of the ISPs are now charging a small fee for this work (typically $10/yr). The delegation is not changed from one manager to another unless there are significant service problems. US Domain Registry @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ P.S. The figure of $10 above has not been confirmed. $50 seems like a more accurate estimate. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8) -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa10957; 8 Nov 96 2:55 EST Received: from SPECTRUM.RNS.COM by ietf.org id aa10866; 8 Nov 96 2:51 EST Received: from anchor.rns.com by RNS.COM (SMI-8.6/SMI-4.1(Spectrum)) id XAA05096; Thu, 7 Nov 1996 23:42:38 -0800 Received: by anchor.rns.com (SMI-8.6/SMI-SVR4) id XAA03501; Thu, 7 Nov 1996 23:50:34 -0800 To: ietf@ietf.org Path: anchor!not-for-mail Sender:ietf-request@ietf.org From: Lars Poulsen Newsgroups: ietf.misc Subject: Why More TLDs Date: 7 Nov 1996 23:50:32 -0800 Organization: RNS / Meret Communications Lines: 118 Distribution: world Message-ID: <55uoo8$3d2@anchor.rns.com> Source-Info: From (or Sender) name not authenticated. I must confess a certain puzzlement. I see a small but very vocal band of mutineers, fighting the entire establisment of Internet governance, fighting for the right to take over the licensing of top level domains. Yet I have seen no clear enumeration of the problems to be solved, and how the changes would - or possibly could - resolve those problems. Somewhere along the line, the mutineers have decided that we need more TLDs, and the TLDs must be given to competing registries, and those deemed most financially promising to the mutineers should be deemed to have already been licensed to the AlterNIC. I do see some problems with the current scheme, but I don't see that adding more TLDs will conclusively improve on the situation, or that the situation could not be improved by means other than those now proposed. Here are the problems that I see in the current regimen: 1) The root servers are heavily loaded, and lookups often seem to be hampered by congestion. It seems to me that this is a result of too many functions being loaded on the same set of servers, and could be best alleviated by distributing the system more, separating the servers for ROOT, COM, EDU and the rest onto 4 distinct (symmetrically mirrored) server sets. I have never understood why it was considered an advantage to keep SOA for all the TLDs on the root server set. 2) The COM domain is too crowded. The lack of a second-level structure creates a huge, flat namespace which must be hard on the servers' search algorithms. At first blush one would think that adding more TLDs would spread the registrations; I have come to believe that this is not clear at all, and that only one thing can possibly induce a migration away from the .COM namespace: A fee high enough to scare any but the largest users away; my guess is that it would take at least $5000 per name per year to make a dent. (Assuming we can establish a less expensive place for them to go to.) 3) In the absence of a better directory function, DNS+WWW has become our directory. Thus everyone is motivated to register in the obvious place in the namespace: .COM in order to make it simple for customers to find them. Since company names aren't unique, this produces collisions which the registries are ill-equipped to resolve. Multiple TLDs served out of unique registries would not solve this problem, unless there were to be a strong price differentiation. If we open BIZ, INC, TRADE and COMPANY with the same $50/year registration fee, I predict that everyone would rush to duplicate their second-level entries under .COM in EACH of the new domains. This would be worse than the status quo, in that the clients would pay more, the burdens of sorting out conflicts would get multiplied by the number of registries. At the same time, it would be less convenient for users, since any search that failed in .COM would now have to be retried in each of the alternates, before the slower fallback lookup methods (such as WHOIS) would be tried. Furthermore, there is a real risk that large businesses would choose to use the TLD registry function to effectively register themselves in the root rather than in the second level, thus perpetuating the present problems and focusing them in the root, which has got to be the worst possible place to have this congestion. 4) There are anecdotes of clients being denied registration in reasonable parts of the national domains. I am sure that this has happenend, but I have yet to be convinced that it is widespread. Here are some advantages in the current system: 5) It is really simple to navigate. Over 90% of the time, I find the entity I'm looking for in the first try. 6) It provides for choices in where to register: COM, US, ORG. 7) Everyone involved seems to have a friendly, community-service attitude (at least until someone threatens them with lawyers). 8) It works remarkably well. I suspect that after we open up the system, it will never work this well again. Here are some minor steps we could take: 9) Open for industry-specific second level domains under US NETWORKS.US (e.g. CISCO.NETWORKS.US) MOTOR.US (e.g. FORD.MOTOR.US) MOVIES.US (e.g. ID4.MOVIES.US, Texas-Chainsaws.MOVIES.US) AERO.US (e.g. BOEING.AERO.US, MARTIN.AERO.US) AIRLINES.US (e.g. AMERICAN.AIRLINES.US) etc. and encourage other national registries to do the same. This could take a LOT of pressure off COM. 10) License a single alternative TLD named ALT to the group behind AlterNIC to operate as they wish. This would allow them to set up an entire structure with a market orientation under BIZ.ALT INC.ALT MARKET.ALT etc This would have a minimal impact on the core system, while allowing the community to asses the effects of competition. The licenssee should be free to sublicense portions of this namespace according to whatever rules they can agree on between themselves. Under this proposal, an IAHC could later license other TLDs to other groups if the experiment is successful. All of my engineering experience tells me that the way to get to a new structure is by a sequnece of planned, minor adjustments rather than by massive changes all at once. -- / Lars Poulsen Internet E-mail: lars@OSICOM.COM OSICOM Technologies (Internet Business Unit, formerly RNS) 7402 Hollister Avenue Telefax: +1-805-968-8256 Santa Barbara, CA 93117 Telephone: +1-805-562-3158   Received: from ietf.org by ietf.org id aa14215; 8 Nov 96 5:04 EST Received: from dxmint.cern.ch by ietf.org id aa13864; 8 Nov 96 5:00 EST Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id KAA14868; Fri, 8 Nov 1996 10:59:23 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA05282; Fri, 8 Nov 1996 10:59:16 +0100 Message-Id: <9611080959.AA05282@dxcoms.cern.ch> Subject: Re: IAHC To: Karl Denninger Date: Fri, 8 Nov 1996 10:59:16 +0100 (MET) Sender:ietf-request@ietf.org From: Brian Carpenter CERN-CN Cc: HANK@taunivm.tau.ac.il, karl@mcs.net, HANK@vm.biu.ac.il, ietf@ietf.org In-Reply-To: <199611071959.NAA17027@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 7, 96 01:59:58 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. >--------- Text sent by Karl Denninger follows: > ... > > Further, the IAB has not responded to our formal complaint regarding the > IANA attempts to circumvent procedure. If you are referring to a message from Eugene Kashpureff dated September 17, 1996, we replied to it on September 27, 1996. Brian Carpenter   Received: from ietf.org by ietf.org id aa17031; 8 Nov 96 6:34 EST Received: from eunet.EU.net by ietf.org id aa16800; 8 Nov 96 6:30 EST Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id MAA06107; Fri, 8 Nov 1996 12:29:54 +0100 (MET) Received: by jotun.EU.net id AA00921 (5.67a/IDA-1.5); Fri, 8 Nov 1996 12:29:53 +0100 Message-Id: <199611081129.AA00921@jotun.EU.net> Sender:ietf-request@ietf.org From: Per Gregers Bilse Date: Fri, 8 Nov 1996 12:29:52 +0100 In-Reply-To: <01BBCCBD.094F5560@webster.unety.net> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Jim Fleming Subject: Re: The Internet Tree Cc: "ietf@ietf.org" Source-Info: From (or Sender) name not authenticated. On Nov 7, 15:04, Jim Fleming wrote: > @ How does your, Fleming's, et als "process" line up? >[...] > > The process I have proposed is VERY simple. It is For one thing, it sounds like an awfully complicated nightmare to me, but you are in fact completely missing the point. The "process" I am referring to is the feeble-minded attempt by a couple of individuals to invent or hijack non-existent/unregistered namespace and pretend to innocent bystanders that they are authorities on the issue and that their dreams represent the real world. This is completely bogus. And when money changes hands based on this, I believe "fraud" is indeed a correct description. -- ------ ___ --- Per G. Bilse, Mgr Network Operations ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse@EU.net   Received: from ietf.org by ietf.org id aa17773; 8 Nov 96 6:46 EST Received: from eunet.EU.net by ietf.org id aa17543; 8 Nov 96 6:44 EST Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id MAA06409; Fri, 8 Nov 1996 12:43:33 +0100 (MET) Received: by jotun.EU.net id AA00979 (5.67a/IDA-1.5); Fri, 8 Nov 1996 12:43:32 +0100 Message-Id: <199611081143.AA00979@jotun.EU.net> Sender:ietf-request@ietf.org From: Per Gregers Bilse Date: Fri, 8 Nov 1996 12:43:32 +0100 In-Reply-To: <199611071959.NAA17027@Jupiter.Mcs.Net> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Karl Denninger Subject: Re: IAHC Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. On Nov 7, 13:59, Karl Denninger wrote: > Sure. But I won't give you 4 (or more) months. So what are you going to do? Sue somebody, as usual? Can't you just for once lower the adrenalin level and let things fall into place? You didn't seriously believe anybody in the Net would fall for the AlterNIC story, did you? The IAHC will have the full support of all relevant parts of the Net, given that it seems to consist of sober, rational, well-composed individuals with more or less reasonably proven track records wherever they come from. This is what creates authority, Karl; not jumping up and down, bellowing, and foaming at the mouth. -- ------ ___ --- Per G. Bilse, Mgr Network Operations ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse@EU.net   Received: from ietf.org by ietf.org id aa21542; 8 Nov 96 9:13 EST Received: from Kitten.mcs.com by ietf.org id aa21114; 8 Nov 96 9:04 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id IAA14040; Fri, 8 Nov 1996 08:03:02 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id IAA25868; Fri, 8 Nov 1996 08:03:01 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id IAA11211; Fri, 8 Nov 1996 08:03:00 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611081403.IAA11211@Jupiter.Mcs.Net> Subject: Re: The cartel begins to crumble? To: Rens Troost Date: Fri, 8 Nov 1996 08:03:00 -0600 (CST) Cc: karl@mcs.net, HANK@taunivm.tau.ac.il, HANK@vm.biu.ac.il, ietf@ietf.org In-Reply-To: <199611080959.EAA21151@engine.name.net> from "Rens Troost" at Nov 8, 96 04:59:10 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > It would be a *real* bad idea to attempt to do this in many countries -- the > > United States included. > > Incorrect. Most securities firms, for instance, tape all > converstations as a matter of course. The government actually smiles > on this activity, as do the insurance companies. > > -Rens There are laws providing that proper notice must be given to the person calling you when you do that. How likely is someone to admit to a practice they know is a problem on the phone if they KNOW they're being taped. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa21832; 8 Nov 96 9:16 EST Received: from [207.32.128.130] by ietf.org id aa21577; 8 Nov 96 9:14 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id IAA29123; Fri, 8 Nov 1996 08:07:46 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCD4C.3102DB60@webster.unety.net>; Fri, 8 Nov 1996 08:09:40 -0600 Message-ID: <01BBCD4C.3102DB60@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: Multiple recipients of list DOMAIN-POLICY Cc: "'ietf@ietf.org'" , 'New Newdom' , "'simsong@VINEYARD.NET'" Subject: RE: US Top Level Domain Date: Fri, 8 Nov 1996 08:09:39 -0600 Encoding: 28 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 08, 1996 7:20 AM, Simson L. Garfinkel[SMTP:simsong@VINEYARD.NET] wrote: @ US domain used to be a volunteer project. It became a burden for ISI. So they @ farmed it out. People who take up regions are allowed to charge. @ -s @ It is useful to note that this "farming out" was not done with an RFC, no fee guidelines have been set, no IAHC had to be formed, and the net has not collapsed. Are people happy about this ? Only time will tell... Do city governments understand why "their" domain is managed by some company in another state ? No. Will state governments start asking those companies why they are not registered to do business in the states where they control large blocks of US domain names ? Only time will tell... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa22948; 8 Nov 96 9:31 EST Received: from ietf.org by ietf.org id aa22347; 8 Nov 96 9:26 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: namedroppers@internic.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsind-dynDNS-10.txt Date: Fri, 08 Nov 1996 09:26:10 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611080926.aa22347@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS IXFR, Notification, and Dynamic Update Working Group of the IETF. Title : Dynamic Updates in the Domain Name System (DNS UPDATE) Author(s) : P. Vixie, S. Thomson, Y. Rekhter, J. Bound Filename : draft-ietf-dnsind-dynDNS-10.txt Pages : 28 Date : 11/07/1996 The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File. Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. UPDATE is atomic, i.e., all prerequisites must be satisfied or else no update operations will take place. There are no data dependent error conditions defined after the prerequisites have been met. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsind-dynDNS-10.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-dynDNS-10.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnsind-dynDNS-10.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961107111943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsind-dynDNS-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsind-dynDNS-10.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961107111943.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22962; 8 Nov 96 9:31 EST Received: from ietf.org by ietf.org id aa22404; 8 Nov 96 9:26 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-fujikawa-ipsvc-01.txt Date: Fri, 08 Nov 1996 09:26:33 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611080926.aa22404@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Another ATM Signaling Protocol for IP (IP-SVC) Author(s) : K. Fujikawa Filename : draft-fujikawa-ipsvc-01.txt Pages : 13 Date : 11/07/1996 This memo describes IP-SVC that is another ATM signaling protocol for implementing IP protocols. IP-SVC restricts the range of signaling to an IP subnet, and this restriction makes the IP-SVC structure simple. IP-SVC provides easy implementation of the mechanism of ARP and IP multicasting without any servers. IP-SVC can not establish VCs across IP subnet boundaries by itself. However, adapting CSRs (Cell Switching Routers) with RSVP (Resource ReSerVation Protocol) enables end-to-end VC establishment across IP subnet boundaries in IP/ATM LANs based on IP-SVC. This method also shows one solution of RSVP over ATM. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fujikawa-ipsvc-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-fujikawa-ipsvc-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-fujikawa-ipsvc-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961107163254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fujikawa-ipsvc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-fujikawa-ipsvc-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961107163254.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22942; 8 Nov 96 9:31 EST Received: from ietf.org by ietf.org id aa22377; 8 Nov 96 9:26 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wessels-icp-v2-00.txt Date: Fri, 08 Nov 1996 09:26:24 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611080926.aa22377@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Cache Protocol (ICP), version 2 Author(s) : D. Wessels, K. Claffy Filename : draft-wessels-icp-v2-00.txt Pages : 7 Date : 11/07/1996 This draft document describes the Internet Cache Protocol (ICP) currently implemented in a few World-Wide Web proxy cache packages. ICP was initially developed by Peter Danzig, et. al. at the Univerisity of Southern California. It evolved as an important part of hierarchical caching on the Harvest research project. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wessels-icp-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-wessels-icp-v2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-wessels-icp-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961107140512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wessels-icp-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-wessels-icp-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961107140512.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22900; 8 Nov 96 9:31 EST Received: from ietf.org by ietf.org id aa22365; 8 Nov 96 9:26 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stager-pdc-netapp-backup-00.txt Date: Fri, 08 Nov 1996 09:26:18 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611080926.aa22365@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Data Management Protocol Author(s) : R. Stager, D. Hitz Filename : draft-stager-pdc-netapp-backup-00.txt Pages : 75 Date : 11/07/1996 The Network Data Management Protocol (NDMP) addresses the user's need for centralized control of enterprise-wide network data management while minimizing network traffic. The design objective of the protocol is to make every network attached storage device "backup ready", enabling true plug-and-play backup operation. The user will not be required to install any additional software on an NDMP-compliant network storage device. With the NDMP approach, each network-attached file server ships with a "universal agent," which can be used by any NDMP-compliant backup administration application. For IS departments and system administrators, NDMP will ensure interoperability between different file servers and backup solutions, significantly simplifying the data management process. This same universal agent architecture is also for network-attached backup devices, such as a tape libraries. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stager-pdc-netapp-backup-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-stager-pdc-netapp-backup-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-stager-pdc-netapp-backup-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961107115709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stager-pdc-netapp-backup-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-stager-pdc-netapp-backup-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961107115709.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23764; 8 Nov 96 9:37 EST Received: from cnri by ietf.org id aa23531; 8 Nov 96 9:34 EST Received: from wilbur.nas.nasa.gov by CNRI.Reston.VA.US id aa11254; 8 Nov 96 9:34 EST Received: (from lekash@localhost) by wilbur.nas.nasa.gov (8.7.6/NAS.6.1) id GAA09703; Fri, 8 Nov 1996 06:32:56 -0800 (PST) Date: Fri, 8 Nov 1996 06:32:56 -0800 (PST) Sender:ietf-request@ietf.org From: John Lekashman Message-Id: <199611081432.GAA09703@wilbur.nas.nasa.gov> To: JimFleming@unety.net, sthaug@nethelp.no CC: ietf@CNRI.Reston.VA.US, newdom@vrx.net, lekash@nas.nasa.gov In-reply-to: <01BBC802.B4CACCE0@webster.unety.net> (message from Jim Fleming on Fri, 1 Nov 1996 14:41:01 -0600) Subject: NASA name servers, various comments regarding function. Source-Info: From (or Sender) name not authenticated. I noted that various comments were made regarding alleging problems with reachability, functionality, Government funding, et al, with regard to the current NASA root name server. NASA has programmatic requirements that lead it to develop major parts of Internet infrastructure in the distant past, and to continue to be well connected and a part of that infrastructure. It is actually a fairly trivial economic decision to spend some small amount of $ on things such as root servers, rather than a much larger amount to provision private systems. So, I made that particular decision some 10 years ago, when I first set up said root server. Yes, things have changed. Yes, I gave it all to Milo to run, some five or six years ago, because he did it very well, and I had other things to go build. Yes, there have been many personnel changes at NASA in the interim. If there are now operational problems with the facilities, I would like actual explicit details of actual problems with these, or other such NASA Internet facilities. I am prepared to do something about it, if there are any substantive issues. Useful statements, such as noting under-capacity servers or links, noted extended downtime, corrupted or out of date caching, congestion choke-points in the infrastructure, or any other real issues will be addressed. I do not, however, promise that your overloaded T1 will be upgraded. Innuendo, noting that some random site could not ping the server, or other such statements, are not very useful. Questions regarding the political rightness or wrongness of the US Government using or deploying a facility, or other forms of self-aggrandizement will be ignored. Send those to your Congressman or other favorite elected official, please. Thank you, john remember. simple is really, really hard. lekash@nas.nasa.gov   Received: from ietf.org by ietf.org id aa25296; 8 Nov 96 9:57 EST Received: from dns1.noc.best.net by ietf.org id aa24764; 8 Nov 96 9:53 EST Received: from bovik.vip.best.com (bovik.vip.best.com [205.149.161.94]) by dns1.noc.best.net (8.8.2/8.7.3) with SMTP id GAA01059 for ; Fri, 8 Nov 1996 06:52:37 -0800 (PST) Message-Id: <199611081452.GAA01059@dns1.noc.best.net> Date: Fri, 08 Nov 96 06:53:00 -0800 Sender:ietf-request@ietf.org From: James Salsman Organization: Bovik Research X-Mailer: Mozilla 1.22 (Windows; I; 16bit) MIME-Version: 1.0 Newsgroups: comp.speech To: ietf@ietf.org Subject: Re: IETF speech coding for email? References: <328332D4.4AD0@sprynet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Source-Info: From (or Sender) name not authenticated. Dan Robinson wrote: > > The IETF is looking at sending coded speech via email. > Does anyone know what algorithm they are planning to use? Dear IETF: Please do not use Linear Predictive Coding. Linear Predictive Coding has been shown many times to be microphone-dependent, which is to say that identical speech sampled with different microphones produces highly divergent Linear Predictive Codes. Linear Predictive Coding may be a remnant of legal threats made my the government against independant inventors who have from time to time developed very effective speech coding schemes which happened to be used in sensitive cockpit applications and as such would have provided hostile forces with the means for identifying the plain text of sensitive transmissions. Please use a coding which is likely to allow for the seperation of phonemic units by flat hyperplanes in the space defined by the code vector. I believe the most suitable candidate for use is an overlapping window of cepstral codes, as defined by Cooley and Tukey in 1963 as the forward Fourier transform of the log magnitude spectrum. The IETF should also consider providing a code which emphasises the frequencies of the range of human vocal tracts. My personal opinion is that the IETF should also consider a coding which seperatly encodes the harmonics of the spoken sound. For additional information on this topic, please see the one-page dataflow diagram in ftp://ftp.best.com/pub/bovik/coder.ps Sincerely, :James Salsman Disclaimer: these are my views and I have shared these views with my employers. Now that I have an employer capable of understanding these views (for which I am quite thankful), they agree as far as I know.   Received: from ietf.org by ietf.org id aa27785; 8 Nov 96 10:18 EST Received: from mikado.name.net by ietf.org id aa27545; 8 Nov 96 10:13 EST Received: from engine.name.net (engine.name.net [204.50.44.14]) by name.net (8.7.6/8.6.12) with ESMTP id KAA19956; Fri, 8 Nov 1996 10:12:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by engine.name.net (8.7.6/8.6.12) with SMTP id KAA22282; Fri, 8 Nov 1996 10:12:34 -0500 (EST) Message-Id: <199611081512.KAA22282@engine.name.net> X-Authentication-Warning: engine.name.net: Host localhost [127.0.0.1] didn't use HELO protocol To: Karl Denninger cc: Rens Troost , HANK@taunivm.tau.ac.il, HANK@vm.biu.ac.il, ietf@ietf.org Subject: Re: The cartel begins to crumble? X-Jothi: Mail Not From Jothi. Jothi's permission not required for distribution. In-reply-to: Your message of "Fri, 08 Nov 1996 08:03:00 CST." <199611081403.IAA11211@Jupiter.Mcs.Net> Date: Fri, 08 Nov 1996 10:12:33 -0500 Sender:ietf-request@ietf.org From: James Wetterau Source-Info: From (or Sender) name not authenticated. Karl Denninger says: > > > It would be a *real* bad idea to attempt to do this in many countries -- the > > > United States included. > > > > Incorrect. Most securities firms, for instance, tape all > > converstations as a matter of course. The government actually smiles > > on this activity, as do the insurance companies. > > > > -Rens > > There are laws providing that proper notice must be given to the person > calling you when you do that. > > How likely is someone to admit to a practice they know is a problem on the > phone if they KNOW they're being taped. The laws vary from state to state. I believe that all of the following have been tried somewhere in the U.S., at some time: o you must give advance notice o you must merely beep every n seconds, to implicitly notify the other person o you must do both of the above o you may freely, clandestinely tape I believe that in New York state the last is now the law, but I am not a lawyer. Consult a lawyer before taping. -- James Wetterau jwjr@name.net   Received: from ietf.org by ietf.org id aa28352; 8 Nov 96 10:26 EST Received: from jekyll.piermont.com by ietf.org id aa28194; 8 Nov 96 10:23 EST Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id KAA27396; Fri, 8 Nov 1996 10:21:11 -0500 (EST) Message-Id: <199611081521.KAA27396@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol To: Jim Fleming cc: 'Hank Nussbacher' , "ietf@ietf.org" , 'New Newdom' Subject: Re: More iTLD thread In-reply-to: Your message of "Thu, 07 Nov 1996 13:57:35 CST." <01BBCCB3.A20269A0@webster.unety.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 08 Nov 1996 10:21:05 -0500 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Jim Fleming writes: > I do not think that you 4 months. Have you read Paul Vixie's > postion statement giving you a January 15, 1997 deadline > before he goes "ballistic" (whatever Paul means by that). I've spoken to Paul. He understands the situation. Feel free to continue spreading rumors if you wish, however. Perry   Received: from ietf.org by ietf.org id aa01062; 8 Nov 96 11:05 EST Received: from jekyll.piermont.com by ietf.org id aa00832; 8 Nov 96 11:01 EST Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id KAA27488; Fri, 8 Nov 1996 10:59:05 -0500 (EST) Message-Id: <199611081559.KAA27488@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol To: Karl Denninger cc: Hank Nussbacher , HANK@vm.biu.ac.il, ietf@ietf.org Subject: Re: The cartel begins to crumble? In-reply-to: Your message of "Thu, 07 Nov 1996 14:04:54 CST." <199611072004.OAA17158@Jupiter.Mcs.Net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 08 Nov 1996 10:59:05 -0500 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Karl Denninger writes: > > In one case, a customer taped his phone conversation with the company > > trying to sell the DN. > > Try that in the US and you may run afoul of CRIMINAL statutes, depending on > the state you're calling from and to. In most of the U.S., its perfectly legal to tape a conversation you are a party to. In a couple of exceptional states, it isn't. Perry   Received: from ietf.org by ietf.org id aa03535; 8 Nov 96 11:27 EST Received: from jekyll.piermont.com by ietf.org id aa03052; 8 Nov 96 11:22 EST Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id LAA27522; Fri, 8 Nov 1996 11:20:01 -0500 (EST) Message-Id: <199611081620.LAA27522@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol To: Jim Fleming cc: "ietf@ietf.org" , 'New Newdom' Subject: Re: More iTLD thread In-reply-to: Your message of "Thu, 07 Nov 1996 15:36:45 CST." <01BBCCC1.7C657940@webster.unety.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 08 Nov 1996 11:20:01 -0500 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Jim Fleming writes: > Why haven't the discussions with "Paul" been in > an open forum...? Jim; I will call Paul Vixie up any time I like and discuss anything I like with him. I am under no obligation, now or ever, to inform you before I call him, to inform you if I call him, or to inform you of why I called him or the contents of the call if I choose to mention in public that I spoke with him at all. Perry   Received: from ietf.org by ietf.org id aa09967; 8 Nov 96 13:32 EST Received: from Kitten.mcs.com by ietf.org id aa09843; 8 Nov 96 13:28 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id MAA28265; Fri, 8 Nov 1996 12:27:28 -0600 (CST) Received: from Mars.mcs.net (karl@Mars.mcs.com [192.160.127.85]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id MAA14844; Fri, 8 Nov 1996 12:27:19 -0600 (CST) Received: (from karl@localhost) by Mars.mcs.net (8.8.2/8.8.2) id MAA22241; Fri, 8 Nov 1996 12:27:14 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611081827.MAA22241@Mars.mcs.net> Subject: Re: The cartel begins to crumble? To: Dave Crocker Date: Fri, 8 Nov 1996 12:27:13 -0600 (CST) Cc: karl@mcs.net, ietf@ietf.org In-Reply-To: from "Dave Crocker" at Nov 7, 96 02:53:28 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > At 8:19 AM -0800 11/7/96, Karl Denninger wrote: > >If a TLD is desirable, it will have NEW customers. > > I'd guess that any scheme that is adopted needs to handle the > TRANSITION very, very carefully. Disruption of service is a fundamentally > Bad Thing, as I'd predict you will agree. Yes it is. However, I do not believe it is a proper function of the Internet "infrastructure" to provide what amounts to insurance. I *do* support an escrow arrangement for the *current* configuration of the zone (since its public anyway, there are no issues). Likewise, there are no significant issues with pointing the NS lines in the root nameservers on a *temporary* basis to an escrowing agent if a registry "dies" -- until things are sorted out. However, any attempt to prevent and money with the normal asset disposal process of a bankrupt registry is going to run afoul of at least US (and probably most other national) laws. There is no point in trying to do this. The courts won't permit it anyway, and if you represent that you *can* usurp their authority you just create a cause of action for the registrants against the ISOC and related organizations! Why would you want to do THAT? > So, yes. If no one is using a TLD, who cares. But the instant > there is even ONE user of a TLD, what is our "social" responsibility to > ensure continuity of service (i.e., permanence of domain names)? We can > certainly be cavalier and leave the whole matter to freemarket commercial > forces, but we can also choose to require continuity. Personally, I would > wish for the latter, if feasible. > -------------------- > Dave Crocker +1 408 246 8253 You can't *require* continuity. You can take steps to attempt to prevent interruption of service *during the period that a registry is offline, up to but not beyond the point at which a court makes a disposal of that asset (the registry and its customers)*. The first is trival to do. The second (ie: trying to force successors to honor agreements with a firm that no longer exists) is contrary to public policy and law, and won't stand. The first rule that I believe these "committees" need to understand is this: Don't try to act like a tribunal. Do not attempt to set policy which has the effect of contravening the authority of real judicial systems. You *will* get in trouble down the road if you do this from BOTH sides of the disputes which subsequently arise, and you are just creating causes of civil action out of whole cloth! -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa10034; 8 Nov 96 13:34 EST Received: from Kitten.mcs.com by ietf.org id aa09932; 8 Nov 96 13:31 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id MAA28362; Fri, 8 Nov 1996 12:30:34 -0600 (CST) Received: from Mars.mcs.net (karl@Mars.mcs.com [192.160.127.85]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id MAA15582; Fri, 8 Nov 1996 12:30:30 -0600 (CST) Received: (from karl@localhost) by Mars.mcs.net (8.8.2/8.8.2) id MAA22372; Fri, 8 Nov 1996 12:30:29 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611081830.MAA22372@Mars.mcs.net> Subject: Re: IAHC To: Per Gregers Bilse Date: Fri, 8 Nov 1996 12:30:28 -0600 (CST) Cc: karl@mcs.net, ietf@ietf.org In-Reply-To: <199611081143.AA00979@jotun.EU.net> from "Per Gregers Bilse" at Nov 8, 96 12:43:32 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > On Nov 7, 13:59, Karl Denninger wrote: > > Sure. But I won't give you 4 (or more) months. > > So what are you going to do? Sue somebody, as usual? If someone (including the IAHC) does something which creates a cause of action, why wouldn't I? Or are we (and the rest of the Internet community) just supposed to "take it on the chin" and enjoy it? I think not. > Can't you just for once lower the adrenalin level and let things fall > into place? You didn't seriously believe anybody in the Net would > fall for the AlterNIC story, did you? On the contrary. Many people are supporting the eDNS environment. > The IAHC will have the full support of all relevant parts of the Net, > given that it seems to consist of sober, rational, well-composed > individuals with more or less reasonably proven track records > wherever they come from. On the contrary. There is no evidence to support this assertion *AT THIS TIME*. The actions of that group will determine the response. >This is what creates authority, Karl; not > jumping up and down, bellowing, and foaming at the mouth. And people wonder why they end up in kill files.... ad-hominen attacks top the list of causes. > ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. Thank you very much for yet another organization that needs no cooperation from me. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa10641; 8 Nov 96 13:42 EST Received: from cnri by ietf.org id aa10313; 8 Nov 96 13:39 EST Received: from hera.rbi.informatik.uni-frankfurt.de by CNRI.Reston.VA.US id aa17641; 8 Nov 96 13:39 EST Received: from dbis.informatik.uni-frankfurt.de (roma.dbis.informatik.uni-frankfurt.de) by hera.rbi.informatik.uni-frankfurt.de with SMTP (1.40.112.4/16.2) id AA060217630; Fri, 8 Nov 1996 19:27:10 +0100 Received: from atlas.rbi.informatik.uni-frankfurt.de by dbis.informatik.uni-frankfurt.de with smtp (Smail3.1.28.1 #4) id m0vLvdw-000BmsC; Fri, 8 Nov 96 19:27 MET Received: by atlas.rbi.informatik.uni-frankfurt.de (1.39.111.2/16.2) id AA007308782; Fri, 8 Nov 1996 19:46:22 +0100 Sender:ietf-request@ietf.org From: zicari@informatik.uni-frankfurt.de Posted-Date: Fri, 8 Nov 1996 19:46:22 +0100 Received-Date: Fri, 8 Nov 1996 19:46:22 +0100 Message-Id: <199611081846.AA007308782@atlas.rbi.informatik.uni-frankfurt.de> Subject: owf release To: int.multimedia@dbis.informatik.uni-frankfurt.de Date: Fri, 8 Nov 1996 19:46:22 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 5390 Source-Info: From (or Sender) name not authenticated. FYI. Regards Roberto Zicari OWF Chair ------------------------------------------------------- Press Release Object World Frankfurt is now 60% larger than last year Frankfurt -- October 15, 1996. A Rapidly Growing Show: The conferences and exhibits Object World Frankfurt and Internet Forum Europe, held October 9-11, 1996 at the Sheraton Conference Center (Airport) in Frankfurt/Main, continue to grow. With 78 exhibitors (1995: 50), 2,000 sqm exhibition (1995: 1,200), 2,800 visitors (1995: 1,800), and 780 conference delegates (1995: 650), the show grew overall of a whopping 60 percent with respect to last year. The business aspects of object technology and the Internet was the main theme of the two conferences Object World Frankfurt - now in its fifth year- and Internet Forum Europe - premiere event this year - , and of the combined exhibits. For the two conferences, over 150 speakers from all over the world came to Frankfurt/Main from October 9 to 11, to address issues such as "The Business value of the Internet", and "The Real Benefits of Objects in Business". International Conferences: 40% of the conference delegates came this year from several European countries ranging from the Netherlands, Switzerland to Sweden. The rest of the delegates came from Germany, with the notably exception of a delegation of participants from the Japan Education Service Corporation in Tokyo. "We are particularly happy with this result: The high number of international conference delegates, and the fact that the European Commission has chosen Object World Frankfurt and Internet Forum Europe to present their activities on the Internet, is a confirmation of the importance of this event in Europe", says Prof. Roberto Zicari, Object World Frankfurt and Internet Forum Europe Program Chair. The European Commission presented at Internet Forum Europe two tracks on Electronic Commerce, the G7 Initiative for a Global Marketplace for SMEs, and Web for schools. The combined exhibition on object technology and Internet on October 10 and 11, included leading companies such as Deutsche Telekom, Digital Equipment, Hewlett-Packard, IBM, Informix Software, NeXT Computer, Siemens Nixdorf, Software AG, SunSoft, and Sybase. "Combining object technology and the Internet in one single exhibition has proven to be a successful formula" , says Christiane Sattler, show manager at LogOn Technology Transfer GmbH, "We will definitely repeat it next year as well". Show Highlight: The Object Application Awards One of the highlights of the show was in the evening of October 10, the Third Object Applications Ceremony. Dr. Hartmut Schwesinger, Chief Executive Officer, Business and Economic Development Corp. City of Frankfurt, welcomed the over 400 attendees to the ceremony, together with Christopher Stone, President and CEO of the Object Management Group, who was the Master of Ceremony. Five Awards for the best applications using object technology were given to: ABB (Germany), debis Systemhaus GmbH (Germany), Deutsche Bahn AG (Germany), Motorola (US) and Sabre Decision Technologies (US). The awards jury was chaired by Prof. Roberto Zicari, University of Frankfurt and LogOn and included Prof. Gerhard Barth (Daimler Benz), Prof. Ulrich Eisenecker (FH Heidelberg), Dr. Ralf Jungclaus (Deutsche Telekom), Prof. Dr. Klaus Kuspert (University of Jena), Dr. Thomas Neumann (SMS), Hauke Peyn (Bertelsmann), Prof. Radu Popescu-Zeletin (GMD FOKUS), Michael Wagner (Free Journalist). Dates for the 1997 show: Internet Forum Europe and Object World Frankfurt will return to Frankfurt/Main next year on October 7-10, 1997 (Sheraton Airport Conference Center). OWF and IFE are sponsored and organized by Object World Corp. (a Softbank COMDEX company) Object Management Group (OMG) and LogOn technology Transfer GmbH. Press contact: LogOn Technology Transfer GmbH Birgit Osterholt, Annegret Claushues Burgweg 14 D-61476 Kronberg / Ts. Germany phone: +49-61 73 - 2852 fax: +49-61 73 - 94 04 20 e-mail: 101510.3135@compuserve.com (Birgit Osterholt) Object World Corp. Object World Corporation, a Softbank COMDEX company, owns and produces Object World conferences and expositions. Object World is the world's largest leading object technology event series focusing exclusively on the commercial and practical applications of object technology and distributed object computing. Object World is held annually in Boston, San Jose, London, Frankfurt, Tokyo and Sydney. LogOn LogOn Technology Transfer GmbH, founded in 1991, is a privately owned company exclusively focused on the Internet and object technology market. LogOn helps European companies to exploit the Internet and object technology (OT) for their business needs and provides a comprehensive set of services. LogOn is organized into five operating divisions: Trade Shows Division, Marketing Division, PR Division, Training Division, Business Division. LogOn is the official representative of the Object Management Group (OMG) for Austria, Benelux, France, Germany, Italy and Switzerland. OMG is the largest software consortium worldwide with more than 600 members companies dedicated to promoting the theory and practice of object technology (OT) for the development of distributed computing systems. World Wide Web: http://www.ltt.de ## 2   Received: from ietf.org by ietf.org id aa17089; 8 Nov 96 16:29 EST Received: from presence.lglobal.com by ietf.org id aa16910; 8 Nov 96 16:23 EST Received: from [207.107.12.71] (voyager6.lglobal.com [207.107.12.71]) by presence.lglobal.com (8.6.12/8.6.12) with SMTP id QAA09988; Fri, 8 Nov 1996 16:32:49 -0500 X-Sender: allisat@mail.lglobal.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Nov 1996 16:26:43 -0500 To: perry@piermont.com Sender:ietf-request@ietf.org From: Bob Allisat Subject: Re: More iTLD thread Cc: Jim Fleming , 'Hank Nussbacher' , "ietf@ietf.org" , 'New Newdom' Source-Info: From (or Sender) name not authenticated. Perry E. Metzger wrote: >I've spoken to Paul. He understands the situation. > >Feel free to continue spreading rumors if you wish, however. And, Perry, you can continue to spread disharmony, venom and a slanted view of the whole matter. As you always have. Same bitter Metzger. Quote> No, but there could be a perception that you picked the Quote> most rabid, stubborn, uncooperative IANA apologist that Quote> could be found on this earth. In my Humble opinion you're the best thing to happen to the IAHC... you are sure to destroy it's credibility faster than anyone I know. Except, perhaps, me... Internationally Yours, Bob Allisat tor@wtv.net Director, (416) 588-0670 World Televirtual Network http://www.wtv.net PO Box 191 Station E Toronto Ontario Canada M6H 4E2   Received: from ietf.org by ietf.org id aa17699; 8 Nov 96 16:39 EST Received: from capone.ch.apollo.hp.com by ietf.org id aa17550; 8 Nov 96 16:36 EST Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Fri, 8 Nov 1996 16:34:50 -0500 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id QAA01133; Fri, 8 Nov 1996 16:34:47 -0500 (EST) Message-Id: <199611082134.QAA01133@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Leonid Egoshin Cc: ietf@ietf.org, lars@anchor.rns.com Subject: Re: Why More TLDs In-Reply-To: egoshin's message of Fri, 08 Nov 1996 13:22:35 -0800. <199611082122.NAA06282@giant.genesyslab.com> Date: Fri, 08 Nov 1996 16:34:39 -0500 Sender:ietf-request@ietf.org From: Bill Sommerfeld Source-Info: From (or Sender) name not authenticated. > Yes, but the namespace of _trademarks_ is unique. Of course in the > area of corresponding laws. And it is possible to create hierarhy .TM > which would match "hierarhy" of trademarks laws. Nope. .TM would be, or is, Turkmenistan's top level domain. Still waiting for someone to register toys.ar.us, - Bill   Received: from ietf.org by ietf.org id aa17964; 8 Nov 96 16:45 EST Received: from eunet.EU.net by ietf.org id aa17812; 8 Nov 96 16:42 EST Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id WAA23017; Fri, 8 Nov 1996 22:41:33 +0100 (MET) Received: by jotun.EU.net id AA02743 (5.67a/IDA-1.5); Fri, 8 Nov 1996 22:41:33 +0100 Message-Id: <199611082141.AA02743@jotun.EU.net> Sender:ietf-request@ietf.org From: Per Gregers Bilse Date: Fri, 8 Nov 1996 22:41:32 +0100 In-Reply-To: <199611081830.MAA22372@Mars.mcs.net> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Karl Denninger Subject: Re: IAHC Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. On Nov 8, 12:30, Karl Denninger wrote: > > > Sure. But I won't give you 4 (or more) months. > > > > So what are you going to do? Sue somebody, as usual? > > If someone (including the IAHC) does something which creates a cause of > action, why wouldn't I? And taking a little time to evaluate proposals creates a cause of action? If people don't do as you say, they're wrong? > Or are we (and the rest of the Internet community) just supposed to "take it > on the chin" and enjoy it? I think not. Take what? Are you saying damage is incurred by having people evaluate and implement something sustainable, instead of just doing what you say? > >This is what creates authority, Karl; not > > jumping up and down, bellowing, and foaming at the mouth. > > And people wonder why they end up in kill files.... ad-hominen attacks top > the list of causes. An ad hominem attack is one where a person's character is attacked. I did not attack your character, I said your style is counter-productive. -- ------ ___ --- Per G. Bilse, Mgr Network Operations ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse@EU.net   Received: from ietf.org by ietf.org id aa18313; 8 Nov 96 16:49 EST Received: from cnri by ietf.org id aa18063; 8 Nov 96 16:46 EST Received: from hail.ncr.disa.mil by CNRI.Reston.VA.US id aa22668; 8 Nov 96 16:46 EST Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id MAA05936 for ; Fri, 8 Nov 1996 12:37:52 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA847485969; Fri, 08 Nov 96 12:18:13 EST Date: Fri, 08 Nov 96 12:18:13 EST Sender:ietf-request@ietf.org From: "C.Joe Pasquariello" Message-Id: <9610088474.AA847485969@ncr.disa.mil> To: IETF@CNRI.Reston.VA.US Subject: Three Cheers for Jake Feinler !! Source-Info: From (or Sender) name not authenticated. There is worthy food for thought, I believe, in the comments of Jake Feinler below! THANX Jake for taking the time to provide a very cogent and statesmanlike perspective on what the IETF is all about! C.Joe Pasquariello US/DoD/DISA [remote, ccMobile, NYC, 08 Nov 96/1207] ______________________________ Forward Header __________________________________ Subject: Re: The cartel begins to crumble? Author: Jake Feinler at smtp Date: 11/6/96 7:12 PM Having been the originator of the idea of .com, .edu, .gov, .mil, etc I have been watching this discussion with some amusement. I can only say to those whose first language is not English that you are not alone in feeling some trepidation. I feel great sympathy for ** ANY** speakers who are willing to step up to the microphone in IETF meetings, especially if the topic is naming and addressing! That is not an exercise for the faint of heart. In the heat of battle and the exchange of ideas, it behooves us all to remember that we are engaged in an international discussion among peers and be a little kinder and gentler with each other. As this discussion is pointing out, what is satire in one background can be insult in another. Also I might point out that the naming system has held up reasonably well over several years because of the many ideas and heated discussions that led to a workable consensus. My suggestion would be to continue this process of evolution of the naming system until better solutions are found, and go easy on flames and bashing. IETF is not perfect in its approach to problem solving, but hey, it's held up as a viable open technical forum for more than 20 years (thanks to the dedication of many) and has produced the phenomenon of the Internet, so has to be doing something right. If you have good ideas get them in there...global feedback and concensus are what have made the Internet great...it's a chaotic democracy not a cartel conspiracy. Signed, Tattered but still unfurled Jake Feinler P.S. These are my own musings and do not represent any organizations with which I am now or have been affiliated. ==================================================================   Received: from ietf.org by ietf.org id aa20855; 8 Nov 96 17:15 EST Received: from black-ice.cc.vt.edu by ietf.org id aa20419; 8 Nov 96 17:12 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id RAA15624; Fri, 8 Nov 1996 17:11:24 -0500 Message-Id: <199611082211.RAA15624@black-ice.cc.vt.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: Leonid Egoshin Cc: ietf@ietf.org Subject: Re: Why More TLDs In-Reply-To: Your message of "Fri, 08 Nov 1996 13:22:35 PST." <199611082122.NAA06282@giant.genesyslab.com> Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <199611082122.NAA06282@giant.genesyslab.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_432571060P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 08 Nov 1996 17:11:24 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_432571060P Content-Type: text/plain; charset=us-ascii On Fri, 08 Nov 1996 13:22:35 PST, you said: > Yes, but the namespace of _trademarks_ is unique. Of course in the > area of corresponding laws. And it is possible to create hierarhy .TM > which would match "hierarhy" of trademarks laws. And we can register > company under name if its trademarks. This doesn't *really* address the issue of multinational companies. What happens when XYZ Inc of the US and XYZ France, which are 2 seperate businesses that own their trademarks in their respective contries, both go multi-national? It would be considered Really Bad if user expectations said "Well, XYZ is trademarked, but XYZ.TM takes me to the wrong company".... OK.. you want to make it 'trademark-here.country.tm'? Pop Quiz - in what country is Honeywell-Bull's trademark held? I know Bull is a French company, but Honeywell is US-based, so where do I look, under .US.TM, or .FR.TM? I'll defer the question of whether "IBM World Trade" (IBM's worldwide operations) is actually trademarked in every country that IBM does business, or whether it's trademarked in every country that can *access* IBM World Trade computers via the Internet. This is just *asking* for trouble, if you are a user in some recently-founded Balkanize-Europe or African contry, where IBM does not do business, is not trademarked, but you wish to reach it anyhow.... -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_432571060P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMoOwCtQBOOoptg9JAQFH+QP/aoAlAqi6DWtf7z7B3rVkuFycDFkiZWdu GuwdWU0E7IAsHq6ca5U35I5+j+0xBowWevCAd55yPb4uXH7OU43c1GI1q+7lalyg //DS9I9ewSMtJAVuWi4iIllh9wWnGviIvoMTxF82L2m8mLKW5kp/opPHDmE6AOm4 gsNrFOwWuZU= =zrv+ -----END PGP MESSAGE----- --==_Exmh_432571060P--   Received: from ietf.org by ietf.org id aa23976; 8 Nov 96 17:46 EST Received: from nirvana.genesyslab.com by ietf.org id aa23710; 8 Nov 96 17:44 EST Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id OAA11589; Fri, 8 Nov 1996 14:44:16 -0800 (PST) Received: (from egoshin@localhost) by giant.genesyslab.com (8.7.5/8.7.3) id OAA07907; Fri, 8 Nov 1996 14:43:46 -0800 (PST) Date: Fri, 8 Nov 1996 14:43:46 -0800 (PST) Sender:ietf-request@ietf.org From: Leonid Egoshin Message-Id: <199611082243.OAA07907@giant.genesyslab.com> To: Valdis.Kletnieks@vt.edu Subject: Re: Why More TLDs Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. >From: Valdis.Kletnieks@vt.edu > >On Fri, 08 Nov 1996 13:22:35 PST, you said: >> Yes, but the namespace of _trademarks_ is unique. Of course in the >> area of corresponding laws. And it is possible to create hierarhy .TM >> which would match "hierarhy" of trademarks laws. And we can register >> company under name if its trademarks. > >This doesn't *really* address the issue of multinational companies. >What happens when XYZ Inc of the US and XYZ France, which are 2 >seperate businesses that own their trademarks in their respective >contries, both go multi-national? It would be considered Really Bad >if user expectations said "Well, XYZ is trademarked, but XYZ.TM takes >me to the wrong company".... > Any multinational corparation must run in the national law. And register trademark in all countries. If it want, of course. If not - I have doubts that it is serious business. >OK.. you want to make it 'trademark-here.country.tm'? Pop Quiz - in >what country is Honeywell-Bull's trademark held? I know Bull is a >French company, but Honeywell is US-based, so where do I look, under >.US.TM, or .FR.TM? > Look at trademark lists - may be this name absent in both countries :-) And may be IS in both lists (I think so). In this case it would be two names: Honeywell-Bull.US.TM and Honeywell-Bull.FR.TM pointed to the same company. Or pointed to different sets of hosts. I think it is more preferable for most of companies - to point to regional division: look at fr.oracle.com and us.oracle.com for exam. At least it is definitely used for mail exchange. - Leonid Yegoshin, LY22   Received: from ietf.org by ietf.org id aa24486; 8 Nov 96 17:52 EST Received: from nirvana.genesyslab.com by ietf.org id aa24184; 8 Nov 96 17:51 EST Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id OAA11640; Fri, 8 Nov 1996 14:47:23 -0800 (PST) Received: (from egoshin@localhost) by giant.genesyslab.com (8.7.5/8.7.3) id OAA07987; Fri, 8 Nov 1996 14:46:52 -0800 (PST) Date: Fri, 8 Nov 1996 14:46:52 -0800 (PST) Sender:ietf-request@ietf.org From: Leonid Egoshin Message-Id: <199611082246.OAA07987@giant.genesyslab.com> To: sommerfeld@apollo.hp.com Subject: Re: Why More TLDs Cc: ietf@ietf.org, lars@anchor.rns.com Source-Info: From (or Sender) name not authenticated. >From: Bill Sommerfeld > >> Yes, but the namespace of _trademarks_ is unique. Of course in the >> area of corresponding laws. And it is possible to create hierarhy .TM >> which would match "hierarhy" of trademarks laws. > >Nope. .TM would be, or is, Turkmenistan's top level domain. > Ok, let it be .C (Copyright, of course :-) - Leonid Yegoshin, LY22   Received: from ietf.org by ietf.org id aa24851; 8 Nov 96 17:56 EST Received: from zephyr.isi.edu by ietf.org id aa24084; 8 Nov 96 17:49 EST Received: from pog.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 8 Nov 1996 14:48:43 -0800 Message-Id: <199611082248.AA20896@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2057 on Source Directed Access Control Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 08 Nov 96 14:51:36 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2057: Title: Source Directed Access Control on the Internet Author: S. Bradner Date: November 1996 Mailbox: sob@harvard.edu Pages: 20 Characters: 56,664 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2057.txt This memo was developed from a deposition that Scott Bradner submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This document may be useful where descriptions of the way the Internet and its applications work could help clear up confusion in the technical feasibility of proposed content control regulations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961108144252.RFC@ISI.EDU> SEND /rfc/rfc2057.txt --OtherAccess Content-Type: Message/External-body; name="rfc2057.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961108144252.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa25986; 8 Nov 96 18:12 EST Received: from SPECTRUM.RNS.COM by ietf.org id aa25878; 8 Nov 96 18:10 EST Received: from anchor.rns.com by RNS.COM (SMI-8.6/SMI-4.1(Spectrum)) id PAA07855; Fri, 8 Nov 1996 15:01:40 -0800 Received: by anchor.rns.com (SMI-8.6/SMI-SVR4) id PAA27889; Fri, 8 Nov 1996 15:09:44 -0800 To: ietf@ietf.org Path: anchor!not-for-mail Sender:ietf-request@ietf.org From: Lars Poulsen Newsgroups: ietf.misc Subject: Re: US Top Level Domain Date: 8 Nov 1996 15:09:43 -0800 Organization: RNS / Meret Communications Lines: 67 Message-ID: <560ejn$r79@anchor.rns.com> References: <01BBCD4C.3102DB60@webster.unety.net> Source-Info: From (or Sender) name not authenticated. On Friday, November 08, 1996 7:20 AM, Simson L. Garfinkel[SMTP:simsong@VINEYARD.NET] wrote: >@ US domain used to be a volunteer project. It became a burden for ISI. So they >@ farmed it out. People who take up regions are allowed to charge. In article <01BBCD4C.3102DB60@webster.unety.net> JimFleming@unety.net (Jim Fleming) writes: >It is useful to note that this "farming out" was not done with >an RFC, no fee guidelines have been set, no IAHC had to be >formed, and the net has not collapsed. While one could wish that the RFCs documenting the operation of the US domain had been updated when the procedures changed, the transition appears to have gone remarkably well. There have been no wholesale complaints of - lack of access - unreasonable fees - contention for address space that I am aware of, other than the allegations from the "AlterNIC mutineers" for which I have not seen specific examples to back them up. I attribute this success to someone having had extremely good judgement in selecting registry delegates to service the local zones, as well as a good dose of community spirit on behalf of the delegates in refraining from exploiting the community's trust. I have heard stories of many national TLDs that have not had such good luck with their delegations. --- Someone was suggesting that trademarks form a unique hierachy, and would be suitable for a TLD. As far as I understand, trademarks are registered country by country, so if a TM hierachy were implemented, it would have to be replicated under each national domain, with a second level for the twenty-some separate market classifications recognized by the trademark authorities (which I would expect to have some variations from country to country). I.e. such a domain would have the form ..TRADEMARK.US IBM.OFFICE-EQUIPMENT.TRADEMARK.US Someone else suggested that if BIND was unable to deal with a humongous flat namespace, BIND should be rewritten to do that better. I believe that better hierachical structure will benefit ANY implementation of a DNS server. A third correspondent suggested that I save my breath and sit back and wait until the mutineers fail. Actually, I think their effort has merit; it is a worthwhile experiment. I just want their tree to be rooted one level down from the top, rather than at the root. Less debris to clean up that way, if they fail to maintain discipline in their structuring of the name space. Jim Fleming complains of fees being introduced into (some parts of ?) the US branch. I think that what he really is unhappy about is that the fees are modest, so he cannot achieve the financial independence he desires by operating such a branch. (For all I know, they are probably informally regulated to be no higher than InterNIC's fees.) -- / Lars Poulsen Internet E-mail: lars@OSICOM.COM OSICOM Technologies (Internet Business Unit, formerly RNS) 7402 Hollister Avenue Telefax: +1-805-968-8256 Santa Barbara, CA 93117 Telephone: +1-805-562-3158   Received: from ietf.org by ietf.org id aa00051; 8 Nov 96 19:09 EST Received: from zephyr.isi.edu by ietf.org id aa29873; 8 Nov 96 19:04 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 8 Nov 1996 16:03:32 -0800 Message-Id: <199611090003.AA24826@zephyr.isi.edu> To: IETF-Announce: ; To: Internet-Monthly-Report-People: ; Subject: Internet Monthly Report for September, 1996 Cc: imr-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Date: Fri, 08 Nov 96 16:03:32 PST Sender:ietf-announce-request@ietf.org From: IMR Editor --NextPart The Internet Monthly Report for September, 1996 is now available at the following location: URL= ftp://ftp.isi.edu/in-notes/imr/imr9609.txt The Internet Monthly Report (IMR) is normally distributed via EMail to the IMR list and the IETF list. For most readers this is the most convenient way to receive the report. However, there are some mail systems or mail gateways that do not accommodate large messages (some issues of the IMR are more than 100,000 characters). Readers that do not receive the IMR via the normal distribution may obtain copies via FTP or EMail retrieval. Requests to be added or deleted from the IMR report list: The Internet Monthly Report list is managed by MajorDomo atISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be added or deleted from the Internet Monthly report list should be sent to majordomo@isi.edu with the message body either subscribe imr or unsubscribe imr. Requests to be added or deleted from the IETF list should be sent to ietf-request@ietf.org. Internet Monthly Report availability via WWW, FTP and EMAIL: IMR Retrieval using WWW ----------------------- The URL below may be used in web browsers to access the IMRs. You will see a list of names in the form IMR9609.TXT. For example, IMR9609.TXT is the report for September 1996. URL: ftp://ftp.isi.edu/in-notes/imr IMR Retrieval using EMAIL via the RFC-INFO Service -------------------------------------------------- The EMail retrieval system RFC-Info will send a large report in segments in separate EMail messages not exceeding 50,000 characters each. Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_imrs. For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs IMR Retrieval using FTP ----------------------- IMRs are available via anonymous FTP from FTP.ISI.EDU, with the pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of the IMR. For example IMR9609.TXT is the report for September 1996). Login with FTP username anonymous and password ftp. IMR retrieval using MIME ------------------------ Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retreive the current IMR. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="rfc-info@isi.edu" Content-Type: text/plain Retrieve: imr Doc-ID: imr9609 --OtherAccess Content-Type: Message/External-body; name="imr9609.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes/imr" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00185; 8 Nov 96 19:09 EST Received: from zephyr.isi.edu by ietf.org id aa29985; 8 Nov 96 19:07 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 8 Nov 1996 16:06:06 -0800 Message-Id: <199611090006.AA24984@zephyr.isi.edu> To: ietf@ietf.org, imr@isi.edu Subject: Internet Monthly Report for September, 1996 Cc: imr-ed@isi.edu Date: Fri, 08 Nov 96 16:06:06 PST Sender:ietf-request@ietf.org From: IMR Editor Source-Info: From (or Sender) name not authenticated. September 1996 INTERNET MONTHLY REPORTS ------------------------ The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the participating organizations. Each organization is expected to submit a 1/2 page report on the first business day of the month describing the previous month's activities. These reports should be submitted via network mail to "IMR@ISI.EDU". ````````````````````````````````````````````````````````````````````` The Internet Monthly Report mailing list is now managed by MajorDomo at ISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be ADDED or DELETED from the Internet Monthly report list should be sent to "majordomo@isi.edu" with the message body either "subscribe imr" or "unsubscribe imr". Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_imrs". For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs or URL: http://www.isi.edu/in-notes/imr/ IMR Editor [Page 1] Internet Monthly Report September 1996 TABLE OF CONTENTS INTERNET ARCHITECTURE BOARD IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3 INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3 Internet Projects INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 12 Registration Services . . . . . . . . . . . . . . . . . page 12 Directory Services. . . . . . . . . . . . . . . . . . . page 13 US Domain Registry. . . . . . . . . . . . . . . . . . . page 14 MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 18 UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 20 CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 21 TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 25 IMR Editor [Page 2] Internet Monthly Report September 1996 INTERNET ARCHITECTURE BOARD --------------------------- The minutes of the IAB back to 1990 are available for anonymous ftp access on host ftp.isi.edu, directory /pub/IAB, or via the IAB World-Wide Web page with URL http://www.iab.org/iab/. Brian Carpenter IAB Chair INTERNET ENGINEERING REPORTS ---------------------------- IETF Monthly Report for September, 1996 1. The IETF returns to San Jose, California on December 9-13, 1996. Our local host will be cisco Systems. The Secretariat will begin accepting registrations the first part of October. The IETF opens 1997 in Memphis, Tennessee where Federal Express will be the host. This meeting will be held April 7-11, 1997. Following Memphis, the IETF is we returning to Europe and will met in Munich, Germany August 11-15, 1997, hosted by Digi/ISOC.DE. The Secretariat is still working on the final meeting of 1997. Once all the arrangements have been made, notifications will be sent to the IETF Announcement list. Remember that information on future IETF meetings can be always be found in the file 0mtg-sites.txt which is located on the IETF shadow directories. This information can also be viewed from the IETF Home Page on the Web. The URL is: http://www.ietf.org 2. The minutes of the IESG teleconferences have been publicly available on the IETF Shadow directories since 1991. These files are placed in the /ftp/iesg directory. The following IESG minutes have been added: August 22, 1996 (iesg.96-08-22) September 5, 1996 (iesg.96-09-05) IMR Editor [Page 3] Internet Monthly Report September 1996 3. The IESG approved or recommended the following 15 Protocol Actions during the month of September, 1996: o RIPng for IPv6 for publication as a Proposed Standard. o RIPng Protocol Applicability Statement be published as an Informational RFC. o RIP-II MD5 Authentication for publication as a Proposed Standard. o Common Internet Message Headers be published as an Informational RFC. o Requirements for Web Transaction Security be published as an Informational RFC. o Multicast Support for Nimrod: Requirements and Solution Approaches be published as an Informational RFC. o Mobility Support for Nimrod: Requirements and Solution Approaches be published as an Informational RFC. o Definition of X.500 Attribute Types and an Object Class to Hold Uniform Resource Identifiers (URIs) for publication as a Proposed Standard. o The Model Primary Content Type for Multipurpose Internet Mail Extensions for publication as a Proposed Standard. o Network Renumbering Overview: Why would I want it and what is it anyway? be published as an Informational RFC. o How new BGP Attribute Types are defined be published as an Informational RFC. o Generic Security Service Application Program Interface, Version 2 for publication as a Proposed Standard. o Internationalization of the Hypertext Markup Language for publication as a Proposed Standard. o IMAP/POP AUTHorize Extension for Simple Challenge/Response for publication as a Proposed Standard. o IRTF Research Group Guidelines and Procedures for publication as a Best Current Practices RFC. IMR Editor [Page 4] Internet Monthly Report September 1996 4. The IESG issued 9 Last Calls to the IETF during the month of September, 1996: o Selection and Operation of Secondary DNS Servers for consideration as a Best Current Practices RFC. o Security Extensions For HTML for consideration as a Proposed Standard. o Clarifications to the DNS Specification for consideration as a Proposed Standard. o The Secure HyperText Transfer Protocol for consideration as a Proposed Standard. o The PPP NetBIOS Frames Control Protocol (NBFCP) for consideration as a Proposed Standard. o Management Information Base for Frame Relay DTEs (Draft Standard) o VEMMI URL Specification for consideration as a Proposed Standard. o A File Format for the Exchange of Images in the Internet be republished as an Informational RFC. o The PPP Bandwidth Allocation Protocol (BAP) & The PPP Bandwidth Allocation Control Protocol (BACP) for consideration as a Proposed Standard. 5. Three Working Groups were created during this period: Extensions to FTP (ftpext) Uniform Resource Names (urn) IP over Cable Data Network (ipcdn) and one working groups concluded: HyperText Markup Language (html) IMR Editor [Page 5] Internet Monthly Report September 1996 6. A total of 76 Internet-Draft actions were taken during the month of September, 1996: (Revised draft (o), New Draft(+) ) (ospf) o OSPF Version 2 (iplpdn) o Management Information Base for Frame Relay DTEs (idmr) o Core Based Trees (CBT) Multicast -- Protocol Specification (asid) o Definition of X.500 Attribute Types and an Object Class to Hold Uniform Resource Identifiers (URIs) (ripv2) o RIP-II MD5 Authentication (http) o An Extension to HTTP: Digest Access Authentication (atommib) o Definitions of Supplemental Managed Objects for ATM Management (none) o The auto-submitted e-mail header field (isdnmib) o ISDN Management Information Base (idmr) o Internet Group Management Protocol, Version 2 (idmr) o Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (isdnmib) o Dial Control Management Information Base (none) o The Model Primary Content Type for Multipurpose Internet Mail Extensions IMR Editor [Page 6] Internet Monthly Report September 1996 (trunkmib) o Definitions of Managed Objects for the DS3/E3 Interface Type (trunkmib) o Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types (none) o ISO Transport Service on top of TCP (ITOT) (mixer) o X.400 image body parts (hubmib) o Definitions of Managed Objects for IEEE 802.3 Repeater Devices (ids) o The CCSO Nameserver (Ph) Architecture (none) o Bi-directional Tunneling for Mobile IP (idmr) o Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol Specification (ids) o X.500 Implementations Catalog-96 (ids) o Managing the X.500 Root Naming Context (applmib) o Definitions of Managed Objects for Applications (trunkmib) o Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type (none) + Dynamic Reassignment of IP Addresses for TCP and UDP (idmr) o Distance Vector Multicast Routing Protocol IMR Editor [Page 7] Internet Monthly Report September 1996 (ipsec) o Combined DES-CBC, HMAC and Replay Prevention Security Transform (dnssec) o Secure Domain Name System Dynamic Update (none) o IMAP/POP AUTHorize Extension for Simple Challenge/Response (http) o Transparent Content Negotiation in HTTP (fddimib) o FDDI Management Information Base (none) o The ESP Stream Transform (pier) o Network Renumbering Overview: Why would I want it and what is it anyway? (none) o Voice Profile for Internet Mail - version 2 (issll) o IP Integrated Services with RSVP over ATM (issll) + Interoperation of Controlled-Load and Guaranteed-Service with ATM (asid) o Lightweight Directory Access Protocol: Extensions for Dynamic Directory Services (none) o SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over Ethernet (none) o Issues affecting MARS Cluster Size (mboned) o Multicast pruning a necessity IMR Editor [Page 8] Internet Monthly Report September 1996 (fddimib) o FDDI Management Information Base in the SNMPv2 SMI (mhtml) o Content-ID and Message-ID Uniform Resource Locators (none) o TFTP Multicast Option (none) + Domain Names and Company Name Retrieval (none) + Review of Roaming Implementations (none) + Challenge-Handshake Authentication Protocol for SOCKS V5 (none) + IPv4 Address Behaviour Today (ripv2) + RIP Version 2 Carrying Additional Information (none) + IP Echo Host Service (none) + V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent (none) + Requirements on HTTP for Distributed Content Editing (none) + The Application Configuration Access Protocol in the Context of Other Internet Protocols (none) + On Experimental Top Level Domains Rev 0 (none) + Tag Distribution Protocol (none) + Firewall Support for Mobile IP IMR Editor [Page 9] Internet Monthly Report September 1996 (none) + S/MIME Message Specification: PKCS Security Services for MIME (none) + Tag Switching Architecture Overview (none) + Extensions to the MARS model for Integrated Services (pppext) + Layer Two Tunneling Protocol "L2TP" (dnsind) + Simple Transaction Signature for DNS (none) + ATM Virtual Circuit Identification Support for an RSVP-based Service (none) + ST2+ over ATM Protocol Specification - UNI 3.1 Version (none) + Definitions of Managed Objects for Instance Reservation (pppext) + Proposal for LCP Authentication Option (pppext) + Proposal for LCP Authentication Option (none) + QOSPPP Framing Extensions to PPP (issll) + The Multi-Class Extension to Multi-Link PPP (none) + A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies (none) + The IPv6 communication model (otp) + OTP Extended Responses IMR Editor [Page 10] Internet Monthly Report September 1996 (none) + Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment (none) + A MODEL FOR SECURE CALL-LIKE SESSIONS WITHIN THE INTERNET (ids) + Internet Nomenclator Project (none) + Electronic Data Interchange MIB (EDIMIB) Version 1 (pier) + Subnet Lists 7. One RFC was published during the month of September, 1996: RFC St WG Title ------- -- -------- ------------------------------------- RFC1982 PS (dnsind) Serial Number Arithmetic St(atus): ( S) Internet Standard (PS) Proposed Standard (DS) Draft Standard ( B) Best Current Practice ( E) Experimental ( I) Informational Steve Coya IMR Editor [Page 11] Internet Monthly Report September 1996 INTERNET PROJECTS ----------------- INTERNIC -------- REGISTRATION SERVICES --------------------- The Following report covers the months of July, August, and September: I. Significant Events * HostReg and CReg templates are now being processed automatically; previously they had to be processed manually; now about 50% are being processed automatically. * The auto-registration software now sorts requests into six groups: (1) COM, (2) ORG, (3) NET, (4) GOV, (5) EDU and (6) TLD; this eliminates a manual step in the process and allows the ability to put an increased priority on GOV, EDU and TLD requests. * Plans to initiate a night shift are under development to assist in reducing the manual processing backlog. * Informal training was provided for Billing CSRs regarding how to register as a contact. * Selection and training of a second shift for processing support was completed; a full day training class was held on Saturday, September 10th; final staffing arrangements were completed for a night shift with a start date of September 30th. * A "SWAT Team" of existing staff was used to reduce the backlog. * Fax processing has become an overwhelming problem, requiring over four full-time equivalent employees. * Duane Stone and Carley Johnson represented the InterNIC DomReg Section at Network World Interop. * Testing of a share-ware Fax Server solution is going very well; it would make faxes available as e-mail; the fax viewer works very well on Sparc 5s and also supports sending faxes out; the MTS and Ack/Nak interfaces still need to be completed. IMR Editor [Page 12] Internet Monthly Report September 1996 * DomReg software enhancements have reduced the number of requests that need to be processed manually from about 1,000 to 700 (30% improvement). * A method for gathering performance measurements was finalized and documented. II. Current Status Sept: Email: 210,283 Postal/Fax: 2,026 Phone: 24,806 Gopher connections: 14,275 retrievals: 34,676 WAIS connections: 54,926 retrievals: 29,985 FTP connections: 73,925 retrievals: 155,385 Mailserv: n/a Telnet: 73,992 Http: 4,673,017 Whois client: 423,835 Whois server: 10,764,238 Rich Landers INTERNIC DIRECTORY AND DATABASE SERVICES ---------------------------------------- In September, our Harvest gatherer went into production operation. It currently gathers from our directory of directories pages, and offers search capabilities beyond those available using WAIS. It also gives us the ability to index web pages. We expect to index additional resources from inside and outside the InterNIC over time. To try out this system, look at: http://ds.internic.net/Harvest/brokers/dod/query.html To track new features on our servers, visit our "New Stuff" page: http://ds.internic.net/new/newstuff.html This page is updated regularly. IMR Editor [Page 13] Internet Monthly Report September 1996 A reminder - if you would like to help the Internet community find a resource that you offer, send mail to admin@ds.internic.net and we will send information about listing your resource in the Directory of Directories. If you prefer, you can enter information about your resource in our WWW suggestion form. The form can be reached through our Directory of Directories Web page at: http://ds.internic.net:80/ds/dsdirofdirs.html by Rick Huber THE US DOMAIN REGISTRY ---------------------- The US Domain now has an online line registration form. Some of the processing of the requests to the third level domain name is now automated. In particular, most requests to register names in localities already delegated are automatically forwarded to the administrator for that locality. The US Domain administrator no longer makes direct registrations of hosts, and only makes delegations of third or fourth level domain names (such as localities). A new policy has been added to the criteria for delegating domain names under the US Domain: It is the intention that the delegation of third level (for example, locality) domain names be wide spread to many registries. It is undesirable for one person or organization to manage a large part of the third level names in any particular geographic or logical area. No individual or organization shall have more than 500 delegations total in the US Domain as a whole, or more than 50 delegation in any particuilar second level (for example, a state). About the special domains under the state codes. The K12, CC, TEC, LIB, STATE, DST, COG and GEN domain under each state are established for special purposes (see RFC 1480). IMR Editor [Page 14] Internet Monthly Report September 1996 In addition to the constaint to use them only for the defined purpose, each of these special domains is also to delegated only to a manager within the state, and the operation of the delegated registry should be non-profit. The LIB domain should be managed by a govermental or educational library organization. Further, it is most appropriate for the K12, CC, and TEC, domains to be managed by an educational organization (for example, a university or a department of education). The STATE domain is most appropriately managed by an agency of the state government. DST and COG should be managed by a goverment agency. The GEN domain may be delegated to any organization that will provide the registration service for free (and remember the purpose of the GEN domain is to register statewide non-profit organizations). To obtain a copy of the list of other delegated localities and subdomains not administered by the US Domain Registrar, get the file "us-domain-delegated.txt". URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt For further information about the US Domain, send a message to: US-DOMAIN@ISI.EDU, or see our WEB page: http://www.isi.edu/us-domain US DOMAIN ADMINISTRATIVE INFORMATION ------------------------------------ EMAIL/FAX 3101 PHONE 500 ---------------------------- Total Contacts 3601 DELEGATIONS 137 FORWARDED DELEGATIONS: 972 OTHER US DOMAIN MSGS: 2492 --------------------------- Total 3601 IMR Editor [Page 15] Internet Monthly Report September 1996 OTHER US DOMAIN MESSAGES INCLUDE: referrals to other subdomains or to/from the InterNic, phone calls, modifications, application requests, discussion and clarification of the requests, questions about names, resolving technical problems with zone files and name servers, and whois listings. In addition, and not listed below, another 398 localities have been delegated in Arizona, Arkansas, California, Colorado, Connecticut, Massachusetts, Maryland, Missouri, Montana, Michigan , Mississippi, North Carolina, New Jersey, New York, Virginia, Vermont, this month. MAJOR SUBDOMAINS DELEGATED K12 CC TEC STATE LIB MUS GEN DST COG =================================================================== 51 37 34 47 39 23 24 9 4 =================================================================== ----------------------- THIRD LEVEL DELEGATIONS ----------------------- CC.AL.US Community Colleges, Alabama. LIB.AR.US Libraries, Arkansas. TEC.AR.US Technical Schools, Arkansas. GEN.AR.US General, Arkansas. CC.AR.US Community Colleges, Arkansas. LOCALITIES ========== CHEYENNE-ARAPAHO.NSN.US. WESTFIELD.IN.US. BEANBLOSSOM.IN.US. ATLANTA.GA.US. COLORADO-SPRINGS.CO.US. LEES-SUMMIT.MO.US MIDFIELD.AL.US. CITY-OF-COMMERCE.CA.US. OAK-BLUFFS.MA.US. ALBEMARLE.NC.US. LAYTONSVILLE.MD.US. BRUNSWICK.OH.US. GILPIN.CO.US. SULLIVAN.TN.US. DIAMONDHEAD.MS.US. GREENE.OH.US. NEW-HANOVER.NC.US. ASHEVILLE.NC.US. COBURG.OR.US. WAVELAND.MS.US. WASHTENAW.MI.US. EATON.MI.US. COLTS-NECK.NJ.US. SUFFOLK.VA.US. FREMONT.CA.US. PLEASANTON.CA.US. COLTS-NECK.NJ.US. SUFFOLK.VA.US. IMR Editor [Page 16] Internet Monthly Report September 1996 FREMONT.CA.US. PLEASANTON.CA.US. ROCHESTER.NH.US. HAYWARD.CA.US. MANCHESTER.VT.US. BAY-ST-LOUIS.MS.US. LITTLEROCK.CA.US. OTHER US DOMAIN DELEGATIONS THIS MONTH -------------------------------------- TOWN.HIGHLAND.NY.US. TWP.SCIO.MI.US. HEALTH.CO.HERKIMER.NY.US. BARTLESVILLE.LIB.OK.US. GOODMAN.SUNBURY.PA.US. LAKEMED.CUMBERLAND.ME.US. MSAS.GEN.MI.US. CALVARY.GEN.MI.US. CI.BIG-BEAR-LAKE.CA.US. HAMPTON.LIB.NH.US. CO.NEVADA.CA.US. SRVFPD.DST.CA.US. INFO.WASHINGTON.DC.US. NSCC.CC.MA.US. CI.MADISON.NH.US. MADISON.LIB.NH.US. HILLSML.LIB.NH.US. FRIEDMAN.MOUNTAIN-VIEW.CA.US. CI.WOODSTOCK.IL.US. MILIND-MARTHE.LARAMIE.WY.US. PARADOX.WESTCHESSTER.CA.US. ONEWORD.READING-CENTER.NY.US. FORD.DEARBORN.MI.US. CI.CRESTLINE.OH.US. CI.EVERETT.WA.US. TOM.AGOURA.CA.US. YV.COG.WA.US. WWW.WASHINGTON.DC.US. PORTERCO.CO.PORTER.IN.US. MAGISTRATE.COG.GA.US. TOWNSHIP.MONROE.NJ.US. GCIT.TEC.NJ.US. CI.NEWMAN-GROVE.NE.US. CI.LEWISTON.NE.US. SCVWD.DST.CA.US. WWW.CO.GWINNETT.GA.US. PICHER.K12.OK.US. CI.FAIRFIELD.OH.US. CPI.NEW-YORK.NY.US. CI.SCHUYLER.NE.US. ECDEV.COVINA.CA.US. CI.MUKILTEO.WA.US. ASPENTREE.LARAMIE.WY.US. METRO.WASHINGTON.DC.US. ABNAMRO.CHICAGO.IL.US. ECPUBL.LIB.CA.US. WMRLS.LIB.MA.US. TOWN.CHEVERLY.MD.US. SPIDERNET.CHAUTAUQUA.NY.US. SHERIFF.FRANKLIN.OH.US. KONAWA.K12.OK.US. CI.OAKLAND.NE.US. PETERSON.HAYWARD.CA.US. CI.HUMBOLDT.NE.US. CI.WAYNE.NE.US. CI.EUSTIS.NE.US. CI.SHELBY.NE.US. CI.OSCEOLA.NE.US. HEALTH.CO.MONROE.NY.US. CO.MADISON.NY.US. SOPHIA2.SOMERVILLE.MA.US. CI.BARRINGTON-HILLS.IL.US. CI.NEWARK.OH.US. AMB.CARMEL-VALLEY.CA.US. CMASS.GEN.MA.US. CO.BUTTE.CA.US. CO.ALLEN.IN.US. CI.HESPERIA.CA.US. CHAMBER.DEMOPOLIS.AL.US. CI.FLAT-ROCK.MI.US. CO.ALLEN.IN.US. CI.HESPERIA.CA.US. CHAMBER.DEMOPOLIS.AL.US. CI.FLAT-ROCK.MI.US. SVAHA.YELLOW-SPRINGS.OH.US. WMC.WRIGHTSVILLE.AR.US. STPAT.GEN.MI.US. JAYCEES.GEN.MI.US. IMR Editor [Page 17] Internet Monthly Report September 1996 CI.LAGUNA-HILLS.CA.US. LSCS.LAKE-STATION.IN.US. CI.MANCHESTER.NH.US. VAMPIRES.IRVING.TX.US. BOSCOTECH.TEC.CA.US. FLINT.HARTLAND.MI.US. COLEMAN.HADLYME.CT.US. CI.CREIGHTON.NE.US. CI.WASHINGTON.DC.US. EIGHTCAP.GEN.MI.US. CI.RUSHVILLE.NE.US. MIKESUN.HOLMDEL.NJ.US. CI.SAN-PABLO.CA.US. TOWN.ANDOVER.MA.US. FIRSTCITY.LIB.AK.US. HEALTH.CO.ORLEANS.NY.US. RAPTOR.BENTON.KS.US. STANG.MOUNDRIDGE.KS.US. HATHBURN.NIOTA.TN.US. GREGNET.ROYERSFORD.PA.US. CI.TARBORO.NC.US. BAYPATH.TEC.MA.US. ANTIOCH.YELLOW-SPRINGS.OH.US. LOOPEXPERT.BRIDGEWATER.NJ.US. TOMLINSON.LPS.K12.OK.US. SCHOLASTICA.CHICAGO.IL.US. QAR.OAK-PARK.CA.US. CO.JOHNSTON.NC.US. CI.WALNUT.CA.US. CI.BAYTOWN.TX.US. AGRANENTERPRISES.ATLANTA.GA.US. CRAIGSWORLD.FT-LAUDERDALE.FL.US. LAKESREGIONOFMAINE.GEN.ME.US. DHS.CO.FAIRFIELD.OH.US. TWP.CARNEYS-POINT.NJ.US. BREEDERS-REGISTRY.GEN.CA.US. MCS.GEN.ME.US. SKIPATROL.MT-HOOD.OR.US. CO.CULPEPER.VA.US. CI.PLEASANTON.CA.US. ----------------------------------------------------------- URL: http://www.isi.edu/us-domain/ Shanthi Ranganathan (US-Domain@ISI.EDU) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MERIT INTERNET ENGINEERING -------------------------- This report summarizes September 1996 activities of Merit's Internet Engineering group on behalf of the Routing Arbiter (RA) service and other projects. The National Science Foundation has announced a new direction for the Routing Arbiter project, which was charged by NSF in 1994 with the task of providing routing coordination in the post-NSFNET environment. The announcement, which followed the 24-month review of the Routing Arbiter and the four Network Access Point projects, noted that all these projects had completed their basic missions ahead of schedule. The RA project is a partnership between Merit and the University of Southern California Information Sciences Institute. George Strawn, networking division director at the NSF, commended the Routing Arbiter for its performance during the past two years, and noted that the Routing Arbiter and the NAPs "have IMR Editor [Page 18] Internet Monthly Report September 1996 now proven that multiple network providers can work together in a competitive marketplace, and so can be scheduled for transition to commercial operations themselves." NSFNET program director Mark Luker said that researchers from the RA and the NAPs will now focus on connections and routing for advanced networking, and noted that "both actions help NSF to move to the next stage, a stronger focus on the high-performance Internet of the future needed to support today's advanced research." Merit is working with NSF to define its refocused activities for the RA project. Elise Gerich, Associate Director of Merit for National Networking, resigned her position to take a job in private industry. Elise joined Merit in 1987 in support of the NSFNET Backbone Service project, and focused on technical interfaces and policy interactions between the regional networks, sister Federal agencies, and international network research organizations. She was named Manager of the Internet Engineering group in 1994, was promoted to Associate Director in July 1995, and was also a Co- Principal Investigator for the Routing Arbiter project. Elise was instrumental in providing a smooth transition for the regional networks to the new NSFNET architecture. We wish her continued success in her new position! Merit invites applications for both the Associate Director and Manager of Internet Engineering positions; for further information, contact Merit President Eric Aupperle (313/764-9430, ema@merit.edu). Last month's report described a new incremental update client implemented for the Routing Arbiter Database by Jerry Winters. At that writing, the client was polling the RIPE registry's mirroring site every 30 minutes for database updates; previously, updates had only been provided once each day. The new client is now polling the RIPE site every 15 minutes; eventually, Merit expects that polls will occur every five minutes. A new tool known as IPN, Inter-Provider Notification, is now available on the RA Web pages: http://compute.merit.edu/ipn.html IMR Editor [Page 19] Internet Monthly Report September 1996 IPN is a public bulletin board that Internet Service Providers and NAP operators can use to announce scheduled maintenance and ongoing network outages. IPN participants include major Internet Service Providers who BGP-peer at one or more of the primary exchange points. We encourage providers to participate in testing and developing the new tool; improved coordination and cooperation among providers will lead to a better-managed and more stable Internet. To join the IPN, send e-mail to: outage@ra.net Brian Renaud attended the 25th RIPE meeting in Amsterdam, where he participated in sessions of the Routing and Database Working Groups. Susan R. Harris (srh@merit.edu) UCL ---- Finally, the effort on the Merci project has paid off, with help from HP and LBL, and the audio, text and (LBNL) video tools rat, nte and vic all work on the various Microsoft Windows platforms. Availability soon. John Crowcroft (j.crowcroft@CS.UCL.AC.UK) IMR Editor [Page 20] Internet Monthly Report September 1996 CALENDAR -------- Last update 10/9/96 The information below has been submitted to the IETF Secretariat as a means of notifying readers of future events. Readers are requested to send in dates of events that are appropriate for this calendar section. Please send submissions, corrections, etc., to: Please note: The Secretariat does not maintain on-line information for the events listed below. FYI - The EMail World & Internet World originally scheduled for Sept. 10-12, 1996 has been moved to Oct. 15-17, 1996. Boston, MA. A copy of this calendar is available as follows: VIA FTP ------ IETF Information is available by anonymous FTP from several sites. US East Coast Address: ds.internic.net (198.49.45.10) US West Coast Address: ftp.isi.edu (128.9.0.32) Europe Address: nic.nordu.net (192.36.148.17) Pacific Rim Address: munnari.oz.au (128.250.1.21) Africa Address: ftp.is.co.za (196.4.160.12) cd ietf ls *0mtg* WWW ------- Click on the link for "meetings" and you should find an entry "listing of other Internet related events". ************************************************************************ 1996 ----------- Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL Oct. 7-11 ATM Forum Montreux, Switzerland IMR Editor [Page 21] Internet Monthly Report September 1996 Oct. 7-11 NetWorld+Interop Paris, France Oct. 7-11 Performance 96 Conference Lausanne, Switzerland Oct. 9-11 Object World Frankfurt Frankfurt, Germany Oct. 13-16 IEEE Local Computer Ntwrks (LCN) Minneapolis, MN Oct. 14-17 MEDNET '96 European Congress of the Internet in Medicine Brighton, UK Oct. 15 Commercenet New Orleans, LA Oct. 15-17 EMail World & Internet Expo Boston, MA Oct. 15-18 3rd Int'l on Protocols for Multimedia Systems Madrid, Spain Oct. 16-18 Internet World Monterrey '96 Monterrey, Mexico Oct. 16-19 5th Int'l Conference on Computer Communications & Ntwrks Rockville, MD Oct. 17-20 IEEE Symposium on Planning & Design of Broadband Networks Quebec, Canada Oct. 21-22 FNC Advisory Committee Arlington, VA Oct. 21-23 Integrated Office Conf '96 San Diego, CA Oct. 21-25 ICECCS'96 (held jointly with 6th CSESAW, 4th IEEE RTAW) Montreal, Canada Oct. 24-25 2nd IEEE Wrkshop on Wireless LANs Worcester, MA Oct. 28-31 2nd USENIX Seattle, WA Oct. 28-Nov. 1 NetWorld+Interop London, England Oct. 29-31 Internet Professional '96 Paris, France Oct. 29-Nov. 1 ICNP-96 Int'l Conf. on Network Protocols Columbus, Ohio Oct. 29-Nov. 1 2nd USENIX Symp. Operating Sys. Design & Implement. (OSIDI II) Seattle, WA Nov. 1996 OMG TC (Groupe Bull) Nice, France Nov. 4-6 APPN Implementers Workshop Raleigh, NC Nov. 4-8 ANSI X3T10 '96 Western Digital Palm Springs, CA Nov. 5-6 7th Maryland Workshop on Very High Speed Networks Balitmore, MD Nov. 6-8 Web Developer Mexico '96 Mexico Ciy, Mexico Nov. 10-12 2nd annual of ACM's MobiCom '96 Rye, New York Nov. 11-15 IEEE 802 '96 Hotel Vancouver Vancouver, BC Canada Nov. 12-15 3rd Int'l Conf. on Multimedia Modeling Toulouse, France Nov. 13 Commercenet Santa Clara, CA Nov. 18-20 2nd USENIX Workshop on Electronic Commerce Oakland, CA Nov. 18-22 ACM Multimedia '96 Boston, MA Nov. 18-22 IEEE Globecom 96 London, England Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA Nov. 20-21 IEEE Global Internet '96 London, UK Nov. 25-29 NetWorld+Interop Sydney, Australia Dec. 2-4 Web World San Diego, CA Dec. 2-6 ANSI X3T11 (host by IBM) Minneapolis, MN Dec. 2-6 ATM Forum Vancover, BC IMR Editor [Page 22] Internet Monthly Report September 1996 Dec. 4-6 Vir. Reality & VRML World '96 Boston, MA Dec. 9-12 Internet World '96 Baltimore, MD Dec. 9-13 37th IETF (host by cisco) San Jose, CA Dec. 9-13 OIW (Firm) Dec. 10-13 Fall Internet World '96 New York, NY Dec. 12 Internet Security for System & Network Administrators Pittsburgh, PA Dec. 13 Commercenet Albuquerque, NM 1997 ----------- Jan. 6-10 ANSI X3T10 '97 Jan. 6-10 USENIX '97 Annual Technical Conf. Anaheim, CA Jan. 6-10 USELINUX: Linux Appl. Dev. Anaheim, CA Jan. 7-10 13th Annual Hawaii Int'l Conf on Systems Sciences Maui, Hawaii Jan. 7-10 Internet World Canada '97 Toronto, Canada Jan. 21-23 Internet World Shanghai-China Shanghai, China Jan. 21-25 Internet World Singapore Intl Singapore Jan. 28-30 IEEE 802.10 Interim meeting Orlando, FL Feb. 3-7 ANSI X3T11 (host by Sun) San Jose, CA Feb. 9-15 ATM Forum San Diego, CA Feb. 10-11 ISOC Symposium on Network and Distributed System Security San Diego, CA Feb. 17-19 Internet Expo & EMail World San Jose, CA Mar. 1-5 ACM '97: The Next 50 yrs. of Computing San Jose, CA Mar. 10-13 UniForum San Francisco, CA Mar. 10-14 OIW (Firm) Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque Mar. 11-14 Spring Internet World '97 Los Angeles, CA Mar. 11-15 ANSI X3T10 '97 Mar. 17-19 1st Euromicro Working Conf. on Software Maintenance & Reengineering Berlin, Germany Mar. 19-21 Internet World Asia '97 Kuala Lumpur, Malaysia Mar. 24-27 APPN Implementers Workshop Raleigh, NC Apr. 7-11 38th IETF (host by Fed. Exp) Memphis, TN Apr. 7-11 ANSI X3T11 (Brocade) Palm Springs, CA Apr. 7-11 IEEE Infocom '97 Kobe, Japan Apr. 9-11 ISADS 97 - 3rd Intl Symposium on Autonmous Decentralized Sys. Berlin, Germany Apr. 22-24 Internet Expo & EMail World Chicago, IL Apr. 27-May 3 ATM Forum Chicago, IL May 5-9 ANSI X3T10 '97 May 12-15 8th JENC8 Edinburgh, Scotland May 12-16 IFIP/IEEE San Diego, CA IMR Editor [Page 23] Internet Monthly Report September 1996 May 19-21 7th Int'l Workshop on Ntwk & Oper for Digital Audio & Video St. Louis, MO May 28-30 Web Developer '97 Chicago, IL Jun. 3-5 Internet World Mexico '97 Mexico City, Mexico Jun. 8-12 ICC '97 (joint with ENM) Montreal, CANADA Jun. 9-13 OIW (Firm) Jun. 9-13 ANSI X3T11 (host by Boeing) Seattle, WA Jun. 24-27 INET '97 Kuala Lumpur, Malaysia Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI Jul. 14-18 ANSI X3T10 '97 Jul. 14-17 APPN Implementers Workshop San Jose, CA Jul. 20-26 ATM Forum Montreal, CANADA Aug. 4-8 ANSI X3T11 (host by Hitachi) Honolulu, HI Aug. 11-15 39th IETF (host by German ISOC) Munich, Germany Aug. 12-14 (tenative) Internet Expo & EMail World Boston, MA Sep. 8-12 ANSI X3T10 '97 Sep. 8-12 OIW (Firm) Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France Oct. 6-10 ANSI X3T11 (host by FSI) Tucson, AZ Nov. 3-7 ANSI X3T10 '97 Nov. 30-Dec 6 ATM Forum Singapore Dec. 1-5 ANSI X3T11 (host by DPT) Orlando, FL Dec. 8-12 40th IETF (tentative) Univ. of Hawaii Dec. 8-12 OIW (Firm) TELECOM '97 Asia (Venue and Dates to be Determined) 1998 ----------- SPRING 1998 TELECOM '97 Africa Midrand, South Africa Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and Budapest, Hungary 1999 ----- Oct. 8-14 TELECOM '99 Geneva, Switzerland IMR Editor [Page 24] Internet Monthly Report September 1996 TERENA List of Meetings ======================= This list of meetings is provided for information. Many of the meetings are closed or by invitation; if in doubt, please contact the chair of the meeting or the TERENA Secretariat. If you have additions/corrections/comments, please mail . ********************************************************************** MEETING/DATE LOCATION ============ ======== TERENA General Assembly ----------------------- GA6 24-25 October Bled GA7 15-16 May 1997 Edinburgh TERENA Executive Committee -------------------------- 17 December Amsterdam TERENA Technical Committee -------------------------- 13 November Brussels 22 January 1997 Amsterdam TERENA Office Meeting --------------------- 16 October Amsterdam JENC8 ----- Conference Committee 8 November (provisional) Edinburgh Programme Committee 4 December Amsterdam IMR Editor [Page 25] Internet Monthly Report September 1996 INSIGHT Training Workshop ------- 28-29 October Bled CEEnet ------ 26 October Bled PHARE Research Networking ------ 25 October Bled ----------------------------------------------------------------- ================================================================= EEMA ---- Electronic Commerce '96 Wembley, London 15-17 October Regional Conference 29 November - 1 December Malta Electronic Communications Olympia, London 10-12 December EWOS ---- TA35, 3-4 December Brussels TA36, 25-26 February 1997 " TA37, 13-14 May 1997 " TA38, 16-17 September 1997 " TA39, 2-3 December 1997 " SC - 24 September " SC - 17 December " Workshops 35: 21-25 October Brussels 36: 20-24 January 1997 " 37: 7-11 April 1997 " 38: 16-20 June 1997 " 39: 27-31 October 1997 " IMR Editor [Page 26] Internet Monthly Report September 1996 ETSI ---- Seminar/Workshop 1-3 October Nice, France GA24 10-11 December Nice, France TA25 23-25 October " IETF ---- 9-13 December San Jose, CA 7-11 April 1997 Memphis, Tenn. 11-15 August 1997 Munich, Germany RIPE ---- RIPE26 20-22 January 1997 Amsterdam RIPE27 May 1997 Dublin NATO Workshop ------------- 5-9 May 1997 Edinburgh +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TERENA CONFERENCES ------------------ Call for Papers JENC8 - 8th Joint European Networking Conference ------------------------------------------------ "Diversity and Integration: The New European Networking Landscape" 12-15 May 1997 Edinburgh, Scotland This conference will be the European Forum to get up-to-date information, to debate and assess the new deregulated tele- communication environment in Europe, new leading-edge applications, and the network/internetwork support infrastructure which is currently being developed IMR Editor [Page 27] Internet Monthly Report September 1996 Subject Areas: * Emerging Network Technologies and Network Engineering * User Support, Training and Education * Security and Management Issues * Information Systems and Distributed Applications * Economic and Political Issues Deadline for paper submission 10 November 1996 to: For information please contact the JENC8 Secretariat at: TERENA Secretariat Singel 466-468 1017 AW Amsterdam, The Netherlands tel: +31 20 6391131 fax: +31 20 6393289 email: http://www.terena.nl/jenc8 or JENC8 Local Organization c/o Concorde Services Ltd Unit 5, SECC Glasgow, G3 8YW, Scotland email: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ OTHER CONFERENCES: ----------------- Performance '96 --------------- International Conference on Performance Theory, Measurement and Evaluation of Computer and Communications Systems Organized by IFIPWG7.3 7-11 October Ecole Polytechnique Federal de Lausanne, Lausanne, Switzerland Deadline paper submission 15 March 1996 Further information on WWW Page: http://lrcwww.epfl.ch/perf96/ IMR Editor [Page 28] Internet Monthly Report September 1996 PROMS'96 Third International Workshop on Protocols for Multimedia Systems ---------------------------------------------------------------- 15-18 October Madrid, Spain This workshop is intended to contribute to scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their usage on broadband networks. Papers to be submitted by 7 June. For information contact Arturo Azcorra at 6th CEN/CENELEC/ETSI Conference 1996 -------------------------------- 5-6 November Sheraton Brussels Hotel, Brussels, Belgium Theme of this conference is "Standards on Trial: Case Studies in European Standardization" Deadline for abstracts is 13 Sept. For further information: c/o CENELAC, Tel: +32 2 519 6871 Fax: +32 2 519 6919 IDATE96 18th International Conference of IDATE -------------------------------------- 6-8 November Montpellier, France An opportunity for professional contacts with major industrial group leaders, users and clients, researchers and academics, administrators and politians. Full details of the conference available on the Web: http://www.idate.fr CEN/TC304 - Character Set Technology Workshop --------------------------------------------- 11-12 November Bled, Slovenia Providing multilingual support in middleware: Implementing the Universal Character Set ISO 10646 in the European Information Society For information look up URL: http://www.e5.ijs.si/i18n/ws-bled.html IMR Editor [Page 29] Internet Monthly Report September 1996 "The Telematics Revolution, Consequences for Individuals and Organisations" ---------------------------------------------- 13 November University of Technology, Eindhoven, the Netherlands Theme of the conference is that progress of information and telecommunication technologies do create a huge number of questions, be it social, jurisdictional, economic or technical. Parallel sessions will deal with: interactive scientific visual- isation, tele-learning, user aspects of multimedia, distant consultation and using of laboratories. For all information and to receive brochure, contact Mr. Marc Fleskens at email address IEEE Global Internet 1996 ------------------------- 20-21 November Queen Elizabeth II Conference Centre, London This mini-conference will provide an open forum for the communications and computer networking communities to review the state-of-the-art technologies and applications of the evolving Global Internet. Deadline paper submissions 15 May to: http://gaia.cs.umass.edu:80/tccc/internet96/ or email Jon Crowcroft WEB INTERNATIONALIZATION & MULTILINGUISM SYMPOSIUM -------------------------------------------------- 20-22 November Sevilla, Spain Organized by Sadiel and the WWW Consortium, with the support of the European Commission. The object of this symposium is the advancement of the internationalization and multilingualism of the Web, as well as to seek agreement on the relevant standards. Registration from 15 September. For further information see: http://www.w3.org/pub/WWW/International/Sevilla-96 IMR Editor [Page 30] Internet Monthly Report September 1996 EITC'96 - European IT Conference -------------------------------- 25-27 November Congress Centre, Brussels, Belgium "Doing Business in the Information Society" Electronic commerce, provides the focus for sessions on IT applications, enabling technologies and international initiatives. Post-Conference Workshops to be held on 28 November. For information contact European Commission, DGIII or WWW: http://www.cordis.lu/esprit/src/eitc96.htm ASIAN'96 - Asian Computing Science Conference --------------------------------------------- 2-5 December Singapore Themes of this conference is: - Programming (sematics, languages, systems, ...) - Concurrency & Parallelism (algorithms, formalisms, systems ...) - Networking & Security (algorithms, protocols, formalisms, ...) Additional information available from: http://www.escs.nus.sg/~asian96 Multimedia Computing and Networking 1997 ---------------------------------------- 10-12 February 1997 San Jose, CA, USA The object of this conference is to bring together researchers, developers, and practitioners working in all facets of multimedia computing and networking. Paper submission by 16 July 1996. For further information email COREC -"Interregional Cooperation in RTD - Challenges and Opportunities for Regions in Economic Conversion" --------------------------------------------------------- 16-17 December Bremen, Germany Background is the experience of the community initiative STRIDE and other programmes of the European Commission.The conference will deal questions of RTD-programmes and policies, their European Dimension and impact on regional development. For information contact Mr. Wolfgang Petzold at: email IMR Editor [Page 31] Internet Monthly Report September 1996 IEEE INFOCOM '97 16th Annual Joint Conference of the IEEE Computer & Communications Societies ---------------------------------------- 7-11 April 1997 Kobe, Japan Paper submissions by 14 June 1997. For further information contact http://www.ics.uci.edu/~infocom/ http:// arpeggio.ics.es.osaka-u.ac.jp/infocom.html ISADS 97 3rd International Symposium on Autonomous Decentralized Systems --------------------------------------------------------------- 9-11 April 1997 Berlin, Germany Supported by Hitachi, DeTeBerkom, NEC, Digital, GMD-FOCUS, Hewlett Packard, IBM. The focus will be on advancements and innovations in ADS platforms and applications. Integration of telecommunication and computing aspects into a uniform concept for providing an open distributed processing environment. For information see WWW: http://www.fokus.gmd.de/ws/isads97/ EEMA'97 10th Annual Conference of European Electronic Messaging Association ------------------------------------------------------------------- 16-19 June 1997 Maastricht Exhibition and Congress Centre, Maastricht, Netherlands Issues of the conference will be: Global Security; Corporate Directories; Messaging Products & Services; Electronic Commerce; Global Messaging Enterprise; European Initiatives; Mobile Messaging Technology; Messaging Technology & Management Strategy; Intranet; World Wide Web & Infobots. For information contact WWW: http://www.eema.org/ IMR Editor [Page 32] Internet Monthly Report September 1996 INET'97 The Internet: The Global Frontiers ---------------------------------- 24-27 June 1997 Kuala Lumpur, Malaysia The conference will address the traditional and evolving frontiers of the Internet as well as its significant impact on education, commerce and societies throughout the world. Abstracts of papers to be submitted by 10 October. -for details of submission procedure email -for program information email ==================================================== This meeting list is also available on our WWW page: http://www.terena.nl/news/ ==================================================== IMR Editor [Page 33]   Received: from ietf.org by ietf.org id aa00278; 8 Nov 96 19:10 EST Received: from service.esys.ca by ietf.org id aa00064; 8 Nov 96 19:08 EST Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0vM0vP-000UmhC; Fri, 8 Nov 96 17:05 MST Received: from multivac.orthanc.com by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0vM0z1-000RWwC; Fri, 8 Nov 96 17:09 MST Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.8.0/8.8.0) with SMTP id RAA00508; Fri, 8 Nov 1996 17:08:48 -0700 (MST) Date: Fri, 8 Nov 1996 17:08:48 -0700 (MST) Sender:ietf-request@ietf.org From: Lyndon Nerenberg To: Leonid Egoshin cc: ietf@ietf.org, lars@anchor.rns.com Subject: Re: Why More TLDs In-Reply-To: <199611082122.NAA06282@giant.genesyslab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Fri, 8 Nov 1996, Leonid Egoshin wrote: > Yes, but the namespace of _trademarks_ is unique. Of course in the > area of corresponding laws. And it is possible to create hierarhy .TM > which would match "hierarhy" of trademarks laws. And we can register > company under name if its trademarks. Since the trademark space is not globally unique this would have to be ..TM. --lyndon   Received: from ietf.org by ietf.org id aa00275; 8 Nov 96 19:10 EST Received: from sjf-mail20.sjf.novell.com by ietf.org id aa00065; 8 Nov 96 19:08 EST Received: from INET-SJF-Message_Server by novell.com with Novell_GroupWise; Fri, 08 Nov 1996 16:01:23 -0800 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 08 Nov 1996 16:00:49 -0800 Sender:ietf-request@ietf.org From: Skip Addison To: egoshin@genesyslab.com, ietf@ietf.org Subject: Re: Why More TLDs -Reply Source-Info: From (or Sender) name not authenticated. Trademarks are not at all unique, even within a geography. Two companies can use the same trademark name if their goods and services are unrelated. The requirement is simply that no relationship between the companies would be inferred by a "reasonable" consumer. I've seen some real life examples that escape me at the moment. The best one I can come up with off the top of my head is "Safeway" (grocery store chain) and "Safeway" (security software). Unrelated services, identical trademark. Who gets Safeway.com? Here's an example closer to home. Look at www.forefront.com. Now www.ffg.com. Tell me there's no trademark collision. That's just "doing-business-as" (DBA) names. We haven't even gotten started on product brands. -- Skip >From: Leonid Egoshin 11/08/96 01:22pm > [ . . . ] > Yes, but the namespace of _trademarks_ is unique. Of course in the >area of corresponding laws. And it is possible to create hierarhy .TM >which would match "hierarhy" of trademarks laws. And we can register >company under name if its trademarks.   Received: from ietf.org by ietf.org id aa00579; 8 Nov 96 19:14 EST Received: from [207.32.128.130] by ietf.org id aa00493; 8 Nov 96 19:13 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id SAA01112; Fri, 8 Nov 1996 18:07:19 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCD9F.F30E10A0@webster.unety.net>; Fri, 8 Nov 1996 18:09:14 -0600 Message-ID: <01BBCD9F.F30E10A0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "ietf@ietf.org" , 'Lars Poulsen' Cc: 'New Newdom' Subject: RE: US Top Level Domain Date: Fri, 8 Nov 1996 18:09:12 -0600 Encoding: 128 TEXT Source-Info: From (or Sender) name not authenticated. On Friday, November 08, 1996 5:09 PM, Lars Poulsen[SMTP:lars@anchor.rns.com] wrote: @ On Friday, November 08, 1996 7:20 AM, @ Simson L. Garfinkel[SMTP:simsong@VINEYARD.NET] wrote: @ >@ US domain used to be a volunteer project. It became a burden for ISI. So they @ >@ farmed it out. People who take up regions are allowed to charge. @ @ In article <01BBCD4C.3102DB60@webster.unety.net> @ JimFleming@unety.net (Jim Fleming) writes: @ >It is useful to note that this "farming out" was not done with @ >an RFC, no fee guidelines have been set, no IAHC had to be @ >formed, and the net has not collapsed. @ @ While one could wish that the RFCs documenting the operation of @ the US domain had been updated when the procedures changed, @ the transition appears to have gone remarkably well. @ There have been no wholesale complaints of @ - lack of access @ - unreasonable fees @ - contention for address space @ that I am aware of, other than the allegations from the @ "AlterNIC mutineers" for which I have not seen specific @ examples to back them up. @ @ I attribute this success to someone having had extremely good @ judgement in selecting registry delegates to service the local @ zones, as well as a good dose of community spirit on behalf @ of the delegates in refraining from exploiting the community's @ trust. I have heard stories of many national TLDs that have @ not had such good luck with their delegations. @ @ --- @ @ Someone was suggesting that trademarks form a unique hierachy, @ and would be suitable for a TLD. As far as I understand, trademarks @ are registered country by country, so if a TM hierachy were @ implemented, it would have to be replicated under each national @ domain, with a second level for the twenty-some separate market @ classifications recognized by the trademark authorities (which I @ would expect to have some variations from country to country). @ I.e. such a domain would have the form @ @ ..TRADEMARK.US @ IBM.OFFICE-EQUIPMENT.TRADEMARK.US @ @ Someone else suggested that if BIND was unable to deal with a @ humongous flat namespace, BIND should be rewritten to do that @ better. I believe that better hierachical structure will benefit @ ANY implementation of a DNS server. @ @ A third correspondent suggested that I save my breath and @ sit back and wait until the mutineers fail. Actually, I think @ their effort has merit; it is a worthwhile experiment. I just @ want their tree to be rooted one level down from the top, @ rather than at the root. Less debris to clean up that way, @ if they fail to maintain discipline in their structuring @ of the name space. @ @ Jim Fleming complains of fees being introduced into (some parts @ of ?) the US branch. I think that what he really is unhappy @ about is that the fees are modest, so he cannot achieve the @ financial independence he desires by operating such a branch. @ (For all I know, they are probably informally regulated to be @ no higher than InterNIC's fees.) @ -- @ / Lars Poulsen Internet E-mail: lars@OSICOM.COM @ OSICOM Technologies (Internet Business Unit, formerly RNS) @ 7402 Hollister Avenue Telefax: +1-805-968-8256 @ Santa Barbara, CA 93117 Telephone: +1-805-562-3158 @ @ Can you point out where I am "complaining" of fees being introduced into the US top level domains ? I believe that I was pointing out that a double standard is at play, when the US top level domain is ready to be parceled out, people just do it, and they do not ask anyone...other delegations have not happened in this manner. I find it interesting that you attribute the quiet, behind the scenes transition of the US domain to be "extremely good judgement". Why is that ? Did the "right" people make the decision without asking anyone ? So you give your rubber stamp approval. Do you consider it a success because it was done quietly ? Also, who is to say this has been a success ? How many people really know what is going on ? Maybe the key to top level domain migration is to use "extremely good judgment" and do it quietly the way the US domain was given away. No RFCs were needed, no committees, no consensus. All that was needed were commercial companies willing to speculate on various city names and willing to run registries, collect money, and keep DNS data bases up to date. This is about all that is needed for progress to be made on new top level domains. I think that many people, including myself, have been saying this for a long time. The double standard is that people on "newdom" and in similar discussions are told one thing while the US domain administrators do as they please. You call this "extremely good judgement". If we follow your guidance, top level domain delegations and registry start-ups should quietly proceed while the rest of the people make a lot of noise in San Jose and other places. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa03717; 8 Nov 96 19:50 EST Received: from [207.32.128.130] by ietf.org id aa02888; 8 Nov 96 19:48 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id SAA01203; Fri, 8 Nov 1996 18:41:54 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCDA4.C8093D80@webster.unety.net>; Fri, 8 Nov 1996 18:43:49 -0600 Message-ID: <01BBCDA4.C8093D80@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'New Newdom' Cc: "'ietf@ietf.org'" , "'postel@isi.edu'" Subject: 500 Delegation Limit Date: Fri, 8 Nov 1996 18:43:48 -0600 Encoding: 45 TEXT Source-Info: From (or Sender) name not authenticated. @@@@@ ftp://ftp.isi.edu/in-notes/imr/imr9609.txt THE US DOMAIN REGISTRY ---------------------- The US Domain now has an online line registration form. Some of the processing of the requests to the third level domain name is now automated. In particular, most requests to register names in localities already delegated are automatically forwarded to the administrator for that locality. The US Domain administrator no longer makes direct registrations of hosts, and only makes delegations of third or fourth level domain names (such as localities). A new policy has been added to the criteria for delegating domain names under the US Domain: It is the intention that the delegation of third level (for example, locality) domain names be wide spread to many registries. It is undesirable for one person or organization to manage a large part of the third level names in any particular geographic or logical area. No individual or organization shall have more than 500 delegations total in the US Domain as a whole, or more than 50 delegation in any particuilar second level (for example, a state). @@@@@@ Is a company an "organization"...? Can people own multiple companies...? -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa06542; 8 Nov 96 20:48 EST Received: from nirvana.genesyslab.com by ietf.org id aa06475; 8 Nov 96 20:46 EST Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id RAA13874; Fri, 8 Nov 1996 17:45:41 -0800 (PST) Received: (from egoshin@localhost) by giant.genesyslab.com (8.7.5/8.7.3) id RAA13626; Fri, 8 Nov 1996 17:45:06 -0800 (PST) Date: Fri, 8 Nov 1996 17:45:06 -0800 (PST) Sender:ietf-request@ietf.org From: Leonid Egoshin Message-Id: <199611090145.RAA13626@giant.genesyslab.com> To: JimFleming@unety.net, ietf@ietf.org, lars@anchor.rns.com Subject: RE: US Top Level Domain Cc: newdom@vrx.net Source-Info: From (or Sender) name not authenticated. On Friday, November 08, 1996 5:09 PM, Lars Poulsen[SMTP:lars@anchor.rns.com] wrote: > Someone was suggesting that trademarks form a unique hierachy, > and would be suitable for a TLD. As far as I understand, trademarks > are registered country by country, so if a TM hierachy were > implemented, it would have to be replicated under each national > domain, with a second level for the twenty-some separate market > classifications recognized by the trademark authorities (which I > would expect to have some variations from country to country). > I.e. such a domain would have the form > > ..TRADEMARK.US > IBM.OFFICE-EQUIPMENT.TRADEMARK.US > > Someone else suggested that if BIND was unable to deal with a > humongous flat namespace, BIND should be rewritten to do that > better. I believe that better hierachical structure will benefit > ANY implementation of a DNS server. > If there are the only "twenty-some separate market classifications" then it is simple to implement it in DNS name-servers or in resolver. It is seemed as not very large load on servers. - "Someone" (Leonid Yegoshin, LY22)   Received: from ietf.org by ietf.org id aa26487; 10 Nov 96 7:32 EST Received: from biff.ibm.net.il by ietf.org id aa26072; 10 Nov 96 7:23 EST Received: from rex.ibm.net.il (root@rex.ibm.net.il [192.115.72.138]) by biff.ibm.net.il (8.7.5/8.7.3) with ESMTP id OAA15088 for ; Sun, 10 Nov 1996 14:18:43 +0200 Received: from hank (hank.tlv.ibm.net.il [192.115.72.130]) by rex.ibm.net.il (8.8.2/8.8.2) with SMTP id OAA46819 for ; Sun, 10 Nov 1996 14:22:09 +0200 Message-Id: <2.2.16.19961110142621.0d87b47a@rex.ibm.net.il> X-Sender: hank@rex.ibm.net.il X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Nov 1996 14:26:21 +0000 To: ietf@ietf.org Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: NSI contract Source-Info: From (or Sender) name not authenticated. When does the NSI contract expire? Month and year, please. Thanks, Hank Nussbacher IBM Israel   Received: from ietf.org by ietf.org id aa01255; 10 Nov 96 13:10 EST Received: from merit.edu by ietf.org id aa01169; 10 Nov 96 13:07 EST Received: from LapTop.Simpson.DialUp.Mich.Net (pm036-14.dialip.mich.net [141.211.7.56]) by merit.edu (8.7.6/merit-2.0) with SMTP id NAA12909 for ; Sun, 10 Nov 1996 13:06:37 -0500 (EST) Date: Sun, 10 Nov 96 16:48:06 GMT Sender:ietf-request@ietf.org From: William Allen Simpson Message-ID: <2177.wsimpson@greendragon.com> To: ietf@ietf.org Subject: Re: The cartel begins to crumble? Source-Info: From (or Sender) name not authenticated. > From: Karl Denninger > > In one case, a customer taped his phone conversation with the company > > trying to sell the DN. > > Try that in the US and you may run afoul of CRIMINAL statutes, depending on > the state you're calling from and to. > > It would be a *real* bad idea to attempt to do this in many countries -- the > United States included. > Actually, Karl, although you sometimes raise issues of real importance, in these matters I wish that you would keep to areas of your own expertise. It is perfectly legal virtually anywhere to record phone conversations to which you are a party, or to wear a body microphone to record conversations to which you are a party, or to wire a room which you own to record any conversations that take place. Interstate conversations by necessity do not follow state law, but rather interstate (federal or international) law. But state laws generally follow the federal anyway. There are some instances where US law has stated that for formal legal meetings, you must give all parties advance notice that you might record the meeting. For example, US I.R.C. 7521(a)(1) has come into my life recently. You might have noticed that when you call your local RBOC, you hear a message saying that the conversation might be recorded. That is because the entity doing the recording is _not_ a party to the conversation; instead, it is a third party administrator. It only takes a court order to be admissible as evidence in a court of law, and then only when recording conversations to which you are _NOT_ a party. Otherwise, you can testify as to the accuracy of the recording or transcript the same as if you had taken contemporaneous notes. Next time you raise legal authority, please give us all a true case cite. Thanks.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from ietf.org by ietf.org id aa03024; 10 Nov 96 14:16 EST Received: from Kitten.mcs.com by ietf.org id aa02820; 10 Nov 96 14:14 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id NAA07723; Sun, 10 Nov 1996 13:13:06 -0600 (CST) Received: from Venus.mcs.net (karl@Venus.mcs.com [192.160.127.92]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id NAA02742; Sun, 10 Nov 1996 13:13:05 -0600 (CST) Received: (from karl@localhost) by Venus.mcs.net (8.8.2/8.8.2) id NAA00524; Sun, 10 Nov 1996 13:13:04 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611101913.NAA00524@Venus.mcs.net> Subject: Re: The cartel begins to crumble? To: William Allen Simpson Date: Sun, 10 Nov 1996 13:13:04 -0600 (CST) Cc: ietf@ietf.org In-Reply-To: <2177.wsimpson@greendragon.com> from "William Allen Simpson" at Nov 10, 96 04:48:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > > From: Karl Denninger > > > In one case, a customer taped his phone conversation with the company > > > trying to sell the DN. > > > > Try that in the US and you may run afoul of CRIMINAL statutes, depending on > > the state you're calling from and to. > > > > It would be a *real* bad idea to attempt to do this in many countries -- the > > United States included. > > > Actually, Karl, although you sometimes raise issues of real importance, > in these matters I wish that you would keep to areas of your own > expertise. It is perfectly legal virtually anywhere to record phone > conversations to which you are a party, or to wear a body microphone to > record conversations to which you are a party, or to wire a room which > you own to record any conversations that take place. Not in Illinois. There are specific exceptions, but in *GENERAL* it is illegal to record a telephone conversation in this state. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa03293; 10 Nov 96 14:21 EST Received: from access.netaxs.com by ietf.org id aa03219; 10 Nov 96 14:21 EST Received: from unix1.netaxs.com (cook@unix1.netaxs.com [207.8.186.3]) by access.netaxs.com (8.7.6/8.6.11) with ESMTP id OAA22907; Sun, 10 Nov 1996 14:19:58 -0500 (EST) Received: (from cook@localhost) by unix1.netaxs.com (8.7.6/8.7.3) id OAA00886; Sun, 10 Nov 1996 14:19:54 -0500 (EST) Date: Sun, 10 Nov 1996 14:19:53 -0500 (EST) Sender:ietf-request@ietf.org From: Gordon Cook To: Hank Nussbacher cc: ietf@ietf.org Subject: Re: NSI contract In-Reply-To: <2.2.16.19961110142621.0d87b47a@rex.ibm.net.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Hank asks when the NSI contract ends: The answer is: April 1 1998. But remember that it is a cooperative agreement which means that some of the rules governing it are a bit different than a contract. And remember that the FNC (or was it the FNCAC?) recently expressed the desire that NSF remove itself from involvement with the entire domain name issue. Thus the terminaton of the current five year agreement well in advance of April 1 1998 is not at all impossible. ************************************************************************ The COOK Report on Internet For subsc. pricing & more than 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material (609) 882-2572 (phone & fax) visit http://pobox.com/cook/ Internet: cook@cookreport.com For case study of MercerNet & TIIAP induced harm to local community http://pobox.com/cook/mercernet.html ************************************************************************ On Sun, 10 Nov 1996, Hank Nussbacher wrote: > When does the NSI contract expire? Month and year, please. > > Thanks, > Hank Nussbacher > IBM Israel >   Received: from ietf.org by ietf.org id aa04858; 10 Nov 96 14:55 EST Received: from ns.research.att.com by ietf.org id aa04815; 10 Nov 96 14:55 EST Received: from research.att.com by ns; Sun Nov 10 14:53:05 EST 1996 Received: from raptor.research.att.com by research; Sun Nov 10 14:51:55 EST 1996 Received: from research.att.com (raptor.research.att.com [135.205.49.32]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id OAA03116; Sun, 10 Nov 1996 14:51:54 -0500 (EST) Message-Id: <199611101951.OAA03116@raptor.research.att.com> To: William Allen Simpson cc: ietf@ietf.org Subject: Re: The cartel begins to crumble? Date: Sun, 10 Nov 1996 14:51:54 -0500 Sender:ietf-request@ietf.org From: Steven Bellovin Source-Info: From (or Sender) name not authenticated. Interstate conversations by necessity do not follow state law, but rather interstate (federal or international) law. But state laws generally follow the federal anyway. ... Next time you raise legal authority, please give us all a true case cite. There are number of states where all parties must consent to a conversation being recorded. While I don't have a complete list handy, I know that Pennsylvania is one. Here's a quote from the Pennsylvania Supreme Court case barring Caller-ID in that state: 18 P.S. s 5704 provides: It shall not be unlawful under this chapter for: ... (4) A person to intercept a wire, electronic or oral communication, where all parties to the communication have given prior consent to such interception. As stated by Judge Pellegrini: [W]hen the 1988 amendments were adopted by the General Assembly, they were grafted onto a legislative scheme very different and one that is much more protective of individual rights than federal law. Even though the language of the federal law and 1988 amendments to the Wiretap Act are nearly the same, by not changing the "all party consent rule," it is clear that the General Assembly meant that any part of the communication, including phone number identification, should have the consent of all parties prior to it being trapped and traced. 576 A.2d at 93. I'm quite certain that other states have similar provisions, but I don't have a list handy. For starters, see Section 632 of the California Penal Code: 632. (a) Every person who, intentionally and without the consent of all parties to a confidential communication, by means of any electronic amplifying or recording device, eavesdrops upon or records the confidential communication, whether the communication is carried on among the parties in the presence of one another or by means of a telegraph, telephone, or other device, except a radio, shall be punished ... (from http://www.leginfo.ca.gov/cgi-bin/displaycode?section=pen&group=00001-01000&file=630-637.6) Recordings of conversations with phone companies is covered by 47 CFR 64.501, which specifically requires consent of the othe party. See http://orbus.pls.com:8001/cgi-bin/taos_doc.pl?unix+1+cfr+189723+query+record+conversation+%25BREAK%25+cfr%3a for that one.   Received: from ietf.org by ietf.org id aa05041; 10 Nov 96 14:57 EST Received: from mail1.Reston.mci.net by ietf.org id aa04975; 10 Nov 96 14:55 EST Received: from cerf (infolink-204.189.236.45.Chicago.mci.net) by MAIL1.RESTON.MCI.NET (PMDF V5.0-5 #8388) id <01IBOO2ZTDR4000HB4@MAIL1.RESTON.MCI.NET>; Sun, 10 Nov 1996 15:00:17 -0500 (EST) Date: Sun, 10 Nov 1996 14:55:09 -0500 Sender:ietf-request@ietf.org From: "Vinton G. Cerf" Subject: Re: NSI contract X-Sender: vcerf@166.45.25.52 To: Gordon Cook Cc: Hank Nussbacher , ietf@ietf.org Message-id: <2.2.16.19961110195509.430776ba@166.45.25.52> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 2.2 (16) Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT Source-Info: From (or Sender) name not authenticated. Gordon, I think it was the FNCAC that expressed this view. vint cerf At 02:19 PM 1996/11/10 -0500, Gordon Cook wrote: >Hank asks when the NSI contract ends: The answer is: April 1 1998. >But remember that it is a cooperative agreement which means >that some of the rules governing it are a bit different than a contract. >And remember that the FNC (or was it the FNCAC?) recently expressed the >desire that NSF remove itself from involvement with the entire domain name >issue. Thus the terminaton of the current five year agreement well in >advance of April 1 1998 is not at all impossible. > > >************************************************************************ >The COOK Report on Internet For subsc. pricing & more than >431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material >(609) 882-2572 (phone & fax) visit http://pobox.com/cook/ >Internet: cook@cookreport.com For case study of MercerNet & >TIIAP induced harm to local community http://pobox.com/cook/mercernet.html >************************************************************************ > >   Received: from ietf.org by ietf.org id aa08253; 10 Nov 96 16:07 EST Received: from luggage.tecc.co.uk by ietf.org id aa08164; 10 Nov 96 16:05 EST Received: from auntie.bbcnc.org.uk by luggage.tecc.co.uk id aa25692; 10 Nov 96 20:53 GMT To: Steven Bellovin cc: William Allen Simpson , ietf@ietf.org Subject: Re: The cartel begins to crumble? In-reply-to: Your message of "Sun, 10 Nov 1996 14:51:54 EST." <199611101951.OAA03116@raptor.research.att.com> Date: Sun, 10 Nov 1996 20:53:49 +0000 Sender:ietf-request@ietf.org From: Gordon Joly Message-ID: <9611102053.aa25692@luggage.tecc.co.uk> Source-Info: From (or Sender) name not authenticated. >> There are number of states where all parties must consent to a >> conversation being recorded. Shall I check what happens in the "state" of the UK? And European Union? -- Gordon Joly http://pobox.com/~gjoly/ gordon.joly@pobox.com   Received: from ietf.org by ietf.org id aa10824; 10 Nov 96 18:26 EST Received: from WLV.IIPO.GTEGSC.COM by ietf.org id aa10731; 10 Nov 96 18:23 EST Received: from SPIELZEUG.IIPO.GTEGSC.COM (SPIELZEUG.IIPO.GTEGSC.COM [199.107.242.241]) by wlv.iipo.gtegsc.com (8.8.2/8.7.3) with SMTP id PAA10986; Sun, 10 Nov 1996 15:09:28 -0800 (PST) Sender:ietf-request@ietf.org From: Merton Campbell Crockett Message-Id: <961110150854.ZM12734@SPIELZEUG.IIPO.GTEGSC.COM> Date: Sun, 10 Nov 1996 15:08:45 -0700 In-Reply-To: Gordon Joly "Re: The cartel begins to crumble?" (Nov 10, 20:53) References: <9611102053.aa25692@luggage.tecc.co.uk> X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996) To: Gordon Joly , Steven Bellovin Subject: Re: The cartel begins to crumble? Cc: William Allen Simpson , ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Source-Info: From (or Sender) name not authenticated. On Nov 10, 20:53, Gordon Joly wrote: > Subject: Re: The cartel begins to crumble? } } }>> There are number of states where all parties must consent to a }>> conversation being recorded. } }Shall I check what happens in the "state" of the UK? And European }Union? I thought that the United Kingdom of Great Britain and Northern Ireland was still independent. ;-) The "states" would be England Scotland Wales Northern Ireland I'm a little rusty but I think the Channel Islands do have the following states. Jersey Guernsey Alderney Sark And, then we have the Isle of Man that doesn't have any states. It, also, isn't a member of the European Union as are the United Kingdom and the Channel Islands. Could you give us a run down for each of the above? Merton Campbell Crockett   Received: from ietf.org by ietf.org id aa11242; 10 Nov 96 18:33 EST Received: from [207.32.130.1] by ietf.org id aa11151; 10 Nov 96 18:32 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id RAA09483 for ; Sun, 10 Nov 1996 17:26:18 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCF2C.9199B160@webster.unety.net>; Sun, 10 Nov 1996 17:28:21 -0600 Message-ID: <01BBCF2C.9199B160@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "'ietf@ietf.org'" Subject: Taxing Domain Name Servers Date: Sun, 10 Nov 1996 17:28:19 -0600 Encoding: 143 TEXT Source-Info: From (or Sender) name not authenticated. TAXING DOMAIN NAME SERVERS or "Think Globally and Act Locally"... Now that the elections are over in the U.S. It appears that some governments and local areas are quickly beginning to see the light, that the Internet is a potential source of tax revenue. This could also be a result of the windfall profits being reaped by Network Solutions, Inc. and their owner, SAIC, from its "cooperative agreement" with the National Science Foundation (NSF) which is largely funded by the U.S. Government. State governments and local communities are beginning to see that "tax-like" dollars for domain registrations are being sent to Virginia from all around the world. As usual, the Washington, D.C. area economy is the beneficiary and states get little in return. In the past, people would claim that free registrations in the US. domain allowed people an alternative, and these "Internet Taxes" were not a concern. The US. domain is no longer totally free. Companies are being delegated city's names and in some cases they are sending invoices without the registrants' prior approval. To make matters worse, some of these companies are not operating in the state where the city is located. This raises questions about business licensing, registrations and interstate commerce. Even though U.S. Internet users are constantly being told that they should "think globally" and avoid U.S.-centric views, when the rubber hits the road, Internet Politicians "act locally" to protect their own interests. This is no different than what has been happening for centuries, all around the world, with government politicians. As government politicians begin to see the "taxation" patterns and revenue flows, there is little doubt that they will become interested in mapping the Internet to existing rules and regulations. One of the easiest ways to do this is via the domain registration system. Because of all of the discussions about new top level domains and domain registries, people are becoming more educated about the technology and the flexibility of the systems. Many people have been mislead that the system is rigid and "Internet Taxes" must be paid to those that maintain the system and no one else can participate. This is clearly not the case. One of the keys to controlling the Internet domain system rests with the root name servers. Internet Service Providers use these root name servers to help their subscribers locate web sites and e-mail destinations. If ISPs are "encouraged", via legislation or regulation, to use state supplied (or supported) root name servers, the state can insert itself into the domain name look-up flow, with very little effort, and can bring "Internet Tax" dollars back to the state (or community) where the commerce is originating. The arrangement would be very simple, the state would provide a small collection of root name servers and delegate all of the top level domains to registries located in that state. The major top level domains such as .COM, .NET, and .ORG could be easily operated by local agencies under "cooperative agreements" with the state. Those agreements could be made with ISPs in the state who cooperate with the plan. With such an arrangement, companies currently registered in the .COM domain would have to register in each state (or region) where they wanted to "easily" do business. They could start with a "federal registration" as they do today and then reproduce that in each state. Fifty states at $50/year could cost a company $2,500. At a more realistic cost of $10/state, these fees could be brought into line with other corporate filing fees currently levied by states. To discourage changes, a fee could be charged for any transaction, just as most states do today. This process is nothing new to corporations who must register as a "foreign corporation" in all the states where they have operations. (Since people could always bypass the domain name system by using an IP address people could still reach a company, the hard way). The registration fees could help to fund Internet infrastructure in that state and would not have to be sent to a Washington, D.C. suburb. Also, the technical burden on the companies would not be high because all states could direct their .COM name servers to the same corporate name servers now supplied by the company (unless the company wanted a different DNS data base for a different region of the country). While it would be nice to think that everyone is going to "think globally" and "act globally" it is clear that this is not the case. Pandora's box was opened when the NSF allowed for "Internet Taxes" to be levied without representation. Those taxes have been enjoyed by a select group of individuals who keep telling everyone that there are no other solutions. Many people have witnessed the bitter battles over the domain name system and the positioning for revenue opportunities and windfall profits. These battles are just getting started. The next round of top level domain expansion is likely to attract large corporate players and it appears that the Internet Politicians are more willing to turn things over to big money, than the local communities. One solution available to local politicians is to take that global NSF action and apply it at a local level. They can now "think globally" and "act locally" and keep those tax dollars in their community. With a small change for ISPs, and some minor investment in infrastructure, a state can insert itself into the domain name system and follow the model established by the Internet Politicians. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa13371; 10 Nov 96 19:36 EST Received: from ivory.educom.edu by ietf.org id aa13285; 10 Nov 96 19:32 EST Received: by ivory.educom.edu (8.6.12/1.34 (CREN)) id TAA02557; Sun, 10 Nov 1996 19:31:40 -0500 Message-Id: <199611110031.TAA02557@ivory.educom.edu> Subject: Re: NSI contract To: Gordon Cook Date: Sun, 10 Nov 1996 19:31:39 -0500 (EST) Sender:ietf-request@ietf.org From: Mike Roberts Cc: hank@ibm.net.il, ietf@ietf.org In-Reply-To: from "Gordon Cook" at Nov 10, 96 02:19:53 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1753 Source-Info: From (or Sender) name not authenticated. Gordon - That's not quite an accurate view of the FNCAC discussion. The motion we passed expressed the strong desire that the FNC work hard NOW to develop a sound future foundation for the domain name system when the NSI agreement ends in less than 18 months, and further, that an "appropriate entity" be identified to hold responsibility for those parts of the DNS that are found to require permanent stewardship, ie not to be handed over for dissection by the greedy private sector types that lust after the alleged NSI monopoly profits. - M. > > Hank asks when the NSI contract ends: The answer is: April 1 1998. > But remember that it is a cooperative agreement which means > that some of the rules governing it are a bit different than a contract. > And remember that the FNC (or was it the FNCAC?) recently expressed the > desire that NSF remove itself from involvement with the entire domain name > issue. Thus the terminaton of the current five year agreement well in > advance of April 1 1998 is not at all impossible. > > > ************************************************************************ > The COOK Report on Internet For subsc. pricing & more than > 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material > (609) 882-2572 (phone & fax) visit http://pobox.com/cook/ > Internet: cook@cookreport.com For case study of MercerNet & > TIIAP induced harm to local community http://pobox.com/cook/mercernet.html > ************************************************************************ > > > On Sun, 10 Nov 1996, Hank Nussbacher wrote: > > > When does the NSI contract expire? Month and year, please. > > > > Thanks, > > Hank Nussbacher > > IBM Israel > > > >   Received: from ietf.org by ietf.org id aa16048; 10 Nov 96 20:30 EST Received: from [207.32.130.1] by ietf.org id aa15971; 10 Nov 96 20:28 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id TAA09689; Sun, 10 Nov 1996 19:21:18 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCF3C.A26D9AA0@webster.unety.net>; Sun, 10 Nov 1996 19:23:21 -0600 Message-ID: <01BBCF3C.A26D9AA0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: Gordon Cook , 'Mike Roberts' Cc: "hank@ibm.net.il" , "ietf@ietf.org" Subject: RE: NSI contract Date: Sun, 10 Nov 1996 19:23:19 -0600 Encoding: 60 TEXT Source-Info: From (or Sender) name not authenticated. On Sunday, November 10, 1996 1:31 PM, Mike Roberts[SMTP:roberts@ivory.educom.edu] wrote: @ Gordon - That's not quite an accurate view of the FNCAC discussion. @ @ The motion we passed expressed the strong desire that the FNC @ work hard NOW to develop a sound future foundation for the @ domain name system when the NSI agreement ends in less than @ 18 months, and further, that an "appropriate entity" be @ identified to hold responsibility for those parts of the @ DNS that are found to require permanent stewardship, ie not @ to be handed over for dissection by the greedy private sector @ types that lust after the alleged NSI monopoly profits. @ @ - M. @ @ > @ > Hank asks when the NSI contract ends: The answer is: April 1 1998. @ > But remember that it is a cooperative agreement which means @ > that some of the rules governing it are a bit different than a contract. @ > And remember that the FNC (or was it the FNCAC?) recently expressed the @ > desire that NSF remove itself from involvement with the entire domain name @ > issue. Thus the terminaton of the current five year agreement well in @ > advance of April 1 1998 is not at all impossible. @ > @ > @ > @ > On Sun, 10 Nov 1996, Hank Nussbacher wrote: @ > @ > > When does the NSI contract expire? Month and year, please. @ > > @ > > Thanks, @ > > Hank Nussbacher @ > > IBM Israel @ > > @ > @ > Mike, Since you refer to NSI's profits as "alleged NSI monopoly profits", I assume that you are implying one of the following.... 1. There are no profits. 2. They are not "monopoly" profits (in your opinion). 3. They are SAIC's profits, not NSI's. 4. They are alleged because no one knows what the true story is because there is no public disclosure. For some of these options, you have to have information on the financials. Can you disclose that information ? -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa25298; 10 Nov 96 23:37 EST Received: from cnri by ietf.org id aa25126; 10 Nov 96 23:33 EST Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa00571; 10 Nov 96 23:33 EST Received: by gw.home.vix.com id UAA20300; Sun, 10 Nov 1996 20:32:05 -0800 (PST) Date: Sun, 10 Nov 1996 20:32:05 -0800 (PST) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ietf@CNRI.Reston.VA.US Sender:ietf-request@ietf.org From: Paul A Vixie Subject: Re: Why More TLDs Organization: Vixie Enterprises Message-ID: References: <55uoo8$3d2@anchor.rns.com> NNTP-Posting-Host: wisdom.home.vix.com In-reply-to: lars@anchor.rns.com's message of 8 Nov 1996 00:22:46 -0800 Xref: vixie local.mail.net.ietf:6629 Source-Info: From (or Sender) name not authenticated. The simple answer to "why more TLD's?" is that 100% of the users on the Internet as of this date are abusing DNS as a directory service, and since DNS somewhat predictably does not work well as a directory service these people are trying to solve a "wrong technology" problem with a "more data" solution. It won't work but like lemmings to the sea, we just gotta do it. Consider those rasty little ISO layers and which one(s?) hold any hope of being used as a directory service: L1 identifiers (circuit ID's, registered cross connects) change during the lifetime of their consumer and provider, and are meaningless outside of the cable plant other than for billing. L2 identifiers (mac-level addresses like ethernet or E.164) also change during the lifetime of their consumer and provider, and are meaningless to anyone not connected to a particular L2 wire/hub/cloud. L3 identifiers (IP addresses) change every time a new provider is chosen, even though the web/mail/whatever server/client is still the same entity doing the same things they did before the change. L4 identifiers ( tuples) change every time a connection is made and so using them as locators is an anticoncept. Clearly we're not going to see any of those used on movie posters in a URL that tells folks how to buy stuffed dolls representing story characters. Right now we use domain names, since they are universally unique, and they are permanent. They are not, however, guessable. Sure, I can find *something* if I ask for http://WWW.PIZZA.COM/ but it's not likely that I can find my local pizza shop that way. I can try Alta Vista or Yahoo, but it's going to be hard to find my local pizza shop that way, too. Therefore I use the telephone company's directory service ("can you give me the number for Lucia's Pizza in Woodside?") and then I use the telephone to call and get their URL so I can use HTTPS to order my pizza online. Then I keep it as a bookmark. Which is OK until I have 2,000 such bookmarks and I need to spend an hour per week cataloguing them. (As it happens, PIZZA.COM is held by IIS, a domain name speculator. I digress.) What I need and what the other 98% of Internet users who have not yet signed on need, is a way to say "does lucia's pizza in woodside have a URL?" and get something useful -- an authoritative "no" or a short/accurate list of possible "yes"'s. Asking Lucia's of Woodside to register as lucias.woodside.ca.us.pizza.com is one possible answer but does it scale to automotive transmission shops? Do I look under Automotive or do I look under Transmission? Keep in mind that a true directory service allows some fuzz in the lookups, but DNS does not. So I suppose we had better allocate .PIZZA but I don't think it will solve the real problem. Lucia's Pizza of Woodside probably could live happily with lucias.woodside.ca.us even though a lot of folks think they are in Redwood City since they are actually closer to it. The domain name that would work for them (lucias.woodside.ca.us) says nothing about their business and it's not particularly guessable -- but it excells at what DNS provides, which is universal uniqueness and permanence. The current TLD's were chosen by programmers rather than librarians. If you look at the average programmer's choice of file names and variable names and what not, you will see that programmers ought not, usually, be allowed to pick names -- especially names that have to map to real world objects. What we *need* in DNS is to close the current TLD's to new registrations, get a bunch of librarians together and let them hammer out a new schema that will provide better splay (.COM is too flat), get leverage out of universal uniqueness and permanence, and publically sacrifice (stake through the heart) any possible guessability. And then we need an actual, real live directory service that works as well as the one the telephone companies provide now. What we'll *get* is .PIZZA and a zillion other attempts to meet the nongoal of guessability. Any questions? (See ftp://ftp.vix.com/pri/vixie/dns-badnames.psf.gz for answers.) -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul   Received: from ietf.org by ietf.org id aa01980; 11 Nov 96 7:27 EST Received: from cnri by ietf.org id aa01771; 11 Nov 96 7:23 EST Received: from ng.netgate.net by CNRI.Reston.VA.US id aa00959; 11 Nov 96 7:23 EST Received: from [204.179.131.85] (mg131-085.ricochet.net [204.179.131.85]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id VAA09708; Sun, 10 Nov 1996 21:58:04 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: References: lars@anchor.rns.com's message of 8 Nov 1996 00:22:46 -0800 <55uoo8$3d2@anchor.rns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Nov 1996 21:46:46 -0800 To: Paul A Vixie Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: Why More TLDs Cc: ietf@CNRI.Reston.VA.US Source-Info: From (or Sender) name not authenticated. At 8:32 PM -0800 11/10/96, Paul A Vixie wrote: >Right now we use domain names, since they are universally unique, and they >are permanent. They are not, however, guessable. to emphasize for thos who may miss this point: guessability is the core characteristic of a 'directory' versus the completely deterministic behaviors of a mapping service like the dns. The difference between =46INDING a name (and associated information) based on various criteria, possibly including the name, versus USING the name to find only and exactly the information associated with it is technically quite different tasks. >Asking Lucia's of Woodside to register as lucias.woodside.ca.us.pizza.com i= s >one possible answer but does it scale to automotive transmission shops? Do Paul probably knows this, but to be clear, we need to make sure that there is a general appreciation that this approach is doomed. The scheme fits within the classic model of hierarchical (tree structured) data base systems and they simply are not flexible enough for the undisciplined range of queries that will come into a public Internet data base. Whatever scheme you put lucias under, there will be others that some folks will look for -- and not find. >What we *need* in DNS is to close the current TLD's to new registrations, I personally question the viability of this. It is, perhaps, yet another example of the technicians approach. We find it comforting to fix a problem by simply moving everyone off the field of battle and put them somewhere more comfortable. Nice work if you can get it. Also there is, I think, another factor at work. Domain Names are a good idea not only because they can permit a degree of guessability -- a degree; one that does not scale. Rather, they also have a general mnemonic quality and some information redundancy. They tend to be easy to remember and mistyping one usually causes a failure rather than misdelivery. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa03152; 11 Nov 96 8:06 EST Received: from cnri by ietf.org id aa03063; 11 Nov 96 8:04 EST Received: from host02.net.voyager.co.nz by CNRI.Reston.VA.US id aa02112; 11 Nov 96 8:04 EST Received: from [203.21.27.148] (ts1p12.net.hamilton.voyager.co.nz [203.21.27.148]) by host02.net.voyager.co.nz (8.7.4/8.6.12) with SMTP id VAA09283 for ; Mon, 11 Nov 1996 21:23:06 +1300 (NZDT) Date: Mon, 11 Nov 1996 21:23:06 +1300 (NZDT) Message-Id: <199611110823.VAA09283@host02.net.voyager.co.nz> Subject: PLEASE TAKE ME OFF THIS LIST !!!!!!!! Sender:ietf-request@ietf.org From: jotham To: "ietf@CNRI.Reston.VA.US" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Source-Info: From (or Sender) name not authenticated. PLEASE TAKE ME OFF THIS LIST !!!!!!!! thanks !!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jotham Read Graphic Artist and Web Designer Email: jotham@voyager.co.nz Phone: 07) 5520066 Web: Http://www.voyager.co.nz/~jotham/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~   Received: from ietf.org by ietf.org id aa03385; 11 Nov 96 8:08 EST Received: from cnri by ietf.org id aa03183; 11 Nov 96 8:07 EST Received: from fxiod04.is.chrysler.com by CNRI.Reston.VA.US id aa02188; 11 Nov 96 8:07 EST Received: by fxiod04.is.chrysler.com; id AA29604; Mon, 11 Nov 96 07:01:43 EST Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod04.is.chrysler.com via smap (V3.1.1) id xma029601; Mon, 11 Nov 96 07:01:14 -0500 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id GAA09275; Mon, 11 Nov 1996 06:50:28 -0500 (EST) Message-Id: <3.0b36.32.19961111065239.009eee60@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Mon, 11 Nov 1996 07:01:05 -0500 To: Paul A Vixie , ietf@CNRI.Reston.VA.US Sender:ietf-request@ietf.org From: Robert Moskowitz Subject: Re: Why More TLDs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. At 08:32 PM 11/10/96 -0800, Paul A Vixie wrote: Paul, this is an excellent exposition. One of the best I've seen you supply on a subject that you are so close to for so long. I hope that the techno and business dweeps here can truely understand your meaning. So, should we appeal to Joyce to get her crew in gear? I really think you have done an excellent job of pointing out where the work on DNS really has to move to. Not to operations and business, but to users and librarians. Only after that can ops have it. >The simple answer to "why more TLD's?" is that 100% of the users on the >Internet as of this date are abusing DNS as a directory service, and since >DNS somewhat predictably does not work well as a directory service these >people are trying to solve a "wrong technology" problem with a "more data" >solution. It won't work but like lemmings to the sea, we just gotta do it. > >Consider those rasty little ISO layers and which one(s?) hold any hope of >being used as a directory service: > >L1 identifiers (circuit ID's, registered cross connects) change during the > lifetime of their consumer and provider, and are meaningless outside > of the cable plant other than for billing. > >L2 identifiers (mac-level addresses like ethernet or E.164) also change during > the lifetime of their consumer and provider, and are meaningless to > anyone not connected to a particular L2 wire/hub/cloud. > >L3 identifiers (IP addresses) change every time a new provider is chosen, even > though the web/mail/whatever server/client is still the same entity > doing the same things they did before the change. > >L4 identifiers ( tuples) change every time > a connection is made and so using them as locators is an anticoncept. > >Clearly we're not going to see any of those used on movie posters in a URL >that tells folks how to buy stuffed dolls representing story characters. > >Right now we use domain names, since they are universally unique, and they >are permanent. They are not, however, guessable. > >Sure, I can find *something* if I ask for http://WWW.PIZZA.COM/ but it's not >likely that I can find my local pizza shop that way. I can try Alta Vista >or Yahoo, but it's going to be hard to find my local pizza shop that way, too. >Therefore I use the telephone company's directory service ("can you give me >the number for Lucia's Pizza in Woodside?") and then I use the telephone to >call and get their URL so I can use HTTPS to order my pizza online. Then I >keep it as a bookmark. Which is OK until I have 2,000 such bookmarks and I >need to spend an hour per week cataloguing them. > >(As it happens, PIZZA.COM is held by IIS, a domain name speculator. I digress.) > >What I need and what the other 98% of Internet users who have not yet signed >on need, is a way to say "does lucia's pizza in woodside have a URL?" and get >something useful -- an authoritative "no" or a short/accurate list of possible >"yes"'s. > >Asking Lucia's of Woodside to register as lucias.woodside.ca.us.pizza.com is >one possible answer but does it scale to automotive transmission shops? Do >I look under Automotive or do I look under Transmission? Keep in mind that >a true directory service allows some fuzz in the lookups, but DNS does not. > >So I suppose we had better allocate .PIZZA but I don't think it will solve >the real problem. Lucia's Pizza of Woodside probably could live happily >with lucias.woodside.ca.us even though a lot of folks think they are in >Redwood City since they are actually closer to it. The domain name that >would work for them (lucias.woodside.ca.us) says nothing about their business >and it's not particularly guessable -- but it excells at what DNS provides, >which is universal uniqueness and permanence. > >The current TLD's were chosen by programmers rather than librarians. If you >look at the average programmer's choice of file names and variable names and >what not, you will see that programmers ought not, usually, be allowed to >pick names -- especially names that have to map to real world objects. > >What we *need* in DNS is to close the current TLD's to new registrations, >get a bunch of librarians together and let them hammer out a new schema that >will provide better splay (.COM is too flat), get leverage out of universal >uniqueness and permanence, and publically sacrifice (stake through the heart) >any possible guessability. And then we need an actual, real live directory >service that works as well as the one the telephone companies provide now. > >What we'll *get* is .PIZZA and a zillion other attempts to meet the nongoal >of guessability. > >Any questions? > >(See ftp://ftp.vix.com/pri/vixie/dns-badnames.psf.gz for answers.) >-- >Paul Vixie >La Honda, CA "Illegitimibus non carborundum." > >pacbell!vixie!paul > > Robert Moskowitz Chrysler Corporation (810) 758-8212   Received: from ietf.org by ietf.org id aa05341; 11 Nov 96 8:48 EST Received: from cnri by ietf.org id aa05256; 11 Nov 96 8:46 EST Received: from [207.32.130.1] by CNRI.Reston.VA.US id aa03066; 11 Nov 96 8:46 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id HAA11730; Mon, 11 Nov 1996 07:40:09 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBCFA3.DA8838C0@webster.unety.net>; Mon, 11 Nov 1996 07:42:13 -0600 Message-ID: <01BBCFA3.DA8838C0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "ietf@CNRI.Reston.VA.US" , 'Paul A Vixie' Cc: 'New Newdom' Subject: RE: Why More TLDs Date: Mon, 11 Nov 1996 07:42:12 -0600 Encoding: 50 TEXT Source-Info: From (or Sender) name not authenticated. On Sunday, November 10, 1996 2:32 PM, Paul A Vixie[SMTP:paul@vix.com] wrote: @ The simple answer to "why more TLD's?" is that 100% of the users on the @ Internet as of this date are abusing DNS as a directory service, and since @ DNS somewhat predictably does not work well as a directory service these @ people are trying to solve a "wrong technology" problem with a "more data" @ solution. It won't work but like lemmings to the sea, we just gotta do it. @ @ @ Sure, I can find *something* if I ask for http://WWW.PIZZA.COM/ but it's not @ likely that I can find my local pizza shop that way. I can try Alta Vista @ or Yahoo, but it's going to be hard to find my local pizza shop that way, too. @ Therefore I use the telephone company's directory service ("can you give me @ the number for Lucia's Pizza in Woodside?") and then I use the telephone to @ call and get their URL so I can use HTTPS to order my pizza online. Then I @ keep it as a bookmark. Which is OK until I have 2,000 such bookmarks and I @ need to spend an hour per week cataloguing them. @ Paul, Rather than shift directory services to the DNS, you could also consider an alternative... You could become the webmaster for Woodside, California and help others place your "hot links" on... ...this will allow you to dynamically build a community directory, using descriptive categories and names. Once people discover the value of these types of directories, then the pressure will shift from using the DNS. P.S. Comm.unety.net was featured in the Chicago Tribune's Digital City project.... ...don't miss..."Pizza a slice of Naperville life."...:-) -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa07200; 11 Nov 96 9:37 EST Received: from ietf.org by ietf.org id aa07103; 11 Nov 96 9:35 EST To: ietf@ietf.org Subject: CFP: Interactive Distributed Multimedia Systems & Telecomm. Services Sender:ietf-request@ietf.org From: Lars Wolf Date: Mon, 11 Nov 1996 09:35:22 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611110935.aa07103@ietf.org> Source-Info: From (or Sender) name not authenticated. Dear Colleague, please find enclosed a Call for Papers for IDMS'97 to be held September 10-12, 1997 in Darmstadt, Germany. Apologies for duplicates you may receive through multiple mailing lists. Best regards, Lars CALL FOR PAPERS European Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services (IDMS'97) 10. - 12. September 1997 Darmstadt, Germany In Cooperation with ACM SIGMM Gesellschaft fuer Informatik GMD IEEE Computer Society VDE ITG This Fourth International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services follows the successful IDMS workshop held 1996 in Berlin. The purpose of this workshop is to provide a forum for the presentation, exploration and discussion of technologies and their advancements in the broad field of interactive distributed multimedia systems -- from basic system technologies such as networking and operating system support to all kinds of multimedia applications. Furthermore, we are also looking for work from related areas, including digital library, mobile communication, VR, and software agents. Case studies and papers describing experimental work are especially welcome. Relevant topics include, but are not limited to * High-speed and multimedia networks * ATM networks and applications * Mobile multimedia systems * Multimedia communication protocols * Compression algorithms * Quality of service and media scaling * Resource management * Multimedia operating systems * Synchronization * Multimedia database and storage * Video-on-demand systems, components and architectures * Multimedia programming languages, abstractions & APIs * Development tools for distributed multimedia applications * Multimedia-specific intelligent agents * Multimedia/hypermedia applications and tools, production and authoring * Conferencing * Computer supported collaborative work * Digital libraries * Interactive television * Virtual reality systems IDMS'97 will consist of one day of tutorials and two days of technical presentations in an envisaged single-track. System and tool demonstrations will be possible throughout the workshop. In order to keep the flavor of a "workshop", participation will be restricted to about 100 participants. The proceedings of the workshop will be published in the Springer LNCS series and will be available during the workshop. Selected papers will be forwarded to a special issue of the "Computer Communications" Journal. Information for Authors ======================= The working language of the workshop is English. The submission process of papers will be handled electronically. Detailed description of the electronic submission procedures are available in the IDMS'97 web page http://www.th-darmstadt.de/idms97/ Authors without web access may send mail to idms97@KOM.th-darmstadt.de requesting electronic submission information. Authors unable to submit electronically are invited to send 5 copies of their full paper to the program chair: Lars C. Wolf Dept. of Electrical Engineering & Information Technology Darmstadt University of Technology Merckstr. 25, D-64283 Darmstadt, Germany Manuscripts ----------- Submitted manuscripts must describe original work (not submitted or published elsewhere). The manuscripts must be no longer than 5000 words (including references, tables, etc.), be typed double-spaced, contain an abstract of approximately 300 words, and include title, authors and affiliations. The author who serves as contact person must be marked appropriately. Panels ------ Suggestions for panels which present innovative, controversial, or otherwise interesting ideas are welcome. Send a panel proposal of at most 3 pages including a biographical sketch of the panelist to the general chair. Important Dates =============== Submissions due: 01. March 1997 Notification of acceptance: 15. May 1997 Camera-ready version due: 15. June 1997 General Chair ============= Ralf Steinmetz, Darmstadt U., Germany Email: Ralf.Steinmetz@KOM.th-darmstadt.de Dept. of Electrical Engineering and Information Technology Darmstadt University of Technology Merckstr. 25, D-64283 Darmstadt, Germany Fax: +49 6151 166152 Program Committee ================= B. Butscher, DeTeBerkom, Germany A. Danthine, U. Liege, Belgium L. Delgrossi, Andersen Consulting, France J. Eberspaecher, TU Munich, Germany W. Effelsberg, U. Mannheim, Germany J. Encarnacao, FhG-IGD, Germany D. Ferrari, U. Cattolica, Italy B. Furht, Florida Atlantic U., USA N. Georganas, U. Ottawa, Canada R.G. Herrtwich, RWE, Germany A. Hopper, U. Cambridge / ORL, UK J.P. Hubaux, EPFL, Switzerland D. Hutchison, Lancaster U., UK Y. Ip, Siemens AG, Germany W. Kalfa, TU Chemnitz, Germany T.D.C. Little, Boston U., USA F. Mattern, Darmstadt U., Germany E. Moeller, GMD FOKUS, Germany K. Nahrstedt, U. Illinois, USA E. Neuhold, GMD IPSI, Germany S. Pink, SICS, Sweden R. Popescu-Zeletin, TU Berlin, Germany V. Rangan, U. California, USA K. Rothermel, U. Stuttgart, Germany J. Schweitzer, Siemens AG, Germany J. Schweitzer, Siemens AG, Germany H. Tokuda, Keio U., Japan F. Williams, Ericsson, Germany L. Wolf, Darmstadt U., Germany (Chair) General Information =================== For program information contact the Program Chair. For additional information see World-Wide Web: http://www.th-darmstadt.de/idms97 Local Organization ================== For any details on transportation, accomodation, or any other local arrangements please contact Martin Karsten Email: Martin.Karsten@KOM.th-darmstadt.de (same address as general chair) ------------------------------------------------------------------------------ Dr.-Ing. Lars C. Wolf Email: Lars.Wolf@KOM.th-darmstadt.de Industrial Process&System Communication http://www.th-darmstadt.de/fb/et/ipsk Dept. Electr. Eng.&Information Techn. Tel.: +49-6151-16-6155 (Fax -6152) Darmstadt University of Technology, Merckstr. 25, D-64283 Darmstadt, Germany   Received: from ietf.org by ietf.org id aa08163; 11 Nov 96 9:54 EST Received: from cnri by ietf.org id aa07944; 11 Nov 96 9:52 EST Received: from mailer1.lut.ac.uk by CNRI.Reston.VA.US id aa04800; 11 Nov 96 9:52 EST Received: from sun-cc201.lboro.ac.uk [158.125.1.201] (root) by mailer1.lut.ac.uk with smtp (Exim 0.56 #2) id E0vMxhz-00004p-00; Mon, 11 Nov 1996 14:51:31 +0000 Received: from comth by sun-cc201.lboro.ac.uk with smtp (Exim 0.56 #2) id E0vMxho-0002yw-00; Mon, 11 Nov 1996 14:51:20 +0000 Date: Mon, 11 Nov 1996 14:51:20 +0000 (GMT) Sender:ietf-request@ietf.org From: martin hamilton X-Sender: comth@sun-cc201 To: ietf@CNRI.Reston.VA.US Subject: Re: Why More TLDs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Sun, 10 Nov 1996, Dave Crocker wrote: > At 8:32 PM -0800 11/10/96, Paul A Vixie wrote: > >Right now we use domain names, since they are universally unique, and they > >are permanent. They are not, however, guessable. > > to emphasize for thos who may miss this point: guessability is the > core characteristic of a 'directory' versus the completely deterministic > behaviors of a mapping service like the dns. The difference between > FINDING a name (and associated information) based on various criteria, > possibly including the name, versus USING the name to find only and > exactly the information associated with it is technically quite different > tasks. If anyone is interested in doing a little bit of practical experimentation on the FINDING front, I'd like to volunteer a mailing list over here which has been created for this purpose. Mail "deploy-request@mrrl.lut.ac.uk", with the word "subscribe" on its own in the message body, if you want to participate. Recommended reading... RFCs 1714, 1777, 1798, 1835, 1913 and 1914, plus draft-klensin-tld-whois-00.txt, and draft-ietf-find-new-cip-00.txt Cheerio, Martin   Received: from ietf.org by ietf.org id aa08526; 11 Nov 96 9:56 EST Received: from cnri by ietf.org id aa08303; 11 Nov 96 9:55 EST Received: from WLV.IIPO.GTEGSC.COM by CNRI.Reston.VA.US id aa04961; 11 Nov 96 9:55 EST Received: from SPIELZEUG.IIPO.GTEGSC.COM (SPIELZEUG.IIPO.GTEGSC.COM [199.107.242.241]) by wlv.iipo.gtegsc.com (8.8.2/8.7.3) with SMTP id GAA25303; Mon, 11 Nov 1996 06:46:09 -0800 (PST) Sender:ietf-request@ietf.org From: Merton Campbell Crockett Message-Id: <961111064536.ZM13502@SPIELZEUG.IIPO.GTEGSC.COM> Date: Mon, 11 Nov 1996 06:44:56 -0700 In-Reply-To: Dave Crocker "Re: Why More TLDs" (Nov 10, 21:46) References: lars@anchor.rns.com's message of 8 Nov 1996 00:22:46 -0800 <55uoo8$3d2@anchor.rns.com> X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996) To: Dave Crocker , Paul A Vixie Subject: Re: Why More TLDs Cc: ietf@CNRI.Reston.VA.US Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Source-Info: From (or Sender) name not authenticated. On Nov 10, 21:46, Dave Crocker wrote: > Subject: Re: Why More TLDs }At 8:32 PM -0800 11/10/96, Paul A Vixie wrote: }>Right now we use domain names, since they are universally unique, and they }>are permanent. They are not, however, guessable. } } to emphasize for thos who may miss this point: guessability is the }core characteristic of a 'directory' versus the completely deterministic }behaviors of a mapping service like the dns. The difference between }FINDING a name (and associated information) based on various criteria, }possibly including the name, versus USING the name to find only and }exactly the information associated with it is technically quite different }tasks. We do have a rudimentary directory service: (r)whois. What is missing from the mass-market Internet Software is a glitzy user interface and a discussion of why and when it should be used. Using whois, one finds that BNONLINE.COM belongs to Barnes & Noble and ORA.COM to O'Reilly & Associates. Good places to start looking for a Web Page listing their available publications. What we find, however, is the typical user with his Web browser open banging away at the DNS trying different permutations of WWW.something.COM that might lead him to where he wants to go. And, of course, he is conducting his search using a product name instead of a manufacturer's name because he doesn't have the Thomas Register sitting next to his computer. As a result, we have the typical manufacturer trying to get registered under .COM using his corporate name and each of his trademarked product names. Increasing the number of TLDs is a "stop-gap" measure and not necessarily a solution. If I know that O'Reilly & Associates uses ORA, the question is now where do I find them? ORA.COM ORA.LTD ORA.PTY ORA.CIE ORA.GMBH ORA.CORP ORA.AB ORA.AG ORA.xx.CA.US Increasing the number of TLDs does allow us to eliminate some obscurity in names but does not relieve the pressure on the DNS. Assuming that there is a WWW.VOLVO.COM, what incentive is there for Volvo to switch to WWW.VOLVO.AB? Merton Campbell Crockett Hasenthaler InfoSysteme   Received: from ietf.org by ietf.org id aa12683; 11 Nov 96 11:34 EST Received: from mail.border.com by ietf.org id aa12541; 11 Nov 96 11:30 EST Received: by janus.border.com id <18460-2>; Mon, 11 Nov 1996 11:27:19 -0500 Message-Id: <96Nov11.112719est.18460-2@janus.border.com> To: Skip Addison cc: egoshin@genesyslab.com, ietf@ietf.org Subject: Re: Why More TLDs -Reply References: In-reply-to: Your message of "Fri, 08 Nov 1996 19:00:49 -0500". Sender:ietf-request@ietf.org From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date:Mon, 11 Nov 1996 11:29:03 -0500 X-Orig-Sender: chk@border.com Source-Info: From (or Sender) name not authenticated. In message , Skip Addison writes: > Trademarks are not at all unique, even within a geography. Two companies can use the same trademark name if > their goods and services are unrelated. The requirement is simply that no relationship between the companies > would be inferred by a "reasonable" consumer. I've seen some real life examples that escape me at the moment. Apple Computer and Apple Records. -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7157 (voice) | "Madness takes its toll. Please have exact change." +1 416 368 7789 (fax) | -Karen Murphy   Received: from ietf.org by ietf.org id aa15822; 11 Nov 96 12:38 EST Received: from cnri by ietf.org id aa15627; 11 Nov 96 12:35 EST Received: from archimedes.inoc.sj.nec.com by CNRI.Reston.VA.US id aa09368; 11 Nov 96 12:35 EST Received: by inoc.sj.nec.com (8.7.3/YDL1.7-930126.17) id JAA10451(archimedes.inoc.sj.nec.com); Mon, 11 Nov 1996 09:33:59 -0800 (PST) Received: by sj.nec.com (8.7.3/YDL1.7-940623.1) id JAA29142(netkeeper.sj.nec.com); Mon, 11 Nov 1996 09:33:58 -0800 (PST) Received: (from smtp@localhost) by firenode2.ibu.sj.nec.com (8.7.5/8.7.3) id JAA15534 for ; Mon, 11 Nov 1996 09:31:14 -0800 (PST) Received: from vegas.ibu.sj.nec.com (vegas.ibu.sj.nec.com [131.241.70.2]) by firenode2.ibu.sj.nec.com id rfJAA15531 for <>; Mon Nov 11 09:27:19 1996 Received: by vegas.ibu.sj.nec.com (8.6.9/YDL1.9-9507101400) id JAA00651(vegas.ibu.sj.nec.com); Mon, 11 Nov 1996 09:29:28 -0800 Message-Id: <199611111729.JAA00651@vegas.ibu.sj.nec.com> To: ietf@CNRI.Reston.VA.US Subject: Re: Why More TLDs Date: Mon, 11 Nov 1996 09:29:27 -0800 Sender:ietf-request@ietf.org From: zen Source-Info: From (or Sender) name not authenticated. unsubscribe   Received: from ietf.org by ietf.org id aa19873; 11 Nov 96 14:07 EST Received: from nacho.cisco.com by ietf.org id aa19664; 11 Nov 96 14:03 EST Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id LAA01182 for ; Mon, 11 Nov 1996 11:01:44 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id LAA22391 for ; Mon, 11 Nov 1996 11:01:41 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 11:00:04 -0800 To: ietf@ietf.org Sender:ietf-request@ietf.org From: Fred Baker Subject: Changes in the IETF Organization Source-Info: From (or Sender) name not authenticated. Permit me to take this opportunity to inform you of some changes in the organization of the IETF, effective with the Memphis IETF meeting. At the recent IESG Retreat (October 21-22) in Santa Barbara, we discussed the direction of the Operations (formerly Operational Requirements) and the Network Management Areas. We decided to merge them into a common Operations and Management (O&M) Area. Mike O'Dell, the continuing Operations Area Director, will be one of the Area Directors for O&M; the other is to be determined by the Nominations Committee. The purpose of this change is, as much as anything, to ensure a closer liaison between the Network Management and the Operations communities. We want to make very certain that network management is more than "making SNMP work well"; it needs to be "SNMP and whatever else manages networks well" - a strong operational focus. All work which is currently being done in the Operations Area will be in the O&M Area. This includes benchmarking, peformance analysis, management of deployments and transitions, route policy, and some other issues. Over the years, the Network Management community has developed a pool of expertise in MIB development, embodied in the Network Management Directorate. This important group will continue to exist in the O&M area, and will continue to provide expertise in MIB development as a service to their own and other areas. Much of what has happened in the SNMP area is the development of MIBs. The policy has been for some time that MIBs should really be developed by the working group handling the protocol or other entity being managed. Nonetheless, some MIB development has occurred in the Network Management Area. The IESG will review these working groups during the transition; some of will move to other areas, such as Internet or Applications. Those groups that are closely tied to the evolution of management itself, like AgentX, will move with the SNMP work to O&M. Groups that don't have a natural home will be evaluated on a case by case basis. The development of SNMP itself, including the SNMP V2 Advisory Group chaired by Russ Mundy, will be in the O&M Area. We expect that the work identified and agreed to will be chartered in O&M, and will be carried out with strong support from the Security community. Thanks are due to Chuck Davin, Marshall Rose, and Deirdre Kostick for their leadership of the area over the years, and to the many who have worked in it. We hope that with this refocusing of vision, future network management developments will build and improve on the groundwork that has been laid. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Fred Baker | While one person hesitates because Cisco Systems | he feels inferior, the other is 519 Lado Drive | busy making mistakes and becoming Santa Barbara, California 93111 | superior. VOICE +1 408 526 4257 | FAX +1 805 681-0115 | -- Henry C. Link   Received: from ietf.org by ietf.org id aa20088; 11 Nov 96 16:40 EST Received: from cnri by ietf.org id aa19786; 11 Nov 96 16:34 EST Received: from IG.CS.UTK.EDU by CNRI.Reston.VA.US id aa15593; 11 Nov 96 16:33 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA21115; Mon, 11 Nov 1996 16:31:31 -0500 (EST) Message-Id: <199611112131.QAA21115@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Paul A Vixie cc: ietf@CNRI.Reston.VA.US, moore@cs.utk.edu Subject: Re: Why More TLDs In-reply-to: Your message of "Sun, 10 Nov 1996 20:32:05 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Nov 1996 16:31:31 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > The simple answer to "why more TLD's?" is that 100% of the users on the > Internet as of this date are abusing DNS as a directory service, and since > DNS somewhat predictably does not work well as a directory service these > people are trying to solve a "wrong technology" problem with a "more data" > solution. It won't work but like lemmings to the sea, we just gotta do it. Bingo. > What I need and what the other 98% of Internet users who have not yet signed > on need, is a way to say "does lucia's pizza in woodside have a URL?" and get > something useful -- an authoritative "no" or a short/accurate list > of possible "yes"'s. Absolutely. > The current TLD's were chosen by programmers rather than librarians. If you > look at the average programmer's choice of file names and variable names and > what not, you will see that programmers ought not, usually, be allowed to > pick names -- especially names that have to map to real world objects. And if you let librarians pick names, you'll get several different names for the same object. And the schema for those names will change over time as new topics/words are defined and the meanings of old words change. Just like existing schema for the organization of information, you'd generally need to be an expert in information science to want to use them. So I don't think this is the answer. > What we *need* in DNS is to close the current TLD's to new registrations, > get a bunch of librarians together and let them hammer out a new schema that > will provide better splay (.COM is too flat), get leverage out of universal > uniqueness and permanence, and publically sacrifice (stake through the heart) > any possible guessability. And then we need an actual, real live directory > service that works as well as the one the telephone companies provide now. What we *need* is to stop trying to use DNS as a directory service. Then we can let DNS be used for unique, transcribable, persistent names, and let the directory services do the (inherently fuzzy) matching. Of course, before we can do that, we'll need a replacement that works. Keith   Received: from ietf.org by ietf.org id aa22417; 11 Nov 96 17:24 EST Received: from cnri by ietf.org id aa22177; 11 Nov 96 17:18 EST Received: from nirvana.genesyslab.com by CNRI.Reston.VA.US id aa16843; 11 Nov 96 17:18 EST Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id OAA03052; Mon, 11 Nov 1996 14:17:54 -0800 (PST) Received: (from egoshin@localhost) by giant.genesyslab.com (8.7.5/8.7.3) id OAA11043; Mon, 11 Nov 1996 14:17:22 -0800 (PST) Date: Mon, 11 Nov 1996 14:17:22 -0800 (PST) Sender:ietf-request@ietf.org From: Leonid Egoshin Message-Id: <199611112217.OAA11043@giant.genesyslab.com> To: moore@cs.utk.edu, paul@vix.com Subject: Re: Why More TLDs Cc: ietf@CNRI.Reston.VA.US Source-Info: From (or Sender) name not authenticated. >From: Keith Moore > >> What I need and what the other 98% of Internet users who have not yet signed >> on need, is a way to say "does lucia's pizza in woodside have a URL?" and get >> something useful -- an authoritative "no" or a short/accurate list >> of possible "yes"'s. > >Absolutely. > > >What we *need* is to stop trying to use DNS as a directory service. >Then we can let DNS be used for unique, transcribable, persistent >names, and let the directory services do the (inherently fuzzy) >matching. Service providers (not ISP, but companies with WWW-servers) need "unique, transcribable, persistent names" to announce it, to publish it for clients and they don't want that client will do some search in non-unique directory service. This is the only reason of overcrowded .COM At least this service may looks like "unique", during step up on tree of names (city-state-country). - Leonid Yegoshin, LY22   Received: from ietf.org by ietf.org id aa09302; 12 Nov 96 0:39 EST Received: from cnri by ietf.org id af07398; 11 Nov 96 23:10 EST Received: from IG.CS.UTK.EDU by CNRI.Reston.VA.US id aa20134; 11 Nov 96 20:02 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id UAA25880; Mon, 11 Nov 1996 20:00:46 -0500 (EST) Message-Id: <199611120100.UAA25880@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Leonid Egoshin cc: moore@cs.utk.edu, paul@vix.com, ietf@CNRI.Reston.VA.US Subject: Re: Why More TLDs In-reply-to: Your message of "Mon, 11 Nov 1996 14:17:22 PST." <199611112217.OAA11043@giant.genesyslab.com> Date: Mon, 11 Nov 1996 20:00:46 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > >What we *need* is to stop trying to use DNS as a directory service. > >Then we can let DNS be used for unique, transcribable, persistent > >names, and let the directory services do the (inherently fuzzy) > >matching. > > Service providers (not ISP, but companies with WWW-servers) need > "unique, transcribable, persistent names" to announce it, to publish it > for clients and they don't want that client will do some search in > non-unique directory service. All well and good. But if they want those names to be guessable, or even mnemonic, they won't be unique any longer. Keith   Received: from ietf.org by ietf.org id aa05315; 12 Nov 96 5:08 EST Received: from cnri by ietf.org id aa05170; 12 Nov 96 5:03 EST Received: from [194.170.125.24] by CNRI.Reston.VA.US id aa05541; 12 Nov 96 5:03 EST Received: from [129.156.240.33] (kevin-mac [129.156.240.33]) by netcomm.NetComm.IE (8.8.0/8.7) with SMTP id IAA02421; Tue, 12 Nov 1996 08:48:41 +0400 X-Sender: kevinbr@129.156.240.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 08:57:16 +0300 To: Jim Fleming Sender:ietf-request@ietf.org From: Kevin Brown Subject: RE: Why More TLDs Cc: "ietf@CNRI.Reston.VA.US" , 'Paul A Vixie' , 'New Newdom' Source-Info: From (or Sender) name not authenticated. Paul, The Internet will eventually follow real business practices. Today you look in a paper yellow pages, but we believe that soon communities will have their own yellow pages on the net. We have done www.middle-east-pages.com that drills into each ME country, where people may add links. When and if it gets full, we will drill down into the City level, and then to the neighborhood. This needs to be done on a worldwide basis. Eventually people will realise that regional directories are superior to Yahoo. Agreed about DNS, but like everything on the NET, Yahoo, IANA, everything is very much US centric. I hope this will change. regards, Kevin At 16:42 11/11/96, Jim Fleming wrote: >On Sunday, November 10, 1996 2:32 PM, Paul A Vixie[SMTP:paul@vix.com] wrote: >@ The simple answer to "why more TLD's?" is that 100% of the users on the >@ Internet as of this date are abusing DNS as a directory service, and since >@ DNS somewhat predictably does not work well as a directory service these >@ people are trying to solve a "wrong technology" problem with a "more data" >@ solution. It won't work but like lemmings to the sea, we just gotta do it. >@ > >@ >@ Sure, I can find *something* if I ask for http://WWW.PIZZA.COM/ but it's not >@ likely that I can find my local pizza shop that way. I can try Alta Vista >@ or Yahoo, but it's going to be hard to find my local pizza shop that >way, too. >@ Therefore I use the telephone company's directory service ("can you give me >@ the number for Lucia's Pizza in Woodside?") and then I use the telephone to >@ call and get their URL so I can use HTTPS to order my pizza online. Then I >@ keep it as a bookmark. Which is OK until I have 2,000 such bookmarks and I >@ need to spend an hour per week cataloguing them. >@ > > >Paul, > >Rather than shift directory services to the DNS, you could >also consider an alternative... > >You could become the webmaster for Woodside, California >and help others place your "hot links" on... > > > >...this will allow you to dynamically build a community >directory, using descriptive categories and names. Once >people discover the value of these types of directories, >then the pressure will shift from using the DNS. > >P.S. Comm.unety.net was featured in the Chicago >Tribune's Digital City project.... > > > >...don't miss..."Pizza a slice of Naperville life."...:-) > >-- >Jim Fleming >UNETY Systems, Inc. >Naperville, IL > >e-mail: >JimFleming@unety.net >JimFleming@unety.net.s0.g0 (EDNS/IPv8) //////////////////////////////////////////////////////////// Kevin Brown | N \ We operate in Ireland NetComm | e / and the Middle East Unix Training, Consultancy | t \ --IRELAND-- Networking | C / Voice: 353-1-282-7342 | o \ Fax: 353-1-282-7342 Sun Microsystems | m / --DUBAI-- Internet Associate | m \ Voice: 971-4-491476 | / Fax: 971-4-492957 | \ email: kevinbr@netcomm.ie | / (Internet) | \ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Coming soon.......our UK office in Wokingham will open!   Received: from ietf.org by ietf.org id aa03046; 12 Nov 96 9:15 EST Received: from taunivm.tau.ac.il by ietf.org id aa02297; 12 Nov 96 8:51 EST Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 1808; Tue, 12 Nov 96 08:46:14 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 2894; Tue, 12 Nov 1996 08:46:12 +0200 Date: Tue, 12 Nov 96 08:46:01 IST Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: iTLDs To: ietf@ietf.org MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611120852.aa02297@ietf.org> Source-Info: From (or Sender) name not authenticated. >As a result, we have the typical manufacturer trying to get registered under >..COM using his corporate name and each of his trademarked product names. > >Increasing the number of TLDs is a "stop-gap" measure and not necessarily a >solution. If I know that O'Reilly & Associates uses ORA, the question is now >where do I find them? > > ORA.COM > ORA.LTD > ORA.PTY > ORA.CIE > ORA.GMBH > ORA.CORP > ORA.AB > ORA.AG > ORA.xx.CA.US > >Increasing the number of TLDs does allow us to eliminate some obscurity in >names but does not relieve the pressure on the DNS. > >Assuming that there is a WWW.VOLVO.COM, what incentive is there for Volvo to >switch to WWW.VOLVO.AB? Volvo may not be a good example, since you are right that they would want to be registered in every iTLD. Local stores do not need that global exposure. Increasing the number of iTLDs is indeed a stopgap measure. As Paul and others have pointed out we need to disconnect the DNS from a directory service. The way to do this is the way Netscape has a Net Search button built right into their browser. What we need is for Netscape and Microsoft to build into their 4.0 versions of their browsers a 'Site Lookup' button, that takes a user to a Web form that allows lookup for company name by substring or phonetic match and using the Internic/RIPE/APNIC DN databases as the base for the information supplied. >Merton Campbell Crockett >Hasenthaler InfoSysteme Hank Nussbacher Israel   Received: from cnri by ietf.org id aa05871; 12 Nov 96 10:29 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12543; 12 Nov 96 10:29 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Tue, 12 Nov 1996 14:38:22 GMT Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP id AA13420; Tue, 12 Nov 96 09:38:01 EST Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Tue, 12 Nov 1996 14:37:37 GMT Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id JAA00727; Tue, 12 Nov 1996 09:37:36 -0500 Message-Id: <199611121437.JAA00727@winkl.cam.ov.com> To: cat-ietf@mit.edu Cc: linn@cam.ov.com Subject: Draft 1, San Jose CAT agenda Date: Tue, 12 Nov 1996 09:37:35 -0500 From: John Linn Here's a first draft for the San Jose CAT agenda, which is currently rather sparse. If anyone has additional discussion topics to propose, please make them known. Thanks, ... --jl CAT agenda, 1996 San Jose IETF (Draft 1, 12 November) Tuesday, 10 December, 0900-1130 GSS-V2 C bindings discussion Wednesday, 11 December, 1530-1730. 1530-1545: John Myers (CMU), SASL 1545-1600: Brian Tung (ISI), pk-init 1600-1615: Denis Pinkas (Bull), updated SESAME mechanism 1615-1730: Revisited issues   Received: from ietf.org by ietf.org id aa12789; 12 Nov 96 10:49 EST Received: from ietf.org by ietf.org id aa05520; 12 Nov 96 10:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-katsube-00.txt Date: Tue, 12 Nov 1996 10:23:47 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611121023.aa05520@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Router Architecture Extensions for ATM : Overview Author(s) : H. Esaki Filename : draft-rfced-info-katsube-00.txt Pages : 18 Date : 11/11/1996 This memo describes a new internetworking architecture which makes better use of the property of ATM. IP datagrams are transferred along hop-by-hop path via routers, but datagram assembly/disassembly and IP header processing are not necessarily carried out at individual routers in the proposed architecture. A concept of "Cell Switch Router (CSR)" is introduced as a new internetworking equipment, which has ATM cell switching capabilities in addition to conventional IP datagram forwarding. Proposed architecture can provide applications with high-throughput and low-latency ATM pipes while retaining current router-based internetworking concept. It also provides applications with specific QoS/bandwidth by cooperating with internetworking level resource reservation protocols such as RSVP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rfced-info-katsube-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-katsube-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-katsube-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961111135510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-katsube-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-katsube-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961111135510.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12786; 12 Nov 96 10:49 EST Received: from ietf.org by ietf.org id aa05585; 12 Nov 96 10:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-brown-dcom-v1-spec-01.txt Date: Tue, 12 Nov 1996 10:23:58 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611121023.aa05585@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Distributed Component Object Model Protocol -- DCOM/1.0 Author(s) : N. Brown, C. Kindel Filename : draft-brown-dcom-v1-spec-01.txt Pages : 34 Date : 11/11/1996 The Distributed Component Object Model protocol is an application-level protocol for object-oriented remote procedure calls useful for distributed, component-based systems of all types. It is a generic protocol layered on the distributed computing environment (DCE) RPC specification and facilitates the construction of task-specific communication protocols through features such as: a platform neutral argument/parameter marshaling format (NDR), the ability for objects to support multiple interfaces with a safe, interface-level versioning scheme suited to independent evolution by multiple parties, the ability to make authenticated connections and to choose levels of channel security, and a transport-neutral data representation for references (including by-value) to objects. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brown-dcom-v1-spec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-brown-dcom-v1-spec-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-brown-dcom-v1-spec-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961111170700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brown-dcom-v1-spec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-brown-dcom-v1-spec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961111170700.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12783; 12 Nov 96 10:49 EST Received: from ietf.org by ietf.org id aa05536; 12 Nov 96 10:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ids-iwps-schema-spec-02.txt Date: Tue, 12 Nov 1996 10:23:49 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611121023.aa05536@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Directory Services Working Group of the IETF. Title : A Common Schema for the Internet White Pages Service Author(s) : T. Genovese, B. Jennings Filename : draft-ietf-ids-iwps-schema-spec-02.txt Pages : 5 Date : 11/11/1996 The work is the result of the IETF Integrated Directory Services (IDS) Working Group which proposes to establish a specification for a simple Internet white pages service. To facilitate this effort it would be helpful to have a common schema used by the various white page servers. This document is designed to specify the basic set of attributes to be used for a white page entry for an individual. This schema does not describe how to represent other objects in the White page service. It does describe how new objects can be defined and registered. This schema is independent of implementations of the White Page service. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ids-iwps-schema-spec-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ids-iwps-schema-spec-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961111141516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ids-iwps-schema-spec-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961111141516.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12800; 12 Nov 96 10:49 EST Received: from ietf.org by ietf.org id aa05569; 12 Nov 96 10:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-ldapv3-lang-00.txt Date: Tue, 12 Nov 1996 10:23:54 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611121023.aa05569@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : Use of Language Codes in LDAP Author(s) : M. Wahl, T. Howes Filename : draft-ietf-asid-ldapv3-lang-00.txt Pages : 7 Date : 11/11/1996 The Lightweight Directory Access Protocol [1] provides a means for clients to interrogate and modify information stored in a distributed directory system. The information in the directory is maintained as attributes [2] of entries. Most of these attributes have syntaxes which are human-readable strings, and it is desirable to be able to indicate the natural language associated with attribute values. This document describes how language codes [3] are carried in LDAP and are to be interpreted by LDAP servers. All implementations must be prepared to accept language codes in the LDAP protocols. Servers may or may not be capable of storing attributes with language codes in the directory. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-asid-ldapv3-lang-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-lang-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-ldapv3-lang-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961111150012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-ldapv3-lang-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-ldapv3-lang-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961111150012.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12793; 12 Nov 96 10:49 EST Received: from ietf.org by ietf.org id aa05487; 12 Nov 96 10:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-andrews-dns-hostnames-03.txt Date: Tue, 12 Nov 1996 10:23:43 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611121023.aa05487@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Clarification on the use of Hostnames, Mail Boxes and Mail Domains in the DNS Author(s) : M. Andrews Filename : draft-andrews-dns-hostnames-03.txt Pages : 6 Date : 11/11/1996 At the protocol level, DNS domain names and records may contain arbitrary binary data. However, many domain names and records are, or refer to, hostnames, which are restricted by RFCs 952 and 1123 to contain only certain characters. Similar restrictions apply to mail domain names, RFC-821. This document identifies the types of domain names and records which are hostnames / mail domain names, and specifies the circumstances under which validation checks should be performed within the class IN. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-andrews-dns-hostnames-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-andrews-dns-hostnames-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-andrews-dns-hostnames-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961111133841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-andrews-dns-hostnames-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-andrews-dns-hostnames-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961111133841.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12791; 12 Nov 96 10:49 EST Received: from ietf.org by ietf.org id aa05552; 12 Nov 96 10:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-aboba-roam-nai-00.txt Date: Tue, 12 Nov 1996 10:23:51 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611121023.aa05552@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Network Access Identifier Author(s) : B. Aboba Filename : draft-aboba-roam-nai-00.txt Pages : 12 Date : 11/11/1996 This document describes issues relating to user identification in provision of "roaming capability" for dialup Internet users. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aboba-roam-nai-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-aboba-roam-nai-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-aboba-roam-nai-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961111144758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aboba-roam-nai-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-aboba-roam-nai-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961111144758.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12796; 12 Nov 96 10:49 EST Received: from ietf.org by ietf.org id aa05503; 12 Nov 96 10:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-almesberger-00.txt Date: Tue, 12 Nov 1996 10:23:45 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611121023.aa05503@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Application REQuested IP over ATM (AREQUIPA) Author(s) : W. Almesberger, J. Le Boudec, P. Oechslin Filename : draft-rfced-info-almesberger-00.txt Pages : 10 Date : 11/11/1996 This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS). Given a mapping from service classes, as defined by INTSERV[6], to ATM traffic descriptors, Arequipa can be used to implement integrated services over ATM link layers. Usage of Arequipa to provide integrated services even if ATM is only available for intermediate links is not discussed in this document but should be straight-forward. The major advantage of using an approach like Arequipa is that it needs to be implemented only on the hosts using it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rfced-info-almesberger-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-almesberger-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-almesberger-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961111134448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-almesberger-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-almesberger-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961111134448.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23959; 12 Nov 96 11:59 EST Received: from ietf.org by ietf.org id aa23440; 12 Nov 96 11:52 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-hmac-md5-01.txt Date: Tue, 12 Nov 1996 11:52:19 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611121152.aa23440@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : HMAC: Keyed-Hashing for Message Authentication Author(s) : H. Krawczyk, M. Bellare, R. Canetti Filename : draft-ietf-ipsec-hmac-md5-01.txt Pages : 8 Date : 11/08/1996 This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-hmac-md5-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961108101246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-hmac-md5-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961108101246.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa26598; 12 Nov 96 12:28 EST Received: from cnri by ietf.org id aa26388; 12 Nov 96 12:26 EST Received: from IG.CS.UTK.EDU by CNRI.Reston.VA.US id aa15930; 12 Nov 96 12:26 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id MAA29633; Tue, 12 Nov 1996 12:24:10 -0500 (EST) Message-Id: <199611121724.MAA29633@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Leonid Egoshin cc: moore@cs.utk.edu, ietf@CNRI.Reston.VA.US, paul@vix.com Subject: Re: Why More TLDs In-reply-to: Your message of "Mon, 11 Nov 1996 17:31:37 PST." <199611120131.RAA14322@giant.genesyslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 12:24:09 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > >> Service providers (not ISP, but companies with WWW-servers) need > >> "unique, transcribable, persistent names" to announce it, to publish it > >> for clients and they don't want that client will do some search in > >> non-unique directory service. > > > >All well and good. But if they want those names to be guessable, > >or even mnemonic, they won't be unique any longer. > > > Are you shure ? I know about service for money which construct > guessable and mnemonic names for market something. Of course - unique ! > It is the purpose if you don't want a lack of potential customers attention. Yes, there are business that do this. (New drugs especially tend to have such synthetic names.) But there's also a general human tendency to reuse names in such a way that their meanings change. Most of the time, when we name something, we use words or parts of words which already have meaning in other contexts. Even names origianlly chosen to be unique, can be reused in this way...so that they aren't unique any longer. If every one who applied for a DNS name were required to make it be globally unique, we wouldn't have nearly so many problems with lawsuits. But most companies want their their DNS name to reflect their company name (or their trademark, or their line of business, e.g. "soap.com"). And most company names or trademarks weren't chosen to be globally unique. Keith   Received: from ietf.org by ietf.org id aa23854; 12 Nov 96 13:32 EST Received: from refuge.Colorado.EDU by ietf.org id aa23609; 12 Nov 96 13:29 EST Received: from refuge.Colorado.EDU (bevo@localhost [127.0.0.1]) by refuge.Colorado.EDU (8.7.5/8.7.3) with ESMTP id LAA18740; Tue, 12 Nov 1996 11:28:13 -0700 (MST) Message-Id: <199611121828.LAA18740@refuge.Colorado.EDU> To: Hank Nussbacher cc: ietf@ietf.org Subject: Re: iTLDs In-reply-to: Your message of "Tue, 12 Nov 1996 08:46:01 +0700." <9611120852.aa02297@ietf.org> Date: Tue, 12 Nov 1996 11:28:12 -0700 Sender:ietf-request@ietf.org From: John Bevilacqua Source-Info: From (or Sender) name not authenticated. Yes, and that 'Site Lookup' button should be a whois client, since whois is the functional, embedded directory service. Perhaps the whois client could be enhanced a bit to include the search types you have identified. --bevo UnixOps/University of Colorado -------- > Increasing the number of iTLDs is indeed a stopgap measure. As Paul > and others have pointed out we need to disconnect the DNS from a > directory service. The way to do this is the way Netscape has a > Net Search button built right into their browser. > > What we need is for Netscape and Microsoft to build into their > 4.0 versions of their browsers a 'Site Lookup' button, that > takes a user to a Web form that allows lookup for company name > by substring or phonetic match and using the Internic/RIPE/APNIC > DN databases as the base for the information supplied. > > >Merton Campbell Crockett > >Hasenthaler InfoSysteme > > Hank Nussbacher > Israel --------   Received: from ietf.org by ietf.org id aa28645; 12 Nov 96 14:50 EST Received: from morgan.cnu.edu by ietf.org id aa28384; 12 Nov 96 14:46 EST Received: from redbeard.cnu.edu (redbeard.cnu.edu [137.155.12.211]) by morgan.cnu.edu (8.7.3/8.6.9) with SMTP id OAA23791; Tue, 12 Nov 1996 14:45:02 -0500 (EST) Date: Tue, 12 Nov 1996 14:48:22 -0500 (EST) Sender:ietf-request@ietf.org From: "J. Patrick Narkinsky" To: John Bevilacqua cc: ietf@ietf.org Subject: Re: iTLDs In-Reply-To: <199611121828.LAA18740@refuge.Colorado.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Tue, 12 Nov 1996, John Bevilacqua wrote: > > Yes, and that 'Site Lookup' button should be a whois client, since whois > is the functional, embedded directory service. Perhaps the whois client > could be enhanced a bit to include the search types you have identified. > hrrrmmm... As a caveat - it should be a whois client that is smart enough to look in multiple databases. Patrick --------------------------------------------------------------------------- J. Patrick Narkinsky | | Over the router, through the bridge, Comp. Systems Sr. Engineer | past the T1, bounce off MAE-East, CNU Computer Center | nothing but net. (804)594-7180 | ---------------------------------------------------------------------------   Received: from ietf.org by ietf.org id aa29085; 12 Nov 96 14:54 EST Received: from zephyr.isi.edu by ietf.org id aa28663; 12 Nov 96 14:50 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 12 Nov 1996 11:49:14 -0800 Message-Id: <199611121949.AA06416@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2011 on SNMPv2 MIB for IP Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 12 Nov 96 11:49:13 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2011: Title: SNMPv2 Management Information Base for the Internet Protocol using SMIv2 Author: K. McCloghrie, Editor Date: November 1996 Mailbox: kzm@cisco.com Pages: 18 Characters: 31,168 Updates/Obsoletes: 1213 URL: ftp://ds.internic.net/rfc/rfc2011.txt This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). This RFC is the product of the SNMP Working Group of the IETF. IESG Note: The IP, UDP, and TCP MIB modules currently support only IPv4. These three modules use the IpAddress type defined as an OCTET STRING of length 4 to represent the IPv4 32-bit internet addresses. (See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 internet addresses. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961112103144.RFC@ISI.EDU> SEND /rfc/rfc2011.txt --OtherAccess Content-Type: Message/External-body; name="rfc2011.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961112103144.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01441; 12 Nov 96 15:18 EST Received: from core.atmnet.net by ietf.org id aa01224; 12 Nov 96 15:17 EST Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id MAA10860 for ; Tue, 12 Nov 1996 12:15:50 -0800 (PST) Received: by jfbb.atmnet.net with Microsoft Mail id <01BBD093.38277320@jfbb.atmnet.net>; Tue, 12 Nov 1996 12:15:40 -0800 Message-ID: <01BBD093.38277320@jfbb.atmnet.net> Sender:ietf-request@ietf.org From: Jim Browning To: "ietf@ietf.org" Subject: RE: iTLDs Date: Tue, 12 Nov 1996 12:15:39 -0800 Encoding: 33 TEXT Source-Info: From (or Sender) name not authenticated. >From: John Bevilacqua[SMTP:bevo@refuge.colorado.edu] >Sent: Tuesday, November 12, 1996 10:28 AM > >Yes, and that 'Site Lookup' button should be a whois client, since whois >is the functional, embedded directory service. Perhaps the whois client >could be enhanced a bit to include the search types you have identified. Are you suggesting that domains at levels below those administered by the registries be included in the whois database? Otherwise, wouldn't this create an even greater desire for every entity to have a level two domain, so that it would be found with a whois search? Any comprehensive directory service must include those entities who have accepted domains that do not currently appear in the whois directory, including addresses such as "boulder.colorado.edu/~bevo/". A whois search for bevilacqua does not currently provide this info... Do we want a whois database that large, which the infrastructure surrounding it which would be required to handle the traffic? It is clear that the ability to guess a domain will erode over time, and any successful introduction of additional TLDs will only serve to hasten that erosion. As the ability to guess erodes, those commercial ventures who are dealing with these problems will enjoy greater success, and enhance their ability to locate specific entities, whereas right now they appear focused on content oriented searches. I think it best to spread the directory effort among the many commercial enterprises who want to provide the service, with IETF ensuring that the DNS system supports a reasonable technical approach that also accepts the realities of the business environment. -- Jim Browning   Received: from ietf.org by ietf.org id aa04992; 12 Nov 96 16:15 EST Received: from ZAFU.BBN.COM by ietf.org id aa04775; 12 Nov 96 16:12 EST Received: from [128.89.30.23] (ARA23.BBN.COM [128.89.30.23]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id QAA11545; Tue, 12 Nov 1996 16:10:39 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199611101951.OAA03116@raptor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 15:30:55 -0500 To: Steven Bellovin Sender:ietf-request@ietf.org From: Stephen Kent Subject: Re: The cartel begins to crumble? Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. I believe that Massachusetts is another state with a similar two-party approval law re recording phone conversations.   Received: from ietf.org by ietf.org id aa05437; 12 Nov 96 16:24 EST Received: from zephyr.isi.edu by ietf.org id aa05137; 12 Nov 96 16:20 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 12 Nov 1996 13:18:58 -0800 Message-Id: <199611122118.AA12694@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2012 on SNMPv2 MIB for TCP Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 12 Nov 96 13:18:57 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2012: Title: SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 Author: K. McCloghrie, Editor Date: November 1996 Mailbox: kzm@cisco.com Pages: 10 Characters: 16,792 Updates/Obsoletes: 1213 URL: ftp://ds.internic.net/rfc/rfc2012.txt This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). This RFC is the product of the SNMP Version 2 Working Group of the IETF. IESG Note: The IP, UDP, and TCP MIB modules currently support only IPv4. These three modules use the IpAddress type defined as an OCTET STRING of length 4 to represent the IPv4 32-bit internet addresses. (See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 internet addresses. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961112131208.RFC@ISI.EDU> SEND /rfc/rfc2012.txt --OtherAccess Content-Type: Message/External-body; name="rfc2012.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961112131208.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05676; 12 Nov 96 16:26 EST Received: from IG.CS.UTK.EDU by ietf.org id aa05520; 12 Nov 96 16:25 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA15821; Tue, 12 Nov 1996 16:23:18 -0500 (EST) Message-Id: <199611122123.QAA15821@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Hank Nussbacher cc: ietf@ietf.org, moore@cs.utk.edu Subject: Re: iTLDs In-reply-to: Your message of "Tue, 12 Nov 1996 08:46:01 +0700." <9611120852.aa02297@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 16:23:18 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > What we need is for Netscape and Microsoft to build into their > 4.0 versions of their browsers a 'Site Lookup' button, that > takes a user to a Web form that allows lookup for company name > by substring or phonetic match and using the Internic/RIPE/APNIC > DN databases as the base for the information supplied. Yes, this is precisely what's needed. Keith   Received: from ietf.org by ietf.org id aa05834; 12 Nov 96 16:28 EST Received: from cnri by ietf.org id aa05746; 12 Nov 96 16:27 EST Received: from IG.CS.UTK.EDU by CNRI.Reston.VA.US id aa22908; 12 Nov 96 16:27 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA15828; Tue, 12 Nov 1996 16:21:44 -0500 (EST) Message-Id: <199611122121.QAA15828@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Zheng Wang cc: Merton Campbell Crockett , Dave Crocker , Paul A Vixie , ietf@CNRI.Reston.VA.US, moore@cs.utk.edu Subject: Re: Why More TLDs In-reply-to: Your message of "Mon, 11 Nov 1996 23:24:37 GMT." <13243.847754677@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 16:21:44 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > DNS is not a directory > service but having easy to remember names is important. You dont > want to search a directory or bookmarks (most people's > bookmarks are rapidly becoming large directories) each time when you > go to a web site. We want domain names like sun.com, not > s8ssdk349.com. It can be done. All we need is some reasonable > classification as TLDs. > > Yes, I agree we should get librarians and classification people > to design the TLDs. I don't think this is the answer, either. What we'd get is a set of domain names which can be navigated, menu-style, but are not easy to remember for those who aren't experts in the classification system. Keith p.s. The closest "real world" analogs to domain name labels that I've found are stock ticker symbols and alphabetic telex addresses. Both of these are short, unique (within their domain), and mnemonic, and both of them tend to have rather strained mappings between the "real world" name and the label. Maybe we should limit domain labels to six characters?   Received: from ietf.org by ietf.org id aa08429; 12 Nov 96 16:57 EST Received: from zephyr.isi.edu by ietf.org id aa08152; 12 Nov 96 16:54 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 12 Nov 1996 13:27:53 -0800 Message-Id: <199611122127.AA13097@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2013 on SNMPv2 MIB for UDP Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 12 Nov 96 13:27:53 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2013: Title: SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 Author: K. McCloghrie, Editor Date: November 1996 Mailbox: kzm@cisco.com Pages: 6 Characters: 9,333 Updates/Obsoletes: 1213 URL: ftp://ds.internic.net/rfc/rfc2013.txt This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). This RFC is a product of the SNMP Version 2 Working Group of the IETF. IESG Note: The IP, UDP, and TCP MIB modules currently support only IPv4. These three modules use the IpAddress type defined as an OCTET STRING of length 4 to represent the IPv4 32-bit internet addresses. (See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 internet addresses. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961112132028.RFC@ISI.EDU> SEND /rfc/rfc2013.txt --OtherAccess Content-Type: Message/External-body; name="rfc2013.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961112132028.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09851; 12 Nov 96 17:11 EST Received: from rip.psg.com by ietf.org id aa09685; 12 Nov 96 17:10 EST Received: by rip.psg.com id m0vNR0I-0007zZC; Tue, 12 Nov 96 14:08 PST (Smail3.1.29.1#1) Message-Id: Date: Tue, 12 Nov 96 14:08 PST Sender:ietf-request@ietf.org From: Randy Bush To: Keith Moore Cc: ietf@ietf.org Subject: Re: iTLDs References: <9611120852.aa02297@ietf.org> <199611122123.QAA15821@ig.cs.utk.edu> Source-Info: From (or Sender) name not authenticated. >> What we need is for Netscape and Microsoft to build into their >> 4.0 versions of their browsers a 'Site Lookup' button, that >> takes a user to a Web form that allows lookup for company name >> by substring or phonetic match and using the Internic/RIPE/APNIC >> DN databases as the base for the information supplied. > Yes, this is precisely what's needed. s/precisely/one example of/ I can think of other data bases which might transform interesting search strings into URLs. I could see a market in such providers of mappings. randy   Received: from ietf.org by ietf.org id aa11010; 12 Nov 96 17:20 EST Received: from aspen.wwsi.com by ietf.org id aa10852; 12 Nov 96 17:18 EST Received: from aspen.wwsi.com (localhost [127.0.0.1]) by aspen.wwsi.com (8.7.6/8.7.3) with ESMTP id QAA02827; Tue, 12 Nov 1996 16:17:05 -0700 Message-Id: <199611122317.QAA02827@aspen.wwsi.com> To: Keith Moore cc: Hank Nussbacher , ietf@ietf.org Subject: Re: iTLDs In-reply-to: Your message of "Tue, 12 Nov 1996 16:23:18 EST." <199611122123.QAA15821@ig.cs.utk.edu> Mime-Version: 1.0 (generated by tm-edit 7.78) Content-Type: text/plain; charset=US-ASCII Date: Tue, 12 Nov 1996 16:17:05 -0700 Sender:ietf-request@ietf.org From: Steve Hultquist Source-Info: From (or Sender) name not authenticated. >>>>> "Keith" == Keith Moore writes: >> What we need is for Netscape and Microsoft to build into their 4.0 >> versions of their browsers a 'Site Lookup' button, that takes a user >> to a Web form that allows lookup for company name by substring or >> phonetic match and using the Internic/RIPE/APNIC DN databases as the >> base for the information supplied. Keith> Yes, this is precisely what's needed. Hmmm... Shouldn't the response be to build that search engine and then suggest to either one of those companies or a third party search engine provider that they host it for the "good of the 'net"? I'm not sure I want the "browser wars" to turn into the "site lookup wars", with incompatibility and redundancy all over the place. We have more difficult problems to solve that need that kind of energy. I agree, however, that this capability will go a long way towards making the new TLDs actually usable. Without it, I see massive end-user frustration as the initial result from the new domains. And that's something we definitely *don't* need! ssh -- Steve Hultquist Business, system, network, and Internet Worldwide Solutions, Inc. Engineering Boulder, Colorado, USA 303.581.0800 http://www.wwsi.com   Received: from ietf.org by ietf.org id aa13002; 12 Nov 96 17:44 EST Received: from [207.32.130.1] by ietf.org id aa12835; 12 Nov 96 17:42 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id QAA15921 for ; Tue, 12 Nov 1996 16:35:51 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBD0B7.DBFE76A0@webster.unety.net>; Tue, 12 Nov 1996 16:37:57 -0600 Message-ID: <01BBD0B7.DBFE76A0@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "'ietf@ietf.org'" Subject: ISOC IAHC Date: Tue, 12 Nov 1996 16:37:55 -0600 Encoding: 32 TEXT Source-Info: From (or Sender) name not authenticated. @@@@ http://www.isoc.org/whatsnew/iahcmembers.html "NEW INTERNATIONAL COMMITTEE NAMED TO RESOLVE DOMAIN NAME SYSTEM ISSUES" Dr. Donald N. Telage, president of the Herndon, Virginia - based Network Solutions, Inc., which manages the InterNIC Registry administering the .com, .net, .edu, and .org top level domains, said: "Network Solutions has supported the registration process and the growth of the Internet since 1991. We have seen its evolution from a research and education tool to a powerful medium for global communication and collaboration. The National Science Foundation has played a critical role in the early governance activities, and we support the Internet Society's efforts to review issues critical to the future of Internet growth, evolution and governance. Network Solutions will participate and support this effort enthusiastically supplying our extensive operational knowledge as needed." @@@@ -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa18777; 13 Nov 96 8:27 EST Received: from ng.netgate.net by ietf.org id aa17768; 13 Nov 96 8:23 EST Received: from [204.179.132.128] ([204.179.128.254]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id PAA07185; Tue, 12 Nov 1996 15:56:12 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <199611122123.QAA15821@ig.cs.utk.edu> References: Your message of "Tue, 12 Nov 1996 08:46:01 +0700." <9611120852.aa02297@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Nov 1996 15:36:52 -0800 To: Keith Moore Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: iTLDs Cc: Hank Nussbacher , ietf@ietf.org, moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. At 1:23 PM -0800 11/12/96, Keith Moore wrote: >> What we need is for Netscape and Microsoft to build into their >> 4.0 versions of their browsers a 'Site Lookup' button, that > >Yes, this is precisely what's needed. uhh, what data bases are to be consulted? How are they found? What standards are used to consult them? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa18784; 13 Nov 96 8:27 EST Received: from ng.netgate.net by ietf.org id aa17439; 13 Nov 96 8:22 EST Received: from [205.214.160.148] (d107.netgate.net [205.214.160.145]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id XAA03768; Tue, 12 Nov 1996 23:33:42 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <199611130658.BAA01251@ig.cs.utk.edu> References: Your message of "Tue, 12 Nov 1996 22:03:11 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Nov 1996 23:23:07 -0800 To: Keith Moore Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: iTLDs Cc: Keith Moore , ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 10:58 PM -0800 11/12/96, Keith Moore wrote: >The server is implemented using "big flat server technology" ahh. this is the "one true data base" model. All companies in the world need to be listed in it. sounds ambitious. can wait to see the scaling behavior. Keeping it up to date is going to be another interesting exercise. By the way, where does it get its data from? >> Seems to me either the user knows a heck of a lot, so they can go to a >> correct, specialized data base, or else we have the requirement for a =2E.. >Neither one. How many different kinds of telephone books do we need? >Do users have to know "a heck of a lot" to decide whether to use the >yellow pages or the white pages, or to decide whether to call You have to know the city, or at least the metropolitan area. That's a heck of a lot. using a yellow pages can get pretty interesting, too, but yes, I think it's a dandy model to start with. d. -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa18793; 13 Nov 96 8:27 EST Received: from IG.CS.UTK.EDU by ietf.org id aa16453; 13 Nov 96 8:17 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id BAA01251; Wed, 13 Nov 1996 01:58:39 -0500 (EST) Message-Id: <199611130658.BAA01251@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Dave Crocker cc: Keith Moore , ietf@ietf.org Subject: Re: iTLDs In-reply-to: Your message of "Tue, 12 Nov 1996 22:03:11 PST." Date: Wed, 13 Nov 1996 01:58:39 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > At 6:20 PM -0800 11/12/96, Keith Moore wrote: > >Nah. We don't have to solve the general distributed directory problem. > >And for a single-purpose database, like one that matches company names > >and returns pointers to their web pages, the solution can be quite simple. > > > >We're quite capable of building large centralized databases and replicating > >them at multiple sites. The interface to these can be as simple as a > >profile of whois or http. > > Keith, I guess I just plain don't understand the usage scenario. > What does a user have to know? He has to know how to use a web browser, and the (approximate) name of the company he wants to search for (say, as good as he'd have to give to telephone directory assistance). > How do they use it? Probably, the user just has to type in the company name into his web browser's "go to" blank. The web browser will notice that it doesn't look like a URI or domain name, and will send the query to the directory service. Present day web browsers would store the URL for the directory service as a bookmark. > How does it work. The browser sends an http POST request to one of the locations of the directory service, and gets back html. If the original query was too ambiguous to return a small number of possible matches, the response either asks the user to be more specific (just like telephone directory assistance), or lets the user browse through an list of possible matches (just like a telephone directory). The server is implemented using "big flat server technology" (altavista or lycos or whatever, except that only the names and acronyms of companies are indexed, rather than the full text of articles like we're used to seeing from these servers.) > Seems to me either the user knows a heck of a lot, so they can go to a > correct, specialized data base, or else we have the requirement for a > highly integrated, global, distributed system. If the former, we really > are requiring the end user to have quite a lot of information. Otherwise, > we are requiring the data base service to do a lot. Neither one. How many different kinds of telephone books do we need? Do users have to know "a heck of a lot" to decide whether to use the yellow pages or the white pages, or to decide whether to call "800 number directory assistance" versus "local directory assistance"? Which is not to say that there won't be other ways to search for web pages, but this is a special-purpose server that happens to be useful in a large number of situations. Keith   Received: from ietf.org by ietf.org id aa18776; 13 Nov 96 8:27 EST Received: from ng.netgate.net by ietf.org id aa17451; 13 Nov 96 8:22 EST Received: from [205.214.160.148] (d110.netgate.net [205.214.160.148]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id WAA01580; Tue, 12 Nov 1996 22:42:51 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <199611130220.VAA27470@ig.cs.utk.edu> References: Your message of "Tue, 12 Nov 1996 17:26:31 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Nov 1996 22:03:11 -0800 To: Keith Moore Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: iTLDs Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 6:20 PM -0800 11/12/96, Keith Moore wrote: >Nah. We don't have to solve the general distributed directory problem. >And for a single-purpose database, like one that matches company names >and returns pointers to their web pages, the solution can be quite simple. > >We're quite capable of building large centralized databases and replicating >them at multiple sites. The interface to these can be as simple as a profi= le >of whois or http. Keith, I guess I just plain don't understand the usage scenario. What does a user have to know? How do they use it? How does it work. Seems to me either the user knows a heck of a lot, so they can go to a correct, specialized data base, or else we have the requirement for a highly integrated, global, distributed system. If the former, we really are requiring the end user to have quite a lot of information. Otherwise, we are requiring the data base service to do a lot. What am I missing (and how do I figure out what data base to go to to get the answer...) d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa18757; 13 Nov 96 8:27 EST Received: from IG.CS.UTK.EDU by ietf.org id aa16490; 13 Nov 96 8:17 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id VAA27470; Tue, 12 Nov 1996 21:20:55 -0500 (EST) Message-Id: <199611130220.VAA27470@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Dave Crocker cc: Keith Moore , Hank Nussbacher , ietf@ietf.org Subject: Re: iTLDs In-reply-to: Your message of "Tue, 12 Nov 1996 17:26:31 PST." Date: Tue, 12 Nov 1996 21:20:54 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > At 4:12 PM -0800 11/12/96, Keith Moore wrote: > >> uhh, what data bases are to be consulted? How are they found? > > > >The data bases should be selectable by the client. Users will > >find out about them the same way they find out about other > >information services. > > Oh? So the solution to the fuzzy searching problem is moved from > trying to figure out what your company's domain name is to trying to figure > out what data bases your company is listed in? (No. Really. I mean the > question seriously.) The solution is to encourage the development/deployment of extensive data bases of company names that happen to have a presence on the Internet. Actually, several companies have managed to develop such services already; what we need is a standard interface between these services and web browsers. > >We need to develop standards (or more likely, profiles of existing > >standards) for them. > > ahh. that's fine. It also means that we won't have a deployed > solution available for at least a couple of years. Nah. We don't have to solve the general distributed directory problem. And for a single-purpose database, like one that matches company names and returns pointers to their web pages, the solution can be quite simple. We're quite capable of building large centralized databases and replicating them at multiple sites. The interface to these can be as simple as a profile of whois or http. Keith   Received: from ietf.org by ietf.org id aa18787; 13 Nov 96 8:27 EST Received: from IG.CS.UTK.EDU by ietf.org id aa16496; 13 Nov 96 8:17 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id TAA19356; Tue, 12 Nov 1996 19:12:59 -0500 (EST) Message-Id: <199611130012.TAA19356@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Dave Crocker cc: Keith Moore , Hank Nussbacher , ietf@ietf.org Subject: Re: iTLDs In-reply-to: Your message of "Tue, 12 Nov 1996 15:36:52 PST." Date: Tue, 12 Nov 1996 19:12:59 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > uhh, what data bases are to be consulted? How are they found? The data bases should be selectable by the client. Users will find out about them the same way they find out about other information services. > What standards are used to consult them? We need to develop standards (or more likely, profiles of existing standards) for them. Keith   Received: from ietf.org by ietf.org id aa18790; 13 Nov 96 8:27 EST Received: from ng.netgate.net by ietf.org id aa17725; 13 Nov 96 8:23 EST Received: from [205.214.160.82] (d48.netgate.net [205.214.160.82]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id SAA16010; Tue, 12 Nov 1996 18:08:53 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <199611130012.TAA19356@ig.cs.utk.edu> References: Your message of "Tue, 12 Nov 1996 15:36:52 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Nov 1996 17:26:31 -0800 To: Keith Moore Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: iTLDs Cc: Keith Moore , Hank Nussbacher , ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 4:12 PM -0800 11/12/96, Keith Moore wrote: >> uhh, what data bases are to be consulted? How are they found? > >The data bases should be selectable by the client. Users will >find out about them the same way they find out about other >information services. Oh? So the solution to the fuzzy searching problem is moved from trying to figure out what your company's domain name is to trying to figure out what data bases your company is listed in? (No. Really. I mean the question seriously.) >> What standards are used to consult them? > >We need to develop standards (or more likely, profiles of existing >standards) for them. ahh. that's fine. It also means that we won't have a deployed solution available for at least a couple of years. (Lest folks miss the history, there have been efforts at global data base service underway since 1984. No doubt we will yet get one, but the history says it will take awhile. Probably not soon enough to eliminate the immediate domain name problem.) d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa18758; 13 Nov 96 8:27 EST Received: from WLV.IIPO.GTEGSC.COM by ietf.org id aa17906; 13 Nov 96 8:24 EST Received: from MCC.IIPO.GTEGSC.COM (MCC.IIPO.GTEGSC.COM [199.107.242.254]) by wlv.iipo.gtegsc.com (8.8.2/8.7.3) with SMTP id QAA08651; Tue, 12 Nov 1996 16:28:31 -0800 (PST) Sender:ietf-request@ietf.org From: Merton Campbell Crockett Message-Id: <961112162812.ZM3302@MCC.IIPO.GTEGSC.COM> Date: Tue, 12 Nov 1996 16:28:09 -0700 In-Reply-To: Hank Nussbacher "Re: iTLDs" (Nov 12, 8:46) References: <9611120852.aa02297@ietf.org> X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996) To: Hank Nussbacher , ietf@ietf.org Subject: Re: iTLDs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Source-Info: From (or Sender) name not authenticated. On Nov 12, 8:46, Hank Nussbacher wrote: > Subject: Re: iTLDs | |Increasing the number of iTLDs is indeed a stopgap measure. As Paul |and others have pointed out we need to disconnect the DNS from a |directory service. The way to do this is the way Netscape has a |Net Search button built right into their browser. | |What we need is for Netscape and Microsoft to build into their |4.0 versions of their browsers a 'Site Lookup' button, that |takes a user to a Web form that allows lookup for company name |by substring or phonetic match and using the Internic/RIPE/APNIC |DN databases as the base for the information supplied. Jon Postel forwarded the following URL. This is based on the RS.INTERNIC.NET whois database. http://netpart.com/free/search.html It provides a list of possible Web Servers and Anonymous FTP servers based on the assumption there is, at least, a CNAME for WWW and FTP in the domain. This would be a start for Netscape, Microsoft, Spyglass, etc. to include a lookup feature with this type of information. Also, something that online services should be doing as well. While this does eliminate some of the DNS guessing traffic, its principal advantage is that it makes other TLDs more appealing. If there someway for the home user to determine what there is besides .com, one might entice movie production companies to join an .mpc domain. | |Hank Nussbacher |Israel | >-- End of excerpt from Hank Nussbacher Merton Campbell Crockett Hasenthaler InfoSysteme   Received: from ietf.org by ietf.org id aa20072; 13 Nov 96 8:31 EST Received: from core.atmnet.net by ietf.org id aa19764; 13 Nov 96 8:30 EST Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id UAA19868; Tue, 12 Nov 1996 20:38:25 -0800 (PST) Received: by jfbb.atmnet.net with Microsoft Mail id <01BBD0D9.713B1A40@jfbb.atmnet.net>; Tue, 12 Nov 1996 20:38:20 -0800 Message-ID: <01BBD0D9.713B1A40@jfbb.atmnet.net> Sender:ietf-request@ietf.org From: Jim Browning To: "'davidk@ISI.EDU'" Cc: "ietf@ietf.org" , 'IAHC Mailing List' Subject: RE: iTLDs Date: Tue, 12 Nov 1996 20:38:19 -0800 Encoding: 95 TEXT Source-Info: From (or Sender) name not authenticated. >From: davidk@ISI.EDU[SMTP:davidk@ISI.EDU] >Sent: Tuesday, November 12, 1996 7:38 AM > >> Jim Browning writes : >> >> >From: John Bevilacqua[SMTP:bevo@refuge.colorado.edu] >> >> Are you suggesting that domains at levels below those administered by the >> registries be included in the whois database? Otherwise, wouldn't this >> create an even greater desire for every entity to have a level two domain, >> so that it would be found with a whois search? > >The RIPE database that is used by the European IP registry and many TLD >administrators in Europe and other parts of the world supports creation >of lower-level domain objects including a hierarchical authorization >model for creating the entries. So yes, this is already being done and >possible. > >However, why do you need sub-level domain information registered for this ?!? > >You are looking for information on a company/person when doing a query >for a company/person name whether you want to find out about his/her >Internet phone number, E-mail address or web URL. This can be done with >any whois service by adding URL data to each company/person entry (in >fact people are already finding out how usefull this is and are doing >this in the RIPE database although it's not designed and *intended* to be >used as a white/yellow pages service for the Internet). You don't need to >have sub-level domains registered with a registry for this approach. In other words, a return to the days when most people with Email addresses were in the database and could be located with a simple lookup... >The problem remains (and might be insolvable) that person/company name >indices are a flat name space and cannot very easily be distributed to >more different *and* competing companies, and still keep a transparent >and efficient system for the user, ISPs and webbrowser implementor. > >A not-for-profit consortium might be a much better organization type for >such a service (note: this doesn't mean that Jim Fleming is not allowed >to start his own service, in contrary some competion will keep the >consortium awake) since every member can accept to handle a part of the >flat name space (example: all keys ab[a-z]*) and gets approval for adding >data to the directory services of other members (ISPs) that are managing >other parts of the index name space when becoming a member (ISP). I may be missing something (more), but if there is a single database where the information is originally entered (the whois database), can it not then be made available to any number of entities who might want to provide lookup services for the entire database? This would provide competition to develop the best set of tools. Of course, given that the providers of the directory systems would not be building their own proprietary (lucrative) database, it might be necessary to have a not-for-profit entity provide the service, thus encouraging *everyone* to register in the official database. I suspect that if the not-for-profit entity tackled the database, it could be licensed (probably without fee) to multiple directory providers, enabling the desired competition without splintering the database. >And yes, the importance of having your own nice looking DNS name will >decrease and the importance of being registered at the root or lower >down is not so much important anymore and thus running a TLD might not >be that much of a revenue source as some business people hope it will be. How awful that would be.. ;-) But OTOH competition is good.. >Solutions that only involve new TLDs might very well increase the costs >for most of us since more popular TLDs will be able to ask *higher* >prices then they do now and you need to register in more then one popular >TLD to keep up with the competion... (My elektricien is now paying $100.- >a month to get registered in all local yellow pages phone services with >just a single line *and* his customers (me) are paying that). I agree that the new TLDs will increase the need for a directory service, and think that this is one of the sources of revenue the new registries will pursuing. >However, it's our own fault if this happens because there is no reason >what so ever that we cannot design a good directory service that will >diminish the value of having a nice short recognizable/trademarked domain >name whether there are a few or thousands of TLDs. So let's use our >(valuable) time to get a good and cheap directory service running instead >of wasting our time on discussing the inevitable evolution towards more TLDs. New TLDs are inevitable for a variety of reasons, not the least of which is the desire for registry competition and the need to dilute the impact/benefit of having the appropriate .com domain. I am cross-posting this to the new IAHC list. Perhaps participation in a directory service can be made a requirement for new TLD registries, or the funds derived from the new registries can be used to fund a directory service. -- Jim Browning   Received: from cnri by ietf.org id aa22419; 13 Nov 96 8:48 EST Received: from ietf.org by CNRI.Reston.VA.US id aa09442; 13 Nov 96 8:48 EST Received: from ietf.org by ietf.org id aa22411; 13 Nov 96 8:48 EST Received: from venera.isi.edu by ietf.org id aa22407; 13 Nov 96 8:48 EST Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-25) id ; Tue, 12 Nov 1996 18:03:25 -0800 Received: from zen.isi.edu (zen-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 12 Nov 1996 18:03:09 -0800 Date: Tue, 12 Nov 1996 18:03:01 -0800 Sender:iesg-request@ietf.org From: postel@isi.edu Posted-Date: Tue, 12 Nov 1996 18:03:01 -0800 Message-Id: <199611130203.AA07631@zen.isi.edu> Received: by zen.isi.edu (5.65c/4.0.3-6) id ; Tue, 12 Nov 1996 18:03:01 -0800 To: iesg@isi.edu, iab@isi.edu, ietf@ietf.org Subject: IAHC Members Announced Subject: IAHC Members Announced Date: Tue, 12 Nov 96 14:50:00 EST From: major@linus.isoc.org Contact: Internet Society 12020 Sunrise Valley Drive Reston, VA 20191-3429 TEL 703-648-9888 FAX 703-648-9887 E-mail info@isoc.org http://www.isoc.org NEW INTERNATIONAL COMMITTEE NAMED TO STUDY DOMAIN NAME SYSTEM ISSUES WASHINGTON, DC, November 12, 1996 -- An Internet International Ad Hoc Committee (IAHC) has been named to resolve issues resulting from current international debate over a proposal to establish additional global registries and international Top Level Domain (iTLDs). "We are pleased to have attracted such a high level of leading international experts in their fields to examine these questions that are critical to the current and future growth of the Internet," Donald M. Heath, president and CEO of the Internet Society said in announcing the eleven-member committee. Heath will serve as chairman. Deliberations of the committee may lead to the establishment of new international Top Level Domains (iTLDs), adding to the current three-letter tags, such as .com, .net, and .org, that end many Internet email and World Wide Web addresses. Dr. Donald N. Telage, president of the Herndon, Virginia - based Network Solutions, Inc., which manages the InterNIC Registry administering the .com, .net, .edu, and .org top level domains, said: "Network Solutions has supported the registration process and the growth of the Internet since 1991. We have seen its evolution from a research and education tool to a powerful medium for global communication and collaboration. The National Science Foundation has played a critical role in the early governance activities, and we support the Internet Society's efforts to review issues critical to the future of Internet growth, evolution and governance. Network Solutions will participate and support this effort enthusiastically supplying our extensive operational knowledge as needed." Named to the new IAHC are: o Sally M. Abel, specializes in international trademark and trade name counseling, chairs the Internet Subcommittee of the International Trademark Association (INTA), and will represent that organization on the IAHC. Ms. Abel is the partner in charge of the Trademark Group of the law firm of Fenwick and West, a Palo Alto, Ca. firm specializing in high technology matters. O Dave Crocker, is co-founder of the Internet Mail Consortium, an industry trade association. He is also a principal with Brandenburg Consulting in Sunnyvale, Ca., a firm specializing in guiding the development and use of Internet applications. With ten years in the ARPA research community, ten years developing commercial network products and services, and extensive contributions to the Internet Engineering Task Force, he is considered an expert about the Internet, e-mail, electronic commerce, Internet operation and the Internet standards process. o Geoff Huston is the technical manager of Australia's Telstra Internet and is responsible for the architecture and operations of its service. He formerly was technical manager of the Australian Academic and Research Network, and was largely responsible for the introduction and subsequent development of the Internet into Australia. o David W. Maher, is a partner at the law firm of Sonnenschein Nath & Rosenthal, of Chicago, IL, is a registered patent attorney and has extensive experience in intellectual property and entertainment law. Principal outside trademark counsel for several nationwide companies, he has served as special counsel to the American Bar Association for telecommunications matters. o Perry E. Metzger is the president of New York - based Piermont Information Systems Inc., a consulting firm specializing in communications and computer systems security. He has worked with the New York financial community for many years and is active in the Internet Engineering Task Force's (IETF) security area, chairing the group's Simple Public Key Infrastructure working group. o Jun Murai is associate professor of Faculty of Environmental Information at Keio University in Tokyo. He developed JUNET, Japan's first UUCP network and the WIDE Internet, Japan's first IP network. He is president of the Japan Network Information Center (JPNIC) and serves as adjunct professor at the Institute of Advanced Studies of the United Nations University in Tokyo. o Hank Nussbacher, is an independent networking consultant, currently works with IBM Israel as Internet Technology Manager and has been responsible for all aspects in establishing IBM Israel as a major ISP in Israel. He also consults to the Israeli inter-university consortium and is on the board of directors of the Internet Society of Israel. o Robert Shaw is an advisor on Global Information Infrastructure (GII) issues at the International Telecommunication Union (ITU). The ITU, based in Geneva, Switzerland, is a United Nations treaty organization within which governments and the private sector coordinate global telecom networks and services. o George Strawn is with the US National Science Foundation (NSF), which has funded Internet development for research and education. Mr. Strawn has been involved with the NSF's Internet activities for the last five years and also co-chairs the Federal Networking Council, a US government committee coordinating inter-agency Internet activities, including funding for administrative activities, such as the Internet Assigned Numbers Authority (IANA). o Albert Tramposch is senior legal counsellor at the World Intellectual Property Organization (WIPO) in Geneva. WIPO is a United Nations organization which has responsibility for the promotion of the protection of intellectual property throughout the world. It also administers various treaties dealing with legal and administrative aspects of intellectual property, including the international registration of trademarks. In addition, Stuart Levi, a partner in the New York Office of Skadden, Arps, Slate, Meagher & Flom, and the head of the firm's Computer and Information Technology Practice, will serve as outside counsel supporting the IAHC. "The IAHC will be charged with fairly and openly looking at the complex issues surrounding the current domain name and registry situation, including trademark and infringement, economics and administration of registry operations, dispute policies, fees and iTLDs," Heath said. He anticipates the Committee reaching reasonable consensus on issues surfaced, sometime in January. A subset of the IAHC will seek to implement its recommendations very shortly after that. To meet its aggressive schedule, the widely dispersed group will primarily operate online, over the Internet. Interested parties throughout the Internet world will be able to participate in the IAHC's process, through an electronic mail list service and a Web site that are being established. Discussions, evaluations and decisions will be available for public inspection. An archive, and relevant documents, will be available public comment at the Web site which will be established by November 15 at http://www.iahc.org. To subscribe to the IAHC's email list service, send email with the word "subscribe" to: iahc-discuss-request@iahc.org. # # # # # # #   Received: from ietf.org by ietf.org id aa24275; 13 Nov 96 8:51 EST Received: from zephyr.isi.edu by ietf.org id aa23443; 13 Nov 96 8:50 EST Received: by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 12 Nov 1996 20:12:57 -0800 Date: Tue, 12 Nov 1996 20:12:57 -0800 Sender:ietf-request@ietf.org From: Jon Postel Message-Id: <199611130412.AA13370@zephyr.isi.edu> To: ietf@ietf.org Subject: directory of companies (was Re: iTLDs) Source-Info: From (or Sender) name not authenticated. Hi. Here is a service that can reduce the pressure on domain names to be a directory service. Try this out! http://netpart.com/free/search.html It is not perfect, but it is an indication of something that can be done to make life better, and reduce the importance of having an obvious domain name. --jon.   Received: from ietf.org by ietf.org id aa24287; 13 Nov 96 8:51 EST Received: from zephyr.isi.edu by ietf.org id aa23577; 13 Nov 96 8:50 EST Received: from brind.isi.edu (old-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 12 Nov 1996 15:40:40 -0800 Sender:ietf-request@ietf.org From: davidk@isi.edu Posted-Date: Tue, 12 Nov 1996 15:37:38 -0800 (PST) Message-Id: <9611122337.AA00892@brind.isi.edu> Received: by brind.isi.edu (4.1/4.0.3-6) id ; Tue, 12 Nov 96 15:37:38 PST Subject: Re: iTLDs To: Jim Browning Date: Tue, 12 Nov 1996 15:37:38 -0800 (PST) Cc: ietf@ietf.org In-Reply-To: <01BBD093.38277320@jfbb.atmnet.net> from "Jim Browning" at Nov 12, 96 12:15:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3324 Source-Info: From (or Sender) name not authenticated. Hi Jim, > Jim Browning writes : > > >From: John Bevilacqua[SMTP:bevo@refuge.colorado.edu] > > Are you suggesting that domains at levels below those administered by the > registries be included in the whois database? Otherwise, wouldn't this > create an even greater desire for every entity to have a level two domain, > so that it would be found with a whois search? The RIPE database that is used by the European IP registry and many TLD administrators in Europe and other parts of the world supports creation of lower-level domain objects including a hierarchical authorization model for creating the entries. So yes, this is already being done and possible. However, why do you need sub-level domain information registered for this ?!? You are looking for information on a company/person when doing a query for a company/person name whether you want to find out about his/her Internet phone number, E-mail address or web URL. This can be done with any whois service by adding URL data to each company/person entry (in fact people are already finding out how usefull this is and are doing this in the RIPE database although it's not designed and *intended* to be used as a white/yellow pages service for the Internet). You don't need to have sub-level domains registered with a registry for this approach. The problem remains (and might be insolvable) that person/company name indices are a flat name space and cannot very easily be distributed to more different *and* competing companies, and still keep a transparent and efficient system for the user, ISPs and webbrowser implementor. A not-for-profit consortium might be a much better organization type for such a service (note: this doesn't mean that Jim Fleming is not allowed to start his own service, in contrary some competion will keep the consortium awake) since every member can accept to handle a part of the flat name space (example: all keys ab[a-z]*) and gets approval for adding data to the directory services of other members (ISPs) that are managing other parts of the index name space when becoming a member (ISP). And yes, the importance of having your own nice looking DNS name will decrease and the importance of being registered at the root or lower down is not so much important anymore and thus running a TLD might not be that much of a revenue source as some business people hope it will be. Solutions that only involve new TLDs might very well increase the costs for most of us since more popular TLDs will be able to ask *higher* prices then they do now and you need to register in more then one popular TLD to keep up with the competion... (My elektricien is now paying $100.- a month to get registered in all local yellow pages phone services with just a single line *and* his customers (me) are paying that). However, it's our own fault if this happens because there is no reason what so ever that we cannot design a good directory service that will diminish the value of having a nice short recognizable/trademarked domain name whether there are a few or thousands of TLDs. So let's use our (valuable) time to get a good and cheap directory service running instead of wasting our time on discussing the inevitable evolution towards more TLDs. David K. Disclaimer: this is my personal opinion at this point in time. ---   Received: from ietf.org by ietf.org id aa24744; 13 Nov 96 8:52 EST Received: from taunivm.tau.ac.il by ietf.org id aa24068; 13 Nov 96 8:51 EST Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 5282; Wed, 13 Nov 96 07:37:11 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 2441; Wed, 13 Nov 1996 07:37:11 +0200 Date: Wed, 13 Nov 96 07:34:57 IST Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: iTLDs To: Steve Hultquist , Keith Moore cc: Hank Nussbacher , ietf@ietf.org In-Reply-To: Message of Tue, 12 Nov 1996 16:17:05 -0700 from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611130852.aa24068@ietf.org> Source-Info: From (or Sender) name not authenticated. On Tue, 12 Nov 1996 16:17:05 -0700 you said: >Hmmm... Shouldn't the response be to build that search engine and then >suggest to either one of those companies or a third party search engine >provider that they host it for the "good of the 'net"? I'm not sure I >want the "browser wars" to turn into the "site lookup wars", with >incompatibility and redundancy all over the place. We have more >difficult problems to solve that need that kind of energy. See: http://netpart.com/free/search.html as an example of what might be done (got this link from Jon). It has a long way to go but it is a start in the right direction. >I agree, however, that this capability will go a long way towards making >the new TLDs actually usable. Without it, I see massive end-user >frustration as the initial result from the new domains. And that's >something we definitely *don't* need! > >ssh >-- >Steve Hultquist Business, system, network, and Internet >Worldwide Solutions, Inc. Engineering >Boulder, Colorado, USA 303.581.0800 http://www.wwsi.com Hank Nussbacher Israel   Received: from ietf.org by ietf.org id aa24752; 13 Nov 96 8:52 EST Received: from weeble.lut.ac.uk by ietf.org id aa24411; 13 Nov 96 8:52 EST Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vNd4C-0006zV-00; Wed, 13 Nov 1996 11:01:12 +0000 Date: Wed, 13 Nov 1996 11:01:12 +0000 (GMT) Sender:ietf-request@ietf.org From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Keith Moore cc: Hank Nussbacher , ietf@ietf.org Subject: Re: iTLDs In-Reply-To: <199611122123.QAA15821@ig.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Tue, 12 Nov 1996, Keith Moore wrote: > > What we need is for Netscape and Microsoft to build into their > > 4.0 versions of their browsers a 'Site Lookup' button, that > > takes a user to a Web form that allows lookup for company name > > by substring or phonetic match and using the Internic/RIPE/APNIC > > DN databases as the base for the information supplied. > > Yes, this is precisely what's needed. Sounds a bit like WHOIS++ with its query routing/referals is called for here. And crumbs, its a technology that's already got RFCs written about it and software being deployed (and tested for interoperability). Sounds just like what the doctor ordered*. Tatty bye, Jim'll * Well this doctor anyway, but I'm a big WHOIS++ fan so that's not surprising really. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. *   Received: from ietf.org by ietf.org id aa24860; 13 Nov 96 8:53 EST Received: from taunivm.tau.ac.il by ietf.org id aa24681; 13 Nov 96 8:52 EST Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 5288; Wed, 13 Nov 96 07:40:06 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 2460; Wed, 13 Nov 1996 07:40:06 +0200 Date: Wed, 13 Nov 96 07:38:36 IST Sender:ietf-request@ietf.org From: Hank Nussbacher Subject: Re: iTLDs To: Dave Crocker , moore@cs.utk.edu cc: Hank Nussbacher , ietf@ietf.org In-Reply-To: Message of Tue, 12 Nov 1996 15:36:52 -0800 from MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <9611130853.aa24681@ietf.org> Source-Info: From (or Sender) name not authenticated. On Tue, 12 Nov 1996 15:36:52 -0800 you said: >At 1:23 PM -0800 11/12/96, Keith Moore wrote: >>> What we need is for Netscape and Microsoft to build into their >>> 4.0 versions of their browsers a 'Site Lookup' button, that >> >>Yes, this is precisely what's needed. > > uhh, what data bases are to be consulted? How are they found? >What standards are used to consult them? Which databases: All whois/rwhois databases run by iTLD registries. How are they found: All those registered in the root nameservers must be running one. Standard: BCP. > >d/ > >-------------------- >Dave Crocker +1 408 246 8253 >Brandenburg Consulting fax: +1 408 249 6205 >675 Spruce Dr. dcrocker@brandenburg.com >Sunnyvale CA 94086 USA http://www.brandenburg.com > >Internet Mail Consortium http://www.imc.org, info@imc.org > > Hank Nussbacher Israel   Received: from ietf.org by ietf.org id aa27684; 13 Nov 96 9:08 EST Received: from mailer.dir.org by ietf.org id aa26776; 13 Nov 96 9:05 EST Received: from nassau.dir.org (nassau.dir.org [194.205.62.19]) by mailer.dir.org (8.6.12/8.6.9) with SMTP id JAA01236; Wed, 13 Nov 1996 09:05:03 -0500 Message-ID: <3289FEC6.1907@dir.org> Date: Wed, 13 Nov 1996 09:00:54 -0800 Sender:ietf-request@ietf.org From: John Harvey Reply-To: john.harvey@dir.org Organization: Directory Corporation X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Steve Hultquist CC: paul@vix.com, moore@cs.utk.edu, ietf@ietf.org Subject: Re: iTLDs - Directory. References: <199611122317.QAA02827@aspen.wwsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Increasing TLD to address ***.COM or ***.CAR or ***.PTY, if left unchecked would invite multiple registrations in each TLD. As new TLDs are introduced there will emerge the associated phychological kudos of being represented in all domains, increasing the TLD hop and search mentality, whilst confounding and frustrating the TLD functionality even more. To use the well quoted verse Paul A Vixie wrote, Sun Nov 10: > What I need and what the other 98% of Internet users who have not yet > signed on need, is a way to say "does lucia's pizza in woodside have a > URL?" and get something useful -- an authoritative "no" or a short/accurate > list of possible "yes"'s. > I agree 100%. This would also make multiple TLD registrations pointless. In monopolistic times, Telcos operated directory assistance services to stimulate call revenue. In the competitive Internet environment, users want a centralized directory service, but do their Access Providers? The bottom line is, how do Access Providers profit from, and "virtual site customers" be included in, a universal directory service? What have Access Providers got to do with top tier functionality. Inviting Access Providers to "service" their customer base, would significantly reduce the intense market demand for multiple TLD name space - overnight. Steve Hultquist wrote Tue Nov 12: > > >>>>> "Keith" == Keith Moore writes: > > >> What we need is for Netscape and Microsoft to build into their 4.0 > >> versions of their browsers a 'Site Lookup' button, that takes a user > >> to a Web form that allows lookup for company name by substring or > >> phonetic match and using the Internic/RIPE/APNIC DN databases as the > >> base for the information supplied. > > Keith> Yes, this is precisely what's needed. > > Hmmm... Shouldn't the response be to build that search engine and then > suggest to either one of those companies or a third party search engine > provider that they host it for the "good of the 'net"? I'm not sure I > want the "browser wars" to turn into the "site lookup wars", with > incompatibility and redundancy all over the place. We have more > difficult problems to solve that need that kind of energy. > > I agree, however, that this capability will go a long way towards making > the new TLDs actually usable. Without it, I see massive end-user > frustration as the initial result from the new domains. And that's > something we definitely *don't* need! > Absolutely. John. -- __________________________________________________________________ John Harvey - Director of On-line Information Services. mailto:john.harvey@dir.org Fax + 1 242 326 4105 http://www.dir.org Directory Corporation, Universal House, Nassau, PO N-3401, Bahamas __________________________________________________________________   Received: from ietf.org by ietf.org id aa29435; 13 Nov 96 9:14 EST Received: from cnri by ietf.org id al29057; 13 Nov 96 9:13 EST Received: from ng.netgate.net by CNRI.Reston.VA.US id aa03307; 13 Nov 96 2:16 EST Received: from [205.214.160.148] (d107.netgate.net [205.214.160.145]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id XAA03483 for ; Tue, 12 Nov 1996 23:26:12 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 22:35:21 -0800 To: IETF@CNRI.Reston.VA.US Sender:ietf-request@ietf.org From: Donald Heath Subject: Press Release Source-Info: From (or Sender) name not authenticated. NEW INTERNATIONAL COMMITTEE NAMED TO RESOLVE DOMAIN NAME SYSTEM ISSUES WASHINGTON, DC, November 12, 1996 -- An Internet International Ad Hoc Committee (IAHC) has been named to resolve issues resulting from current international debate over a proposal to establish additional global registries and international Top Level Domains (iTLDs). "We are pleased to have attracted such a high level of leading international experts in their fields to examine these questions that are critical to the current and future growth of the Internet," Donald M. Heath, president and CEO of the Internet Society said in announcing the eleven-member committee. Heath will serve as chairman. Deliberations of the committee may lead to the establishment of new international Top Level Domains (iTLDs), adding to the current three-letter tags, such as .com, .net, and .org, that end many Internet email and World Wide Web addresses. Dr. Donald N. Telage, president of the Herndon, Virginia - based Network Solutions, Inc., which manages the InterNIC Registry administering the .com, .net, .edu, and .org top level domains, said: "Network Solutions has supported the registration process and the growth of the Internet since 1991. We have seen its evolution from a research and education tool to a powerful medium for global communication and collaboration. The National Science Foundation has played a critical role in the early governance activities, and we support the Internet Society's efforts to review issues critical to the future of Internet growth, evolution and governance. Network Solutions will participate and support this effort enthusiastically supplying our extensive operational knowledge as needed." Named to the new IAHC are: .Sally M. Abel, specializes in international trademark and trade name counseling, chairs the Internet Subcommittee of the International Trademark Association (INTA), and will represent that organization on the IAHC. Ms. Abel is the partner in charge of the Trademark Group of the law firm of Fenwick and West, a Palo Alto, Ca. firm specializing in high technology matters. .Dave Crocker, is co-founder of the Internet Mail Consortium, an industry trade association. He is also a principal with Brandenburg Consulting in Sunnyvale, Ca., a firm specializing in guiding the development and use of Internet applications. With ten years in the ARPA research community, ten years developing commercial network products and services, and extensive contributions to the Internet Engineering Task Force, he is considered an expert about the Internet, email, electronic commerce, Internet operation and the Internet standards process. .Geoff Huston is the technical manager of Australia's Telstra Internet and is responsible for the architecture and operations of its service. He formerly was technical manager of the Australian Academic and Research Network, and was largely responsible for the introduction and subsequent development of the Internet into Australia. .David W. Maher, a partner at the law firm of Sonnenschein Nath & Rosenthal, of Chicago, IL, is a registered patent attorney and has extensive experience in intellectual property and entertainment law. Principal outside trademark counsel for several nationwide companies, he has served as special counsel to the American Bar Association for telecommunications matters. .Perry E. Metzger is the president of New York - based Piermont Information Systems Inc., a consulting firm specializing in communications and computer systems security. He has worked with the New York financial community for many years and is active in the Internet Engineering Task Force's (IETF) security area, chairing the group's Simple Public Key Infrastructure working group. .Jun Murai is an associate professor on the Faculty of Environmental Information at Keio University in Tokyo. He developed JUNET, Japan's first UUCP network and the WIDE Internet, Japan's first IP network. He is president of the Japan Network Information Center (JPNIC) and serves as adjunct professor at the Institute of Advanced Studies of the United Nations University in Tokyo. .Hank Nussbacher, an independent networking consultant, currently works with IBM Israel as Internet Technology Manager and has been responsible for all aspects in establishing IBM Israel as a major ISP in Israel. He also consults for the Israeli inter-university consortium and is on the board of directors of the Internet Society of Israel. .Robert Shaw is an advisor on Global Information Infrastructure (GII) issues at the International Telecommunication Union (ITU). The ITU, based in Geneva, Switzerland, is a United Nations treaty organization within which governments and the private sector coordinate global telecom networks and services. .George Strawn is with the US National Science Foundation (NSF), which has funded Internet development for research and education. Mr. Strawn has been involved with the NSF's Internet activities for the last five years and also co-chairs the Federal Networking Council, a US government committee coordinating inter-agency Internet activities, including funding for administrative activities, such as the Internet Assigned Numbers Authority (IANA). .Albert Tramposch is senior legal counsellor at the World Intellectual Property Organization (WIPO) in Geneva. WIPO is a United Nations organization which has responsibility for the promotion of the protection of intellectual property throughout the world. It also administers various treaties dealing with legal and administrative aspects of intellectual property, including the international registration of trademarks. In addition, Stuart Levi, a partner in the New York Office of Skadden, Arps, Slate, Meagher & Flom, and the head of the firm's Computer and Information Technology Practice, will serve as outside counsel supporting the IAHC. "The IAHC will be charged with fairly and openly looking at the complex issues surrounding the current domain name and registry situation, including trademark and infringement, economics and administration of registry operations, dispute resolution policies, fees and iTLDs," Heath said. He anticipates the Committee reaching reasonable consensus on issues identified, sometime in January. A subset of the IAHC will seek to implement its recommendations very shortly after that. To meet its aggressive schedule, the widely dispersed group will primarily operate online, over the Internet. Interested parties throughout the Internet world will be able to participate in the IAHC's process, through an electronic mail list service and a Web site that are being established. Discussions, evaluations and decisions will be available for public inspection. An archive, and relevant documents, will be available for public comment at the Web site which will be established by November 15 at http://www.iahc.org. To subscribe to the IAHC's email list service, send email with the word "subscribe" to: iahc-discuss-request@iahc.org. # # # # # # #   Received: from ietf.org by ietf.org id aa03548; 13 Nov 96 10:08 EST Received: from IG.CS.UTK.EDU by ietf.org id aa03169; 13 Nov 96 10:06 EST Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id KAA11021; Wed, 13 Nov 1996 10:00:09 -0500 (EST) Message-Id: <199611131500.KAA11021@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ Sender:ietf-request@ietf.org From: Keith Moore To: Jon Knight cc: Keith Moore , Hank Nussbacher , ietf@ietf.org Subject: Re: iTLDs In-reply-to: Your message of "Wed, 13 Nov 1996 11:01:12 GMT." Date: Wed, 13 Nov 1996 10:00:08 -0500 X-Orig-Sender: moore@cs.utk.edu Source-Info: From (or Sender) name not authenticated. > > > What we need is for Netscape and Microsoft to build into their > > > 4.0 versions of their browsers a 'Site Lookup' button, that > > > takes a user to a Web form that allows lookup for company name > > > by substring or phonetic match and using the Internic/RIPE/APNIC > > > DN databases as the base for the information supplied. > > > > Yes, this is precisely what's needed. > > Sounds a bit like WHOIS++ with its query routing/referals is called for > here. That would work, but it would probably be overkill. The nice thing about this approach is that very simple protocols (not to mention protocols that are already deployed) will do. Keith   Received: from ietf.org by ietf.org id aa06253; 13 Nov 96 10:42 EST Received: from cnri by ietf.org id aa05960; 13 Nov 96 10:39 EST Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa13209; 13 Nov 96 10:39 EST Received: by ginger.lcs.mit.edu id AA22021; Wed, 13 Nov 96 10:38:26 -0500 Date: Wed, 13 Nov 96 10:38:26 -0500 Sender:ietf-request@ietf.org From: Noel Chiappa Message-Id: <9611131538.AA22021@ginger.lcs.mit.edu> To: ietf@CNRI.Reston.VA.US Subject: Re: iTLDs Cc: jnc@ginger.lcs.mit.edu Source-Info: From (or Sender) name not authenticated. Umm, guys'n'gals, this discussion, while initially one with policy implications of broad interest, seems to have moved into an area (distributed lookups) that don't really seem like an issue for the main IEFT list. Maybe you could take it elsewhere? Thanks... Noel   Received: from ietf.org by ietf.org id aa07097; 13 Nov 96 11:00 EST Received: from ietf.org by ietf.org id aa06271; 13 Nov 96 10:41 EST To: IETF-Announce: ; Subject: IETF PGP Key Signing Party Sender:ietf-announce-request@ietf.org From: "Theodore Y. Ts'o" Date: Wed, 13 Nov 1996 10:41:56 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611131041.aa06271@ietf.org> Once again, we will be holding a PGP Key signing party at the IETF meeting in San Jose. We have been scheduled to meet at 10:30pm on the evening of Wednesday, December 11, 1996, in the Garden room. The procedure we will use is the following: o People who wish to participate should email an ASCII extract of their PGP public key to by NOON on Wednesday of the week of the IETF meeting. Please include a subject line of "IETF PGP KEY". (Note, this is earlier than I was accepting keys than before. Please get them in on-time!!) 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 10pm 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 in the file /pub/tytso/ietf.asc and /pub/tytso/ietf.pgp. o At 10:30pm, come prepared with the PGP Key fingerprint of your PGP public key; we will have handouts with all of the key fingerprints of the keys that people have mailed in. o In turn, readers at the front of the room will recite people's keys; as your key fingerprint is read, stand up, and at the end of reading of your PGP key fingerprint, acknowledge that the fingerprint as read was correct. o Later that evening, or perhaps when you get home, you can sign the keys corresponding to the fingerprints which you were able to verify on the handout; note that it is advisable that you only sign keys of people when you have personal knowledge that the person who stood up during the reading of his/her fingerprint really is the person which he/she claimed to be. o Submit the keys you have signed to the PGP keyservers. A good one to use is the one at MIT: simply send mail containing the ascii armored version of your PGP public key to . Note that you don't have 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   Received: from ietf.org by ietf.org id aa08959; 13 Nov 96 11:18 EST Received: from cnri by ietf.org id aa08607; 13 Nov 96 11:16 EST Received: from m-ws.vol.cz by CNRI.Reston.VA.US id aa14371; 13 Nov 96 11:16 EST Received: from nvasa (tabor2.vol.cz [194.166.38.195]) by m-ws.vol.cz (8.7.5/8.6.9) with SMTP id RAA16390 for ; Wed, 13 Nov 1996 17:15:05 +0100 Message-Id: <199611131615.RAA16390@m-ws.vol.cz> Comments: Authenticated sender is Sender:ietf-request@ietf.org From: "Nabytek VASA s. r. o." Organization: Nabytek VASA s. r. o. To: ietf@CNRI.Reston.VA.US Date: Wed, 13 Nov 1996 17:14:54 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42a) Source-Info: From (or Sender) name not authenticated. help   Received: from ietf.org by ietf.org id aa13090; 13 Nov 96 12:01 EST Received: from zephyr.isi.edu by ietf.org id aa12452; 13 Nov 96 11:59 EST Received: from zen.isi.edu (zen-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 13 Nov 1996 08:58:12 -0800 Date: Wed, 13 Nov 1996 08:58:04 -0800 Sender:ietf-request@ietf.org From: postel@isi.edu Posted-Date: Wed, 13 Nov 1996 08:58:04 -0800 Message-Id: <199611131658.AA12025@zen.isi.edu> Received: by zen.isi.edu (5.65c/4.0.3-6) id ; Wed, 13 Nov 1996 08:58:04 -0800 To: dcrocker@brandenburg.com, moore@cs.utk.edu, HANK@taunivm.tau.ac.il Subject: Re: iTLDs Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. Hi. Who cares what databases are consulted by what methods. Let the market decide. What i want (an maybe what a lot of users want) is a way to enter a company name and get back a link to its home page. The seract tool at http://netpart.com/free/search.html does this, to some extent. It needs to be better. Let's encourage others to develop similar tools. Let's have some competition. Let the tool that best makes the users happy win. --jon.   Received: from ietf.org by ietf.org id aa17330; 13 Nov 96 13:04 EST Received: from cnri by ietf.org id aa17201; 13 Nov 96 13:01 EST Received: from hail.ncr.disa.mil by CNRI.Reston.VA.US id aa17073; 13 Nov 96 13:01 EST Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id MAA10809; Wed, 13 Nov 1996 12:49:28 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA847918151; Wed, 13 Nov 96 12:19:08 EST Date: Wed, 13 Nov 96 12:19:08 EST Sender:ietf-request@ietf.org From: "C.Joe Pasquariello" Message-Id: <9610138479.AA847918151@ncr.disa.mil> To: IETF@CNRI.Reston.VA.US, poised@tis.com, newdom@vrx.net Subject: "Thank You" Jim Fleming ! Source-Info: From (or Sender) name not authenticated. Mr FLEMING - As a 'lurker' for the most part, I want you to know that your many messages concerning DNS, etc to various lists in recent days have had one positive effect on me. I have come away with increased respect for, and confidence in, the many senior members and leaders of the I* community for the extraordinary patience and thoroughness with which they have responded to your many unfounded personal attacks and generally destructive comments. For my part, I wish that you would 'leave' these lists and come back after you have time to reflect on the courtesy they have extended to you, and which I hope you would reciprocate. For your consideration, C.Joe Pasquariello US/DoD/DISA   Received: from ietf.org by ietf.org id aa21440; 13 Nov 96 14:00 EST Received: from gw.home.vix.com by ietf.org id aa21065; 13 Nov 96 13:58 EST Received: by gw.home.vix.com id KAA13818; Wed, 13 Nov 1996 10:57:29 -0800 (PST) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: from localhost (localhost [127.0.0.1]) by wisdom.home.vix.com (8.8.2/8.8.2) with SMTP id KAA13087 for ; Wed, 13 Nov 1996 10:57:27 -0800 (PST) Message-Id: <199611131857.KAA13087@wisdom.home.vix.com> X-Authentication-Warning: wisdom.home.vix.com: localhost [127.0.0.1] didn't use HELO protocol To: ietf@ietf.org Subject: Re: iTLDs - Directory. In-reply-to: Your message of "Wed, 13 Nov 1996 09:00:54 PST." <3289FEC6.1907@dir.org> Date: Wed, 13 Nov 1996 10:57:27 -0800 Sender:ietf-request@ietf.org From: Paul A Vixie Source-Info: From (or Sender) name not authenticated. > Increasing TLD to address ***.COM or ***.CAR or ***.PTY, if left > unchecked would invite multiple registrations in each TLD. > As new TLDs are introduced there will emerge the associated > phychological kudos of being represented in all domains, increasing the > TLD hop and search mentality, whilst confounding and frustrating the TLD > functionality even more. Agreed. This is why I so strongly support the creation of new iTLD's: it will make all attempts to trademark lion-king. as obviously silly as trademarking lion-king.cs.berkeley.edu is now. Let a thousand points of confusion bloom, let the namespace be driven the rest of the way to hell (in a handbasket I shall help weave) and then let folks discover that the Internet has no directory service and then let us go about solving that. Some folks want COM to have competition because they want some of the money. I want COM to have competition so that the idea of using DNS as a directory service will be more obviously absurd to more and more and more people.   Received: from ietf.org by ietf.org id aa23854; 13 Nov 96 14:39 EST Received: from Kitten.mcs.com by ietf.org id aa23728; 13 Nov 96 14:37 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id NAA27818; Wed, 13 Nov 1996 13:36:41 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id NAA07225; Wed, 13 Nov 1996 13:36:38 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id NAA18226; Wed, 13 Nov 1996 13:36:37 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611131936.NAA18226@Jupiter.Mcs.Net> Subject: Re: iTLDs - Directory. To: Paul A Vixie Date: Wed, 13 Nov 1996 13:36:36 -0600 (CST) Cc: ietf@ietf.org In-Reply-To: <199611131857.KAA13087@wisdom.home.vix.com> from "Paul A Vixie" at Nov 13, 96 10:57:27 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > > > Increasing TLD to address ***.COM or ***.CAR or ***.PTY, if left > > unchecked would invite multiple registrations in each TLD. > > As new TLDs are introduced there will emerge the associated > > phychological kudos of being represented in all domains, increasing the > > TLD hop and search mentality, whilst confounding and frustrating the TLD > > functionality even more. > > Agreed. This is why I so strongly support the creation of new iTLD's: it > will make all attempts to trademark lion-king. as obviously silly as > trademarking lion-king.cs.berkeley.edu is now. Let a thousand points of > confusion bloom, let the namespace be driven the rest of the way to hell > (in a handbasket I shall help weave) and then let folks discover that the > Internet has no directory service and then let us go about solving that. > > Some folks want COM to have competition because they want some of the money. > I want COM to have competition so that the idea of using DNS as a directory > service will be more obviously absurd to more and more and more people. Actually, I want COM to have competition because I believe it will do ALL of the following: 1) Destroy an improper monopoly. 2) Improve service to customers of the TLD registries. 3) Drop prices by anywhere from 50 to 90%. 4) FORCE the implementation of a REAL directory service as a "front-end" to the DNS. That is, I want the Yellow Pages (more or less) to show up. DNS names have value. But that value is SYNTHETIC (ie: you have it now and 500,000 people know what it is, that's valuable -- just like your ADDRESS is in the real world). Right now the synthesis of things is such that we have (1) high prices, (2) poor service, (3) dictatorial implementations, (4) DNS as a battlefield for corporations who only have one possible place to reasonably register, and (5) no incentive for a WG to form that will address point (4) above. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa24300; 13 Nov 96 14:47 EST Received: from nirvana.genesyslab.com by ietf.org id aa24185; 13 Nov 96 14:46 EST Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id LAA29938; Wed, 13 Nov 1996 11:45:33 -0800 (PST) Received: (from egoshin@localhost) by giant.genesyslab.com (8.7.5/8.7.3) id LAA16732; Wed, 13 Nov 1996 11:44:57 -0800 (PST) Date: Wed, 13 Nov 1996 11:44:57 -0800 (PST) Sender:ietf-request@ietf.org From: Leonid Egoshin Message-Id: <199611131944.LAA16732@giant.genesyslab.com> To: dcrocker@brandenburg.com, moore@cs.utk.edu Subject: Re: iTLDs Cc: HANK@taunivm.tau.ac.il, ietf@ietf.org Source-Info: From (or Sender) name not authenticated. >From: Keith Moore > >The solution is to encourage the development/deployment of extensive >data bases of company names that happen to have a presence on >the Internet. >Nah. We don't have to solve the general distributed directory problem. >And for a single-purpose database, like one that matches company names >and returns pointers to their web pages, the solution can be quite simple. > We find some-company in the following cases: 1) We already have a business with it. We try find letters/e-mails/or some documentation to obtain street address or Internet name. Without any doubts directory service can help us in this case. 2) We haven't business with it but we know company profile or another additional information. Also dircetory service can help us. 3) We read ads about some product and try to find company to obtain more information. In many cases we don't remember any coordinates about company exclude some bright "names" in this ads. What we would find ? This name. It is the company deal to support me (as customer) this distinctive name and search system for it. Just now it is company.com in DNS. Can central directory service help us in this ? No - we know about problem with duplicated company names in different regions. We need to setup some search system in some division (regional or trade sectors) which can find company on single word (may be composed). And it can be connected to DNS wthout doubts - if this will not be done then using of .COM for this purpose would continue - DNS has attribute to simple and universal search. Unfortunately DNS has also problem with duplicated company/trademarks/etc names. And In my mind a focusing on WWW only is error - there is also non-interactive E-mail, FTP, etc. Just now I think about trademark due to very correlation in point (3) and trademark behaviour - it has the same trade sector and can die with loss of interest to it. But if somebody can suggest any another naming it would be also beautifull. - Leonid Yegoshin, LY22   Received: from ietf.org by ietf.org id aa27372; 13 Nov 96 15:33 EST Received: from cnri by ietf.org id aa27225; 13 Nov 96 15:31 EST Received: from fractal.chaos.com by CNRI.Reston.VA.US id aa21664; 13 Nov 96 15:31 EST Received: from fractal.chaos.com by fractal.chaos.com (NTMail 3.02.11) with ESMTP id na003575 for ; Wed, 13 Nov 1996 15:29:45 -0500 Message-Id: <3.0.32.19961113152945.00a92550@fractal.chaos.com> X-Sender: amr@fractal.chaos.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Wed, 13 Nov 1996 15:29:45 -0500 To: "C.Joe Pasquariello" Sender:ietf-request@ietf.org From: Tony Rutkowski Subject: Re: "Thank You" Jim Fleming ! Cc: IETF@CNRI.Reston.VA.US, poised@tis.com, newdom@vrx.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. Joe, > I have come away with increased respect for, and confidence in, the > many senior members and leaders of the I* community for the > extraordinary patience and thoroughness with which they have responded > to your many unfounded personal attacks and generally destructive > comments. > > For my part, I wish that you would 'leave' these lists and come back > after you have time to reflect on the courtesy they have extended to > you, and which I hope you would reciprocate. Giorno.. As another senior member of the world community, I'd like to suggest that Jim is actually undertaking the valuable task of asking questions about existing institutions and roles from an alternative perspective. OK - he's been incredibly "productive" and sometimes bothersome, but nothing that warrants the characterization of "personal attacks and...destructive comments." He's been questioning direction, roles and authority, not personal integrity or competence. That's the sort of reaction we used to hear in the CCITT about the Internet community not too long ago. It's not going to serve the IETF well to force out people because they ask questions you don't like. I certainly wouldn't expect this in an organization that takes pride in accommodating diverse views and adapting to change. If nothing else, life on these lists (such as it is) would be much duller without Jim. ciao, --tony   Received: from ietf.org by ietf.org id aa00004; 13 Nov 96 16:37 EST Received: from cnri by ietf.org id aa29831; 13 Nov 96 16:33 EST Received: from hail.ncr.disa.mil by CNRI.Reston.VA.US id aa23330; 13 Nov 96 16:33 EST Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id QAA13637; Wed, 13 Nov 1996 16:21:03 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA847931491; Wed, 13 Nov 96 16:29:09 EST Date: Wed, 13 Nov 96 16:29:09 EST Sender:ietf-request@ietf.org From: "C.Joe Pasquariello" Message-Id: <9610138479.AA847931491@ncr.disa.mil> To: Tony Rutkowski Cc: IETF@CNRI.Reston.VA.US, poised@tis.com, newdom@vrx.net Subject: Re[2]: "Thank You" Jim Fleming ! Source-Info: From (or Sender) name not authenticated. OH REALLY TONY ! I'm surprised that you don't find the following Fleming comment of today [like others over recent days] anything BUT unfounded, personal and destructive! " 3. The appointed leaders in the IETF (and other I* leaders) have not necessarily signed up to be anything more than figureheads. As they are "pushed" from below, by the membership, they have a difficult time devoting their life to some cause when the reality of the world is that they mostly work for some company and mainly protect that company's interests, instead of the Internet's interest, or the people's interest." - Jim Fleming; 13 Nov 96 See also Eastlake's comments of today on this point. I fail to see your point on the old CCITT/Internet animosity. Happily there is currently a growing degree of respect and cooperation today between the Internet community and the ITU-T. This has come about through mutual respect and civility on both sides - NOT through the sort of dialog being fostered by Mr Fleming. "Valuable" indeed ! C.Joe P--> US/DoD/DISA ______________________________ Reply Separator _________________________________ Subject: Re: "Thank You" Jim Fleming ! Author: Tony Rutkowski at smtp Date: 11/13/96 3:54 PM Joe, > I have come away with increased respect for, and confidence in, the > many senior members and leaders of the I* community for the > extraordinary patience and thoroughness with which they have responded > to your many unfounded personal attacks and generally destructive > comments. > > For my part, I wish that you would 'leave' these lists and come back > after you have time to reflect on the courtesy they have extended to > you, and which I hope you would reciprocate. Giorno.. As another senior member of the world community, I'd like to suggest that Jim is actually undertaking the valuable task of asking questions about existing institutions and roles from an alternative perspective. OK - he's been incredibly "productive" and sometimes bothersome, but nothing that warrants the characterization of "personal attacks and...destructive comments." He's been questioning direction, roles and authority, not personal integrity or competence. That's the sort of reaction we used to hear in the CCITT about the Internet community not too long ago. It's not going to serve the IETF well to force out people because they ask questions you don't like. I certainly wouldn't expect this in an organization that takes pride in accommodating diverse views and adapting to change. If nothing else, life on these lists (such as it is) would be much duller without Jim. ciao, --tony   Received: from ietf.org by ietf.org id aa02474; 13 Nov 96 17:32 EST Received: from zephyr.isi.edu by ietf.org id aa02301; 13 Nov 96 17:30 EST Received: from brind.isi.edu (old-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 13 Nov 1996 14:29:20 -0800 Sender:ietf-request@ietf.org From: davidk@isi.edu Posted-Date: Wed, 13 Nov 1996 14:29:19 -0800 (PST) Message-Id: <9611132229.AA02518@brind.isi.edu> Received: by brind.isi.edu (4.1/4.0.3-6) id ; Wed, 13 Nov 96 14:29:19 PST Subject: Re: iTLDs - Directory. To: Karl Denninger Date: Wed, 13 Nov 1996 14:29:19 -0800 (PST) Cc: paul@vix.com, ietf@ietf.org In-Reply-To: <199611131936.NAA18226@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 13, 96 01:36:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1889 Source-Info: From (or Sender) name not authenticated. Hi Karl, > Karl Denninger writes : > > Actually, I want COM to have competition because I believe it will do ALL > of the following: > > 1) Destroy an improper monopoly. Agreed. > 2) Improve service to customers of the TLD registries. Agreed, but note that it doesn't necessarely means better service for the *users* of the Internet. > 3) Drop prices by anywhere from 50 to 90%. This remains to be seen. There is good chance that the administrator of the .COM domain can ask higher prices (at least in the short term) just because people are willing to pay that for such a popular domain. Until recently many foreign companies could easily register in their mothercountry TLD for free but they still decided to pay for a .COM address because it is better known and that $50.- is not that much ... And even if competition drives down the prices, you will probably need to register in more then one domain or pay for directory services possibly owned by Micro$oft or Netscape. And guess where you will have to buy your web browsers ... you will not get them for free anymore ... > 4) FORCE the implementation of a REAL directory service as a > "front-end" to the DNS. This will certainly happen, but who is doing it ?!? Is it a cheap service ?!? Do you need to subscribe to 20 different services ?!? There are enough examples in recent computer history that not always the best/cheapest system wins in the free market. However, having more TLDs is inevitable, whether we like it or not. Nobody can stop other people creating other domains and government intervention (domain taxes or regulations) become much more unlikely with a non-monopolistic system. Let's focuss on getting a cheap, open & easy directory service to assure that the pricedrop in service fees and user convenience really happens. And let's discuss this on another more appropriate list ;-), David K. ---   Received: from ietf.org by ietf.org id aa03960; 13 Nov 96 18:00 EST Received: from ietf.org by ietf.org id aa03690; 13 Nov 96 17:58 EST To: ietf@ietf.org Subject: Re: iTLDs Sender:ietf-request@ietf.org From: marshall eubanks Date: Wed, 13 Nov 1996 17:58:40 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611131758.aa03690@ietf.org> Source-Info: From (or Sender) name not authenticated. RE: >>> What we need is for Netscape and Microsoft to build into their >>> 4.0 versions of their browsers a 'Site Lookup' button, that >> >>Yes, this is precisely what's needed. > uhh, what data bases are to be consulted? How are they found? > What standards are used to consult them? I proposed on the new domain mailing list (in one of its varients) that each new i-TLD be required to maintain a web site (and/or a database) of the second level domains below it, containing, with the domain name, the name of the underlying company, the type of business offered, a URL for further information, etc. This would 1.) Relieve the need for one centralized database & 2.) Make the new iTLDs much easier to navigate than .com, and thus more attractive. I still think this sounds like a good idea - Since no i-TLDs exist officially as yet,, it would not seem too onerous to require them to keep up with this from the start. Regards Marshall Eubanks tme@casa.usno.navy.mil   Received: from ietf.org by ietf.org id aa08442; 13 Nov 96 18:51 EST Received: from Kitten.mcs.com by ietf.org id aa08275; 13 Nov 96 18:48 EST Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id RAA09732; Wed, 13 Nov 1996 17:46:54 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id RAA28339; Wed, 13 Nov 1996 17:46:51 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id RAA25946; Wed, 13 Nov 1996 17:46:50 -0600 (CST) Sender:ietf-request@ietf.org From: Karl Denninger Message-Id: <199611132346.RAA25946@Jupiter.Mcs.Net> Subject: Re: iTLDs - Directory. To: davidk@isi.edu Date: Wed, 13 Nov 1996 17:46:50 -0600 (CST) Cc: karl@mcs.net, paul@vix.com, ietf@ietf.org In-Reply-To: <9611132229.AA02518@brind.isi.edu> from "davidk@ISI.EDU" at Nov 13, 96 02:29:19 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Source-Info: From (or Sender) name not authenticated. > Hi Karl, > > > Karl Denninger writes : > > > > Actually, I want COM to have competition because I believe it will do ALL > > of the following: > > > > 1) Destroy an improper monopoly. > > Agreed. > > > 2) Improve service to customers of the TLD registries. > > Agreed, but note that it doesn't necessarely means better service for the > *users* of the Internet. > > > 3) Drop prices by anywhere from 50 to 90%. > > This remains to be seen. > > There is good chance that the administrator of the .COM domain can ask > higher prices (at least in the short term) just because people are > willing to pay that for such a popular domain. Sure. But it also means that if there are 20 companies out there (or 200) registering for $10.00/year, and NSI stays at $50.00, it won't be long before critical mass is achieved at those other entities and NSI is kaput. Especially if they counted on that revenue stream and did something silly like, oh, say, sold stock to the public :-) That's the problem with a competitive market. You just can't count on people staying out. However, for this to happen we *MUST* open the doors to basically all comers on terms that are sufficiently easy to satisfy that we end up with *lots* (hundreds) of registries. If we only get dozens, it won't happen. The dozens will all be big companies, and they have every interest in seeing that charge stay high. Ever wonder why cellular use is so outrageous? > > 4) FORCE the implementation of a REAL directory service as a > > "front-end" to the DNS. > > This will certainly happen, but who is doing it ?!? Is it a cheap service ?!? > Do you need to subscribe to 20 different services ?!? There are > enough examples in recent computer history that not always the > best/cheapest system wins in the free market. So what? Again, open markets and open competition have a way of fixing this problem. > Let's focuss on getting a cheap, open & easy directory service to assure > that the pricedrop in service fees and user convenience really happens. > And let's discuss this on another more appropriate list ;-), > > David K. > --- Sounds reasonable. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal   Received: from ietf.org by ietf.org id aa20982; 13 Nov 96 23:50 EST Received: from black-ice.cc.vt.edu by ietf.org id aa20822; 13 Nov 96 23:47 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id XAA17688; Wed, 13 Nov 1996 23:46:06 -0500 Message-Id: <199611140446.XAA17688@black-ice.cc.vt.edu> To: marshall eubanks cc: ietf@ietf.org Subject: Re: iTLDs In-reply-to: Your message of "Wed, 13 Nov 1996 17:58:40 EST." <9611131758.aa03690@ietf.org> Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="" X-URL: http://black-ice.cc.vt.edu/~valdis/ References: <9611131758.aa03690@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36112.847946765.1@black-ice.cc.vt.edu> Date: Wed, 13 Nov 1996 23:46:06 -0500 Source-Info: From (or Sender) name not authenticated. On Wed, 13 Nov 1996 17:58:40 EST, you said: > I proposed on the new domain mailing list (in one of > its varients) that each new i-TLD be required to maintain > a web site (and/or a database) of the second > level domains below it, containing, with the domain name, the > name of the underlying company, the type of business offered, a > URL for further information, etc. This would An interesting idea. It would however probably prove useful to ponder some of these data items, and ask if we *really* need them, or if they should be optional. Obviously, the domain name and the owner thereof should be public information, just as it is in the current WHOIS database. However, note that a "URL for further information" may or may not exist (the company may be a startup and not be up to speed yet, or may for policy reasons wish to be an e-mail only participant behind a firewall). Also, "type of business offered" may be problematic for inclusion in a database, unless we specifically remember to be *very* flexible. What business is Phillip Morris in (or any other conglomerate)? What about the company in Florida that was recently in the news, who as *one* of their specialty cleaning services, remove the evidence from crime scenes? Note - they come in and clean bloodstains and the like *after* the police are satisfied, not clean up for organized crime figures before the police arrive ;) I suspect that there's a *really* fat Ph.D. thesis in it for anybody who figures out how to make this anywhere near natural-language searchable, for more than just English. Actually, I take that back. If *I* knew how to do it, I'd say " the sheepskin", hack code, make a killing on the IPO, and then relax. ;) I admit to senility - is there an active list for discussing these sorts of directory issues, or should I look at creating one so we can move this whole thread there? Valdis Kletnieks Computer Systems Engineer Virginia Tech   Received: from ietf.org by ietf.org id aa20981; 13 Nov 96 23:50 EST Received: from cnri by ietf.org id aa20722; 13 Nov 96 23:45 EST Received: from access.netaxs.com by CNRI.Reston.VA.US id aa00925; 13 Nov 96 23:45 EST Received: from unix1.netaxs.com (cook@unix1.netaxs.com [207.8.186.3]) by access.netaxs.com (8.7.6/8.6.11) with ESMTP id XAA03176; Wed, 13 Nov 1996 23:43:50 -0500 (EST) Received: (from cook@localhost) by unix1.netaxs.com (8.7.6/8.7.3) id XAA05439; Wed, 13 Nov 1996 23:43:48 -0500 (EST) Date: Wed, 13 Nov 1996 23:43:47 -0500 (EST) Sender:ietf-request@ietf.org From: Gordon Cook To: "C.Joe Pasquariello" cc: Tony Rutkowski , IETF@CNRI.Reston.VA.US, poised@tis.com, newdom@vrx.net Subject: Re: Re[2]: "Thank You" Jim Fleming ! In-Reply-To: <9610138479.AA847931491@ncr.disa.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Tony..... are you really aware of the totality of the inane blathering of Fleming??? And the number of people who are kill filing him or automatically deleting him? If you were aware surely you'd be giving your own arguments rather than urging that he be listened to!? ************************************************************************ The COOK Report on Internet For subsc. pricing & more than 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material (609) 882-2572 (phone & fax) visit http://pobox.com/cook/ Internet: cook@cookreport.com For case study of MercerNet & TIIAP induced harm to local community http://pobox.com/cook/mercernet.html ************************************************************************ On Wed, 13 Nov 1996, C.Joe Pasquariello wrote: > OH REALLY TONY ! > > I'm surprised that you don't find the following Fleming comment of > today [like others over recent days] anything BUT unfounded, personal > and destructive! > > " 3. The appointed leaders in the IETF (and other I* leaders) have not > necessarily signed up to be anything more than figureheads. > As they are "pushed" from below, by the membership, they > have a difficult time devoting their life to some cause when the > reality of the world is that they mostly work for some > company and mainly protect that company's interests, > instead of the Internet's interest, or the people's interest." > - Jim Fleming; 13 Nov 96 > > See also Eastlake's comments of today on this point. > > I fail to see your point on the old CCITT/Internet animosity. Happily > there is currently a growing degree of respect and cooperation today > between the Internet community and the ITU-T. This has come about > through mutual respect and civility on both sides - NOT through the > sort of dialog being fostered by Mr Fleming. "Valuable" indeed ! > > C.Joe P--> > US/DoD/DISA > > ______________________________ Reply Separator _________________________________ > Subject: Re: "Thank You" Jim Fleming ! > Author: Tony Rutkowski at smtp > Date: 11/13/96 3:54 PM > > > Joe, > > > I have come away with increased respect for, and confidence in, the > > many senior members and leaders of the I* community for the > > extraordinary patience and thoroughness with which they have responded > > to your many unfounded personal attacks and generally destructive > > comments. > > > > For my part, I wish that you would 'leave' these lists and come back > > after you have time to reflect on the courtesy they have extended to > > you, and which I hope you would reciprocate. > > Giorno.. > > As another senior member of the world community, I'd like > to suggest that Jim is actually undertaking the valuable task > of asking questions about existing institutions and roles > from an alternative perspective. OK - he's been incredibly > "productive" and sometimes bothersome, but nothing that warrants > the characterization of "personal attacks and...destructive > comments." He's been questioning direction, roles and > authority, not personal integrity or competence. That's > the sort of reaction we used to hear in the CCITT about > the Internet community not too long ago. > > It's not going to serve the IETF well to force out people > because they ask questions you don't like. I certainly wouldn't > expect this in an organization that takes pride in accommodating > diverse views and adapting to change. If nothing else, life > on these lists (such as it is) would be much duller without Jim. > > ciao, > --tony > > >   Received: from ietf.org by ietf.org id aa00038; 14 Nov 96 7:52 EST Received: from cnri by ietf.org id aa29669; 14 Nov 96 7:46 EST Received: from mercury.Sun.COM by CNRI.Reston.VA.US id aa09006; 14 Nov 96 7:46 EST Received: from Canada.Sun.COM ([129.155.1.11]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA07769; Thu, 14 Nov 1996 04:43:19 -0800 Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1) id AA00965; Thu, 14 Nov 96 07:43:18 EST Received: from elsbeth.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4) id HAA13748; Thu, 14 Nov 1996 07:43:13 -0500 Received: from elsbeth by elsbeth.canada.sun.com (SMI-8.6/SMI-SVR4) id HAA08746; Thu, 14 Nov 1996 07:43:17 -0500 X-Orig-Sender: davecb@canada.sun.com Message-Id: <328B13E5.B92@scooter.canada.sun.com> Date: Thu, 14 Nov 1996 07:43:17 -0500 Sender:ietf-request@ietf.org From: David Collier-Brown Organization: The Orville Torpid Family and Friends X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.6 sun4m) Mime-Version: 1.0 To: Tony Rutkowski Cc: "C.Joe Pasquariello" , IETF@CNRI.Reston.VA.US, poised@tis.com, newdom@vrx.net Subject: Re: "Thank You" Jim Fleming ! References: <3.0.32.19961113152945.00a92550@fractal.chaos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Tony Rutkowski wrote: > [...] I'd like > to suggest that Jim is actually undertaking the valuable task > of asking questions about existing institutions and roles > from an alternative perspective. OK - he's been incredibly > "productive" and sometimes bothersome, but nothing that warrants > the characterization of "personal attacks and...destructive > comments." He's been questioning direction, roles and > authority, not personal integrity or competence. That's > the sort of reaction we used to hear in the CCITT about > the Internet community not too long ago. Alas, he's doing both. I like his content, actually, but could do with fewer colorfull adjectives (:-)) > It's not going to serve the IETF well to force out people > because they ask questions you don't like. I certainly wouldn't > expect this in an organization that takes pride in accommodating > diverse views and adapting to change. The House of Commons' task is almost entirely to deal with change, and they **certainly** have a diversity of views, yet even they throw out members who scream at the speaker... Seriously, though, the English nobility long ago emphasized civility: not because they were particularly nice people, but as an evil plot to make everyone think **everyone** else was a nice person. This lead to some debates over very contentious subjects actually taking place: previously raising the question would have led to bloodshead (people still wore daggers in those days). If someone really wanted to prevent consideration of the points Jim makes, he would be well advised to act just has Jim has. That is sufficient to turn debate in **this** commons into a shouting match. And yes, this is exactly how the former newsgroup soc.women was rendered ``nonthreatening'' by some commentators. --dave [and no, I don't think Jim or Bob are agents provacateurs, just a bit high on adrenalin] -- David Collier-Brown, | Cherish your enemies: they're harder 185 Ellerslie Ave., | to come by than friends, and MUCH more Willowdale, Ontario | motivated. CANADA M2N 1Y3 | -- me.   Received: from ietf.org by ietf.org id aa01710; 14 Nov 96 8:47 EST Received: from mailer1.lut.ac.uk by ietf.org id aa01512; 14 Nov 96 8:44 EST Received: from sun-cc201.lboro.ac.uk [158.125.1.201] (root) by mailer1.lut.ac.uk with smtp (Exim 0.56 #2) id E0vO241-0005II-00; Thu, 14 Nov 1996 13:42:41 +0000 Received: from comth by sun-cc201.lboro.ac.uk with smtp (Exim 0.56 #2) id E0vO23q-0004qk-00; Thu, 14 Nov 1996 13:42:30 +0000 Date: Thu, 14 Nov 1996 13:42:28 +0000 (GMT) Sender:ietf-request@ietf.org From: martin hamilton X-Sender: comth@sun-cc201 Reply-To: martin hamilton To: ietf@ietf.org Subject: Re: iTLDs In-Reply-To: <199611140446.XAA17688@black-ice.cc.vt.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Wed, 13 Nov 1996 Valdis.Kletnieks@vt.edu wrote: > However, note that a "URL for further information" may or may not > exist (the company may be a startup and not be up to speed yet, > or may for policy reasons wish to be an e-mail only participant > behind a firewall). Also, "type of business offered" may be > problematic for inclusion in a database, unless we specifically > remember to be *very* flexible. What business is Phillip Morris > in (or any other conglomerate)? What about the company in > Florida that was recently in the news, who as *one* of their > specialty cleaning services, remove the evidence from crime scenes? It's perhaps also worth bearing in mind that there isn't necessarily a one-to-one correspondence between organisations and domain names ? > Note - they come in and clean bloodstains and the like *after* > the police are satisfied, not clean up for organized crime figures > before the police arrive ;) I suspect that there's a *really* fat > Ph.D. thesis in it for anybody who figures out how to make this > anywhere near natural-language searchable, for more than just English. > > Actually, I take that back. If *I* knew how to do it, I'd say > " the sheepskin", hack code, make a killing on the IPO, > and then relax. ;) :-)) > I admit to senility - is there an active list for discussing these > sorts of directory issues, or should I look at creating one so > we can move this whole thread there? Well... I created the deploy list (see below) because I hadn't been able to find an existing forum, though there are a number of directory services and New Domain ;-) type lists. The thread would be welcome to move over in this direction. Cheerio, Martin | If anyone is interested in doing a little bit of practical experimentation | on the FINDING front, I'd like to volunteer a mailing list over here which | has been created for this purpose. Mail "deploy-request@mrrl.lut.ac.uk", | with the word "subscribe" on its own in the message body, if you want to | participate. | | Recommended reading... RFCs 1714, 1777, 1798, 1835, 1913 and 1914, plus | draft-klensin-tld-whois-00.txt, and draft-ietf-find-new-cip-00.txt   Received: from ietf.org by ietf.org id aa01996; 14 Nov 96 8:59 EST Received: from cnri by ietf.org id aa01855; 14 Nov 96 8:55 EST Received: from ester.dsv.su.se by CNRI.Reston.VA.US id aa10520; 14 Nov 96 8:55 EST Received: from localhost (jpalme@localhost) by ester.dsv.su.se (8.7.1/8.7.1) with SMTP id OAA03887; Thu, 14 Nov 1996 14:53:34 +0100 (MET) Date: Thu, 14 Nov 1996 14:53:34 +0100 (MET) Sender:ietf-request@ietf.org From: Jacob Palme To: ietf-types@uninett.no cc: ietf@CNRI.Reston.VA.US Subject: ISO 639 Standardised Language Codes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Apparently, there are two versions of the ISO 639 standard specifying codes for languages. Version 1 specifies two-letter language codes, while version 2 specifies three-letter language codes. I guess in practice this means that you must in input support both the two and the three-letter code for each language, or should we in IETF only accept the two letter codes, since that is what is specified in RFC 1766? The ISO codes can be found on the following web page: http://www.dsv.su.se/~jpalme/ietf/language-codes.html That web page contains an index for rapid retrieval of the ISO language codes and links to other pages with the ISO codes in other formats. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme   Received: from ietf.org by ietf.org id aa04982; 14 Nov 96 9:42 EST Received: from cnri by ietf.org id aa04640; 14 Nov 96 9:39 EST Received: from callandor.cybercash.com by CNRI.Reston.VA.US id aa11565; 14 Nov 96 9:39 EST Received: by callandor.cybercash.com; id JAA10289; Thu, 14 Nov 1996 09:32:38 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma010287; Thu, 14 Nov 96 09:32:37 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA16798; Thu, 14 Nov 96 09:35:42 EST Date: Thu, 14 Nov 1996 09:35:41 -0500 (EST) Sender:ietf-request@ietf.org From: "Donald E. Eastlake 3rd" To: Jacob Palme Cc: ietf-types@uninett.no, ietf@CNRI.Reston.VA.US Subject: Re: ISO 639 Standardised Language Codes In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. My first inclination was to say that recognizing three letter language codes where it's unambiguous seems fine, following the general "be liberal in what you receive" principle. But for use in protocols, I thought we should mandate generation only of two letter codes, the same way we only actually use two letter country codes in DNS, even though there are also official three letter country codes. [X.509 also mandates two letter country codes.] However, on actually looking at your web page, there seem to be lots of languages that *only* have three letter codes. Given that, I think both two and three letters have to be generally acceptable for generation or receipt. Donald On Thu, 14 Nov 1996, Jacob Palme wrote: > Date: Thu, 14 Nov 1996 14:53:34 +0100 (MET) > From: Jacob Palme > To: ietf-types@uninett.no > Cc: ietf@CNRI.Reston.VA.US > Subject: ISO 639 Standardised Language Codes > > Apparently, there are two versions of the ISO 639 standard > specifying codes for languages. Version 1 specifies two-letter > language codes, while version 2 specifies three-letter language > codes. I guess in practice this means that you must in input > support both the two and the three-letter code for each > language, or should we in IETF only accept the two letter > codes, since that is what is specified in RFC 1766? > > The ISO codes can be found on the following web page: > http://www.dsv.su.se/~jpalme/ietf/language-codes.html > > That web page contains an index for rapid retrieval of the ISO > language codes and links to other pages with the ISO codes > in other formats. > > ------------------------------------------------------------------------ > Jacob Palme (Stockholm University and KTH) > for more info see URL: http://www.dsv.su.se/~jpalme > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html   Received: from ietf.org by ietf.org id aa05466; 14 Nov 96 9:47 EST Received: from ietf.org by ietf.org id aa04031; 14 Nov 96 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-01.txt Date: Thu, 14 Nov 1996 09:27:10 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611140927.aa04031@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : R. Atkinson Filename : draft-ietf-ipsec-arch-sec-01.txt Pages : 24 Date : 11/12/1996 This memo describes the security protocols for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. Each security protocol is specified in a separate document. This document also describes key management requirements for systems implementing these security protocols. This document is not an overall Security Architecture for the Internet; it addresses only IP-layer security. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-sec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-sec-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-sec-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961112150209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961112150209.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05492; 14 Nov 96 9:47 EST Received: from ietf.org by ietf.org id aa03987; 14 Nov 96 9:26 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-thaler-interop-00.txt, .ps Date: Thu, 14 Nov 1996 09:26:23 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611140926.aa03987@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interoperability Rules for Multicast Routing Protocols Author(s) : D. Thaler Filename : draft-thaler-interop-00.txt, .ps Pages : 16 Date : 11/12/1996 The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. Specific instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-thaler-interop-00.txt". Or "get draft-thaler-interop-00.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-thaler-interop-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-thaler-interop-00.txt". Or "FILE /internet-drafts/draft-thaler-interop-00.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961112110947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thaler-interop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-thaler-interop-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961112110947.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05493; 14 Nov 96 9:47 EST Received: from ietf.org by ietf.org id aa03969; 14 Nov 96 9:26 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-weider-iab-char-wrkshop-00.txt Date: Thu, 14 Nov 1996 09:26:15 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611140926.aa03969@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Report of the IAB Character Set Workshop Author(s) : C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg Filename : draft-weider-iab-char-wrkshop-00.txt Pages : 27 Date : 11/12/1996 This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-weider-iab-char-wrkshop-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-weider-iab-char-wrkshop-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-weider-iab-char-wrkshop-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961112110248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-weider-iab-char-wrkshop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-weider-iab-char-wrkshop-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961112110248.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05483; 14 Nov 96 9:47 EST Received: from ietf.org by ietf.org id aa04075; 14 Nov 96 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: applmib@emi-summit.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-applmib-sysapplmib-05.txt Date: Thu, 14 Nov 1996 09:27:06 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611140927.aa04075@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application MIB Working Group of the IETF. Title : Definitions of Managed Objects for Applications Author(s) : C. Krupczak, J. Saperia, R. Sturm, J. Weinstock Filename : draft-ietf-applmib-sysapplmib-05.txt Pages : 44 Date : 11/12/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. More specifically, the managed objects are restricted to information that can be determined from the system itself and which does not require special instrumentation within the applications to make the information available. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-applmib-sysapplmib-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-applmib-sysapplmib-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-applmib-sysapplmib-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961112133820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-applmib-sysapplmib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-applmib-sysapplmib-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961112133820.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05485; 14 Nov 96 9:47 EST Received: from ietf.org by ietf.org id aa04050; 14 Nov 96 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ema-vpim-03.txt Date: Thu, 14 Nov 1996 09:27:13 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611140927.aa04050@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Voice Profile for Internet Mail - version 2 Author(s) : G. Vaudreuil, G. Parsons Filename : draft-ema-vpim-03.txt Pages : 44 Date : 11/12/1996 A class of special-purpose computers has evolved to provide voice messaging services. These machines generally interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent to a non-local machine are transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there is a need for a standard high-quality digital protocol to connect these machines. The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice messaging networking protocol. The profile is referred to as VPIM (Voice Profile for Internet Mail) in this document. This profile is based on earlier work in the Audio Message Interchange Specification (AMIS) group that defined a voice messaging protocol based on X.400 technology. This profile is intended to satisfy the user requirements statement from that earlier work with the industry standard ESMTP/MIME mail protocol infrastructures already used within corporate intranets. This second version of VPIM is based on implementation experience and obsoletes RFC 1911 which describes version 1 of the profile. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ema-vpim-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ema-vpim-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ema-vpim-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961112150833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ema-vpim-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ema-vpim-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961112150833.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05488; 14 Nov 96 9:47 EST Received: from ietf.org by ietf.org id aa04010; 14 Nov 96 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-minnear-igrpng-00.txt Date: Thu, 14 Nov 1996 09:27:03 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611140927.aa04010@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IGRPng for IPv6 Author(s) : R. Minnear, R. Hinden Filename : draft-minnear-igrpng-00.txt Pages : 28 Date : 11/12/1996 This document defines a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet. This specification represents a new version of the Inter-Gateway Routing Protocol (IGRP) for use with IPv6 and other protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-minnear-igrpng-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-minnear-igrpng-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-minnear-igrpng-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961112113241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-minnear-igrpng-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-minnear-igrpng-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961112113241.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa05480; 14 Nov 96 9:47 EST Received: from ietf.org by ietf.org id aa04109; 14 Nov 96 9:29 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: if-mib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ifmib-mib-04.txt Date: Thu, 14 Nov 1996 09:29:54 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611140929.aa04109@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interfaces MIB Working Group of the IETF. Title : The Interfaces Group MIB Author(s) : K. McCloghrie, F. Kastenholz Filename : draft-ietf-ifmib-mib-04.txt Pages : 77 Date : 11/12/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ifmib-mib-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ifmib-mib-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ifmib-mib-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961114092845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ifmib-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ifmib-mib-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961114092845.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06936; 14 Nov 96 10:04 EST Received: from cnri by ietf.org id aa06563; 14 Nov 96 10:00 EST Received: from domen.uninett.no by CNRI.Reston.VA.US id aa12218; 14 Nov 96 10:00 EST Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <14468-0@domen.uninett.no>; Thu, 14 Nov 1996 15:58:57 +0100 X-Mailer: exmh version 1.6.7 5/3/96 Sender:ietf-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: Jacob Palme cc: ietf-types@uninett.no, ietf@CNRI.Reston.VA.US Subject: Re: ISO 639 Standardised Language Codes In-reply-to: Your message of "Thu, 14 Nov 1996 14:53:34 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Nov 1996 15:58:54 +0100 Message-ID: <14456.847983534@domen.uninett.no> X-Orig-Sender: Harald.T.Alvestrand@uninett.no Source-Info: From (or Sender) name not authenticated. The key to the question lies IMHO on the ISO webserver: http://www.iso.ch/isob/switch-engine-cate.pl?searchtype=refnumber&KEYWORDS=639 gives you: ISO 639:1988 Code for the representation of names of languages ISO/DIS 639-2 Codes for the representation of names of languages -- Part 2: Alpha-3 code Note the DIS part: This is a Draft International Standard, not a Standard. However, it's advancing; last time I heard of it, it was in CD state, and had failed a DIS ballot, because lots of people wanted to change the way codes were allocated. Keld Simonsen's codes come from the CD proposal of 1991. Once this is stable within ISO, I will probably update RFC 1766 to reference it, but until that time, I think we should stick with 2-letter codes and our own extensions. Note that the existence of this ISO effort is one reason why RFC 1766 doesn't allow registering new top-level codes, and that I objected strongly to an earlier proposal to use SIL Ethnologue 3-letter codes as top-level language tags! Harald A   Received: from ietf.org by ietf.org id aa16193; 14 Nov 96 12:16 EST Received: from cnri by ietf.org id aa15202; 14 Nov 96 12:08 EST Received: from hail.ncr.disa.mil by CNRI.Reston.VA.US id aa15949; 14 Nov 96 12:08 EST Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id LAA07025; Thu, 14 Nov 1996 11:55:56 -0500 (EST) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA848001985; Thu, 14 Nov 96 12:04:35 EST Date: Thu, 14 Nov 96 12:04:35 EST Sender:ietf-request@ietf.org From: "C.Joe Pasquariello" Message-Id: <9610148480.AA848001985@ncr.disa.mil> To: ISOC-Advisory-Council@isoc.org Cc: "ISOC Exec. Dir." , ISOC-Trustees@isoc.org, IETF@CNRI.Reston.VA.US Subject: Last Call - ISOC Advisory Council Officer Nominees Source-Info: From (or Sender) name not authenticated. GREETINGS - re: Council document 95-005, and my note of 5 Nov 96 This is to remind that we plan to close the nominations for the two vacant Advisory Council Officer positions at weeks end. To date we have four declared candidates: - Prof.Dr.Srisakdi Charmonman Thailand; Assumption University - Micheal E.Conn USA; MCI Corp. - Ole J. Jacobsen USA; InterOp Company - Stefano Trumpy Italy, CNUCE REMEMBER THAT SELF NOMINATION IS PERFECTLY OK FOR THIS PROCESS. ISOC staff will send out ballots [electronically] next week to the currently designated Organizational Representatives and Alternates. All of the election documentation will also be posted in the Council Documents folder on the ISOC gopher/ftp server. Best regards, C.Joe Pasquariello Chair, ISOC Advisory Council ====================== Note for IETF Recipients ============= As you may know, the ISOC/IETF roles and relationships have recently been formalized in RFC 2031. The ISOC Advisory Council consists of the Representatives of the Organizational Members of ISOC. It provides an advisory function to the ISOC Board of Trustees on matters of interest to the organizational members. The Officers of the Council [4] sit as non-voting participants in ISOC Board meetings. Should you wish to participate in this area of Internet community affairs, and your parent organization is not an organizational member of ISOC - you might wish to encourage them to consider such. Details are on the ISOC web server THX ========================= End of Commercial' ==================   Received: from ietf.org by ietf.org id aa23377; 14 Nov 96 13:31 EST Received: from cnri by ietf.org id aa23103; 14 Nov 96 13:28 EST Received: from [204.250.49.14] by CNRI.Reston.VA.US id aa18072; 14 Nov 96 13:28 EST Received: from mail.coupon.net (204.250.49.77) by mail.higgs.net with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 14 Nov 1996 10:27:05 -0800 Received: from [204.250.49.20] by mail.coupon.net with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 14 Nov 1996 10:26:56 -0800 Message-Id: In-Reply-To: <328B13E5.B92@scooter.canada.sun.com> References: <3.0.32.19961113152945.00a92550@fractal.chaos.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Nov 1996 09:54:55 -0800 To: David Collier-Brown , Tony Rutkowski Sender:ietf-request@ietf.org From: Simon Higgs Subject: Re: "Thank You" Jim Fleming ! Cc: "C.Joe Pasquariello" , IETF@CNRI.Reston.VA.US, poised@tis.com, newdom@vrx.net Source-Info: From (or Sender) name not authenticated. At 7:43 AM -0500 11/14/96, David Collier-Brown wrote: > Tony Rutkowski wrote: > > [...] I'd like > > to suggest that Jim is actually undertaking the valuable task > > of asking questions about existing institutions and roles > > from an alternative perspective. OK - he's been incredibly > > "productive" and sometimes bothersome, but nothing that warrants > > the characterization of "personal attacks and...destructive > > comments." He's been questioning direction, roles and > > authority, not personal integrity or competence. That's > > the sort of reaction we used to hear in the CCITT about > > the Internet community not too long ago. > > Alas, he's doing both. > I like his content, actually, but could do with > fewer colorfull adjectives (:-)) > > > It's not going to serve the IETF well to force out people > > because they ask questions you don't like. I certainly wouldn't > > expect this in an organization that takes pride in accommodating > > diverse views and adapting to change. > > The House of Commons' task is almost entirely > to deal with change, and they **certainly** have a diversity > of views, yet even they throw out members who scream > at the speaker... > > Seriously, though, the English nobility long ago emphasized > civility: not because they were particularly nice people, but as > an evil plot to make everyone think **everyone** else was a nice > person. > This lead to some debates over very contentious subjects > actually taking place: previously raising the question would have led to > bloodshead (people still wore daggers in those days). > This was taken into consideration when they physically built the present English House of Commons. Each party sits facing each other, and when someone addresses the house from the front row, they are exactly two arms lengths and two sword lengths and one foot away from their opponent. Crossing the threshhold is frowned upon. This has probably saved many lives. You have to build the infrastructure properly to address human nature, as it's far more damaging when unaddressed than even organized technically-crafted warfare. Simon -- Madness takes its toll. Please have exact change.   Received: from ietf.org by ietf.org id aa00321; 14 Nov 96 18:13 EST Received: from nsipo.arc.nasa.gov by ietf.org id aa00063; 14 Nov 96 18:07 EST Received: Thu, 14 Nov 1996 15:05:58 -0800 (PST) from localhost (RFC1413 sender feinler@localhost) by nsipo.arc.nasa.gov (8.7.1/1.5) id PAA08746 Date: Thu, 14 Nov 1996 15:05:58 -0800 (PST) Sender:ietf-request@ietf.org From: Jake Feinler To: Gordon Cook cc: Hank Nussbacher , ietf@ietf.org Subject: Re: NSI contract In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. I am confused about this interchange. My understanding is that a Cooperative Agreement is an agreement between or among government agencies. For instance FNCAC members have a Cooperative Agreement with NSF. However, NSF under the mandate given to it via the Cooperative Agreement has then entered into a Contract with NSI (which I believe was competitive). Is this correct? Aren't there two different contractual entities involved here? Perhaps someone in the know could comment as to whether this is correct or not. I confess I am not following all this commentary closely; however, there seems to be a thread that NSI was "appointed" rather than competed which, if it is not correct, may be causing confusion about the process. Can someone in the know either corroborate or correct my understanding. Thanks, Jake Feinler On Sun, 10 Nov 1996, Gordon Cook wrote: > Hank asks when the NSI contract ends: The answer is: April 1 1998. > But remember that it is a cooperative agreement which means > that some of the rules governing it are a bit different than a contract. > And remember that the FNC (or was it the FNCAC?) recently expressed the > desire that NSF remove itself from involvement with the entire domain name > issue. Thus the terminaton of the current five year agreement well in > advance of April 1 1998 is not at all impossible. > > > ************************************************************************ > The COOK Report on Internet For subsc. pricing & more than > 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material > (609) 882-2572 (phone & fax) visit http://pobox.com/cook/ > Internet: cook@cookreport.com For case study of MercerNet & > TIIAP induced harm to local community http://pobox.com/cook/mercernet.html > ************************************************************************ > > > On Sun, 10 Nov 1996, Hank Nussbacher wrote: > > > When does the NSI contract expire? Month and year, please. > > > > Thanks, > > Hank Nussbacher > > IBM Israel > > > >   Received: from ietf.org by ietf.org id aa01784; 14 Nov 96 18:43 EST Received: from access.netaxs.com by ietf.org id aa01660; 14 Nov 96 18:42 EST Received: from unix1.netaxs.com (cook@unix1.netaxs.com [207.8.186.3]) by access.netaxs.com (8.7.6/8.6.11) with ESMTP id SAA28757; Thu, 14 Nov 1996 18:41:10 -0500 (EST) Received: (from cook@localhost) by unix1.netaxs.com (8.7.6/8.7.3) id SAA20400; Thu, 14 Nov 1996 18:41:07 -0500 (EST) Date: Thu, 14 Nov 1996 18:41:06 -0500 (EST) Sender:ietf-request@ietf.org From: Gordon Cook To: Jake Feinler cc: Hank Nussbacher , ietf@ietf.org Subject: Re: NSI contract In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. NSI most definitely competed. They were not appointed. The government uses a cooperative agreement rather than a contract when it wants xxxx rather than yyyy. i believe it is when it is buying services for use by third parties rather than something to be owned by the purchasing government agencies....but i am going on memory and could be wrong. i am however 100% certain of my first two sentences. the terms of a cooperative agreement can be changed more easily in mid course than could a contract..... but again some reader here with the appropriate gov't purchasing experience can speak to the details better than I. ************************************************************************ The COOK Report on Internet For subsc. pricing & more than 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material (609) 882-2572 (phone & fax) visit http://pobox.com/cook/ Internet: cook@cookreport.com For case study of MercerNet & TIIAP induced harm to local community http://pobox.com/cook/mercernet.html ************************************************************************ On Thu, 14 Nov 1996, Jake Feinler wrote: > I am confused about this interchange. My understanding is that a > Cooperative Agreement is an agreement between or among government > agencies. For instance FNCAC members have a Cooperative Agreement with > NSF. However, NSF under the mandate given to it via the > Cooperative Agreement has then entered into a Contract with NSI (which I > believe was competitive). Is this correct? Aren't there two different > contractual entities involved here? Perhaps someone in the know could > comment as to whether this is correct or not. I confess I am not > following all this commentary closely; however, there seems to be a thread > that NSI was "appointed" rather than competed which, if it is not correct, > may be causing confusion about the process. > > Can someone in the know either corroborate or correct my understanding. > > Thanks, > > Jake Feinler > > On Sun, 10 Nov 1996, Gordon Cook wrote: > > > Hank asks when the NSI contract ends: The answer is: April 1 1998. > > But remember that it is a cooperative agreement which means > > that some of the rules governing it are a bit different than a contract. > > And remember that the FNC (or was it the FNCAC?) recently expressed the > > desire that NSF remove itself from involvement with the entire domain name > > issue. Thus the terminaton of the current five year agreement well in > > advance of April 1 1998 is not at all impossible. > > > > > > ************************************************************************ > > The COOK Report on Internet For subsc. pricing & more than > > 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material > > (609) 882-2572 (phone & fax) visit http://pobox.com/cook/ > > Internet: cook@cookreport.com For case study of MercerNet & > > TIIAP induced harm to local community http://pobox.com/cook/mercernet.html > > ************************************************************************ > > > > > > On Sun, 10 Nov 1996, Hank Nussbacher wrote: > > > > > When does the NSI contract expire? Month and year, please. > > > > > > Thanks, > > > Hank Nussbacher > > > IBM Israel > > > > > > > >   Received: from ietf.org by ietf.org id aa29896; 15 Nov 96 12:19 EST Received: from nsipo.arc.nasa.gov by ietf.org id aa29390; 15 Nov 96 12:05 EST Received: Fri, 15 Nov 1996 09:04:20 -0800 (PST) from localhost (RFC1413 sender feinler@localhost) by nsipo.arc.nasa.gov (8.7.1/1.5) id JAA06788 Date: Fri, 15 Nov 1996 09:04:20 -0800 (PST) Sender:ietf-request@ietf.org From: Jake Feinler To: ietf@ietf.org cc: Jake Feinler Subject: Re: NSI Cooperative Agreement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Thanks for the feedback. I was mistaken as to how the cooperative agreement worked in this case. Jake Hank, fyi, cooperative agreements are used in governement agencies other than NSF (however, that is a random bit of info that is tangential to the discussion here.)   Received: from ietf.org by ietf.org id aa04585; 15 Nov 96 15:03 EST Received: from burnout.cts.com by ietf.org id aa04183; 15 Nov 96 14:58 EST Received: from netguru.cts.com (netguru.cts.com [204.94.77.43]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id LAA18614; Fri, 15 Nov 1996 11:51:00 -0800 Message-Id: <3.0b36.32.19961115113113.006bf510@mail.cts.com> X-Sender: kwe@mail.cts.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Fri, 15 Nov 1996 11:55:45 -0800 To: Gordon Cook Sender:ietf-request@ietf.org From: "Kent W. England" Subject: NSI cooperative agreement [was Re: NSI contract] Cc: Jake Feinler , Hank Nussbacher , ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. At 06:41 PM 14-11-96 -0500, Gordon Cook wrote: >NSI most definitely competed. They were not appointed. The government >uses a cooperative agreement rather than a contract when it wants xxxx >rather than yyyy. i believe it is when it is buying services for use by >third parties rather than something to be owned by the purchasing >government agencies....but i am going on memory and could be wrong. Gordon; It's a subtle distinction for the layman, but quite important for the way that NSF conducts its business. You are right that a contract is a better vehicle when the government is buying something like staples or gasoline. Government contracts are very strict on deliverables and terms and conditions. Cooperative agreements involve commitments by both parties, but they are much more flexible than contracts. In the fast changing world of the Internet this is much better, in my opinion, than trying to predict the future ala FTS 2000. Bear in mind that cooperative agreements are competitive just as much as contracts. The flexibility inherent in cooperative agreements would cause contracts to be rebid, wasting a lot of everyone's time and money. But cooperative agreements can't be too flexible -- the limits are all in the way the cooperative agreement is worded. More often than not, changes cost the awardee time and money in exchange for some other good, like opportunity. --Kent   Received: from cnri by ietf.org id aa08266; 15 Nov 96 17:07 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa21640; 15 Nov 96 17:07 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA19101 for uri-out; Fri, 15 Nov 1996 16:17:02 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA19092; Fri, 15 Nov 1996 16:16:59 -0500 Received: from ns.alis.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01031 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 16:16:42 -0500 Received: from fyergeau.alis.com ([207.81.28.17]) by genstar.alis.ca (8.7.5/8.7.3) with SMTP id QAA28482; Fri, 15 Nov 1996 16:16:05 -0500 (EST) Message-Id: <2.2.32.19961115211148.006eb9e0@genstar.alis.ca> X-Sender: yergeau@genstar.alis.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Nov 1996 16:11:48 -0500 To: Ron Daniel From: Francois Yergeau Subject: Re: [URN] URI internationalization Cc: urn-ietf@bunyip.com, uri@bunyip.com Content-Transfer-Encoding: quoted-printable Sender: owner-uri@bunyip.com Precedence: bulk [Cross-posted to URI list, from URN-IETF list] =C0 09:05 15-11-96 -0700, Ron Daniel a =E9crit : >I think I18N for URLs is a more difficult problem than it has been for >URNs. We have a large number of existing URLs in a variety of character >sets. Well, no, it appears we don't really have that. I made a search for non-ASCII URLs last spring (both 8-bit octets and %XY with X>=3D8), and f= ound very few out on the Web (cf. ). Less than 0.25% in fact, and then some were typos (divide signs instead of tilde, f= or instance) that didn't work until corrected by hand. Furthermore, compatibility is made easier by the fact that UTF-8 data can= be quite reliably recognized as such. Given a UR*, a server can test it for UTF-8 validity; if it fails, it's some 'old' UR* in some encoding other t= han UTF-8, the server can process as it did before and nothing is broken; if = it passes, just process as UTF-8. A little experimentation (need more) show= s that false positives are unlikely, provided one takes care of 7-bit ISO-2022-like encodings that look like ASCII (and thus UTF-8) but are not. As for complexity, a UTF-8 validator fits in about 20 lines of C. >While I18N for URLs is a legitimate issue, it is not an issue for the >URN-WG (IMHO). The URI list is still alive, that might be the proper >place to begin discussions. Agreed, I cross-posted there. Please limit replies to the URI list. Regards, --=20 Fran=E7ois Yergeau Alis Technologies Inc., Montr=E9al T=E9l : +1 (514) 747-2547 Fax : +1 (514) 747-2561   Received: from ietf.org by ietf.org id aa10041; 15 Nov 96 18:07 EST Received: from ietf.org by ietf.org id aa09509; 15 Nov 96 18:00 EST To: ietf@ietf.org Sender:ietf-request@ietf.org From: shaw Subject: Re: NSI contract Date: Fri, 15 Nov 1996 18:00:07 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611151800.aa09509@ietf.org> Source-Info: From (or Sender) name not authenticated. >I am confused about this interchange. My understanding is that a >Cooperative Agreement is an agreement between or among government >agencies. For instance FNCAC members have a Cooperative Agreement with >NSF. However, NSF under the mandate given to it via the >Cooperative Agreement has then entered into a Contract with NSI (which I >believe was competitive). Is this correct? Aren't there two different >contractual entities involved here? Perhaps someone in the know could >comment as to whether this is correct or not. I confess I am not The FNCAC is *chartered* by NSF. See http://www.fnc.gov/FNC_charter.html "The FNC Advisory Committee (FNCAC) is chartered by the National Science Foundation to work in collaboration with the FNC by providing external perspectives and balanced points of view; the FNCAC consists of senior representatives from technical, industrial, academic and user communities." Also see http://www.fnc.gov/FNCAC_charter.html Robert   Received: from ietf.org by ietf.org id aa10737; 15 Nov 96 18:17 EST Received: from diablo.cisco.com by ietf.org id aa10304; 15 Nov 96 18:14 EST Received: from [171.68.13.40] (c2robo8.cisco.com [171.68.13.40]) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id PAA02608; Fri, 15 Nov 1996 15:10:52 -0800 X-Sender: swolff@diablo.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Nov 1996 18:11:08 -0500 To: Jake Feinler Sender:ietf-request@ietf.org From: Stephen Wolff Subject: Re: NSI contract Cc: Gordon Cook , Hank Nussbacher , ietf@ietf.org Source-Info: From (or Sender) name not authenticated. Jake - Under the Grants and Cooperative Agreements Act of (I think) 1977, there are two conditions that mandate the use of a Cooperative Agreement (CA) instead of a contract: (1) the goods/services being acquired are NOT primarily for the use of the Government, and (2) the Government will be actively and jointly involved in the management of the project being funded. The first criterion explains why NSF uses so many CAs: it is funding stuff primarily for the use of the academic community it was created to serve. And of course that was the case for the NSI award. When NSF procures desks, workstations, telecomms services or whatnot for its own internal staff and operations, it uses a contract subject to the FARs just like any other Government agency Long time no see. Howgozit? Best, -s   Received: from ietf.org by ietf.org id aa19033; 17 Nov 96 12:51 EST Received: from cnri by ietf.org id aa18918; 17 Nov 96 12:39 EST Received: from dkuug.dk by CNRI.Reston.VA.US id aa11976; 17 Nov 96 12:39 EST Received: (from keld@localhost) by dkuug.dk (8.6.12/8.6.12) id SAA21372; Sun, 17 Nov 1996 18:37:32 +0100 Message-Id: <199611171737.SAA21372@dkuug.dk> Sender:ietf-request@ietf.org From: Keld J|rn Simonsen Date: Sun, 17 Nov 1996 18:37:31 +0100 In-Reply-To: Jacob Palme "ISO 639 Standardised Language Codes" (Nov 14, 14:56) X-Charset: ISO-8859-1 X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Jacob Palme , ietf-types@uninett.no Subject: Re: ISO 639 Standardised Language Codes Cc: ietf@CNRI.Reston.VA.US Source-Info: From (or Sender) name not authenticated. Jacob Palme writes: > Apparently, there are two versions of the ISO 639 standard > specifying codes for languages. Version 1 specifies two-letter > language codes, while version 2 specifies three-letter language > codes. I guess in practice this means that you must in input > support both the two and the three-letter code for each > language, or should we in IETF only accept the two letter > codes, since that is what is specified in RFC 1766? As far as I know, there is no finalized part 2 (with three-letter codes). And there are doubts that it will materialize. So for now we only need to support the two-letter codes. Also please note that we talk about ISO 639 part 1 and part 2, (not versions), using the name version is misleading as a newer version is expected to have outdated the older version, and this is not normally done with ISO standards in parts, and even more misleading here where part 2 did not make it. > The ISO codes can be found on the following web page: > http://www.dsv.su.se/~jpalme/ietf/language-codes.html the merge you have done of the two specifications is misleading, as somebody could be falsely interpret the three-letter codes to have a standards standing. Kind regards Keld Simonsen   Received: from ietf.org by ietf.org id aa04895; 18 Nov 96 9:31 EST Received: from cnri by ietf.org id aa04673; 18 Nov 96 9:23 EST Received: from emout20.mx.aol.com by CNRI.Reston.VA.US id aa10082; 18 Nov 96 9:23 EST Received: by emout20.mail.aol.com (8.6.12/8.6.12) id JAA00154 for IETF@cnri.reston.va.us; Mon, 18 Nov 1996 09:22:22 -0500 Date: Mon, 18 Nov 1996 09:22:22 -0500 Sender:ietf-request@ietf.org From: WRGJT@aol.com Message-ID: <961118092221_1351426094@emout20.mail.aol.com> To: IETF@CNRI.Reston.VA.US Subject: subscription Source-Info: From (or Sender) name not authenticated. IETF-REQUEST@CNRI.RESTON.VA.US   Received: from ietf.org by ietf.org id aa09046; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05461; 18 Nov 96 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-userclass-00.txt Date: Mon, 18 Nov 1996 09:51:48 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180951.aa05461@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The User Class Option for DHCP Author(s) : G. Stump, R. Droms Filename : draft-ietf-dhc-userclass-00.txt Pages : 4 Date : 11/15/1996 This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an NVT ASCII text object that represents the user class of which the client is a member. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-userclass-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-userclass-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-userclass-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115101522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-userclass-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115101522.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09111; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05950; 18 Nov 96 9:54 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rps@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rps-tunnels-00.txt Date: Mon, 18 Nov 1996 09:54:27 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180954.aa05950@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Policy System Working Group of the IETF. Title : Representing Tunnels in RPSL Author(s) : D. Meyer Filename : draft-ietf-rps-tunnels-00.txt Pages : 7 Date : 11/15/1996 This document specifies the language and set of semantics describing tunnels in the Routing Policy Specification Language (RPSL). It defines a new tunnel class, inet-tunnel, and a set of extensions to the inet-rtr class. An instance of the inet-tunnel class specifies endpoints for tunnels of various encapsulation types, including DVMRP [DVMRP], GRE [GRE], and IPv6 [IPV6]. This memo is a product of the Routing Policy System Working Group (RPS) in the Operational Requirements area of the Internet Engineering Task Force. Submit comments to or the author. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rps-tunnels-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rps-tunnels-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rps-tunnels-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115163043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rps-tunnels-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rps-tunnels-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115163043.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09139; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05445; 18 Nov 96 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-masinter-url-data-02.txt Date: Mon, 18 Nov 1996 09:51:45 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180951.aa05445@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The "data" URL scheme Author(s) : L. Masinter Filename : draft-masinter-url-data-02.txt Pages : 2 Date : 11/15/1996 A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-masinter-url-data-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-masinter-url-data-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-masinter-url-data-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115100240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-masinter-url-data-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-masinter-url-data-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115100240.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09092; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05638; 18 Nov 96 9:52 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-fielding-url-syntax-00.txt Date: Mon, 18 Nov 1996 09:52:44 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180952.aa05638@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Uniform Resource Locators (URL) Author(s) : T. Berners-Lee, R. Fielding, L. Masinter Filename : draft-fielding-url-syntax-00.txt Pages : 19 Date : 11/15/1996 A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. This document defines the general syntax and semantics of URLs, including both absolute and relative locators, and guidelines for their use and for the definition of new URL schemes. It revises and replaces the generic definitions in RFC 1738 and RFC 1808. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fielding-url-syntax-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-fielding-url-syntax-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-fielding-url-syntax-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115140413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fielding-url-syntax-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-fielding-url-syntax-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115140413.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09149; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05672; 18 Nov 96 9:53 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-huizer-poised-ietfdoc-00.txt Date: Mon, 18 Nov 1996 09:53:05 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180953.aa05672@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A New IETF Document Classification Author(s) : M. O'Dell Filename : draft-huizer-poised-ietfdoc-00.txt Pages : 7 Date : 11/15/1996 The Simple Record Framing Protocol (SRFP) is designed to provide a common, light-weight protocol for sending record-structured data of possibly indeterminate size over a reliable (TCP) connection. It is designed to be a "nickel's worth of presentation layer" which can be incorporated into a simple library to prevent reinvention of wheels. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-huizer-poised-ietfdoc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-huizer-poised-ietfdoc-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-huizer-poised-ietfdoc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115154518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-huizer-poised-ietfdoc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-huizer-poised-ietfdoc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115154518.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09148; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa06035; 18 Nov 96 9:55 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-options-1533update-05.txt Date: Mon, 18 Nov 1996 09:55:11 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180955.aa06035@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : DHCP Options and BOOTP Vendor Extensions Author(s) : S. Alexander, R. Droms Filename : draft-ietf-dhc-options-1533update-05.txt Pages : 38 Date : 11/15/1996 The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options." This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments [22]. All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of the DHCP options defined in this document, except for those specific to DHCP as defined in section 9, may be used as BOOTP vendor information extensions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-options-1533update-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-options-1533update-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-options-1533update-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115155856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-options-1533update-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-options-1533update-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115155856.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09145; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05612; 18 Nov 96 9:52 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipng@sunroof.eng.sun.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-multicast-assgn-01.txt Date: Mon, 18 Nov 1996 09:52:35 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180952.aa05612@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Multicast Address Assignments Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-multicast-assgn-01.txt Pages : 8 Date : 11/15/1996 This document defines the initial assignment of IPv6 multicast addresses. It is based on the "RFC-1884 IP Version 6 Addressing Architecture" [RFC1884] and current IPv4 multicast address assignment found in . It adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4 assignments that were not relevant were not converted into IPv6 assignments. Comments are solicited on this conversion. All other IPv6 multicast addresses are reserved. Sections 2 and 3 specify reserved and preassigned IPv6 multicast addresses. Section 4 defines guidelines for assigning new IPv6 multicast addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-multicast-assgn-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115104009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-multicast-assgn-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115104009.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09080; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05477; 18 Nov 96 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-pkix@tandem.com, pki-tg@opengroup.org, OGsecurity@opengroup.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-apki-00.txt Date: Mon, 18 Nov 1996 09:51:51 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180951.aa05477@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Architecture for Public-Key Infrastructure Author(s) : B. Blakley Filename : draft-ietf-pkix-apki-00.txt Pages : 43 Date : 11/15/1996 This document describes Requirements and an Architecture for Public-Key Infrastructure components, identifies which elements of the architecture should (in the opinion of the authors) be standardized, and identifies candidate interface and protocol specifications which might serve as base documents for the standardization effort. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-apki-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-apki-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pkix-apki-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115090604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-apki-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-apki-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115090604.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09110; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05722; 18 Nov 96 9:53 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-options-1533update-05.txt Date: Mon, 18 Nov 1996 09:53:31 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180953.aa05722@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : DHCP Options and BOOTP Vendor Extensions Author(s) : S. Alexander, R. Droms Filename : draft-ietf-dhc-options-1533update-05.txt Pages : 38 Date : 11/15/1996 The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options." This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments [22]. All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of the DHCP options defined in this document, except for those specific to DHCP as defined in section 9, may be used as BOOTP vendor information extensions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-options-1533update-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-options-1533update-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-options-1533update-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115155856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-options-1533update-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-options-1533update-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115155856.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09206; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05811; 18 Nov 96 9:53 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hethmon-mlst-command-ftp-00.txt Date: Mon, 18 Nov 1996 09:53:40 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180953.aa05811@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MLST Command and Extensions to FTP Author(s) : P. Hethmon Filename : draft-hethmon-mlst-command-ftp-00.txt Pages : 9 Date : 11/15/1996 In order to overcome the problems inherent in the current FTP LIST output, a new command is needed to transfer standardized listing information from Server-FTP to Client-FTP. In addition, a way for the Server-FTP to let the Client-FTP know of this capability without imposing on the Client-FTP to randomly try new commands is needed. This proposal meets both of these requirements. This proposal also extends the FTP protocol to allow character sets other than US-ASCII[1] by allowing the transmission of 8-bit characters and the recommended use of UTF-8[2] encoding. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hethmon-mlst-command-ftp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-hethmon-mlst-command-ftp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-hethmon-mlst-command-ftp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118093606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hethmon-mlst-command-ftp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hethmon-mlst-command-ftp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118093606.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09129; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05706; 18 Nov 96 9:53 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-dhcp-08.txt Date: Mon, 18 Nov 1996 09:53:28 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180953.aa05706@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Dynamic Host Configuration Protocol Author(s) : R. Droms Filename : draft-ietf-dhc-dhcp-08.txt Pages : 44 Date : 11/15/1996 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcp-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcp-08.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcp-08.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115155535.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcp-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115155535.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ab09206; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa06077; 18 Nov 96 9:55 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-petke-mech-00.txt Date: Mon, 18 Nov 1996 09:55:29 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180955.aa06077@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Remote Passphrase Authentication Part Two: The Mechanism Author(s) : G. Brown Filename : draft-petke-mech-00.txt Pages : 14 Date : 11/15/1996 Remote Passphrase Authentication provides a way to authenticate a user to a service by using a pass phrase over an insecure network, without revealing the pass phrase to eavesdroppers. In addition, the service need not know and does not learn the user's pass phrase, making this scheme useful in distributed environments where it would be difficult or inappropriate to trust a service with a pass phrase database or to allow the server to learn enough to masquerade as the user in a future authentication attempt. This draft is part two of a four part series and explains the mechanism behind RPA. Part one of this series (draft-petke-ext-intro-00.txt) provides an extended introduction to the problems of authentication over insecure networks. Part three (draft-petke-http-auth-scheme-00.txt) explains how to incorporate the mechanism into HTTP. Part four (draft-petke-serv-deity-protocol-00.txt) explains the protocol between the service and deity. This scheme was inspired by Dave Raggett's Mediated Digest Authentication paper. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-petke-mech-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-petke-mech-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-petke-mech-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115164732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-petke-mech-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-petke-mech-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115164732.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ac09206; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa06285; 18 Nov 96 9:55 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-petke-serv-deity-protocol-00.txt Date: Mon, 18 Nov 1996 09:55:55 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180955.aa06285@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Remote Passphrase Authentication Part Four: Service-to-Deity Protocol Author(s) : G. Brown Filename : draft-petke-serv-deity-protocol-00.txt Pages : 12 Date : 11/15/1996 Remote Passphrase Authentication provides a way to authenticate a user to a service by using a pass phrase over an insecure network, without revealing the pass phrase to eavesdroppers. In addition, the service need not know and does not learn the user's pass phrase, making this scheme useful in distributed environments where it would be difficult or inappropriate to trust a service with a pass phrase database or to allow the server to learn enough to masquerade as the user in a future authentication attempt. This draft is part four of a four part series and explains the protocol between the service and the deity. Part one of this series (draft-petke-ext-intro-00.txt) provides an extended introduction to the problems of authentication over insecure networks. Part two (draft-petke-mech-00.txt) explains the RPA mechanism. Part three (draft-petke-http-auth-scheme-00.txt) explains how to incorporate the mechanism into HTTP. This scheme was inspired by Dave Raggett's Mediated Digest Authentication paper. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-petke-serv-deity-protocol-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-petke-serv-deity-protocol-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-petke-serv-deity-protocol-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115165518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-petke-serv-deity-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-petke-serv-deity-protocol-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115165518.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09045; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05688; 18 Nov 96 9:53 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: bmwg@harvard.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-call-00.txt Date: Mon, 18 Nov 1996 09:53:11 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180953.aa05688@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Terminology for Cell/Call Benchmarking Author(s) : R. Craig Filename : draft-ietf-bmwg-call-00.txt Pages : 13 Date : 11/15/1996 The purpose of this draft is to add terminology specific to the cell and call-based switch environment to that defined by the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF) in RFC1242. While primarily directed towards wide area switches, portions of the document may be useful for benchmarking other devices such as ADSU's. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-call-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-call-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-call-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115154931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-call-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-call-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115154931.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09128; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05655; 18 Nov 96 9:53 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-fr-update-02.txt Date: Mon, 18 Nov 1996 09:53:00 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180953.aa05655@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : Multiprotocol Interconnect over Frame Relay Author(s) : C. Brown, A. Malis Filename : draft-ietf-ion-fr-update-02.txt Pages : 34 Date : 11/15/1996 This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-fr-update-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-fr-update-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-fr-update-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115142547.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-fr-update-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-fr-update-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115142547.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09138; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa06419; 18 Nov 96 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ferguson-ingress-filtering-01.txt Date: Mon, 18 Nov 1996 09:56:14 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180956.aa06419@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Ingress Filtering Defending Against IP Source Address Spoofing Author(s) : P. Ferguson, D. Senie Filename : draft-ferguson-ingress-filtering-01.txt Pages : 7 Date : 11/15/1996 Recent occurrences of various Denial of Service attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective and straightforward methods for using ingress traffic filtering to deny attacks which use forged IP addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ferguson-ingress-filtering-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ferguson-ingress-filtering-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118092047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ferguson-ingress-filtering-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ferguson-ingress-filtering-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118092047.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09143; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05611; 18 Nov 96 9:52 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-provan-dhcp-options-dir-serv-00.txt Date: Mon, 18 Nov 1996 09:52:39 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180952.aa05611@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Options for Novell Directory Services Author(s) : D. Provan Filename : draft-provan-dhcp-options-dir-serv-00.txt Pages : 3 Date : 11/15/1996 This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. The first option carries a list of NDS servers. The second option carries the name of the client's NDS tree. The third carries the initial NDS context. These three options provide an NDS client with enough information to connect to an NDS tree without manual configuration of the client. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-provan-dhcp-options-dir-serv-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-provan-dhcp-options-dir-serv-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-provan-dhcp-options-dir-serv-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118094505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-provan-dhcp-options-dir-serv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-provan-dhcp-options-dir-serv-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118094505.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09106; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa06221; 18 Nov 96 9:55 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-petke-http-auth-scheme-00.txt Date: Mon, 18 Nov 1996 09:55:46 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180955.aa06221@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Remote Passphrase Authentication Part Three: HTTP Authentication Scheme Author(s) : G. Brown Filename : draft-petke-http-auth-scheme-00.txt Pages : 9 Date : 11/15/1996 Remote Passphrase Authentication provides a way to authenticate a user to a service by using a pass phrase over an insecure network, without revealing the pass phrase to eavesdroppers. In addition, the service need not know and does not learn the user's pass phrase, making this scheme useful in distributed environments where it would be difficult or inappropriate to trust a service with a pass phrase database or to allow the server to learn enough to masquerade as the user in a future authentication attempt. This draft is part three of a four part series and explains how to incorporate the RPA mechanism into HTTP. Part one of this series (draft-petke-ext-intro-00.txt) provides an extended introduction to the problems of authentication over insecure networks. Part two (draft-petke-mech-00.txt) explains the RPA mechanism. Part four (draft-petke-serv-deity-protocol-00.txt) explains the protocol between the service and deity. This scheme was inspired by Dave Raggett's Mediated Digest Authentication paper. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-petke-http-auth-scheme-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-petke-http-auth-scheme-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-petke-http-auth-scheme-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115165129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-petke-http-auth-scheme-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-petke-http-auth-scheme-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115165129.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09127; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa06373; 18 Nov 96 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: tosi@lkg.dec.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pouffary-itot-04.txt Date: Mon, 18 Nov 1996 09:56:05 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180956.aa06373@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Note: This revision reflects comments received during the last call period. Title : ISO Transport Service on top of TCP (ITOT) Author(s) : Y. Pouffary, A. Young Filename : draft-pouffary-itot-04.txt Pages : 29 Date : 11/15/1996 This document is a revision to RFC1006 written by Marshall T. Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience has been gained in using ISO transport services on top of TCP. This document refines the protocol and supersedes RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. The goal of this version is to minimise the number of changes to RFC1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC1006 users. Discussion list: tosi@lkg.dec.com To Subscribe send mail to tosi-request@lkg.dec.com Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pouffary-itot-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-pouffary-itot-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-pouffary-itot-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115171006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pouffary-itot-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-pouffary-itot-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115171006.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09108; 18 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa05975; 18 Nov 96 9:54 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-petke-ext-intro-00.txt Date: Mon, 18 Nov 1996 09:54:46 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611180954.aa05975@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Remote Passphrase Authentication Part One: Extended Introduction Author(s) : G. Brown Filename : draft-petke-ext-intro-00.txt Pages : 6 Date : 11/15/1996 Remote Passphrase Authentication provides a way to authenticate a user to a service by using a pass phrase over an insecure network, without revealing the pass phrase to eavesdroppers. In addition, the service need not know and does not learn the user's pass phrase, making this scheme useful in distributed environments where it would be difficult or inappropriate to trust a service with a pass phrase database or to allow the server to learn enough to masquerade as the user in a future authentication attempt. This draft is part one of a four part series and contains an extended introduction to the problem and potential solutions to the problem. It is optional reading for those already familiar with the general issues of authentication over insecure networks. Part two (draft-petke-mech-00.txt) explains the RPA mechanism. Part three (draft-petke-http-auth-scheme-00.txt) explains how to incorporate the mechanism into HTTP. Part four (draft-petke-serv-deity-protocol-00.txt) explains the protocol between the service and deity. This scheme was inspired by Dave Raggett's Mediated Digest Authentication paper. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-petke-ext-intro-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-petke-ext-intro-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-petke-ext-intro-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115164422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-petke-ext-intro-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-petke-ext-intro-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115164422.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa18620; 18 Nov 96 13:13 EST Received: from zephyr.isi.edu by ietf.org id aa17783; 18 Nov 96 13:03 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 18 Nov 1996 10:01:59 -0800 Message-Id: <199611181801.AA03403@zephyr.isi.edu> To: ietf@ietf.org, imr@isi.edu Subject: Internet Monthly Report for October, 1996 Cc: imr-ed@isi.edu Date: Mon, 18 Nov 96 10:01:58 PST Sender:ietf-request@ietf.org From: IMR Editor Source-Info: From (or Sender) name not authenticated. October 1996 INTERNET MONTHLY REPORTS ------------------------ The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the participating organizations. Each organization is expected to submit a 1/2 page report on the first business day of the month describing the previous month's activities. These reports should be submitted via network mail to "IMR@ISI.EDU". ````````````````````````````````````````````````````````````````````` The Internet Monthly Report mailing list is now managed by MajorDomo at ISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be ADDED or DELETED from the Internet Monthly report list should be sent to "majordomo@isi.edu" with the message body either "subscribe imr" or "unsubscribe imr". Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_imrs". For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs or URL: http://www.isi.edu/in-notes/imr/ IMR Editor [Page 1] Internet Monthly Report October 1996 TABLE OF CONTENTS INTERNET ARCHITECTURE BOARD IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3 INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3 Internet Projects INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 12 Registration Services . . . . . . . . . . . . . . . . . page 12 Directory Services. . . . . . . . . . . . . . . . . . . page 14 US Domain Registry. . . . . . . . . . . . . . . . . . . page 15 MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 20 UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 23 CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 24 TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 28 IMR Editor [Page 2] Internet Monthly Report October 1996 INTERNET ARCHITECTURE BOARD --------------------------- The minutes of the IAB back to 1990 are available for anonymous ftp access on host ftp.isi.edu, directory /pub/IAB, or via the IAB World-Wide Web page with URL http://www.iab.org/iab/. Brian Carpenter IAB Chair INTERNET ENGINEERING REPORTS ---------------------------- IETF Monthly Report for October, 1996 1. The IETF returns to San Jose, California on December 9-13, 1996. Our local host will be cisco Systems. The Secretariat will open for registrations the first part of October. The IETF opens 1997 in Memphis, Tennessee where Federal Express will be the host. This meeting will be held April 7-11, 1997. Following Memphis, the IETF is we returning to Europe and will met in Munich, Germany August 11-15, 1997, hosted by Digi/ISOC.DE. The Secretariat is still working on the final meeting of 1997. Once all the arrangements have been made, notifications will be sent to the IETF Announcement list. Remember that information on future IETF meetings can be always be found in the file 0mtg-sites.txt which is located on the IETF shadow directories. This information can also be viewed from the IETF Home Page on the Web. The URL is: http://www.ietf.org 2. The minutes of the IESG teleconferences have been publicly available on the IETF Shadow directories since 1991. These files are placed in the /ftp/iesg directory. The following IESG minutes have been added: September 19, 1996 (iesg.96-09-19) October 3, 1996 (iesg.96-10-03) October 17, 1996 (iesg.96-10-17) IMR Editor [Page 3] Internet Monthly Report October 1996 3. The IESG approved or recommended the following seven Protocol Actions during the month of October, 1996: o IMAP4 QUOTA extension be published as a Proposed Standard. o IMAP4 non-synchroniziong literals be published as a Proposed Standard. o TFTP Multicast Option be published as an Experimental Protocol. o IMAP4 ACL extension be published as a Proposed Standard. o The PPP NetBIOS Frames Control Protocol (NBFCP) be published as a Proposed Standard. o TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms be published as a Proposed Standard. o Triggered Extensions to RIP to Support Demand Circuits be published as a Proposed Standard. 4. The IESG issued nine Last Calls to the IETF during the month of October, 1996: o XDR: External Data Representation Standard for consideration as a Draft Standard. o Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type for consideration as a Proposed Standard. o Definitions of Managed Objects for the DS3/E3 Interface Type for consideration as a Draft Standard. o Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types for consideration as a Draft Standard. o Definitions of Managed Objects for IEEE 802.3 Repeater Devices for consideration as a Proposed Standard. o ISO Transport Service on top of TCP (ITOT) for consideration as a Proposed Standard. IMR Editor [Page 4] Internet Monthly Report October 1996 o Telnet window size option for consideration as a Proposed Standard. o Telnet terminal-type option for consideration as a Proposed Standard. o Multicast pruning a necessity for consideration as a Best Current Practices RFC. 5. Two Working Groups were created during this period: Calendaring and Scheduling (calsch) Physical Topology MIB (ptopomib) and one working group concluded: Network Training Materials (trainmat) 6. A total of 98 Internet-Draft actions were taken during the month of October, 1996: (Revised draft (o), New Draft (+) ) (avt) o RTP payload format for H.261 video streams (ion) o NBMA Next Hop Resolution Protocol (NHRP) (ospf) o IP Forwarding Table MIB (idmr) o Protocol Independent Multicast (PIM): Motivation and Architecture (none) o TCP MD5 Signature Option (mailext) o Common Internet Message Headers (cat) o Public Key Cryptography for Initial Authentication in Kerberos (none) o SMTP Service Extension for Authentication (cat) o Simple GSS-API Negotiation Mechanism (none) o Guidelines for IETF Meeting Sites (atommib) o Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management IMR Editor [Page 5] Internet Monthly Report October 1996 (avt) o RTP Payload Format for MPEG1/MPEG2 Video (idmr) o Internet Group Management Protocol, Version 2 (none) o Simple Authentication and Security Layer (idmr) o Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (none) o Universal Payment Preamble (rip) o Protocol Analysis for Triggered RIP (trunkmib) o Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types (trunkmib) o Definitions of Managed Objects for the DS3/E3 Interface Type (ipngwg) o Generic Packet Tunneling in IPv6 Specification (st2) o Internet Stream Protocol Version 2 (ST2) Protocol State Machines - Version ST2+ (pktway) o Proposed Specification for the PacketWay Protocol (ids) o X.500 Implementations Catalog-96 (applmib) o Definitions of Managed Objects for Applications (none) o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (dhc) o Interaction between DHCP and DNS (none) o VEMMI URL Specification (asid) o Lightweight Directory Access Protocol: Standard and Pilot Attribute Definitions (asid) o Lightweight Directory Access Protocol (v3) (drums) o Augmented BNF for Syntax Specifications: ABNF (idr) o Configuring IDRP Confederations (none) o Mail Ubiquitous Security Extensions (MUSE) (none) + Introduction to IP Multicast Routing IMR Editor [Page 6] Internet Monthly Report October 1996 (madman) o Mail and Directory Alarms (atommib) o Definitions of Managed Objects for ATM Management (atommib) o Definitions of Managed Objects for the SONET/SDH Interface Type (atommib) o Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals (pier) o Router Renumbering Guide (mhtml) o MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) (ipsec) o HMAC-MD5 IP Authentication with Replay Prevention (ipsec) o HMAC-SHA IP Authentication with Replay Prevention (mhtml) o Sending HTML in E-mail, an informational supplement to RFC ???: MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML) (ids) o Best Current Practice for the Internet White Pages Service (ids) o Finding Stuff (Providing information to support service discovery) (none) o Quality of Sevice (QoS)-Based Routing in the Internet - Some Issues (none) o Dialup Roaming Requirements (none) + Resolution of Uniform Resource Identifiers using the Domain Name System (asid) o Lightweight Directory Access Protocol: Extensions for Dynamic Directory Services (mhtml) o Content-ID and Message-ID Uniform Resource Locators (ripv2) o RIP Version 2 Carrying Additional Information (none) o IPv4 Address Behaviour Today (otp) o OTP Extended Responses (none) + A Primer On Internet and TCP/IP Tools and Utilities (none) + EARTH - EAsy IP multicast Routing THrough ATM clouds (none) + Network News Transport Protocol IMR Editor [Page 7] Internet Monthly Report October 1996 (none) + Network Ingress Filtering (none) + The TACACS+ Protocol (none) o A Method for the Transmission of IPv6 Packets over ARCnet Networks. (ipcdn) + IP Over Cable Data Network Service (none) + Internet Secure Electronic Mail: Algorithms, Modes, and Identifiers for FORTEZZA Cryptography (none) + NFS URL Scheme (none) o IMAP URL Scheme (none) o NNTP Full-text Search Enhancements (none) + Use of Flow Label for Tag Switching (none) + WebNFS Server Specification (none) + Use of Tag Switching With ATM (none) + Defending Against IP Source Address Spoofing (none) + Data Link Switching Remote Access Protocol (none) + WebNFS Client Specification (none) + Responsible Network Management Guidelines (none) + Real Time Streaming Protocol(RTSP) (none) + The AM Domain (none) + The LDAP Application Program Interface (none) + Management Information Base for IP Version 6 (none) o FTP Extensions for Variable Protocol Specification (asid) + A String Representation of LDAP Search Filters (none) + The Safe Response Header (none) + MIME Parameter Value and Encoded Words: Character Sets, Language, and Continuations (none) + A Mail-Safe Transformation Format of Unicode IMR Editor [Page 8] Internet Monthly Report October 1996 (ipngwg) + IPv6 Multicast Address Assignments (none) + Multicast Synchronization Protocol (MSP) (none) + The Simple Record Framing Protocol (none) + Advanced Sockets API for IPv6 (none) + NNTP LIST Additions (ediint) o MIME-based Secure EDI (none) + Remote Network Monitoring MIB Extensions for Switch Networks (none) + Wrapping MIME Objects: Application/MIME (none) + Combined 3DES-CBC, LZS Compression, HMAC, and Replay Prevention ESP Transform (mboned) o The Use of SNTP as a Multicast Heartbeat (none) + 8+8 - An Alternate Addressing Architecture for IPv6 (none) + Simple Hit-Metering for HTTP Preliminary Draft (ipngwg) + IPv6 Routing Table Size Issues (none) + Management Information Base for Frame Relay DTE Extensions for SVC's over Frame Relay (none) + Management Information Base for Frame Relay DCP DTE Extensions for Data Compression over Frame Relay (urn) + URN Syntax (http) + Feature Tag Registration Procedures (none) + Payload Format for HTTP Encoding in RTP (none) + Restricting the External Archiving of Email IMR Editor [Page 9] Internet Monthly Report October 1996 7. There were 40 RFCs published during the month of October, 1996: RFC St WG Title ------- -- -------- ------------------------------------- RFC2002 PS (mobileip) IP Mobility Support RFC2003 PS (mobileip) IP Encapsulation within IP RFC2004 PS (mobileip) Minimal Encapsulation within IP RFC2005 PS (mobileip) Applicability Statement for IP Mobility Support RFC2006 PS (mobileip) The Definitions of Managed Objects for IP Mobility Support using SMIv2 RFC2007 I (trainmat) Catalogue of Network Training Materials RFC2008 B (cidrd) Implications of Various Address Allocation Policies for Internet Routing RFC2010 I (none) Operational Criteria for Root Name Servers RFC2014 B (none) IRTF Research Group Guidelines and Procedures RFC2015 PS (none) MIME Security with Pretty Good Privacy (PGP) RFC2016 E (none) Uniform Resource Agents (URAs) RFC2017 PS (mailext) Definition of the URL MIME External-Body Access-Type RFC2018 PS (tcplw) TCP Selective Acknowledgment Options RFC2019 PS (ipngwg) Transmission of IPv6 Packets Over FDDI RFC2020 PS (vgmib) Definitions of Managed Objects for IEEE 802.12 Interfaces RFC2023 PS (ipngwg) IP Version 6 over PPP RFC2024 PS (dlswmib) Definitions of Managed Objects for Data Link Switching using SNMPv2 RFC2025 PS (cat) The Simple Public-Key GSS-API Mechanism (SPKM) RFC2026 B (poised95) The Internet Standards Process -- Revision 3 RFC2027 B (poised95) IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees RFC2028 B (poised95) The Organizations Involved in the IETF Standards Process RFC2029 PS (avt) RTP Payload Format of Sun's CellB Video Encoding RFC2030 I (none) Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI RFC2031 I (poised95) IETF-ISOC relationship RFC2032 PS (avt) RTP payload format for H.261 video streams RFC2033 I (none) Local Mail Transfer Protocol IMR Editor [Page 10] Internet Monthly Report October 1996 RFC2034 PS (none) SMTP Service Extension for Returning Enhanced Error Codes RFC2035 PS (avt) RTP Payload Format for JPEG-compressed Video RFC2036 I (cidrd) Observations on the use of Components of the Class A Address Space within the Internet RFC2037 PS (entmib) Entity MIB RFC2038 PS (avt) RTP Payload Format for MPEG1/MPEG2 Video RFC2040 I (none) The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms RFC2041 I (none) Mobile Network Tracing RFC2043 PS (pppext) The PPP SNA Control Protocol (SNACP) RFC2044 I (none) UTF-8, a transformation format of Unicode and ISO 10646 RFC2051 PS (snanau) Definitions of Managed Objects for APPC RFC2052 E (none) A DNS RR for specifying the location of services (DNS SRV) RFC2053 I (none) The AM (Armenia) Domain RFC2054 I (none) WebNFS Client Specification RFC2055 I (none) WebNFS Server Specification St(atus): ( S) Internet Standard (PS) Proposed Standard (DS) Draft Standard ( B) Best Current Practice ( E) Experimental ( I) Informational Steve Coya IMR Editor [Page 11] Internet Monthly Report October 1996 INTERNET PROJECTS ----------------- INTERNIC -------- REGISTRATION SERVICES I. Significant Events Help Desk Support The following foreign language skills are now available in the Call/Processing Center: Spanish, French, Portuguese, Chinese (Mandarin), Hindu, Urdu, Punjabi, English, and Canadian; five CSRs are available to support the pending Latin NIC with Spanish/Portuguese. Presentations were viewed by four telecommunications vendors regarding available technology for a new PBX/ACD system. 16 new staff were trained regarding Billing customer service. Increasing reports were received indicating that customers are receiving busy signals when they call or are being put on hold for excessively long times; this was caused by the rapid growth in registrations plus the large numbers of invoices and 15-Day Final Invoices being sent out; plans are being implemented to correct the problems. Name Registration Support DomReg software enhancements have reduced the number of requests that need to be processed manually from about 1,000 to 700 (30% improvement). The majority of registration processing work was taken over by night shift personnel, thereby freeing up more staff to answer Help Desk calls during regular business hours. Billing Support A contract was negotiated and executed to outsource printing and mailing of invoices to Osprey Imaging; start date is targeted for early November. IMR Editor [Page 12] Internet Monthly Report October 1996 A contract was negotiated and executed to outsource the process of receiving telephone credit card payments to First Data Call Interactive; an automated voice response system will be used; start date is targeted for late November. A contract was negotiated and executed to outsource the function of processing credit card payments with the associated credit card companies. First Data Merchant Services is the company involved; credit cards to be accepted are VISA, Master Card, American Express, Discover/NOVA, Diners Club, and JCB; start date is targeted for late November. Workloads continued to accelerate; additional temporary staff was added to use all available PCs on the night shift (6 p.m. to midnight) and on Saturdays and Sundays. IP Support Kim Hubbard met with Jon Postel (IANA), David Conrad (APNIC) and Daniel Karrenberg (RIPE) in California to discuss IP issues. Kim attended the NANOG meeting in Ann Arbor, Michigan. Information Services Support The process of notifying Admin Contacts for all domain names about Revision 2 of the Name Dispute Policy was completed, including a minimum of one attempt for each of 291,673 contacts. The 15-Minute Training Series was promoted at the EDUCOM 96 conference in Philadelphia and the ACM-SIGUCCS meeting. Possible partners are being explored for implementing a Spanish version of the 15-Minute Series. Technical work is ongoing to implement First Virtual Two new web specialists were hired. IMR Editor [Page 13] Internet Monthly Report October 1996 II. Current Status October: Email: 246,727 Postal/Fax: 3,466 Phone: 41,672 Gopher connections: n/a retrievals: 33,623 WAIS connections: 44,908 retrievals: 29,780 FTP connections: 62,227 retrievals: 122,014 Mailserv: n/a Telnet: 93,804 Http: 4,092,824 Whois client: 330,124 Whois server: 8,686,336 Rich Landers INTERNIC DIRECTORY AND DATABASE SERVICES For some time, InterNIC Directory and Database Services has been storing the IETF sessions that are broadcast on the MBONE. These sessions could be downloaded and played back at a later time. This helped participants who could not listen to the sessions live because of other commitments or because of time zone differences. The system was somewhat awkward to use because the VAT/RTP format used on the MBONE produced multi-megabyte files that had to be downloaded to the listener's machine and played back in full. We have now implemented a web-accessible version of the recordings using Real Audio format. Using this format, users can listen to parts of a session via the web and skip over sections that are not of interest. The Real Audio MBONE recordings may be found at: http://ds.internic.net/mbone/mbone.html The current recordings were used during our testing and are from the March IETF meeting. Recordings from the upcoming San Jose IETF will be available in December. IMR Editor [Page 14] Internet Monthly Report October 1996 To listen to the Real Audio versions, users will have to install a Real Audio player. A free version of the player is available from Progressive Networks for a number of different processor/operating system combinations at the following URL: http://www.realaudio.com/products/player/download.html A reminder - if you would like to help the Internet community find a resource that you offer, send mail to admin@ds.internic.net and we will send information about listing your resource in the Directory of Directories. If you prefer, you can enter information about your resource in our WWW suggestion form. The form can be reached through our Directory of Directories Web page at: http://ds.internic.net:80/ds/dsdirofdirs.html by Rick Huber THE US DOMAIN REGISTRY ---------------------- The US Domain now has an online line registration form. Some of the processing of the requests to the third level domain name is now automated. In particular, most requests to register names in localities already delegated are automatically forwarded to the administrator for that locality. The US Domain administrator no longer makes direct registrations of hosts, and only makes delegations of third or fourth level domain names (such as localities). A new policy has been added to the criteria for delegating domain names under the US Domain: It is the intention that the delegation of third level (for example, locality) domain names be wide spread to many registries. It is undesirable for one person or organization to manage a large part of the third level names in any particular geographic or logical area. No individual or organization shall have more than 500 delegations total in the US Domain as a whole, or more than 50 delegation in any particuilar second level (for example, a state). IMR Editor [Page 15] Internet Monthly Report October 1996 About the special domains under the state codes. The K12, CC, TEC, LIB, STATE, DST, COG and GEN domain under each state are established for special purposes (see RFC 1480). In addition to the constaint to use them only for the defined purpose, each of these special domains is also to delegated only to a manager within the state, and the operation of the delegated registry should be non-profit. The LIB domain should be managed by a govermental or educational library organization. Further, it is most appropriate for the K12, CC, and TEC, domains to be managed by an educational organization (for example, a university or a department of education). The STATE domain is most appropriately managed by an agency of the state government. DST and COG should be managed by a goverment agency. The GEN domain may be delegated to any organization that will provide the registration service for free (and remember the purpose of the GEN domain is to register statewide non-profit organizations). To obtain a copy of the list of other delegated localities and subdomains not administered by the US Domain Registrar, get the file "us-domain-delegated.txt". URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt For further information about the US Domain, send a message to: US-DOMAIN@ISI.EDU, or see our WEB page: http://www.isi.edu/us-domain IMR Editor [Page 16] Internet Monthly Report October 1996 US DOMAIN ADMINISTRATIVE INFORMATION ------------------------------------ EMAIL/FAX 3163 PHONE 450 ---------------------------- Total Contacts 3613 DELEGATIONS 133 FORWARDED DELEGATIONS:1129 OTHER US DOMAIN MSGS: 2351 --------------------------- Total 3613 OTHER US DOMAIN MESSAGES INCLUDE: referrals to other subdomains or to/from the InterNic, phone calls, modifications, application requests, discussion and clarification of the requests, questions about names, resolving technical problems with zone files and name servers, and whois listings. In addition, and not listed below, another 1052 localities have been delegated in Arizona, Arkansas, California, Colorado, Connecticut, Massachusetts, Maryland, Missouri, Montana, Michigan , Mississippi, North Carolina, New Jersey, New York, Virginia, Vermont, Illinois, Tennessee, Utah and Wyoming this month. MAJOR SUBDOMAINS DELEGATED K12 CC TEC STATE LIB MUS GEN DST COG =================================================================== 51 37 34 47 39 24 24 9 5 =================================================================== IMR Editor [Page 17] Internet Monthly Report October 1996 ----------------------- THIRD LEVEL DELEGATIONS ----------------------- MUS.IA.US. Museums, Iowa. COG.IA.US. Council of Governments, Iowa. LOCALITIES ========== WALKER.MI.US. ROCKFORD.MI.US. ADA.MI.US. JACKSON.WY.US. MOOSE.WY.US. WILSON.WY.US. ENTERPRISE.OK.US. WILBURTON.OK.US. POTEAU.OK.US. SEABROOK.NH.US. NEWINGTON.NH.US. NEWMARKET.NH.US. GREENLAND.NH.US. MABEL.MN.US. ORTONVILLE.MN.US. LONDONDERRY.NH.US. MANCHESTER.NH.US. SENECA.NY.US. SCHUYLER.NY.US. CLEAR-LAKE.IA.US. STORM-LAKE.IA.US. AMANA.IA.US. OKOBOJI.IA.US. SPIRIT-LAKE.IA.US. LEAD.SD.US. WHITEWOOD.SD.US. BELLE-FOURCHE.SD.US. MITCHELL.SD.US. EVANSTON.IL.US. WAUKEGAN.IL.US. MERRILLVILLE.IN.US. PUYALLUP.NSN.US. OLIVIA.MN.US. NEW-YORK.NY.US. ALLEN.TX.US. MARTHAS-VINEYARD.MA.US. STEAMBOAT-SPRINGS.CO.US. ARAPAHOE.CO.US. LODI.CA.US. ENGLEWOOD.OH.US. PLUMAS.CA.US. ALBANY.CA.US. WESTCHESTER.CA.US. STURGIS.SD.US. ALBEMARLE.VA.US. LAKE.CA.US. FAIRFIELD.IA.US. WAHOO.NE.US. WASHINGTON.UT.US. PALATINE.IL.US. CARTHAGE.NC.US. MOUNT-AIRY.MD.US. LAFAYETTE.CA.US. PLATTEVILLE.WI.US. IONIA.MI.US. MARYVILLE.MO.US. FLEMING.CO.US. ALPHARETTA.GA.US. RAYTOWN.MO.US. BREVARD.NC.US. MCCALL.ID.US. LUDLOW.VT.US. DANVILLE.IL.US. BIG-ISLAND.VA.US. NEWARK.CA.US. CREVE-COEUR.MO.US. HAMPDEN.PA.US. LAUREL.MD.US. VINALHAVEN.ME.US. SANDUSKY.OH.US. SUTTER-CREEK.CA.US. IMR Editor [Page 18] Internet Monthly Report October 1996 OTHER US DOMAIN DELEGATIONS THIS MONTH -------------------------------------- BORO.ZELIENOPLE.PA.US. FREEDOM.WASHINGTON.DC.US. ENVIRON.STATE.DC.US. CO.GOOCHLAND.VA.US. CENTRALSAN.DST.CA.US. PVWMA.DST.CA.US. BIZ.CI.WEST-POINT.MS.US. JOE.LISLE.IL.US. AMPHIGORY.MONTICELLO.IN.US. ARPA.ST-CLAIR-SHORES.MI.US. PD.CHICAGO-HEIGHTS.IL.US. PD.STREAMWOOD.IL.US. PD.JUSTICE.IL.US. CREATIVEDESIGN.COLLEGE.MD.US. HCST.TEC.NJ.US. HEALTH.CO.YATES.NY.US. CO.CHEMUNG.NY.US. CO.STEUBEN.NY.US. HEALTH.CO.GENESEE.NY.US. HEALTH.CO.ALLEGANY.NY.US. HEALTH.CO.FULTON.NY.US. CO.CAPE-MAY.NJ.US. WADLEIGH.LIB.NH.US. AMHERST.LIB.NH.US. CI.WYMORE.NE.US. CROSSROAD.BRODHEAD.WI.US. CO.ITAWAMBA.MS.US. KUA.DST.FL.US. COA.WRENTHAM.MA.US. TOWNSHIP.DELTA.MI.US. GECAP.SALT-LAKE-CITY.UT.US. CI.RICHWOOD.WV.US. MVRTA.DST.OH.US. CI.PONCA.NE.US. CI.DESHLER.NE.US. CI.TILDEN.NE.US. HORTON.MADISON.AL.US. TRAVELWAYS.WAYZATA.MN.US. NETINC.HUMBLE.TX.US. FISHING.HILTON-HEAD-ISLAND.SC.US. ZERO.GEN.CA.US. CI.MONTEBELLO.CA.US. INTERSURF.HIGHLAND.IN.US. THINKNET.GARDEN-GROVE.CA.US. DIALOGNET.GARDEN-GROVE.CA.US. CI.CEDAR-HILLS.TX.US. CI.LEBANON.OR.US. GSSA.GEN.GA.US. NEOAM.CC.OK.US. SPALEK.MOUNTAIN-VIEW.CA.US. CO.BALDWIN.AL.US. BEMA.TOWN.BELMONT.MA.US. INTERIORS.ALAMEDA.CA.US. REDLANDS.CC.OK.US. DRINKARD.MADISON.AL.US. KENTWOODCC.GEN.MI.US. HOPENETWORK.GEN.MI.US. TRICOUNTYTECH.TEC.OK.US. POLICE.JACKSON.OH.US. CHAMBER.HILTON-HEAD-ISLAND.SC.US. ----------------------------------------------------------- URL: http://www.isi.edu/us-domain/ Shanthi Ranganathan (US-Domain@ISI.EDU) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IMR Editor [Page 19] Internet Monthly Report October 1996 MERIT INTERNET ENGINEERING -------------------------- This report summarizes October 1996 activities of Merit's Internet Engineering group on behalf of the Routing Arbiter (RA) service and other projects. Based on feedback from providers at the exchange points, Jake Khuon has developed a mechanism that gives ISPs increased control over their Route Server peering sessions. Two new fields in the Route Server Peering Request Template, rs-in and rs-out, can be used to specify exactly which routes the Route Server should import and export on behalf of each peer. The new fields can also be used to enable route-flap dampening and specify whether the RS=92s AS number should be inserted into route announcements to the peer. The new fields will eventually be proposed as an extension to the RIPE inet-rtr object. Further details are available from: http://www.ra.net/peering.template.html Volunteer sites are still needed for Merit's Network Probe Daemon (NPD) project, a study of Internet routing patterns using a global traceroute matrix. Sites participating in the project are asked to run the NPD software, which runs on any standard Unix system. For more information, see: http://compute.merit.edu/stats/npd/npd.html The NPD software is available from ftp://nic.merit.edu/routing.arbiter/tools/npd-1.0.tar.Z. If you are interested in participating, please send e-mail to Dun Liu (dunl@merit.edu.) Your help is greatly appreciated! IMR Editor [Page 20] Internet Monthly Report October 1996 Merit hosted the eighth North American Network Operators' Group (NANOG) meeting in Ann Arbor on October 24-25. Stan Barber of Academ Consulting Services has kindly made available a complete set of notes and slides from the meeting; they are available through Merit's Web site (http://www.nanog.org). Bill Norton of Merit moderated the meeting, which featured the following presentations: >STATE OF THE INTERNET: NAPs PacBell NAP Warren Williams, PacBell Sprint NAP Steve Schnell, Sprint Ameritech NAP Andy Schmidt, Ameritech The MAEs Steve Feldman, MFS Datanet >STATE OF THE INTERNET: NSPs Sprint Benham Malcom, Sprint IBM Global Network Dimitri Krinos and Scott Blandford, IBM ANS Curtis Villamizer, ANS AGIS Peter Kline, AGIS=20 >New Exchange Point Matt Zimmerman, Netrail Announcement >Some Economics Issues for Jeff Mackie-Mason, the Future Internet Univ. of Mich. >vBNS Overview and Status John Jamison, MCI/vBNS >Broadening vBNS Access: Mark Luker, NSF, and the New Connections Program Jim Williams, FARNET >STATE OF THE INTERNET: Statistical Research, Part 1 Network Probe Daemon Dun Liu and Sue Hares, Merit Routing Stability Craig Labovitz, Merit Analysis >Customer Requirements for Sue Hares, Merit Future Routers - What's Next? (moderator) 3Com Corporation Cyndi Jung, 3Com Cisco Systems Dave O'Leary, Cisco NetStar Jeff Wabik, Ascend Bay Networks Jeff Burgan, Bay IMR Editor [Page 21] Internet Monthly Report October 1996 >RA Update Bill Manning, ISI Brian Renaud, Merit >STATE OF THE INTERNET: Statistical Research, Part 2 Flow Switching Overview John Hawkinson, BBN Planet, and Daniel McRobb, ANS Current Efforts in Kim Claffy, SDSC Statistics/Metrics Research and Practice >New Tools from the RA: Craig Labovitz, Merit NetNow and IPN (Inter- Provider Notification) >MBoneD Working Group Update Dave Meyer, Univ. of Oregon >Source Spoofing and SYN Avi Freedman, Net Access, Flooding: Problems, Moderator Solutions, Community Views, and Discussion >Scalable Support for Multi- Yakov Rekhter, Cisco homed, Multi-provider Systems Connectivity >Multi-homing: Overview, Pros and Cons, Community Views Curtis Villamizer, ANS Avi Freedman, Net Access Randy Bush, RGnet >Trans-Atlantic IP Over SONET Peter Lothberg The NANOG sessions were followed by a Route Flap BOF and a Routing Arbiter tutorial, covering various aspects of peering with the Route Servers and registering in the RADB. Susan R. Harris (srh@merit.edu) IMR Editor [Page 22] Internet Monthly Report October 1996 UCL ---- Finally, we released the windows versions of our audio tool and LBL's video tool, as well as versions of sdr and nte - these last two were the "parting gift" from Mark Handley, who has now moved from UCL, to ISI (North East). http://www-mice.cs.ucl.ac.uk/mice/rat/ http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic and the MICE FTP Area for other tools ftp://cs.ucl.ac.uk/mice/ Crowcroft presented a keynote on QoS at the Protocol's for High Speed Networks workshop at INRIA in France, and a paper on Charging in the Internet at an IEE Colloquium - see http://www.cs.ucl.ac.uk/staff/jon/hipparch/hipparch.html for pointers to papers. John Crowcroft (j.crowcroft@CS.UCL.AC.UK) IMR Editor [Page 23] Internet Monthly Report October 1996 CALENDAR -------- Last update 11/8/96 The information below has been submitted to the IETF Secretariat as a means of notifying readers of future events. Readers are requested to send in dates of events that are appropriate for this calendar section. Please send submissions, corrections, etc., to: Please note: The Secretariat does not maintain on-line information for the events listed below. A copy of this calendar is available as follows: VIA FTP ------- IETF Information is available by anonymous FTP from several sites. US East Coast Address: ds.internic.net (198.49.45.10) US West Coast Address: ftp.isi.edu (128.9.0.32) Europe Address: nic.nordu.net (192.36.148.17) Pacific Rim Address: munnari.oz.au (128.250.1.21) Africa Address: ftp.is.co.za (196.4.160.12) cd ietf ls *0mtg* WWW ------- Click on the link for "meetings" and you should find an entry "listing of other Internet related events". ************************************************************************ 1996 ---------- Nov. 10-12 2nd annual of ACM's MobiCom '96 Rye, New York Nov. 11-15 IEEE 802 '96 Hotel Vancouver Vancouver, BC Canada Nov. 12-15 3rd Int'l Conf. on Multimedia Modeling Toulouse, France Nov. 13 Commercenet Santa Clara, CA IMR Editor [Page 24] Internet Monthly Report October 1996 Nov. 13 TERENA Tech. Committee Brussels Nov. 18-20 2nd USENIX Workshop on Electronic Commerce Oakland, CA Nov. 18-22 ACM Multimedia '96 Boston, MA Nov. 18-22 IEEE Globecom 96 London, England Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA Nov. 20-21 IEEE Global Internet '96 London, UK Nov. 20-22 W3C Web Int'l & Multilingualism Symposium Sevilla, Spain Nov. 25-28 EITC'96 - European IT Conference Brussels, Belgium Nov. 25-29 NetWorld+Interop Sydney, Australia Dec. 2-4 Web World San Diego, CA Dec. 2-6 ANSI X3T11 (host by IBM) Minneapolis, MN Dec. 2-6 ATM Forum Vancover, BC Dec. 4 JENC8 Programme Committee Amsterdam Dec. 4-6 Vir. Reality & VRML World '96 Boston, MA Dec. 9-12 Internet World '96 Baltimore, MD Dec. 9-13 37th IETF (host by cisco) San Jose, CA Dec. 9-13 OIW (Firm) Dec. 10-12 EEMA (Electronic Communications) London Dec. 10-13 Fall Internet World '96 New York, NY Dec. 12 Internet Security for System & Network Administrators Pittsburgh, PA Dec. 13 Commercenet Albuquerque, NM Dec. 17 TERENA Executive Committee Amsterdam 1997 ----------- Jan. 6-10 ANSI X3T10 '97 Jan. 6-10 USENIX '97 Annual Technical Conf. Anaheim, CA Jan. 6-10 USELINUX: Linux Appl. Dev. Anaheim, CA Jan. 7-10 13th Annual Hawaii Int'l Conf on Systems Sciences Maui, Hawaii Jan. 7-10 Internet World Canada '97 Toronto, Canada Jan. 20-22 RIPE 26 Amsterdam Jan. 21-23 Internet World Shanghai-China Shanghai, China Jan. 21-25 Internet World Singapore Intl Singapore Jan. 22 TERENA Tech. Committee Amsterdam Jan. 28-30 IEEE 802.10 Interim meeting Orlando, FL Jan. 28-31 RSA Data Security Conf San Francisco Feb. 3-7 ANSI X3T11 (host by Sun) San Jose, CA Feb. 9-14 ATM Forum San Diego, CA Feb. 10-11 ISOC Symposium on Network and Distributed System Security San Diego, CA Feb. 10-12 Multimedia Computing & Networking 1997 San Jose, CA Feb. 17-19 Internet Expo & EMail World San Jose, CA IMR Editor [Page 25] Internet Monthly Report October 1996 Mar. 1-5 ACM '97: The Next 50 yrs. of Computing San Jose, CA Mar. 10-11 10th Int'l Unicode Conf & Global Computing Showcase Mainz, Germany Mar. 10-13 UniForum San Francisco, CA Mar. 10-14 OIW (Firm) Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque Mar. 11-14 Spring Internet World '97 Los Angeles, CA Mar. 11-15 ANSI X3T10 '97 Mar. 17-19 1st Euromicro Working Conf. on Software Maintenance & Reengineering Berlin, Germany Mar. 19-21 Internet World Asia '97 Kuala Lumpur, Malaysia Mar. 24-27 APPN Implementers Workshop Raleigh, NC Apr. 7-10 EMA'97 Philadelphia, PA Apr. 7-11 38th IETF (host by Fed. Exp) Memphis, TN Apr. 7-11 ANSI X3T11 (Brocade) Palm Springs, CA Apr. 7-11 IEEE INFOCOM '97 Kobe, Japan Apr. 7-12 W3C "Accessibility" 6th Int'l WWW Conference Santa Clara, CA Apr. 9-11 ISADS 97 - 3rd Intl Symposium on Autonmous Decentralized Sys. Berlin, Germany Apr. 22-24 Internet Expo & EMail World Chicago, IL Apr. 27-May 2 ATM Forum Chicago, IL May 5-9 ANSI X3T10 '97 May 5-9 NATO Workshop Edinburgh, Scotland May 12-15 8th JENC8 Edinburgh, Scotland May 12-16 IFIP/IEEE San Diego, CA May 15-16 TERENA General Assembly Edinburgh, Scotland May 19-21 7th Int'l Workshop on Ntwk & Oper for Digital Audio & Video St. Louis, MO May 21-23 RIPE 27 Dublin May 27-29 IS&N '97 4th Int'l Conf. on Intelligence in Services & Networks Como, Italy May 28-30 Web Developer '97 Chicago, IL Jun. 2-6 IEEE Multimedia Systems '97 Ottawa, CANADA Jun. 3-5 Internet World Mexico '97 Mexico City, Mexico Jun. 8-12 ICC '97 (joint with ENM) Montreal, CANADA Jun. 9-13 OIW (Firm) Jun. 9-13 ANSI X3T11 (host by Boeing) Seattle, WA Jun. 16-18 EEMA'97 Netherlands Jun. 24-27 INET '97 Kuala Lumpur, Malaysia Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI Jul. 14-18 ANSI X3T10 '97 Jul. 14-17 APPN Implementers Workshop San Jose, CA Jul. 20-25 ATM Forum Montreal, CANADA Aug. 4-8 ANSI X3T11 (host by Hitachi) Honolulu, HI IMR Editor [Page 26] Internet Monthly Report October 1996 Aug. 11-15 39th IETF (host by German ISOC) Munich, Germany Aug. 12-14 (tenative) Internet Expo & EMail World Boston, MA Sep. 8-12 ANSI X3T10 '97 Sep. 8-12 OIW (Firm) Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France Sep. 21-26 ATM Forum Paris, France Oct. 6-10 ANSI X3T11 (host by FSI) Tucson, AZ Oct. 7-10 Internet Forum Europe (IFE) & Object World Frankfurt (OWF) Frankfurt, Germany Nov. 3-7 ANSI X3T10 '97 Nov. 30-Dec 5 ATM Forum Singapore Dec. 1-5 ANSI X3T11 (host by DPT) Orlando, FL Dec. 8-12 40th IETF (tentative) Univ. of Hawaii Dec. 8-12 OIW (Firm) TELECOM '97 Asia (Venue and Dates to be Determined) 1998 ----------- Feb. 8-13 ATM Forum TBA Apr. 19-24 ATM Forum TBA SPRING 1998 TELECOM '97 Africa Midrand, South Africa Jul. 26-31 ATM Forum TBA Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and Oct. 4-9 ATM Forum TBA Dec. 6-11 ATM Forum TBA 1999 ----- Oct. 8-14 TELECOM '99 Geneva, Switzerland IMR Editor [Page 27] Internet Monthly Report October 1996 TERENA List of Meetings CALENDAR updated 1 November 1996 This list of meetings is provided for information. Many of the meetings are closed or by invitation; if in doubt, please contact the chair of the meeting or the TERENA Secretariat. If you have additions/corrections/comments, please mail . ********************************************************************** NAME / DATE LOCATION TERENA General Assembly GA7 15-16 May 1997 Edinburgh TERENA Executive Committee 17 December Amsterdam TERENA Technical Committee 13 November Brussels 22 January 1997 Amsterdam JENC8 Conference Committee 8 November Edinburgh Programme Committee 4 December Amsterdam SCIMITAR -------- Concertation 14 November Brussels TF-CACHE -------- 23 January 1997 Amsterdam IMR Editor [Page 28] Internet Monthly Report October 1996 ============================================================= CCIRN ----- 12 or 13 December (tbc) San Jose EEMA ---- Electronic Communications 10-12 December London Spring Conference and Exhibition February 1997 Berlin ENPG ---- 10 January 1997 Amsterdam ETSI ---- GA24 10-11 December Nice, France TA25 23-25 October " EWOS ---- TA35, 3-4 December Brussels TA36, 25-26 February 1997 " TA37, 13-14 May 1997 " TA38, 16-17 September 1997 " TA39, 2-3 December 1997 " SC - 17 December Workshops 36: 20-24 January 1997 Brussels 37: 7-11 April 1997 " 38: 16-20 June 1997 " 39: 27-31 October 1997 " ICT Partnership - General Meeting --------------------------------- 29 January 1997 (tbc) Brussels IMR Editor [Page 29] Internet Monthly Report October 1996 IETF ---- 9-13 December San Jose, CA 7-11 April 1997 Memphis, Tenn. 11-15 August 1997 Munich, Germany NATO ---- Workshop 5-9 May 1997 Edinburgh RIPE ---- RIPE 26 20-22 January 1997 Amsterdam RIPE27 21-23 May 1997 Dublin RIPE IR Training 11 November Berlin 12 November " +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TERENA CONFERENCES Call for Papers JENC8 - 8th Joint European Networking Conference "Diversity and Integration: The New European Networking Landscape" 12-15 May 1997 Edinburgh, Scotland This conference will be the European Forum to get up-to-date information, to debate and assess the new deregulated tele- communication environment in Europe, new leading-edge applications, and the network/internetwork support infrastructure which is currently being developed Subject Areas: * Emerging Network Technologies and Network Engineering * User Support, Training and Education IMR Editor [Page 30] Internet Monthly Report October 1996 * Security and Management Issues * Information Systems and Distributed Applications * Economic and Political Issues Deadline for paper submission 10 November 1996 to: For information please contact the JENC8 Secretariat at: TERENA Secretariat Singel 466-468 1017 AW Amsterdam, The Netherlands tel: +31 20 6391131 fax: +31 20 6393289 email: http://www.terena.nl/jenc8 or JENC8 Local Organization c/o Concorde Services Ltd Unit 5, SECC Glasgow, G3 8YW, Scotland email: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ OTHER CONFERENCES 6th CEN/CENELEC/ETSI Conference 1996 ------------------------------------ 5-6 November Sheraton Brussels Hotel, Brussels, Belgium Theme of this conference is "Standards on Trial: Case Studies in European Standardization" Deadline for abstracts is 13 Sept. For further information: c/o CENELAC, Tel: +32 2 519 6871 Fax: +32 2 519 6919 IMR Editor [Page 31] Internet Monthly Report October 1996 IDATE96 18th International Conference of IDATE -------------------------------------- 6-8 November Montpellier, France An opportunity for professional contacts with major industrial group leaders, users and clients, researchers and academics, administrators and politians. Full details of the conference available on the Web: http://www.idate.fr CEN/TC304 - Character Set Technology Workshop --------------------------------------------- 11-12 November Bled, Slovenia Providing multilingual support in middleware: Implementing the Universal Character Set ISO 10646 in the European Information Society For information look up URL: http://www.e5.ijs.si/i18n/ws-bled.html "The Telematics Revolution, Consequences for Individuals and Organisations" -------------------------------------------- 13 November University of Technology, Eindhoven, the Netherlands Theme of the conference is that progress of information and telecommunication technologies do create a huge number of questions, be it social, jurisdictional, economic or technical. Parallel sessions will deal with: interactive scientific visualisation, tele-learning, user aspects of multimedia, distant consultation and using of laboratories. For all information and to receive brochure, contact Mr. Marc Fleskens at email address IEEE Global Internet 1996 ------------------------- 20-21 November Queen Elizabeth II Conference Centre, London This mini-conference will provide an open forum for the communications and computer networking communities to review the state-of-the-art technologies and applications of the evolving Global Internet. Deadline paper submissions 15 May to: http://gaia.cs.umass.edu:80/tccc/internet96/ or email Jon Crowcroft IMR Editor [Page 32] Internet Monthly Report October 1996 WEB INTERNATIONALIZATION & MULTILINGUISM SYMPOSIUM -------------------------------------------------- 20-22 November Sevilla, Spain Organized by Sadiel and the WWW Consortium, with the support of the European Commission. The object of this symposium is the advancement of the internationalization and multilingualism of the Web, as well as to seek agreement on the relevant standards. Registration from 15 September. For further information see: http://www.w3.org/pub/WWW/International/Sevilla-96 EITC'96 - European IT Conference ------------------------------------------ 25-27 November Congress Centre, Brussels, Belgium "Doing Business in the Information Society" Electronic commerce, provides the focus for sessions on IT applications, enabling technologies and international initiatives. For further information contact European Commission, DGIII or look up WWW: http://www.cordis.lu/esprit/src/eitc96.htm EITC'96 - Post-Conference workshops ------------------------------------- 28 November Congress Centre, Brussels, Belgium "Promoting Networking Best Practice in Industry" Registration Forms on WWW: http://www.cordis.lu/esprit/src/wrkfrm96.htm (to be filled in and returned by 8 November) For further information contact Franck Boissiere of the European Commission DGIII F5 at email ASIAN'96 - Asian Computing Science Conference --------------------------------------------- 2-5 December Singapore Themes of this conference is: - Programming (sematics, languages, systems, ...) - Concurrency & Parallelism (algorithms, formalisms, systems ...) - Networking & Security (algorithms, protocols, formalisms, ...) Additional information available from: http://www.escs.nus.sg/~asian96 IMR Editor [Page 33] Internet Monthly Report October 1996 COREC - "Interregional Cooperation in RTD - Challenges and Opportunities for Regions in Economic Conversion" ----------------------------------------------------------- 16-17 December Bremen, Germany This conference is about "Interregional Cooperation in Research and Technological Development and its Impact on Regional Economies". Background is the experience of the community initiative STRIDE and other programmes of the European Commission. Agenda is available on the Internet under: http://www.bremen.de Any further information may be obtained from: Mr. Wolfgang Petzold Senator fur Wirtschaft, Mittelstand, Technologie und Europeangelegenheiten Multimedia Computing and Networking 1997 ---------------------------------------- 10-12 February 1997 San Jose, CA, USA The object of this conference is to bring together researchers, developers, and practitioners working in all facets of multimedia computing and networking. Paper submission by 16 July 1996. For further information email IEEE INFOCOM '97 16th Annual Joint Conference of the IEEE Computer & Communications Societies --------------------------------------------------- 7-11 April 1997 Kobe, Japan Paper submissions by 14 June 1997. For further information contact http://www.ics.uci.edu/~infocom/ http:// arpeggio.ics.es.osaka-u.ac.jp/infocom.html IMR Editor [Page 34] Internet Monthly Report October 1996 ISADS 97 3rd International Symposium on Autonomous Decentralized Systems --------------------------------------------------------------- 9-11 April 1997 Berlin, Germany Supported by Hitachi, DeTeBerkom, NEC, Digital, GMD-FOCUS, Hewlett Packard, IBM. The focus will be on advancements and innovations in ADS platforms and applications. Integration of telecommunication and computing aspects into a uniform concept for providing an open distributed processing environment. For information see WWW: http://www.fokus.gmd.de/ws/isads97/ IS&N '97 4th International Conference on Intelligence in Services & Networks ------------------------------------------------------------------- 27-29 May 1997 Como, Italy Title: "Technology for Co-operative Competition". The conference will provide a forum for the discussion of issues and the exchange of outstanding technical results related to the engineering of advanced communication services and experiments on their use. Sponsored by the European Commission and Italtel, and supported by ACTS projects in IS&N domain. Further information is available on WWW: http://www.uni-stuttgart.de/SONAH/Acts/domain5 EEMA'97 10th Annual Conference of European Electronic Messaging Association ------------------------------------------------------------------- 16-18 June 1997 Maastricht Exhibition and Congress Centre, Maastricht, Netherlands Issues of the conference will be: Global Security; Corporate Directories; Messaging Products & Services; Electronic Commerce; Global Messaging Enterprise; European Initiatives; Mobile Messaging Technology; Messaging Technology & Management Strategy; Intranet; World Wide Web & Infobots. For information contact WWW: http://www.eema.org/ IMR Editor [Page 35] Internet Monthly Report October 1996 INET'97 ------- 24-27 June 1997 Kuala Lumpur, Malaysia The conference will address the traditional and evolving frontiers of the Internet as well as its significant impact on education, commerce and societies throughout the world. Abstracts of papers to be submitted by 10 October. - for details of submission procedure email - for program information email - for general information email +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IMR Editor [Page 36]   Received: from ietf.org by ietf.org id aa18615; 18 Nov 96 13:14 EST Received: from zephyr.isi.edu by ietf.org id aa17677; 18 Nov 96 13:01 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 18 Nov 1996 10:00:06 -0800 Message-Id: <199611181800.AA03220@zephyr.isi.edu> To: IETF-Announce: ; To: Internet-Monthly-Report-People: ; Subject: Internet Monthly Report for October, 1996 Cc: imr-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Date: Mon, 18 Nov 96 10:00:03 PST Sender:ietf-announce-request@ietf.org From: IMR Editor --NextPart The Internet Monthly Report for October, 1996 is now available at the following location: URL= ftp://ftp.isi.edu/in-notes/imr/imr9610.txt The Internet Monthly Report (IMR) is normally distributed via EMail to the IMR list and the IETF list. For most readers this is the most convenient way to receive the report. However, there are some mail systems or mail gateways that do not accommodate large messages (some issues of the IMR are more than 100,000 characters). Readers that do not receive the IMR via the normal distribution may obtain copies via FTP or EMail retrieval. Requests to be added or deleted from the IMR report list: The Internet Monthly Report list is managed by MajorDomo atISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be added or deleted from the Internet Monthly report list should be sent to majordomo@isi.edu with the message body either subscribe imr or unsubscribe imr. Requests to be added or deleted from the IETF list should be sent to ietf-request@ietf.org. Internet Monthly Report availability via WWW, FTP and EMAIL: IMR Retrieval using WWW ----------------------- The URL below may be used in web browsers to access the IMRs. You will see a list of names in the form IMR9610.TXT. For example, IMR9610.TXT is the report for October 1996. URL: ftp://ftp.isi.edu/in-notes/imr IMR Retrieval using EMAIL via the RFC-INFO Service -------------------------------------------------- The EMail retrieval system RFC-Info will send a large report in segments in separate EMail messages not exceeding 50,000 characters each. Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_imrs. For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs IMR Retrieval using FTP ----------------------- IMRs are available via anonymous FTP from FTP.ISI.EDU, with the pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of the IMR. For example IMR9610.TXT is the report for October 1996). Login with FTP username anonymous and password ftp. IMR retrieval using MIME ------------------------ Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retreive the current IMR. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="rfc-info@isi.edu" Content-Type: text/plain Retrieve: imr Doc-ID: imr9610 --OtherAccess Content-Type: Message/External-body; name="imr9610.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes/imr" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa18211; 19 Nov 96 10:16 EST Received: from ietf.org by ietf.org id aa15479; 19 Nov 96 10:00 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-parnes-rtp-ext-srm-00.txt Date: Tue, 19 Nov 1996 10:00:21 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191000.aa15479@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP extension for Scalable Reliable Multicast Author(s) : P. Parnes Filename : draft-parnes-rtp-ext-srm-00.txt Pages : 15 Date : 11/18/1996 This document describes how the Real-time Transport Protocol, RTP (RFC1189), could be extended to include support for parts of the framework called Scalable Reliable Multicast. The scheme proposed could be used for transporting a data flow reliably over the transport protocols supported by RTP in a light-weight way. This could be used for numerous applications, for instance white-boards, semi-reliable audio/video and messaging/data-transfers within group-ware applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-parnes-rtp-ext-srm-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-parnes-rtp-ext-srm-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-parnes-rtp-ext-srm-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118112345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-parnes-rtp-ext-srm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-parnes-rtp-ext-srm-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118112345.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23805; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15531; 19 Nov 96 10:00 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: poised@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-poisson-ietfdoc-00.txt Date: Tue, 19 Nov 1996 10:00:45 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191000.aa15531@ietf.org> --NextPart Note: This announcement is being re-sent with a new filename. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Process for Organization of Internet StandardS ONg Working Group of the IETF. Title : A New IETF Document Classification Author(s) : M. O'Dell Filename : draft-ietf-poisson-ietfdoc-00.txt Pages : 7 Date : 11/18/1996 The Simple Record Framing Protocol (SRFP) is designed to provide a common, light-weight protocol for sending record-structured data of possibly indeterminate size over a reliable (TCP) connection. It is designed to be a "nickel's worth of presentation layer" which can be incorporated into a simple library to prevent reinvention of wheels. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-poisson-ietfdoc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-poisson-ietfdoc-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-poisson-ietfdoc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118114836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-poisson-ietfdoc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-poisson-ietfdoc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118114836.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23808; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15417; 19 Nov 96 9:59 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ballou-nntpsrch-00.txt Date: Tue, 19 Nov 1996 09:59:38 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611190959.aa15417@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NNTP Full-text Search Enhancements Author(s) : N. Ballou Filename : draft-ballou-nntpsrch-00.txt Pages : 8 Date : 11/18/1996 This document describes a set of enhancements to the Network News Transport Protocol [NNTP-977] that allows full-text searching of news articles in multiple newsgroups. The proposed SEARCH command supports functionality similar to the [IMAP4] SEARCH command, minus user specific search keys (i.e., ANSWERED, DRAFT, FLAGGED, KEYWORD, NEW, OLD, RECENT, SEEN) and minus search keys based on headers that do not exist in news (i.e., CC, BCC, TO). The availability of the extensions described here will be advertised by the server using the extension negotiation-mechanism described in the new NNTP protocol specification currently being developed [NNTP-NEW]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ballou-nntpsrch-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ballou-nntpsrch-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ballou-nntpsrch-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118110352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ballou-nntpsrch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ballou-nntpsrch-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118110352.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23828; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15568; 19 Nov 96 10:01 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ipsec-ipsec-doi-00.txt Date: Tue, 19 Nov 1996 10:01:09 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191001.aa15568@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ipsec-ipsec-doi-00.txt Pages : 15 Date : 11/18/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipsec-ipsec-doi-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ipsec-ipsec-doi-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118135339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipsec-ipsec-doi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipsec-ipsec-doi-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118135339.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23817; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15493; 19 Nov 96 10:00 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-palme-MHRegistry-00.txt Date: Tue, 19 Nov 1996 10:00:28 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191000.aa15493@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mail Header Registration Procedure Author(s) : J. Palme Filename : draft-palme-MHRegistry-00.txt Pages : 15 Date : 11/18/1996 Various IETF standards and e-mail software products use various e-mail header fields. This memo specifies a procedure for the registration of e-mail header field names, to reduce the risk that two different mail products use the same header name in different ways. A proposed initial content of the header name registry at start-up is specifed in an appendix to this ietf-draft. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-palme-MHRegistry-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-palme-MHRegistry-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-palme-MHRegistry-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118113447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-palme-MHRegistry-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-palme-MHRegistry-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118113447.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23887; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15752; 19 Nov 96 10:04 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: stdguide@midnight.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-stdguide-ops-01.txt Date: Tue, 19 Nov 1996 10:02:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191004.aa15752@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Guide for Internet Standards Writers Working Group of the IETF. Title : Guide for Internet Standards Writers Author(s) : G. Scott Filename : draft-ietf-stdguide-ops-01.txt Pages : 14 Date : 11/18/1996 This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. Also, it singles out usage believed to have led to unclear specifications, resulting in non-interoperable interpretations in the past. These guidelines are to be used with RFC 1543, "Instructions to RFC Authors." This version of the document is a draft. It is intended to generate further discussion and addition by the STDGUIDE working group. Please send comments to stdguide@midnight.com. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-stdguide-ops-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-stdguide-ops-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-stdguide-ops-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118151920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-stdguide-ops-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-stdguide-ops-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118151920.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23858; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15400; 19 Nov 96 9:59 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-woundy-aris-ipswitching-00.txt Date: Tue, 19 Nov 1996 09:59:33 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611190959.aa15400@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ARIS: Aggregate Route-Based IP Switching Author(s) : R. Woundy, A. Viswanathan, N. Feldman, R. Boivie Filename : draft-woundy-aris-ipswitching-00.txt Pages : 17 Date : 11/18/1996 IP based networks use a number of routing protocols, including RIP, OSPF, IS-IS, and BGP, to determine how packets ought to be routed. Among these protocols, OSPF and BGP are IETF-recommended standards that have been extensively deployed and exercised in many networks. In this memo, we describe a mechanism which uses these protocols as the basis for switching IP datagrams, by the addition of a simple protocol ("ARIS") that establishes switched paths through a network. The ARIS protocol allows us to leverage the advantages of switching technologies in an internet network. This memo is defined with respect to ATM. ARIS can be easily extended to other switching technologies. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-woundy-aris-ipswitching-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-woundy-aris-ipswitching-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-woundy-aris-ipswitching-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118104550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-woundy-aris-ipswitching-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-woundy-aris-ipswitching-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118104550.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23849; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15757; 19 Nov 96 10:04 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: idmr@cs.ucl.ac.uk Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-pim-sm-spec-09.txt Date: Tue, 19 Nov 1996 10:02:58 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191004.aa15757@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification Author(s) : D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei Filename : draft-ietf-idmr-pim-sm-spec-09.txt Pages : 77 Date : 11/18/1996 This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. We refer to the approach as Protocol Independent Multicast--Sparse Mode (PIM-SM) because it is not dependent on any particular unicast routing protocol, and because it is designed to support sparse groups as defined in [1][2]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-pim-sm-spec-09.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-pim-sm-spec-09.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idmr-pim-sm-spec-09.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118165117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-pim-sm-spec-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-pim-sm-spec-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118165117.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23927; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15462; 19 Nov 96 10:00 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myers-auth-sasl-06.txt Date: Tue, 19 Nov 1996 10:00:07 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191000.aa15462@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Authentication and Security Layer Author(s) : J. Myers Filename : draft-myers-auth-sasl-06.txt Pages : 13 Date : 11/18/1996 This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-myers-auth-sasl-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-06.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myers-auth-sasl-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118111104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-auth-sasl-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-auth-sasl-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118111104.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23937; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15691; 19 Nov 96 10:03 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-armitage-ion-tn-01.txt Date: Tue, 19 Nov 1996 10:03:14 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191003.aa15691@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transient Neighbors for IPv6 over ATM Author(s) : G. Armitage, P. Schulter, M. Jork, G. Harter Filename : draft-armitage-ion-tn-01.txt Pages : 30 Date : 11/18/1996 This document is a synthesis of two models for IPv6 over ATM that were presented to the ION working group in June 1996. The model attempts to allow conventional host-side operation of the Neighbor Discovery protocol, while also supporting the establishment of 'cut through' ATM routes. This is achieved through the use of Redirects to create Transient Neighbors, standard IPv6 protocol operation within the IPv6 Logical Link, and partial NHRP for location of off-Link destinations. The egress router detects flows that are suitable candidates for cut-through, uses NHRP to locate a better link level first hop, and then issues a Redirect message to the source. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-armitage-ion-tn-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-armitage-ion-tn-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-armitage-ion-tn-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118170131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-armitage-ion-tn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-armitage-ion-tn-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118170131.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23893; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15628; 19 Nov 96 10:01 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myers-sasl-pop3-00.txt Date: Tue, 19 Nov 1996 10:01:58 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191001.aa15628@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : POP3 AUTHentication command Author(s) : J. Myers Filename : draft-myers-sasl-pop3-00.txt Pages : 6 Date : 11/18/1996 This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Session Layer [SASL]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-myers-sasl-pop3-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-sasl-pop3-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myers-sasl-pop3-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118145257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-sasl-pop3-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-sasl-pop3-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118145257.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23818; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15755; 19 Nov 96 10:04 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ids-discovery-03.txt Date: Tue, 19 Nov 1996 10:03:29 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191004.aa15755@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Directory Services Working Group of the IETF. Title : Finding Stuff (Providing information to support service discovery) Author(s) : R. Moats, M. Hamilton Filename : draft-ietf-ids-discovery-03.txt Pages : 11 Date : 11/18/1996 This document proposes a solution to the problem of finding information about which services are being offered at a particular Internet domain, based on deployment experience with the Netfind White Pages directory software. This approach makes it possible to supply clients with more information than the DNS aliases which have been widely deployed in this role - notably the port numbers being used by servers. However, it is not without problems, and we have tried to take account of these. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ids-discovery-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ids-discovery-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ids-discovery-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118171114.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ids-discovery-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ids-discovery-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118171114.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23925; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15434; 19 Nov 96 9:59 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myers-smtp-auth-04.txt Date: Tue, 19 Nov 1996 09:59:56 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611190959.aa15434@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : SMTP Service Extension for Authentication Author(s) : J. Myers Filename : draft-myers-smtp-auth-04.txt Pages : 7 Date : 11/18/1996 This document defines an extension to the SMTP service whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Security Layer [SASL]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-myers-smtp-auth-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-smtp-auth-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myers-smtp-auth-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118110730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-smtp-auth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-smtp-auth-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118110730.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23932; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15589; 19 Nov 96 10:01 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-01.txt Date: Tue, 19 Nov 1996 10:01:15 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191001.aa15589@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The resolution of ISAKMP with Oakley Author(s) : D. Harkins, D. Carrel Filename : draft-ietf-ipsec-isakmp-oakley-01.txt Pages : 27 Date : 10/18/1996 [MSST96] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). This document describes a proposal for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-oakley-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118135721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118135721.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23979; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15756; 19 Nov 96 10:04 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: idmr@cs.ucl.ac.uk Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-pim-arch-04.txt Date: Tue, 19 Nov 1996 10:03:06 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191004.aa15756@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : Protocol Independent Multicast-Sparse Mode (PIM-SM): Motivation and Architecture Author(s) : S. Deering, D. Estrin, D. Farinacci, M. Handley, A. Helmy, V. Jacobson, C. Liu, P. Sharma, D. Thaler, L. Wei Filename : draft-ietf-idmr-pim-arch-04.txt Pages : 24 Date : 11/18/1996 Traditional multicast routing mechanisms (e.g. DVMRP and MOSPF [1][2]) were intended for use within regions where groups are widely represented or bandwidth is universally plentiful. When group members, and senders to those group members, are distributed sparsely across a wide area, these schemes are not efficient; data packets or membership report information are periodically sent over many links that do not lead to receivers or senders, respectively. This characteristic lead the Internet community to investigate multicast routing architectures that efficiently establish distribution trees across wide-area internets, where many groups are sparsely represented and where bandwidth is not uniformly plentiful due to the distances and multiple administrations traversed. Efficiency is evaluated in terms of the state, control message processing, and data packet processing required across the entire network in order to deliver data packets to the members of the group. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-pim-arch-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-pim-arch-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idmr-pim-arch-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118165648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-pim-arch-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-pim-arch-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118165648.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23919; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15754; 19 Nov 96 10:04 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-inarp-update-00.txt Date: Tue, 19 Nov 1996 10:02:45 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191004.aa15754@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : Inverse Address Resolution Protocol Author(s) : T. Bradley, C. Brown, A. Malis Filename : draft-ietf-ion-inarp-update-00.txt Pages : 7 Date : 11/18/1996 This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. Specifically, this applies to Frame Relay stations that may have a Data Link Connection Identifier (DLCI), the Frame Relay equivalent of a hardware address, associated with an established Permanent Virtual Circuit (PVC), but do not know the protocol address of the station on the other side of this connection. It will also apply to other networks with similar circumstances. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-inarp-update-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-inarp-update-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-inarp-update-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118154840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-inarp-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-inarp-update-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118154840.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23955; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15709; 19 Nov 96 10:03 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-freier-ssl-version3-02.txt Date: Tue, 19 Nov 1996 10:03:20 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191003.aa15709@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The SSL Protocol Version 3.0 Author(s) : A. Freier, P. Karlton, P. Kocher Filename : draft-freier-ssl-version3-02.txt Pages : 63 Date : 11/18/1996 This document specifies Version 3.0 of the Secure Sockets Layer (SSL V3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-freier-ssl-version3-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-freier-ssl-version3-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-freier-ssl-version3-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118170625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-freier-ssl-version3-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-freier-ssl-version3-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118170625.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23971; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15734; 19 Nov 96 10:03 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-syntax-01.txt Date: Tue, 19 Nov 1996 10:03:40 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191003.aa15734@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URN Syntax Author(s) : R. Moats Filename : draft-ietf-urn-syntax-01.txt Pages : 6 Date : 11/18/1996 Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-syntax-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-syntax-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118171343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-syntax-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-syntax-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118171343.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa27555; 19 Nov 96 16:41 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20433; 19 Nov 96 16:41 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Tue, 19 Nov 1996 19:58:14 GMT Received: from mail11.digital.com by MIT.EDU with SMTP id AA26673; Tue, 19 Nov 96 14:58:11 EST Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA21941; Tue, 19 Nov 1996 14:46:31 -0500 (EST) Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA09574; Tue, 19 Nov 96 14:48:31 -0500 Message-Id: <9611191948.AA09574@us1rmc.bb.dec.com> Received: from tuxedo.enet; by us1rmc.enet; Tue, 19 Nov 96 14:48:31 EST Date: Tue, 19 Nov 96 14:48:31 EST From: "John Wray, Digital DPE, (508) 486-5210 19-Nov-1996 1420" To: linn@cam.ov.com Cc: "cat-ietf@mit.edu"@in.enet.dec.com, wray@tuxedo.enet.dec.com Apparently-To: cat-ietf@mit.edu, linn@cam.ov.com Subject: RE: Ongoing document status; C bindings issues Here's an update of what I've done to the C bindings so far. The cutoff date for Internet Draft submission is one week from today, so if there are any other items, or if there's disagreement about the changes I've made, there's still a few days left to fix things. From John's original list of topics: >(1) Ted Ts'o, 6 August: requested tightened description about behavior >of GSS_C_NULL_OID with gss_import_name(). Not sure what to do about this. The request was for: "some tightening up of the language of what GSS_C_NULL_OID beyond "local system-specific printable syntax". I think it should be clear that this is the local system-specific syntax for naming _users_, since we already have GSS_C_NT_HOSTBASED_SERVICE for naming services, per the latest gssv2 draft". I'm not sure I agree with this. For one thing, GSSAPI doesn't intrinsically distinguish between users and services. There's no reason to use a different syntax for users and services (e.g. "/c=US/o=DEC/ou=DPE/cn=John Wray" might identify me while "/c=US/o=DEC/ou=DPE/cn=John Wray's Printer" might identify my print server). The purpose of allowing the app to specify GSS_C_NULL_OID here was to allow GSSAPI implementations to be smart, and be able to relieve the app from having to make the determination of name type, which aids in app portability across mechanisms. Of course, if the app can work out the type of name it's dealing with, then it should certainly use an explicit name-type. >(2) John Wray, 7 August: planned changes relative to >draft-ietf-cat-gssv2-cbind-02.txt re gss_inquire_mechs_for_name() and >nametype OIDs. Those changes are there now. >(3) Martin Rex, 20 August: treatment of OID management routines and >memory allocation issues. (Extended follow-up, including suggestions >to eliminate certain calls. See also commentary in my 13 September >message.) Haven't done anything here, although I'm inclined to agree that the simplest thing to do is to remove dynamic OIDs and gss_release_oid() altogether (along with the str<->oid conversion routines that require them). >(4) Martin Rex, 20 August: behavior re empty strings, empty OIDs. Explanatory text added, saying that, when presented with an invalid OID encoding (which includes NULL pointers and zero-length data), the resulting buffer will contain a zero length field, and the routine will return GSS_S_FAILURE. >(5) Martin Rex, 23 August: gss_acquire_cred behavior per C bindings >draft. Added text explicitly allowing the use of NULL for desired_name as a way of requesting a credential that will invoke default behavior. >(6) Marc Horowitz, 28 August: clarification re empty tokens and on the >circumstances under which tokens may be returned. (See also >commentary in my 13 September message.) C-binding already equates a zero-length token with "no token". I believe this is an issue for the high-level spec. >(7) Marc Horowitz, 28 August: modifiability of default credential. >(See also commentary in my 13 September message.) Added wording based on John Linn's proposal. >(8) Marc Horowitz, 28 August: requested clarifications re which >GSS-returned objects must be released by a caller, and under what >circumstances. I've added text to make explicit the current intent of the document. Resolution of point (3) above may require this text to change. >(9) Marc Horowitz, 28 August: request for facility which, after >context establishment, obtains any incoming delegated credential. I'd like to see this routine too, although I'm not sure how it should interact with passing contexts between processes (via gss_export_sec_context). I can imagine situations where I'd like to pass on the ability to communicate securely with a peer, but not pass on the right to act as a delegate of that peer. I think that some implementations may also have problems passing delegated credentials between processes. Maybe gss_export_sec_context should take an additional input parameter that says whether any delegated credential contained within the context should be transferred. >(10) Marc Horowitz, 28 August: request explicit statement that >"release" routines can be omitted in environments where they are not >required. I think this was aimed at the high-level spec only. The C-bindings assumes that data has to be released explicitly. >(11) Marc Horowitz, 28 August: request constraints on GSS_S_BAD_NAMETYPE >returns from gss_display_name(), gss_compare_name(). Done. >(12) Dennis Glatting, 29 August: suggested use of "const". I've done this. Instead of using the "const" keyword, I've used a macro GSS_CONST, which the GSSAPI header file conditionally equates to either const or a null token (the default being to equate it to "const"). That may make life a bit easier for GSS V1 implementations converting to V2. In doing this, I noticed a minor problem with gss_process_context(). If we ever decide to use this function for anything, it might be better to have it take a (gss_ctx_id_t *) rather than a (gss_ctx_id_t) - that way it would be able to indicate whether the context is still valid after the call has completed (by setting the ctx_id_t to null if the context has gone away). >(13) Martin Rex, 18 September: proposed changes re >gss_release_buffer(). (One element accepted by John Wray, another >disputed.) I've added the clarifying text to gss_release_buffer (actually, deleted the erroneous reference to names). (14) Martin Rex, 18 September: proposed changes re gss_release_cred(). (Extensive response from John Wray.) I believe that the high-level spec should be modified to remove the reference to deleting the default credential, >(15) Martin Rex, Ted Ts'o, 27 September: request deprecation of >CREDENTIALS_EXPIRED returns from context-level calls. Done. >(16) Martin Rex, Ted Ts'o, 1 October, thread about context expiration >policy. Fixed the typo about lifetime_rec and time_rec in gss_inquire_context() and gss_init_sec_context(). >(17) Martin Rex, 10 October: observation re newly-optional parameters >in GSS-V2 C bindings. (Ted Ts'o responded, considering the issue not >to be a concern.) I don't think this is a problem either. I've removed the cofnusing text about actual_mech_type never being NULL from the description of gss_init_sec_context(). >(18) Martin Rex, 18 October: need added text re shared library >conventions. Shared libraries aren't part of ANSI C, so at most is could go in an appendix. But I don't think there's really anything to say, at least nothing that's specific to GSSAPI.   Received: from cnri by ietf.org id aa09324; 19 Nov 96 21:22 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25375; 19 Nov 96 21:22 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 01:22:34 GMT Received: from rover.cygnus.com by MIT.EDU with SMTP id AA09884; Tue, 19 Nov 96 20:22:33 EST Received: (from marc@localhost) by rover.cygnus.com (8.7.6/8.6.12) id UAA13272; Tue, 19 Nov 1996 20:22:30 -0500 (EST) To: wray@tuxedo.enet.dec.com, linn@cam.ov.com, cat-ietf@mit.edu Subject: Re: Ongoing document status; C bindings issues References: <9611191948.AA09574@us1rmc.bb.dec.com> From: Marc Horowitz Date: 19 Nov 1996 20:22:29 -0500 In-Reply-To: "John Wray, Digital DPE,'s message of Tue, 19 Nov 96 14:48:31 EST Message-Id: Lines: 17 X-Mailer: Gnus v5.3/Emacs 19.34 "John Wray, Digital DPE, (508) 486-5210 19-Nov-1996 1420" writes: >> >(12) Dennis Glatting, 29 August: suggested use of "const". >> >> I've done this. Instead of using the "const" keyword, I've used a macro >> GSS_CONST, which the GSSAPI header file conditionally equates to either const >> or a null token (the default being to equate it to "const"). That may make >> life a bit easier for GSS V1 implementations converting to V2. What is it conditional on, and what is the default? If it defaults to evaluating to "const", then v1 apps will see type warnings anyway. If it doesn't, v1 apps will need to change their code to get rid of the warning; they might as well just upgrade the code to v2 if they're going to do anything. I'd rather just use const, and eliminate the ambiguity. Marc   Received: from cnri by ietf.org id aa12314; 19 Nov 96 22:58 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26498; 19 Nov 96 22:58 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 02:59:58 GMT Received: from btw.plaintalk.bellevue.wa.us by MIT.EDU with SMTP id AA10547; Tue, 19 Nov 96 21:59:56 EST Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.7.6/8.7.3/dpg hack 01aug96) with ESMTP id SAA01144; Tue, 19 Nov 1996 18:59:52 -0800 (PST) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id SAA19427; Tue, 19 Nov 1996 18:59:51 -0800 (PST) Message-Id: <199611200259.SAA19427@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Tue, 19 Nov 96 18:59:48 -0800 To: Marc Horowitz Subject: Re: Ongoing document status; C bindings issues Cc: wray@tuxedo.enet.dec.com, linn@cam.ov.com, cat-ietf@mit.edu Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <9611191948.AA09574@us1rmc.bb.dec.com> "John Wray, Digital DPE, (508) 486-5210 19-Nov-1996 1420" writes: > > >(12) Dennis Glatting, 29 August: suggested use of "const". > > > > I've done this. Instead of using the "const" keyword, I've used > > a macro GSS_CONST, which the GSSAPI header file conditionally > > equates to either const or a null token (the default being to > > equate it to "const"). That may make life a bit easier for GSS V1 > > implementations converting to V2. > > > > What is it conditional on, and what is the default? If it > defaults to evaluating to "const", then v1 apps will see type > warnings anyway. If it doesn't, v1 apps will need to change > their code to get rid of the warning; they might as well just > upgrade the code to v2 if they're going to do anything. I'd > rather just use const, and eliminate the ambiguity. > Using unconditionalized const is the same as specifying prototypes: you are assuming the developer is using a compiler that supports those features. There are plenty of Sun 4.x machines and old HPs still in use. -dpg   Received: from ietf.org by ietf.org id aa11052; 20 Nov 96 8:10 EST Received: from cnri by ietf.org id aa10886; 20 Nov 96 8:00 EST Received: from [128.19.0.20] by CNRI.Reston.VA.US id aa07621; 20 Nov 96 8:00 EST Received: (from martin@localhost) by spica.iern.disa.mil (8.6.10/8.6.10) id HAA13925; Wed, 20 Nov 1996 07:55:08 -0500 Date: Wed, 20 Nov 1996 07:55:08 -0500 Sender:ietf-request@ietf.org From: "Cynthia E. Martin" Message-Id: <199611201255.HAA13925@spica.iern.disa.mil> To: dunn@spica.iern.disa.mil, ietf@CNRI.Reston.VA.US, martin@spica.iern.disa.mil, scoya@CNRI.Reston.VA.US Subject: San Jose Information Source-Info: From (or Sender) name not authenticated. For all attending the IETF in San Jose, If you are registered at the Fairmont Hotel I suggest you call and reconfirm your room. I called and not only did they deny I had a confirmed room with a confirmation number, they didn't even have my name listed. BTW, they are booked and I had to find another hotel at this late date. - Cynthia :(   Received: from cnri by ietf.org id aa12229; 20 Nov 96 8:38 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08397; 20 Nov 96 8:38 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 12:19:54 GMT Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP id AA08034; Wed, 20 Nov 96 07:19:52 EST Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id NAA29607; Wed, 20 Nov 1996 13:18:08 +0100 Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA08394 (5.67b8/IDA-1.5); Wed, 20 Nov 1996 13:18:03 +0100 Message-Id: <199611201218.AA08394@sap-ag.de> Received: by hw1464.wdf.sap-ag.de (1.39.111.2/16.2) id AA256942278; Wed, 20 Nov 1996 07:17:58 -0500 From: Martin Rex Subject: Re: Ongoing document status; C bindings issues To: dennis.glatting@plaintalk.bellevue.wa.us Date: Wed, 20 Nov 1996 07:17:58 -0500 (EST) Cc: cat-ietf@mit.edu In-Reply-To: <199611200259.SAA19427@imo.plaintalk.bellevue.wa.us> from "Dennis Glatting" at Nov 19, 96 06:59:48 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Dennis Glatting wrote: > "John Wray" wrote: > > >(12) Dennis Glatting, 29 August: suggested use of "const". > > > > I've done this. Instead of using the "const" keyword, I've used > > a macro GSS_CONST, which the GSSAPI header file conditionally > > equates to either const or a null token (the default being to > > equate it to "const"). That may make life a bit easier for GSS V1 > > implementations converting to V2. > > Using unconditionalized const is the same as specifying > prototypes: you are assuming the developer is using a compiler > that supports those features. There are plenty of Sun 4.x > machines and old HPs still in use. The question acutally is: are we going to make C-Bindings or ANSI-C Bindings? -Martin   Received: from ietf.org by ietf.org id aa15451; 20 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa14213; 20 Nov 96 9:57 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-pf-key-v2-00.txt Date: Wed, 20 Nov 1996 09:57:41 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611200957.aa14213@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, C. Metz, B Phan Filename : draft-mcdonald-pf-key-v2-00.txt Pages : 43 Date : 11/19/1996 This memo documents a user-to-kernel interface for key management applications. It is derived from the 4.x BSD routing socket, and it operates in a very similar fasion. This document is informational, and not meant to specify a standard. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcdonald-pf-key-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mcdonald-pf-key-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119151230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119151230.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15449; 20 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa14159; 20 Nov 96 9:57 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-klensin-tld-whois-01.txt Date: Wed, 20 Nov 1996 09:57:09 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611200957.aa14159@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Names and Company Name Retrieval Author(s) : J. Klensin, T. Wolf Filename : draft-klensin-tld-whois-01.txt Pages : 6 Date : 11/19/1996 Location of web information for particular companies based on their names has become an increasingly difficult problem and the Internet and the web grow. The use of a naming convention and the domain name system (DNS) for that purpose has caused complications for the latter while not solving the problem. While there have been several proposals to use contemporary, high-capability, directory service and search protocols to reduce the dependencies on DNS conventions, none of them have been significantly deployed. This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether and extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-klensin-tld-whois-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-klensin-tld-whois-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-klensin-tld-whois-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119105842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-klensin-tld-whois-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-klensin-tld-whois-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119105842.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15462; 20 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa14194; 20 Nov 96 9:57 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-deri-http-mgmt-00.txt Date: Wed, 20 Nov 1996 09:57:27 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611200957.aa14194@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : HTTP-based SNMP and CMIP Network Management Author(s) : L. Deri Filename : draft-deri-http-mgmt-00.txt Pages : 6 Date : 11/19/1996 This document describes the application of the HyperText Transfer Protocol (HTTP) [HTTP] for the purpose of SNMP [SNMP] and CMIP [CMIP] management. It shows how SNMP and CMIP resources can be managed by using the standard HTTP protocol by defining a mapping between SNMP/CMIP protocols and HTTP. The mapping is very simple and based on strings which can easily be handled by any programming and scripting language. This will allow light and simple HTTP-based applications to be created, since they have not to include any management service like encoding/decoding nor to handle complex data types. This document does not cover management of HTTP [Hazewinkel]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-deri-http-mgmt-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-deri-http-mgmt-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-deri-http-mgmt-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119114538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-deri-http-mgmt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-deri-http-mgmt-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119114538.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15450; 20 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa14139; 20 Nov 96 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Date: Wed, 20 Nov 1996 09:56:50 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611200956.aa14139@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ipsec-ipsec-doi-01.txt Pages : 15 Date : 11/19/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipsec-ipsec-doi-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipsec-ipsec-doi-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15461; 20 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa14176; 20 Nov 96 9:57 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-carpenter-ipng-6over4-00.txt Date: Wed, 20 Nov 1996 09:57:17 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611200957.aa14176@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Packets over IPv4 Networks without Tunnels Author(s) : B. Carpenter, C. Jung Filename : draft-carpenter-ipng-6over4-00.txt Pages : 6 Date : 11/19/1996 This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 networks. It also specifies the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages, when those messages are transmitted on an IPv4 network. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 network as their virtual local link. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-carpenter-ipng-6over4-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-carpenter-ipng-6over4-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-carpenter-ipng-6over4-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119112612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-carpenter-ipng-6over4-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-carpenter-ipng-6over4-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119112612.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15446; 20 Nov 96 10:10 EST Received: from ietf.org by ietf.org id aa14232; 20 Nov 96 9:58 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-daviel-web-copy-control-00.txt Date: Wed, 20 Nov 1996 09:58:05 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611200958.aa14232@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Copy Control for Web Documents Author(s) : A. Daviel Filename : draft-daviel-web-copy-control-00.txt Pages : 2 Date : 11/19/1996 This memo describes a simple syntax for describing the copyright status of a World-Wide-Web document in a machine-readable way. When implemented in a Web browser it provides an unambiguous notification when permission must be sought to print or copy material obtained from the network. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-daviel-web-copy-control-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-daviel-web-copy-control-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-daviel-web-copy-control-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119155759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daviel-web-copy-control-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-daviel-web-copy-control-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119155759.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa16990; 20 Nov 96 10:31 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11502; 20 Nov 96 10:31 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 14:16:01 GMT Received: from mail11.digital.com by MIT.EDU with SMTP id AA23011; Wed, 20 Nov 96 09:15:59 EST Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA32200; Wed, 20 Nov 1996 09:07:55 -0500 (EST) Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA08949; Wed, 20 Nov 96 09:09:55 -0500 Message-Id: <9611201409.AA08949@us1rmc.bb.dec.com> Received: from tuxedo.enet; by us1rmc.enet; Wed, 20 Nov 96 09:09:55 EST Date: Wed, 20 Nov 96 09:09:55 EST From: "John Wray, Digital DPE, (508) 486-5210 20-Nov-1996 0904" To: dennis.glatting@plaintalk.bellevue.wa.us Cc: "cat-ietf@mit.edu"@in.enet.dec.com, wray@tuxedo.enet.dec.com Apparently-To: cat-ietf@mit.edu, dennis.glatting@plaintalk.bellevue.wa.us Subject: Re: Ongoing document status; C bindings issues Dennis Glatting writes: >> > >(12) Dennis Glatting, 29 August: suggested use of "const". >> > >> > I've done this. Instead of using the "const" keyword, I've used >> > a macro GSS_CONST, which the GSSAPI header file conditionally >> > equates to either const or a null token (the default being to >> > equate it to "const"). That may make life a bit easier for GSS V1 >> > implementations converting to V2. >> > >> >> What is it conditional on, and what is the default? If it >> defaults to evaluating to "const", then v1 apps will see type >> warnings anyway. If it doesn't, v1 apps will need to change >> their code to get rid of the warning; they might as well just >> upgrade the code to v2 if they're going to do anything. I'd >> rather just use const, and eliminate the ambiguity. >> > >Using unconditionalized const is the same as specifying >prototypes: you are assuming the developer is using a compiler >that supports those features. There are plenty of Sun 4.x >machines and old HPs still in use. That's a valid reason to keep the conditional use of const. Although the GSSAPI spec is supposed to be an ANSI-C spec, I have tried to avoid constructs that confuse some older non-ANSI compilers (like formal parameter names in prototypes). Maybe I should conditionalize the definition of GSS_CONST based on __STDC__, rather than on a GSSAPI-defined symbol? John   Received: from cnri by ietf.org id aa18110; 20 Nov 96 10:45 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11970; 20 Nov 96 10:45 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 14:16:03 GMT Received: from mail11.digital.com by MIT.EDU with SMTP id AA12463; Wed, 20 Nov 96 09:16:02 EST Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA32444; Wed, 20 Nov 1996 09:03:11 -0500 (EST) Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA08638; Wed, 20 Nov 96 09:05:11 -0500 Message-Id: <9611201405.AA08638@us1rmc.bb.dec.com> Received: from tuxedo.enet; by us1rmc.enet; Wed, 20 Nov 96 09:05:12 EST Date: Wed, 20 Nov 96 09:05:12 EST From: "John Wray, Digital DPE, (508) 486-5210 20-Nov-1996 0855" To: marc@cygnus.com Cc: "cat-ietf@mit.edu"@in.enet.dec.com, wray@tuxedo.enet.dec.com Apparently-To: cat-ietf@mit.edu, marc@cygnus.com Subject: Re: Ongoing document status; C bindings issues Marc writes: > >>> >(12) Dennis Glatting, 29 August: suggested use of "const". >>> >>> I've done this. Instead of using the "const" keyword, I've used a macro >>> GSS_CONST, which the GSSAPI header file conditionally equates to either const >>> or a null token (the default being to equate it to "const"). That may make >>> life a bit easier for GSS V1 implementations converting to V2. > >What is it conditional on, and what is the default? If it defaults to >evaluating to "const", then v1 apps will see type warnings anyway. If >it doesn't, v1 apps will need to change their code to get rid of the >warning; they might as well just upgrade the code to v2 if they're >going to do anything. I'd rather just use const, and eliminate the >ambiguity. It's conditional on seeing a symbol GSS_NO_CONSTANT (if this symbol isn't defined then GSS_CONST is defined as "const", otherwise GSS_CONST is defined as nothing). This wasn't so much to help apps, as the compiler shouldn't generate warnings if a caller passes a non-constant object to a routine that declares its parameters const (const before a formal parameter is merely a promise that the routine won't modify the parameter, not a requirement that the caller pass a constant object). It's intended to help V1 GSSAPI _implementations_ upgrade to V2 - if a GSSAPI routine assigns a const parameter to a non-const local, the compiler will generate a warning (or maybe an error), and some existing implementations may do this. Having the "const" keyword be optional allows the GSSAPI implementation to remove it during compilation of GSSAPI itself, but retain it for application compilation. However, this is just a hack, and as such it probably doesn't belong in the C-bindings document. I'll remove it unless anyone feels it's worth keeping. John   Received: from ietf.org by ietf.org id aa05328; 20 Nov 96 16:39 EST Received: from ietf.org by ietf.org id aa04589; 20 Nov 96 16:20 EST To: IETF-Announce: ; cc: idmr@cs.ucl.ac.uk Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: Internet Group Management Protocol, Version 2 to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 20 Nov 1996 16:20:41 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611201620.aa04589@ietf.org> The IESG has received a request from the Inter-Domain Multicast Routing Working Group to consider "Internet Group Management Protocol, Version 2" for the status of Proposed Standard. 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 December 11, 1996 Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from cnri by ietf.org id aa07117; 20 Nov 96 17:21 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25078; 20 Nov 96 17:21 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 21:14:33 GMT Received: from cygnus.com by MIT.EDU with SMTP id AA06852; Wed, 20 Nov 96 16:14:25 EST Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.6.12/8.6.9) with SMTP id NAA18298; Wed, 20 Nov 1996 13:14:02 -0800 Received: from maneki-neko.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA17628; Wed, 20 Nov 96 16:13:29 EST Received: (from eichin@localhost) by maneki-neko.cygnus.com (8.7.6/8.7.3) id QAA01018; Wed, 20 Nov 1996 16:13:29 -0500 Sender: eichin@cygnus.com To: dennis.glatting@plaintalk.bellevue.wa.us Cc: Marc Horowitz , wray@tuxedo.enet.dec.com, linn@cam.ov.com, cat-ietf@mit.edu Subject: Re: Ongoing document status; C bindings issues References: <9611191948.AA09574@us1rmc.bb.dec.com> <199611200259.SAA19427@imo.plaintalk.bellevue.wa.us> From: Mark Eichin Date: 20 Nov 1996 16:13:27 -0500 In-Reply-To: Dennis Glatting's message of Tue, 19 Nov 96 18:59:48 -0800 Message-Id: Lines: 9 X-Mailer: Gnus v5.2.39/Emacs 19.34 > Using unconditionalized const is the same as specifying > prototypes: you are assuming the developer is using a compiler > that supports those features. ... Well, no. You're just assuming that the developer is using a compiler that supports the "-Dconst=" compatibility flag :-) Prototypes have a bunch of interesting semantic implications, as well as additional syntax; command-line tweaking -Dconst= doesn't...   Received: from cnri by ietf.org id aa08293; 20 Nov 96 18:06 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26088; 20 Nov 96 18:06 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 21:31:12 GMT Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP id AA29666; Wed, 20 Nov 96 16:31:08 EST Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id WAA18823 for ; Wed, 20 Nov 1996 22:30:11 +0100 Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA11821 (5.67b8/IDA-1.5 for ); Wed, 20 Nov 1996 22:30:07 +0100 Message-Id: <199611202130.AA11821@sap-ag.de> Received: by hw1464.wdf.sap-ag.de (1.39.111.2/16.2) id AA270605399; Wed, 20 Nov 1996 16:29:59 -0500 From: Martin Rex Subject: description of gss_duplicate_name To: cat-ietf@mit.edu Date: Wed, 20 Nov 1996 16:29:59 -0500 (EST) Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit The current description of gss_duplicate_name in the C-Bindings could grow some more text. We could reuse the description from the high-level specs, but I would prefer some small changes: current description from high-level (gssv2-08): 2.4.19: GSS_Duplicate_name call This routine takes input internal name src_name, and returns another reference (dest_name) to that name which can be used even if src_name is later freed. (Note: This may be implemented by copying or through use of reference counts.) My suggestion (for at least the C-Bindings): This routine creates an exact duplicate of the existing internal name src_name and returns it. The new internal name dest_name will be independent of src_name, i.e. dest_name will have to be released seperately; its validity will not be affected by the release of src_name. (It is a local matter if a gssapi mechanism implements this by refcounting or true copying). (high-level uses "freed" instead of "released" -- I seem to have missed this one when I was chasing "free()", sorry.) While writing this I was looking up the description of gss_canonicalize_name(). I was wondering if there was any gssapi call able to "modify" an internal name, which would create gotchas for refcount implementations. Well, gss_canonicalize_name takes a src_name and returns a dest_name, very similar to gss_duplicate_name. Acutally I would expect canonicalize_name to work EXACTLY like duplicate_name for MNs. I feel this is not sufficiently clear from the explanation in the high-level spec. current description from high-level (gssv2-08): 2.4.17: GSS_Canonicalize_name call This routine reduces a GSS-API internal name, which may in general contain elements corresponding to multiple mechanisms, to a mechanism-specific Mechanism Name (MN) by applying the translations corresponding to the mechanism identified by mech_type. current description from C-bindings (gssv2-cbind-02): 7.5. gss_canonicalize_name Generate a canonical mechanism name (MN) from an arbitary internal name. A mechanism name is the name that would be returned to a context acceptor on succesful authentication of a context where the initiator used the input_name in a sucesful call to gss_acquire_cred, specifying an OID set containing as its only member, followed by a call to gss_init_sec_context, specifying as the authentication mechanism. The wording in the high level specs sounds slightly like it would be *modifying* src_name. It should be *duplicating* src_name into dest_name and modify dest_name (or create a modified dest_name from src_name), and it should be mentioned (like in duplicate_name), that dest_name will exist indepently of src_name. I really appreciate the information in the current explanation in the C-bindings, but (I'm nitpicking, please forgive me) a mechanism name will also be returned when the initiator doesn't call gss_acquire_cred and passes GSS_C_NO_CREDENTIAL to gss_init_sec_context. -Martin   Received: from cnri by ietf.org id aa08456; 20 Nov 96 18:17 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26345; 20 Nov 96 18:17 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 22:15:27 GMT Received: from rover.cygnus.com by MIT.EDU with SMTP id AA11204; Wed, 20 Nov 96 17:15:19 EST Received: (from marc@localhost) by rover.cygnus.com (8.7.6/8.6.12) id RAA17167; Wed, 20 Nov 1996 17:15:12 -0500 (EST) To: wray@tuxedo.enet.dec.com, cat-ietf@mit.edu Subject: Re: Ongoing document status; C bindings issues References: <9611201409.AA08949@us1rmc.bb.dec.com> From: Marc Horowitz Date: 20 Nov 1996 17:15:12 -0500 In-Reply-To: "John Wray, Digital DPE,'s message of Wed, 20 Nov 96 09:09:55 EST Message-Id: Lines: 14 X-Mailer: Gnus v5.3/Emacs 19.34 "John Wray, Digital DPE, (508) 486-5210 20-Nov-1996 0904" writes: >> That's a valid reason to keep the conditional use of const. >> Although the GSSAPI spec is supposed to be an ANSI-C spec, I have >> tried to avoid constructs that confuse some older non-ANSI >> compilers (like formal parameter names in prototypes). Maybe I >> should conditionalize the definition of GSS_CONST based on >> __STDC__, rather than on a GSSAPI-defined symbol? As you pointed out, this is a hack, and as such does not belong in the *standard*. Nothing is stopping you from making your implementation a little different. Marc   Received: from cnri by ietf.org id aa08473; 20 Nov 96 18:19 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26384; 20 Nov 96 18:19 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 22:03:37 GMT Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP id AA08318; Wed, 20 Nov 96 17:03:23 EST Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id XAA19613 for ; Wed, 20 Nov 1996 23:02:22 +0100 Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA13208 (5.67b8/IDA-1.5 for ); Wed, 20 Nov 1996 23:02:17 +0100 Message-Id: <199611202202.AA13208@sap-ag.de> Received: by hw1464.wdf.sap-ag.de (1.39.111.2/16.2) id AA271317330; Wed, 20 Nov 1996 17:02:10 -0500 From: Martin Rex Subject: duplicate_name: BAD_NAME_TYPE ? To: cat-ietf@mit.edu Date: Wed, 20 Nov 1996 17:02:10 -0500 (EST) Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I think gss_duplicate_name() should not be allowed to return GSS_S_BAD_NAMETYPE. An invalid internal name (i.e. a gss_name_t that doesn't map to a valid internal name) should be answered with GSS_S_BAD_NAME. -Martin PS: sorry for the seperate message   Received: from cnri by ietf.org id aa09056; 20 Nov 96 18:46 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26845; 20 Nov 96 18:46 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 22:48:30 GMT Received: from kerby.cybersafe.com by MIT.EDU with SMTP id AA19795; Wed, 20 Nov 96 17:48:28 EST Received: from CyberSafe.com (engineering.cybersafe.com [192.156.168.125]) by kerby.cybersafe.com (8.7.6/8.7.3/8.7.5, dpg hack 30jul96) with SMTP id OAA07797 for ; Wed, 20 Nov 1996 14:48:26 -0800 (PST) Received: by CyberSafe.com (5.x/SMI-SVR4) id AA01119; Wed, 20 Nov 1996 14:48:22 -0800 From: Changwen Liu Message-Id: <9611201448.ZM1117@engineering.cybersafe.com> Date: Wed, 20 Nov 1996 14:48:21 -0800 X-Mailer: Z-Mail (3.2.1 10apr95) To: cat-ietf@mit.edu Subject: RFC-1964: Problem with getting server network addresses in GSS-API delegation support Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii RFC-1964 specifies the GSS-API mechanisms atop Kerberos V5 security technology per RFC-1508 and RFC-1510. It defines the elements of protocols for interoperability and independent of language bindings per RFC-1509. A new binding feature in the RFC-1964 is the support for delegation in GSS-API mechanisms. When delegation is active, a TGT with its FORWARDABLE flag set will be transferred within the check sum field in the initial token. RFC-1510 specifies how the forwarded TGT to be obtained. Clients usually send TGS_REQs with a set of network addresses where the tickets will be used to KDC. The KDC replies with TGTs back to clients. Clients are discouraged to send TGS-REQs without the set of network addresses to KDC. So in order to support delegation in GSS-API mechanisms, clients usually first get the network addresses of servers and then obtain delegated TGTs from KDC with these set of addresses. My big question is that how clients always get the network addresses of servers. In Kerberos V5 and GSS-API mechanisms, server names can be of types NT-PRINCIPAl, NT-SRV-HST, and NT-SRV-XHST. If the server name is of types NT-SRV-HST and NT-SRV-XHST, it is pretty straight forward to figure out the server network address from its name. The tough part is how to get the server network address if its name is of type NT-PRINCIPAl? Obviously, we cannot get server network address from its name. Then what should we do? In case of delegation support in GSS-API mechanisms, a lazy solution is that clients simply pass no network addresses to TGS_REQs and thus get TGTS which can be used everywhere. Since the RFC-1964 doesn't give a general scheme on how to get the network addresses for servers. This seems what we can go now. Do you have any better solutions for this problem? Thanks. Sincerely, changwen   Received: from cnri by ietf.org id aa10154; 20 Nov 96 19:21 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27544; 20 Nov 96 19:21 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 20 Nov 1996 23:37:44 GMT Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP id AA00600; Wed, 20 Nov 96 18:37:33 EST Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id AAA21764; Thu, 21 Nov 1996 00:36:39 +0100 Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA17368 (5.67b8/IDA-1.5); Thu, 21 Nov 1996 00:36:35 +0100 Message-Id: <199611202336.AA17368@sap-ag.de> Received: by hw1464.wdf.sap-ag.de (1.39.111.2/16.2) id AA272452988; Thu, 21 Nov 1996 00:36:28 +0100 From: Martin Rex Subject: Re: Ongoing document status; C bindings issues To: John Wray Digital DPE Date: Thu, 21 Nov 1996 00:36:28 +0100 (MEZ) Cc: cat-ietf@mit.edu In-Reply-To: <9611191948.AA09574@us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Nov 19, 96 02:48:31 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit John Wray, Digital DPE, wrote: > >(5) Martin Rex, 23 August: gss_acquire_cred behavior per C bindings > >draft. > > Added text explicitly allowing the use of NULL for desired_name as a way > of requesting a credential that will invoke default behavior. Did you add this information to gss_add_cred as well (the high level spec has it for both)? On top of that I'd really like to see the addition of #define GSS_C_NO_NAME (gss_name_t)0 to the C-Bindings and example header file -- I am using it heavily. :) -Martin   Received: from ietf.org by ietf.org id aa07351; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa05730; 21 Nov 96 9:45 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-sig-uni4.0-01.txt Date: Thu, 21 Nov 1996 09:45:42 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210945.aa05730@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : ATM Signalling Support for IP over ATM - UNI 4.0 Update Author(s) : M. Perez, A. Mankin Filename : draft-ietf-ion-sig-uni4.0-01.txt Pages : 20 Date : 11/15/1996 This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI 4.0 [UNI96] to support IP over ATM environments as described in RFC 1577 [LAUB94] and in [KATZ96]. Among the new features found in UNI 4.0 signalling are Available Bit Rate (ABR) signalling and traffic parameter negotiation. This initial draft highlights the features of UNI 4.0 signalling that provide IP entities capabilities for requesting ATM service in sites with SVC support, whether it is private ATM or publicly provisioned ATM, in which case the SVC support is probably configured inside PVPs. This document is only relevant to IP when used as the well know "best effort" connectionless service. In particular, this means that this document does not pertain to IP in the presence of implemented IP Integrated Services (ISS). The topic of IP with ISS over ATM will be handled by a different specification or set of specifications being worked on in the IISSL WG. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-sig-uni4.0-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-sig-uni4.0-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-sig-uni4.0-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115140905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-sig-uni4.0-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-sig-uni4.0-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115140905.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07353; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa06996; 21 Nov 96 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-ipv6-nbma-01.txt Date: Thu, 21 Nov 1996 09:51:10 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210951.aa06996@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : IPv6 over NBMA Networks Author(s) : R. Atkinson, D. Haskin, J. Luciani Filename : draft-ietf-ion-ipv6-nbma-01.txt Pages : 14 Date : 11/15/1996 This draft proposes an comprehensive approach to IPv6 over Non-Broadcast Multiple Access (NBMA) technologies that maximises reuse of existing technology and should work equally well over Frame Relay, ATM, and other NBMA technologies. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-ipv6-nbma-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-ipv6-nbma-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-ipv6-nbma-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961115141942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-ipv6-nbma-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-ipv6-nbma-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961115141942.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07344; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04153; 21 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rosen-tag-stack-00.txt Date: Thu, 21 Nov 1996 09:38:28 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210938.aa04153@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Tag Switching: Tag Stack Encodings Author(s) : E. Rosen, D. Tappan, D. Farinacci, Y. Rekhter, G. Fedorkow Filename : draft-rosen-tag-stack-00.txt Pages : 9 Date : 11/19/1996 This document specifies how the Tag Stack is encoded on Tagged Packets which are sent over PPP data links and over LAN data links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosen-tag-stack-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rosen-tag-stack-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rosen-tag-stack-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119155104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-tag-stack-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosen-tag-stack-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119155104.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07363; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04300; 21 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-parnes-rtp-ext-srm-01.txt Date: Thu, 21 Nov 1996 09:40:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210940.aa04300@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP extension for Scalable Reliable Multicast Author(s) : P. Parnes Filename : draft-parnes-rtp-ext-srm-01.txt Pages : 15 Date : 11/21/1996 This document describes how the Real-time Transport Protocol, RTP (RFC1889), could be extended to include support for parts of the framework called Scalable Reliable Multicast. The scheme proposed could be used for transporting a data flow reliably over the transport protocols supported by RTP in a light-weight way. This could be used for numerous applications, for instance white-boards, semi-reliable audio/video and messaging/data-transfers within group-ware applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-parnes-rtp-ext-srm-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-parnes-rtp-ext-srm-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-parnes-rtp-ext-srm-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121092229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-parnes-rtp-ext-srm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-parnes-rtp-ext-srm-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121092229.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07358; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04253; 21 Nov 96 9:39 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-01.txt Date: Thu, 21 Nov 1996 09:39:33 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210939.aa04253@ietf.org> --NextPart Note: This announcement is being re-sent with a new filename. A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-01.txt Pages : 15 Date : 11/19/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ipsec-doi-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961120140904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961120140904.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07359; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04435; 21 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myjak-lsma-scenarios-00.txt Date: Thu, 21 Nov 1996 09:41:00 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210941.aa04435@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Scenarios and Appropriate Protocols for Distributed Interactive Simulation Author(s) : S. Seidensticker, W. Smith, M. Myjak Filename : draft-myjak-lsma-scenarios-00.txt Pages : 5 Date : 11/20/1996 We describe Distributed Interactive Simulation (DIS) scenarios from the vantage point of hardware and software vendors who would need to address the network implications and requirements to enable large scale networked multiplayer virtual worlds. This document is meant to migrate the heuristic knowledge of the traditional Department of Defense (DoD) modeling and simulation community into tangible design metrics for the commercial networking community [2]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-myjak-lsma-scenarios-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myjak-lsma-scenarios-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myjak-lsma-scenarios-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121090823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myjak-lsma-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-myjak-lsma-scenarios-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121090823.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07356; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04170; 21 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-aboba-radius-tunnel-imp-00.txt Date: Thu, 21 Nov 1996 09:38:40 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210938.aa04170@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Implementation of Mandatory Tunneling via RADIUS Author(s) : B. Aboba, G. Zorn Filename : draft-aboba-radius-tunnel-imp-00.txt Pages : 14 Date : 11/20/1996 This document discusses implementation issues arising in the provisioning of mandatory tunneling in dial-up networks using the PPTP and L2TP protocols. This provisioning may be accomplished via the integration of RADIUS and tunneling protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aboba-radius-tunnel-imp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-aboba-radius-tunnel-imp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-aboba-radius-tunnel-imp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961120111203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aboba-radius-tunnel-imp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-aboba-radius-tunnel-imp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961120111203.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07310; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04234; 21 Nov 96 9:39 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ediint@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ediint-as1-02.txt Date: Thu, 21 Nov 1996 09:39:25 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210939.aa04234@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF. Title : MIME-based Secure EDI Author(s) : M. Jansson, C. Shih, N. Turaj, R. Drummond Filename : draft-ietf-ediint-as1-02.txt Pages : 15 Date : 11/20/1996 This document describes how to securely exchange EDI documents using MIME and public key cryptography. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ediint-as1-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ediint-as1-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ediint-as1-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121092640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ediint-as1-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ediint-as1-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121092640.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07375; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04339; 21 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-04.txt Date: Thu, 21 Nov 1996 09:40:39 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210940.aa04339@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : HMAC-SHA IP Authentication with Replay Prevention Author(s) : S. Chang, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-sha-04.txt Pages : 8 Date : 11/20/1996 This document describes a keyed-SHA transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-hmac-sha-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-sha-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961120141941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-sha-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961120141941.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07360; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04214; 21 Nov 96 9:39 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-smirnov-ion-earth-01.txt Date: Thu, 21 Nov 1996 09:39:16 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210939.aa04214@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : EARTH - EAsy IP multicast Routing THrough ATM clouds Author(s) : M. Smirnov Filename : draft-smirnov-ion-earth-01.txt Pages : 10 Date : 11/20/1996 The EARTH could be positioned between MARS [1] and VENUS [2], however EARTH deals not only with address resolution but with routing issue as well. This document describes a solution simplifying distribution of IP multicast flows over ATM clouds with the use of point-to-multipoint connections. The EARTH solution includes: - IP multicast addresses (Class D) resolution to ATM addresses; - support for a multicast group management and receiver-initiated quality of service (QoS) specification; - multiple LISs sharing the same physical ATM network. Similarly to separation of IP addresses to unicast and multicast classes, the EARTH proposal separates logical IP subnets as an option to speed up implementation. EARTH differs from MARS: address resolution is made only for IP Class D addresses; multiple LISs could be served by a single EARTH server; EARTH server belongs to a `multicast LIS'. On contrary to VENUS proposal, EARTH simplifies bypassing Mrouters and requires no coordination of multiple MARSs. The EARTH proposal is not intended to solve problems of ATM backbone for the Internet; it deals with state-of-the-art ATM clouds. This document, proposing a solution not yet implemented completely, is intended to help focus ION efforts. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-smirnov-ion-earth-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-smirnov-ion-earth-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-smirnov-ion-earth-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961120132111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-smirnov-ion-earth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-smirnov-ion-earth-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961120132111.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07312; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04188; 21 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ediint@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ediint-req-01.txt Date: Thu, 21 Nov 1996 09:38:46 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210938.aa04188@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF. Title : Requirements for Inter-operable Internet EDI Author(s) : C. Shih, M. Jansson, R. Drummond, L. Yarbrough Filename : draft-ietf-ediint-req-01.txt Pages : 33 Date : 11/20/1996 This document is a functional specification, discussing the requirements for inter-operable EDI, with sufficient background material to give an explanation for the EDI community of the Internet, and security related issues. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ediint-req-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ediint-req-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ediint-req-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961120113939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ediint-req-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ediint-req-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961120113939.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa09337; 21 Nov 96 10:31 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11542; 21 Nov 96 10:31 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Thu, 21 Nov 1996 14:23:02 GMT Received: from mail11.digital.com by MIT.EDU with SMTP id AA16058; Thu, 21 Nov 96 09:23:01 EST Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA26703; Thu, 21 Nov 1996 09:13:24 -0500 (EST) Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA23830; Thu, 21 Nov 96 09:15:26 -0500 Message-Id: <9611211415.AA23830@us1rmc.bb.dec.com> Received: from tuxedo.enet; by us1rmc.enet; Thu, 21 Nov 96 09:15:26 EST Date: Thu, 21 Nov 96 09:15:26 EST From: "John Wray, Digital DPE, (508) 486-5210 21-Nov-1996 0909" To: martin.rex@sap-ag.de Cc: "cat-ietf@mit.edu"@in.enet.dec.com, wray@tuxedo.enet.dec.com Apparently-To: cat-ietf@mit.edu, martin.rex@sap-ag.de Subject: RE: duplicate_name: BAD_NAME_TYPE ? Martin writes: >I think gss_duplicate_name() should not be allowed to return >GSS_S_BAD_NAMETYPE. > >An invalid internal name (i.e. a gss_name_t that doesn't map to >a valid internal name) should be answered with GSS_S_BAD_NAME. I agree - the same argument as was used to remove this status code from gss_display_name() and gss_compare_names() applies, so (subject to the top-level spec adopting this change) this status should go away here too. John   Received: from cnri by ietf.org id aa11512; 21 Nov 96 11:10 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12585; 21 Nov 96 11:10 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Thu, 21 Nov 1996 15:08:24 GMT Received: from mail12.digital.com by MIT.EDU with SMTP id AA21215; Thu, 21 Nov 96 09:15:52 EST Received: from us1rmc.bb.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA24009; Thu, 21 Nov 1996 09:09:19 -0500 (EST) Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA23446; Thu, 21 Nov 96 09:11:20 -0500 Message-Id: <9611211411.AA23446@us1rmc.bb.dec.com> Received: from tuxedo.enet; by us1rmc.enet; Thu, 21 Nov 96 09:11:21 EST Date: Thu, 21 Nov 96 09:11:21 EST From: "John Wray, Digital DPE, (508) 486-5210 21-Nov-1996 0906" To: martin.rex@sap-ag.de Cc: "cat-ietf@mit.edu"@in.enet.dec.com, wray@tuxedo.enet.dec.com Apparently-To: cat-ietf@mit.edu, martin.rex@sap-ag.de Subject: Re: Ongoing document status; C bindings issues Martin writes: >> Added text explicitly allowing the use of NULL for desired_name as a way >> of requesting a credential that will invoke default behavior. > >Did you add this information to gss_add_cred as well (the high level >spec has it for both)? I didn't, but I have now. >On top of that I'd really like to see the addition of > >#define GSS_C_NO_NAME (gss_name_t)0 > >to the C-Bindings and example header file -- I am using it heavily. :) OK, that's there too. John   Received: from cnri by ietf.org id aa11773; 21 Nov 96 11:14 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12674; 21 Nov 96 11:14 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Thu, 21 Nov 1996 14:36:24 GMT Received: from mail11.digital.com by MIT.EDU with SMTP id AA18678; Thu, 21 Nov 96 09:36:23 EST Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA15190; Thu, 21 Nov 1996 09:28:23 -0500 (EST) Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA24731; Thu, 21 Nov 96 09:30:25 -0500 Message-Id: <9611211430.AA24731@us1rmc.bb.dec.com> Received: from tuxedo.enet; by us1rmc.enet; Thu, 21 Nov 96 09:30:26 EST Date: Thu, 21 Nov 96 09:30:26 EST From: "John Wray, Digital DPE, (508) 486-5210 21-Nov-1996 0917" To: martin.rex@sap-ag.de Cc: "cat-ietf@mit.edu"@in.enet.dec.com, wray@tuxedo.enet.dec.com Apparently-To: cat-ietf@mit.edu, martin.rex@sap-ag.de Subject: RE: description of gss_duplicate_name Martin writes: >The current description of gss_duplicate_name in the C-Bindings >could grow some more text. We could reuse the description from >the high-level specs, but I would prefer some small changes: > >current description from high-level (gssv2-08): > > 2.4.19: GSS_Duplicate_name call > > This routine takes input internal name src_name, and returns another > reference (dest_name) to that name which can be used even if src_name > is later freed. (Note: This may be implemented by copying or through > use of reference counts.) > >My suggestion (for at least the C-Bindings): > > This routine creates an exact duplicate of the existing internal name > src_name and returns it. The new internal name dest_name will be > independent of src_name, i.e. dest_name will have to be released > seperately; its validity will not be affected by the release > of src_name. (It is a local matter if a gssapi mechanism implements > this by refcounting or true copying). I haven't mentioned reference-counting anywhere else in the C-bindings, so I don't think I should introduce it here. Based on your text above, I've put: Create an exact duplicate of the existing internal name src_name. The new dest_name will be independent of src_name (i.e. dest_name must be released independently of src_name, and the release of one shall not affect the validity of the other). >While writing this I was looking up the description of >gss_canonicalize_name(). I was wondering if there was any gssapi call >able to "modify" an internal name, which would create gotchas for >refcount implementations. Well, gss_canonicalize_name takes a src_name >and returns a dest_name, very similar to gss_duplicate_name. > >Acutally I would expect canonicalize_name to work EXACTLY like >duplicate_name for MNs. I feel this is not sufficiently clear from >the explanation in the high-level spec. > > >current description from high-level (gssv2-08): > > 2.4.17: GSS_Canonicalize_name call > > This routine reduces a GSS-API internal name, which may in general > contain elements corresponding to multiple mechanisms, to a > mechanism-specific Mechanism Name (MN) by applying the translations > corresponding to the mechanism identified by mech_type. > > >current description from C-bindings (gssv2-cbind-02): > > 7.5. gss_canonicalize_name > > Generate a canonical mechanism name (MN) from an arbitary internal > name. A mechanism name is the name that would be returned to a > context acceptor on succesful authentication of a context where the > initiator used the input_name in a sucesful call to gss_acquire_cred, > specifying an OID set containing as its only member, > followed by a call to gss_init_sec_context, specifying as > the authentication mechanism. > > >The wording in the high level specs sounds slightly like it would be >*modifying* src_name. It should be *duplicating* src_name into dest_name >and modify dest_name (or create a modified dest_name from src_name), >and it should be mentioned (like in duplicate_name), that dest_name >will exist indepently of src_name. > >I really appreciate the information in the current explanation in the >C-bindings, but (I'm nitpicking, please forgive me) a mechanism name >will also be returned when the initiator doesn't call gss_acquire_cred >and passes GSS_C_NO_CREDENTIAL to gss_init_sec_context. What I was trying to do in the C-bindings text here was to explicitly say _which_ MN would be returned (as opposed to defining what an MN is). I've change the initial "A" of the second sentence in the para quoted above to "The" to clarify this. I've also fixed the spelling of "successful" and "arbitrary" :-) John   Received: from cnri by ietf.org id ab05886; 21 Nov 96 19:20 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25190; 21 Nov 96 19:20 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Thu, 21 Nov 1996 23:18:01 GMT Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA23430; Thu, 21 Nov 96 18:17:59 EST Received: by dcl.MIT.EDU (5.x/4.7) id AA01403; Thu, 21 Nov 1996 18:17:59 -0500 Date: Thu, 21 Nov 1996 18:17:59 -0500 Message-Id: <9611212317.AA01403@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: cat-ietf@mit.edu Subject: [Steve Nahm: New charter; new co-chair] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 The ONCRPC working group is starting a new phase of work, which involves adding an authentication flavor which uses GSSAPI. I invite all those in the CAT wg who might be interested in this work area to join the ONCRPC wg mailing list, download the internet drafts, and show up at the upcoming San JOSE wg meeting! - Ted ------- Forwarded Message Date: Wed, 20 Nov 1996 21:30:09 -0800 From: sxn@caribe-85.Eng.Sun.COM (Steve Nahm) To: oncrpc-wg@sunroof.Eng.Sun.COM Subject: New charter; new co-chair Cc: mankin@ISI.EDU, allyn@caribe-85.Eng.Sun.COM X-Sun-Charset: US-ASCII There were no objections or discussions on the revised charter that I posted on this alias a while back, so our area directors made a few minor tweaks to it and agreed to the new charter. I'm pleased to announce that Ted Ts'o has agreed to become co-chair of this WG as we move into the "security mechanism" phase of work. Ted's experience working with the RPC authentication flavors will bring a practical perspective to the review of the RPCSEC_GSS proposal that's currently on the table. Note that the schedule listed below is moderately agressive, and will require that all interested parties spend the time needed to review the RPCSEC_GSS proposal and bring up any issues early. To date, no one outside of Sun has committed to reviewing the draft by the San Jose WG meeting. We *must* do a critical review of the proposal by this meeting if we are to meet the timetable below. So this time I'll ask those of you who think they *might* review the RPCSEC_GSS proposal in time for discussion at the San Jose meeting, please email me (or the WG list if you're willing to go public :-). Thanks and see you in a few weeks, Steve ONC Remote Procedure Call (oncrpc) ----------------------------------- Charter Current status: active working group Chair(s): Steve Nahm Ted Ts'o Transport Area Director(s): Allison Mankin Allyn Romanow Mailing lists: General Discussion:oncrpc-wg@sunroof.eng.sun.com To Subscribe: oncrpc-wg-request@sunroof.eng.sun.com Archive: ftp://playground.sun.com/pub/oncrpc Description of Working Group: The Open Network Computing Remote Procedure Call Working Group was originally formed to update the RFCs that describe ONC RPC to reflect the current state of the deployed and accepted technology, and submit them for Internet standardization. RFCs have been submitted for the three core ONC technologies: RPC (RFC1831), RPC Binding (RFC 1833) and XDR (RFC1832). During this work, IESG identified the area of security as requiring improvement prior to standardizing the core RPC technologies (RPC and RPC Binding). Therefore, the Working Group shall develop and define a security mechanism for ONC RPC which shall, at the minimum, allow for strong authentication of client and server principals. The core RPC technologies will be unblocked from the standards track once such a mechanism is approved as a Proposed Standard, provided that its design does not require changes to the core RPC technologies. The basis for the work will be the RPCSEC_GSS Protocol Specification, draft-ietf-oncrpc-rpcsec_gss.00.txt. The document editor will be Michael Eisler. Background: ONC RPC is a Remote Procedure Call technology that originated in Sun Microsystems in the early 1980s. ONC RPC was modelled on Xerox's Courier RPC protocols. It has been widely deployed on platforms from most major workstation vendors. It has been implemented on MS-DOS, Microsoft Windows, Microsoft Windows NT, Mac, VMS, MVS, and practically all flavors of UNIX, among others. Sun Microsystems has delegated change control for the ONC RPC protocols for the purposes of making an Internet Standard to the IETF (see RFC 1790). Goals and Milestones: Done Submit XDR document to IESG for consideration as a Draft Standard. Done Submit a strong security mechanism for ONC RPC as an Internet Draft. Feb 97 Submit strong security mechanism for ONC RPC to IESG for consideration as a Proposed Standard. Mar 97 Submit core RPC documents to IESG for consideration as Draft Standards. Mar 97 Conclude working group, leaving mailing list in place for pursuit of the subseqent standards stages. The anticipated schedule for submissions is: Apr 97 XDR for consideration as Internet Standard Aug 97 Core RPC for consideration as Internet Standard Aug 97 Strong security mechanism for consideration as Draft Standard Jan 98 Strong security mechanism for consideration as Internet Standard ------- End Forwarded Message   Received: from cnri by ietf.org id aa07249; 21 Nov 96 20:24 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26400; 21 Nov 96 20:24 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Fri, 22 Nov 1996 00:35:26 GMT Received: from palrel3.hp.com by MIT.EDU with SMTP id AA19593; Thu, 21 Nov 96 19:35:24 EST Received: from bengal.cup.hp.com (bengal.cup.hp.com [15.13.104.131]) by palrel3.hp.com with SMTP (8.7.5/8.7.3) id QAA27310 for ; Thu, 21 Nov 1996 16:34:38 -0800 (PST) Received: by bengal.cup.hp.com (1.38.193.4/15.5+IOS 3.20+cup+OMrelay) id AA12656; Thu, 21 Nov 1996 16:28:13 -0800 From: Sandya Bhoajaraj Message-Id: <9611220028.AA12656@bengal.cup.hp.com> Subject: FTP Security Extensions? To: cat-ietf@mit.edu Date: Thu, 21 Nov 96 16:28:13 PST Mailer: Elm [revision: 70.85] Hi, Could someone respond with the status of the ietf draft "FTP Security Extensions"? The last revision expired in February. Thanks, Sandya. -- Sandya Bhoajaraj sandya@bengal.cup.hp.com NCD Internet Services Telnet:1-447-3123 Outside: 408-447-3123 Hewlett-Packard   Received: from cnri by ietf.org id aa08568; 21 Nov 96 21:29 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27479; 21 Nov 96 21:29 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Fri, 22 Nov 1996 01:35:27 GMT Received: from rover.cygnus.com by MIT.EDU with SMTP id AA14375; Thu, 21 Nov 96 20:35:25 EST Received: (from marc@localhost) by rover.cygnus.com (8.7.6/8.6.12) id UAA24190; Thu, 21 Nov 1996 20:32:04 -0500 (EST) To: Sandya Bhoajaraj Cc: cat-ietf@mit.edu Subject: Re: FTP Security Extensions? References: <9611220028.AA12656@bengal.cup.hp.com> From: Marc Horowitz Date: 21 Nov 1996 20:32:04 -0500 In-Reply-To: Sandya Bhoajaraj's message of Thu, 21 Nov 96 16:28:13 PST Message-Id: Lines: 12 X-Mailer: Gnus v5.3/Emacs 19.34 Sandya Bhoajaraj writes: >> Could someone respond with the status of the ietf draft >> "FTP Security Extensions"? The last revision expired in February. I guess this is a good place to announce this. I've revised the draft (finished it today), and will submit it once I get some nroff questions answered. (Anybody know how to do section numbering in nroff for i-d's?) I won't let mere formatting hold this up, so if I don't get a good answer by Monday, I'll submit it then. Marc   Received: from cnri by ietf.org id aa21592; 22 Nov 96 4:07 EST Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa05417; 22 Nov 96 4:07 EST Received: (from daemon@localhost) by external.BSDI.COM (8.8.3/8.8.2) id CAA13483 for telnet-ietf-list@bsdi.com; Fri, 22 Nov 1996 02:03:15 -0700 (MST) Received: from dtc.rankxerox.co.uk (mailgate.dtc.rankxerox.co.uk [194.217.143.1]) by external.BSDI.COM (8.8.3/8.8.2) with ESMTP id CAA13453 for ; Fri, 22 Nov 1996 02:03:12 -0700 (MST) Received: (from robin@localhost) by dtc.rankxerox.co.uk (8.7.4/8.7.3) id IAA21002; Fri, 22 Nov 1996 08:53:26 GMT Date: Fri, 22 Nov 1996 08:53:23 +0000 (GMT) From: Robin Carey To: telnet-ietf@bsdi.com Subject: Telnet Protocol Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Sir/Madam, I would be most grateful if you could help me with some information, with regard to the TELNET protocol. Could you please advise me as to which RFC documents provide a complete and up-to-date specification for the TELNET protocol (including the individual options) ? I have heard rumour that the telnet-ietf are in the process of creating a RFC for TELNET encryption ... has this been released yet ? Many thanks for any/all help. Yours sincerely, Robin J Carey.   Received: from cnri by ietf.org id aa28357; 22 Nov 96 9:54 EST Received: from [171.69.1.187] by CNRI.Reston.VA.US id aa12217; 22 Nov 96 9:54 EST Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by maltese.cisco.com (8.6.12/8.6.5) with ESMTP id GAA13411 for ; Fri, 22 Nov 1996 06:43:06 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id GAA02843 for ; Fri, 22 Nov 1996 06:43:05 -0800 (PST) Received: from ietf.org by ietf.org id aa27364; 22 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: snanaumib@cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snanau-hprmib-00.txt Date: Fri, 22 Nov 1996 09:40:04 -0500 Sender: cclark@ietf.org Message-ID: <9611220940.aa27364@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNA NAU Services MIB Working Group of the IETF. Title : Definitions of Managed Objects for HPR Author(s) : B. Clouston, B. Moore Filename : draft-ietf-snanau-hprmib-00.txt Pages : 37 Date : 11/21/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snanau-hprmib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snanau-hprmib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-snanau-hprmib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121103757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snanau-hprmib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snanau-hprmib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121103757.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa29998; 22 Nov 96 10:22 EST Received: from ietf.org by ietf.org id aa27512; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: nimrod-wg@bbn.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nimrod-dns-02.txt Date: Fri, 22 Nov 1996 09:41:03 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220941.aa27512@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the New Internet Routing and Addressing Architecture Working Group of the IETF. Title : DNS Resource Records for Nimrod Routing Architecture Author(s) : M. Patton Filename : draft-ietf-nimrod-dns-02.txt Pages : 5 Date : 11/21/1996 This document describes two additional RR types for the Domain Name System[7,8] required to implement the Nimrod Routing Architecture[1]. These RRs record the Nimrod Locator and an Endpoint Identifier (EID) associated with a given Domain Name. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nimrod-dns-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-nimrod-dns-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-nimrod-dns-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121151450.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nimrod-dns-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nimrod-dns-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121151450.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01712; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27529; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ftp-wg@hops.ag.utk.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ftpext-intl-ftp-00.txt Date: Fri, 22 Nov 1996 09:41:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220941.aa27529@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions to FTP Working Group of the IETF. Title : Internationalization of the File Transfer Protocol Author(s) : B. Curtin Filename : draft-ietf-ftpext-intl-ftp-00.txt Pages : 15 Date : 11/21/1996 The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC 1123 Section 4 [RFC1123], is one of the oldest and widely used protocols on the Internet. The protocol's primary character set, 7 bit ASCII, has served the protocol well through the early growth years of the Internet. However, as the Internet becomes more global, there is a need to support character sets beyond 7 bit ASCII. This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ftpext-intl-ftp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ftpext-intl-ftp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ftpext-intl-ftp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121155610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ftpext-intl-ftp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ftpext-intl-ftp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121155610.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01780; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27393; 22 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: snanaumib@cisco.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snanau-dlurmib-00.txt Date: Fri, 22 Nov 1996 09:40:14 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220940.aa27393@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNA NAU Services MIB Working Group of the IETF. Title : Definitions of Managed Objects for DLUR Author(s) : B. Clouston, B. Moore Filename : draft-ietf-snanau-dlurmib-00.txt Pages : 20 Date : 11/21/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snanau-dlurmib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snanau-dlurmib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-snanau-dlurmib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121104155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snanau-dlurmib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snanau-dlurmib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121104155.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01776; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27563; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-http-conv-00.txt Date: Fri, 22 Nov 1996 09:41:23 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220941.aa27563@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Conventions for the Use of HTTP for URN Resolution Author(s) : R. Daniel Filename : draft-ietf-urn-http-conv-00.txt Pages : 6 Date : 11/21/1996 The URN-WG was formed to specify persistent, location-independent names for network accessible resources, and resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal does not get the client software all the way from the URN to the resource. Instead, it gets the client from a URN to a "resolver", which is a system that can then tell the client where the resource is. The NAPTR draft defines a "resolution protocol" to be the protocol used to speak to a resolver in order to obtain the resource, its location(s), or other information about the resource. The NAPTR proposal allows different resolution protocols to be used for commuicating with resolvers. This draft establishes conventions for encoding URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URNresolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-http-conv-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-http-conv-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-http-conv-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121163444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-http-conv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-http-conv-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121163444.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01720; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27489; 22 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: nimrod-wg@bbn.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nimrod-eid-01.txt Date: Fri, 22 Nov 1996 09:40:51 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220940.aa27489@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the New Internet Routing and Addressing Architecture Working Group of the IETF. Title : Endpoint Identifier Destination Option Author(s) : C. Lynn Filename : draft-ietf-nimrod-eid-01.txt Pages : 4 Date : 11/21/1996 This document describes a Destination Option that is used to convey topologically independent endpoint identification information between source and destination endpoints in either IPv4 or IPv6 packets. The general format of Destination Options are described in [5]. The Nimrod Routing System [1] will make use of this option to convey Nimrod EIDs. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nimrod-eid-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-nimrod-eid-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-nimrod-eid-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121145606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nimrod-eid-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nimrod-eid-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121145606.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01777; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27425; 22 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pritchard-http-links-00.txt Date: Fri, 22 Nov 1996 09:40:30 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220940.aa27425@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Efficient HyperLink Maintenance for HTTP Author(s) : J. Pritchard Filename : draft-pritchard-http-links-00.txt Pages : 7 Date : 11/21/1996 Hyperlink maintenance allows robots and servers to cooperate in propagating the effects of daily changes in the millions of resource locations in the wwweb. Here, we propose developing the definitions of the LINK and UNLINK methods defined for HTTP since RFC 1945 and which remain largely unimplemented and unused. We believe that the only reason these methods have not been employed is that they remain too loosely defined and implicitly too inefficient. A new syntax and semantics simplify implementation and improve utility. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pritchard-http-links-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-pritchard-http-links-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-pritchard-http-links-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121114349.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pritchard-http-links-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pritchard-http-links-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121114349.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01785; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27315; 22 Nov 96 9:39 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-nhrp-appl-00.txt Date: Fri, 22 Nov 1996 09:39:54 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220939.aa27315@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : NHRP Protocol Applicability Statement Author(s) : D. Cansever Filename : draft-ietf-ion-nhrp-appl-00.txt Pages : 8 Date : 11/21/1996 As required by the Routing Protocol Criteria [RFC 1264], this draft report discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. The final form of this draft report is a prerequisite to advancing NHRP on the standards track. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-nhrp-appl-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-nhrp-appl-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-nhrp-appl-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121100048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-nhrp-appl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-nhrp-appl-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121100048.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01762; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27443; 22 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ssh@cert.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ssh-users-00.txt Date: Fri, 22 Nov 1996 09:40:34 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220940.aa27443@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Security Handbook Working Group of the IETF. Title : Users' Security Handbook Author(s) : G. Malkin Filename : draft-ietf-ssh-users-00.txt Pages : 19 Date : 11/21/1996 The Users' Security Handbook is the companion to the Site Security Handbook (FYI 8). It is intended to provide users with the information they need to keep their networks and systems secure. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ssh-users-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ssh-users-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ssh-users-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121132801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ssh-users-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ssh-users-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121132801.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01783; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27580; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-naptr-01.txt Date: Fri, 22 Nov 1996 09:41:32 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220941.aa27580@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Resolution of Uniform Resource Identifiers using the Domain Name System Author(s) : R. Daniel, M. Mealling Filename : draft-ietf-urn-naptr-01.txt Pages : 13 Date : 11/21/1996 Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-naptr-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-naptr-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121163946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-naptr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-naptr-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121163946.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa07475; 22 Nov 96 11:11 EST Received: from griffon.cisco.com by CNRI.Reston.VA.US id aa14670; 22 Nov 96 11:11 EST Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by griffon.cisco.com (8.6.12/8.6.5) with ESMTP id IAA25176 for ; Fri, 22 Nov 1996 08:05:27 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id IAA01483 for ; Fri, 22 Nov 1996 08:05:25 -0800 (PST) Received: from ietf.org by ietf.org id aa27334; 22 Nov 96 9:39 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: snanaumib@cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snanau-appnmib-02.txt Date: Fri, 22 Nov 1996 09:39:59 -0500 Sender: cclark@ietf.org Message-ID: <9611220939.aa27334@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNA NAU Services MIB Working Group of the IETF. Title : Definitions of Managed Objects for APPN Author(s) : B. Clouston, B. Moore Filename : draft-ietf-snanau-appnmib-02.txt Pages : 129 Date : 11/21/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snanau-appnmib-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snanau-appnmib-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-snanau-appnmib-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121103403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snanau-appnmib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snanau-appnmib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121103403.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa08358; 22 Nov 96 11:36 EST Received: from merit.edu by CNRI.Reston.VA.US id aa15490; 22 Nov 96 11:36 EST Received: (from daemon@localhost) by merit.edu (8.7.6/merit-2.0) id LAA29690 for idr-outgoing; Fri, 22 Nov 1996 11:07:39 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.7.6/merit-2.0) with SMTP id LAA29676 for ; Fri, 22 Nov 1996 11:07:35 -0500 (EST) Received: from ietf.org by ietf.org id aa27613; 22 Nov 96 9:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-04.txt Date: Fri, 22 Nov 1996 09:41:41 -0500 Message-ID: <9611220942.aa27613@ietf.org> Sender: owner-idr@merit.edu Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter, T. Li Filename : draft-ietf-idr-bgp4-04.txt Pages : 60 Date : 11/21/1996 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121164823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121164823.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa09851; 22 Nov 96 11:57 EST Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa16120; 22 Nov 96 11:57 EST Received: (from daemon@localhost) by external.BSDI.COM (8.8.3/8.8.2) id JAA04776 for telnet-ietf-list@bsdi.com; Fri, 22 Nov 1996 09:53:19 -0700 (MST) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by external.BSDI.COM (8.8.3/8.8.2) with SMTP id JAA04770 for ; Fri, 22 Nov 1996 09:53:17 -0700 (MST) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA17155; Fri, 22 Nov 96 11:52:42 EST Received: by dcl.MIT.EDU (5.x/4.7) id AA03822; Fri, 22 Nov 1996 11:52:35 -0500 Date: Fri, 22 Nov 1996 11:52:35 -0500 Message-Id: <9611221652.AA03822@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Robin Carey Cc: telnet-ietf@bsdi.com In-Reply-To: Robin Carey's message of Fri, 22 Nov 1996 08:53:23 +0000 (GMT), Subject: Re: Telnet Protocol Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Fri, 22 Nov 1996 08:53:23 +0000 (GMT) From: Robin Carey I would be most grateful if you could help me with some information, with regard to the TELNET protocol. Could you please advise me as to which RFC documents provide a complete and up-to-date specification for the TELNET protocol (including the individual options) ? There unfortunately no one document that describes the full telnet protocol. If you ftp to ds.internic.net, and look in /rfc, you will see all of the various RFC's. (Or you can go to some other RFC repository, if you wish). RFC 854 contains the base telent specification. It does not contain the various telnet options, however. For those you will have to look up all of the various telnet options in the rfc-index. This is inconvenient, I know, but there is no comprehensive list of which options you should really implement if you're interested in interoperability. Examining the freely available telnet source code from BSD is a good start for seeing which telnet options are commonly accepted by most implementations on the internet. I have heard rumour that the telnet-ietf are in the process of creating a RFC for TELNET encryption ... has this been released yet ? No, not yet, and that's mostly my fault. (ENOTIME....) I can give you drafts of what the base telnet encryption specification (and the attendant Kerberos V4 and V5 suboptions), if you like. Let me know and I'll e-mail them out. - Ted   Received: from ietf.org by ietf.org id aa26155; 22 Nov 96 15:12 EST Received: from ietf.org by ietf.org id aa25625; 22 Nov 96 15:08 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: ietf-rsvp@ietf.org Subject: IETF MAILING: RSVP: December 9-13, 1996/San Jose, CA Date: Fri, 22 Nov 1996 15:08:33 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9611221508.aa25625@ietf.org> **************************** Registration cut-off is December 4, 1996 after that time you will need to register on-site **************************** REGISTRATION FORM 37th Internet Engineering Task Force - Page 1 of 2 December 9-13, 1996 San Jose, California, USA Please print or type: Name (Mr/Dr/Ms)__________________________________________________________ Title____________________________________________________________________ Organization_____________________________________________________________ Address__________________________________________________________________ _________________________________________________________________________ City_____________________________State_____________Postal Code___________ Country__________________________________________________________________ Telephone______________________________Fax_______________________________ Email____________________________________________________________________ Do you plan to attend the Sunday, DECEMBER 8th NEWCOMER'S ORIENTATION at 1530? YES___ NO___ Do you plan to attend the Sunday, DECEMBER 8th reception at 17:00? YES___ NO___ The IETF Proceedings are available electronically. Would you still like a hard copy? YES___ NO ___ US$270.00 (US$250.00 + US$20.00 late fee) Registration postmarked after Friday, November 8, 1996. Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check (U.S. dollars, drawn on a U.S. Bank), payable to: Corporation for National Research Initiatives Account No.____________________________ Expiration Date__________________ Cardholder Name__________________________________________________________ Cardholder Signature_____________________________________________________ Registration Forms can be sent via electronic mail, facsimile, or postal mail: Electronic: ietf-rsvp@ietf.org Facsimile: +1-703-758-5913 Postal: Corporation for National Research Initiatives Accounting Department - 37th IETF Meeting 1895 Preston White Drive, Suite 100 Reston, VA 20191-5434 USA REGISTRATION FORM 37th Internet Engineering Task Force - Page 2 of 2 December 9-13, 1996 San Jose, California, USA IMPORTANT: 1. Payment MAY, but does NOT have to, accompany the Form. 2. As long as your Form is postmarked by the deadline date of November 8, 1996, you are locked in to pay the lower registration fee of $250.00 (e.g., send us your form via e-mail by the deadline date and pay the $250.00 fee later via postal mail). When paying by company check, be sure that your Accounting Department knows that you qualified yourself for the lower rate. 3. Payment is accepted on-site. 4. Register ONE person per form. Substitutions are NOT allowed. 5. Include a completed Registration Form with payment. 6. Purchase orders are NOT accepted. 7. DD Form 1556 IS accepted. 8. We CANNOT invoice for payment. 9. Registration Forms will be accepted via electronic mail and facsimile until 1300ET on Wednesday, December 4, 1996. 10. Requests for refunds must be received by 1700ET, Thursday, December 5, 1996. No refunds will be processed beyond this point. 11. REFUND POLICY: Refunds are subject to a US$20.00 service charge. Late fees WILL NOT be refunded. 12. Your registration fee includes Sunday evening reception (cash bar), and a daily continental breakfast and coffee breaks. For additional information or assistance, please contact +1-703-620-8990, +1-703-758-5913 (Fax) or ietf-rsvp@ietf.org. Direct all inquiries to: 37th IETF Meeting - San Jose, California, USA   Received: from ietf.org by ietf.org id aa26159; 22 Nov 96 15:12 EST Received: from ietf.org by ietf.org id aa25216; 22 Nov 96 15:05 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: ietf-rsvp@ietf.org Subject: 37th IETF LIST OF REGISTERED ATTENDEES Date: Fri, 22 Nov 1996 15:05:27 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9611221505.aa25216@ietf.org> Following is a list of registered attendees as of noon ET on November 22, 1996. 1 Aboba, Bernard Microsoft Corporation 2 Adam, Daniel Microsoft Corporation 3 Adams, Carlisle Nortel Technology 4 Adams, Robert Cisco Systems 5 Agbleze, Mawuse FTP Software, Inc. 6 Ahmed, Masuma Terayon Corporation 7 Ahuja, Ratinder Cisco Systems 8 Aibara, Reiji Hiroshima City University 9 Alaettinoglu, Cengiz Information Sciences Institute 10 Albadine, Samir Global One 11 Alden, Roland 12 Alexander, Steve Silicon Graphics, Inc. 13 Allen, Edward Bay Networks, Inc. 14 Allen, Jeff Bunyip Information Systems 15 Allen, Terry Fujitsu Software Corp. 16 Alles, Anthony Cisco Systems 17 Allocchio, Claudio National Institute for Nuclear Physics, Italy 18 Almes, Guy Advanced Network and Services, Inc. 19 Alten, Alex Tri-State Security, Inc. 20 Alterman, Louise Lucent Technologies 21 Alvestrand, Harald UNINETT AS 22 Amano, Akira Hiroshima City University 23 Ambler, Christopher Image Online Design, Inc. 24 Amidon, Keith Hewlett-Packard 25 Andersson, Loa Eriksson Telecom AB 26 Angelopoulos, Spiros Sterling Software 27 Antonov, Vadim Pluris, Inc. 28 Apple, Chris AT&T Bell Laboratories 29 Aprille, Thomas Lucent Technologies, Bell Laboratories 30 Arango, Jesus Supernet S.A. 31 Ariaans, Jos Unisource Business Networks Netherlands B.V. 32 Arkko, Jari Oy LM Ericsson Ab 33 Armitage, Grenville Bellcore 34 Armstrong, Susie Qualcomm Inc. 35 Armstrong, Thomas Internet MCI 36 Arneson, David Digital Equipment Corporation 37 Aronson, Jules National Library of Medicine 38 Artru, Frederic Apple Computer, Inc. 39 Arunkumar, Nagaraj 3Com Corporation 40 Asaeda, Hitoshi IBM Japan Ltd. 41 Asano, Kazuo Fujitsu Laboratories Ltd. 42 Ashraf, Syed Cisco Systems 43 At-Taras, Elsiddig Tandem Computers Incorporated 44 Atarashi, Yoshifumi Hitachi, Ltd. 45 Atkinson, Randall Cisco Systems 46 Audet, Francois Nortel Technology 47 Auerbach, Karl Precept Software, Inc. 48 Austein, Robert Epilogue Technology Corporation 49 Bade, Steven IBM 50 Bailey, Chase Cisco Systems 51 Bailey, Ed IBM Corporation 52 Baird-Smith, W3C / INRIA 53 Baker, Fred Cisco Systems 54 Baker, Mary Stanford University 55 Baker, Roman 3Com Corporation 56 Bakker, Steven DANTE 57 Balenson, David Trusted Information Systems 58 Ballardie, Anthony University College London 59 Ballou, Nat Microsoft Corporation 60 Bando, Tatsuo Matsushita Graphic Communication Systems, Inc. 61 Bannister, Joseph USC/ISI 62 Bantel, Richard Lucent Technologies 63 Bare, Ballard Hewlett-Packard 64 Barnes, Jeremy BT Laboratories 65 Barnes, Jim Bay Networks, Inc. 66 Barnick, Michael Apple Computer, Inc. 67 Barrett, Alan UUNET Internet Africa 68 Bason, Chris Network Solutions, Inc. 69 Bassham, Lawrence National Institute of Standards and Technology 70 Bates, Tony Cisco Systems 71 Bathina, Raghu Trancell Systems, Inc. 72 Bathrick, Ward NetLOCK 73 Batsell, Stephen Oak Ridge National Laboratory 74 Bauer, Fred SRI International 75 Baugher, Mark Intel Corporation 76 Beaulieu, Marcia Corporation for National Research Initiatives 77 Bedell, J. Patrick 78 Behki, Nutan Newbridge Networks Inc. 79 Behrle, Jeremy Cisco Systems 80 Belk, C.J. CMG Direct Interactive 81 Bellovin, Steven AT&T Research 82 Bennington, Jerry CableLabs 83 Berger, Lou FORE Systems 84 Berkhout, Vincent DANTE 85 Berkowitz, Howard PSC International 86 Bernardi, Marco CSELT 87 Bernstein, Alon Netro-Corp 88 Berson, Steven Information Sciences Institute 89 Beyer, Mark NetManage, Inc. 90 Bhoajaraj, Sandya Hewlett-Packard 91 Bhogavilli, Suresh Information Sciences Institute 92 Bierman, Andy Cisco Systems 93 Billau, Roger Re/Spec Inc. 94 Binder, Richard Corporation for National Research Initiatives 95 Bird, Lester Novell, Inc. 96 Blacka, David Network Solutions, Inc. 97 Blake, Steven IBM Corporation 98 Blanchet, Marc Viagenie inc. 99 Blondel, P.F.C. S.A.R.A. 100 Blumenthal, Uri IBM Corporation 101 Bohn, Gregg A.J. Boggs & Company 102 Boivie, Richard IBM 103 Bolot, Jean-Chrysostome INRIA Sophia Antipolis 104 Borden, Marty Bay Networks, Inc. 105 Borinski, Stan Realogic, Inc. 106 Borman, David Berkeley Software Design, Inc. 107 Boroumand, Javad USC/ISI 108 Boroumand, Sepideh NASA GSFC/HSTX 109 Bos, Erik-Jan SURFnet bv 110 Bosch, Brad Computer Associates 111 Boudreaux, John Daleen Technologies, Inc. 112 Boulianne, Luc McGill University 113 Bound, Jim Digital Equipment Corporation 114 Bournas, Redha IBM Corporation 115 Bowen, Ed IBM Corporation 116 Bowen, Rich NetEdge Systems, Inc. 117 Boyle, Jim The MITRE Corporation 118 Braden, Robert Information Sciences Institute 119 Bradescu, Roxana Sun Microsystems, Inc. 120 Bradner, Scott Harvard University 121 Bradshaw, Robert Daresbury Laboratory 122 Breed, Charles PGP, Inc. 123 Breslau, Lee Xerox PARC 124 Briceno, Marc DigiCash, Inc. 125 Bridgham, David Epilogue Technology Corporation 126 Brim, Scott Cornell University 127 Brisson, Barbara Sylvandale Middle School 128 Brittenson, Jan Sun Microsystems, Inc. 129 Brochu, Alain Plaintree Systems, Inc. 130 Brockners, Frank University of Cologne - ZPR 131 Brody, Lawrence AT&T 132 Brown, Anne Nortel Technology 133 Brown Klinger, Sheila Lucent Technologies 134 Browning, Jim ATMnet 135 Brownlee, Nevil University of Auckland 136 Buchko, Steven Newbridge Networks Inc. 137 Buclin, Bertrand AT&T International 138 Buddenberg, Rex Naval Postgraduate School 139 Burg, Fred AT&T 140 Burgan, Jeffrey Bay Networks, Inc. 141 Burke, Robert NetSpeed 142 Burle, Marlene Conferon, Incorporated 143 Burrescia, Joseph ESnet 144 Bush, Randy NSRC 145 Cabeca, Linda Bay Networks, Inc. 146 Cai, Yiqun Northern Telecom 147 Cain, Patrick BBN Corporation 148 Cajano, Alessandro Telecom Italia 149 Calcari, Susan InterNIC/University of Wisconsin 150 Calhoun, Pat US Robotics Access Corporation 151 Callaghan, Brent Sun Microsystems, Inc. 152 Callas, Jon Apple Computer, Inc. 153 Callon, Ross Cascade Communications Corp. 154 Calvert, Kenneth Georgia Institute of Technology 155 Campbell, Malcolm Shiva Europe Ltd. 156 Cansever, Derya GTE Laboratories, Inc. 157 Caradec, Jean-Philippe Hewlett-Packard France 158 Card, James Nokia Telecommunications 159 Carlos, Sennen Network General Corporation 160 Carlson, John University of Washington 161 Carlson, Richard Argonne National Laboratory 162 Carney, Michael Sun Microsystems, Inc. 163 Carpenter, Brian CERN 164 Carrel, David Cisco Systems 165 Carter, Stephen Novell, Inc. 166 Carugo, Marco CNET France Telecom 167 Case, Jeff SNMP Research, Inc. 168 Casner, Stephen Precept Software, Inc. 169 Caswell, Peter US Robotics 170 Cerveny, William Advanced Network and Services, Inc. 171 Chakrabarti, Samita Sun Microsystems Inc. 172 Chambliss, Warren Hewlett-Packard 173 Chan, Kin Net2Net Corporation 174 Chandika, Naga Apple Computer, Inc. 175 Chang, Shu-jen National Institute of Standards and Technology 176 Chang, Sunny Apple Computer, Inc. 177 Chang, Wo National Institute of Standards and Technology 178 Chapin, A. Lyman BBN Corporation 179 Chappell, Brett Naval Surface Warfare Center 180 Chefurka, Paul Plaintree Systems, Inc. 181 Chen, Carson Cisco Systems 182 Chen, Enke MCI Telecommunications Corporation 183 Chen, Jason Advanced Computer Communications 184 Chen, Yao-Min Fujitsu Laboratories of America 185 Cheng, Pau-Chen IBM Corporation 186 Cherenson, Andrew Liquid Audio, Inc. 187 Cheshire, Stuart Stanford University 188 Chiotasso, Chris BGS Systems, Inc. 189 Chiu, Alex Sun Microsystems, Inc. 190 Cho, Young-So E.T.R.I. 191 Chokhani, Santosh CynaCom Solutions, Inc. 192 Chon, Kilnam KAIST 193 Chong, Chi Cellswitch Networks 194 Chong Fong, Yoshiko Asia Pacific Network Information Center 195 Choresh, Eyal LanOptics Ltd. 196 Chow, Jeff AMD 197 Christy, Greg Cisco Systems 198 Chu, H. K. Jerry SunSoft, Inc. 199 Chung, Shiyun Fujitsu Business Communication Systems 200 Cicero, Tana University of the Pacific 201 Ciotti, Frank Telxon Corporation 202 Civanlar, Reha AT&T Research 203 Clark, Cynthia Corporation for National Research Initiatives 204 Clark, David Massachusetts Institute of Technology 205 Clark, Henry BBN Corporation 206 Clark, Wayne Cisco Systems 207 Clauberg, Axel University of Cologne 208 Clement, Taryn NCCOSC 209 Cobo, Luis Pontificia Universidad Catolica del Peru 210 Coburn, Jeff MCI Telecommunications Corporation 211 Cocquet, Patrick Dassault Electronique 212 Cohen, Danny Myricom, Inc. 213 Cohen, Josh Netscape Communications, Inc. 214 Cohen, Ron CDSI Ltd. 215 Cole, Bruce Cisco Systems 216 Cole, Robert Hewlett-Packard 217 Colella, Richard America Online 218 Collins, John Rutgers University Computing Services 219 Comay, David Sun Microsystems, Inc. 220 Compton, Kip Continental Cablevision 221 Cong, David Motorola 222 Conklin, Chris IBM Corporation 223 Conklin, Jim CREN 224 Connolly, Daniel Massachusetts Institute of Technology 225 Cook, Gordon Cook Report on Internet 226 Coolidge, Don Apple Computer, Inc. 227 Cooper, Bob Apple Computer, Inc. 228 Copeland, Ken U.S. Dept. of Veterans Affairs 229 Corbato, Steven University of Washington 230 Cordell, Peter BT Labs 231 Cordonnier, Alcatel 232 Corson, Scott University of Maryland 233 Corwin, BPS Inc. 234 Cotton, Christopher Apple Computer 235 Coya, Stephen Corporation for National Research Initiatives 236 Craren, Michael 3Com Corporation 237 Crawford, Matt Fermilab 238 Crawley, Eric Bay Networks, Inc. 239 Crispin, Kent 240 Crowcroft, Jon University College London 241 Crowe, David NERO Network 242 Cucchiara, Joan Bay Networks, Inc. 243 Cummings, David Hitachi Telecom, Inc. 244 Cunningham, Laura MCI Telecommunications Corporation 245 Curran, John BBN Corporation 246 Curtin, Bill Defense Information Systems Agency 247 Dabbous, Walid INRIA 248 Dacuycuy, LaVergne Fujitsu Business Communication Systems 249 Daigle, Leslie Bunyip Information Systems 250 Dam, Tru Network Systems Corporation 251 Dang, Winston University of Hawaii 252 Daniel, Ron Los Alamos National Laboratory 253 Daoud, Edward Fujitsu 254 Darnell, David SysTrends, Inc. 255 Davie, Bruce Cisco Systems 256 Davis, Glenn 257 Davis, Terry Boeing Information and Support Services 258 Davison, Michael cisco Systems 259 Dawkins, Spencer Nortel Technology 260 De Bry, Roger IBM Corporation 261 de la Salle, Pierre Compuware 262 De Winter, Jack Wildbear Consulting, Inc. 263 Deboo, Farokh Network Appliance 264 Del Torto, Dave PGP, Inc. 265 Delagi, Bruce Apple Computer, Inc. 266 DeMatteis, Cheryl The Aerospace Corporation 267 Demirtjis, Ann Sprint 268 Demizu, Noritoshi Sony Computer Science Laboratory, Inc. 269 Dillman, Neal NEC Corporation 270 Dinha, Francis NewCom Technologies,Inc. 271 Diot, Christophe INRIA 272 Dittler, Hans Braintec Network Consulting 273 Doi, Yuusuke Keio University 274 Donelan, Sean Data Research Associates, Inc. 275 Donner, Paul 276 Doraswamy, Naganand FTP Software, Inc. 277 Dosedal, Anke Cisco Systems 278 Doyle, Robert Berkeley Networks 279 Dreyer, Jon Sun Microsystems, Inc. 280 Droms, Ralph Bucknell University 281 Droz, Patrick IBM Research Laboratory 282 Drummond, Rik The Drummond Group 283 Dubray, Kevin Bay Networks, Inc. 284 Dumitru, Don Microsoft Corporation 285 Duncan, Ian Newbridge Networks Inc. 286 Duniho, Michael National Security Agency 287 Dunlap, Kevin MetaInfo, Inc. 288 Dunn, Jeffrey Hewlett-Packard 289 Dunstan, Adam Bay Networks, Inc. 290 Dupont, Francis INRIA Rocquencourt 291 Durand, Alain Institut de Mathmatiques Appliquees de Grenoble 292 Duros, Emmanuel INRIA 293 Dyer, John Terena 294 Dykes, Barry GENUITY 295 Earhart, Rob Carnegie Mellon University 296 Eastlake, Donald CyberCash, Inc. 297 Eddy, Rusty USC/ISI 298 Eidnes, Havard NORDUnet A/S 299 Eisler, Mike SunSoft, Inc. 300 Elkins, Michael Trusted Information Systems 301 Ellehauge, Peter Dansk Data Elektronik A/S 302 Ellerbee, Jeff ichat Inc. 303 Ellermann, Uwe DFN CERT 304 Ellesson, Ed IBM Corporation 305 Ellis, Gehrett Corporation for National Research Initiatives 306 Elz, Robert University of Melbourne 307 Elzur, Uri Intel 308 Emery, Nick AltaVista Internet Software 309 Engel, David Optical Data Systems, Inc. 310 England, Kent Six Sigma Networks 311 Erickson, Rodger Wall Data 312 Eriksson, Johnny KTHNOC 313 Erlinger, Michael The Aerospace Corporation 314 Esaki, Hiroshi Toshiba Corporation 315 Estrin, Deborah Information Sciences Institute 316 Fair, Erik Apple Computer, Inc. 317 Fajman, Roger National Institutes of Health 318 Falk, Bennett Sybase 319 Faltstrom, Patrik Tele2 320 Fang, Hsin National Institute of Standards and Technology 321 Farinacci, Dino Cisco Systems 322 Farrell, Lee Canon Information Systems 323 Fasano, Paolo CSELT 324 Faynberg, Igor Lucent Technologies 325 Featherstone, Dougal Shiva Europe Ltd. 326 Fenner, Bill Xerox PARC 327 Ferenz, David Price Waterhouse LLC 328 Ferguson, Dennis Juniper Networks, Inc. 329 Ferguson, Paul Cisco Systems 330 Fernandez, Antonio Bellcore 331 Ferracin, Joseph SITA/ITS 332 Fink, Robert Lawrence Berkeley Laboratory 333 Finkelson, Dale University of Nebraska 334 Finkelstein, David Xcert Software Inc. 335 Finlayson, Ross Live Networks, Inc. 336 Firenze, Mary NetManage, Inc. 337 Flanigan, William Defense Information Systems Agency 338 Fleshman, Michael Clearview Systems, Inc. 339 Ford, Peter Microsoft Corporation 340 Ford, Warwick 341 Forster, James Cisco Systems 342 Forsythe, Margaret Epilogue Technology Corporation 343 Fowler, Dave Newbridge Networks Inc. 344 Fox, Barbara Microsoft Corporation 345 Fox, Craig Cisco Systems 346 Fox, Daniel Bay Networks, Inc. 347 Francis, Paul NTT Software Laboratories 348 Frankhauser, Martine SITA 349 Frantz, William Periwinkle 350 Fraser, Barbara CERT Coordination Center 351 Fredette, Andre Bay Networks 352 Frei, Randy Com21 353 Friend, Robert Stac Electronics 354 Fritz, Thomas barili systems limited 355 Frogner, Gary Concurrent Technologies Corp. 356 Fruitbat, AT&T ISP 357 Fu, James Nokia Telecommunications 358 Fucarile, Lori Lotus Development Corporation 359 Fujikawa, Kazutoshi Boston University 360 Fujikawa, Kenji Kyoto University 361 Fujimoto, Shingo Fujitsu Laboratories of America 362 Fujiwara, Hiroyuki Hotline Integrator, Inc. 363 Fukushima, Hidehiro Hitachi Ltd. 364 Fuller, Vince BBN Corporation 365 Fumeno, Takanori Telecoment Inc. 366 Fung, Alan Hong Kong Supernet Ltd 367 Furuseth, Hallvard University of Oslo 368 Gadre, Jay Bell Atlantic 369 Gahrns, Mike Microsoft Corporation 370 Galvin, James CommerceNet 371 Ganguly, Anik Campbell Services Inc. 372 Garcia, Francisco Hewlett-Packard 373 Garrett, Mark Bellcore 374 Gartner, John TechWeb 375 Gastaud, Gerard Alcatel Telecom 376 Gastonde, Sunil Cisco Systems 377 Gellens, Randall Qualcomm Inc. 378 Gentile, Elizabeth University of Pennsylvania 379 Gerich, Elise @Home Network 380 Getchell, Arlene @Home Network 381 Ghanwani, Anoop IBM Corporation 382 Gibbs, W. Wayt Scientific American Magazine 383 Gillam, Shawn TimonWare, Inc. 384 Gilliam, William Hewlett-Packard 385 Gilmore, John Electronic Frontier Foundation 386 Girod, Lewis Massachusetts Institute of Technology 387 Glass, Steven FTP Software, Inc. 388 Glatting, Dennis CyberSafe Corporation 389 Goel, Vab Sprint 390 Goland, Yaron Microsoft Corporation 391 Gold, Harry NCCOSC 392 Goldsmith, Eric Applied Innovation, Inc. 393 Goller, Sean Carnegie Mellon University 394 Golshan, Ali 3Com Corporation 395 Gonzalez, Ricardo Hypertech Corporation 396 Good, Gordon Netscape Communications, Inc. 397 Gorden, Bengt KTHNOC 398 Goto, Yukinori Institute of Systems & Information Technology 399 Govindan, Ramesh Information Sciences Institute 400 Goyal, Mukul Sun Microsystems, Inc. 401 Graveman, Richard Bellcore 402 Gray, Eric 403 Gray, Terry University of Washington 404 Green, Mark @Home Network 405 Greene, Barry Cisco Systems 406 Greene, Jeremy Xedia Corporation 407 Greene, Maria Ascom Nexion, Inc. 408 Gressley, Christine University of Illinois 409 Grill, Thomas E-Systems 410 Grobelch, Mike Cisco Systems 411 Gross, Phillip MCI Telecommunications Corporation 412 Gudmundsson, Olafur Trusted Information Systems 413 Gudur, Smitha BMC Software 414 Gupta, Rajeev Trillium Digital Systems, Inc. 415 Gupta, Vipul Sun Microsystems, Inc. 416 Gurajapu, Suresh Trancell Systems, Inc. 417 Guse, Jimmy Lawrence Livermore National Labs 418 Guttman, Erik Sun Microsystems, Inc. 419 Hackwood, Tom MCI Telecommunications Corp. 420 Haggerty, William Cabletron Systems, Inc. 421 Hain, Tony Microsoft Corporation 422 Haller, Neil Bellcore 423 Halpern, Joel Newbridge Networks Inc. 424 Halpin, James US Robotics 425 Hamada, Takeo Fujitsu Laboratories 426 Hambridge, Sally Intel Corporation 427 Hamilton, Martin University of Technology, Loughborough 428 Handelman, Sigmund IBM Corporation 429 Handley, Mark USC/ISI 430 Haney, Craig Cando Consulting 431 Hanna, Donal Netskills 432 Hanna, Stephen 433 Hansen, Karen Ohio University 434 Hardie, Ted NASA Science Internet 435 Hares, Susan Merit Network, Inc. 436 Harkins, Dan Cisco Systems 437 Harrington, Dan Lucent Technologies 438 Harrison, Sari Apple Computer, Inc. 439 Hart, Andrew Hitachi, Ltd. 440 Hartrick, Tim Mentat, Inc. 441 Hasegawa, Yusaku Nara Institute of Science & Technology 442 Haskin, Dimitry Bay Networks, Inc. 443 Hasson, Marc Mentat, Inc. 444 Hastings, Thomas Xerox Corporation 445 Hathaway, Wayne Alteon Networks, Inc. 446 Hawkinson, John BBN Planet 447 Heard, C.M. VVNET, Inc. 448 Heberlein, Larry Seattle Lab 449 Hedberg, Roland SUNET 450 Heermann, Chris Internet MCI 451 Heffernan, Andy Cisco Systems 452 Heffner, Wendy U.C. Berkeley 453 Heidemann, John USC/ISI 454 Helmy, Ahmed USC/ISI 455 Hendricks, Dan Concurrent Technologies Corp. 456 Henkle, Pat US Robotics 457 Hernacki, Brian Netscape Communications, Inc. 458 Herron, Andrew Microsoft Corporation 459 Herzog, Shai IBM Corporation 460 Hetzel, Dorn HLC/Epoch Networks 461 Hien, Nguyen IBM Corporation 462 Higgs, Simon Higgs America 463 Hildenbrand, Bruce Sun Microsystems, Inc. 464 Hill, Paul Massachusetts Institute of Technology 465 Hilton, Rhonda Cable Television Laboratories 466 Hinden, Robert Ipsilon Networks, Inc. 467 Hirabaru, Masaki Merit Network, Inc. 468 Hirai, Chiaki Hitachi Ltd. 469 Hobby, Russ University of California, Davis 470 Hoffman, Don Sun Microsystems, Inc. 471 Hoffman, Paul Internet Mail Consortium 472 Hofmann, Jeanette WZB 473 Holcomb, Jeff Apple Computer, Inc. 474 Holdrege, Matt Ascend Communications 475 Hole, Steve The Esys Corporation 476 Holmstead, Stephen Hewlett-Packard 477 Honce, Jhon Hughes STX 478 Honnur, Virupaksh Cisco Systems 479 Hopkins, Gerry Bell Atlantic 480 Hopprich, John Cisco Systems 481 Hornby, Peter Unisys Corporation 482 Horneffer, Martin University of Cologne 483 Horowitz, Marc Cygnus Support 484 Hoschka, Philipp INRIA-Rodeo 485 Hosein, Javed Bay Networks, Inc. 486 Hoshi, Tohru Hitachi Ltd. 487 Houldsworth, Jack ISO/IEC JTC1/SC6 488 Howes, Tim Netscape Communications, Inc. 489 Huang, Chia-Li Nokia Telecommunications 490 Huber, Rick AT&T Bell Laboratories InterNIC 491 Huddle, Scott MCI Telecommunications Corporation 492 Huitema, Christian Bellcore 493 Huizer, Erik SURFnet Expertise Center 494 Humphrey, Keith IBM Corporation 495 Hunt, Bill VPNet Technologies, Inc. 496 Hur, Matt CyberSafe Corporation 497 Huss, Claude Matsushita Electric Works US R&D Laboratories 498 Huston, Geoff Telstra 499 Hutton, Anne Information Sciences Institute 500 Hyman, Marco 501 Iannella, Renato The University of Queensland 502 Ilgun, Koral Advanced Computer Communications 503 Inbar, Ofer The Left Bank Operation, Inc. 504 Inoue, Takashi Furukawa Electric Technologies 505 Inoue, Yoshinobu Fujitsu Laboratories Ltd. 506 Irey, Phil Naval Surface Warfare Center 507 Irlam, Gordon Cygnus Support 508 Isaacson, Scott Novell, Inc. 509 Ishida, Kiyoshi Internet Initiative Japan, Inc 510 Ishiguro, Kunihiro DML 511 Ishiyama, Masahiro Toshiba Corporation 512 Ito, Jodi-Ann University of Hawaii 513 Ito, Tadashi NTT Network Service Systems Laboratories 514 Iuso, Francesco Telecom Italia 515 Ivano, Guardini CSELT 516 Iversen, Ruben Dan Net 517 Iwata, Atsushi NEC Corporation 518 Izumiyama, Hidetaka Japan Satellite Systems Inc. 519 Jackowski, Steven NetManage, Inc. 520 Jacobi, Eli Siemens 521 Jacobs, Stuart GTE Laboratories, Inc. 522 Jacobsen, Ole ConneXions 523 Jaeggli, Joel University of Oregon 524 Jagannath, S. Bay Networks 525 Jakobs, Peter Novell 526 Jennings, Barbara Sandia National Laboratories 527 Jensen, Del Novell, Inc. 528 Jiang, Jonathan Bellcore 529 Jinzenji, Hiroshi NTT Human Interface Labs 530 Jippo, Yasuhito Fujisu Ltd 531 Johnson, Dale The MITRE Corporation 532 Johnson, Dave Carnegie Mellon University 533 Johnson, Jeff Cisco Systems 534 Johnson, Keith Federal Express Corporation 535 Johnson, Richard Cisco Systems 536 Johnson, Terry Develcon Electronics Ltd. 537 Johnson, Tony Network Systems Corporation 538 Jokubaitis, Vito AT&T 539 Jones, Douglas US West 540 Jones, Ken Bay Networks, Inc. 541 Jones, Rick Hewlett-Packard 542 Jordan, Kevin Control Data Systems, Inc. 543 Jork, Markus Digital Equipment GmbH 544 Joseph, Mark Attachmate Corporation 545 Juliano, Bryan NASA Ames Research Center 546 Jurg, Peter SURFnet bv 547 Kaat, Marijke SURFnet Expertise Center 548 Kalbfleisch, Carl On-Ramp Technologies, Inc. 549 Kalra, Sanjay Cisco Systems 550 Kaminski, Peter NanoSpace, Inc. 551 Kane Stewart, Monica NASA Science Internet 552 Kane, Tracy Cisco Systems 553 Kapil, Vivek Nortel Technology 554 Kapur, Arun Quadritek Systems, Inc. 555 Karawas, Georg AT&T Bell Laboratories 556 Karn, Phil Qualcomm Inc. 557 Karp, Brad USC/ISI 558 Kashima, Hiroaki Fujitsu Laboratories Ltd. 559 Kassi-Lahlou, Mohammed France Telecom 560 Kastenholz, Frank FTP Software, Inc. 561 Kato, Akira The University of Tokyo Computer Center 562 Katsube, Yasuhiro Toshiba Corporation 563 Kaufman, Charlie Iris Associates 564 Kawano, Tetsuo NTT Software Laboratories 565 Kaycee, Manu Paradyne Corporation 566 Kellenbenz, Jerry Apple Computer, Inc. 567 Kemp, David National Security Agency 568 Kennedy, John Novell, Inc. 569 Kennedy, L. Sean BBN Corporation 570 Kent, Stephen BBN Corporation 571 Kermode, Roger Massachusetts Institute of Technology 572 Kern, Ed DIGEX 573 Keromytis, Angelos University of Pennsylvania 574 Kessens, David USC/ISI 575 Key, Kenneth Cisco Systems 576 Khalandovsky, Michael FTP Software, Inc. 577 Khalsa, Kirpal Lotus cc:Mail 578 Khan, Shabbir Skylight Software, Inc. 579 Khare, Rohit World Wide Web Consortium 580 Khuon, Jake Merit Network, Inc. 581 Kikuchi, Hiroaki Tokai University 582 Kilfoil, John Intel Corporation 583 Kim, Charlie Apple Computer, Inc. 584 Kim, Dae Sik E.T.R.I. 585 Kim, David Apple Computer, Inc. 586 Kim, Dorian CICNet, Inc. 587 Kim, Hyogon Bellcore 588 Kim, Young-kyun National Computerization Agency 589 King, Ed Boeing Information and Support Services 590 Kirani, Shekhar Starfish Software 591 Kirchhoff, Julie Corporation for National Research Initiatives 592 Kirstein, Peter University College London 593 Kiyoshima, Naoki Ultra-high Speed Network & Computer Tech. Labs. 594 Klensin, John MCI Telecommunications Corporation 595 Klug, David International Network Services 596 Knuutila, Timo Nokia Research Center 597 Kobayashi, Masayuki CSR co., Ltd. 598 Koch, Harald Secure Computing Canada Ltd. 599 Koester, Greg Bay Networks, Inc. 600 Koga, Youichirou NEC Corporation 601 Komiya, Masakatsu Japan Satellite Systems Inc. 602 Kondo, Kuniaki Dream Train Internet, Inc. 603 Kopsa, Ray Cygnet 604 Korver, Brian Terisa Systems, Inc. 605 Koskelainen, Petri Nokia Research Center 606 Kossack, Nancy Bay Networks, Inc. 607 Kosters, Mark InterNIC 608 Kozdon, Peter Siemens Business Communication Systems 609 Krawczyk, John Bay Networks, Inc. 610 Krechmer, Ken Action Consulting 611 Kristol, David Lucent Technologies, Bell Laboratories 612 Krol, Edward University of Illinois Urbana 613 Krupczak, Cheryl Empire Technologies, Inc. 614 Ksinant, Vladimir Dassault Electronique 615 Kuang, Fidelia Apple Computer, Inc. 616 Kuehne, Mirjam RIPE NCC 617 Kumar, Sanjay First Virtual Corporation 618 Kumar, Vinay ICAST Communications, Inc. 619 Kumarasamy, Jay Novell, Inc. 620 Kunze, John UCSF Center for Knowledge Management 621 Kurakami, Hiroshi NTT Multimedia Networks Labs 622 Kurn, David Tandem Computers Inc. 623 Kuroda, Yasutsugu Fujutsu Laboratories Ltd. 624 Kuruppu, Pidibanda 3Com Corporation 625 Kwan, Stuart Microsoft Corporation 626 Kwan, William Jupiter Technology, Inc. 627 Labovitz, Craig Merit Network, Inc. 628 Lahaye, William Cabletron Systems, Inc. 629 Lahey, Kevin NASA Ames Research Center 630 Lai, Kevin Stanford University 631 Lai, William Microsoft Corporation 632 Lamond, Keith British Telecom North America 633 Land, David Apple Computer, Inc. 634 Lang, Ruth SRI International 635 Langeveld, Henk Sun Microsystems, Inc. 636 Langlois, Sylvain Electricite de France 637 Lanphier, Rob Progressive Networks 638 Larson, Greg MCI Telecommunications Corporation 639 Larsson, Jorgen Telia AB 640 Lasker, Valerie Precept Software, Inc. 641 Latzko, Alex Rutgers University Computing Services 642 LaVange, Don Novell, Inc. 643 Laviano, Vincent George Mason University 644 Lavu, Lava George Mason University 645 Lawler, John VPNet Technologies, Inc. 646 Lear, Eliot Silicon Graphics, Inc. 647 Lechner, Mikel NEC Technologies 648 Lee, C.J. Novell, Inc. 649 Lee, Dongho Kwangwoon University 650 Lee, Ho John Hewlett-Packard 651 Lee, Ronald Naval Research Laboratory 652 Lee, WeeSan USC/ISI 653 Leech, Marcus Nortel Technology 654 Leelanivas, Manoj Cisco Systems 655 Leinen, Simon SWITCH 656 Lemaire, Thomas 3Com Corporation 657 Lenggenhager, Thomas SWITCH 658 Lenharth, William University of New Hampshire 659 Leong, Ivan Pacific Internet Pte. Ltd. 660 Leong, Leon Network General 661 Leong, Lorna Singapore Telecom 662 Leroy, David FORE Systems 663 Leu, Brian Semaphore Communications Corp. 664 Leuca, Ileana AT&T Wireless 665 LeValley, Jim Macmillan Technical Publishing 666 Levi, Steven Microsoft Corporation 667 Levinson, Ed XIson, Inc. 668 Levy, Martin CMG Direct Interactive 669 Lewis, Chris Nortel Technology 670 Lewis, Edward Trusted Information Systems 671 Li, Hongqing Lucent Technologies 672 Li, Jian Sprint 673 Li, Tony Juniper Networks, Inc. 674 Li, Yan-Fa Hewlett-Packard 675 Liau, Wendy Oracle Corporation 676 Lichtensteiger, Reto Mitsubishi Electric ITA 677 Lim, David 3Com Corporation 678 Lim, Hock-Koon Pacific Internet Pte. Ltd. 679 Lim, Koon Sang Logic Group of Companies 680 Liman, Lars-Johan EBONE NOC 681 Lin, Elle Apple Computer 682 Lin, Felix 3Com Corporation 683 Ling, Lin SunSoft, Inc. 684 Ling, Wenken Bay Networks, Inc. 685 Linn, John OpenVision Technologies 686 Liu, Eric Cable & Wireless 687 Liu, Yuan-Kwei NASA Ames Research Center 688 Lo, Shau-Ping SunSoft, Inc. 689 Lord, Anne UUNET PIPEX 690 Love, E. Paul Internet Consulting of Vermont 691 Lu, Hui-Lan Lucent Technologies 692 Lu, Vivian NetEdge Systems, Inc. 693 Luciani, James Bay Networks, Inc. 694 Luke, Wanda Sterling Software 695 Lund, Craig Mercury Computer Systems, Inc. 696 Lundblade, Laurence Qualcomm Inc. 697 Lunow, Eric NEC Technologies 698 Luotonen, Ari Netscape Communications, Inc. 699 Lutz, Raymond Cognisys Inc. 700 Lynch, Peter Jyra Research Inc. 701 Maciocco, Christian Intel Corporation 702 Macker, Joseph US Naval Research Laboratory 703 Mader, Keith Bay Networks, Inc. 704 Madison, Eric ACSI 705 Madson, Cheryl Cisco Systems 706 Maeda, Kaori Hiroshima City University 707 Mah, Bruce University of California, Berkeley 708 Mahdavi, Jamshid Pittsburgh Supercomputing Center 709 Maher, Maryann USC/ISI 710 Malamud, Carl Massachusetts Institute of Technology 711 Malcolm, Andrew SCO 712 Malcolm, Joseph UUNET Technologies, Inc. 713 Malis, Andrew Ascom Nexion 714 Malkin, Gary Bay Networks, Inc. 715 Mallory, Tracy 3Com Corporation 716 Mamakos, Louis UUNET Technologies, Inc. 717 Mamros, Shawn FTP Software, Inc. 718 Maniatis, Petros Stanford University 719 Mankin, Allison Information Sciences Institute 720 Mannie, Eric Brussels University 721 Manning, Bill Information Sciences Institute 722 Manros, Carl-Uno Xerox Corporation 723 Marine, April NASA NIC 724 Markki, Outi Nokia Telecommunications 725 Marlow, David Naval Surface Warfare Center 726 Marsh, Ian Swedish Institute of Computer Science 727 Martillo, Joachim Telford Tools, Inc. 728 Martin, Antony Defense Research Agency 729 Martin, Cynthia Defense Information Systems Agency 730 Martin, John TERENA 731 Maruyama, Mitsuru NTT Software Laboratories 732 Masinter, Larry Xerox Corporation 733 Maslen, Thomas 734 Maston, Michael Cisco Systems 735 Mather, Tim Apple Computer, Inc. 736 Mathis, Matt Pittsburgh Supercomputing Center 737 Matsuda, Masahiro Fujitsu Labs Ltd. 738 Matsuhira, Naoki Fujitsu Laboratories Ltd. 739 Matsukata, Jun National Center for Science Information Systems 740 Matsune, Mio Network Information Service Co 741 Matsushita, Nobuo Bell Labs, Lucent Technologies 742 Matthew, Neil Shiva Europe Ltd. 743 Maughan, Douglas National Security Agency 744 Maw, Tim Stentor Resource Centre Inc. 745 Maxham, Mark Apple Computer, Inc. 746 Mayhew, Sheri Develcon Electronics 747 Mazzucato, Sandro Bunyip Information Systems 748 McBurnett, Neal Lucent Technologies, Bell Laboratories 749 McCann, Jack Digital Equipment Corporation 750 McCloghrie, Keith Cisco Systems 751 McCollum, Bob SAIC 752 McCooey, Jeremy University of New Hampshire 753 McDonald, Daniel Sun Microsystems, Inc. 754 McGarvey, John IBM Corporation 755 McGuire, William Cisco Systems 756 McManis, Chuck Free Gate Corporation 757 McMaster, Donna Cisco Systems 758 McMillan, Tom 3Com Primary Access 759 McPherson, Danny MCI Telecommunications Corporation 760 Mealling, Michael Network Solutions, Inc. 761 Medin, Milo @Home Network 762 Medlin, William Hewlett-Packard 763 Medrinsky, Ari CyberSafe Corporation 764 Medved, Patrick Computer Associates 765 Mehta, Mehul Apple Computer, Inc. 766 Melter, Cindy Cisco Systems 767 Mende, Robert Silicon Graphics, Inc. 768 Mendes, Jerry Mendes DataComm Insights 769 Merchant, Shashank Advanced Micro Devices 770 Metzger, Perry Piermont Information Systems 771 Meyer, David University of Oregon 772 Meyer, Gerry Shiva Limited 773 Michel, Scott The Aerospace Corporation 774 Miller, Kenneth StarBurst Communications 775 Miller, Quentin Microsoft Corporation 776 Miller, Thomas Siemens 777 Miller, W. Marcus Lawrence Livermore National Labs 778 Millington, Linda Control Data Systems, Inc. 779 Mills, Cynthia GTE Laboratories, Inc. 780 Minami, Masaki Keio University 781 Minnear, Robert Ipsilon Networks, Inc. 782 Minshall, Greg Ipsilon Networks, Inc. 783 Mirsky, Gregory Bay Networks, Inc. 784 Mistry, Danny Nortel Technology 785 Mitton, David Bay Networks, Inc. 786 Miyazaki, Randy Lantron Design, Inc. 787 Moats, Ryan AT&T Bell Laboratories InterNIC 788 Mobasser, Bahman Alcatel Telecom 789 Mogul, Jeffrey Digital Equipment Corporation 790 Mohta, Pushpendra CERFnet 791 Monfort, Martial Electricite et Gaz de France 792 Monk, Tracie DynCorp 793 Monsour, Robert Hi/fn, Inc. 794 Montenegro, Gabriel Sun Microsystems, Inc. 795 Montgomery, Doug National Institute of Standards and Technology 796 Moore, Keith University of Tennessee 797 Moore, Mike Hewlett-Packard 798 Moore, Richard Michigan State University 799 Moore, Robert IBM Corporation 800 Morgan, Bob Stanford University 801 Morla, Kim Pontificia Universidad Catolica del Peru 802 Morris, David barili systems limited 803 Morris, Jonathan Manchester Metropolitan University 804 Morse Johnson, Kelly Cisco Systems 805 Moscaritolo, Vinnie Apple Computer, Inc. 806 Moskowitz, Robert Chrysler Corporation 807 Mouradian, George AT&T Bell Laboratories 808 Moy, Diana US Robotics 809 Moy, John Cascade Communications Corp. 810 Mullaney, John Ziga Corporation 811 Mullaney, Patrick Cabletron Systems, Inc. 812 Muller, Claude Hewlett-Packard 813 Mundy, Russ Trusted Information Systems 814 Murai, Jun Keio University 815 Murphy, James Cisco Systems 816 Murphy, Patrick U.S. Geological Survey 817 Murphy, Sandra Trusted Information Systems 818 Murray, Cecil Campbell Services Inc. 819 Mutz, Andrew Hewlett-Packard 820 Myers, John Carnegie Mellon University 821 Myers, Michael Motorola SSTG 822 Myjak, Michael University of Central Florida 823 Na, Jung-jung National Computerization Agency 824 Nagami, Ken-ichi Toshiba Corporation 825 Nahm, Stephen Sun Microsystems, Inc. 826 Nair, Raj Ascom Nexion 827 Nakamura, Makoto The Furukawa Electronic Company, Ltd. 828 Nakamura, Osamu Keio University 829 Napjus, Erikas Carnegie Mellon University 830 Narayan, Vishy NASA Ames Research Center 831 Narayana, Raj Cable & Wireless 832 Narten, Thomas IBM Corporation 833 Nassi, Ike AppleSoft 834 Natale, Bob American Computer and Electronics Corporation 835 Nathaniel, Rina RAD Network Devices Ltd. 836 Naveh, Arad CDSI Ltd. 837 Neely, W. Shields National Semiconductor 838 Neer, Merle NRaD 839 Nelson, JoAnn NASA Science Internet 840 Nemeth, Evi University of Colorado 841 Nerenberg, Lyndon The Esys Corporation 842 Nesser, Philip Nesser & Nesser Consulting 843 Nessett, Dan 3Com Corporation 844 Neuman, Clifford Information Sciences Institute 845 Newman, Chris Innosoft International, Inc. 846 Newman, Daniel Innosoft International, Inc. 847 Ng, Fo Hong Kong Supernet Ltd. 848 Nguyen, Hai Raytheon E-Systems 849 Niazi, S. Chin Apple Computer, Inc. 850 Nichols, Kathleen Com21, Inc. 851 Nicklass, Orly RAD Data Communications 852 Nicklow, Doug Lycos, Inc. 853 Nielsen, Henrik World Wide Web Consortium 854 Niinomi, Tadafusa Fujitsu Laboratories Ltd. 855 Nikander, Pekka 856 Nishida, Takeshi NEC USA 857 Nix, Shannon Cisco Systems 858 Noerenberg, John Qualcomm Inc. 859 Nordmark, Erik Sun Microsystems, Inc. 860 Norton, Bill Merit Network, Inc. 861 Nowicki, William Silicon Graphics, Inc. 862 Nussbacher, Hank IBM Israel 863 Nygren, Svante 864 O'Brien, Robert Microsoft Corporation 865 O'Donoghue, Karen Naval Surface Warfare Center 866 O'Leary, David Cisco Systems 867 O'Leary, Peter Clear Blue Network Systems, Inc. 868 O'Malley, Timothy BBN Corporation 869 O'Neill, Alan BT Labs 870 Obraczka, Katia USC/ISI 871 Oehler, Michael National Security Agency 872 Ogawa, Jun Fujitsu Laboratories Ltd. 873 Oh, Soo-Hyoung Electronics & Telecomm. Research Institute 874 Ohta, Masataka Tokyo Institute of Technology 875 Okada, Shin PFU Limited 876 Okamoto, Toshio Toshiba Corporation 877 Ollikainen, Ari Sprint Advanced Technology Laboratories 878 Olsson, Bengt Ericsson Telecom AB 879 Onishi, Steven Bay Networks, Inc. 880 Ooka, Toshio Sumitomo Electric USA, Inc. 881 Oran, David Cisco Systems 882 Ordille, Joann Bell Labs, Lucent Technologies 883 Orman, Hilarie DARPA/ITO 884 Ostrowski, Stephen 3Com Corporation 885 Ouin, Edouard NIC France 886 Overby, Mary UNC-CH 887 Owen, Kraig Cisco Systems 888 Owens, Craig 3Com Corporation 889 Ozaki, Satoshi Toshiba Corporation 890 Pace, Wayne IBM Corporation 891 Paez-Ramirez, Alonso BT Labs 892 Pang, Joseph Starlight Networks 893 Pareth, Sameer C2Net 894 Paridaens, Oliver Universite Libre de Bruxelles 895 Parker, Steve SunSoft, Inc. 896 Parnes, Peter University of Lulea 897 Partan, Andrew WNA 898 Partington, Heath US Robotics 899 Pascoe, David 3Com Corporation 900 Patrick, Michael Motorola ISG 901 Patrick, Phil Motorola 902 Patton, Michael 903 Pereira, Roy TimeStep Corporation 904 Periyanna, Alagu Apple Computer, Inc. 905 Perkins, Charles IBM Corporation 906 Perkins, Colin University College London 907 Perkins, David SNMP Consultant 908 Perkins, Drew FORE Systems 909 Perlman, Radia Novell, Inc. 910 Perry, Yonadav CDSI Ltd. 911 Petke, Richard CompuServe, Inc. 912 Petronelli, Paul PALM Associates, Inc. 913 Pfenning, Thomas Microsoft Corporation 914 Phan, Bao Naval Research Laboratory 915 Pickering, Rob 3Com 916 Picoto, Carlos Universidade de Lisboa 917 Pierce, Greg Network Solutions, Inc. 918 Pilger, Alexander Siemens AG 919 Pink, Stephen Swedish Institute of Computer Science 920 Piper, Derrell Cisco Systems 921 Plunkett, Timothy Naval Surface Warfare Center 922 Plzak, Ray SAIC 923 Poger, Elliot Stanford University 924 Postel, Jon Information Sciences Institute 925 Presuhn, Randy BMC Software, Inc. 926 Prior, Mark connect.com.au pty ltd 927 Przygienda, Antoni FORE Systems 928 Pulito, Brian DataBeam Corporation 929 Pullen, J. Mark C3I Center 930 Pusateri, Tom Juniper Networks, Inc. 931 Quartuccio, Anthony Sterling Software 932 Quinto, Peter Novell 933 Rabin, Tal IBM Corporation 934 Rafferty, James Human Communications 935 Raghu, Jagannath Shomiti Systems, Inc. 936 Rajagopalan, Bala Bellcore 937 Rajagopal, Murali Fujitsu 938 Ramalingam, Jayakumar Novell, Inc. 939 Ramanan, P.S. Sprint 940 Ramanathan, Srinivas Hewlett-Packard 941 Ran, Xiaonong National Semiconductor Corp. 942 Randall, Karen AT&T Universal Card Services Corporation 943 Rank, Edward Bay Networks, Inc. 944 Ravikanth, Ravadurgam Nokia Research Center 945 Ray, Cathe Sun Microsystems, Inc. 946 Reed, Benjamin IBM Corporation 947 Reeder, David Portland State University 948 Reilly, Michael Cisco Systems 949 Reitsma, Rob Unisource Business Networks Netherlands B.V. 950 Rekhter, Yakov Cisco Systems 951 Renwick, John Ascend Communications 952 Rescorla, Eric Terisa Systems, Inc. 953 Resnick, Pete Qualcomm Inc. 954 Rex, Martin SAP AG 955 Reynolds, Joyce K. Information Sciences Institute 956 Richard, Pat Xcert Software Inc. 957 Richardson, John Intel Corporation 958 Rickard Bollentin, WendyOnTheInternet Magazine 959 Ridenour, Howard Apple Computer, Inc. 960 Riordan, John Swiss Telecom 961 Roberts, Ron Stanford University 962 Robertson, Kary StarBurst Communications 963 Robinson, David Sun Microsystems, Inc. 964 Robles, Frank NanoSpace, Inc. 965 Rodney, Steve Racal - Datacom 966 Roeck, Guenter Cisco Systems 967 Rogerson, Duncan University of London 968 Roinson, Michael Global One, China 969 Romanow, Allyn Sun Microsystems, Inc. 970 Romkey, John Blue Forest Research 971 Ronen, Elazar Radlinx Ltd. 972 Roos, Jan Sun Microsystems, Inc. 973 Roque Marques, Pedro Universidade de Lisboa 974 Rose, Marshall T. First Virtual Holdings Inc. 975 Rose, Strata Synopsys Inc. 976 Roselinsky, Milt Advanced Computer Communications 977 Rosselli, Michael AssureNet Pathways 978 Rossen, Ken MCI Telecommunications Corporation 979 Roussopoulos, Mema Stanford University 980 Routhier, Shawn Epilogue Technology Corporation 981 Royce, Kathy Bay Networks, Inc. 982 Rubens, Allan Merit Network, Inc. 983 Russell, Mick BT Labs 984 Ruth, Greg GTE Laboratories, Inc. 985 Rutkowski, Anthony General Magic, Inc. 986 Ryan, Gerard Bell Labs, Lucent Technologies 987 Ryutov, Tatyana USC/ISI 988 Saito, Takeshi Toshiba Corporation 989 Sajima, Takahiro Nihon Sun Microsystems, KK 990 Sakamoto, Hiromitsu NEC Corporation 991 Sakurai, Akihiro Sumitomo Electric Ind, Ltd. 992 Sales, Bernard Alcatel Telecom 993 Salo, Timothy Minnesota Supercomputer Center 994 Salomon, Marc University of California 995 Samanick, John Defense Information Systems Agency 996 Samberg, Larry Maker Communications 997 Sandberg, Ulla KTH 998 Sandick, Hal IBM Corporation 999 Saperia, Jon BGS Systems, Inc. 1000 Sarkezians, Hasmik US Robotics 1001 Sarmiento, Ramiro Sun Microsystems, Inc. 1002 Sauerbrey, Uwe ITK AG 1003 Sawyer, Wilson Bay Networks, Inc. 1004 Scano, John 3Com Corporation 1005 Schefstrom, Dick CDT 1006 Schertler, Mark Terisa Systems, Inc. 1007 Schey, John Europay International 1008 Schiller, Jeffrey Massachusetts Institute of Technology 1009 Schmechel, Christopher Sun Microsystems, Inc. 1010 Schneider, Mark National Security Agency 1011 Schneider, Wolfgang GMD 1012 Schnell, Steven Sprint 1013 Scholl, Reinhard Siemens AG 1014 Schulman, Martin Cisco Systems 1015 Schwartz, Mike @Home Network 1016 Scott, Gregor Defense Information Systems Agency 1017 Sedayao, Jeff Intel Corporation 1018 Seligson, John Bay Networks, Inc. 1019 Seraphin, Vinod Lotus Development Corporation 1020 Seto, Koichiro Hitachi Cable 1021 Shand, Mike Digital Equipment Co. Ltd. 1022 Sharon, Dan Plaintree Systems Inc. 1023 Shepard, Timothy BBN Corporation 1024 Shew, Stephen Nortel Technology 1025 Shieh, Shuching Bay Networks, Inc. 1026 Shimojo, Shinji Osaka University Computer Center 1027 Shionozaki, Atsushi Sony Computer Science Laboratory, Inc. 1028 Shirahama, Ritsuo Matsushita Graphic Communication Systems, Inc. 1029 Shirley, Fred Sanders 1030 Shiroshita, Teruji NTT Laboratories 1031 Shmulevsky, Mark ADP, Inc. 1032 Shobatake, Yasuro Toshiba Corporation 1033 Siadak, William Merit Network, Inc. 1034 Siegel, Dave RTD Systems & Networking, Inc. 1035 Siegel, Jon Object Management Group, Inc. 1036 Sikora, John AT&T Bell Laboratories 1037 Silbiger, Herman Applicom 1038 Siller, Curtis Lucent Technologies 1039 Simpson, William Computer Systems Consulting Services 1040 Singh, Jasdip InterNIC 1041 Sjodin, Peter SICS 1042 Skevington, Peter BT Labs 1043 Sklower, Keith University of California, Berkeley 1044 Sloane, Lance University of Michigan 1045 Sloane, Timon timonWare Inc. 1046 Smith, Andrew NeoSoft, Inc. 1047 Smith, Bradley University of California 1048 Smith, Carl Sun Microsystems, Inc. 1049 Smith, Jason The MITRE Corporation 1050 Smith, Mark Netscape Communications, Inc. 1051 Smith, Michael TIAA-CREF 1052 Smith, Pat Merit Network, Inc. 1053 Smith, Philip UUNET PIPEX 1054 Smith, Timothy IBM Corporation 1055 Sneed, Michael Connectware Inc. 1056 So, Benny Novell, Inc. 1057 So, Hon Pacific Bell 1058 Solensky, Frank FTP Software, Inc. 1059 Sollins, Karen Massachusetts Institute of Technology 1060 Solo, Dave BBN Corporation 1061 Solomon, Jim Motorola 1062 Sommerfeld, Bill Hewlett-Packard 1063 Spatscheck, Oliver University of Arizona 1064 Speakman, Tony Cisco Systems 1065 Speer, Michael Sun Microsystems, Inc. 1066 Spell, Charlie Cisco Systems 1067 Spreitzer, Mike Xerox PARC 1068 Sridhar, T. Future Communications Software 1069 Srinivasan, Suresh Thomson Technology Services Group 1070 Srinivasan, Andre Oracle Corporation 1071 Srinivasan, Vijay IBM Corporation 1072 Srisuresh, Pyda 3Com Corporation 1073 St. Johns, Michael @Home Network 1074 Staubach, Peter Sun Microsystems, Inc. 1075 Steenstrup, Martha BBN Corporation 1076 Stefferud, Einar Network Management Associates 1077 Stenerson, Derik Microsoft 1078 Stepanek, James The Aerospace Corporation 1079 Stephens, Tom Microsoft Corporation 1080 Stewart, Bob Cisco Systems 1081 Stewart III, John W. USC/ICI 1082 Stibler, Stephen IBM Corporation 1083 Stockman, Bernhard Telia AB 1084 Stuart, Wayne Cisco Systems 1085 Subramaniam, Anand Novell, Inc. 1086 Sugeno, Akio Telehouse International 1087 Sumikawa, Munechika Nara Institute of Science & Technology 1088 Sumner, Mark Motorola 1089 Sundell, Kenneth Ericsson Telecom AB 1090 Suzuki, Muneyoshi NTT Multimedia Networks Labs 1091 Svirk, John Internet MCI 1092 Swallow, George Cisco Systems 1093 Swan, Matti Helsinki Telephone Company Ltd 1094 Sweeney, Steven Apple Computer, Inc. 1095 Swink, Michael Sprint 1096 Takada, Toshiaki Dream Train Internet, Inc. 1097 Takamatsu, Satoshi NTT 1098 Takeuchi, Shohei NEC Corporation 1099 Takihiro, Masatoshi Hitachi Ltd. 1100 Tallerico, David The MITRE Corporation 1101 Talpade, Rajesh Georgia Institute of Technology 1102 Tanaka, Kei Internet Initiative Japan, Inc 1103 Tang, Cheng Hewlett-Packard 1104 Tang, Diane Stanford University 1105 Taniguchi, Kunihiro NEC USA 1106 Tardo, Joseph FreeGate Corporation 1107 Tatham, Martin BT Labs 1108 Taylor, Peter Mailbase, Newcastle University 1109 Tecot, Ed Apple Computer, Inc. 1110 Teplitsky, Jacob FORE Systems 1111 Teraoka, Fumio Sony Computer Science Laboratory, Inc. 1112 Terpstra, Marten Bay Networks, Inc. 1113 Terzis, Andreas UCLA 1114 Tesink, Kaj Bellcore 1115 Tesler, Lawrence Apple Computer, Inc. 1116 Thaler, David Merit Network, Inc. 1117 Thatcher, Michael Thatcher Consulting Services 1118 Thayer, Rodney Sable Technology Corporation 1119 Thomas, Matt Digital Equipment Corporation 1120 Thomas, Richard Nortel Technology 1121 Thomas, Robert Berkeley Networks 1122 Thomson, Susan Bellcore 1123 Thurlow, Robert Sun Microsystems, Inc. 1124 Tirilok, Prem Computer Associates 1125 Toborg, Scott SouthWestern Bell 1126 Tomimura, Eiji Sumitomo Electric USA, Inc. 1127 Tominaga, Akihiro Keio University 1128 Tomoda, Ichiro Bellcore 1129 Topolcic, Claudio BBN Corporation 1130 Touch, Joseph USC/ISI 1131 Tow, Agnes AT&T 1132 Towfiq, Mark Sun Microsystems, Inc. 1133 Toyoda, Kiyoshi Matsushita Graphic Communication Systems, Inc. 1134 Tracey, Karen IBM Corporation 1135 Tracy, Michael Sunsoft, Inc. 1136 Traina, Paul Juniper Networks, Inc. 1137 Tramposch, Albert World Intellectual Property Organization 1138 Travis, Ward Cisco Systems 1139 Treacy, Mark Access One 1140 Trest, Mike ATMnet 1141 Trostle, Jonathan CyberSafe Corporation 1142 Ts'o, Theodore Massachusetts Institute of Technology 1143 Tsuchiya, Kazuaki Hitachi Ltd. 1144 Tsukada, Koji Hitachi Ltd. 1145 Tsushima, Masahiko IBM Japan Ltd. 1146 Tung, Brian Information Sciences Institute 1147 Turaj, Nancy The MITRE Corporation 1148 Turner, Randy Sharp Laboratories of America 1149 Uehara, Keisuke Keio University 1150 Umeda, Masayoshi Nippon Telegraph and Telephone Corporation 1151 Valkenburg, Peter Terena 1152 Valloppillil, Vinod Microsoft 1153 Van Baalen, Jim ATMnet 1154 van den Berg, Gert AT&T Unisource 1155 Varnis, Harry Network Systems Corporation 1156 Vaudreuil, Gregory Octel Network Services 1157 Veach, Ross CICNet, Inc. 1158 Veenstra, Jack AT&T 1159 Vegesna, Srinivas Cisco Systems 1160 Veizades, John @Home Network 1161 Verina, Maria ICGEB 1162 Verrilli, Colin IBM Corporation 1163 Veum, Gary NASA Goddard Space Flight Center 1164 Villanueva, Deric WRQ 1165 Vinores, Cindy SunSoft, Inc. 1166 Vohra, Quaizar University of New Hampshire 1167 Vollbrecht, John Merit Network, Inc. 1168 Von Andel, Bob Allegro Software Development Corp. 1169 von Kaenel, Juerg IBM Corporation 1170 Vozza, Vincenzo Telecom Italia 1171 Vu, Anh FORE Systems 1172 Vu, Joseph FORE Systems 1173 Vu, Trinh Secure Computing Corp. 1174 Wada, Hiromi Matsushita Electric Industrial Company, Ltd. 1175 Waghray, Sanjay Sanjay Waghray 1176 Wagner, Michael Lockheed Martin 1177 Wahl, Mark Critical Angle, Inc. 1178 Walia, Lakhinder FORE Systems 1179 Wall, Matt Carnegie Mellon University 1180 Wallace, Dick Concord Communications, Inc. 1181 Wallace, Leland Apple Computer, Inc. 1182 Wang, Wei Merit Network, Inc. 1183 Ward, Carol NASA Ames Research Center 1184 Wasley, David University of California 1185 Watanabe, Ken Hitachi Ltd. 1186 Watanabe, Tomoo Nihon Cisco Systems 1187 Watanabe, Yoshinori Hotline Integrator, Inc. 1188 Waterman, Richard Madge Networks 1189 Watt, James Newbridge Networks Inc. 1190 Weaver, Elfed Defense Research Agency 1191 Webb, Jonathan SCO 1192 Webber, Bob PictureTel Corporation 1193 Wee, Tan Tin Internet Resrch & Devlpmt Unit 1194 Wei, Liming Cisco Systems 1195 Weiler, Samuel Carnegie Mellon University 1196 Weinrib, Abel Intel Corporation 1197 Weise, Bernd DeteBerkom GmbH 1198 Weiss, Howard SPARTA, Inc. 1199 Wellens, Chris InterWorking Labs, Inc. 1200 Wells, Amy Tracy InterNIC Net Scout 1201 Wesp, Jennifer Light Dreams Inc. 1202 Wessels, Duane Nat'l Lab for Applied Netwrk Research 1203 West, Jim Ciena Optical Communications 1204 Whelan, William Cabletron/Network Express 1205 Whipple, Mark Octel Network Services 1206 White, Gerry LANcity Corporation 1207 White, Kenneth IBM Corporation 1208 White, Paul University College London 1209 Whitehead, Jim University of California, Irvine 1210 Whittle, Rob Novell, Inc. 1211 Wiebe, Walter Federal Networking Council 1212 Williams, Carl Sun Microsystems, Inc. 1213 Williamson, Scott Network Solutions, Inc. 1214 Willis, Steven Bay Networks, Inc. 1215 Willits, Jim Hewlett-Packard 1216 Windrim, Mark Newstar Technologies 1217 Wine, Hal DTOR Consulting 1218 Wing, William Oak Ridge National Lab. 1219 Winkler, Linda Argonne National Laboratory 1220 Winseck, Michael Lucent Technologies 1221 Winter, Brian US Robotics 1222 Winters, Jerry Merit Network, Inc. 1223 Wise, Mary IBM 1224 Won, King Network General Corporation 1225 Wong, John Lotus cc:mail 1226 Woodcock, Bill Zocalo Engineering 1227 Woolf, Suzanne Information Sciences Institute 1228 Woundy, Richard Continental Cablevision 1229 Wray, John Digital Equipment Corporation 1230 Wright, F. Don Lexmark International, Inc. 1231 Wright, Graham Hummingbird Communications 1232 Wright, Russ Lawrence Berkeley Laboratory 1233 Wroclawski, John Massachusetts Institute of Technology 1234 Yaguchi, Tomokazu Telecomet Inc. 1235 Yamaguchi, Suguru Wide Project 1236 Yamamoto, Kazuhiko Nara Institute of Science & Technology 1237 Yamamoto, Shigeru Internet Initiative Japan Ltd. 1238 Yao, Kwang Hewlett-Packard 1239 Yarnell, Jeff Kaspia Systems, Inc. 1240 Yavatkar, Raj Intel Corporation 1241 Yen, Leemay 3Com Corporation 1242 Ying, Wen-Ping AT&T Wireless 1243 Ylonen, Tatu SSH Communications Security 1244 Yomashita, Hirotaka The Furukawa Electric Co. Ltd. 1245 Yoshida, Shin Sumitomo Electric USA, Inc. 1246 Yoshida, Toshiaki Werk mikro systems, Ltd. 1247 Young, Jeffrey MCI Telecommunications Corporation 1248 Young, Lloyd Lexmark International Inc. 1249 Yu, I-Hsiang GTE Laboratories, Inc. 1250 Yuan, Chin Pacific Bell 1251 Yuan, Jenny Cisco Systems 1252 Zaba, Stefek Hewlett-Packard 1253 Zao, John BBN Corporation 1254 Zeilstra, Koert Network Solutions, Inc. 1255 Zelenka, Jim Carnegie Mellon University 1256 Zhang, Leah AT&T Bell Laboratories 1257 Zhang, Lixia UCLA 1258 Zhang, Yi 3Com Corporation 1259 Zhang, Yongguang Hughes Research Laboratories 1260 Zhang, Zhaohui Bay Networks, Inc. 1261 Zhao, Bill AT&T 1262 Ziegast, Eric GTE Interactive Media 1263 Ziemba, Paul FORE Systems 1264 Zigmond, Dan Wink Communications 1265 Zorn, Glen Microsoft Corporation   Received: from ietf.org by ietf.org id aa29717; 22 Nov 96 15:51 EST Received: from ietf.org by ietf.org id aa29115; 22 Nov 96 15:47 EST To: IETF-Announce: ; cc: isdn-mib@cisco.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call2: ISDN Management Information Base to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 22 Nov 1996 15:47:24 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611221547.aa29115@ietf.org> The IESG has received a request from the ISDN MIB Working Group to consider the following two Internet-Drafts as Proposed Standards: 1. ISDN Management Information Base 2. Dial Control Management Information Base 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 December 20, 1996. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from ietf.org by ietf.org id aa06278; 22 Nov 96 17:26 EST Received: from ietf.org by ietf.org id aa05976; 22 Nov 96 17:23 EST To: IETF-Announce: ; Subject: REMINDER: Internet-Draft CUTOFF Date Date: Fri, 22 Nov 1996 17:23:39 -0500 Sender:ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9611221723.aa05976@ietf.org> The cut-off for Internet-Draft submissions prior to the San Jose IETF meeting is Tuesday, November 26, 1996 at 5pm ET. Internet-Drafts received after this time will not be announced nor made available in the Internet-drafts Directories. We will begin processing Internet-Draft submissions the week following the IETF meeting. Thank you for your understanding and cooperation. Please do not hesitate to contact me if you have any questions or concerns. Kind Regards, Cynthia Clark Internet-Drafts Administrator   Received: from cnri by ietf.org id aa07010; 23 Nov 96 15:32 EST Received: from ietf.org by CNRI.Reston.VA.US id aa21973; 23 Nov 96 15:32 EST Received: from ietf.org by ietf.org id aa06995; 23 Nov 96 15:32 EST Received: from [204.250.49.14] by ietf.org id aa06974; 23 Nov 96 15:32 EST Received: from mail.coupon.net (204.250.49.77) by mail.higgs.net with ESMTP (Apple Internet Mail Server 1.1.1); Sat, 23 Nov 1996 12:30:17 -0800 Received: from [204.250.49.20] by mail.coupon.net with ESMTP (Apple Internet Mail Server 1.1.1); Sat, 23 Nov 1996 12:30:12 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 23 Nov 1996 12:30:04 -0800 To: iesg@ietf.org, ietf@ietf.org, rfc-editor@isi.edu Sender:iesg-request@ietf.org From: elvis@graceland.com Subject: [Submission] Elvis Spoofing Please consider the following Internet-Draft for RFC status. Thank you. Internet-Draft Elvis The Stiff Category: Informational GRACELAND.COM Expires April 1, 1997 November 1996 Elvis Spoofing Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes Elvis Spoofing - the abuse of the email account (especially by Usenet users and system admninistrators), and introduces the death penalty as a deterent. 1. Funny, ha, ha - NOT It appears to be "cool", "funny", "cute" (and many other equally pathetically similar phrases) to send email to someone with the Sender or From address set to . Each person who does this is, of course, acting entirely in a totally original manner and doing "something that nobody has ever thought of before", and are thinking "boy, won't this cause a laugh". This misplaced belief causes the recipient to respond with an equally witty reply to the email address. This situation, while usually harmless, is still annoying because of the volume of email sent to the "elvis@graceland.com" account. Elvis The Stiff [Page 1] Internet Draft Elvis Spoofing November 1996 Usenet users are the most problematic group. They have test newsgroups to do this in. "Gee, I can post test mail and if I do it from , no one will know it's me!". This would be fine in itself, but each test newsgroup sends an email message saying the posting has been successful. So what you say? Email is harmless. The majority of *.test postings that the account receives contain copyright materials sold by major software companies. In addition, posting large (megabytes) messages to *.test newsgroups creates hundreds and hundreds of 32k "posting verification" messages to be sent to the From address. Not only is posting copyrighted material without the permission of the copyright owner illegal, the quantity of email generated places a severe strain on the intermediate internet infrastructure, as well as the GRACELAND.COM mail server(s). 2. What to do about this 1. DO NOT FORGE THE EMAIL ADDRESS 2. DO NOT POST COPYRIGHTED MATERIALS ANYWHERE ON THE INTERNET WITHOUT PERMISSION OF THE COPYRIGHT OWNER 3. Deterrent As a deterrent to this dilemma, anyone caught forging the email address will be given a virtual death penalty. They may find their access to the GRACELAND.COM domain permanently terminated. They may also find fines and even jail time being imposed by a court of law. 4. Appeals There is no appeals process. 5. Security Considerations There are no known security considerations beyond those of the perpetrators host being found. 10. Author's Address Elvis The Stiff email: elvis@graceland.com [This document expires April 1, 1997] Elvis The Stiff [Page 2]   Received: from ietf.org by ietf.org id aa07063; 23 Nov 96 15:34 EST Received: from [207.32.130.1] by ietf.org id aa06532; 23 Nov 96 15:18 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id OAA23583 for ; Sat, 23 Nov 1996 14:11:04 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBD948.7F2F4E60@webster.unety.net>; Sat, 23 Nov 1996 14:13:27 -0600 Message-ID: <01BBD948.7F2F4E60@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: "'ietf@ietf.org'" Subject: First? TRUE Root Name Server On Line Date: Sat, 23 Nov 1996 14:13:26 -0600 Encoding: 194 TEXT Source-Info: From (or Sender) name not authenticated. RE: First? TRUE Root Name Server On Line Name: NS2.NIC.EARTH IP Address: 199.5.157.5 When history is made on the Internet, it is important to briefly pause to recognize the event, and then move forward. Recently, one of the first TRUE Root Name Servers was put into service by John Palmer of The American Global Network, Inc. (AGN.NET) [1]. AGN is the owner and operator of the Top Level Domain Registry for the .EARTH and .USA TLDs. There are several factors which make this particular Root Name Server unique: 1. First and foremost, this appears to be the first, public access, Root Name Server which operates as a TRUE NON-RECURSIVE Root Server [2]. This is a requirement which is part of the new root name server guidelines which are being discussed by the IETF and other engineering groups. The 9 "popular" root name servers use by many ISPs do NOT meet these guidelines and resolve second level names.[3] True root name servers should do nothing but return references to TLD Name Servers [2], to reduce the scope of their control and their overall load. 2. The official name of this root name server is...NS2.NIC.EARTH. Because of the growing availability of access to the new Top Level Domains, such as .EARTH, it seems appropriate to begin naming the new Root Name Servers with the newly available names. 3. This Root Name Server can be added to the growing collection of Root 64 Name Servers which can be freely used by ISPs in their "root.cache" files. Because this Root Name Server is supported by a commercial enterprise, and not a hodge podge of volunteers (or the U.S. Government), ISPs can use this Root Name Server to help bring added stability and performance to their systems. [4] [5] In these times where confusion is being caused by groups who think that they can continue to debate the Top Level Domain issues primarily to prevent businesses (registries, ISPs, etc.) from making progress, it is important to recognize the efforts being made by business people to bring stability to the system and better service to consumers. As has been proven over and over during the past year, new commercial Top Level Domains are a reality along with new commercial Root Name Servers. The business community is rising to the challenge of building a better, more complete, and better engineered Internet now that the research and development is largely over. More commercial Root Name Servers are being installed and tested. As news of their introduction becomes available the "newdom" mailing list seems like the best place to keep everyone informed. The web interface for subscribing to that list can be found at: http://www.newdom.com/lists/ @@@@@@ [1] @@@@@@@@@ Result of: whois 199.5.156 The American Global Network, Inc. (NETBLK-RABBIT2) 31511 Harper Ave. St. Clair Shores, MI 48082 Netname: NETBLK-RABBIT2 Netblock: 199.5.156.0 - 199.5.157.0 Coordinator: Palmer, John P. (JP4736) jp@AGN.NET 800-456-0094 (FAX) 810-790-0156 Domain System inverse mapping provided by: SIMBA.AGN.NET 160.79.1.3 NS.AGN.NET 160.79.1.1 Record last updated on 18-Jan-96. @@@@@@ [2] @@@@@@@@@ Result of: dig @199.5.157.5 mcs.com any ; <<>> DiG 2.1 <<>> @199.5.157.5 mcs.com any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 9, Addit: 9 ;; QUESTIONS: ;; mcs.com, type = ANY, class = IN ;; AUTHORITY RECORDS: COM. 172800 NS A.ROOT-SERVERS.NET. COM. 172800 NS H.ROOT-SERVERS.NET. COM. 172800 NS B.ROOT-SERVERS.NET. COM. 172800 NS C.ROOT-SERVERS.NET. COM. 172800 NS D.ROOT-SERVERS.NET. COM. 172800 NS E.ROOT-SERVERS.NET. COM. 172800 NS I.ROOT-SERVERS.NET. COM. 172800 NS F.ROOT-SERVERS.NET. COM. 172800 NS G.ROOT-SERVERS.NET. ;; ADDITIONAL RECORDS: A.ROOT-SERVERS.NET. 518400 A 198.41.0.4 H.ROOT-SERVERS.NET. 518400 A 128.63.2.53 B.ROOT-SERVERS.NET. 518400 A 128.9.0.107 C.ROOT-SERVERS.NET. 518400 A 192.33.4.12 D.ROOT-SERVERS.NET. 518400 A 128.8.10.90 E.ROOT-SERVERS.NET. 518400 A 192.203.230.10 I.ROOT-SERVERS.NET. 518400 A 192.36.148.17 F.ROOT-SERVERS.NET. 518400 A 192.5.5.241 G.ROOT-SERVERS.NET. 518400 A 192.112.36.4 ;; Total query time: 29 msec ;; FROM: doorstep.unety.net to SERVER: 199.5.157.5 ;; WHEN: Sat Nov 23 10:59:28 1996 ;; MSG SIZE sent: 25 rcvd: 332 @@@@@@ [3] @@@@@@@@@ Result of: dig @a.root-servers.net mcs.com any ; <<>> DiG 2.1 <<>> @a.root-servers.net mcs.com any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 2, Auth: 2, Addit: 2 ;; QUESTIONS: ;; mcs.com, type = ANY, class = IN ;; ANSWERS: mcs.com. 172800 NS CEREBUS.mcs.com. mcs.com. 172800 NS KITTEN.mcs.com. ;; AUTHORITY RECORDS: mcs.com. 172800 NS CEREBUS.mcs.com. mcs.com. 172800 NS KITTEN.mcs.com. ;; ADDITIONAL RECORDS: CEREBUS.mcs.com. 172800 A 192.160.127.125 KITTEN.mcs.com. 172800 A 192.160.127.90 ;; Total query time: 88 msec ;; FROM: doorstep.unety.net to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Sat Nov 23 12:31:25 1996 ;; MSG SIZE sent: 25 rcvd: 128 @@@@@@ [4] @@@@@@@@@ Sample Traceroute to the NEW Root Server 1 chi00-s8-3.nap.net (206.54.225.89) 4.131 ms 4.066 ms 4.211 ms 2 core0-atm0.chi.nap.net (207.112.247.33) 4.013 ms 4.913 ms 4.309 ms 3 909.Hssi3-0.GW2.CHI1.ALTER.NET (137.39.130.173) 5.988 ms 5.735 ms 5.69 ms 4 Fddi1.CR1.CHI1.Alter.Net (137.39.38.193) 5.555 ms 6.243 ms 6.533 ms 5 106.Hssi3-0.GW1.DET1.Alter.Net (137.39.58.58) 14.022 ms 15.304 ms 15.322 ms 6 agn-gw.ALTER.NET (137.39.146.6) 18.409 ms 20.191 ms 19.351 ms 7 NS2.NIC.EARTH (199.5.157.5) 17.695 ms 18.895 ms 17.738 ms @@@@@@ [5] @@@@@@@@@ Sample Ping to NEW Root Server for above route. # ping -c 5 199.5.157.5 PING 199.5.157.5 (199.5.157.5): 56 data bytes 64 bytes from 199.5.157.5: icmp_seq=0 ttl=247 time=19.313 ms 64 bytes from 199.5.157.5: icmp_seq=1 ttl=247 time=20.071 ms 64 bytes from 199.5.157.5: icmp_seq=2 ttl=247 time=18.218 ms 64 bytes from 199.5.157.5: icmp_seq=3 ttl=247 time=19.377 ms 64 bytes from 199.5.157.5: icmp_seq=4 ttl=247 time=18.007 ms --- 199.5.157.5 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 18.007/18.997/20.071 ms @@@@@@@@@@@@@@@ -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa01691; 24 Nov 96 14:04 EST Received: from unixville.com by ietf.org id aa01400; 24 Nov 96 13:56 EST Received: by grep.unixville.com (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA03014; Sun, 24 Nov 1996 13:56:45 -0800 Date: Sun, 24 Nov 1996 13:56:44 -0800 (PST) Sender:ietf-request@ietf.org From: johan To: "'ietf@ietf.org'" Subject: PPP In-Reply-To: <01BBD948.7F2F4E60@webster.unety.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. I would like to contact any ISP's that are currently implementing PPP, preferably running PPP from a unix box. Or, I would like to contact any organization that is working with implementing PPP, and is VERY familiar TCP/IP. ( don't worry, I am not going to ask a question!) Thanks, - Johan   Received: from ietf.org by ietf.org id aa04738; 24 Nov 96 16:32 EST Received: from ng.netgate.net by ietf.org id aa04231; 24 Nov 96 16:19 EST Received: from [205.214.160.33] (d54.netgate.net [205.214.160.88]) by ng.netgate.net (8.8.3/8.6.9) with ESMTP id NAA22295; Sun, 24 Nov 1996 13:19:16 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <01BBD948.7F2F4E60@webster.unety.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Nov 1996 12:57:01 -0800 To: Jim Fleming Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: First? TRUE Root Name Server On Line Cc: "'ietf@ietf.org'" Source-Info: From (or Sender) name not authenticated. At 12:13 PM -0800 11/23/96, Jim Fleming wrote: >to recognize the event, and then move forward. Recently, one of the >first TRUE Root Name Servers was put into service by John Palmer =2E.. > 1. First and foremost, this appears to be the first, public > access, Root Name Server which operates as > a TRUE NON-RECURSIVE Root Server [2]. This is a For those who did not see this posted to the NANOG list and did not, therefore, see Paul Vixie's response, it's probably worth pointing out that the reference to "non-recursive" appears to be a mis-labeling of the distinctive point, namely that the server claiming to service the root domain does not also service other, i.e., second-level domains. The issue of recursion is entirely independent of where the data are stored. d/ ps. and for those who have not been following the saga, it's important to note that the server in question pertains to the Alternic activity and not to the official set of root servers. -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa06715; 24 Nov 96 17:29 EST Received: from [207.32.130.1] by ietf.org id aa06612; 24 Nov 96 17:26 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id QAA27918; Sun, 24 Nov 1996 16:18:59 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBDA23.890C0F00@webster.unety.net>; Sun, 24 Nov 1996 16:21:24 -0600 Message-ID: <01BBDA23.890C0F00@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Dave Crocker' Cc: "'ietf@ietf.org'" Subject: RE: First? TRUE Root Name Server On Line Date: Sun, 24 Nov 1996 16:21:22 -0600 Encoding: 93 TEXT Source-Info: From (or Sender) name not authenticated. On Sunday, November 24, 1996 2:57 PM, Dave Crocker[SMTP:dcrocker@brandenburg.com] wrote: @ At 12:13 PM -0800 11/23/96, Jim Fleming wrote: @ >to recognize the event, and then move forward. Recently, one of the @ >first TRUE Root Name Servers was put into service by John Palmer @ ... @ > 1. First and foremost, this appears to be the first, public @ > access, Root Name Server which operates as @ > a TRUE NON-RECURSIVE Root Server [2]. This is a @ @ For those who did not see this posted to the NANOG list and did @ not, therefore, see Paul Vixie's response, it's probably worth pointing out @ that the reference to "non-recursive" appears to be a mis-labeling of the @ distinctive point, namely that the server claiming to service the root @ domain does not also service other, i.e., second-level domains. The issue @ of recursion is entirely independent of where the data are stored. @ @ d/ @ @ ps. and for those who have not been following the saga, it's important to @ note that the server in question pertains to the Alternic activity and not @ to the official set of root servers. @ @ -------------------- @ Dave Crocker +1 408 246 8253 @ Brandenburg Consulting fax: +1 408 249 6205 @ 675 Spruce Dr. dcrocker@brandenburg.com @ Sunnyvale CA 94086 USA http://www.brandenburg.com @ @ Internet Mail Consortium http://www.imc.org, info@imc.org @ @ @ Since one of the IAHC members, is obliged to comment on Paul's comments...here is my reply... Paul, Because the 9 popular Root Name Servers are NOT configured as TRUE Root Name Servers, it is difficult to draw fine distinctions between recursion, iteration, referrals, etc. If you check pages 31 and 32 of the book, "DNS and BIND", by Paul Albitz & Cricket Liu you will not serveral statements which attempt to differentiate between "recursion" and "iteration". In one statement, they state, "In recursion, a resolver sends a recursive query to a name server...The queried name server is then obliged to respond with the requested data...The name server can't just refer the querier to a different name server, because the query was recursive." Because the 9 popular Root Name Servers are not configured as TRUE Root Name Servers (and also do not meet other basic Root Name Server requirements), it is a coincidence that they are able to avoid recursion and return information for the .COM, .NET, .ORG, .EDU, .MIL, .ARPA, etc. domains. When they do this, they appear to look like a "recursive" to another server or resolver that is using their services. I hope that we can agree that TRUE Root Name Servers should only return "referrals" to other Top Level Domain Name Servers. In the above book, this is considered "Iterative Resolution" because "a name server simply gives the best answer it already knows... it makes its best attempt to give the querier data that will help it continue the resolution process". While I continue to find it interesting that you always lower yourself to personal attacks, in apparent violation of the IETF Code of Conduct, I am not sure that your attacks help to educate Internet users. Your attacks also do not focus on the real problem which is the fact that the 9 popular Root Name Servers, used by many ISPs, are not properly configured as TRUE Root Name Servers. If you like, we can leave the complex terms, recursion and iteration out of these discussions. In the future, we can refer to TRUE Root Name Servers, as those that meet the technical requirements for being called a TRUE Root Name Server. If and when the 9 popular Root Name Servers ever meet these requirements, then we can refer to them as TRUE Root Name Servers, and everyone will understand that they do not return replys which appear to be the result of a recursive search, thus giving one the impression that they are recursive. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa08012; 24 Nov 96 18:27 EST Received: from ng.netgate.net by ietf.org id aa07923; 24 Nov 96 18:25 EST Received: from [205.214.160.33] (d40.netgate.net [205.214.160.74]) by ng.netgate.net (8.8.3/8.6.9) with ESMTP id PAA28049 for ; Sun, 24 Nov 1996 15:24:45 -0800 (PST) X-Sender: Message-Id: In-Reply-To: <01BBDA23.890C0F00@webster.unety.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Nov 1996 15:07:37 -0800 To: "'ietf@ietf.org'" Sender:ietf-request@ietf.org From: Dave Crocker Subject: RE: First? TRUE Root Name Server On Line Source-Info: From (or Sender) name not authenticated. At 02:21 PM -0800 11/24/96, Jim Fleming wrote: >On Sunday, November 24, 1996 2:57 PM, Dave >Crocker[SMTP:dcrocker@brandenburg.com] wrote: >@ that the reference to "non-recursive" appears to be a mis-labeling of the >@ distinctive point, namely that the server claiming to service the root >@ domain does not also service other, i.e., second-level domains. The issu= e >@ of recursion is entirely independent of where the data are stored. >Because the 9 popular Root Name Servers are NOT configured >as TRUE Root Name Servers, it is difficult to draw fine distinctions >between recursion, iteration, referrals, etc. The goal of separating functional roles of root server vs. TLD server onto different physical machines has nothing to do with validity of either function but, instead, is only a matter of performance. Things have worked just dandy for roughly a decade, configured as they are, but Internet scaling dictates separating them to spread the load. The fact they my web page resides on a machine that is shared by some hundreds or thousands of other customers for my provider does not in any way make it less than "my" web pages. This distinction between architectural and functional role vs. the implementation detail of placement for that role is a common source of error. >In one statement, they state, "In recursion, a resolver sends a >recursive query to a name server...The queried name server is >then obliged to respond with the requested data...The name >server can't just refer the querier to a different name server, because >the query was recursive." Didn't FEEL "obliged" as much as desirous of clarifying some basic techncial points that appears to be causing confusion. Again, the error that seems to accrue, here, is the belief that one must actually go to a separate physical machine for the recurson (or redirection) to be meaningful. It isn't. >I hope that we can agree that TRUE Root Name Servers should >only return "referrals" to other Top Level Domain Name Servers. The use of referral vs. recursion is a matter of operational performance, particularly related to the desire in having intermediate data cached at the server or by the client. It has nothing to do with officialness, correctness, etc. Having a single server carry multiple sections of the DNS is common and important practise for efficient operation. That's the reason a 'zone' in the DNS does not map one-to-one with a subdomain. d/ (read the last line, please) ---------------------------- Dave Crocker, Director +1 408 246 8253 Internet Mail Consortium (f) +1 408 249 6205 127 Segr=E9 Place dcrocker@imc.o= rg Santa Cruz, CA 95060 USA http://www.imc.org Also: IAHC member, expressing personal opinions   Received: from ietf.org by ietf.org id aa09765; 24 Nov 96 19:15 EST Received: from [207.32.130.1] by ietf.org id aa09477; 24 Nov 96 19:13 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id SAA28062; Sun, 24 Nov 1996 18:05:56 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBDA32.79F15660@webster.unety.net>; Sun, 24 Nov 1996 18:08:21 -0600 Message-ID: <01BBDA32.79F15660@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Dave Crocker' , "'ietf@ietf.org'" Subject: RE: First? TRUE Root Name Server On Line Date: Sun, 24 Nov 1996 18:08:19 -0600 Encoding: 53 TEXT Source-Info: From (or Sender) name not authenticated. On Sunday, November 24, 1996 5:07 PM, Dave Crocker[SMTP:dcrocker@imc.org] wrote: @ At 02:21 PM -0800 11/24/96, Jim Fleming wrote: @ @ >I hope that we can agree that TRUE Root Name Servers should @ >only return "referrals" to other Top Level Domain Name Servers. @ @ The use of referral vs. recursion is a matter of operational @ performance, particularly related to the desire in having intermediate data @ cached at the server or by the client. It has nothing to do with @ officialness, correctness, etc. Having a single server carry multiple @ sections of the DNS is common and important practise for efficient @ operation. That's the reason a 'zone' in the DNS does not map one-to-one @ with a subdomain. @ @ d/ @ The past is the past...we need to work on the future... As the "administrative" boundaries of the Domain Name System get drawn more precisely, (i.e. along the lines of which company's bank account is being increased) I think that you will find that the "engineering" boundaries follow. It is interesting that Network Solutions, Inc. has been able to get volunteers to provide free infrastructure for them while they collect the fees and pocket the profits. In the real business world, this will not likely last very long. In the end, I predict that governments will step into the picture to take advantage of the "taxing" opportunities which exist and which have been demonstrated by NSI and NSF. When that occurs, I suspect that you will see very fine administrative lines, and engineering efficiencies will not be allowed to violate the laws they enact. As those sorts of discussions occur in other forums, it is important to educate non-engineering people about which IETF decisions were made because of historical evolution, which decisions were made for efficiency reasons, and which decisions were made simply to maintain control and not to allow these taxing bodies to get into the game and to make sure that other states, besides Virginia benefit from domain name taxes. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa11279; 24 Nov 96 20:10 EST Received: from ng.netgate.net by ietf.org id aa11197; 24 Nov 96 20:07 EST Received: from [205.214.160.33] (d102.netgate.net [205.214.160.140]) by ng.netgate.net (8.8.3/8.6.9) with ESMTP id RAA02837 for ; Sun, 24 Nov 1996 17:07:17 -0800 (PST) X-Sender: Message-Id: In-Reply-To: <01BBDA32.79F15660@webster.unety.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Nov 1996 16:38:58 -0800 To: "'ietf@ietf.org'" Sender:ietf-request@ietf.org From: Dave Crocker Subject: RE: First? TRUE Root Name Server On Line Source-Info: From (or Sender) name not authenticated. At 04:08 PM -0800 11/24/96, Jim Fleming wrote: >As the "administrative" boundaries of the Domain Name System >get drawn more precisely, (i.e. along the lines of which company's "more" precisely? How could it be more precise than it is now? >It is interesting that Network Solutions, Inc. has been able to get >volunteers to provide free infrastructure for them while they collect NSI had nothing to do with it. The volunteers have been running the root services long before NSI came on the scene, and that's perhaps 8 years beforehand. I think NSI's server is the first one to be explicitly funded. d/ (read the last line, please) ---------------------------- Dave Crocker, Director +1 408 246 8253 Internet Mail Consortium (f) +1 408 249 6205 127 Segr=E9 Place dcrocker@imc.o= rg Santa Cruz, CA 95060 USA http://www.imc.org Also: IAHC member, expressing personal opinions   Received: from ietf.org by ietf.org id aa12517; 24 Nov 96 20:51 EST Received: from [207.32.130.1] by ietf.org id aa12418; 24 Nov 96 20:49 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id TAA28260; Sun, 24 Nov 1996 19:41:42 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBDA3F.DB4D6D60@webster.unety.net>; Sun, 24 Nov 1996 19:44:07 -0600 Message-ID: <01BBDA3F.DB4D6D60@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: 'Dave Crocker' , "'ietf@ietf.org'" Cc: "'bobm@NIC.DDN.MIL'" , "'jamesf@ARL.MIL'" , "'koda@ISI.EDU'" , "'marcel@NSIPO.NASA.GOV'" , "'markk@NETSOL.COM'" , "'matti@COMEDIA.SE'" Cc: "'paul@VIX.COM'" , "'psinet-domain-admin@PSI.COM'" , "'sneeri@NI.UMD.EDU'" Subject: RE: First? TRUE Root Name Server On Line Date: Sun, 24 Nov 1996 19:44:06 -0600 Encoding: 74 TEXT Source-Info: From (or Sender) name not authenticated. On Sunday, November 24, 1996 6:38 PM, Dave Crocker[SMTP:dcrocker@imc.org] wrote: @ At 04:08 PM -0800 11/24/96, Jim Fleming wrote: @ >As the "administrative" boundaries of the Domain Name System @ >get drawn more precisely, (i.e. along the lines of which company's @ @ "more" precisely? How could it be more precise than it is now? @ Most people view the DNS system as a rather strict hierarchy with 3 levels (4 outside the U.S. and popular TLDs). As you have pointed out the implementation does not always match whct people think exists. I am just suggesting that in the future, I have a feeling that the implementation will more closely match people's perceptions, because those perceptions will have "tax boundary" implications. Consider the *possible* following scenario: 1. A State passes a law requiring ISPs in that State to use State owned and operated Root Name Servers. 2. Those Root Name Servers point at State owned and operated .COM TLD Name Servers. 3. The State owned and operated .COM TLD Name Servers "selectively" point to Company-owned SLD Name Servers, based on whether the company has registered with that State's "tax collection" agency, just like they now register with the InterNIC tax collection agency located in the State of Virginia. P.S. Do you think that IBM would not pay $50 to 50 States to make sure that ibm.com was visible to the most people possible ? Maybe we should ask them...:-) @ >It is interesting that Network Solutions, Inc. has been able to get @ >volunteers to provide free infrastructure for them while they collect @ @ NSI had nothing to do with it. The volunteers have been running @ the root services long before NSI came on the scene, and that's perhaps 8 @ years beforehand. I think NSI's server is the first one to be explicitly @ funded. @ @ d/ @ OK...my apologies...let me restate that last part.... It is interesting that the volunteers who have always provided free infrastructure, prior to NSI setting up a "tax collection" agency (or toll booth) continue to provide this free infrastructure and have not recognized that they are being used. It is also interesting that NSI has not used some of the tens of millions of dollars, which do not seem to have any public accounting, to deploy a wide-spread network of root name servers to ensure that they are not dependent on the whims of these volunteers. As one of the root name server operators stated, if things do not change by mid January 1997, then he is going to take matters into his own hands. I would think that NSI and the rest of the Internet would be concerned about the instability that this could cause. I aould assume that they would invest some of their profits to prevent some disruption. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from cnri by ietf.org id aa26482; 25 Nov 96 5:23 EST Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa11045; 25 Nov 96 5:23 EST Received: (from daemon@localhost) by external.BSDI.COM (8.8.3/8.8.2) id DAA25527 for telnet-ietf-list@bsdi.com; Mon, 25 Nov 1996 03:21:06 -0700 (MST) Received: from dtc.rankxerox.co.uk (mailgate.dtc.rankxerox.co.uk [194.217.143.1]) by external.BSDI.COM (8.8.3/8.8.2) with ESMTP id DAA25524 for ; Mon, 25 Nov 1996 03:21:03 -0700 (MST) Received: (from robin@localhost) by dtc.rankxerox.co.uk (8.7.4/8.7.3) id KAA27149; Mon, 25 Nov 1996 10:10:54 GMT Date: Mon, 25 Nov 1996 10:10:54 +0000 (GMT) From: Robin Carey To: "Theodore Y. Ts'o" cc: telnet-ietf@bsdi.com Subject: Re: Telnet Protocol In-Reply-To: <9611221652.AA03822@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 22 Nov 1996, Theodore Y. Ts'o wrote: > Date: Fri, 22 Nov 1996 08:53:23 +0000 (GMT) > From: Robin Carey > > I would be most grateful if you could help me with some information, > with regard to the TELNET protocol. > Could you please advise me as to which RFC documents provide a > complete and up-to-date specification for the TELNET protocol (including > the individual options) ? > > There unfortunately no one document that describes the full telnet > protocol. If you ftp to ds.internic.net, and look in /rfc, you will see > all of the various RFC's. (Or you can go to some other RFC repository, > if you wish). RFC 854 contains the base telent specification. It does Yeh..... Also RFC-1123, section 3 seems to further RFC-854 ... > not contain the various telnet options, however. For those you will > have to look up all of the various telnet options in the rfc-index. > This is inconvenient, I know, but there is no comprehensive list of > which options you should really implement if you're interested in > interoperability. > > Examining the freely available telnet source code from BSD is a good > start for seeing which telnet options are commonly accepted by most > implementations on the internet. Yes, I've already done that. But as you say, there is no one ``TELNET-RFC-SPEC'' which contains a list of all the currently appropriate TELNET RFC's ... > > I have heard rumour that the telnet-ietf are in the process of > creating a RFC for TELNET encryption ... has this been released yet ? > > No, not yet, and that's mostly my fault. (ENOTIME....) I can give you > drafts of what the base telnet encryption specification (and the > attendant Kerberos V4 and V5 suboptions), if you like. Let me know and > I'll e-mail them out. Yeh, if it's no problem I'd appreciate it ! Thanks ! > > - Ted >   Received: from ietf.org by ietf.org id aa27602; 25 Nov 96 6:27 EST Received: from sigma.itu.ch by ietf.org id aa27317; 25 Nov 96 6:19 EST Received: from MR.ITU.CH by ITU.CH (PMDF V5.0-6 #16074) id <01IC9GMY6YBK94F91S@ITU.CH> for ietf@ietf.org; Mon, 25 Nov 1996 12:14:00 +0200 Received: with PMDF-MR; Mon, 25 Nov 1996 10:12:05 +0200 MR-Received: by mta TIES.MUAS; Relayed; Mon, 25 Nov 1996 10:12:05 +0200 MR-Received: by mta TAU; Relayed; Mon, 25 Nov 1996 11:12:08 +0200 Disclose-recipients: prohibited Date: Mon, 25 Nov 1996 10:12:05 +0200 Sender:ietf-request@ietf.org From: shaw Subject: US Touts Duty-Free Internet In-reply-to: <2.2.32.19960718204218.0099c534@pop3hub.is.chrysler.com> To: ietf Message-id: <6105121225111996/A59913/TAU/11ABCB0C0400*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Importance: normal Priority: normal UA-content-id: 11ABCB0C0400 X400-MTS-identifier: [;6105121225111996/A59913/TAU] Hop-count: 1 Source-Info: From (or Sender) name not authenticated. Thought this would be of significantly high interest to the list to warrant posting it. The article should appear in the press within the next few days... Bob ******************************** Forwarded with permission - Copyright 1996 Communications Week International. U.S. touts duty-free Internet BY KENNETH HART In a bid to abolish trade barriers and boost exports, the United States is proposing to declare the Internet a global duty-free zone for all electronic goods and services. But the plan, which proponents said would expand the market for electronic 'content,' has been criticized by governments wary of 'info-imperialism' and politicking. The new policy, designed to pre-empt any attempts to impose customs duties or other new Net taxes, will apply to all electronic items and services purchased across the Internet in the United States and abroad, said senior White House officials. The proposal, to be discussed with senior European Commission representatives at a meeting in Brussels next week and with world trade representatives shortly afterwards, is part of a broad administration public policy initiative by President Bill Clinton's administration to spur electronic commerce across the Internet. Under the proposal, only goods and services bought and delivered electronically would be exempt from tariffs and taxes. Material items, such as a modem purchased electronically from a Web site, will not be included. The proposal--which may ultimately require the backing of a Republican congress as well as international approval--will almost certainly face stiff resistance from local state governments and other countries that fear electronic commerce over the Internet will erode their current revenue base. It has received qualified support from leading figures in the Internet community, who caution against overly-ambitious political intervention. But free trade enthusiasts and U.S. software companies called the move a giant leap towards the creation of a stable, predictable market for global electronic commerce. "This is marvellous," said Tony Rutkowski, vice president for Internet business development at software maker General Magic Inc., of Sunnyvale, California. Industry observers say the U.S. initiative, to be lead by Ira Magaziner, senior White House policy adviser to President Bill Clinton, throws the spotlight on the difficulty that sovereign governments have in tracking, let alone taxing, exchanges of data across the global network of networks. This borderless, lawless nature has been a key element in the Internet's phenomenal global growth. But there is now a widespread belief that, if the Internet is to be accepted as the medium for electronic commerce around the world, it needs a coherent set of legal guidelines and principles. The White House's sweeping Internet initiative represents a new, "minimalist" role that the U.S. government intends to play, senior officials said. Instead of firmly regulating the Internet according to the traditional telecommunications model, White House officials said government emphasis will be on ensuring users can conduct business within a proper commercial environment. Exact details on the Internet electronic initiative remain to be worked out. For example, a few officials said the duty-free proposal may only be applicable to goods and services valued under $50. The aim is to ensure that Net commerce is unencumbered by customs duties or any forms of taxation such as a bit tax, where charges would be levied in proportion to the amount of data flowing across communications networks, which is currently under consideration in Europe. The Clinton initiative is not specifically aimed at abolishing value added tax for electronic goods--European opposition to such a move is likely to be fierce. But Washington officials acknowledge that the U.S.'s tacit admission that taxes are difficult to levy over the Net may undermine countries currently in favor of imposing VAT. Nevertheless, U.S. officials argue that a free-trade zone will boost overall transactions, increasing state revenues through conventional income taxes. If adopted, the duty-free zone will increase sales of software and other items of intellectual propriety over the Internet, said Peter Harter, public policy counsel at Netscape Communications Corp., of Mountain View, California. In addition to the duty-free proposal, a white paper outlining initiatives, to be published in its final form by next spring, will also contain policy guidelines in areas such as data privacy, electronic payment, intellectual property rights and technical standards. Already the Clinton administration has submitted drafts containing some of the key ideas to the World Trade Organization, the World Intellectual Propriety Organization, the Organization of Economic Cooperation and Development (OECD), and other organizations, as the basis for multinational negotiations, said senior officials. It hopes its white paper will dovetail with a variety of Internet-related issues already being tackled by the OECD, including taxation and encryption, said officials at the Paris-based organization. A high-level European Community workgroup is preparing a report on the technical and economic feasibility of taxing flows of digital information, said Luc Soete, professor of international economics at the University of Maastricht and director of an economic research group that works on Internet taxation issues. Privately, however, several top EC officials said they oppose the idea. One senior EC official said the Clinton administration's Internet trade proposal smacks of "U.S. info-imperialism" specifically designed to aggressively boost exports. Not so, said General Magic's Rutkowski. He said a duty-free zone may ultimately help companies, especially those from developing nations, to compete more effectively around the world to the disadvantage of U.S. firms. Other governments are expected to react apprehensively to the new proposal when it is fully discussed at the World Trade Organization meeting in Singapore early next month. Another observer called the proposal a political gesture--the unofficial launch of U.S. vice president Al Gore's presidential campaign for the year 2000. Leading Internet figures, meanwhile, welcomed the government's proposal--albeit with some skepticism. The duty-free proposal is "a step in the right direction," said Scott Bradner, director of Harvard University's network device test lab in Cambridge, Massachusetts, and a leading member of the Internet Engineering Task Force (IETF). But he and other IETF members warned against any "top-down approach" by policy makers who are often unfamiliar with the Internet's technology and operations. While policy makers and diplomats try to hammer out global Internet agreements, many in the Internet community suggest a more pragmatic approach.   Received: from ietf.org by ietf.org id aa28517; 25 Nov 96 6:55 EST Received: from proxy1.ba.best.com by ietf.org id aa28426; 25 Nov 96 6:52 EST Received: from home96a (beansed.vip.best.com [205.149.180.52]) by proxy1.ba.best.com (8.8.3/8.8.3) with SMTP id DAA09037 for ; Mon, 25 Nov 1996 03:50:00 -0800 (PST) Message-Id: <3.0.32.19961125034702.006bec28@best.com> X-Sender: beansed2@best.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Mon, 25 Nov 1996 03:47:11 -0800 To: ietf Sender:ietf-request@ietf.org From: Ken Nakagama Subject: Re: US Touts Duty-Free Internet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. As a commerce based company, I can say that taxation on the net is inevitable. Oh this is near and dear to us ! Consider that for now the IRS has given up on taxation at the federal level but don't discount the state and local level as its their bread and butter. For example.., Airline flight mileage programs are not directly taxed because the IRS cannot figure out how to trace and track it. As a result, the cost-benefit isn't there so they gave up. As noted in a Money magazine article, the computing resources required to track internet commerce transactions would approach those utilized by the Department of Defense. With the IRS Computer Modernization program in dire straits after a $7 billion investment.., (and little results) we see that they can't handle normal tax returns.., much less the internet. Per Government Computer News, the GAO has recommended that another organization (such as DOD) oversees their Project due to the lack of Large IS management ability at IRS. We can then extrapolate that being the IRS is considered the world's most efficient taxation extraction system.., the rest of the world is decades behind. As more commerce migrates to the web and busy lifestyles make web commerce a more attractive choice, government is unlikely to resist the temptation of more tax revenue. On the bright side it just may not happen widely in our lifetime.., ; ) Ken *--------------------------------------* Ken Nakagama (408) 370-9250, 888-864-0155 pager Market TeleMedia Inc. www.opcenter.com *-------------------------------------------*   Received: from ietf.org by ietf.org id aa29513; 25 Nov 96 7:20 EST Received: from bells.cs.ucl.ac.uk by ietf.org id aa29413; 25 Nov 96 7:18 EST Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 25 Nov 1996 12:16:29 +0000 To: ietf , J.Crowcroft@cs.ucl.ac.uk Subject: Re: US Touts Duty-Free Internet In-reply-to: Your message of "Mon, 25 Nov 1996 03:47:11 PST." <3.0.32.19961125034702.006bec28@best.com> Date: Mon, 25 Nov 1996 12:16:25 +0000 Message-ID: <5726.848924185@cs.ucl.ac.uk> Sender:ietf-request@ietf.org From: Jon Crowcroft Source-Info: From (or Sender) name not authenticated. lets see now, after value added networks? Value Added Tax? now where is most of the net nowdays? and which way does most the information go? sounds like US is doing this in the interests of not simply LOSING revenue to the people it sells information too...... great idea: i say that we in the EU should tax the sale of information to europe by the US - you know it makes cents....or is that Ecu? (maybe i'm being ecumenical with the truth here....:-) of course, we might need to distinguish quality from quantity, then the business flow might be the opposite way:-( jon   Received: from ietf.org by ietf.org id aa07086; 25 Nov 96 9:49 EST Received: from ietf.org by ietf.org id aa05713; 25 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: http-wg@cuckoo.hpl.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-http-state-mgmt-05.txt, .ps Date: Mon, 25 Nov 1996 09:38:21 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250938.aa05713@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : HTTP State Management Mechanism Author(s) : D. Kristol, L. Montulli Filename : draft-ietf-http-state-mgmt-05.txt, .ps Pages : 19 Date : 11/22/1996 This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set-Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.) Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-http-state-mgmt-05.txt". Or "get draft-ietf-http-state-mgmt-05.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-http-state-mgmt-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-http-state-mgmt-05.txt". Or "FILE /internet-drafts/draft-ietf-http-state-mgmt-05.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122163335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-state-mgmt-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-http-state-mgmt-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122163335.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07658; 25 Nov 96 9:51 EST Received: from ietf.org by ietf.org id aa05581; 25 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: int-serv@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-intserv-mib-04.txt Date: Mon, 25 Nov 1996 09:37:44 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250937.aa05581@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Services Working Group of the IETF. Title : Integrated Services Management Information Base Author(s) : F. Baker, J. Krawczyk Filename : draft-ietf-intserv-mib-04.txt Pages : 27 Date : 11/22/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-intserv-mib-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-mib-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-intserv-mib-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122104128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-intserv-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-intserv-mib-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122104128.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07669; 25 Nov 96 9:51 EST Received: from ietf.org by ietf.org id aa05597; 25 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-mib-04.txt Date: Mon, 25 Nov 1996 09:37:47 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250937.aa05597@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : RSVP Management Information Base Author(s) : F. Baker, J. Krawczyk Filename : draft-ietf-rsvp-mib-04.txt Pages : 80 Date : 11/22/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-mib-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-mib-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-mib-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122104410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-mib-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122104410.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07684; 25 Nov 96 9:52 EST Received: from ietf.org by ietf.org id aa05672; 25 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-simple-ipsec-api-00.txt Date: Mon, 25 Nov 1996 09:38:09 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250938.aa05672@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Simple IP Security API Extension to BSD Sockets Author(s) : D. McDonald Filename : draft-mcdonald-simple-ipsec-api-00.txt Pages : 9 Date : 11/22/1996 In order to take advantage of the IP Security Architecture [Atk95], an application should be able to tell the system what IP-layer security services it needs to function with some degree of confidence. A simple API that also allows simple security association policy to be set is presented here. This document descends from earlier work performed in the U. S. Naval Research Laboratory's IPv6 and IP security implementation [AMPMC96]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcdonald-simple-ipsec-api-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-simple-ipsec-api-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mcdonald-simple-ipsec-api-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122151515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-simple-ipsec-api-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-simple-ipsec-api-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122151515.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07638; 25 Nov 96 9:52 EST Received: from ietf.org by ietf.org id aa05656; 25 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: srv-location@tgv.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-svrloc-service-scheme-00.txt Date: Mon, 25 Nov 1996 09:38:07 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250938.aa05656@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Location Protocol Working Group of the IETF. Title : The service: URL Scheme Author(s) : E. Guttman Filename : draft-ietf-svrloc-service-scheme-00.txt Pages : 29 Date : 11/22/1996 The service: URL scheme is used to provide service access information for arbitrary network services. These URLs provide an extensible framework for client based network software to obtain configuration information required to make use of network services. A service: URL may be accompanied by a set of well defined attributes which define the characteristics of the service. These attributes may convey protocol configuration information to client software or service characteristics meaningful to end users. This document describes how to define and standardize new service types and attributes for use with the service: scheme and provides examples. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-svrloc-service-scheme-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-service-scheme-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-svrloc-service-scheme-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122150255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-service-scheme-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-service-scheme-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122150255.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07689; 25 Nov 96 9:52 EST Received: from ietf.org by ietf.org id aa05690; 25 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-durand-ipv6prefix-00.txt Date: Mon, 25 Nov 1996 09:38:18 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250938.aa05690@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 network prefix notation Author(s) : A. Durand, J. Richier Filename : draft-durand-ipv6prefix-00.txt Pages : 2 Date : 11/22/1996 This memo propose a text representation of IPv6 network prefixes. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-durand-ipv6prefix-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-durand-ipv6prefix-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-durand-ipv6prefix-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122150739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-durand-ipv6prefix-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-durand-ipv6prefix-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122150739.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07664; 25 Nov 96 9:52 EST Received: from ietf.org by ietf.org id aa05535; 25 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cordell-success-00.txt Date: Mon, 25 Nov 1996 09:37:31 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250937.aa05535@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Universal Call/Conference Establishment Sequence - (SUCCESS) Author(s) : P. Cordell Filename : draft-cordell-success-00.txt Pages : 39 Date : 11/25/1996 Currently in the Internet there are a number of call control protocols, each of them tailored to their own special applications. This includes SDP for session announcement, SIP and SCIP for session invitation and Q.931 used in H.323. None of these is likely to be turned into a generic call control protocol. Q.931 is limited to point-to-point calls. SDP and SIP do not include close down phases which are important if calls are being charged for on a timed basis or gateways are involved. Nor do they support supplementary services such as transfer. This proposal addresses these issues by defining a protocol based on a new conference control paradigm (referred to as the hello-hello paradigm) that can be used to create and control conferences from simple point-to-point calls, to large `broadcasts' and all call models in between. Both real-time peer-to-peer conversational models and client-server streaming models are catered for in the protocol so that all forms of real-time stream can feature in a conference. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cordell-success-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-cordell-success-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-cordell-success-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125090627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cordell-success-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-cordell-success-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125090627.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07657; 25 Nov 96 9:52 EST Received: from ietf.org by ietf.org id aa05725; 25 Nov 96 9:38 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-tls@w3.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-tls-passauth-00.txt Date: Mon, 25 Nov 1996 09:38:26 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250938.aa05725@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Addition of Shared Key Authentication to Transport Layer Security (TLS) Author(s) : D. Simon Filename : draft-ietf-tls-passauth-00.txt Pages : 5 Date : 11/22/1996 This document presents a shared-key authentication mechanism for the TLS protocol. It is intended to allow TLS clients to authenticate using a secret key (such as a password) shared with either the server or a third-party authentication service. The security of the secret authentication key is augmented by its integration into the normal SSL/TLS server authentication/key exchange mechanism. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-passauth-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-tls-passauth-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-tls-passauth-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122161008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-passauth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-passauth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122161008.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07650; 25 Nov 96 9:52 EST Received: from ietf.org by ietf.org id aa05565; 25 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: int-serv@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-intserv-guaranteed-mib-02.txt Date: Mon, 25 Nov 1996 09:37:42 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250937.aa05565@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Services Working Group of the IETF. Title : Integrated Services Management Information Base Guaranteed Service Extensions Author(s) : F. Baker Filename : draft-ietf-intserv-guaranteed-mib-02.txt Pages : 14 Date : 11/22/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-intserv-guaranteed-mib-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-guaranteed-mib-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122103847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-intserv-guaranteed-mib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122103847.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07674; 25 Nov 96 9:52 EST Received: from ietf.org by ietf.org id aa05501; 25 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wright-ipp-req-00.txt Date: Mon, 25 Nov 1996 09:37:16 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250937.aa05501@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for WEB Browser-based Internet Printing Author(s) : F. Wright Filename : draft-wright-ipp-req-00.txt Pages : 8 Date : 11/22/1996 This document describes the requirements for WEB browser-based Internet printing protocol. It describes the end-user, operator and administrator wants and needs in the context of printing documents from a variety of sources. These sources include standard desktop applications (e.g. word processors, spreadsheets, and browsers), documents selected by reference (e.g. URL) and documents created by batch or background applications. Additionally, requirements for light-weight printer status and management and job status and management services will be discussed. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wright-ipp-req-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-wright-ipp-req-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-wright-ipp-req-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122101149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wright-ipp-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-wright-ipp-req-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122101149.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa08186; 25 Nov 96 9:54 EST Received: from ietf.org by ietf.org id aa05624; 25 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-interserver-00.txt Date: Mon, 25 Nov 1996 09:37:56 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250937.aa05624@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : An Inter-server Protocol for DHCP Author(s) : R. Droms Filename : draft-ietf-dhc-interserver-00.txt Pages : 8 Date : 11/22/1996 The DHCP protocol is designed to allow for multiple DHCP servers, so that reliability of DHCP service can be improved through the use of redundant servers. To provide redundant service, all of the DHCP servers must be configured with the same information about assigned IP addresses and parameters; i.e., all of the servers must be configured with the same bindings. Because DHCP servers may dynamically assign new addresses or configuration parameters, or extend the lease on an existing address assignment, the bindings on some servers may become out of date. The DHCP inter-server protocol provides an automatic mechanism for synchronization of the bindings stored on a set of cooperating DHCP servers. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-interserver-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-interserver-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-interserver-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122110448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-interserver-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-interserver-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122110448.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa08980; 25 Nov 96 10:08 EST Received: from ietf.org by ietf.org id ab05625; 25 Nov 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-authentication-03.txt Date: Mon, 25 Nov 1996 09:37:54 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611250937.ab05625@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Authentication for DHCP Messages Author(s) : R. Droms Filename : draft-ietf-dhc-authentication-03.txt Pages : 8 Date : 11/22/1996 The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-authentication-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-authentication-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-authentication-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122105532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-authentication-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-authentication-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122105532.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10522; 25 Nov 96 10:32 EST Received: from [207.32.130.1] by ietf.org id aa10355; 25 Nov 96 10:28 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id JAA00649; Mon, 25 Nov 1996 09:20:57 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBDAB2.4DFA3E20@webster.unety.net>; Mon, 25 Nov 1996 09:23:23 -0600 Message-ID: <01BBDAB2.4DFA3E20@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: ietf , 'Jon Crowcroft' Subject: RE: US Touts Duty-Free Internet Date: Mon, 25 Nov 1996 09:23:21 -0600 Encoding: 116 TEXT Source-Info: From (or Sender) name not authenticated. On Monday, November 25, 1996 6:16 AM, Jon Crowcroft[SMTP:J.Crowcroft@cs.ucl.ac.uk] wrote: @ @ @ lets see now, @ after value added networks? Value Added Tax? @ @ now where is most of the net nowdays? and which way does most the @ information go? @ @ sounds like US is doing this in the interests of not simply LOSING @ revenue to the people it sells information too...... @ @ great idea: @ i say that we in the EU should tax the sale of information to europe by the @ US - you know it makes cents....or is that Ecu? (maybe i'm being @ ecumenical with the truth here....:-) @ @ of course, we might need to distinguish quality from quantity, then @ the business flow might be the opposite way:-( @ @ jon @ @ @ COMpanies registering in the .COM domain face a double-edge sword. On one hand it is a COMmon place that many people are learning to understand as, "the" place to be, on the Internet. On the other hand, COMpanies could find that the lucrative .COM domain will likely attract government taxing bodies and it could become very expensive to maintain a global .COM domain. COMpanies that register in .COM should look down the road at the long term evolution of the Domain Name System that could occur as various government taxing bodies get a better understanding of how Internet COMmerce works. In order to fully understand this possible evolution, one has to have a fundamental understanding of how Domain Name Servers work. The following terms are used to help clarify the different "types" of servers, some of which can exist on the same hardware platform and in the same software process. Root Name Server Primarily directs ISP Name Servers to TLD Name Servers TLD Name Server Primarily directs ISP Name Servers to SLD Name Servers SLD Name Server Primarily directs ISP Name Servers to Web and Mail Servers ISP Name Server Primarily serve customers' stub resolvers and interface with all of the above name servers in a frequency that decreases from the top (Root) to the Bottom (SLD and below) because of caching. As noted in the above list, the ISP Name Servers are the workhorses of the Internet. Subscribers use those servers which operate on behalf of the subscribers to interface with the rest of the Root, TLD, and SLD Name Servers. In the current implementation, there are 9 "popular" Root Name Servers (8 in the U.S.) that ISPs use to locate TLD Name Servers. At the present time, because of history, the .COM domain is supported on those same 9 servers, thus making them overly busy. Many of the other TLDs (especially country TLDs) have their own TLD Name Servers. In the future, the .COM support will likely be moved to an independent set of servers. In the above system, SLD Name Servers are typically supplied by the domain owner or some service bureau that provides domain name services. Whether the .COM domain is supported directly on the Root Name Servers or a separate TLD Name Server is largely transparent to the SLD Name Servers and the ISP Name Servers. One of the reasons why owning a .COM domain could become expensive, is that an easy taxing opportunity exists in the above system. If various regions with government taxing bodies step into the above picture and interpose their own .COM TLD servers, then they can control which SLD Name Servers are easily visible in that region. Once a government takes that step, then they can request that .COM owners register their SLD Name Servers in their registry and could require not only a fee, but also (in State Governments) a Certificate of Incorporation as a Foreign Corporation as well as necessary business licenses for that region. Other than the additional fees, there would be no impact on the owner of the domain name. They could use the same SLD Name Servers for all of the regions where they are registered. All of the .COM TLD Name Servers could point to the same SLD Name Servers. As State governments and various countries learn more about the Internet, it will be interesting to see where they position themselves in the COMmercial world. Anyone that has run a multi-state or mult-national company can verify, that State governments have spent large sums searching for taxes from out of State companies who do business in their States. The taxing opportunities on the Internet are starting to become more clear. This is especially true now that the NSF and the InterNIC have established a model for the domain name taxing system, which has raised millions of dollars. All States and countries need to do is to duplicate that model and collect the revenues. If that occurs, then .COM may not be "THE" place to be after all. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa11450; 25 Nov 96 10:44 EST Received: from cnri by ietf.org id aa11233; 25 Nov 96 10:42 EST Received: from [192.41.104.196] by CNRI.Reston.VA.US id aa05442; 25 Nov 96 10:41 EST Received: from twain (twain.dai.ed.ac.uk [192.41.104.199]) by postbox.dai.ed.ac.uk (8.6.13/8.6.12) with ESMTP id PAA03042; Mon, 25 Nov 1996 15:20:28 GMT Date: Mon, 25 Nov 1996 15:20:28 GMT Message-Id: <1397.199611251520@twain> Sender:ietf-request@ietf.org From: Michael Ramscar Subject: CFP: EuropIA 97 To: BENKING@faw.uni-ulm.de, armin@mic.atr.co.jp, bota@race.u-tokyo.ac.jp, N.G.Cross@open.ac.uk, sugi@rd.nacsis.ac.jp, Peter.Thomas@csm.uwe.ac.uk, jwworth@jupiter.informatik.umu.se, N.Oloughlin@lcad.ac.uk, schmid@dfki.uni-kl.de, hoffmann@osiris.iemar.tuwien.ac.at, ed1@mdx.ac.uk, rafaelp@cogs.susx.ac.uk, M.North@lcad.ac.uk, WGODWIN@chelt.ac.uk, S.M.Loke@u.ac.shef.ac.uk, Pcrofts@chelt.ac.uk, Guy.VanBelle@rug.ac.be, knishi@mic.atr.co.jp, J.L.Leach@maths.bath.ac.uk, sbell@bmth.ac.uk, E.Slarke@unsw.edu.au, EricT@cov.ac.uk, yevin@sam.imash.ras.ru, tccc@cs.umass.edu, IETF@CNRI.Reston.VA.US, fokus-user@fokus.gmd.de, giga@tele.pitt.edu, performance@haven.epm.ornl.gov, rem-conf@es.net, ccrc@dworkin.wustl.edu, cabernet-general@newcastle.ac.uk, osimcast@bbn.com, hipparch@sophia.inria.fr, multicomm@cc.bellcore.com, sigmedia@bellcore.com, alg@comm.toronto.edu, atm@bbn.com, cost237-transport@comp.lancs.ac.uk, xtp-relay@cs.concordia.ca, reres@laas.fr, enternet@bbn.com, isadsoc@fokus.gmd.de, urban@egd.igd.fhg.de Organisation: EuropIA 97 Source-Info: From (or Sender) name not authenticated. ----------------------- CONFERENCE ANNOUNCEMENT & CALL FOR PAPERS ----------------------- europia`97 @EDINBURGH ------------------ DESIGN and the NET ------------------ Sixth International Conference on the Application/Implications of Computer Networking in Architecture, Construction, Design, Civil Engineering and Urban Planning Sixime Confrence Internationale sur les applications/implications des nouvelles technologies de communication en Architecture, Construction, Design, Ingnierie et Planification urbaine 2-3 April 1997 Department of Architecture University of Edinburgh Edinburgh EH1 1JZ Scotland http://www.caad.ed.ac.uk/europia/ Instructions For Authors http://www.caad.ed.ac.uk/europia/formats.html This conference brings together researchers in design, architecture, engineering, construction management, cognitive science, computer science, artificial intelligence, sociology, geography and education as well as industry partners, practitioners and other users of networked communications. The focus for this diverse group is design - how we design with and for networked communications - appropriating recent exciting developments in medium and broad band local area and wide area networks, new protocols for interaction and new communications tools such as Web browsers and network aware multimedia tools. Topics covered include: design and ... World Wide Web applications Distributed design decision support Collaborative systems Information and communication spaces Distributed interactive multimedia Virtual reality on the net Java applications Architecture of cyberspace Role of the Internet in industry and in practice Intranets Networked digital video Desktop video conferencing Computer supported collaborative work Virtual studios Virtual offices Spatial and social implications of networked communications Distributed Geographical Information Systems / Urban Information Systems Distributed facilities management Design of networked multimedia La sixieme conference internationale EuropIA propose une rencontre entre des professionnels et des chercheurs (science de l'education, sciences de traitement de l'information, science cognitive, science sociale, etc.) impliques dans une problematique favorisant ou defavorisant l'usage des nouvelles technologies de communications en Architecture, Construction, Design, Ingenierie et Planification urbaine. Par le biais de cette rencontre, nous souhaitons solliciter et developper diverses approches conceptuelles et exprimentales relevant de cette problematique. L'accent sera mis sur l'emergence de nouveaux protocoles d'interaction et de communications dus a l'usage des outils multimedia d'une part et a la mise en place des autoroutes de l'informations (WWW). Themes abordes Toute contribution relative a la conception et: aux applications de World Wide Web aux applications de JAVA a l'Architecture de Cyberspace aux ateliers Virtuels aux Bureaux d'Etudes Virtuels aux Reseaux Multimedia aux implications sociales et spatiales des nouveaux reseaux de communications aux MultiMedia Interactives a la Ralite Virtuel. au Role d'Internet dans la vie professionnelle aux Intranets aux Reseaux de video numerique aux Systemes distribues d'aide a la Decision aux Systemes de Conception Collaborative aux Systemes d'Information Gographique aux Systemes d'Information Urbaine aux Teleconferences DATES Papers due in electronic form 11 December 1996 Notification of acceptance 7 February 1997 Final paper in electronic form 28 February 1997 Final date for registration 14 March 1997 Conference 2-3 April 1997 REGISTRATION FEE Authors 175 pounds stirling Non-authors 250 pounds stirling Conference Dinner 27 pounds stirling VENUE UnivEd Training and Conference Centre 11 South College Street Edinburgh EH8 9AA ORGANISING COMMITTEE Richard Coyne University of Edinburgh richard@caad.ed.ac.uk John Lee University of Edinburgh john@caad.ed.ac.uk Alan Bridges University of Strathclyde a.h.bridges@strath.ac.uk Linda Candy University of Loughborough L.Candy@lut.ac.uk Reza Beheshti Delft University of Technology R.Beheshti@CT.TUDelft.nl Khaldoun Zreik University of Caen zreik@univ-caen.fr ADVISORY BOARD Richard Buchanan, Carnegie Mellon University, USA Ernesto Costa, Universidade de Coimbra, Portugal Ernest Edmonds, Loughborough University, England Niklaus Kohler, University of Karlsruhe, Germany John Lansdown, University of Middlesex, England Ramon Lopez de Mantaras, Universitat Autonoma de Barcelona, Spain Marcel Miramond, INSA Lyon, France Sidney Newton, University of Western Sydney, Australia James Rutherford, University of Sydney, Australia Gerhard Schmitt, ETH Zrich, Switzerland Keith Stenning, University of Edinburgh, Scotland Peter Szalapaj, University of Sheffield, England David Week, Pacific Architecture, Australia Robin Williams, University of Edinburgh, Scotland Robert Woodbury, University of Adelaide, Australia CONFERENCE SECRETARY Michael Ramscar (michael@caad.ed.ac.uk) SEND TECHNICAL QUERIES TO Michael Ramscar Tel: +44 131 650 2332 Department of Architecture Fax: +44 131 650 8019 University of Edinburgh michael@caad.ed.ac.uk 20 Chambers Street EH1 1JZ Scotland http://www.caad.ed.ac.uk/~michael/ SEND QUEURIES ABOUT REGISTRATION AND ACCOMMODATION TO Ronnie Galloway Conference Manager Ronnie.Galloway@ed.ac.uk UnivEd Technologies Limited 11 South College Street, Edinburgh, EH8 9AA Ph +44 131 650 9020 Fax +44 131 650 9019 REGISTRATION OF INTEREST send to Ronnie.Galloway@ed.ac.uk Title: Mr/Mrs/Ms/Dr/Prof Name -------------------------------------------------------------- Organisation -------------------------------------------------------------- Address -------------------------------------------------------------- Tel Fax ------------------------------ ----------------------------- Email -------------------------------------------------------------- I wish to attend EuropIA'97 Design and the Net on YES/NO 2-3 April 1997 at the University of Edinburgh I intend to submit a paper YES/NO Title/Topic of paper -------------------------------------------------------------- -------------------------------------------------------------- Please send me information on accommodation in Edinburgh YES/NO   Received: from ietf.org by ietf.org id aa12970; 25 Nov 96 11:12 EST Received: from hal.microwave.com by ietf.org id aa12794; 25 Nov 96 11:09 EST Received: (from djc@localhost) by hal.microwave.com (Smail-3.2-#5) id m0vS37L-000Q0lC for ietf@ietf.org; Mon, 25 Nov 1996 10:38:43 -0500 (EST) Date: Mon, 25 Nov 1996 10:38:43 -0500 (EST) Sender:ietf-request@ietf.org From: "D. Chiodo" Reply-To: "D. Chiodo" To: Brad Douglas cc: JimFleming@unety.net, ietf@ietf.org Subject: Re: Fw: First? TRUE Root Name Server On Line In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. A. John Palmer is an incompetent idiot. I've dealt with him before. (And have since terminated all business relations with him because he was unable to perform reliably). If you send him a request for registration in his fantasy domain, he might reply to you. Maybe even within the same year you sent your message. (But probably not) B. Like it or not, there can be only ONE nameserver that is primary authoritative for the root zone. If you dont understand why, go back and read "DNS and BIND" again. (Or perhaps for the first time?) And again. And again, until you understand why. If you never figure it out, then you have no business discussing root nameservice. C. None of these "alternic", "root-64", or other rogue domains really exist until IANA and IETF list them in the REAL primary root server (see below) Dont get me wrong. I am all for: Seperating _root_ nameservice from _tld_ nameservice. Having an arrangement whereby competent and capable organizations are able to "register" a TLD in the root zone, and operate as the registry for (and provide primary nameservice for) that zone. (Competent and capable, at a minimum, would certainly include two or more T-3 or better links to different NAPs - probably NSI doesnt even meet that requirement (Yet one more reason they need to be replaced) To the best of my knowledge, John Palmer and his ever renaming[*] company only has T1 one connection, and its to ALTERNET - not even a backbone) Having SOMETHING other than the current setup where NSI is a monopoly. Perhaps MCI would be interested. They would certainly qualify as competent and capable. Rogue TLD's just isnt the way. * John Palmer has changed the name of his company several times, apparently to get rid of a following poor reputation. He used to be "Maccombnet".. Then "Rabbit Net".. Now he's "AGN".. ========================================================================== dns:~# dig @a.root-servers.net com any any ; <<>> DiG 2.2 <<>> @a.root-servers.net com any any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 10, Auth: 0, Addit: 9 ;; QUESTIONS: ;; com, type = ANY, class = ANY ;; ANSWERS: com. 518400 NS A.ROOT-SERVERS.NET. com. 518400 NS H.ROOT-SERVERS.NET. com. 518400 NS B.ROOT-SERVERS.NET. com. 518400 NS C.ROOT-SERVERS.NET. [...] dns:~# dig @a.root-servers.net earth any any ; <<>> DiG 2.2 <<>> @a.root-servers.net earth any any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; earth, type = ANY, class = ANY ;; Total query time: 83 msec ;; FROM: dns to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Mon Nov 25 10:06:15 1996 ;; MSG SIZE sent: 23 rcvd: 23 dns:~# dig @a.root-servers.net usa any any ; <<>> DiG 2.2 <<>> @a.root-servers.net usa any any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; usa, type = ANY, class = ANY ;; Total query time: 82 msec ;; FROM: dns to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Mon Nov 25 10:06:20 1996 ;; MSG SIZE sent: 21 rcvd: 21 On Mon, 25 Nov 1996, Brad Douglas wrote: > Date: Mon, 25 Nov 1996 09:57:23 -0500 > From: Brad Douglas > To: Dave Chiodo > Subject: Fw: First? TRUE Root Name Server On Line > > ---------- > > From: Jim Fleming > > To: 'ietf@ietf.org' > > Subject: First? TRUE Root Name Server On Line > > Date: Saturday, November 23, 1996 3:13 PM > > > > > > RE: First? TRUE Root Name Server On Line > > Name: NS2.NIC.EARTH > > IP Address: 199.5.157.5 > > > > When history is made on the Internet, it is important to > briefly pause > > to recognize the event, and then move forward. Recently, one > of the > > first TRUE Root Name Servers was put into service by John > Palmer > > of The American Global Network, Inc. (AGN.NET) [1]. AGN is the > owner > > and operator of the Top Level Domain Registry for the .EARTH > and > > .USA TLDs. > > > > There are several factors which make this particular Root Name > > Server unique: > > > > 1. First and foremost, this appears to be the first, public > > access, Root Name Server which operates as > > a TRUE NON-RECURSIVE Root Server [2]. This is a > > requirement which is part of the new root name server > > guidelines which are being discussed by the IETF and > > other engineering groups. The 9 "popular" root name > > servers use by many ISPs do NOT meet these > > guidelines and resolve second level names.[3] > > True root name servers should do nothing but return > > references to TLD Name Servers [2], to reduce the > > scope of their control and their overall load. > > > > 2. The official name of this root name server > is...NS2.NIC.EARTH. > > Because of the growing availability of access to the > > new Top Level Domains, such as .EARTH, it seems > > appropriate to begin naming the new Root Name Servers > > with the newly available names. > > > > 3. This Root Name Server can be added to the growing > collection > > of Root 64 Name Servers which can be freely used > > by ISPs in their "root.cache" files. Because this Root > > Name Server is supported by a commercial enterprise, > > and not a hodge podge of volunteers (or the U.S. > > Government), ISPs can use this Root Name Server to > > help bring added stability and performance to their > > systems. [4] [5] > > > > In these times where confusion is being caused by groups who > think > > that they can continue to debate the Top Level Domain issues > primarily > > to prevent businesses (registries, ISPs, etc.) from making > progress, it > > is important to recognize the efforts being made by business > people to > > bring stability to the system and better service to consumers. > > > > As has been proven over and over during the past year, new > commercial > > Top Level Domains are a reality along with new commercial Root > Name > > Servers. The business community is rising to the challenge of > building > > a better, more complete, and better engineered Internet now > that the > > research and development is largely over. > > > > More commercial Root Name Servers are being installed and > tested. > > As news of their introduction becomes available the "newdom" > mailing > > list seems like the best place to keep everyone informed. The > web > > interface for subscribing to that list can be found at: > > http://www.newdom.com/lists/ > > > > > > @@@@@@ [1] @@@@@@@@@ > > > > Result of: whois 199.5.156 > > > > The American Global Network, Inc. (NETBLK-RABBIT2) > > 31511 Harper Ave. > > St. Clair Shores, MI 48082 > > > > Netname: NETBLK-RABBIT2 > > Netblock: 199.5.156.0 - 199.5.157.0 > > > > Coordinator: > > Palmer, John P. (JP4736) jp@AGN.NET > > 800-456-0094 (FAX) 810-790-0156 > > > > Domain System inverse mapping provided by: > > > > SIMBA.AGN.NET 160.79.1.3 > > NS.AGN.NET 160.79.1.1 > > > > Record last updated on 18-Jan-96. > > > > @@@@@@ [2] @@@@@@@@@ > > > > Result of: dig @199.5.157.5 mcs.com any > > > > ; <<>> DiG 2.1 <<>> @199.5.157.5 mcs.com any > > ; (1 server found) > > ;; res options: init recurs defnam dnsrch > > ;; got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 > > ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 9, Addit: 9 > > ;; QUESTIONS: > > ;; mcs.com, type = ANY, class = IN > > > > ;; AUTHORITY RECORDS: > > COM. 172800 NS A.ROOT-SERVERS.NET. > > COM. 172800 NS H.ROOT-SERVERS.NET. > > COM. 172800 NS B.ROOT-SERVERS.NET. > > COM. 172800 NS C.ROOT-SERVERS.NET. > > COM. 172800 NS D.ROOT-SERVERS.NET. > > COM. 172800 NS E.ROOT-SERVERS.NET. > > COM. 172800 NS I.ROOT-SERVERS.NET. > > COM. 172800 NS F.ROOT-SERVERS.NET. > > COM. 172800 NS G.ROOT-SERVERS.NET. > > > > ;; ADDITIONAL RECORDS: > > A.ROOT-SERVERS.NET. 518400 A 198.41.0.4 > > H.ROOT-SERVERS.NET. 518400 A 128.63.2.53 > > B.ROOT-SERVERS.NET. 518400 A 128.9.0.107 > > C.ROOT-SERVERS.NET. 518400 A 192.33.4.12 > > D.ROOT-SERVERS.NET. 518400 A 128.8.10.90 > > E.ROOT-SERVERS.NET. 518400 A 192.203.230.10 > > I.ROOT-SERVERS.NET. 518400 A 192.36.148.17 > > F.ROOT-SERVERS.NET. 518400 A 192.5.5.241 > > G.ROOT-SERVERS.NET. 518400 A 192.112.36.4 > > > > ;; Total query time: 29 msec > > ;; FROM: doorstep.unety.net to SERVER: 199.5.157.5 > > ;; WHEN: Sat Nov 23 10:59:28 1996 > > ;; MSG SIZE sent: 25 rcvd: 332 > > > > @@@@@@ [3] @@@@@@@@@ > > > > Result of: dig @a.root-servers.net mcs.com any > > > > ; <<>> DiG 2.1 <<>> @a.root-servers.net mcs.com any > > ; (1 server found) > > ;; res options: init recurs defnam dnsrch > > ;; got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 > > ;; flags: qr rd; Ques: 1, Ans: 2, Auth: 2, Addit: 2 > > ;; QUESTIONS: > > ;; mcs.com, type = ANY, class = IN > > > > ;; ANSWERS: > > mcs.com. 172800 NS CEREBUS.mcs.com. > > mcs.com. 172800 NS KITTEN.mcs.com. > > > > ;; AUTHORITY RECORDS: > > mcs.com. 172800 NS CEREBUS.mcs.com. > > mcs.com. 172800 NS KITTEN.mcs.com. > > > > ;; ADDITIONAL RECORDS: > > CEREBUS.mcs.com. 172800 A 192.160.127.125 > > KITTEN.mcs.com. 172800 A 192.160.127.90 > > > > ;; Total query time: 88 msec > > ;; FROM: doorstep.unety.net to SERVER: a.root-servers.net > 198.41.0.4 > > ;; WHEN: Sat Nov 23 12:31:25 1996 > > ;; MSG SIZE sent: 25 rcvd: 128 > > > > > > @@@@@@ [4] @@@@@@@@@ > > > > Sample Traceroute to the NEW Root Server > > > > 1 chi00-s8-3.nap.net (206.54.225.89) 4.131 ms 4.066 ms > 4.211 ms > > 2 core0-atm0.chi.nap.net (207.112.247.33) 4.013 ms 4.913 > ms 4.309 ms > > 3 909.Hssi3-0.GW2.CHI1.ALTER.NET (137.39.130.173) 5.988 ms > 5.735 ms 5.69 ms > > 4 Fddi1.CR1.CHI1.Alter.Net (137.39.38.193) 5.555 ms 6.243 > ms 6.533 ms > > 5 106.Hssi3-0.GW1.DET1.Alter.Net (137.39.58.58) 14.022 ms > 15.304 ms 15.322 ms > > 6 agn-gw.ALTER.NET (137.39.146.6) 18.409 ms 20.191 ms > 19.351 ms > > 7 NS2.NIC.EARTH (199.5.157.5) 17.695 ms 18.895 ms 17.738 > ms > > > > @@@@@@ [5] @@@@@@@@@ > > > > Sample Ping to NEW Root Server for above route. > > > > # ping -c 5 199.5.157.5 > > PING 199.5.157.5 (199.5.157.5): 56 data bytes > > 64 bytes from 199.5.157.5: icmp_seq=0 ttl=247 time=19.313 ms > > 64 bytes from 199.5.157.5: icmp_seq=1 ttl=247 time=20.071 ms > > 64 bytes from 199.5.157.5: icmp_seq=2 ttl=247 time=18.218 ms > > 64 bytes from 199.5.157.5: icmp_seq=3 ttl=247 time=19.377 ms > > 64 bytes from 199.5.157.5: icmp_seq=4 ttl=247 time=18.007 ms > > > > --- 199.5.157.5 ping statistics --- > > 5 packets transmitted, 5 packets received, 0% packet loss > > round-trip min/avg/max = 18.007/18.997/20.071 ms > > > > @@@@@@@@@@@@@@@ > > > > > > -- > > Jim Fleming > > UNETY Systems, Inc. > > Naperville, IL > > > > e-mail: > > JimFleming@unety.net > > JimFleming@unety.net.s0.g0 (EDNS/IPv8) > > > > >   Received: from ietf.org by ietf.org id aa13342; 25 Nov 96 11:17 EST Received: from [207.32.130.1] by ietf.org id aa13205; 25 Nov 96 11:16 EST Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id KAA00739; Mon, 25 Nov 1996 10:09:35 -0600 Received: by webster.unety.net with Microsoft Mail id <01BBDAB9.19A6FE40@webster.unety.net>; Mon, 25 Nov 1996 10:12:01 -0600 Message-ID: <01BBDAB9.19A6FE40@webster.unety.net> Sender:ietf-request@ietf.org From: Jim Fleming To: Brad Douglas Cc: "ietf@ietf.org" , "JimFleming@unety.net" , 'John Palmer' Subject: RE: Fw: First? TRUE Root Name Server On Line Date: Mon, 25 Nov 1996 10:12:00 -0600 Encoding: 19 TEXT Source-Info: From (or Sender) name not authenticated. On Monday, November 25, 1996 4:38 AM, D. Chiodo[SMTP:djc@microwave.com] wrote: @ @ A. John Palmer is an incompetent idiot. I've dealt with him before. (And @ have since terminated all business relations with him because he was @ unable to perform reliably). If you send him a request for registration in @ his fantasy domain, he might reply to you. Maybe even within the same year @ you sent your message. (But probably not) @ Does this reply conform to the IETF Code of Conduct ? -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8)   Received: from ietf.org by ietf.org id aa23020; 25 Nov 96 12:55 EST Received: from ietf.org by ietf.org id aa22427; 25 Nov 96 12:45 EST To: ietf@ietf.org Subject: Subject: Re: First? TRUE Root Name Server On Line Sender:ietf-request@ietf.org From: Dave Barr Date: Mon, 25 Nov 1996 12:45:30 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611251245.aa22427@ietf.org> Source-Info: From (or Sender) name not authenticated. In article <01BBD948.7F2F4E60@webster.unety.net>, Jim Fleming wrote: >When history is made on the Internet, it is important to briefly pause >to recognize the event, and then move forward. Recently, one of the >first TRUE Root Name Servers was put into service by John Palmer Operated by none other than one of the first TRUE Usenet kooks! How appropriate. --Dave   Received: from ietf.org by ietf.org id aa09161; 25 Nov 96 16:10 EST Received: from ietf.org by ietf.org id aa08955; 25 Nov 96 16:06 EST To: IETF-Announce: ; Subject: WG ACTION: Roaming Operations (roamops) Date: Mon, 25 Nov 1996 16:06:47 -0500 Sender:ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9611251606.aa08955@ietf.org> A new working group has been formed in the Operational Requirements Area of the IETF. For additional information, contact the Area Directors or the WG Chair. Roaming Operations (roamops) ---------------------------- Chair(s): Glenn Zorn Pat Calhoun Operational Requirements Area Director(s): Scott Bradner Michael O'Dell Area Advisor Scott Bradner Mailing lists: General Discussion:roamops@nsmx.rutgers.edu To Subscribe: roamops-request@nsmx.rutgers.edu In Body: include "subscribe" Archive: ftp://ftp-no.rutgers.edu/misc/IETF/roamops Description of Working Group: The purpose of this group is to develop or adopt procedures, mechanisms and protocols to support user roaming among groups of Internet service providers (ISPs). This is different from, but related to, the work of the IP Routing for Wireless/Mobile Hosts Working Group (mobileip) in that the roamops group is not concerned with the movement of hosts or subnets, but of users. In the near term, the goals of the group will be to produce an Informational RFC describing existing roaming implementations and an architectural document describing the basic mechanisms required to support user roaming. The group will use draft-zorn-dial-roam-req-01.txt as a starting point for the latter document. In addition, a repository for documentation describing current roaming implementations will be maintained. In the longer term, the group may address interoperability among ISPs and roaming users by standardizing such items as network usage data exchange (including the content, format and protocols involved), phone book attributes and exchange/update protocols, inter-ISP authentication mechanisms and exploring in depth the security issues involved with roaming. This work is expected to consist mainly of new or revised procedures and application-layer protocols. Any and all business issues regarding the operation of an ISP roaming network (such as settlement, business and billing methods) are specifically NOT in the scope of the roamops Working Group and will not be discussed. The group will work closely with other IETF Working Groups (including mobileip, radius, nasreqng and cat) to identify issues to which the roamops group should attend, as well as to assure their work does not make roaming unnecessarily difficult or impossible. Goals and Milestones: Nov 96 Re-submit existing Internet-Drafts as work of the ROAMOPS Working Group Jan 97 Submit Internet-Drafts to IESG for publication as RFCs Jan 97 Review the charter for additional work required   Received: from ietf.org by ietf.org id aa12523; 25 Nov 96 16:50 EST Received: from jekyll.piermont.com by ietf.org id aa12276; 25 Nov 96 16:45 EST Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id QAA18320; Mon, 25 Nov 1996 16:43:53 -0500 (EST) Message-Id: <199611252143.QAA18320@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol To: Jim Fleming cc: Brad Douglas , "ietf@ietf.org" Subject: Re: Fw: First? TRUE Root Name Server On Line In-reply-to: Your message of "Mon, 25 Nov 1996 10:12:00 CST." <01BBDAB9.19A6FE40@webster.unety.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 25 Nov 1996 16:43:51 -0500 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Jim Fleming writes: > On Monday, November 25, 1996 4:38 AM, D. Chiodo[SMTP:djc@microwave.com] wrote : > @ A. John Palmer is an incompetent idiot. I've dealt with him before. (And > @ have since terminated all business relations with him because he was > @ unable to perform reliably). If you send him a request for registration in > @ his fantasy domain, he might reply to you. Maybe even within the same year > @ you sent your message. (But probably not) > > Does this reply conform to the IETF Code of Conduct ? I'd say under the circumstances it does.   Received: from ietf.org by ietf.org id aa13392; 25 Nov 96 17:01 EST Received: from noc.msc.edu by ietf.org id aa13209; 25 Nov 96 16:59 EST Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA20650; Mon, 25 Nov 96 15:57:43 -0600 Sender:ietf-request@ietf.org From: Tim Salo Received: (salo@localhost) by uh.msc.edu (8.7.1/8.6.6) id PAA08906; Mon, 25 Nov 1996 15:57:42 -0600 (CST) Date: Mon, 25 Nov 1996 15:57:42 -0600 (CST) Message-Id: <199611252157.PAA08906@uh.msc.edu> To: JimFleming@unety.net Subject: RE: Fw: First? TRUE Root Name Server On Line Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. > From: Jim Fleming > Subject: RE: Fw: First? TRUE Root Name Server On Line > Date: Mon, 25 Nov 1996 10:12:00 -0600 > > Does this reply conform to the IETF Code of Conduct ? If the IETF Code of Conduct doesn't suggest that the IETF mail lists are to be used for productive information exchange, rather than aggressive evangelism, it could probably be repaired. -tjs   Received: from ietf.org by ietf.org id aa16836; 25 Nov 96 17:32 EST Received: from fnal.fnal.gov by ietf.org id aa16551; 25 Nov 96 17:30 EST Received: from gungnir.fnal.gov ("port 36155"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IC9PJL72MG000CEY@FNAL.FNAL.GOV>; Mon, 25 Nov 1996 16:29:14 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA12398; Mon, 25 Nov 1996 16:28:09 -0600 Date: Mon, 25 Nov 1996 16:28:09 -0600 Sender:ietf-request@ietf.org From: Matt Crawford Subject: Re: Fw: First? TRUE Root Name Server On Line In-reply-to: "25 Nov 1996 10:12:00 CST." <"01BBDAB9.19A6FE40"@webster.unety.net> X-Orig-Sender: crawdad@gungnir.fnal.gov To: Jim Fleming Cc: "ietf@ietf.org" Message-id: <199611252228.QAA12398@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ @ A. John Palmer is an ... > Does this reply conform to the IETF Code of Conduct ? About as much as your FUD-mongering does, Jim. Neither is proper; neither excuses the other; but neither author has the right to throw stones about conduct. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A   Received: from cnri by ietf.org id aa21052; 25 Nov 96 18:18 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19290; 25 Nov 96 18:18 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Mon, 25 Nov 1996 22:29:44 GMT Received: from rover.cygnus.com by MIT.EDU with SMTP id AA03013; Mon, 25 Nov 96 17:29:42 EST Received: (from marc@localhost) by rover.cygnus.com (8.7.6/8.6.12) id RAA00646; Mon, 25 Nov 1996 17:29:03 -0500 (EST) To: Changwen Liu Cc: cat-ietf@mit.edu Subject: Re: RFC-1964: Problem with getting server network addresses in GSS-API delegation support References: <9611201448.ZM1117@engineering.cybersafe.com> From: Marc Horowitz Date: 25 Nov 1996 17:29:03 -0500 In-Reply-To: "Changwen Liu"'s message of Wed, 20 Nov 1996 14:48:21 -0800 Message-Id: Lines: 10 X-Mailer: Gnus v5.3/Emacs 19.34 "Changwen Liu" writes: >> Since the RFC-1964 doesn't give a general scheme on how to >> get the network addresses for servers. This seems what we can go now. >> Do you have any better solutions for this problem? This strikes me as exactly the sort of thing channel bindings are useful for. Marc   Received: from cnri by ietf.org id aa21447; 25 Nov 96 18:27 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19517; 25 Nov 96 18:27 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Mon, 25 Nov 1996 22:05:55 GMT Received: from rover.cygnus.com by MIT.EDU with SMTP id AA18044; Mon, 25 Nov 96 17:05:52 EST Received: (from marc@localhost) by rover.cygnus.com (8.7.6/8.6.12) id RAA00623; Mon, 25 Nov 1996 17:05:50 -0500 (EST) To: cat-ietf@mit.edu Subject: new ftpsec draft From: Marc Horowitz Date: 25 Nov 1996 17:05:50 -0500 Message-Id: Lines: 1391 X-Mailer: Gnus v5.3/Emacs 19.34 I have just submitted draft-ietf-cat-ftpsec-09.txt to the Internet Drafts editor. The changes are simple and essentially clarifying, with no new semantic content: - explanatory text in several places has been clarified or added. - If CCC completes successfully, then unprotected commands must have unprotected replies. - The 502 reply to AUTH has been added to the command-reply sequences section. (This corrects an editing error; the 502 code has been part of the description of the AUTH command all along.) - an authentication state diagram expressing the interaction between the FTP Security commands has been added. - The channel bindings inputs to the GSSAPI are now specified. The full draft as submitted is appended. The official version should be in the usual places in a few days. Marc --cut-- Network Working Group M. Horowitz Cygnus Solutions Updates: RFC 959 S. J. Lunt Internet-Draft Bellcore November, 1996 FTP Security Extensions Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. Please send comments to the mailing list. Abstract This document defines extensions to the FTP specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings. The following new optional commands are introduced in this specification: AUTH (Authentication/Security Mechanism), ADAT (Authentication/Security Data), PROT (Data Channel Protection Level), PBSZ (Protection Buffer Size), CCC (Clear Command Channel), MIC (Integrity Protected Command), CONF (Confidentiality Protected Command), and ENC (Privacy Protected Command). A new class of reply types (6yz) is also introduced for protected replies. None of the above commands are required to be implemented, but interdependencies exist. These dependencies are documented with the Horowitz & Lunt [Page 1] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 commands. Note that this specification is compatible with RFC 959. 1. Introduction The File Transfer Protocol (FTP) currently defined in RFC 959 and in place on the Internet uses usernames and passwords passed in cleartext to authenticate clients to servers (via the USER and PASS commands). Except for services such as 'anonymous' FTP archives, this represents a security risk whereby passwords can be stolen through monitoring of local and wide-area networks. This either aids potential attackers through password exposure and/or limits accessibility of files by FTP servers who cannot or will not accept the inherent security risks. Aside from the problem of authenticating users in a secure manner, there is also the problem of authenticating servers, protecting sensitive data and/or verifying its integrity. An attacker may be able to access valuable or sensitive data merely by monitoring a network, or through active means may be able to delete or modify the data being transferred so as to corrupt its integrity. An active attacker may also initiate spurious file transfers to and from a site of the attacker's choice, and may invoke other commands on the server. FTP does not currently have any provision for the encryption or verification of the authenticity of commands, replies, or transferred data. Note that these security services have value even to anonymous file access. Current practice for sending files securely is generally either: 1. via FTP of files pre-encrypted under keys which are manually distributed, 2. via electronic mail containing an encoding of a file encrypted under keys which are manually distributed, 3. via a PEM message, or 4. via the rcp command enhanced to use Kerberos. None of these means could be considered even a de facto standard, and none are truly interactive. A need exists to securely transfer files using FTP in a secure manner which is supported within the FTP protocol in a consistent manner and which takes advantage of existing security infrastructure and technology. Extensions are necessary to the FTP specification if these security services are to be introduced into the protocol in an interoperable way. Although the FTP control connection follows the Telnet protocol, and Telnet has defined an authentication and encryption option [TELNET- SEC], [RFC-1123] explicitly forbids the use of Telnet option negotiation over the control connection (other than Synch and IP). Horowitz & Lunt [Page 2] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 Also, the Telnet authentication and encryption option does not provide for integrity protection only (without confidentiality), and does not address the protection of the data channel. 2. FTP Security Overview At the highest level, the FTP security extensions seek to provide an abstract mechanism for authenticating and/or authorizing connections, and integrity and/or confidentiality protecting commands, replies, and data transfers. In the context of FTP security, authentication is the establishment of a client's identity and/or a server's identity in a secure way, usually using cryptographic techniques. The basic FTP protocol does not have a concept of authentication. Authorization is the process of validating a user for login. The basic authorization process involves the USER, PASS, and ACCT commands. With the FTP security extensions, authentication established using a security mechanism may also be used to make the authorization decision. Without the security extensions, authentication of the client, as this term is usually understood, never happens. FTP authorization is accomplished with a password, passed on the network in the clear as the argument to the PASS command. The possessor of this password is assumed to be authorized to transfer files as the user named in the USER command, but the identity of the client is never securely established. An FTP security interaction begins with a client telling the server what security mechanism it wants to use with the AUTH command. The server will either accept this mechanism, reject this mechanism, or, in the case of a server which does not implement the security extensions, reject the command completely. The client may try multiple security mechanisms until it requests one which the server accepts. This allows a rudimentary form of negotiation to take place. (If more complex negotiation is desired, this may be implemented as a security mechanism.) The server's reply will indicate if the client must respond with additional data for the security mechanism to interpret. If none is needed, this will usually mean that the mechanism is one where the password (specified by the PASS command) is to be interpreted differently, such as with a token or one-time password system. If the server requires additional security information, then the client and server will enter into a security data exchange. The client will send an ADAT command containing the first block of security data. The server's reply will indicate if the data exchange is complete, if there was an error, or if more data is needed. The server's reply can optionally contain security data for the client to interpret. If more data is needed, the client will send another ADAT command containing the next block of data, and await the server's Horowitz & Lunt [Page 3] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 reply. This exchange can continue as many times as necessary. Once this exchange completes, the client and server have established a security association. This security association may include authentication (client, server, or mutual) and keying information for integrity and/or confidentiality, depending on the mechanism in use. The term ``security data'' here is carefully chosen. The purpose of the security data exchange is to establish a security association, which might not actually include any authentication at all, between the client and the server as described above. For instance, a Diffie-Hellman exchange establishes a secret key, but no authentication takes place. If an FTP server has an RSA key pair but the client does not, then the client can authenticate the server, but the server cannot authenticate the client. Once a security association is established, authentication which is a part of this association may be used instead of or in addition to the standard username/password exchange for authorizing a user to connect to the server. A username specified by the USER command is always required to specify the identity to be used on the server. In order to prevent an attacker from inserting or deleting commands on the control stream, if the security association supports integrity, then the server and client must use integrity protection on the control stream, unless it first transmits a CCC command to turn off this requirement. Integrity protection is performed with the MIC and ENC commands, and the 63z reply codes. The CCC command and its reply must be transmitted with integrity protection. Commands and replies may be transmitted without integrity (that is, in the clear or with confidentiality only) only if no security association is established, the negotiated security association does not support integrity, or the CCC command has succeeded. Once the client and server have negotiated with the PBSZ command an acceptable buffer size for encapsulating protected data over the data channel, the security mechanism may also be used to protect data channel transfers. Policy is not specified by this document. In particular, client and server implementations may choose to implement restrictions on what operations can be performed depending on the security association which exists. For example, a server may require that a client authorize via a security mechanism rather than using a password, require that the client provide a one-time password from a token, require at least integrity protection on the command channel, or require that certain files only be transmitted encrypted. An anonymous ftp client might refuse to do file transfers without integrity protection in order to insure the validity of files downloaded. No particular set of functionality is required, except as dependencies described in the next section. This means that none of authentication, integrity, or confidentiality are required of an implementation, although a mechanism which does none of these is not Horowitz & Lunt [Page 4] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 of much use. For example, it is acceptable for a mechanism to implement only integrity protection, one-way authentication and/or encryption, encryption without any authentication or integrity protection, or any other subset of functionality if policy or technical considerations make this desirable. Of course, one peer might require as a matter of policy stronger protection than the other is able to provide, preventing perfect interoperability. 3. New FTP Commands The following commands are optional, but dependent on each other. They are extensions to the FTP Access Control Commands. The reply codes documented here are generally described as recommended, rather than required. The intent is that reply codes describing the full range of success and failure modes exist, but that servers be allowed to limit information presented to the client. For example, a server might implement a particular security mechanism, but have a policy restriction against using it. The server should respond with a 534 reply code in this case, but may respond with a 504 reply code if it does not wish to divulge that the disallowed mechanism is supported. If the server does choose to use a different reply code than the recommended one, it should try to use a reply code which only differs in the last digit. In all cases, the server must use a reply code which is documented as returnable from the command received, and this reply code must begin with the same digit as the recommended reply code for the situation. AUTHENTICATION/SECURITY MECHANISM (AUTH) The argument field is a Telnet string identifying a supported mechanism. This string is case-insensitive. Values must be registered with the IANA, except that values beginning with "X-" are reserved for local use. If the server does not recognize the AUTH command, it must respond with reply code 500. This is intended to encompass the large deployed base of non-security-aware ftp servers, which will respond with reply code 500 to any unrecognized command. If the server does recognize the AUTH command but does not implement the security extensions, it should respond with reply code 502. If the server does not understand the named security mechanism, it should respond with reply code 504. If the server is not willing to accept the named security mechanism, it should respond with reply code 534. If the server is not able to accept the named security mechanism, such as if a required resource is unavailable, it should respond with reply code 431. If the server is willing to accept the named security mechanism, Horowitz & Lunt [Page 5] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 but requires security data, it must respond with reply code 334. If the server is willing to accept the named security mechanism, and does not require any security data, it must respond with reply code 234. If the server is responding with a 334 reply code, it may include security data as described in the next section. Some servers will allow the AUTH command to be reissued in order to establish new authentication. The AUTH command, if accepted, removes any state associated with prior FTP Security commands. The server must also require that the user reauthorize (that is, reissue some or all of the USER, PASS, and ACCT commands) in this case (see section 4 for an explanation of "authorize" in this context). AUTHENTICATION/SECURITY DATA (ADAT) The argument field is a Telnet string representing base 64 encoded security data (see Section 9, "Base 64 Encoding"). If a reply code indicating success is returned, the server may also use a string of the form "ADAT=base64data" as the text part of the reply if it wishes to convey security data back to the client. The data in both cases is specific to the security mechanism specified by the previous AUTH command. The ADAT command, and the associated replies, allow the client and server to conduct an arbitrary security protocol. The security data exchange must include enough information for both peers to be aware of which optional features are available. For example, if the client does not support data encryption, the server must be made aware of this, so it will know not to send encrypted command channel replies. It is strongly recommended that the security mechanism provide sequencing on the command channel, to insure that commands are not deleted, reordered, or replayed. The ADAT command must be preceded by a successful AUTH command, and cannot be issued once a security data exchange completes (successfully or unsuccessfully), unless it is preceded by an AUTH command to reset the security state. If the server has not yet received an AUTH command, or if a prior security data exchange completed, but the security state has not been reset with an AUTH command, it should respond with reply code 503. If the server cannot base 64 decode the argument, it should respond with reply code 501. If the server rejects the security data (if a checksum fails, for instance), it should respond with reply code 535. If the server accepts the security data, and requires additional Horowitz & Lunt [Page 6] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 data, it should respond with reply code 335. If the server accepts the security data, but does not require any additional data (i.e., the security data exchange has completed successfully), it must respond with reply code 235. If the server is responding with a 235 or 335 reply code, then it may include security data in the text part of the reply as specified above. If the ADAT command returns an error, the security data exchange will fail, and the client must reset its internal security state. If the client becomes unsynchronized with the server (for example, the server sends a 234 reply code to an AUTH command, but the client has more data to transmit), then the client must reset the server's security state. PROTECTION BUFFER SIZE (PBSZ) The argument is a decimal integer representing the maximum size, in bytes, of the encoded data blocks to be sent or received during file transfer. This number shall be no greater than can be represented in a 32-bit unsigned integer. This command allows the FTP client and server to negotiate a maximum protected buffer size for the connection. There is no default size; the client must issue a PBSZ command before it can issue the first PROT command. The PBSZ command must be preceded by a successful security data exchange. If the server cannot parse the argument, or if it will not fit in 32 bits, it should respond with a 501 reply code. If the server has not completed a security data exchange with the client, it should respond with a 503 reply code. Otherwise, the server must reply with a 200 reply code. If the size provided by the client is too large for the server, it must use a string of the form "PBSZ=number" in the text part of the reply to indicate a smaller buffer size. The client and the server must use the smaller of the two buffer sizes if both buffer sizes are specified. DATA CHANNEL PROTECTION LEVEL (PROT) The argument is a single Telnet character code specifying the data channel protection level. This command indicates to the server what type of data channel protection the client and server will be using. The following codes are assigned: Horowitz & Lunt [Page 7] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 C - Clear S - Safe E - Confidential P - Private The default protection level if no other level is specified is Clear. The Clear protection level indicates that the data channel will carry the raw data of the file transfer, with no security applied. The Safe protection level indicates that the data will be integrity protected. The Confidential protection level indicates that the data will be confidentiality protected. The Private protection level indicates that the data will be integrity and confidentiality protected. It is reasonable for a security mechanism not to provide all data channel protection levels. It is also reasonable for a mechanism to provide more protection at a level than is required (for instance, a mechanism might provide Confidential protection, but include integrity-protection in that encoding, due to API or other considerations). The PROT command must be preceded by a successful protection buffer size negotiation. If the server does not understand the specified protection level, it should respond with reply code 504. If the current security mechanism does not support the specified protection level, the server should respond with reply code 536. If the server has not completed a protection buffer size negotiation with the client, it should respond with a 503 reply code. The PROT command will be rejected and the server should reply 503 if no previous PBSZ command was issued. If the server is not willing to accept the specified protection level, it should respond with reply code 534. If the server is not able to accept the specified protection level, such as if a required resource is unavailable, it should respond with reply code 431. Otherwise, the server must reply with a 200 reply code to indicate that the specified protection level is accepted. CLEAR COMMAND CHANNEL (CCC) This command does not take an argument. It is desirable in some environments to use a security mechanism to authenticate and/or authorize the client and server, but not to perform any integrity checking on the subsequent commands. This Horowitz & Lunt [Page 8] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 might be used in an environment where IP security is in place, insuring that the hosts are authenticated and that TCP streams cannot be tampered, but where user authentication is desired. If unprotected commands are allowed on any connection, then an attacker could insert a command on the control stream, and the server would have no way to know that it was invalid. In order to prevent such attacks, once a security data exchange completes successfully, if the security mechanism supports integrity, then integrity (via the MIC or ENC command, and 631 or 632 reply) must be used, until the CCC command is issued to enable non-integrity protected control channel messages. The CCC command itself must be integrity protected. Once the CCC command completes successfully, if a command is not protected, then the reply to that command must also not be protected. This is to support interoperability with clients which do not support protection once the CCC command has been issued. This command must be preceded by a successful security data exchange. If the command is not integrity-protected, the server must respond with a 533 reply code. If the server is not willing to turn off the integrity requirement, it should respond with a 534 reply code. Otherwise, the server must reply with a 200 reply code to indicate that unprotected commands and replies may now be used on the command channel. INTEGRITY PROTECTED COMMAND (MIC) and CONFIDENTIALITY PROTECTED COMMAND (CONF) and PRIVACY PROTECTED COMMAND (ENC) The argument field of MIC is a Telnet string consisting of a base 64 encoded "safe" message produced by a security mechanism specific message integrity procedure. The argument field of CONF is a Telnet string consisting of a base 64 encoded "confidential" message produced by a security mechanism specific confidentiality procedure. The argument field of ENC is a Telnet string consisting of a base 64 encoded "private" message produced by a security mechanism specific message integrity and confidentiality procedure. The server will decode and/or verify the encoded message. This command must be preceded by a successful security data exchange. A server may require that the first command after a successful security data exchange be CCC, and not implement the protection commands at all. In this case, the server should respond with a Horowitz & Lunt [Page 9] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 502 reply code. If the server cannot base 64 decode the argument, it should respond with a 501 reply code. If the server has not completed a security data exchange with the client, it should respond with a 503 reply code. If the server has completed a security data exchange with the client using a mechanism which supports integrity, and requires a CCC command due to policy or implementation limitations, it should respond with a 503 reply code. If the server rejects the command because it is not supported by the current security mechanism, the server should respond with reply code 537. If the server rejects the command (if a checksum fails, for instance), it should respond with reply code 535. If the server is not willing to accept the command (if privacy is required by policy, for instance, or if a CONF command is received before a CCC command), it should respond with reply code 533. Otherwise, the command will be interpreted as an FTP command. An end-of-line code need not be included, but if one is included, it must be a Telnet end-of-line code, not a local end-of-line code. The server may require that, under some or all circumstances, all commands be protected. In this case, it should make a 533 reply to commands other than MIC, CONF, and ENC. 4. Login Authorization The security data exchange may, among other things, establish the identity of the client in a secure way to the server. This identity may be used as one input to the login authorization process. In response to the FTP login commands (AUTH, PASS, ACCT), the server may choose to change the sequence of commands and replies specified by RFC 959 as follows. There are also some new replies available. If the server is willing to allow the user named by the USER command to log in based on the identity established by the security data exchange, it should respond with reply code 232. If the security mechanism requires a challenge/response password, it should respond to the USER command with reply code 336. The text part of the reply should contain the challenge. The client must display the challenge to the user before prompting for the password in this case. This is particularly relevant to more sophisticated clients or graphical user interfaces which provide dialog boxes or other modal input. These clients should be careful not to prompt for Horowitz & Lunt [Page 10] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 the password before the username has been sent to the server, in case the user needs the challenge in the 336 reply to construct a valid password. 5. New FTP Replies The new reply codes are divided into two classes. The first class is new replies made necessary by the new FTP Security commands. The second class is a new reply type to indicate protected replies. 5.1. New individual reply codes 232 User logged in, authorized by security data exchange. 234 Security data exchange complete. 235 [ADAT=base64data] ; This reply indicates that the security data exchange ; completed successfully. The square brackets are not ; to be included in the reply, but indicate that ; security data in the reply is optional. 334 [ADAT=base64data] ; This reply indicates that the requested security mechanism ; is ok, and includes security data to be used by the client ; to construct the next command. The square brackets are not ; to be included in the reply, but indicate that ; security data in the reply is optional. 335 [ADAT=base64data] ; This reply indicates that the security data is ; acceptable, and more is required to complete the ; security data exchange. The square brackets ; are not to be included in the reply, but indicate ; that security data in the reply is optional. 336 Username okay, need password. Challenge is "...." ; The exact representation of the challenge should be chosen ; by the mechanism to be sensible to the human user of the ; system. 431 Need some unavailable resource to process security. 533 Command protection level denied for policy reasons. 534 Request denied for policy reasons. 535 Failed security check (hash, sequence, etc). 536 Requested PROT level not supported by mechanism. 537 Command protection level not supported by security mechanism. 5.2. Protected replies. One new reply type is introduced: 6yz Protected reply Horowitz & Lunt [Page 11] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 There are three reply codes of this type. The first, reply code 631 indicates an integrity protected reply. The second, reply code 632, indicates a confidentiality and integrity protected reply. the third, reply code 633, indicates a confidentiality protected reply. The text part of a 631 reply is a Telnet string consisting of a base 64 encoded "safe" message produced by a security mechanism specific message integrity procedure. The text part of a 632 reply is a Telnet string consisting of a base 64 encoded "private" message produced by a security mechanism specific message confidentiality and integrity procedure. The text part of a 633 reply is a Telnet string consisting of a base 64 encoded "confidential" message produced by a security mechanism specific message confidentiality procedure. The client will decode and verify the encoded reply. How failures decoding or verifying replies are handled is implementation-specific. An end-of-line code need not be included, but if one is included, it must be a Telnet end- of-line code, not a local end-of-line code. A protected reply may only be sent if a security data exchange has succeeded. The 63z reply may be a multiline reply. In this case, the plaintext reply must be broken up into a number of fragments. Each fragment must be protected, then base 64 encoded in order into a separate line of the multiline reply. There need not be any correspondence between the line breaks in the plaintext reply and the encoded reply. Telnet end-of-line codes must appear in the plaintext of the encoded reply, except for the final end-of-line code, which is optional. The multiline reply must be formatted more strictly than the continuation specification in RFC 959. In particular, each line before the last must be formed by the reply code, followed immediately by a hyphen, followed by a base 64 encoded fragment of the reply. For example, if the plaintext reply is 123-First line Second line 234 A line beginning with numbers 123 The last line then the resulting protected reply could be any of the following (the first example has a line break only to fit within the margins): 631 base64(protect("123-First line\r\nSecond line\r\n 234 A line Horowitz & Lunt [Page 12] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 beginning with numbers\r\n123 The last line\r\n")) 631-base64(protect("123-First line\r\n")) 631-base64(protect("Second line\r\n")) 631-base64(protect(" 234 A line beginning with numbers\r\n")) 631 base64(protect("123 The last line")) 631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b")) 631 base64(protect("eginning with numbers\r\n123 The last line\r\n")) 6. Data Channel Encapsulation When data transfers are protected between the client and server (in either direction), certain transformations and encapsulations must be performed so that the recipient can properly decode the transmitted file. The sender must apply all protection services after transformations associated with the representation type, file structure, and transfer mode have been performed. The data sent over the data channel is, for the purposes of protection, to be treated as a byte stream. The sender must take the input byte stream, and break it up into blocks such that each block, when encoded using a security mechanism specific procedure, will be no larger than the buffer size negotiated by the client with the PBSZ command. Each block must be encoded, then transmitted with the length of the encoded block prepended as a four byte unsigned integer, most significant byte first. When the end of the file is reached, the sender must encode a block of zero bytes, and send this final block to the recipient before closing the data connection. The recipient will read the four byte length, read a block of data that many bytes long, then decode and verify this block with a security mechanism specific procedure. This must be repeated until a block encoding a buffer of zero bytes is received. This indicates the end of the encoded byte stream. Any transformations associated with the representation type, file structure, and transfer mode are to be performed by the recipient on the byte stream resulting from the above process. When using block transfer mode, the sender's (cleartext) buffer size is independent of the block size. The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE command if the current protection level is not at the level dictated by the server's security requirements for the particular file transfer. If any data protection services fail at any time during data transfer at the server end (including an attempt to send a buffer size greater Horowitz & Lunt [Page 13] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 than the negotiated maximum), the server will send a 535 reply to the data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE). 7. Potential policy considerations While there are no restrictions on client and server policy, there are a few recommendations which an implementation should implement. - Once a security data exchange takes place, a server should require all commands be protected (with integrity and/or confidentiality), and it should protect all replies. Replies should use the same level of protection as the command which produced them. This includes replies which indicate failure of the MIC, CONF, and ENC commands. In particular, it is not meaningful to require that AUTH and ADAT be protected; it is meaningful and useful to require that PROT and PBSZ be protected. In particular, the use of CCC is not recommended, but is defined in the interest of interoperability between implementations which might desire such functionality. - A client should encrypt the PASS command whenever possible. It is reasonable for the server to refuse to accept a non-encrypted PASS command if the server knows encryption is available. - Although no security commands are required to be implemented, it is recommended that an implementation provide all commands which can be implemented, given the mechanisms supported and the policy considerations of the site (export controls, for instance). 8. Declarative specifications These sections are modelled after sections 5.3 and 5.4 of RFC 959, which describe the same information, except for the standard FTP commands and replies. 8.1. FTP Security commands and arguments AUTH ADAT PROT PBSZ MIC CONF ENC ::= ::= ; must be formatted as described in section 9 ::= C | S | E | P ::= any decimal integer from 1 to (2^32)-1 Horowitz & Lunt [Page 14] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 8.2. Command-Reply sequences Security Association Setup AUTH 234 334 502, 504, 534, 431 500, 501, 421 ADAT 235 335 503, 501, 535 500, 501, 421 Data protection negotiation commands PBSZ 200 503 500, 501, 421, 530 PROT 200 504, 536, 503, 534, 431 500, 501, 421, 530 Command channel protection commands MIC 535, 533 500, 501, 421 CONF 535, 533 500, 501, 421 ENC 535, 533 500, 501, 421 Security-Enhanced login commands (only new replies listed) USER 232 336 Data channel commands (only new replies listed) STOR 534, 535 STOU 534, 535 RETR 534, 535 LIST 534, 535 NLST 534, 535 APPE 534, 535 In addition to these reply codes, any security command can return 500, 501, 502, 533, or 421. Any ftp command can return a reply code encapsulated in a 631, 632, or 633 reply once a security data exchange has completed successfully. Horowitz & Lunt [Page 15] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 9. State Diagrams This section includes a state diagram which demonstrates the flow of authentication and authorization in a security enhanced FTP implementation. The rectangular blocks show states where the client must issue a command, and the diamond blocks show states where the server must issue a response. ,------------------, USER __\| Unauthenticated |_________\ | /| (new connection) | /| | `------------------' | | | | | | AUTH | | V | | / \ | | 4yz,5yz / \ 234 | |<--------< >------------->. | | \ / | | | \_/ | | | | | | | | 334 | | | V | | | ,--------------------, | | | | Need Security Data |<--. | | | `--------------------' | | | | | | | | | | ADAT | | | | V | | | | / \ | | | | 4yz,5yz / \ 335 | | | `<--------< >-----------' | | \ / | | \_/ | | | | | | 235 | | V | | ,---------------. | | ,--->| Authenticated |<--------' | After the client and server | `---------------' | have completed authenti- | | | cation, command must be | | USER | integrity-protected if | | | integrity is available. The | |<-------------------' CCC command may be issued to | V relax this restriction. | / \ | 4yz,5yz / \ 2yz |<--------< >------------->. | \ / | | \_/ | | | | | | 3yz | | V | Horowitz & Lunt [Page 16] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 | ,---------------. | | | Need Password | | | `---------------' | | | | | | PASS | | V | | / \ | | 4yz,5yz / \ 2yz | |<--------< >------------->| | \ / | | \_/ | | | | | | 3yz | | V | | ,--------------. | | | Need Account | | | `--------------' | | | | | | ACCT | | V | | / \ | | 4yz,5yz / \ 2yz | `<--------< >------------->| \ / | \_/ | | | | 3yz | V | ,-------------. | | Authorized |/________| | (Logged in) |\ `-------------' 10. Base 64 Encoding Base 64 encoding is the same as the Printable Encoding described in Section 4.3.2.4 of [RFC-1421], except that line breaks must not be included. This encoding is defined as follows. Proceeding from left to right, the bit string resulting from the mechanism specific protection routine is encoded into characters which are universally representable at all sites, though not necessarily with the same bit patterns (e.g., although the character "E" is represented in an ASCII-based system as hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system, the local significance of the two representations is equivalent). A 64-character subset of International Alphabet IA5 is used, enabling 6 bits to be represented per printable character. (The proposed subset of characters is represented identically in IA5 and ASCII.) The character "=" signifies a special processing function used for padding within the printable encoding procedure. Horowitz & Lunt [Page 17] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right across a 24-bit input group output from the security mechanism specific message protection procedure, each 6-bit group is used as an index into an array of 64 printable characters, namely "[A-Z][a- z][0-9]+/". The character referenced by the index is placed in the output string. These characters are selected so as to be universally representable, and the set excludes characters with particular significance to Telnet (e.g., "", "", IAC). Special processing is performed if fewer than 24 bits are available in an input group at the end of a message. A full encoding quantum is always completed at the end of a message. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions which are not required to represent actual input data are set to the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. Implementors must keep in mind that the base 64 encodings in ADAT, MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily long. Thus, the entire line must be read before it can be processed. Several successive reads on the control channel may be necessary. It is not appropriate to for a server to reject a command containing a base 64 encoding simply because it is too long (assuming that the decoding is otherwise well formed in the context in which it was sent). Case must not be ignored when reading commands and replies containing base 64 encodings. 11. Security Considerations This entire document deals with security considerations related to the File Transfer Protocol. Third party file transfers cannot be secured using these extensions, since a security context cannot be established between two servers using these facilities (no control connection exists between servers over which to pass ADAT tokens). Further work in this area is deferred. Horowitz & Lunt [Page 18] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 12. Acknowledgements I would like to thank the members of the CAT WG, as well as all participants in discussions on the "cat-ietf@mit.edu" mailing list, for their contributions to this document. I would especially like to thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut, Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Kerri Balk for their contributions to this work. Of course, without Steve Lunt, the author of the first six revisions of this document, it would not exist at all. 13. References [TELNET-SEC] Borman, D., "Telnet Authentication and Encryption Option", Internet Draft, Cray Research, Inc, April 1993. [RFC-1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", RFC 1123, October 1989. [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. 14. Author's Address Marc Horowitz Cygnus Solutions 955 Massachusetts Avenue Cambridge, MA 02139 Phone: +1 617 354 7688 Email: marc@cygnus.com Appendix I: Specification under the GSSAPI In order to maximise the utility of new security mechanisms, it is desirable that new mechanisms be implemented as GSSAPI mechanisms rather than as FTP security mechanisms. This will enable existing ftp implementations to support the new mechanisms more easily, since little or no code will need to be changed. In addition, the mechanism will be usable by other protocols, such as IMAP, which are built on top of the GSSAPI, with no additional specification or implementation work needed by the mechanism designers. The security mechanism name (for the AUTH command) associated with all mechanisms employing the GSSAPI is GSSAPI. If the server supports a security mechanism employing the GSSAPI, it must respond with a 334 reply code indicating that an ADAT command is expected next. The client must begin the authentication exchange by calling GSS_Init_Sec_Context, passing in 0 for input_context_handle Horowitz & Lunt [Page 19] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 (initially), and a targ_name equal to output_name from GSS_Import_Name called with input_name_type of Host-Based Service and input_name_string of "ftp@hostname" where "hostname" is the fully qualified host name of the server with all letters in lower case. (Failing this, the client may try again using input_name_string of "host@hostname".) The output_token must then be base 64 encoded and sent to the server as the argument to an ADAT command. If GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client must expect a token to be returned in the reply to the ADAT command. This token musr subsequently be passed to another call to GSS_Init_Sec_Context. In this case, if GSS_Init_Sec_Context returns no output_token, then the reply code from the server for the previous ADAT command must have been 235. If GSS_Init_Sec_Context returns GSS_S_COMPLETE, then no further tokens are expected from the server, and the client must consider the server authenticated. The server must base 64 decode the argument to the ADAT command and pass the resultant token to GSS_Accept_Sec_Context as input_token, setting acceptor_cred_handle to NULL (for "use default credentials"), and 0 for input_context_handle (initially). If an output_token is returned, it must be base 64 encoded and returned to the client by including "ADAT=base64string" in the text of the reply. If GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be 235, and the server must consider the client authenticated. If GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code must be 335. Otherwise, the reply code should be 535, and the text of the reply should contain a descriptive error message. The chan_bindings input to GSS_Init_Sec_Context and GSS_Accept_Sec_Context should use the client address and server internet address as the initiator and acceptor addresses, respectively. The address type for both should be GSS_C_AF_INET. No application data should be specified. Since GSSAPI supports anonymous peers to security contexts, it is possible that the client's authentication of the server or vice versa does not actually establish an identity. The procedure associated with MIC commands, 631 replies, and Safe file transfers is: GSS_Wrap for the sender, with conf_flag == FALSE GSS_Unwrap for the receiver The procedure associated with ENC commands, 632 replies, and Private file transfers is: GSS_Wrap for the sender, with conf_flag == TRUE GSS_Unwrap for the receiver CONF commands and 633 replies are not supported. Both the client and server should inspect the value of conf_avail to determine whether the peer supports confidentiality services. Horowitz & Lunt [Page 20] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 When the security state is reset (when AUTH is received a second time, or when REIN is received), this should be done by calling the GSS_Delete_sec_context function. Appendix II: Specification under Kerberos version 4 The security mechanism name (for the AUTH command) associated with Kerberos Version 4 is KERBEROS_V4. If the server supports KERBEROS_V4, it must respond with a 334 reply code indicating that an ADAT command is expected next. The client must retrieve a ticket for the Kerberos principal "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name of "ftp", an instance equal to the first part of the canonical host name of the server with all letters in lower case (as returned by krb_get_phost(3)), the server's realm name (as returned by krb_realmofhost(3)), and an arbitrary checksum. The ticket must then be base 64 encoded and sent as the argument to an ADAT command. If the "ftp" principal name is not a registered principal in the Kerberos database, then the client may fall back on the "rcmd" principal name (same instance and realm). However, servers must accept only one or the other of these principal names, and must not be willing to accept either. Generally, if the server has a key for the "ftp" principal in its srvtab, then that principal only must be used, otherwise the "rcmd" principal only must be used. The server must base 64 decode the argument to the ADAT command and pass the result to krb_rd_req(3). The server must add one to the checksum from the authenticator, convert the result to network byte order (most significant byte first), and sign it using krb_mk_safe(3), and base 64 encode the result. Upon success, the server must reply to the client with a 235 code and include "ADAT=base64string" in the text of the reply. Upon failure, the server should reply 535. Upon receipt of the 235 reply from the server, the client must parse the text of the reply for the base 64 encoded data, decode it, convert it from network byte order, and pass the result to krb_rd_safe(3). The client must consider the server authenticated if the resultant checksum is equal to one plus the value previously sent. The procedure associated with MIC commands, 631 replies, and Safe file transfers is: krb_mk_safe(3) for the sender krb_rd_safe(3) for the receiver The procedure associated with ENC commands, 632 replies, and Private file transfers is: krb_mk_priv(3) for the sender krb_rd_priv(3) for the receiver Horowitz & Lunt [Page 21] draft-ietf-cat-ftpsec-09.tFxTtP Security Extensions November, 1996 CONF commands and 633 replies are not supported. Note that this specification for KERBEROS_V4 contains no provision for negotiating alternate means for integrity and confidentiality routines. Note also that the ADAT exchange does not convey whether the peer supports confidentiality services. In order to stay within the allowed PBSZ, implementors must take note that a cleartext buffer will grow by 31 bytes when processed by krb_mk_safe(3) and will grow by 26 bytes when processed by krb_mk_priv(3). Horowitz & Lunt [Page 22] --cut--   Received: from ietf.org by ietf.org id aa20356; 26 Nov 96 9:30 EST Received: from ietf.org by ietf.org id aa19667; 26 Nov 96 9:21 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: ietf-acap@andrew.cmu.edu Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-myers-acap-spec-01.txt Date: Tue, 26 Nov 1996 09:21:08 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260921.aa19667@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : ACAP -- Application Configuration Access Protocol Author(s) : J. Myers Filename : draft-myers-acap-spec-01.txt Pages : 44 Date : 11/25/1996 The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-myers-acap-spec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-myers-acap-spec-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-myers-acap-spec-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125170952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-myers-acap-spec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-myers-acap-spec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125170952.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa22886; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19303; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: grip-wg@uu.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-grip-framework-irt-03.txt Date: Tue, 26 Nov 1996 09:20:04 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19303@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the G and R for Security Incident Processing Working Group of the IETF. Title : Expectations for Security Incident Response Author(s) : N. Brownlee Filename : draft-ietf-grip-framework-irt-03.txt Pages : 25 Date : 11/25/1996 This document is intended to facilitate the setting of expectations regarding the operation of Security Incicident Response Teams (SIRTs). It describes the various important topics in the form of a 'template,' through which every SIRT should describe itself and its functions. SIRT clients have a legitimate need and right to fully understand the policies and procedures of their Security Incident Response Team. A SIRT's template supplies details for the various important topics which clients must consider when selecting a SIRT. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-grip-framework-irt-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-grip-framework-irt-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-grip-framework-irt-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125132648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-grip-framework-irt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-grip-framework-irt-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125132648.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23174; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19547; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-req-frame-00.txt Date: Tue, 26 Nov 1996 09:20:46 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19547@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Requirements and a Framework for URN Resolution Systems Author(s) : K. Sollins Filename : draft-ietf-urn-req-frame-00.txt Pages : 17 Date : 11/25/1996 This document addresses the issues of the discovery of local URN resolution services that in turn will directly translate URNs into URLs and URCs. The document falls into three major parts, the assumptions underlying the work, the requirements in order to be a viable URN-resolution-service discovery service or UDS, and a framework for designing UDSs. The requirements fall into three major areas: evolvability, usability, and security and privacy. A UDS that is compliant with the framework will not necessarily be compliant with the requirements. Compliance with the requirements will need to be validated separately. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-req-frame-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-req-frame-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-req-frame-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125154650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-req-frame-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-req-frame-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125154650.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23191; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19090; 26 Nov 96 9:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-bcast-01.txt Date: Tue, 26 Nov 1996 09:19:24 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260919.aa19090@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : IP Broadcast over ATM Networks Author(s) : T. Smith, G. Armitage Filename : draft-ietf-ion-bcast-01.txt Pages : 14 Date : 11/25/1996 This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. The solution revolves around treating the broadcast problem as a special case of multicast, where every host in the subnet or cluster is a member of the group. An understanding of the services provided by RFC 2022 is assumed. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-bcast-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-bcast-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-bcast-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125101632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-bcast-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-bcast-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125101632.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23175; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19117; 26 Nov 96 9:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-policy-arch-01.txt, .ps Date: Tue, 26 Nov 1996 09:19:31 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260919.aa19117@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : Policy Control for RSVP: Architectural Overview Author(s) : S. Herzog Filename : draft-ietf-rsvp-policy-arch-01.txt, .ps Pages : 8 Date : 11/25/1996 This memo provides insight into some possible approaches for policy enforcement in resource reservation protocols. We present sample scenarios for each of these approaches as a way to demonstrate their feasibility, and to motivate the development of supporting architectures. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-policy-arch-01.txt". Or "get draft-ietf-rsvp-policy-arch-01.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-policy-arch-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-policy-arch-01.txt". Or "FILE /internet-drafts/draft-ietf-rsvp-policy-arch-01.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125103155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-policy-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-policy-arch-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125103155.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23222; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19257; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dhcp-v4@bucknell.edu, dhcp-v6@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-08.txt Date: Tue, 26 Nov 1996 09:19:59 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19257@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, C. Perkins Filename : draft-ietf-dhc-dhcpv6-08.txt Pages : 37 Date : 11/25/1996 The Dynamic Host Configuration Protocol (DHCPv6) provides a framework for passing configuration information, via extensions, to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol should be considered a stateful counterpart to the IPv6 Stateless Address Autoconfiguration protocol specification. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcpv6-08.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-08.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125115640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125115640.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23198; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19487; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: cidrd@iepg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cidrd-classless-inaddr-02.txt Date: Tue, 26 Nov 1996 09:20:29 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19487@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CIDR Deployment Working Group of the IETF. Title : Classless IN-ADDR.ARPA delegation Author(s) : H. Eidnes, G. de Groot, P. Vixie Filename : draft-ietf-cidrd-classless-inaddr-02.txt Pages : 9 Date : 11/25/1996 This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries. The proposed method should thus remove one of the objections to subnet on non-octet boundaries but perhaps more significantly, make it possible to assign IP address space in smaller chunks than 24-bit prefixes, without losing the ability to delegate authority for the corresponding IN-ADDR.ARPA mappings. The proposed method is fully compatible with the original DNS lookup mechanisms specified in [1], i.e. there is no need to modify the lookup algorithm used, and there should be no need to modify any software which does DNS lookups either. The document also discusses some operational considerations to provide some guidance in implementing this method. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cidrd-classless-inaddr-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cidrd-classless-inaddr-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cidrd-classless-inaddr-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125143035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cidrd-classless-inaddr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cidrd-classless-inaddr-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125143035.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23227; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19528; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: hubmib@hprnd.rose.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-hubmib-etherif-mib-01.txt Date: Tue, 26 Nov 1996 09:20:26 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19528@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IEEE 802.3 Hub MIB Working Group of the IETF. Title : Definitions of Managed Objects for the Ethernet-like Interface Types Author(s) : J. Johnson Filename : draft-ietf-hubmib-etherif-mib-01.txt Pages : 22 Date : 11/25/1996 This memo is an extension to the SNMP MIB. It specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. The origin of this memo is from RFC 1650 "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2." This memo extends that specification by including management information useful for the management of 100-BaseT ethernet interfaces. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hubmib-etherif-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-hubmib-etherif-mib-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-hubmib-etherif-mib-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125142616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-etherif-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-etherif-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125142616.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23218; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19629; 26 Nov 96 9:21 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ids-dirnaming-00.txt Date: Tue, 26 Nov 1996 09:21:04 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260921.aa19629@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Directory Services Working Group of the IETF. Title : NAMING PLAN FOR AN INTERNET DIRECTORY SERVICE Author(s) : A. Grimstad, R. Huber, S. Sataluri Filename : draft-ietf-ids-dirnaming-00.txt Pages : 11 Date : 11/25/1996 Application of the conventional X.500 approach to naming has, in the experience of the authors, proven to be an obstacle to the creation of directory services. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This plan can, we believe, facilitate the creation of an Internet White Pages Service (IWPS) by overcoming the problems encountered by those using the conventional recommended X.500 approach to naming. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ids-dirnaming-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ids-dirnaming-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ids-dirnaming-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125165212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ids-dirnaming-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ids-dirnaming-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125165212.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23260; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19382; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: frs-mib@newbridge.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-frnetmib-atmiwf-00.txt Date: Tue, 26 Nov 1996 09:20:18 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19382@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Frame Relay Service MIB Working Group of the IETF. Title : Managed Objects for Monitoring and Controlling the Frame Relay/ATM Service Interworking Function Author(s) : G. Mouradian Filename : draft-ietf-frnetmib-atmiwf-00.txt Pages : 14 Date : 11/25/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to monitor and control the Frame Relay/ATM PVC Service Interworking Function described in [9]. This MIB may be implemented in equipment that performs the interworking function, and may also be used by service providers at a Customer Network Management (CNM) interface when the interworking function is performed within the service network. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-frnetmib-atmiwf-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-frnetmib-atmiwf-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-frnetmib-atmiwf-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125140313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-frnetmib-atmiwf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-frnetmib-atmiwf-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125140313.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23279; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19476; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ospf@gated.cornell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv6-03.txt Date: Tue, 26 Nov 1996 09:20:38 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19476@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF for IPv6 Author(s) : R. Coltun, D. Ferguson, J. Moy Filename : draft-ietf-ospf-ospfv6-03.txt Pages : 92 Date : 11/25/1996 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field- and packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. Please send comments to ospf@gated.cornell.edu. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv6-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-ospfv6-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv6-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125153507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv6-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv6-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125153507.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23280; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19200; 26 Nov 96 9:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gellens-submit-02.txt Date: Tue, 26 Nov 1996 09:19:46 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260919.aa19200@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : SMTP Message Submission and Relay Author(s) : H. Alvestrand, R. Gellens Filename : draft-gellens-submit-02.txt Pages : 6 Date : 11/25/1996 SMTP was defined as a message *relay* protocol, that is, a means for message transfer agents (MTAs) to route finished (complete) messages. SMTP forbids MTAs from altering the message text, except to add Received headers. However, SMTP is now also widely used as a message *submission* protocol, that is, a means for message user agents (MUAs) to introduce new messages into the MTA routing network. Regardless of whether this is good or bad, it is far too late to change. Messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in some aspect or other. Unfinished (incomplete) messages need to be completed to ensure they conform to [RFC-822], [RFC-1123], and later requirements. For example, the message may lack proper Date or Message-ID headers, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished (complete) messages (for example, it might not know its time zone). Even when submitted messages are finished (complete), local site policy may dictate that the message text be modified in some ways. Such completions or modifications violate the letter and spirit of SMTP when used as a relay protocol. This memo proposes a low cost, deterministic means for messages to be identified as submissions or relays. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gellens-submit-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-gellens-submit-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-gellens-submit-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125105739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gellens-submit-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-gellens-submit-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125105739.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23278; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19221; 26 Nov 96 9:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: cat-ietf@mit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-sesamemech-01.txt Date: Tue, 26 Nov 1996 09:19:49 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260919.aa19221@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : The SESAME V5 GSS-API Mechanism Author(s) : E. Baize, S. Farrell, T. Parker Filename : draft-ietf-cat-sesamemech-01.txt Pages : 60 Date : 11/25/1996 This specification defines protocols, data elements, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the SESAME Version 5 Mechanism. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-sesamemech-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-sesamemech-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-sesamemech-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125113050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-sesamemech-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-sesamemech-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125113050.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23282; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19404; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kim-jtc1-sc6-ects-00.txt Date: Tue, 26 Nov 1996 09:20:23 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19404@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhanced Communications Transport Service Definition Author(s) : D. Kim Filename : draft-kim-jtc1-sc6-ects-00.txt Pages : 72 Date : 11/25/1996 This memo is the Committee Draft of the Enhanced Transport Service Definition under development within ISO/IEC JTC1/SC6/WG7 since last several years in order to provide to the upper-layer applications enhanced trasnport services over the current OSI transport service; major enhancements include multicast services and enhanced QoS. This memo is distributed to possibly interested groups within IETF, especially to experts in Transport Area, to make noticed the efforts being made within SC6 to come up with a new transport service definition meeting the needs of the both current and future multimedia multicast applications of widely varing ranges service requirements. It is to be noted that a protocol named ECTP(Enhanced Communications Transport Protocol) supporting this ECTS is also under development within SC6 and will be made public in the near future. Experts interested in this topic might compare the services defined by ECTS with those provided by more known protocols including RTP, MTP, RMP, and RAMP. The ultimate apparent objective of ECTS is the multimedia multicast transport service with varyin degress of reliability and multicast QoS. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kim-jtc1-sc6-ects-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-kim-jtc1-sc6-ects-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kim-jtc1-sc6-ects-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125142222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kim-jtc1-sc6-ects-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kim-jtc1-sc6-ects-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125142222.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23344; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19277; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ospf@gated.cornell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-opaque-00.txt Date: Tue, 26 Nov 1996 09:20:02 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19277@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : The OSPF Opaque LSA Option Author(s) : R. Coltun Filename : draft-ietf-ospf-opaque-00.txt Pages : 13 Date : 11/25/1996 This memo documents enhancements to the OSPF protocol to support a new type of link-state advertisement (LSA) called the Opaque LSA. The Opaque LSA option defines a general mechanism to allow for future extensibility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or by other protocols. Opaque LSAs contain some number of octets padded to 32-bit alignment. The standard OSPF link-state database flooding mechanisms are use for distribution of Opaque LSAs. Opaque LSAs are flooded throughout all or some limited portion of the OSPF topology. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-opaque-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-opaque-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ospf-opaque-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125132131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-opaque-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-opaque-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125132131.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23370; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19365; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-holtman-http-safe-01.txt Date: Tue, 26 Nov 1996 09:20:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19365@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Safe Response Header Author(s) : K. Holtman Filename : draft-holtman-http-safe-01.txt Pages : 3 Date : 11/25/1996 This document proposes a HTTP response header called Safe, which can be used to label the corresponding POST request as being safe. This labeling will allow user agents to present services which use safe POSTs in a more user-friendly way. Improving the user-friendliness of safe POSTs is considered important, because web internationalization will depend for a large part on the use of safe POSTs. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-holtman-http-safe-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-holtman-http-safe-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-holtman-http-safe-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125135932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-holtman-http-safe-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-holtman-http-safe-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125135932.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23319; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19697; 26 Nov 96 9:21 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: oncrpc-wg@sunroof.eng.sun.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-oncrpc-rpcsec_gss-01.txt Date: Tue, 26 Nov 1996 09:21:13 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260921.aa19697@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ONC Remote Procedure Call Working Group of the IETF. Title : RPCSEC_GSS Protocol Specification Author(s) : M. Eisler, A. Chiu, L. Ling Filename : draft-ietf-oncrpc-rpcsec_gss-01.txt Pages : 23 Date : 11/25/1996 This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-oncrpc-rpcsec_gss-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-oncrpc-rpcsec_gss-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125171807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-oncrpc-rpcsec_gss-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125171807.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23355; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19100; 26 Nov 96 9:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-06.txt, .ps Date: Tue, 26 Nov 1996 09:19:21 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260919.aa19100@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner Filename : draft-ietf-ipsec-isakmp-06.txt, .ps Pages : 78 Date : 11/25/1996 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-06.txt". Or "get draft-ietf-ipsec-isakmp-06.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-06.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-06.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-06.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125101043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125101043.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23350; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19133; 26 Nov 96 9:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-policy-ext-01.txt, .ps Date: Tue, 26 Nov 1996 09:19:34 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260919.aa19133@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : RSVP Extensions for Policy Control Author(s) : S. Herzog Filename : draft-ietf-rsvp-policy-ext-01.txt, .ps Pages : 16 Date : 11/25/1996 This memo describes a set of extensions for supporting generic policy based admission control in RSVP. [Note 1] This document does not advocate particular policy control mechanisms; however, a recommendation for a mechanism built on top of these extensions can be found in [LPM]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-policy-ext-01.txt". Or "get draft-ietf-rsvp-policy-ext-01.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-policy-ext-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-policy-ext-01.txt". Or "FILE /internet-drafts/draft-ietf-rsvp-policy-ext-01.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125103545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-policy-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-policy-ext-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125103545.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23390; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19241; 26 Nov 96 9:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: frs-mib@newbridge.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ieft-frnetmib-frs-mib-00.txt Date: Tue, 26 Nov 1996 09:19:57 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260919.aa19241@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Frame Relay Service MIB Working Group of the IETF. Title : Definitions of Managed Objects for Frame Relay Service Author(s) : D. Fowler Filename : draft-ieft-frnetmib-frs-mib-00.txt Pages : 64 Date : 11/25/1996 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. This memo does not specify a standard for the Internet community. This document entirely replaces RFC 1604. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ieft-frnetmib-frs-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ieft-frnetmib-frs-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ieft-frnetmib-frs-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125114547.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ieft-frnetmib-frs-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ieft-frnetmib-frs-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125114547.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23349; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19422; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-calendar@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-sch-00.txt Date: Tue, 26 Nov 1996 09:20:21 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19422@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : MIME application/calendar Content Type Author(s) : D. Stenerson, A. Dun Filename : draft-ietf-calsch-sch-00.txt Pages : 50 Date : 11/25/1996 This document defines a MIME message format for openly scheduling meetings with others across the Internet. This definition is independent of any particular scheduling application. A new MIME Content-Type "APPLICATION/CALENDAR" is defined to contain scheduling data, including appointments, appointment requests for single events, appointment requests for recurring events, appointment responses. The scope of this revision of the draft is the MIME format for meeting requests and responses. This the "on the wire" format; no attempt is made to define the storage format for the calendar information. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-sch-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-sch-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-calsch-sch-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125141652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-sch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-sch-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125141652.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa25087; 26 Nov 96 9:35 EST Received: from ietf.org by ietf.org id aa19565; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-degermark-ipv6-hc-02.txt Date: Tue, 26 Nov 1996 09:20:48 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19565@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Header Compression for IPv6 Author(s) : M. Degermark, B. Nordgren, S. Pink Filename : draft-degermark-ipv6-hc-02.txt Pages : 45 Date : 11/25/1996 This document describes how to compress IPv6 headers per-hop over point-to-point links. The methods can be applied to IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 byte UDP or TCP checksum. This largely removes the negative impact of large headers and allows efficient use of bandwidth on low- and medium-speed links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-degermark-ipv6-hc-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-degermark-ipv6-hc-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-degermark-ipv6-hc-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125155111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-degermark-ipv6-hc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-degermark-ipv6-hc-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125155111.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ab25087; 26 Nov 96 9:35 EST Received: from ietf.org by ietf.org id aa19594; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-mars-mib-00.txt Date: Tue, 26 Nov 1996 09:20:53 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19594@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks Author(s) : C. Chung, M. Greene Filename : draft-ietf-ion-mars-mib-00.txt Pages : 54 Date : 11/25/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in "Support for Multicast over UNI 3.0/3.1 based ATM Networks" [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-mars-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-mars-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-mars-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125163237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-mars-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-mars-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125163237.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ac25087; 26 Nov 96 9:35 EST Received: from ietf.org by ietf.org id aa19609; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ghanwani-framework-is-lan-01.txt Date: Tue, 26 Nov 1996 09:20:57 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19609@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies Author(s) : A. Ghanwani, W. Pace, V. Srinivasan Filename : draft-ghanwani-framework-is-lan-01.txt Pages : 8 Date : 11/25/1996 Traditionally, LAN technologies such as ethernet and token ring have been required to handle best effort services only. No standard mechanism exists for providing bandwidth or delay guarantees on these media. It is therefore not possible to provide guaranteed quality of service as will be required by emerging and future multimedia applications. The anticipated demand for real-time applications on the Internet has led to the development of RSVP, a signaling mechanism for performing resource reservation in the Internet. Concurrently, the Integrated Services working group within the IETF has been working on the definition of service classes called "Integrated Services" which are expected to make use of RSVP. Applications will use these service classes in order to obtain the desired quality of service from the network. LAN technologies such as token ring and ethernet typically constitute the last hop in Internet connections. There is therefore a need to enhance these technologies so that they are able to support the Integrated Services. In order to enable such services, it is necessary to provide a resource management functions. This memo describes a framework for providing the necessary functionality on shared and switched LAN technologies. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ghanwani-framework-is-lan-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ghanwani-framework-is-lan-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ghanwani-framework-is-lan-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125164511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ghanwani-framework-is-lan-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ghanwani-framework-is-lan-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125164511.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa25896; 26 Nov 96 9:40 EST Received: from ietf.org by ietf.org id aa19326; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-mime-direct-03.txt Date: Tue, 26 Nov 1996 09:20:07 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19326@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : A MIME Content-Type for Directory Information Author(s) : T. Howes, M. Smith Filename : draft-ietf-asid-mime-direct-03.txt Pages : 26 Date : 11/25/1996 This document defines a MIME Content-Type for holding directory information. The definition is independent of any particular directory service or protocol. The application/directory Content-Type is defined for holding a variety of directory information, for example, name, or email address. The application/directory Content-Type can also be used as the root body part in a multipart/related Content-Type for handling more complicated situations, especially those in which non-textual information that already has a natural MIME representation, for example, a photograph or sound, must be represented. The application/directory Content-Type defines a general framework and format for holding directory information in a simple "type: value" format. Mechanisms are defined to specify alternate character sets, languages, encodings and other meta-information. This document also defines the procedure by which particular formats, called profiles, for carrying application-specific information within an application/directory Content-Type may be defined and registered, and the conventions such formats must follow. It is expected that other documents will be produced that define such formats for various applications (e.g., white pages). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-asid-mime-direct-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-mime-direct-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-mime-direct-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125133651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-mime-direct-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-mime-direct-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125133651.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa28677; 26 Nov 96 9:52 EST Received: from ietf.org by ietf.org id aa27850; 26 Nov 96 9:46 EST To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: ciscoevent@mtgs.com Subject: IETF Social - Hosted by Cisco Systems Date: Tue, 26 Nov 1996 09:46:01 -0500 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9611260946.aa27850@ietf.org> Cisco Systems presents an exclusive evening of food and entertainment at San Jose's premier night spot... San Jose Live! * Watch current basketball, hockey and football games live on more than 50 large-screen video monitors! * Play basketball game with your friends! * Ski down a virtual, snow-covered mountain! * Play unlimited arcade games and pool! * Receive your complimentary Cisco T-shirt! * Eat your fill of a variety of fantastic foods! * Dance to your favorite music! DATE: Tuesday, December 10, 1996 TIME: 6:30 p.m. LOCATION: San Jose Live! 150 S. First Street San Jose, CA San Jose Live! is located within walking distance of all conference hotels. RESERVATIONS: To reserve your place at this event, complete the information below and return via e-mail to: ciscoevent@mtgs.com. PAYMENT: US$30.00 in advance, US$35.00 at the door (cash or check drawn on U.S. bank only). Advance payment will be taken at the Social Event table near the IETF Registration Desk during the following hours. Sunday, December 8: 5:00 p.m. to 7:00 p.m. Monday, December 9: 12 noon to 7:30 p.m. Tuesday, December 10: 8:00 a.m. to 5:00 p.m. COCKTAILS AND DINNER: Hosted beer and wine will be served from 6:30 p.m. to 9:00 p.m. ---------- Menu ---------- * Juicy quarter-pound burgers or veggie burgers, a selection of gourmet sausages accompanied by your favorite toppings, and mountains of french fries * Down-home Texas-style ribs, baked beans, potato salad, and corn muffins * Build-your-own fajitas-how big can they get? * Assorted California pizzas, including vegetarian selections ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ R E G I S T R A T I O N F O R M RSVP to: ciscoevent@mtgs.com. SUBJECT: RSVP IETF Social San Jose IETF Social Presented by Cisco Systems, Inc. San Jose Live! Tuesday, December 10, 1996 6:30 p.m. Cash (U.S. dollars) or personal checks (drawn on U.S. banks) are acceptable. Credit cards, purchase orders, money orders, bank checks, and traveler's checks cannot be accepted. NAME: _________________________ ORGANIZATION: _________________________ Number of reservations requested: _________   Received: from cnri by ietf.org id aa02280; 26 Nov 96 10:46 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa13528; 26 Nov 96 10:46 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id KAA23470 for ; Tue, 26 Nov 1996 10:44:54 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id KAA25437 for disman-out; Tue, 26 Nov 1996 10:44:23 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA25428 for ; Tue, 26 Nov 1996 10:44:20 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id KAA12834 for ; Tue, 26 Nov 1996 10:42:49 -0500 (EST) Received: from ietf.org by ietf.org id aa19459; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-script-mib-00.txt Date: Tue, 26 Nov 1996 09:20:35 -0500 Message-ID: <9611260920.aa19459@ietf.org> Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for the Delegation of Management Scripts Author(s) : D. Levi, J. Schoenwaelder Filename : draft-ietf-disman-script-mib-00.txt Pages : 33 Date : 11/25/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allows the delegation of management scripts to mid-level managers. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-script-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-disman-script-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-disman-script-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125152532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-script-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-script-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125152532.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11520; 26 Nov 96 13:08 EST Received: from ietf.org by ietf.org id aa10619; 26 Nov 96 12:50 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: hubmib@hprnd.rose.hp.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Protocol Action: Definitions of Managed Objects for IEEE 802.3 Repeater Devices to Proposed Standard Date: Tue, 26 Nov 1996 12:50:36 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611261250.aa10619@ietf.org> The IESG has approved the Internet-Draft "Definitions of Managed Objects for IEEE 802.3 Repeater Devices" as a Proposed Standard. This document is the product of the IEEE 802.3 Hub MIB Working Group. The IESG contact person is Deirdre Kostick. Technical Summary This document identifies the set of objects for use in managing Ethernet-like hubs. A hub is defined as a multiport repeater that conforms to Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE 802.3/ISO 8802-3 CSMA/CD standard, 1993 or to Section 27, "Repeater for 100 Mb / s Baseband Networks" in the IEEE Standard 802.3u (October 26, 1995). Working Group Summary The document is the result of the collective work of the IEEE 802.3 HUB MIB (hubmib) WG, which met four times in face-to-face meetings and cooperated intensively on the mailing list. There was no significant dissent in the WG to the proposed document. Protocol Quality The document was reviewed for the IETF NM Area by Bob Stewart (bstewart@cisco.com) and by Deirdre Kostick for the IESG. Several WG members reported that they are working on implementations.   Received: from ietf.org by ietf.org id aa11866; 26 Nov 96 13:13 EST Received: from ietf.org by ietf.org id aa11679; 26 Nov 96 13:09 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Protocol Action: HMAC-MD5 IP Authentication with Replay Prevention to Proposed Standard Date: Tue, 26 Nov 1996 13:09:54 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611261309.aa11679@ietf.org> The IESG has approved the Internet-Drafts 1. HMAC-MD5 IP Authentication with Replay Prevention and 2. HMAC-SHA IP Authentication with Replay Prevention as Proposed Standards. The IESG also approved the reclassification of RFC1828, IP Authentication using Keyed MD5, from Proposed Standard to Historic. These documents are the product of the IP Security Protocol Working Group. The IESG contact person is Jeffrey Schiller. Technical Summary These documents describe two similar Keyed Hashes (one based on MD5 and the other based on SHA) for use in IP Security's Authentication Header (both IPv4 and IPv6). Hashes such as MD5 and SHA were designed to be used as "keyless" hashes which can be used in digital signature systems such as the RSA system and the U.S. Digital Signature Standard (DSS). An obvious approach to using them as "keyed" hashes has involved either prepending the data to be hashed with a secret value (key) or appending the secret value after the data to be hashed (or both). However recently significant analysis work has been carried out by cryptographers as to security of keyed modes of these hashes. The keyed hash mechanism described in these documents benefits from this analytical experience and is therefore believed to be much stronger than the simplistic approaches taken to date in the Internet community (both in AH and SNMP). Working Group Summary These documents are the work product of the IP Security Working Group. The group has come to consensus that these hashes are good approaches to the keyed hash function required by the Authentication Header. Protocol Quality This protocol has been reviewed by Jeffrey I. Schiller, Security Area Director.   Received: from ietf.org by ietf.org id aa12048; 26 Nov 96 13:15 EST Received: from ietf.org by ietf.org id aa11926; 26 Nov 96 13:13 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Document Action: HMAC-MD5: Keyed-MD5 for Message Authentication to Informational Date: Tue, 26 Nov 1996 13:13:51 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611261313.aa11926@ietf.org> The IESG has reviewed the Internet-Draft "HMAC: Keyed-Hashing for Message Authentication" and recommends that it be published by the RFC Editor as an Informational RFC. This document is the product of the IP Security Protocol Working Group. The IESG contact person is Jeffrey Schiller.   Received: from ietf.org by ietf.org id aa12238; 26 Nov 96 13:17 EST Received: from ietf.org by ietf.org id aa12129; 26 Nov 96 13:15 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Sender:ietf-announce-request@ietf.org From: The IESG Subject: Protocol Action: IMAP/POP AUTHorize Extension for Simple Challenge/Response to Proposed Standard Date: Tue, 26 Nov 1996 13:15:47 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611261315.aa12129@ietf.org> The IESG has approved the Internet-Draft "IMAP/POP AUTHorize Extension for Simple Challenge/Response" as a Proposed Standard. The IESG contact persons are Keith Moore and Harald Alvestrand. Technical Summary This document describes an authentication mechanism for use with IMAPv4 and POP that is: - As simple to administer as cleartext passwords (shared secret) - Does not run out of passwords like currently-defined OTPs - Is sound against snooping attacks It does not offer data integrity or confidentiality. The method used is fairly widely understood and established. The cryptographic strength is dependent on the strength of MD5. Working Group Summary The protocol has not been reviewed by an IETF working group. There has been review by individuals who are knowledgeable in the IMAP area and in the security area. Protocol Quality The protocol has been reviewed for the IESG by Harald Alvestrand.   Received: from cnri by ietf.org id aa18368; 26 Nov 96 15:27 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22169; 26 Nov 96 15:27 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Tue, 26 Nov 1996 19:10:30 GMT From: brian@isi.edu Received: from venera.isi.edu by MIT.EDU with SMTP id AA16036; Tue, 26 Nov 96 14:10:15 EST Received: from dot.isi.edu by venera.isi.edu (5.65c/5.61+local-25) id ; Tue, 26 Nov 1996 11:10:13 -0800 Date: Tue, 26 Nov 1996 11:08:58 -0800 Posted-Date: Tue, 26 Nov 1996 11:08:58 -0800 Message-Id: <199611261908.AA01717@dot.isi.edu> Received: by dot.isi.edu (5.65c/4.0.3-4) id ; Tue, 26 Nov 1996 11:08:58 -0800 To: cat-ietf@mit.edu Subject: New Internet-Draft: pk-cross The following draft has been posted to the Internet Drafts server. It is a sort of companion draft to pk-init; it specifies emendments to RFC 1510 providing for public key support for cross-realm authentication. This draft was initially labelled improperly as ...-pk-cross-01.txt; I've asked it to be changed to ...-pk-cross-00.txt but you might want to look for it under both names. Brian Tung brian@isi.edu ===== INTERNET-DRAFT Brian Tung draft-ietf-cat-kerberos-pk-cross-00.txt Tatyana Ryutov Updates: RFC 1510 Clifford Neuman expires May 25, 1997 ISI Public Key Cryptography for Cross-Realm Authentication in Kerberos 0. Status Of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as draft-ietf-cat-kerberos-pk-cross-00.txt, and expires May 25, 1997. Please send comments to the authors. 1. Abstract This document defines extensions to the Kerberos protocol specification (RFC 1510, "The Kerberos Network Authentication Service (V5)", September 1993) to provide a method for using public key cryptography during cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. 2. Motivation The advantages provided by public key cryptography--resistance to key attacks, ease of recoverability in the event of a compromise, the possibility of an autonomous authentication infrastructure, to name a few--have produced a demand for use by Kerberos authentication protocol. A draft describing the use of public key cryptography in the initial authentication exchange in Kerberos has already been submitted. This draft describes its use in cross-realm authentication. The principal advantage provided by public key cryptography in cross-realm authentication lies in the ability to leverage the existing public key infrastructure. It frees the Kerberos realm administrator from having to maintain separate keys for each other realm with which it wishes to exchange authentication information, or to utilize a hierarchical arrangement, which may pose problems of trust. Even with the advent of chained cross-realm authentication, there must be some way to locate the path by which separate realms are to be transited. The current method, which makes use of the DNS-like realm names typical to Kerberos, requires trust of the intermediate KDCs. The methods described in this draft allow a realm to specify, at the time of authentication, which certification paths it will trust. A shared key for cross-realm authentication can be established, for a period of time. Furthermore, these methods are transparent to the client, so that only the KDC's need to be modified to use them. It is not necessary to implement the changes described in the "Public Key Cryptography for Initial Authentication" draft to make use of the changes in this draft. We solicit comments about the interaction between the two protocol changes, but as of this writing, the authors do not perceive any obstacles to using both. 3. Protocol Emendments We assume that the user has already obtained a TGT. To perform cross-realm authentication, the user sends a request to the local KDC as per RFC 1510. If the two realms share a secret key, then cross-realm authentication proceeds as usual. Otherwise, the local KDC may attempt to establish a shared key with the remote KDC using public key cryptography. We first address the case in which the local KDC has and trusts the remote KDC's public key certificate. If it does not, then the two KDCs must exchange public keys, as described below in Section 3.2. We will consider the specific channel on which the message exchanges take place in Section 5 below. 3.1. Shared Key Exchange The local KDC sends a message to the remote KDC containing the shared key to be used to perform cross-realm authentication, encrypted with the remote KDC's public key, and signed with the local KDC's private key: PKX-SHARED-KEY-SEND ::= [APPLICATION 31] SEQUENCE { signedKeyPack [0] SignedKeyPack, pubKeyCert [1] Certificate } SignedKeyPack ::= SEQUENCE { keyPack [0] KeyPack, sigKeyPack [1] Signature -- of keyPack } KeyPack ::= SEQUENCE { encKeyData [0] EncryptedData, -- of type KeyData timestamp [1] KerberosTime, keyPackNonce [2] INTEGER } KeyData ::= SEQUENCE { sharedKey [0] EncryptionKey, keyExpiration [1] KerberosTime OPTIONAL, } Signature ::= SEQUENCE { sigType [0] INTEGER, kvno [1] INTEGER OPTIONAL, signedHash [2] OCTET STRING } where pubKeyCert contains the public key of the local KDC. Its exact form will depend on the particular public key service used by the local KDC. Upon receiving of the PKX-SHARED-KEY-SEND, the remote KDC attempts to verify the pubKeyCert. If it cannot verify the public key certificate, or if it finds the key unacceptable, the remote KDC returns an error message. Otherwise, it returns a message to the local KDC, signed by the remote KDC's private key, acknowledging receipt of the shared key: PKX-SHARED-KEY-ACK ::= [APPLICATION 32] SEQUENCE { ackPack [0] AckPack, sigAckPack [1] Signature -- of ackPack } AckPack ::= SEQUENCE { timestamp [0] KerberosTime, keyPackNonce [1] INTEGER, -- from type KeyPack ackNonce [2] INTEGER -- new nonce } Since it is presumed that the local KDC has and trusts the remote KDC's public key, this key does not need to be included in its acknowledgment. Upon receipt of this acknowledgment, the local KDC issues a ticket to the client, encrypted with the shared key distributed using the above exchange. This shared key can then be used for all subsequent cross-realm authentications to that particular remote KDC, for all clients, until the key expires. The transited field of all such tickets should indicate, in addition to any realms transited, the certification path used to verify the local KDC's public key. 3.2. Public Key Exchange In the event that the local KDC does not have the remote KDC's public key certificate, it must perform an exchange to obtain it. It begins by sending a message to the remote KDC, signed by the local KDC's private key: PKX-PUBLIC-KEY-SEND ::= [APPLICATION 33] SEQUENCE { signedListPack [0] SignedListPack, pubKeyCert [1] Certificate } SignedListPack ::= SEQUENCE { listPack [0] ListPack, sigListPack [1] Signature -- of listPack } ListPack ::= SEQUENCE { listTrust [0] SEQUENCE OF OCTET STRING, timestamp [1] KerberosTime, listPackNonce [2] INTEGER } where listTrust is a list of certifiers trusted by the local KDC. Upon receipt of the PKX-PUBLIC-KEY-SEND, the remote KDC checks to see if its own public key is certified by one of the trusted certifiers. If not, or if the signature is invalid, then it returns an error message. Otherwise, there are two cases: either the remote KDC trusts the local KDC's public key certificate, or it does not. If it does not, then it sends back an error message with an e-data field of PKX-PUBLIC-KEY-ERROR ::= [APPLICATION 35] SEQUENCE { signedListPack [0] SignedListPack, pubKeyCert [1] Certificate } where the signedListPack contains a list of certifiers trusted by the *remote* KDC, and the pubKeyCert is the remote KDC's public key certificate, certified by one of the local KDC's trusted certifiers. If the local KDC does not have a certificate signed by one of the remote KDC's trusted certifiers, then it returns an error message to the client. Otherwise, it resends the PKX-PUBLIC-KEY-SEND, this time with a new public key certificate. If the remote KDC does trust the local KDC's public key, then it sends back an acknowledgment: PKX-PUBLIC-KEY-ACK ::= [APPLICATION 34] SEQUENCE { signedPubAck [0] SignedPubAck, pubKeyCert [1] Certificate } SignedPubAck ::= SEQUENCE { pubAckPack [0] PubAckPack, sigPubAck [1] Signature -- of pubAckPack } PubAckPack ::= SEQUENCE { timestamp [0] KerberosTime, listPackNonce [1] INTEGER, -- from listPack pubAckNonce [2] INTEGER -- new nonce } Upon verification of the PKX-PUBLIC-KEY-ACK, the local KDC then proceeds with the basic exchange from Section 3.1. 4. Finding Realms Supporting PK-CROSS If either the local realm or the destination realm does not support PK-CROSS, or both do not, the mechanism specified in Section 3 can still be used in obtaining the desired remote TGT. In the reference Kerberos implementations, the default behavior is to traverse a path up and down the realm name hierarchy, if the two realms do not share a key. There is, however, the possibility of using cross links--i.e., keys shared between two realms that are non-contiguous in the realm name hierarchy--to shorten the path, both to minimize delay and the number of intermediate realms that need to be trusted. PK-CROSS can be used as a way to provide cross-links even in the absence of shared keys. If the client is aware that one or two intermediate realms support PK-CROSS, then a combination of PK-CROSS and conventional cross-realm authentication can be used to reach the final destination realm. We solicit discussion on the best methods for clients and KDCs to determine or advertise support for PK-CROSS. 5. Message Ports We have not specified the port on which KDCs supporting PK-CROSS should listen to receive the additional messages described above. We solicit discussion on which port should be used. We propose to use the standard Kerberos ports (well-known 88 or 750), but another possibility is to use the kadmin port. 6. Authors' Addresses Brian Tung USC/Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey, CA 90292-6695 Phone: 310-822-1511 E-Mail: brian@isi.edu Tatyana Ryutov USC/Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey, CA 90292-6695 Phone: 310-822-1511 E-Mail: tryutov@isi.edu Clifford Neuman USC/Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey, CA 90292-6695 Phone: 310-822-1511 E-Mail: bcn@isi.edu   Received: from cnri by ietf.org id aa21011; 26 Nov 96 16:05 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23432; 26 Nov 96 16:05 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Tue, 26 Nov 1996 20:02:06 GMT Received: from capone.ch.apollo.hp.com by MIT.EDU with SMTP id AA20820; Tue, 26 Nov 96 15:02:00 EST Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Tue, 26 Nov 1996 15:01:42 -0500 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id PAA01742; Tue, 26 Nov 1996 15:01:32 -0500 (EST) Message-Id: <199611262001.PAA01742@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: brian@isi.edu Cc: cat-ietf@mit.edu Subject: Re: New Internet-Draft: pk-cross In-Reply-To: brian's message of Tue, 26 Nov 1996 11:08:58 -0800. <199611261908.AA01717@dot.isi.edu> Date: Tue, 26 Nov 1996 15:01:22 -0500 From: Bill Sommerfeld The use of public key techniques for inter-realm kerberos has the possibility of improving the scalability of kerberos. Unfortunately, this proposal appears to have problems with respect to replicated KDC's. Most current kerberos KDC implementations support master/slave replication of a mostly read-only database. Some even support dynamic change in the site which is the master. Most current kerberos client implementations do dynamic selection of KDC's on each request. The proposed protocol involves the dynamic creation of a key in *both* KDC's. In order to behave reliably in the presence of replication, the shared state creation operation needs to block until the shared state had been propagated to all KDC replicas of both realms. In the event that one or more replicas are down, it may take several minutes for the replication machinery to recognise that one replica is off the air. I think a better approach would be to use public key techniques to encrypt/sign the cross-realm TGT; as the TGT is opaque to the client, the client need not be aware that public key is in use (though a cross-realm TGT may be ~250 bytes larger than a shared-secret cross-realm TGT). - Bill   Received: from cnri by ietf.org id aa26829; 26 Nov 96 21:40 EST Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa00980; 26 Nov 96 21:40 EST Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA15576 for ipsec-outgoing; Tue, 26 Nov 1996 21:35:20 -0500 (EST) Message-Id: <9611270235.AA11031@sol.hq.tis.com> To: cat-ietf@mit.edu, e-payment@bellcore.com, firewalls@greatcircle.com, ids@uow.edu.au, ietf-otp@bellcore.com, ietf-pkix@tandem.com, ietf-tls@w3.org, ietf@CNRI.Reston.VA.US, ipsec@ans.net, pem-dev@tis.com, psrg@isi.edu, sndss-authors@isi.edu, sndss-chairs@tis.com, spki@c2.net, virus-l@lehigh.edu, www-buyinfo@allegra.att.com, www-security@ns2.rutgers.edu Subject: ANNOUNCEMENT: ISOC 1997 SYMPOSIUM NETWORK & DISTRIBUTED SYSTEM SECURITY Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <11027.849062106.1@tis.com> Date: Tue, 26 Nov 1996 21:35:11 -0500 From: "David M. Balenson" Sender: owner-ipsec@ex.tis.com Precedence: bulk --------------------------------------------------------------------------- THE INTERNET SOCIETY 1997 SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS '97) 10-11 FEBRUARY 1997 SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA This fourth annual symposium will bring together researchers, implementors, and users of network and distributed system security technologies to discuss today's important security issues and challenges. It will provide a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical, and to the extent possible, have been implemented. We hope to foster the exchange of technical information and encourage the Internet community to deploy available security technologies and develop new solutions to unsolved problems. WHY YOU SHOULD ATTEND The use of the Internet is rapidly growing and expanding into all aspects of our society. Commercial organizations are coming under increasing pressure to make their services available on-line. This in turn is increasing the need for rapid and widespread deployment of usable and effective network and distributed system security technologies. High visibility attacks on the Internet underscore the vulnerabilities of the Internet and the need to solve its security problems. There is growing concern for securing the network infrastructure itself. Recent trends in software distribution (such as Java and ActiveX technologies) have made certain attacks easier to carry out. Privacy has become an important issue for the Internet. NDSS '97 will bring together researchers, implementors, and users of network and distributed system technologies to discuss today's important security issues and challenges. We have selected the technical papers and panel presentations that describe promising new approaches to security problems that are practical, and to the extent possible, have been implemented. Topics to be addressed include Internet infrastructure and routing security, security for the World Wide Web, Java and ActiveX security, cryptographic protocols, public key management, and protection of privacy. The symposium will have a positive impact on the state of Internet security. You will have the opportunity to actively participate in the dialog. Ask questions of the speakers, raise your important issues during the panel sessions, and let other participants know of your requirements, observations, and experience in this important area. We hope to encourage the wide-scale deployment of security technologies and to promote new research that can address the currently unmet security needs of the Internet community. CONTENTS Preliminary Program Organizing Committee San Diego Princess Resort Registration Information Registration Form --------------------------------------------------------------------------- P R E L I M I N A R Y P R O G R A M SUNDAY, FEBRUARY 9 6:00 P.M. - 8:00 P.M. RECEPTION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MONDAY, FEBRUARY 10 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. OPENING REMARKS 9:00 A.M. SESSION 1: THINGS THAT GO BUMP IN THE NET Chair: Stephen T. Kent (BBN Corporation, USA) Experimental Results of Covert Channel Elimination in One-Way Communication Systems, Nick Ogurtsov, Hilarie Orman, Richard Schroeppel, Sean O'Malley, and Oliver Spatscheck (University of Arizona, USA) Blocking Java Applets at the Firewall, David M. Martin Jr., Sivaramakrishnan Rajagopalan and Aviel D. Rubin (Bellcore, USA) Continuous Assessment of a Unix Configuration: Integrating Intrusion Detection & Configuration Analysis, Abdelaziz Mounji and Baudouin Le Charlier (Institut D'Informatique, Namur, BELGIUM) 10:30 A.M. BREAK 11:00 A.M. SESSION 2: PANEL: SECURITY OF DOWNLOADABLE EXECUTABLE CONTENT Chair: Aviel Rubin (Bellcore, USA) 12:30 NOON LUNCH 2:00 P.M. SESSION 3: PROTOCOL IMPLEMENTATION AND ANALYSIS Chair: Christoph Schuba (Purdue University, USA) An Interface Specification Language for Automatically Analyzing Cryptographic Protocols, Stephen H. Brackin (Arca Systems, USA) Probable Plaintext Cryptanalysis of the IP Security Protocols, Steven M. Bellovin (AT&T Research, USA) Misplaced Trust: Kerberos Version 4 Session Keys, Bryn Dole (Sun Microsystems), Steve Lodin (Delco Electronics), and Eugene Spafford (Purdue University, USA) 3:30 P.M. BREAK 4:00 P.M. SESSION 4: PANEL: SECURITY OF THE INTERNET INFRASTRUCTURE Chair: Russ Mundy (Trusted Information Systems, USA) 7:00 P.M. DINNER BANQUET - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TUESDAY, FEBRUARY 11 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. SESSION 5: ROUTING SECURITY Chair: Hilarie Orman (DARPA, USA) Securing the Nimrod Routing Architecture, Karen E. Sirois and Stephen T. Kent (BBN Corporation, USA) Securing Distance-Vector Routing Protocols, Bradley R. Smith, Shree Murthy and J.J. Garcia-Luna-Aceves (University of California Santa Cruz, USA) Reducing the Cost of Security in Link-State Routing, R. Hauser, A. Przygienda and G. Tsudik (IBM and USC/ISI, USA) 10:00 A.M. BREAK 10:30 A.M. SESSION 6: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) Securing Web Access with DCE, Brian C. Schimpf (Gradient Technologies, USA) PANEL: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) 12:00 A.M. LUNCH 1:30 P.M. SESSION 7: PUBLIC KEY MANAGEMENT Chair: Jonathan Trostle (CyberSafe, USA) Hierarchical Organization of Certification Authorities for Secure Environments, Lourdes Lopez (Universidad Politecnica de Madrid, SPAIN) Trust Models in ICE-TEL, Andrew Young and Nada Kapidzic Cicovic (Univeristy of Salford, UNITED KINGDOM) Distributed Authentication in Kerberos Using Public Key Cryptography, Marvin Sirbu and John Chung-I Chuang (Carnegie Mellon University, USA) 3:00 P.M. BREAK 3:30 P.M. SESSION 8: PANEL: WEB PRIVACY AND ANONYMITY Chair: (To Be Determined) --------------------------------------------------------------------------- O R G A N I Z I N G C O M M I T T E E GENERAL CHAIR David Balenson, Trusted Information Systems PROGRAM CHAIRS Clifford Neuman, USC Information Sciences Institute Matt Bishop, University of California at Davis PROGRAM COMMITTEE Steve Bellovin, AT&T Research Tom Berson, Anagram Laboratories Doug Engert, Argonne National Laboratory Warwick Ford, Verisign Richard Graveman, Bellcore Li Gong, JavaSoft Burt Kaliski, RSA Laboratories Steve Kent, BBN Corporation Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Hilarie Orman, DARPA/ITO Michael Roe, University of Cambridge Christoph Schuba, Purdue University Jonathan Trostle, CyberSafe Theodore Ts'o, Massachusetts Institute of Technology Doug Tygar, Carnegie Mellon University Vijay Varadharajan, University of W. Sydney Roberto Zamparo, Telia Research PUBLICATIONS CHAIR Steve Welke, Institute for Defense Analyses LOCAL ARRANGEMENTS CHAIR Thomas Hutton, San Diego Supercomputer Center REGISTRATIONS CHAIR Torryn Brazell, Internet Society STEERING GROUP Internet Research Task Force, Privacy and Security Research Group SPONSORED BY THE INTERNET SOCIETY Donald M. Heath, President & CEO Martin Burack, Executive Director --------------------------------------------------------------------------- S A N D I E G O P R I N C E S S R E S O R T LOCATION The Symposium venue is the San Diego Princess Resort, a tropical paradise on a forty-four acre island in Mission Bay, ten minutes from the international airport. Lush gardens landscaped with hundreds of species of tropical and subtropical plants are always ablaze with color and perfect for themed group events. Charming pathways wander among sparkling waterfalls, across quaint footbridges and sleepy lagoons filled with water lilies and waterfowl. A white sand beach curves around the island for over a mile, and the award-winning grounds encompass five swimming pools and six lighted tennis courts. Spouses and family members can catch a convenient Harbor Hopper for a quick trip to Sea World. Plan to visit La Jolla, the world famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley. HOUSING INFORMATION We have reserved a special block of sleeping rooms at the San Diego Princess Resort at the following rates: Lanai Patio Rooms $ 81* Lanai Garden Rooms $114 * This represents the Government Rate for San Diego. A limited number of rooms are available at this rate. Reservations must be made no later than January 13, 1997. You must present a valid government id upon check-in. Based on room type and space availability, the special group rates are applicable two days prior to and two days after the symposium. Current Room Tax is 10.5%. Check-in availability cannot be committed prior to 4:00 p.m. Check-out time is 12:00 noon. The San Diego Princess Resort will make every effort to accommodate any early arrivals, so make sure you give them your arrival time when you make your reservation. TO MAKE A RESERVATION Contact the San Diego Princess Resort at +1-800-344-2626 (+1-619-274-4630 if outside the United States). To receive the special group rates, reservations must be made no later than January 20, 1997. To receive the special goverment rate, you must make your reservation by January 13, 1997. CLIMATE February weather in San Diego is normally very pleasant. Early morning temperatures average 55 degrees while afternoon temperatures average 67 degrees. Generally, a light jacket or sweater is adequate, although, occasionally it rains. --------------------------------------------------------------------------- R E G I S T R A T I O N I N F O R M A T I O N FEES ISOC Non- Members Member* Early registration (postmarked on/before Jan. 22) $305 $345 Late registration $375 $415 REGISTRATION INCLUDES - Attendance - Symposium Proceedings - Two luncheons - Reception - Banquet - Coffee Breaks * Non-Member fee includes one year Internet Society membership. FOR MORE INFORMATION Contact Carol Gray at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. WEB PAGE Additional information about the symposium and San Diego, plus on-line registration, are available via the Web at: http://www.isoc.org/conferences/ndss97 SPONSORSHIP OPPORTUNITIES AVAILABLE! Contact Torryn Brazell at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. --------------------------------------------------------------------------- R E G I S T R A T I O N F O R M INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY 10-11 FEBRUARY, 1997 SAN DIEGO, CALIFORNIA, USA Fill out this form and FAX it to NDSS'97 Registration at +1-703-648-9887, send it via E-mail to Ndss97reg@isoc.org, or mail it to NDSS97, 12020 Sunrise Valley Drive, Suite 210, Reston, VA, 20191, USA PERSONAL INFORMATION __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle First Name: ________________________________ MI: ____________________ Family Name: ___________________________________ __Sr __Jr __II __III Badge Name: __________________________________________________________ Please enter your name as you would like it to appear on your name tag. CONTACT INFORMATION Title: _______________________________________________________________ Organization: ________________________________________________________ Street address: ______________________________________________________ ______________________________________________________________________ City: ________________________________________________________________ State/Province: ___________________________ Postal Code: ____________ Country: _____________________________________________________________ Telephone Number (work): _____________________________________________ Telephone Number (home): _____________________________________________ Fax Number: __________________________________________________________ E-mail address: ______________________________________________________ SPECIAL NEEDS? (Vegetarian meals, wheelchair access, etc?) ______________________________________________________________________ ______________________________________________________________________ APPEAR ON REGISTRANTS LIST? ___ Please check here if you would NOT like your name included in the list of registrants. PAYMENT INFORMATION All Payments must be in United States Dollars. Conference Fee -------------- If you are an Internet Society member, you are eligible for a reduced conference registration fee. Non-member symposium attendees will receive a one year Internet Society membership as part of the non-member registration fees. Check one: On/Before After January 22 January 22 ---------- ---------- ___ Internet Society Member Fee US$ 305.00 US$ 375.00 ___ Non-Member Fee US$ 345.00 US$ 415.00 Method of Payment ----------------- Payment must be received on/before February 7, 1997 or we will be unable to pre-register you. 1. ___ Check. Make payable to the Internet Society. 2. ___ Credit Card. ___ American Express ___ Visa ___ Mastercard Name on Credit Card: ____________________________________ Credit Card Number: _____________________________________ Expiration Date: ________________________________________ 3. ___ CyberCash. Account Number: _____________________________ 4. ___ First Virtual. Account Number: _________________________ 5. ___ Wire Transfer* Bank ABA Number: 054000030 Account Number: Internet Society 148 387 10 Riggs National Bank of Virginia 950 Herndon Parkway Herndon, VA 20171 USA Wire Transfer Confirmation Number: ______________________ * Please process wire transfer before sending registration form. 6. ___ U.S. Government Purchase Order* P.O. Number: ____________________________________________ * Please fax or mail a copy of your purchase order along with your registration form. Cancellation Policy ------------------- Refunds (less a $25 processing fee) will be issued for cancellations received on/before February 7, 1997. No refunds will be issued after February 7, 1997. ------------------------------------------------------------------------   Received: from ietf.org by ietf.org id aa25651; 27 Nov 96 10:29 EST Received: from ietf.org by ietf.org id aa24587; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-aboba-radius-tunnel-imp-01.txt Date: Wed, 27 Nov 1996 10:18:35 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24587@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Implementation of Mandatory Tunneling via RADIUS Author(s) : B. Aboba, G. Zorn Filename : draft-aboba-radius-tunnel-imp-01.txt Pages : 16 Date : 11/26/1996 This document discusses implementation issues arising in the provisioning of mandatory tunneling in dial-up networks using the PPTP and L2TP protocols. This provisioning may be accomplished via the integration of RADIUS and tunneling protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aboba-radius-tunnel-imp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-aboba-radius-tunnel-imp-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-aboba-radius-tunnel-imp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126135128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aboba-radius-tunnel-imp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-aboba-radius-tunnel-imp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126135128.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ab25651; 27 Nov 96 10:29 EST Received: from ietf.org by ietf.org id aa24829; 27 Nov 96 10:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bormann-mtp-so-00.txt Date: Wed, 27 Nov 1996 10:19:18 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271019.aa24829@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MTP/SO: Self-Organizing Multicast Author(s) : C. Bormann, J. Ott, N. Seifert Filename : draft-bormann-mtp-so-00.txt Pages : 21 Date : 11/26/1996 Multiparty cooperative applications have recently received much attention, as has the multicasting of datagrams in the internet. The internet datagram multicasting mechanism is not reliable, often requiring a higher level protocol to achieve the level of reliability required for an application. Much of the extensive work on reliable multicast protocols has assumed relatively stable groups that need to ensure that all messages are received by all members of this well-defined group. Recently, work on loosely coupled teleconferencing has directed attention to a class of multicast applications that scale up to an extent where this assumption is no longer practical. An interesting multicast transport protocol is defined in RFC 1301. MTP provides globally ordered, receiver reliable, rate controlled and atomic transfer of messages to multiple recipients. A revised, more practical version of MTP, the Multicast Transport Protocol MTP-2 has been in use for some time. Self-Organizing Multicast, MTP/SO, uses MTP-2 as a basis and adds spontaneous self-organization of the members of the group into local regions. Scalability is increased by providing passive group joining and local retransmission of lost packets. This version of the document is not yet complete but contains most of the vital parts. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bormann-mtp-so-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bormann-mtp-so-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bormann-mtp-so-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126151104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bormann-mtp-so-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bormann-mtp-so-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126151104.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ac25651; 27 Nov 96 10:29 EST Received: from ietf.org by ietf.org id aa25156; 27 Nov 96 10:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mutz-http-attributes-02.txt Date: Wed, 27 Nov 1996 10:19:45 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271019.aa25156@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : User-Agent Display Attributes Author(s) : A. Mutz, L. Montulli, L. Masinter, K. Holtman Filename : draft-mutz-http-attributes-02.txt Pages : 5 Date : 11/26/1996 User-Agent Display Attributes Headers provide a means for an HTTP client [3] and server to negotiate for content dependent on the client display capabilities. This memo describes feature tags for introducing this information into an HTTP transmission. The intent is to present resource variants when available [5] such that a capable server may present documents in a preferred form to a client. If such a preferred form is not available, the server should still provide the requested documents. This specification is intended as an extension to HTTP/1.1 [4], to be implemented using the negotiation mechanism, transparent content negotiation [5]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mutz-http-attributes-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mutz-http-attributes-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mutz-http-attributes-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126161550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mutz-http-attributes-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-mutz-http-attributes-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126161550.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ad25651; 27 Nov 96 10:30 EST Received: from ietf.org by ietf.org id aa25234; 27 Nov 96 10:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kemp-auth-pklogin-02.txt, .ps Date: Wed, 27 Nov 1996 10:20:02 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271020.aa25234@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Public Key Login Protocol Author(s) : D. Kemp Filename : draft-kemp-auth-pklogin-02.txt, .ps Pages : 18 Date : 11/26/1996 This document defines the Public Key Login (PKL) protocol, a strong authentication mechanism for interactive sessions. PKL employs the digital signature challenge-response exchange specified by ISO 9798-3 and NIST FIPS Pub 196. It is suitable for use with unmodified session protocols such as Telnet and FTP, firewall proxies, dial-up Network Access Servers, remote mail servers, and similar applications. It provides functionality similar to One Time Passwords or handheld authentication tokens, and it supports both one-way and mutual authentication. The PKL protocol provides strong authentication at the beginning of a session and perhaps periodically thereafter, but does not by itself provide communication channel integrity or confidentiality. Channel integrity is required in order to fully realize the benefits of strong authentication; session keys for a cryptographically-protected channel can be established securely within the PKL exchange. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kemp-auth-pklogin-02.txt". Or "get draft-kemp-auth-pklogin-02.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-kemp-auth-pklogin-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kemp-auth-pklogin-02.txt". Or "FILE /internet-drafts/draft-kemp-auth-pklogin-02.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126162556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kemp-auth-pklogin-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kemp-auth-pklogin-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126162556.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ae25651; 27 Nov 96 10:30 EST Received: from ietf.org by ietf.org id aa25255; 27 Nov 96 10:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: confctrl@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mmusic-stream-00.txt, .ps Date: Wed, 27 Nov 1996 10:20:06 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271020.aa25255@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A real-time stream control protocol (RTSP') Author(s) : H. Schulzrinne Filename : draft-ietf-mmusic-stream-00.txt, .ps Pages : 25 Date : 11/26/1996 This strawman proposal presents a revised version of the RTSP proposal put forward to the MMUSIC group, borrowing liberally from the original. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real- time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and delivery mechanisms based upon RTP (RFC 1889). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-stream-00.txt". Or "get draft-ietf-mmusic-stream-00.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-stream-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-stream-00.txt". Or "FILE /internet-drafts/draft-ietf-mmusic-stream-00.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126163430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-stream-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-stream-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126163430.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id af25651; 27 Nov 96 10:30 EST Received: from ietf.org by ietf.org id aa25266; 27 Nov 96 10:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ohta-simple-dns-02.txt Date: Wed, 27 Nov 1996 10:20:10 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271020.aa25266@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Secure DNS Author(s) : M. Ohta Filename : draft-ohta-simple-dns-02.txt Pages : 19 Date : 11/26/1996 An extension to DNS is proposed to make answers from it authenticated. The extension is designed to be minimal, which will be useful as a framework to make applications provide required level of authentication and/or confidentiality. The changes to the existing architecture of DNS is also minimized. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ohta-simple-dns-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ohta-simple-dns-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ohta-simple-dns-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126163723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ohta-simple-dns-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ohta-simple-dns-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126163723.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00409; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24375; 27 Nov 96 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-inetorgperson-00.txt Date: Wed, 27 Nov 1996 10:17:53 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271017.aa24375@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : Definition of the inetOrgPerson Object Class Author(s) : M. Smith Filename : draft-ietf-asid-inetorgperson-00.txt Pages : 5 Date : 11/26/1996 While the X.500 standards define many useful attribute types [1] and object classes [2], they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson that extends the X.521 standard organizationalPerson class to meet these needs. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-asid-inetorgperson-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-inetorgperson-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-inetorgperson-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126123314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-inetorgperson-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-inetorgperson-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126123314.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00472; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24780; 27 Nov 96 10:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: cat-ietf@mit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-sesamemech-02.txt Date: Wed, 27 Nov 1996 10:19:11 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271019.aa24780@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : The SESAME V5 GSS-API Mechanism Author(s) : E. Baize, S. Farrell, T. Parker Filename : draft-ietf-cat-sesamemech-02.txt Pages : 60 Date : 11/26/1996 This specification defines protocols, data elements, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the SESAME Version 5 Mechanism. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-sesamemech-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-sesamemech-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-sesamemech-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126143555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-sesamemech-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-sesamemech-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126143555.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00488; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24609; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: roamops@nsmx.rutgers.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-roamops-imprev-00.txt Date: Wed, 27 Nov 1996 10:18:39 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24609@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Roaming Operations Working Group of the IETF. Title : Review of Roaming Implementations Author(s) : B. Aboba, L. Liu, J. Alsop, J. Ding Filename : draft-ietf-roamops-imprev-00.txt Pages : 25 Date : 11/26/1996 This document reviews the design and functionality of existing roaming implementations. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-roamops-imprev-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-imprev-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-roamops-imprev-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126135652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-roamops-imprev-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-roamops-imprev-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126135652.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00449; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24166; 27 Nov 96 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-holstege-bulletintext-00.txt Date: Wed, 27 Nov 1996 10:17:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271017.aa24166@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Bulletins as an Extension to HTML Author(s) : J. Gardner, M. Holstege Filename : draft-holstege-bulletintext-00.txt Pages : 5 Date : 11/26/1996 This draft defines a bulletin mechanism that conveys time-varying information about a linked resource. It is in a form suitable for use by autonomous user agents monitoring documents for changes in content or for new or changed links. HTML authors can use bulletins to push information back to an interested audience. Bulletins can be text messages of up to 1024 characters. A bulletin has a posting date associated with it and may also have an expiration date, an image, and a link to another resource. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-holstege-bulletintext-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-holstege-bulletintext-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-holstege-bulletintext-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126112040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-holstege-bulletintext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-holstege-bulletintext-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126112040.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00463; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24757; 27 Nov 96 10:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: drums@cs.utk.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-drums-msg-fmt-00.txt Date: Wed, 27 Nov 1996 10:19:08 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271019.aa24757@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detailed Revision/Update of Message Standards Working Group of the IETF. Title : Message Format Standard Author(s) : P. Resnick Filename : draft-ietf-drums-msg-fmt-00.txt Pages : 18 Date : 11/26/1996 This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request For Comments 822, "Standard for the Format of ARPA Internet Text Messages". Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-drums-msg-fmt-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-drums-msg-fmt-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-drums-msg-fmt-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126143206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-drums-msg-fmt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-drums-msg-fmt-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126143206.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00397; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24537; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-morgan-ident-ext-02.txt Date: Wed, 27 Nov 1996 10:18:28 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24537@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : S/Ident: Security Extensions for the Ident Protocol Author(s) : B. Morgan Filename : draft-morgan-ident-ext-02.txt Pages : 11 Date : 11/26/1996 The Ident protocol [RFC-1413], specifies a method for a host to request from a remote host an assertion of an identifier associated with a TCP connection between the two hosts. This memo specifies extensions to Ident to support strong (i.e., cryptographic) authentication methods. The extensions are based on the Simple Authentication and Security Layer [SASL]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-morgan-ident-ext-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-morgan-ident-ext-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-morgan-ident-ext-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126134337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-morgan-ident-ext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-morgan-ident-ext-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126134337.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00419; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa25519; 27 Nov 96 10:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: issll@mercury.lcs.mit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-issll-framing-ext-00.txt Date: Wed, 27 Nov 1996 10:20:32 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271020.aa25519@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Services over Specific Link Layers Working Group of the IETF. Title : QOSPPP Framing Extensions to PPP Author(s) : R. Andrades, F. Burg Filename : draft-ietf-issll-framing-ext-00.txt Pages : 21 Date : 11/26/1996 The Point-to-Point Protocol (PPP) [2] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP datagrams are often encapsulated in HDLC frames [1] when used over standard analog modems. This document describes the extensions to PPP encapsulation and HDLC framing to support Quality of Service (QoS) over low bandwidth links. This document is a submission to the IETF ISSLL working group. Comments are solicited and should be addressed to the working group's mailing list at issll@mercury.lcs.mit.edu and/or the author. This document is an update of the previous version which was named "draft-andrades-framing-ext-00.txt" and was revised as a result of discussions with Carsten Bormann, as well as the discussions at the September 30th meeting of the ISSLL working group. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-issll-framing-ext-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-issll-framing-ext-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-issll-framing-ext-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126164401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-issll-framing-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-issll-framing-ext-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126164401.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00444; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa23950; 27 Nov 96 10:16 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rtfm@auckland.ac.nz Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rtfm-new-traffic-flow-00.txt Date: Wed, 27 Nov 1996 10:16:34 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271016.aa23950@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Realtime Traffic Flow Measurement Working Group of the IETF. Title : Real Time Flow Measurement Working Group - New Attributes for Traffic Flow Measurement Author(s) : S. Handelman, N. Brownlee, G. Ruth Filename : draft-ietf-rtfm-new-traffic-flow-00.txt Pages : 9 Date : 11/26/1996 The Real-time Traffic Flow Measurement (RTFM) working group has developed a rudimentary system for measuring and reporting information about traffic flows in the Internet. This document explores the definition of extensions to the concepts of flow measurements as currently defined in RFC 1272 and [1]. The RTFM Working Group has defined the concept of a standardized meter which records flows from a traffic stream according to a Rule Set that is active in the meter[1]. Implementations of this meter have been done by Nevil Brownlee in the University of Auckland, NZ, and Stephen Stibler and Sig Handelman at IBM in Hawthorne, NY, USA. The meter implementations measure flows by marking them with time stamps, recording total traffic in bytes and packets. In general one may say that the meter finds the existence of flows, and records the traffic in each flow. The RTFM WG has also discussed the Collector Program whose job is to fetch the completed group of flows active in the Meter. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rtfm-new-traffic-flow-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rtfm-new-traffic-flow-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rtfm-new-traffic-flow-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126095058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rtfm-new-traffic-flow-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rtfm-new-traffic-flow-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126095058.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00415; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24680; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-atmacct-01.txt Date: Wed, 27 Nov 1996 10:18:54 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24680@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Accounting Information for ATM Networks Author(s) : K. McCloghrie, J. Heinanen, W. Greene, A. Prasad Filename : draft-ietf-atommib-atmacct-01.txt Pages : 17 Date : 11/26/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. A separate memo [8] defines managed objects, in a manner independent of the type of network, for controlling the selection, collection and storage of accounting information into files for later retrieval via a file transfer protocol. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atommib-atmacct-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atmacct-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-atmacct-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126141628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-atmacct-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-atmacct-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126141628.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00469; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24039; 27 Nov 96 10:16 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: bmwg@harvard.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-lanswitch-01.txt Date: Wed, 27 Nov 1996 10:16:54 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271016.aa24039@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Benchmarking Terminology for LAN Switching Devices Author(s) : B. Mandeville Filename : draft-ietf-bmwg-lanswitch-01.txt Pages : 8 Date : 11/26/1996 The purpose of this draft is to define and discuss benchmarking terminology for local area switching devices. It is meant to extend the terminology already defined for network interconnect devices in RFCs 1242 and 1944 by the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). LAN switches are one of the principal sources of new bandwidth in the local area and are handling a significantly increasing proportion of network traffic. The multiplicity of products brought to market makes it desirable to define a set of terms to be used when evaluating the performance characteristics of local area switching devices. Well-defined terminology will help in providing the user community with complete, reliable and comparable data on LAN switches. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-lanswitch-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-lanswitch-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-lanswitch-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126104057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-lanswitch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-lanswitch-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126104057.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00442; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24302; 27 Nov 96 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-atmhist-00.txt Date: Wed, 27 Nov 1996 10:17:35 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271017.aa24302@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Managed Objects for Recording ATM Performance History Data Based on 15 Minute Intervals Author(s) : G. Mouradian Filename : draft-ietf-atommib-atmhist-00.txt Pages : 21 Date : 11/26/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to record and retrieve ATM performance history data recorded in 15 minute interval. The functionality defined in this document is intended to satisfy the requirements defined by the ATM Forum in [9]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atommib-atmhist-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atmhist-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-atmhist-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126120951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-atmhist-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-atmhist-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126120951.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00500; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24505; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-sabin-lzs-payload-00.txt Date: Wed, 27 Nov 1996 10:18:23 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24505@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LZS Payload Compression Transform for ESP Author(s) : M. Sabin, R. Monsour Filename : draft-sabin-lzs-payload-00.txt Pages : 7 Date : 11/26/1996 This memo proposes a "payload compression transform" based on the LZS compression algorithm. The transform can be used to compress the payload field of an IP datagram that uses the Encapsulating Security Payload (ESP) format. The compression transform proposed here is stateless, meaning that a datagram can be decompressed independently of any other datagram. Compression is performed prior to the encryption operation of ESP, which has the side benefit of reducing the amount of data that must be encrypted. This memo anticipates a forthcoming draft of ESP that will supercede [Atkins96]. The forthcoming draft will allow for ESP payloads to be compressed via transforms such as the one described in this memo. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sabin-lzs-payload-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-sabin-lzs-payload-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-sabin-lzs-payload-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126133813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sabin-lzs-payload-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sabin-lzs-payload-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126133813.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00210; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa25546; 27 Nov 96 10:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ohta-sun-00.txt Date: Wed, 27 Nov 1996 10:20:41 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271020.aa25546@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Unified Networking Author(s) : M. Ohta Filename : draft-ohta-sun-00.txt Pages : 6 Date : 11/26/1996 The concept of LIS for IP over ATM causes a topology mismatch between the link and the internetworking layer. While it introduces some inefficiency with CATENET based operation, it is not so much a problem unless we try to solve this minor problem. Short-cutting attempts such as NHRP can't solve the inefficiency issue at all even though, or, just because, it utterly destroys the CATENET model, which resulted in inelegant modifications of existing protocols, which, in turn, causes scalability problems. Moreover, the creation of short-cut VCs itself suffers a scalability issue. But, CSRs (Cell Switching Routers), or RSVP-signaled ATM switches, make it possible to have end-to-end cell-by-cell relaying over IP routers. That is, there is no reason to have LISes and there is no inefficiency The way to go for the Internet is Simple Unified Networking with the CATENET model. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ohta-sun-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ohta-sun-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ohta-sun-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126165157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ohta-sun-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ohta-sun-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126165157.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00217; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24561; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: if-mib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ifmib-mib-05.txt Date: Wed, 27 Nov 1996 10:18:32 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24561@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interfaces MIB Working Group of the IETF. Title : The Interfaces Group MIB Author(s) : K. McCloghrie, F. Kastenholz Filename : draft-ietf-ifmib-mib-05.txt Pages : 77 Date : 11/26/1996 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ifmib-mib-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ifmib-mib-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ifmib-mib-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126134639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ifmib-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ifmib-mib-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126134639.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00511; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24488; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: receipt@cs.utk.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-receipt-mdn-02.txt Date: Wed, 27 Nov 1996 10:18:19 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24488@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Receipt Notifications for Internet Mail Working Group of the IETF. Title : An Extensible Message Format for Message Disposition Notifications Author(s) : R. Fajman Filename : draft-ietf-receipt-mdn-02.txt Pages : 26 Date : 11/26/1996 This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-receipt-mdn-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-receipt-mdn-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-receipt-mdn-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126133226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-receipt-mdn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-receipt-mdn-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126133226.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00435; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24278; 27 Nov 96 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: applmib@emi-summit.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-applmib-mib-00.txt Date: Wed, 27 Nov 1996 10:17:28 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271017.aa24278@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application MIB Working Group of the IETF. Title : Application Management MIB Author(s) : C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia Filename : draft-ietf-applmib-mib-00.txt Pages : 11 Date : 11/26/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. This MIB complements the System Application MIB, providing for the management of applications' common aspects which could not typically be observed without the cooperation of the software being managed. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-applmib-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-applmib-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-applmib-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126115900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-applmib-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-applmib-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126115900.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00396; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24657; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-acct-04.txt Date: Wed, 27 Nov 1996 10:18:48 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24657@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks Author(s) : K. McCloghrie, J. Heinanen, W. Greene, A. Prasad Filename : draft-ietf-atommib-acct-04.txt Pages : 33 Date : 11/26/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. The accounting data is collected into files for later retrieval via a file transfer protocol. For information on data which can be collected for ATM networks, see [9]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atommib-acct-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-acct-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-acct-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126141329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-acct-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-acct-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126141329.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00423; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24098; 27 Nov 96 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-isaacson-ipp-info-00.txt Date: Wed, 27 Nov 1996 10:17:02 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271017.aa24098@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Printing Protocol - IPP/1.0 Author(s) : R. de Bry, T. Hastings, R. Herriot, S. Isaacson Filename : draft-isaacson-ipp-info-00.txt Pages : 81 Date : 11/26/1996 This Internet-Draft specifies an Internet Printing Protocol (IPP) that is intended to be version 1.0. This protocol is heavily influence by the semantic operations and attributes defined in ISO/IEC 10175 Document Printing Application (DPA) parts 1 and 3. It also incorporates some of the implementation and interoperability lessons learned from other printing related standards such as POSIX System Administration - Part 4 (POSIX 1378.4) and X/Open A Printing System Interoperability Specification (PSIS). IPP is defined as a set of abstract data types and operations. The operations are implemented using a simple request and response mechanism built on top of HTTP. The abstract data types are encoded as simple ASCII text strings. The IPP protocol covers only end user operations on basic print service objects. Authentication is realized by mechanisms outside the scope of the protocol, but the protocol does introduce some access control functionality so that only authorized end users are allowed to submit print jobs to printers whose implementation and site policy support access control. Also, the Cancel Job operation requires some authentication so that jobs can only be canceled by the end user who submitted the job. Extended monitoring and management is possible through other protocols such as the SNMP Printer MIB. In the areas where there are no existing standards, some proposed and emerging standards are being worked (management, security, etc.). As these services become more stable, this document (and hence the protocol) can be updated to reflect the integration and relationships with these other standards. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-isaacson-ipp-info-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-isaacson-ipp-info-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-isaacson-ipp-info-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126105233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-isaacson-ipp-info-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-isaacson-ipp-info-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126105233.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00456; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa25574; 27 Nov 96 10:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-v6exts-04.txt Date: Wed, 27 Nov 1996 10:20:45 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271020.aa25574@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Extensions for DHCPv6 Author(s) : C. Perkins Filename : draft-ietf-dhc-v6exts-04.txt Pages : 18 Date : 11/26/1996 The Dynamic Host Configuration Protocol for IPv6 [3] (DHCPv6) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in typed data items that are stored in the "extensions" field of the DHCPv6 message. The data items themselves are also called "extensions." This document specifies the current set of DHCPv6 extensions. This document will be periodically updated as new extensions are defined. Each superseding document will include the entire current list of valid extensions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-v6exts-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-v6exts-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-v6exts-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126170610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-v6exts-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-v6exts-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126170610.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00478; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24632; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: roamops@nsmx.rutgers.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-roamops-roamreq-00.txt Date: Wed, 27 Nov 1996 10:18:42 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24632@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Roaming Operations Working Group of the IETF. Title : Dialup Roaming Requirements Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-roamops-roamreq-00.txt Pages : 14 Date : 11/26/1996 This document describes the features required for the provision of "roaming capability" for dialup Internet users, as well as offering some suggestions for future protocol standardization work. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-roamops-roamreq-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-roamreq-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-roamops-roamreq-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126140134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-roamops-roamreq-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-roamops-roamreq-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126140134.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00496; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa25097; 27 Nov 96 10:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-armitage-ion-mars-nbma-01.txt Date: Wed, 27 Nov 1996 10:19:33 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271019.aa25097@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using the MARS model in non-ATM NBMA networks. Author(s) : G. Armitage Filename : draft-armitage-ion-mars-nbma-01.txt Pages : 6 Date : 11/26/1996 The MARS model developed by the IP over ATM working group is also applicable to other NBMA networks that provide the equivalent of switched, point to multipoint connections. This short document is intended to state the obvious equivalences, and explain the less obvious implications. No changes to the MARS model per se are suggested or required. The MARS model is not required for NBMA networks that offer a link level group addressing service that maps directly onto the IP multicast model. This document is informational, and may influence the development of MARSv2/NHRPv2 in line with the new ION charter and 'goals and milestones' timeline. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-armitage-ion-mars-nbma-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-armitage-ion-mars-nbma-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-armitage-ion-mars-nbma-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126161153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-armitage-ion-mars-nbma-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-armitage-ion-mars-nbma-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126161153.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00408; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa24349; 27 Nov 96 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rps@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rps-rpsl-00.txt Date: Wed, 27 Nov 1996 10:17:38 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271017.aa24349@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Policy System Working Group of the IETF. Title : Routing Policy Specification Language (RPSL) Author(s) : C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, M. Terpstra, C. Villamizar Filename : draft-ietf-rps-rpsl-00.txt Pages : 36 Date : 11/26/1996 This Internet Draft is the reference document for Routing Policy Specification Language (RPSL). RPSL allows the specification of routing policies at high level; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rps-rpsl-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rps-rpsl-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rps-rpsl-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126122224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rps-rpsl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rps-rpsl-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126122224.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00400; 27 Nov 96 10:33 EST Received: from ietf.org by ietf.org id aa25179; 27 Nov 96 10:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-crowcroft-rmfp-00.txt Date: Wed, 27 Nov 1996 10:19:53 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271019.aa25179@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RMFP: A Reliable Multicast Framing Protocol Author(s) : J. Crowcroft, Z. Wang, A. Ghosh, C. Diot Filename : draft-crowcroft-rmfp-00.txt Pages : 4 Date : 11/26/1996 There has been considerable interest in reliable multicast, and a number of reliable multicast transport systems have been proposed in the past years. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crowcroft-rmfp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-crowcroft-rmfp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-crowcroft-rmfp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126161952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crowcroft-rmfp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-crowcroft-rmfp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126161952.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa02224; 27 Nov 96 10:40 EST Received: from ietf.org by ietf.org id aa24007; 27 Nov 96 10:16 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-whois-schema-00.txt Date: Wed, 27 Nov 1996 10:16:47 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271016.aa24007@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : WHOIS++ templates Author(s) : P. Faltstrom, M. Hamilton, L. Daigle, J. Knight Filename : draft-ietf-asid-whois-schema-00.txt Pages : 22 Date : 11/26/1996 WHOIS++ is a simple Internet search and retrieval protocol, specified in RFC 1835, which allows clients and servers to exchange structured data objects known as templates. In the interests of interoperability it is desirable to have a common base schema for these templates. This document suggests a schema drawn from implementation and deployment experience to date with WHOIS++. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-asid-whois-schema-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-whois-schema-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-whois-schema-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126102105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-whois-schema-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-whois-schema-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126102105.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ab02224; 27 Nov 96 10:40 EST Received: from ietf.org by ietf.org id aa24311; 27 Nov 96 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-classic2-01.txt Date: Wed, 27 Nov 1996 10:17:31 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271017.aa24311@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : Classical IP and ARP over ATM Author(s) : M. Laubach, J. Halpern Filename : draft-ietf-ion-classic2-01.txt Pages : 26 Date : 11/26/1996 This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 5. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many Ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations ("members") and routers operating in the "classical" LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. This memo introduces general ATM technology and nomenclature. Readers are encouraged to review the ATM Forum and ITU-TS (formerly CCITT) references for more detailed information about ATM implementation agreements and standards. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-classic2-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-classic2-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-classic2-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126120417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-classic2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-classic2-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126120417.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ac02224; 27 Nov 96 10:40 EST Received: from ietf.org by ietf.org id aa24425; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: dhcp-v4@bucknell.edu, dhcp-v6@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-08.txt Date: Wed, 27 Nov 1996 10:18:06 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24425@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, C. Perkins Filename : draft-ietf-dhc-dhcpv6-08.txt Pages : 37 Date : 11/26/1996 The Dynamic Host Configuration Protocol (DHCPv6) provides a framework for passing configuration information, via extensions, to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol should be considered a stateful counterpart to the IPv6 Stateless Address Autoconfiguration protocol specification. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcpv6-08.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-08.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126124212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126124212.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ad02224; 27 Nov 96 10:40 EST Received: from ietf.org by ietf.org id aa24449; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-radius@livingston.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radius-tunnel-auth-00.txt Date: Wed, 27 Nov 1996 10:18:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24449@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Attributes for Tunnel Protocol Support Author(s) : G. Zorn Filename : draft-ietf-radius-tunnel-auth-00.txt Pages : 5 Date : 11/26/1996 This document specifies a set of RADIUS attributes designed to support the provision of mandatory tunneling in dial-up networks. RADIUS attributes for both authorization and accounting are specified. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-tunnel-auth-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-radius-tunnel-auth-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-radius-tunnel-auth-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126125249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-tunnel-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-tunnel-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126125249.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa02582; 27 Nov 96 10:45 EST Received: from ietf.org by ietf.org id aa24468; 27 Nov 96 10:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hoffman-issll-l2tcreq-00.txt Date: Wed, 27 Nov 1996 10:18:16 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271018.aa24468@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Integrated-Services/RSVP Requirements for Layer 2 Traffic Control Author(s) : D. Hoffman, R. Yavatkar Filename : draft-hoffman-issll-l2tcreq-00.txt Pages : 9 Date : 11/26/1996 This documents discusses some of the requirements placed on L2 traffic control in IEEE 802-style networks by IP Integrated Services (IntServ) and RSVP signaling. It outlines some of the features of IntServ/RSVP which are of particular relevance to this style of network, and defines the of the requirements that a L2 network must meet to fully support these features. Finally, it discusses certain L2 mechanism which may aid in meeting these requirements. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hoffman-issll-l2tcreq-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-hoffman-issll-l2tcreq-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-hoffman-issll-l2tcreq-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126125904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hoffman-issll-l2tcreq-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hoffman-issll-l2tcreq-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126125904.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa09235; 27 Nov 96 11:09 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13041; 27 Nov 96 11:09 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 27 Nov 1996 15:06:12 GMT Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP id AA17577; Wed, 27 Nov 96 10:04:28 EST Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id QAA28935 for ; Wed, 27 Nov 1996 16:02:36 +0100 Received: from p18509.wdf.sap-ag.de by sap-ag.de with SMTP id AA00993 (5.67b8/IDA-1.5 for ); Wed, 27 Nov 1996 16:02:34 +0100 Received: (from d019080@localhost) by p18509.wdf.sap-ag.de (8.7.1/8.7.1) id QAA04284; Wed, 27 Nov 1996 16:03:39 +0100 Date: Wed, 27 Nov 1996 16:03:39 +0100 Message-Id: <199611271503.QAA04284@p18509.wdf.sap-ag.de> From: Martin Rex To: cat-ietf@mit.edu Subject: anonymous and import_name()/display_name() oh no, naming issues again ... ;-) I'm slightly puzzled about the usage/applicability of certain kinds of internal names to certain kinds of calls. Some additional clarifying comments in the specification might be helpful (this might actually apply more to the high level spec than the c-bindings): * Anonymous name support: - which calls do accept an "anonymous" internal name for input? gss_compare_name(), gss_display_name() according to the specs, what about: gss_canonicalize_name(), gss_export_name() - which calls may return "anonymous" as an internal name? gss_accept_sec_context() according to the specs, what about: gss_import_name() or how else can an "anonymous" internal name be created by an application? gss_canonicalize_name() when anonymous is input name, gss_export_name() with implications for import_name - can the anonymous internal name be created form a printable * what about the output from gss_display_name(), does it have to be parseable by gss_import_name() when the oid from gss_display_name() is supplied? To be more precise: is the return parameter name_type optional only for the application, or is it optional for the mechanism as well? Personally, I would say: - If a mechanism returns an OID with the output_name from gss_display_name(), but doesn't accept these same parameters as input to gss_import_name(), then I would say that the returned name_type OID is a lie! - If gss_import_name() would accept the name, but might map it to a different identity/principal, then I would consider the implementation highly insecure and therefore broken. The only legal way for a mechanism to refuse to reimport the output from display_name would IMO be to not return *no* OID. But for anonymous internal names, the spec says that the name_type returned from gss_display_name() will be GSS_C_NT_ANONYMOUS, and the printable can be anything. * Should gss_import_name() accept GSS_C_NT_ANONYMOUS as input, and if yes, should it ignore the printable completely? * oh, I just noticed this one: in which situations should gss_export_name() be allowed to return GSS_S_BAD_NAMETYPE? (maybe for the anonymous internal name, because it then would imply that import_name has to import the anonymous name when it's supplied as an exported binary blob, and it would be reasonable to allow the import of (any printable,GSS_C_NT_ANONYMOUS) as well). Comments/Opinion? (I don't have any requirements or personal preferences for how to use anonymous names, I'm just curious how it is ment to be). -Martin   Received: from ietf.org by ietf.org id aa13610; 27 Nov 96 11:36 EST Received: from ietf.ietf.org by ietf.org id aa12701; 27 Nov 96 11:33 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-calendar@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cip-00.txt Date: Wed, 27 Nov 1996 11:33:06 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271133.aa12701@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Calendaring Interoperability Protocol Author(s) : A. Ganguly, S. Hanna, P. O'Leary, B. Spencer Filename : draft-ietf-calsch-cip-00.txt Pages : 18 Date : 11/27/1996 The Calendaring Interoperability Protocol (CIP) provides a standard mechanism for exchanging events and other information between scheduling systems. This allows users to schedule meetings with anyone else, no matter what scheduling software they use. CIP is one of three standards under development by the Calendaring and Scheduling Working Group of the IETF. The other two are the Core Object Specification (COS), a standard data format for representing scheduled events, and the Calendaring Access Protocol (CAP), a standard mechanism that scheduling user agents may use to access user calendars (analogous to POP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-cip-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-cip-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-calsch-cip-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127111258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cip-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127111258.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa13698; 27 Nov 96 11:37 EST Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa13716; 27 Nov 96 11:37 EST Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17029 for ipsec-outgoing; Wed, 27 Nov 1996 11:23:12 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-inline-isakmp-00.txt Date: Wed, 27 Nov 1996 10:17:08 -0500 Message-ID: <9611271017.aa24153@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Inline Keying within the ISAKMP Framework. Author(s) : B. Sommerfeld Filename : draft-ietf-ipsec-inline-isakmp-00.txt Pages : 9 Date : 11/26/1996 The current proposal for IP-layer key management [ISAKMP, OAKLEY, ISAOAK] has fairly high overhead. Before a security association can be established, at least one pair of messages need to be exchanged between the communicating peers. For efficiency, this suggests that ISAKMP setup should be infrequent. However, general principles of key management suggest that individual keys should be used as little as practical and changed as frequently as possible. Steve Bellovin has suggested that, ideally, different security associations should be used for each different transport-level connection[BADESP]. This document discusses different ways of structuring a protocol to permit this to happen with minimal overhead, both in round-trip delay at connection setup, and in bandwidth once the connection is established. Portions of this protocol have been inspired by SKIP, which is fundamentally built around the concept of inline keying[SKIP]. SKIP's approach is burdened by the addition of an extra intermediate header of perhaps 20 to 28 bytes to every protected packet, essentially doubling the overhead of protected traffic compared with ESP with manual keying. Ideally, an inline keying header would be used only until the desired security association is established, at which point the peers will fall back to pure ESP/AH. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-inline-isakmp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-inline-isakmp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-inline-isakmp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126110919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-inline-isakmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-inline-isakmp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126110919.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13847; 27 Nov 96 11:39 EST Received: from ietf.ietf.org by ietf.org id aa12677; 27 Nov 96 11:33 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-dawson-csp-01.txt Date: Wed, 27 Nov 1996 11:33:03 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271133.aa12677@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIME Calendaring and Scheduling Content Type Profile Author(s) : F. Dawson Filename : draft-dawson-csp-01.txt Pages : 62 Date : 11/27/1996 The use of mail enabled applications such as calendaring and scheduling has grown considerably in the last decade. Enterprise and inter-enterprise business has become dependent on rapid scheduling of events and actions using this information technology. The store-and-forward characteristic of electronic messaging technologies has been shown to be complementary to the asynchronous nature of group communications. However, the longer term growth of mail enabled applications, such as calendaring and scheduling, is currently limited by the lack of Internet standards for the message content types that these groupware applications are based on. This specification is intended to progress the level of interoperability possible between dissimilar calendaring and scheduling applications that communicate using an SMTP or MIME transport. This specification defines a usage profile for the MIME Calendaring and Scheduling Content Type [MIME-CAL]. Any MIME based calendaring and scheduling application that supports this MIME Calendaring and Scheduling Content Type profile will be able to interoperate with other MIME based calendaring and scheduling applications using a broad range of scheduling functions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dawson-csp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-dawson-csp-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-dawson-csp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127111849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dawson-csp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-dawson-csp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127111849.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13788; 27 Nov 96 11:39 EST Received: from ietf.ietf.org by ietf.org id aa12836; 27 Nov 96 11:33 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-yavatkar-sbm-ethernet-02.txt Date: Wed, 27 Nov 1996 11:33:25 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271133.aa12836@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over Ethernet Author(s) : R. Yavatkar, D. Hoffman, Y. Bernet Filename : draft-yavatkar-sbm-ethernet-02.txt Pages : 19 Date : 11/27/1996 This document outlines an architecture for RSVP-based admission control over IEEE 802-style LANs. The proposed architecture is designed to work with the current generation of IEEE 802 LANs and should be considered as a first step towards discovering solutions for implementation of IntServ capabilities over such networks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yavatkar-sbm-ethernet-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-yavatkar-sbm-ethernet-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-yavatkar-sbm-ethernet-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127110041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yavatkar-sbm-ethernet-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-yavatkar-sbm-ethernet-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127110041.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13845; 27 Nov 96 11:39 EST Received: from ietf.ietf.org by ietf.org id aa12752; 27 Nov 96 11:33 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-allman-ftp-variable-03.txt Date: Wed, 27 Nov 1996 11:33:11 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271133.aa12752@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : FTP Extensions for Variable Protocol Specification Author(s) : M. Allman, S. Ostermann Filename : draft-allman-ftp-variable-03.txt Pages : 5 Date : 11/27/1996 The specification for the File Transfer Protocol assumes that the underlying network protocols use a 32-bit network address and a 16-bit transport address (specifically IP version 4 and TCP). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over a variety of network and transport protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-allman-ftp-variable-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-allman-ftp-variable-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-allman-ftp-variable-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127110910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allman-ftp-variable-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-allman-ftp-variable-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127110910.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13822; 27 Nov 96 11:39 EST Received: from ietf.ietf.org by ietf.org id aa12916; 27 Nov 96 11:33 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-diagnostic-msgs-02.txt Date: Wed, 27 Nov 1996 11:33:37 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271133.aa12916@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : RSVP Diagnostic Messages Author(s) : Lixia Zhang Filename : draft-ietf-rsvp-diagnostic-msgs-02.txt Pages : 10 Date : 11/26/1996 This draft describes the RSVP diagnosis facility. As the deployment of RSVP is spreading out, it has become clear that a method for collecting information about the RSVP state along the path is needed. This specification describes the required functionality, packet format, and processing rules. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-diagnostic-msgs-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-diagnostic-msgs-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-diagnostic-msgs-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127105430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-diagnostic-msgs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-diagnostic-msgs-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127105430.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13841; 27 Nov 96 11:39 EST Received: from ietf.ietf.org by ietf.org id aa12973; 27 Nov 96 11:33 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pullen-ipv4-rsvp-00.txt Date: Wed, 27 Nov 1996 11:33:43 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271133.aa12973@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Simulation Model for IP Multicast with RSVP Author(s) : M. Pullen, R. Malghan, L. Lavu Filename : draft-pullen-ipv4-rsvp-00.txt Pages : 12 Date : 11/27/1996 This document describes a detailed model of IPV4 multicast with RSVP that has been developed using the OPNET simulation package but could be ported to any descrete event simulation package with procedures defined in the C language. The model was developed to allow investigation of performance constraints on routing but should have wide applicability in the Internet multicast/resource reservation community. We are making this model publicly available with the intention that it can be used to provide expanded studies of resource-reserved multicasting. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pullen-ipv4-rsvp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-pullen-ipv4-rsvp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-pullen-ipv4-rsvp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127105226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pullen-ipv4-rsvp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pullen-ipv4-rsvp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127105226.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13789; 27 Nov 96 11:39 EST Received: from ietf.ietf.org by ietf.org id aa12598; 27 Nov 96 11:32 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mankin-reliable-multicast-00.txt Date: Wed, 27 Nov 1996 11:32:43 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271132.aa12598@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IETF Criteria For Evaluating Reliable Multicast Transport Transport and Application Protocols Author(s) : A. Mankin, A. Romanow Filename : draft-mankin-reliable-multicast-00.txt Pages : 5 Date : 11/27/1996 This memo describes the procedures for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. They are temporary procedures. The Area Directors expect to be able to charter one or more WGs for standards track reliable multicast within a year or 18 months, as the procedures described herein help the transport and applications communities to identify and resolve the most serious technical problems with reliable multicast. Within today's Internet, important applications exist for a reliable multicast service. Some examples that are pulling reliable multicast technology are collaborative workspaces (such as whiteboard), data and software distribution, and (more speculatively) web caching protocols. However, the technology for accomplishing reliable multicast in the Internet is not well-understood at the current time. Due to the nature of the technical issues, a single commonly accepted technical solution that solves all the demands for reliable multicast is infeasible. A number of reliable multicast protocols have already been invented to solve a variety of problems for various types of applications (See Bibliography). How should these protocols be treated within the IETF and how should the IETF guide the development of reliable multicast in a direction beneficial for the general Internet? The TSV Area Directors and their Directorate have outlined a set of review procedures that address these questions and set criteria and processes for the publication as RFCs of internet-drafts on reliable multicast transport or reliable multicast applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mankin-reliable-multicast-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mankin-reliable-multicast-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mankin-reliable-multicast-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127112749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mankin-reliable-multicast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mankin-reliable-multicast-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127112749.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13846; 27 Nov 96 11:39 EST Received: from ietf.ietf.org by ietf.org id aa13006; 27 Nov 96 11:33 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pullen-qospf-model-00.txt Date: Wed, 27 Nov 1996 11:33:47 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611271133.aa13006@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Simulation of QOSFP Multicasting for a Large Area Author(s) : M. Pullen, L. Lavu, H. Nguyen, E. Crawley Filename : draft-pullen-qospf-model-00.txt Pages : 8 Date : 11/27/1996 This document describes a detailed simulation model of a sizable IPmc/RSVP network using the Quality of Service Extensions to OSPF and the performance predictions produced by the model. The model was developed using the OPNET simulation package with procedures defined in the C language. The model was developed to allow investigation of scaling characteristics of QoS routing by the Internet multicast/resource reservation community. We are making our model publicly available for this purpose. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pullen-qospf-model-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-pullen-qospf-model-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-pullen-qospf-model-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127104930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pullen-qospf-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pullen-qospf-model-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127104930.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa15196; 27 Nov 96 11:57 EST Received: from bubbuh.cisco.com by CNRI.Reston.VA.US id aa14350; 27 Nov 96 11:57 EST Received: (daemon@localhost) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) id IAA15559 for Rmonmib-outgoing; Wed, 27 Nov 1996 08:25:20 -0800 (PST) Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with ESMTP id IAA15554 for ; Wed, 27 Nov 1996 08:25:16 -0800 (PST) Received: from ietf.org (ietf.org [132.151.1.19]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id IAA07427 for ; Wed, 27 Nov 1996 08:25:15 -0800 (PST) Received: from ietf.org by ietf.org id aa24122; 27 Nov 96 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: rmonmib@cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmonmib-rmonprot-v2-00.txt Date: Wed, 27 Nov 1996 10:17:05 -0500 Message-ID: <9611271017.aa24122@ietf.org> Sender: owner-rmonmib@cisco.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Network Monitoring Working Group of the IETF. Title : Remote Network Monitoring MIB Protocol Identifiers Author(s) : A. Bierman, C. Bucci, R. Iddon Filename : draft-ietf-rmonmib-rmonprot-v2-00.txt Pages : 75 Date : 11/26/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. Although related to the original Remote Network Monitoring MIB [RFC1757], this document refers only to objects found in the RMON-2 MIB. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmonmib-rmonprot-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rmonmib-rmonprot-v2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rmonmib-rmonprot-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126105946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmonmib-rmonprot-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmonmib-rmonprot-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126105946.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa17204; 27 Nov 96 12:48 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15820; 27 Nov 96 12:48 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 27 Nov 1996 16:25:24 GMT Received: from ietf.org by MIT.EDU with SMTP id AA00757; Wed, 27 Nov 96 11:25:23 EST Received: from ietf.org by ietf.org id aa24204; 27 Nov 96 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, ietf.org@CNRI.Reston.VA.US MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-cross-00.txt Date: Wed, 27 Nov 1996 10:17:17 -0500 Sender: cclark@ietf.org Message-Id: <9611271017.aa24204@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Public Key Cryptography for Cross-Realm Authentication in Kerberos Author(s) : B. Tung, T. Ryutov, C. Neuman Filename : draft-ietf-cat-kerberos-pk-cross-00.txt Pages : 4 Date : 11/26/1996 This document defines extensions to the Kerberos protocol specification (RFC 1510, "The Kerberos Network Authentication Service (V5)", September 1993) to provide a method for using public key cryptography during cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-kerberos-pk-cross-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerberos-pk-cross-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerberos-pk-cross-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126113240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-pk-cross-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-pk-cross-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126113240.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa17467; 27 Nov 96 12:56 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16043; 27 Nov 96 12:56 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 27 Nov 1996 16:25:13 GMT Received: from [132.151.1.19] by MIT.EDU with SMTP id AA00688; Wed, 27 Nov 96 11:25:10 EST Received: from ietf.org by ietf.org id aa23979; 27 Nov 96 10:16 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, ietf.org@CNRI.Reston.VA.US MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-ftpsec-09.txt Date: Wed, 27 Nov 1996 10:16:40 -0500 Sender: cclark@ietf.org Message-Id: <9611271016.aa23979@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : FTP Security Extensions Author(s) : M. Horowitz, S. Lunt Filename : draft-ietf-cat-ftpsec-09.txt Pages : 22 Date : 11/26/1996 This document defines extensions to the FTP specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings. The following new optional commands are introduced in this specification: AUTH (Authentication/Security Mechanism), ADAT (Authentication/Security Data), PROT (Data Channel Protection Level), PBSZ (Protection Buffer Size), CCC (Clear Command Channel), MIC (Integrity Protected Command), CONF (Confidentiality Protected Command), and ENC (Privacy Protected Command). A new class of reply types (6yz) is also introduced for protected replies. None of the above commands are required to be implemented, but interdependencies exist. These dependencies are documented with the commands. Note that this specification is compatible with RFC 959. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-ftpsec-09.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-ftpsec-09.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-ftpsec-09.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126095819.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-ftpsec-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-ftpsec-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126095819.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa18272; 27 Nov 96 13:18 EST Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16669; 27 Nov 96 13:18 EST Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id ; Wed, 27 Nov 1996 16:43:26 GMT Received: from ietf.org by MIT.EDU with SMTP id AA04927; Wed, 27 Nov 96 11:43:23 EST Received: from ietf.ietf.org by ietf.org id aa12623; 27 Nov 96 11:32 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, ietf.org@CNRI.Reston.VA.US MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-gssv2-cbind-03.txt Date: Wed, 27 Nov 1996 11:32:53 -0500 Sender: cclark@ietf.org Message-Id: <9611271132.aa12623@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Generic Security Service API Version 2 : C-bindings Author(s) : J. Wray Filename : draft-ietf-cat-gssv2-cbind-03.txt Pages : 93 Date : 11/27/1996 This draft document specifies C language bindings for Version 2 of the Generic Security Service Application Program Interface (GSSAPI), which is described at a language-independent conceptual level in other drafts [GSSAPI]. It revises RFC-1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track. The Generic Security Service Application Programming Interface provides security services to its callers, and is intended for implementation atop a variety of underlying cryptographic mechanisms. Typically, GSSAPI callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSSAPI. The GSSAPI allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-gssv2-cbind-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-gssv2-cbind-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127112335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-gssv2-cbind-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127112335.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa20559; 27 Nov 96 14:08 EST Received: from zephyr.isi.edu by ietf.org id aa19250; 27 Nov 96 13:43 EST Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 27 Nov 1996 10:40:00 -0800 Message-Id: <199611271840.AA17986@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC2047 on Message Header Extensions Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 27 Nov 96 10:42:58 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2047: Title: MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text Author: K. Moore Date: November 1996 Mailbox: moore@cs.utk.edu Pages: 15 Characters: 33,262 Obsoletes: 1521, 1522, 1590 URL: ftp://ds.internic.net/rfc/rfc2047.txt STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for textual message bodies in character sets other than US-ASCII, an extensible set of different formats for non-textual message bodies, multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. This third document in the series describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961127103941.RFC@ISI.EDU> SEND /rfc/rfc2047.txt --OtherAccess Content-Type: Message/External-body; name="rfc2047.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961127103941.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa20560; 27 Nov 96 14:08 EST Received: from zephyr.isi.edu by ietf.org id aa19117; 27 Nov 96 13:38 EST Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 27 Nov 1996 10:36:32 -0800 Message-Id: <199611271836.AA17830@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC2046 on Media Types Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 27 Nov 96 10:39:29 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2046: Title: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types Author: N. Freed & N. Borenstein Date: November 1996 Mailbox: ned@innosoft.com, nsb@nsb.fv.com Pages: 44 Characters: 105,854 Obsoletes: 1521, 1522, 1590 URL: ftp://ds.internic.net/rfc/rfc2046.txt STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for textual message bodies in character sets other than US-ASCII, an extensible set of different formats for non-textual message bodies, multi-part message bodies, and textual header information in character sets other than US-ASCII. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961127103450.RFC@ISI.EDU> SEND /rfc/rfc2046.txt --OtherAccess Content-Type: Message/External-body; name="rfc2046.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961127103450.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa20688; 27 Nov 96 14:08 EST Received: from zephyr.isi.edu by ietf.org id aa20088; 27 Nov 96 13:56 EST Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 27 Nov 1996 10:54:15 -0800 Message-Id: <199611271854.AA19260@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC2049 on MIME Conformance Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 27 Nov 96 10:57:12 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2049: Title: Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples Author: N. Freed & N. Borenstein Date: November 1996 Mailbox: ned@innosoft.com, nsb@nsb.fv.com Pages: 24 Characters: 51,207 Obsoletes: RFCs 1521, 1522, 1590 URL: ftp://ds.internic.net/rfc/rfc2049.txt STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for textual message bodies in character sets other than US-ASCII, an extensible set of different formats for non-textual message bodies, multi-part message bodies, and textual header information in character sets other than US-ASCII. This fifth document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961127105453.RFC@ISI.EDU> SEND /rfc/rfc2049.txt --OtherAccess Content-Type: Message/External-body; name="rfc2049.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961127105453.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa28036; 27 Nov 96 16:37 EST Received: from cnri by ietf.org id aa27055; 27 Nov 96 16:25 EST Received: from hera.rbi.informatik.uni-frankfurt.de by CNRI.Reston.VA.US id aa22602; 27 Nov 96 16:25 EST Received: from dbis.informatik.uni-frankfurt.de (roma.dbis.informatik.uni-frankfurt.de) by hera.rbi.informatik.uni-frankfurt.de with SMTP (1.40.112.4/16.2) id AA272229377; Wed, 27 Nov 1996 22:16:17 +0100 Received: from hera.rbi.informatik.uni-frankfurt.de by dbis.informatik.uni-frankfurt.de with smtp (Smail3.1.28.1 #4) id m0vSrL5-000BmsC; Wed, 27 Nov 96 22:16 MET Received: by hera.rbi.informatik.uni-frankfurt.de (1.40.112.4/16.2) id AA272199376; Wed, 27 Nov 1996 22:16:16 +0100 Sender:ietf-request@ietf.org From: "Prof. Zicari" Posted-Date: Wed, 27 Nov 1996 22:16:16 +0100 Received-Date: Wed, 27 Nov 1996 22:16:16 +0100 Message-Id: <199611272116.AA272199376@hera.rbi.informatik.uni-frankfurt.de> Subject: Comdex Internet To: int.net@dbis.informatik.uni-frankfurt.de Date: Wed, 27 Nov 1996 22:16:15 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4818 Source-Info: From (or Sender) name not authenticated. Please distribute it, as you see proper. Regards Roberto Zicari Program Chair ----------------------cut here---------------------------------- A Global Player comes to Germany: Object World Frankfurt '97 Team Up with COMDEX Internet Frankfurt/Main - November 27, 1996. A global player will enter the German IT trade show-market in 1997: SOFTBANK COMDEX Inc. - producer of the series of COMDEX trade shows world wide - will launch COMDEX Internet '97 in Frankfurt/Main together with Object World Frankfurt '97. COMDEX Internet '97 and Object World Frankfurt '97 will take place on October 7 - 10, 1997 in the Sheraton Conference Center Frankfurt (Airport), Frankfurt/Main, Germany. The show will consist of two conferences side by side and one combined exposition. COMDEX Internet '97 will be the premiere COMDEX event in Germany, and will focus on the business use of the Internet. The COMDEX Internet'97 conference will cover topics such as: the Internet as a business communication vehicle, Electronic Commerce, Developing Intranet-based applications, and Java. The Object World Frankfurt '97 conference - now in its sixth year - will cover the practical aspects of applying object technology for business, with particular focus on Finance, Telecom, Healthcare and Manufacturing. Object World Frankfurt has experienced constant growth (1996: 60% larger than 1995) and it is recognized as the most important event for Object Technology in Europe. The combined exposition will consist of three dedicated technology areas: a COMDEX Internet Pavilion, an Object World Pavilion and an Open Systems Pavilion. The exposition has been designed to meet the visitors' expectations for Internet and Object Technology products on multi-vendors, and multi-platform systems as indicated by an independent study conducted by META Group on 139 of the 2,800 visitors of this year's Object World Frankfurt '96. The study indicated that: 72 % of attendees operate on Network Operating Systems 69% of attendees operate on UNIX platforms 64% of attendees operate on Windows Desktops 49% of attendees use object technology for Internet/Web application development. COMDEX Internet '97 and Object World Frankfurt '97 are sponsored and organized by Object World Corp. (a subsidiary of SOFTBANK COMDEX Inc.), Object Management Group and LogOn Technology Transfer GmbH. Information on Conferences and Exhibition: Christiane Sattler LogOn Technology Transfer GmbH Burgweg 14, D-61476 Kronberg/Ts., Germany phone: +49-6173-9558-53 fax: +49-6173-9404-20 e-mail: LogOn@omg.org Web: http://www.ltt.de Press Contact: Birgit Osterholt // Annegret Claushues LogOn Technology Transfer GmbH Burgweg 14, D-61476 Kronberg / Ts., Germany phone: +49-6173-9558-56//9558-55 fax: +49-6173-9404-20 e-mail: 101510.3135@compuserve.com (Osterholt) 101354.1424@compuserve.com (Claushues) Web: http://www.ltt.de Background Information: As of May 3, 1996, the Object World Series has been acquired by the producers of the most successful IT trade events worldwide, SOFTBANK COMDEX. This investment reflects a strategic initiative to join with Object Management Group in a move toward the expansion and commercialization of object technology around the world. Object World is the industry's most important event developed to focus on the commercial and practical aspects of applying object technology and provides an ideal forum for business and technical professionals to experience first hand the real-time practice of object technology standards. SOFTBANK COMDEX Inc. Since the introduction of the first COMDEX event in 1979, SOFTBANK COMDEX has continued to meet the growing needs of the global information technology marketplace. COMDEX/Fall, first held in Las Vegas in 1979, is now the largest trade show in North America. In 1996 and 1997 SOFTBANK COMDEX will produce over 40 information technology events in North America, South America, Europe and Asia, which are expected to include over 7,000 exhibiting companies and attract more than one million attendees from over 120 countries. Web: http://www.comdex.com LogOn Technology Transfer GmbH LogOn Technology Transfer GmbH, founded in 1991, is a privately owned company exclusively focused on the Internet and object technology markets. LogOn is organized into five operating divisions: Trade Shows, Marketing, PR, Training and Business. LogOn organizes Object World Frankfurt since 1993. LogOn is the official representative of the Object Management Group (OMG) for Austria, Benelux, France, Germany, Italy, Scandinavia and Switzerland. OMG is the largest software consortium worldwide with more than 700 company members dedicated to promoting the theory and practice of object technology (OT) for the development of distributed computing systems. Web: http://www.ltt.de   Received: from ietf.org by ietf.org id aa28033; 27 Nov 96 16:37 EST Received: from cnri by ietf.org id aa26985; 27 Nov 96 16:24 EST Received: from hera.rbi.informatik.uni-frankfurt.de by CNRI.Reston.VA.US id aa22576; 27 Nov 96 16:23 EST Received: from dbis.informatik.uni-frankfurt.de (roma.dbis.informatik.uni-frankfurt.de) by hera.rbi.informatik.uni-frankfurt.de with SMTP (1.40.112.4/16.2) id AA272799453; Wed, 27 Nov 1996 22:17:33 +0100 Received: from hera.rbi.informatik.uni-frankfurt.de by dbis.informatik.uni-frankfurt.de with smtp (Smail3.1.28.1 #4) id m0vSrMK-000BmsC; Wed, 27 Nov 96 22:17 MET Received: by hera.rbi.informatik.uni-frankfurt.de (1.40.112.4/16.2) id AA272769452; Wed, 27 Nov 1996 22:17:32 +0100 Sender:ietf-request@ietf.org From: "Prof. Zicari" Posted-Date: Wed, 27 Nov 1996 22:17:32 +0100 Received-Date: Wed, 27 Nov 1996 22:17:32 +0100 Message-Id: <199611272117.AA272769452@hera.rbi.informatik.uni-frankfurt.de> Subject: Comdex Internet To: int.net@dbis.informatik.uni-frankfurt.de Date: Wed, 27 Nov 1996 22:17:32 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4869 Source-Info: From (or Sender) name not authenticated. (apologizes in case if this has been sent twice) Please distribute it, as you see proper. Regards Roberto Zicari Program Chair ----------------------cut here---------------------------------- A Global Player comes to Germany: Object World Frankfurt '97 Team Up with COMDEX Internet Frankfurt/Main - November 27, 1996. A global player will enter the German IT trade show-market in 1997: SOFTBANK COMDEX Inc. - producer of the series of COMDEX trade shows world wide - will launch COMDEX Internet '97 in Frankfurt/Main together with Object World Frankfurt '97. COMDEX Internet '97 and Object World Frankfurt '97 will take place on October 7 - 10, 1997 in the Sheraton Conference Center Frankfurt (Airport), Frankfurt/Main, Germany. The show will consist of two conferences side by side and one combined exposition. COMDEX Internet '97 will be the premiere COMDEX event in Germany, and will focus on the business use of the Internet. The COMDEX Internet'97 conference will cover topics such as: the Internet as a business communication vehicle, Electronic Commerce, Developing Intranet-based applications, and Java. The Object World Frankfurt '97 conference - now in its sixth year - will cover the practical aspects of applying object technology for business, with particular focus on Finance, Telecom, Healthcare and Manufacturing. Object World Frankfurt has experienced constant growth (1996: 60% larger than 1995) and it is recognized as the most important event for Object Technology in Europe. The combined exposition will consist of three dedicated technology areas: a COMDEX Internet Pavilion, an Object World Pavilion and an Open Systems Pavilion. The exposition has been designed to meet the visitors' expectations for Internet and Object Technology products on multi-vendors, and multi-platform systems as indicated by an independent study conducted by META Group on 139 of the 2,800 visitors of this year's Object World Frankfurt '96. The study indicated that: 72 % of attendees operate on Network Operating Systems 69% of attendees operate on UNIX platforms 64% of attendees operate on Windows Desktops 49% of attendees use object technology for Internet/Web application development. COMDEX Internet '97 and Object World Frankfurt '97 are sponsored and organized by Object World Corp. (a subsidiary of SOFTBANK COMDEX Inc.), Object Management Group and LogOn Technology Transfer GmbH. Information on Conferences and Exhibition: Christiane Sattler LogOn Technology Transfer GmbH Burgweg 14, D-61476 Kronberg/Ts., Germany phone: +49-6173-9558-53 fax: +49-6173-9404-20 e-mail: LogOn@omg.org Web: http://www.ltt.de Press Contact: Birgit Osterholt // Annegret Claushues LogOn Technology Transfer GmbH Burgweg 14, D-61476 Kronberg / Ts., Germany phone: +49-6173-9558-56//9558-55 fax: +49-6173-9404-20 e-mail: 101510.3135@compuserve.com (Osterholt) 101354.1424@compuserve.com (Claushues) Web: http://www.ltt.de Background Information: As of May 3, 1996, the Object World Series has been acquired by the producers of the most successful IT trade events worldwide, SOFTBANK COMDEX. This investment reflects a strategic initiative to join with Object Management Group in a move toward the expansion and commercialization of object technology around the world. Object World is the industry's most important event developed to focus on the commercial and practical aspects of applying object technology and provides an ideal forum for business and technical professionals to experience first hand the real-time practice of object technology standards. SOFTBANK COMDEX Inc. Since the introduction of the first COMDEX event in 1979, SOFTBANK COMDEX has continued to meet the growing needs of the global information technology marketplace. COMDEX/Fall, first held in Las Vegas in 1979, is now the largest trade show in North America. In 1996 and 1997 SOFTBANK COMDEX will produce over 40 information technology events in North America, South America, Europe and Asia, which are expected to include over 7,000 exhibiting companies and attract more than one million attendees from over 120 countries. Web: http://www.comdex.com LogOn Technology Transfer GmbH LogOn Technology Transfer GmbH, founded in 1991, is a privately owned company exclusively focused on the Internet and object technology markets. LogOn is organized into five operating divisions: Trade Shows, Marketing, PR, Training and Business. LogOn organizes Object World Frankfurt since 1993. LogOn is the official representative of the Object Management Group (OMG) for Austria, Benelux, France, Germany, Italy, Scandinavia and Switzerland. OMG is the largest software consortium worldwide with more than 700 company members dedicated to promoting the theory and practice of object technology (OT) for the development of distributed computing systems. Web: http://www.ltt.de   Received: from cnri by ietf.org id ab29226; 27 Nov 96 16:59 EST Received: from newdev.harvard.edu by CNRI.Reston.VA.US id aa20148; 27 Nov 96 15:00 EST Received: from netop3.harvard.edu (netop3.harvard.edu [128.103.205.103]) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) with SMTP id OAA03817 for ; Wed, 27 Nov 1996 14:56:56 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by netop3.harvard.edu (8.6.12/8.6.12) with SMTP id OAA07271 for ; Wed, 27 Nov 1996 14:58:24 -0500 Received: from ietf.ietf.org by ietf.org id aa12869; 27 Nov 96 11:33 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: bmwg@harvard.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-ippm-treno-btc-00.txt Date: Wed, 27 Nov 1996 11:33:31 -0500 Sender: cclark@ietf.org Message-ID: <9611271133.aa12869@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Empirical Bulk Transfer Capacity Author(s) : M. Mathis Filename : draft-ietf-bmwg-ippm-treno-btc-00.txt Pages : 5 Date : 11/27/1996 Bulk Transport Capacity (BTC) is a measure of a network's ability to transfer significant quantities of data with a single congestion-aware transport connection (e.g. state-of-the-art TCP). For many applications the BTC of the underlying network dominates the the overall elapsed time for the application, and thus dominates the performance as perceived by a user. The BTC is a property of an IP cloud (links, routers, switches, etc) between a pair of hosts. It does not include the hosts themselves (or their transport-layer software). However, congestion control is crucial to the BTC metric because the Internet depends on the end systems to fairly divide the available bandwidth on the basis of common congestion behavior. The BTC metric is based on the performance of a reference congestion control algorithm that has particularly uniform and stable behavior. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ippm-treno-btc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-ippm-treno-btc-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ippm-treno-btc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127105742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ippm-treno-btc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ippm-treno-btc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127105742.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa29666; 27 Nov 96 17:05 EST Received: from zephyr.isi.edu by ietf.org id aa28977; 27 Nov 96 16:56 EST Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 27 Nov 1996 10:31:14 -0800 Message-Id: <199611271831.AA17682@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC2045 on Internet Message Bodies Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 27 Nov 96 10:34:11 PST Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2045: Title: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies Author: N. Freed & N. Borenstein Date: November 1996 Mailbox: ned@innosoft.com, nsb@nsb.fv.com Pages: 31 Characters: 72,932 Obsoletes: 1521, 1522, 1590 URL: ftp://ds.internic.net/rfc/rfc2045.txt STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for textual message bodies in character sets other than US-ASCII, an extensible set of different formats for non-textual message bodies, multi-part message bodies, and textual header information in character sets other than US-ASCII. This initial document specifies the various headers used to describe the structure of MIME messages. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <961127103026.RFC@ISI.EDU> SEND /rfc/rfc2045.txt --OtherAccess Content-Type: Message/External-body; name="rfc2045.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <961127103026.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa16581; 27 Nov 96 20:22 EST Received: from newdev.harvard.edu by CNRI.Reston.VA.US id aa26870; 27 Nov 96 20:22 EST Received: from netop3.harvard.edu (netop3.harvard.edu [128.103.205.103]) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) with SMTP id UAA04072 for ; Wed, 27 Nov 1996 20:16:57 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by netop3.harvard.edu (8.6.12/8.6.12) with SMTP id UAA08692 for ; Wed, 27 Nov 1996 20:18:25 -0500 Received: from ietf.ietf.org by ietf.org id aa13072; 27 Nov 96 11:34 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: bmwg@harvard.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-ippm-connect-00.txt Date: Wed, 27 Nov 1996 11:33:57 -0500 Sender: cclark@ietf.org Message-ID: <9611271134.aa13072@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Connectivity Author(s) : J. Mahdavi, V. Paxson Filename : draft-ietf-bmwg-ippm-connect-00.txt Pages : 9 Date : 11/27/1996 Connectivity is the basic stuff from which the Internet is made. Therefore, metrics determining whether pairs of hosts (IP addresses) can reach each other must form the base of a measurement suite. We define several such metrics, some of which serve mainly as building blocks for the others. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ippm-connect-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-ippm-connect-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ippm-connect-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127104549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ippm-connect-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ippm-connect-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127104549.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04191; 29 Nov 96 23:24 EST Received: from cnri by ietf.org id ae03301; 29 Nov 96 23:10 EST Received: from mailer.syr.edu by CNRI.Reston.VA.US id aa11144; 29 Nov 96 12:29 EST Received: from weasel.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.0a) with SMTP id C38C9340 ; Fri, 29 Nov 1996 12:28:02 -0500 Received: from weasel.syr.edu (ahbhatt@localhost [127.0.0.1]) by weasel.syr.edu (8.7.6/8.7.3) with SMTP id MAA00390 for ; Fri, 29 Nov 1996 12:27:52 -0500 (EST) X-Orig-Sender: ahbhatt@mailbox.syr.edu Message-ID: <329F1D15.4005@mailbox.syr.edu> Date: Fri, 29 Nov 1996 12:27:49 -0500 Sender:ietf-request@ietf.org From: "Anjana H. Bhatt" X-Mailer: Mozilla 2.01 (X11; I; SunOS 5.4 sun4m) MIME-Version: 1.0 To: ietf@CNRI.Reston.VA.US Subject: IP Management Solutions X-URL: http://www.data.com/cgi-bin/ShowIWatch/Internet_Engineering_Task_Force_(IETF) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Hi, Can you please let me know the some of the solutions developed by the IETF to address the problem of management of IP addresses in the organizations. regards. Anjana.