Received: from cnri by ietf.org id aa15434; 6 Jan 97 14:24 EST Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa18688; 6 Jan 97 14:24 EST Received: (from daemon@localhost) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) id KAA03992 for imap-out; Mon, 6 Jan 1997 10:16:48 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) with ESMTP id KAA03984 for ; Mon, 6 Jan 1997 10:16:44 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (8.7.5/UW-NDC Revision: 2.28 ) id KAA22881; Mon, 6 Jan 1997 10:16:41 -0800 (PST) Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA04263; Mon, 6 Jan 97 10:16:35 -0800 Date: Mon, 6 Jan 1997 10:12:28 -0800 (PST) From: Mark Crispin Subject: re: SCAN command ? To: Andreas Sahlbach Cc: imap@cac.washington.edu In-Reply-To: <3.0.32.19970106102458.00945a40@sdmail.stardiv.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 06 Jan 1997 10:24:59 +0100, Andreas Sahlbach wrote: > Could someone please give me a short description of the SCAN command ? > Or a URL to the spec ? This would be very nice. There is no documentation for the SCAN command, and there are some serious questions as to whether or not we want to continue supporting it. It is an experiment, and should be treated as such. With that caveat in mind, SCAN is like LIST, only it takes a third astring argument. For each file that would be listed, it does a case-independent search through the file (without regard to mailbox format) and returns a LIST untagged result if and only if the search succeeds. In other words, it is like "grep through your directory of folders", and was intended to replace that.   Received: from ietf.org by ietf.org id aa12305; 9 Jan 97 11:19 EST Received: from ietf.ietf.org by ietf.org id aa10583; 9 Jan 97 10:57 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-protocol-15.txt Date: Thu, 09 Jan 1997 10:56:59 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9701091057.aa10583@ietf.org> --NextPart A Revised 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. Note: This revision reflects comments received during the last call period. Title : Service Location Protocol Author(s) : J. Veizades, E. Guttman, C. Perkins, S. Kaplan Filename : draft-ietf-svrloc-protocol-15.txt Pages : 61 Date : 01/08/1997 The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. 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-protocol-15.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-protocol-15.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.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-protocol-15.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: <19970108110448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-protocol-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-protocol-15.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970108110448.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09533; 10 Jan 97 12:20 EST Received: from ietf.ietf.org by ietf.org id aa09362; 10 Jan 97 12:17 EST To: IETF-Announce: ; cc: srv-location@tgv.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: Service Location Protocol to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 10 Jan 1997 12:17:47 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9701101217.aa09362@ietf.org> The IESG has received a request from the Service Location Protocol Working Group to consider "Service Location Protocol" for the status of Proposed Standard. This is a revised version of the protocol, covering changes made as a result of the previous last call AND changes made as a result of recent interoperability testing. The changes between this version and the previously last-called version are: - Lifetime of service registrations are in seconds not minutes. - Clarification: Strings in the protocol are NOT null terminated. - Change in the semantics of Scopes: DAs which have a scope do NOT accept unscoped service registrations or requests. This changed many explanations and the 'requirements' section. - Clarification: Language id and Character type MUST be set in the header. - The 'recent changes section' from the last call #2 has been removed. - 3 typographical errors remain, summarized below in the email. We request these be changed by the RFC editor rather than issuing draft 16. 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 January 22, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from cnri by ietf.org id aa06469; 14 Jan 97 20:04 EST Received: from ietf.org by CNRI.Reston.VA.US id aa26365; 14 Jan 97 20:04 EST Received: from ietf.org by ietf.org id aa06462; 14 Jan 97 20:04 EST Received: from THOR.INNOSOFT.COM by ietf.org id aa06457; 14 Jan 97 20:04 EST Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-6 #8694) with SMTP id <01IE7L8S7ZQUA8CSPM@INNOSOFT.COM> for iesg@ietf.org; Tue, 14 Jan 1997 17:01:27 PST Date: Tue, 14 Jan 1997 17:02:24 -0800 (PST) Sender:iesg-request@ietf.org From: Chris Newman Subject: From the Chair: Response to Mark's complaint (was Re: blank line...) In-reply-to: To: Mark Crispin Cc: Detailed Revision/Update of Message Standards , iesg@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII On Thu, 2 Jan 1997, Mark Crispin wrote: > On 3 Jan 1997 00:05:43 -0000, D. J. Bernstein wrote: > > Putting spaces around dots in addresses is damaging (since Pine barfs) > > Bernstein has been warned multiple times about making personal attacks, > including a public warning on November 27. > > This is another one. The statement "(since Pine barfs)" is incorrect. It has > never been correct. I do not believe making statements about the correctness of a product counts as a personal attack. In fact, it is often relevant to the group discussion (e.g. the MS Mail SMTP server's capitalization behavior). In addition, if the term "barf" (an imprecise term) is interpreted to mean "generates an error notification", then Dan's statement may be both accurate and relevant. On the other hand, the issue of "." in specials is suspended because it has been discussed too much and no clear concensus has emerged to date. So your original statement and Dan's response were both out of order. > This has been an ongoing problem for many months. He has received very many > "second chances". Would the chair, and IESG, please take appropriate remedial > action (again)? As I have stated before, the correct way to complain that someone is being disruptive is *privately* to the chair. You are more likely to get the response you desire if you follow the protocol I've outlined before. In this case, the chair does not believe such action is warranted. Formal appeals of the chair's ruling may be directed to the IESG.   Received: from cnri by ietf.org id aa08507; 14 Jan 97 22:12 EST Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa28328; 14 Jan 97 22:12 EST Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id VAA17266 for ietf-nntp-outgoing; Tue, 14 Jan 1997 21:09:41 -0600 (CST) X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (sob@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.4/8.7.3) with ESMTP id VAA17260 for ; Tue, 14 Jan 1997 21:09:38 -0600 (CST) Received: (from sob@localhost) by academ.com (8.8.4/8.7.1) id VAA00543; Tue, 14 Jan 1997 21:09:16 -0600 (CST) Message-Id: <199701150309.VAA00543@academ.com> From: Stan Barber Date: Tue, 14 Jan 1997 21:09:16 CST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Evan Champion Subject: Re: ietf-nntp Newsgroup Name Length Question Cc: Ernie Vanden-Ende , "'ietf-nntp@academ.com'" Sender: owner-ietf-nntp@academ.com Precedence: bulk Evan, no one including myself is saying that there is a standard in this area. I was writing what I have observed over the life of USENET as being the general practice for the core seven/eight hierarchies. If we do have to define a standard in this area for the purpose of doing RFC 977 bis, then we do need to come to some definition that does not break group names in the core seven/eight hierarchies. I don't know if we have to accomodate naming in alt, regionals or some of the other hierarchies. Personally, I would rather the RFC1036 bis work deal with this. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.   Received: from ietf.org by ietf.org id aa03828; 17 Jan 97 12:26 EST Received: from webserver.casc.com by ietf.org id aa03573; 17 Jan 97 12:20 EST Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id MAA18414; Fri, 17 Jan 1997 12:17:15 -0500 Received: from spice.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id MAA14710; Fri, 17 Jan 1997 12:20:02 -0500 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id MAA00889; Fri, 17 Jan 1997 12:20:02 -0500 Date: Fri, 17 Jan 1997 12:20:02 -0500 (EST) Sender:ietf-request@ietf.org From: "Andrew G. Malis" X-Sender: amalis@spice To: Walter Ian Kaye cc: ietf@ietf.org Subject: Re: Drafts, RFCs, Informational, Experimental... which to use? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Walter, > How do I determine which type of document to use for describing an internet > proposal? I've read RFC 1543, and its "descriptions" of each type are > totally useless. Can anyone here provide a general method for determining > which type of document to use? I highly recommend that you read RFC 2026 - it just may answer all of your questions. I next suggest that you check out the list of IETF working groups at www.ietf.org - there may already be a working group related to what you would like to propose. If there is, contact the chair(s) to ask about submitting your proposal to the WG. In any case, you should probably first publish your proposal in the form of an internet draft. In addition to RFC 1543, you may find the file ftp://ds.internic.net/ietf/1id-guidelines.txt helpful, as well as the templates for various obsolete :-) document preparation systems that you can find in the files ftp://ds.internic.net/internet-drafts/2-*.template. Once you've written your draft, see the directions in 1id-guidelines for getting it into the internet-drafts directory. Once it's publicly available, it can then be discussed on the relevant WG's email list, or on the ietf list. I hope this helps! Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@casc.com phone:508 952-7414 fax:508 392-9250 Cascade Communications Corp. 5 Carlisle Road Westford, MA 01886   Received: from cnri by ietf.org id aa10880; 17 Jan 97 14:33 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa19294; 17 Jan 97 14:33 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id OAA15141; Fri, 17 Jan 1997 14:19:35 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1773029 for TN3270E@LIST.NIH.GOV; Fri, 17 Jan 1997 14:19:32 -0500 Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by list.nih.gov (8.7.5/8.6.12) with SMTP id OAA15128 for ; Fri, 17 Jan 1997 14:19:30 -0500 (EST) Received: from mboe-home-ss20.cisco.com (mboe-home-ss20.cisco.com [171.69.136.130]) by foxhound.cisco.com (8.6.12/8.6.5) with ESMTP id LAA03870; Fri, 17 Jan 1997 11:18:59 -0800 Received: from localhost ([127.0.0.1]) by mboe-home-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id OAA02837; Fri, 17 Jan 1997 14:18:58 -0500 Date: Fri, 17 Jan 1997 14:18:58 -0500 (EST) From: Michael Boe Reply-To: Michael Boe Subject: Re: Tying up loose ends in RFC 1647 To: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Cc: Bill Kelly , TN3270E list In-Reply-To: <9701171818.AA40744@commanche.ca.boeing.com.> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov > Bill > > We've been quiet on the list and just listening until: > > > "Security issues are not addressed in this document". That's essentially > > what 1647 does. Do we get "grandfathered" in and can get away with doing > > this, or do we have to do something more? > > > > That my be fine for a university but if the vendors want customers > for TN3270e products IT MUST HAVE REAL SECURITY. As it stands today, > using TN3270e in an global network or Internet environment is leaving > your host COMPLETELY OPEN to access and/or use by the rest of the world. > > That is NOT an acceptable business risk and will essentially prevent > any widespread usage of TN3270e as part of a worldwide business > communication environment. > > A "last call" at this time seems inappropriate and without the security > part (which seemed to be agreed to in the earlier proposed charters) > interest in the WG will probably drop off significantly. Terry, At the BOF we discussed whether or not RFC1647 should be pushed forward to the next stage of standardization. It was generally agreed (that is, there were several sounds of support and no sounds of objection from you or anyone else) that we should push forward with getting RFC1647 to the next step of standardization. As you know, the next step of standardization allows changes to the RFC, but only those which correct existing functionality, or drop existing functionality. So...I'm a bit confused. Adding security to the RFC would appear to nix the chances of it getting to the next phase of standardization in the short term (unless you are suggesting getting rid of printer LUs as part of security measures ;-). On the other hand, you didn't voice any objections to pushing the RFC1647 forward along the standards track. Which one is more important to you? Remember that we are planning "minor enhancements" to TN3270E as a part of the new RFCs to be written by the WG. My understanding is that security will be addressed fully as a part those "minor enhancements." [Aside: anything involving security issues is never "minor"--I suggest we be a bit more honest in the naming and staffing of this piece of work.] Ed/Deric, is my understanding correct here? /msb   Received: from ietf.org by ietf.org id aa02813; 19 Jan 97 17:04 EST Received: from cs.nps.navy.mil by ietf.org id aa02567; 19 Jan 97 16:58 EST Received: from capella.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA03639; Sun, 19 Jan 97 13:53:56 PST Sender:ietf-request@ietf.org From: Don Brutzman Received: by capella.cs.nps.navy.mil (4.1) id AA06962; Sun, 19 Jan 97 13:53:45 PST Message-Id: <9701192153.AA06962@capella.cs.nps.navy.mil> Subject: Re: Ipv6 thread goes to sockets mailing lists, returns happy! To: Sampo Syreeni Date: Sun, 19 Jan 1997 13:53:45 -0800 (PST) Cc: TurnerX_Rentz@ccm.jf.intel.com, ietf@ietf.org, Jim Nierle , Dan Boger , Information Infrastructure Research Group In-Reply-To: from "Sampo Syreeni" at Jan 19, 97 02:39:20 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Content-Length: 4639 Source-Info: From (or Sender) name not authenticated. I'm not sure why the preceding discussion (attached below) is on the big ietf list. Here are some further details and a request to take the discussion elsewhere, unless there is some pressing reason to keep it on the big list. The document in question is a (great) master's thesis and not USMC policy. It is written with a very specific network environment in mind. ================================= Internetworking: Technical Strategy for Implementing the Next Generation Internet Protocol (IPv6) in the Marine Corps Tactical Data Network James E. Nierle Master's Thesis Naval Postgraduate School Monterey California USA June 1996 http://www.stl.nps.navy.mil/~jenierle/thesis.html Available in HTML and Postscript Abstract. The Marine Corps must architect a tactical internet based on a software technology that is in transition - the Internet Protocol (IP). Development of the Marine Corps' tactical internetworking system (Tactical Data Network or TDN) is progressing concurrently with the global Internet community's development of the Next Generation Internet Protocol (IPv6). Current (IPv4) and next generation (IPv6) versions of the Internet Protocol can together meet the tactical internetworking needs of the Marine Corps. IPv4 provides universal interoperability with other networking technologies and support for a wide range of services now, but without enhancements IPv4 cannot meet the long-terms needs of evolving tactical applications. IPv6 is needed to meet emerging requirements (such as secure mobility) but is not yet ready for implementation in the Tactical Data Network. Therefore the Marine Corps must build the tactical internet architecture using IPv4 and incorporate IPv6 improvements when transition is possible. Marine Corps commitment to IP is essential to ensure universal interoperability and hardware-independent evolution of tactical applications and networking technology. This work presents a tactical IP addressing plan for TDN that works with IPv4 and also facilitates smooth transition to IPv6. In concert with the other military services, the Marine Corps must develop a strategy for migrating the joint tactical internet to IPv6. The future viability of the Tactical Data Network depends on the Internet Protocol. ================================= All that said, Sampo's clarifying comments below appear valid. Thanks for yours and TurnerX Rentz's interest. Sampo Syreeni writes: > > On Sat, 18 Jan 1997, TurnerX Rentz wrote: > > > 4. The Marine Corps seems to think current address space is sufficient > > http://stl.nps.navy.mil/~jenierle/chapt8.html > > Somehow I get the impression that isn't quite what is said. The author > indicates that the current address space is sufficient for the TDN. > However, just about the first thing said in chapter eight is "Exhaustion > of IPv4 address space is the primary factor is forcing the move toward > IPv6 in the global Internet. The tactical internet's need for IPv6 is > somewhat different. Address space will not be a problem for the Tactical > Data Network (TDN) if the Marine Corps implements the tactical IP > addressing plan proposed in this study.". So what is said is that the > Marine Corps has no forcing need for the larger address space, but the > Internet as a whole sure has. > > > The military document above outlines a strategy for dual stack > > migration, I would like to see something as high up as what > > we have to do as application layer developers (you have to > > assume the OS people are going to do their job in the commercial > > world). > > I would think that in the case of the standard off the shelf applications, > the modifications boil down to changing IP address size buffers and handling > errors a bit differently. As the logical structure of DNS addresses would > not seem to change much and the network level details are well > encapsulated, you shouldn't need to do much. Unless you want to use > multicast, security or other similar options new to IPv6. > > Sampo Syreeni, student, Decoy/dAWN all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman   Received: from cnri by ietf.org id aa20701; 22 Jan 97 7:19 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa07630; 22 Jan 97 7:19 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id HAA05669; Wed, 22 Jan 1997 07:08:16 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1812028 for TN3270E@LIST.NIH.GOV; Wed, 22 Jan 1997 07:08:13 -0500 Received: from fxiod05.is.chrysler.com (firewall-user@fxiod05.is.chrysler.com [204.189.94.74]) by list.nih.gov (8.7.5/8.6.12) with SMTP id GAA05505 for ; Wed, 22 Jan 1997 06:57:31 -0500 (EST) Received: by fxiod05.is.chrysler.com; id AA18156; Wed, 22 Jan 97 06:57:31 EST Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod05.is.chrysler.com via smap (V3.1.1) id xma018118; Wed, 22 Jan 97 06:57:08 -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 GAA21545; Wed, 22 Jan 1997 06:43:43 -0500 (EST) Message-Id: <3.0.32.19970121160114.009926f0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Jan 1997 06:54:45 -0500 To: "Terry L. Davis, Boeing Information & Support Services, Bellevue,\ WA" , Bill Kelly From: Robert Moskowitz Subject: Re: Tying up loose ends in RFC 1647 Cc: TN3270E list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tn3270e@list.nih.gov At 10:18 AM 1/17/97 -0800, Terry L. Davis, Boeing Information & Support > >That my be fine for a university but if the vendors want customers >for TN3270e products IT MUST HAVE REAL SECURITY. As it stands today, >using TN3270e in an global network or Internet environment is leaving >your host COMPLETELY OPEN to access and/or use by the rest of the world. Opening up security will be a can of worms, I must admit. I believe the best we will be able to do is list a set of alternatives. Sitting here at National airport after attending 3 security meetings in one day, I'd list the following: TELNET Auth and Encryp -- Kerberos based SSL (WTS) Client auth and encrypt -- X.509 based IPsec -- DNSsec and/or X.509 based Each of these have their pros and cons. I am partial to IPsec, but SSL or its IETF follow-on (WTS I believe is the wg) has some deployment advantages, being more of an app toolkit whereas IPsec is more of a TCP/IP kernel toolkit. Kerberos in a trading partner environment, I have trouble with. We are doing a SSL/DCE combo here at www.spin.chrysler.com and I do not like some key aspects of the model. Robert Moskowitz Chrysler Corporation (810) 758-8212   Received: from cnri by ietf.org id aa20756; 22 Jan 97 7:19 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa07650; 22 Jan 97 7:19 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id HAA05696; Wed, 22 Jan 1997 07:08:29 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1812029 for TN3270E@LIST.NIH.GOV; Wed, 22 Jan 1997 07:08:26 -0500 Received: from fxiod05.is.chrysler.com (firewall-user@fxiod05.is.chrysler.com [204.189.94.74]) by list.nih.gov (8.7.5/8.6.12) with SMTP id GAA05512 for ; Wed, 22 Jan 1997 06:57:35 -0500 (EST) Received: by fxiod05.is.chrysler.com; id AA18159; Wed, 22 Jan 97 06:57:31 EST Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod05.is.chrysler.com via smap (V3.1.1) id xma018120; Wed, 22 Jan 97 06:57:09 -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 GAA21551; Wed, 22 Jan 1997 06:43:45 -0500 (EST) Message-Id: <3.0.32.19970121162244.00992280@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Jan 1997 06:54:47 -0500 To: "Terry L. Davis, Boeing Information & Support Services, Bellevue,\ WA" , Michael Boe From: Robert Moskowitz Subject: Re: Tying up loose ends in RFC 1647 Cc: Bill Kelly , TN3270E list , tytso@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tn3270e@list.nih.gov At 01:09 PM 1/17/97 -0800, Terry L. Davis, Boeing Information & Support >> >I think you'll have a great deal of difficulty getting folks to recommend >use of TN3270e for corporate business on anything but encrypted links or >with a token card as the primary authentication through a firewall (which >BTW the user community hates) without fixing security. Firewall and encryption are really interesting challenges. Does the firewall participate in the authentication or does it let it through unencumbered. BTW, SSL firewall proxies are only good for outbound traffic. For inbound, the external clients have to specify your firewall as their SSL proxy. This is impossible with a trading partner that will need to go to multiple sites. Thus the best we will be able to do is to agree on a basic set of security functions that can be set up. For example, if auth/encrypt is used, the traffic is passed through the firewall to the TN3270E server for auth/decrypt. Robert Moskowitz Chrysler Corporation (810) 758-8212   Received: from cnri by ietf.org id aa27464; 24 Jan 97 9:00 EST Received: from merit.edu by CNRI.Reston.VA.US id aa10167; 24 Jan 97 9:00 EST Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id IAA01783; Fri, 24 Jan 1997 08:55:10 -0500 (EST) Resent-Date: Fri, 24 Jan 1997 08:55:10 -0500 (EST) Date: Fri, 24 Jan 1997 08:53:06 -0500 (EST) From: Connie Leblanc To: Robert Webster/Shiva Corporation Cc: Leemay_Yen , ietf-ppp Subject: Re: BACP/BAP Protocol ID backward compatibility In-Reply-To: <9701232113.AA2799@SMTP.shiva.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"scDST1.0.YR.vyBwo"@merit.edu> Resent-From: ietf-ppp@merit.edu X-Mailing-List: archive/latest/2580 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@merit.edu On 23 Jan 1997, Robert Webster/Shiva Corporation wrote: > Shiva released a BACP PPP client product with the old protocol ID's and I > believe that we plan to just ignore the old ID's when our next version client > and > servers come out. I think other vendors will be fine doing this, as well. If you ignore the old ID's, does that not mean that your new BACP code will not work with implementations (other vendors and your own) that are currently already out there? Gandalf has three products released last year with BACP. Anyone ignoring the old protocol ids will not be able to do BACP with these until they are updated. Is it not a better idea to handle both sets? Connie > > Rob Webster > Shiva Corp. > > To: ietf-ppp @ MERIT.EDU @ SMTPMAIL > cc: Leemay_Yen @ 3mail.3Com.COM @ SMTPMAIL > From: Leemay_Yen @ 3mail.3Com.COM @ SMTPMAIL > Date: 01/23/97 10:09:05 AM > Subject: BACP/BAP Protocol ID backward compatibility > > > > > > Hi, > > In Jan. 4's message: > > > 1) Mark 0071 and 8071 as `reserved'. They were assigned to BAP/BACP > > in a draft that will not advance. 8071 should never be > > reassigned. > > > > This has been completed. > > > > 2) Assign two new protocol numbers for BAP and BACP; BAP, being a > > protocol that controls aspects of the link, should come from the > > range c001-feff, and BACP, being a Network Control Protocol, > > should come from the range 8001-beff. Please select these two > > values such that (BAP-BACP)==0xc000-0x8000, i.e. essentially they > > should end in the same three digits. The entries should appear > > as follows, with the X's replaced with the values you assign: > > > > The following has been assigned: > > > > c02b Bandwidth Allocation Control Protocol > > c02d Bandwidth Allocation Protocol > > > > I heard that some products have released their BACP (before Jan. 4, I > assume). > Should we try to maintain the (protocol id) backward compatibility since > the original > assigned id's are reserved ? I think the new draft should make a note about > this > even the answer is no. > > Any comments are greatly appreciated. > > Leemay Yen > 3Com > > > > Connie Leblanc cleblanc@gandalf.ca Software Designer (613)274-6500 ex. 8019 Gandalf Technologies Inc. "Opinions expressed by me are not Nepean, Ontario K2E 7M4 necessarily those of a sane person."   Received: from cnri by ietf.org id aa05536; 24 Jan 97 11:15 EST Received: from merit.edu by CNRI.Reston.VA.US id aa13893; 24 Jan 97 11:15 EST Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA04157; Fri, 24 Jan 1997 11:08:07 -0500 (EST) Resent-Date: Fri, 24 Jan 1997 11:08:07 -0500 (EST) Message-Id: <9701241905.AA9210@SMTP.shiva.com> To: Connie Leblanc Cc: Robert Webster/Shiva Corporation , Leemay_Yen , ietf-ppp From: Robert Webster/Shiva Corporation Date: 24 Jan 97 10:53:09 EDT Subject: Re: BACP/BAP Protocol ID backward compatibility Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"ByzoK.0.a01.avDwo"@merit.edu> Resent-From: ietf-ppp@merit.edu X-Mailing-List: archive/latest/2582 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@merit.edu At last we heard, only the Ascend servers and the Shiva Client had been released with the old Proto ID's. Apparently, this was incorrect information. Has anyone else shipped code with the old Proto ID's? Rob Webster Shiva Corp. To: rwebster @ shiva.com (Robert Webster/Shiva Corporation) @ SMTPMAIL cc: Leemay_Yen @ 3mail.3Com.COM @ SMTPMAIL, ietf-ppp @ MERIT.EDU @ SMTPMAIL From: cleblanc @ gandalf.ca (Connie Leblanc) @ SMTPMAIL Date: 01/24/97 08:53:06 AM Subject: Re: BACP/BAP Protocol ID backward compatibility On 23 Jan 1997, Robert Webster/Shiva Corporation wrote: > Shiva released a BACP PPP client product with the old protocol ID's and I > believe that we plan to just ignore the old ID's when our next version client > and > servers come out. I think other vendors will be fine doing this, as well. If you ignore the old ID's, does that not mean that your new BACP code will not work with implementations (other vendors and your own) that are currently already out there? Gandalf has three products released last year with BACP. Anyone ignoring the old protocol ids will not be able to do BACP with these until they are updated. Is it not a better idea to handle both sets? Connie > > Rob Webster > Shiva Corp. > > To: ietf-ppp @ MERIT.EDU @ SMTPMAIL > cc: Leemay_Yen @ 3mail.3Com.COM @ SMTPMAIL > From: Leemay_Yen @ 3mail.3Com.COM @ SMTPMAIL > Date: 01/23/97 10:09:05 AM > Subject: BACP/BAP Protocol ID backward compatibility > > > > > > Hi, > > In Jan. 4's message: > > > 1) Mark 0071 and 8071 as `reserved'. They were assigned to BAP/BACP > > in a draft that will not advance. 8071 should never be > > reassigned. > > > > This has been completed. > > > > 2) Assign two new protocol numbers for BAP and BACP; BAP, being a > > protocol that controls aspects of the link, should come from the > > range c001-feff, and BACP, being a Network Control Protocol, > > should come from the range 8001-beff. Please select these two > > values such that (BAP-BACP)==0xc000-0x8000, i.e. essentially they > > should end in the same three digits. The entries should appear > > as follows, with the X's replaced with the values you assign: > > > > The following has been assigned: > > > > c02b Bandwidth Allocation Control Protocol > > c02d Bandwidth Allocation Protocol > > > > I heard that some products have released their BACP (before Jan. 4, I > assume). > Should we try to maintain the (protocol id) backward compatibility since > the original > assigned id's are reserved ? I think the new draft should make a note about > this > even the answer is no. > > Any comments are greatly appreciated. > > Leemay Yen > 3Com > > > > Connie Leblanc cleblanc@gandalf.ca Software Designer (613)274-6500 ex. 8019 Gandalf Technologies Inc. "Opinions expressed by me are not Nepean, Ontario K2E 7M4 necessarily those of a sane person."   Received: from cnri by ietf.org id aa11934; 24 Jan 97 13:04 EST Received: from merit.edu by CNRI.Reston.VA.US id aa17127; 24 Jan 97 13:04 EST Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA05872; Fri, 24 Jan 1997 12:44:33 -0500 (EST) Resent-Date: Fri, 24 Jan 1997 12:44:33 -0500 (EST) Message-ID: <32E884ED.320F@zyxel.com> Date: Fri, 24 Jan 1997 09:46:21 +0000 From: Troy Gau Reply-To: troy@zyxel.com Organization: ZyXEL Communications, Inc. X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Robert Webster/Shiva Corporation CC: ietf-ppp Subject: Re: BACP/BAP Protocol ID backward compatibility References: <9701241905.AA9210@SMTP.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8ZU8O2.0.RR1.yJFwo"@merit.edu> Resent-From: ietf-ppp@merit.edu X-Mailing-List: archive/latest/2585 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@merit.edu Robert Webster/Shiva Corporation wrote: > > At last we heard, only the Ascend servers and the Shiva Client had been released > with the old Proto ID's. Apparently, this was incorrect information. > > Has anyone else shipped code with the old Proto ID's? > > Rob Webster > Shiva Corp. ZyXEL has, in both our TA and router.   Received: from ietf.org by ietf.org id aa02674; 27 Jan 97 13:55 EST Received: from ietf.ietf.org by ietf.org id aa01524; 27 Jan 97 13:35 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-marsmcs-02.txt Date: Mon, 27 Jan 1997 13:35:14 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9701271335.aa01524@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 : Multicast Server Architectures for MARS-based ATM multicasting. Author(s) : R. Talpade, M. Ammar Filename : draft-ietf-ion-marsmcs-02.txt Pages : 19 Date : 01/24/1997 A mechanism to support the multicast needs of layer 3 protocols in general, and IP in particular, over UNI 3.0/3.1 based ATM networks has been described in RFC 2022. Two basic approaches exist for the intra-subnet (intra-cluster) multicasting of IP packets. One makes use of a mesh of point to multipoint VCs (the 'VC Mesh' approach), while the other uses a shared point to multipoint tree rooted on a Multicast Server (MCS). This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality. 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-marsmcs-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-marsmcs-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.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-marsmcs-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: <19970124101803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-marsmcs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-marsmcs-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970124101803.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06392; 27 Jan 97 14:33 EST Received: from ietf.ietf.org by ietf.org id aa06091; 27 Jan 97 14:28 EST To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: IP Broadcast over ATM Networks to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 27 Jan 1997 14:28:51 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9701271428.aa06091@ietf.org> The IESG has received a request from the Internetworking Over NBMA Working Group to consider "IP Broadcast over ATM Networks" 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 February 10, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from ietf.org by ietf.org id aa07748; 27 Jan 97 14:58 EST Received: from ietf.ietf.org by ietf.org id aa07460; 27 Jan 97 14:50 EST To: IETF-Announce: ; cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Last Call: Multiprotocol Interconnect over Frame Relay to Standard Reply-to: iesg@ietf.org Date: Mon, 27 Jan 1997 14:50:39 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9701271450.aa07460@ietf.org> The IESG has received a request from the Internetworking Over NBMA Working Group to consider "Multiprotocol Interconnect over Frame Relay" for the status of Standard. This action will Obsolete RFC 1294 and RFC 1490. 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 February 10, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/   Received: from cnri by ietf.org id aa13209; 28 Jan 97 11:41 EST Received: from ietf.org by CNRI.Reston.VA.US id aa14342; 28 Jan 97 11:41 EST Received: from ietf.org by ietf.org id aa13198; 28 Jan 97 11:40 EST Received: from kentrox.kentrox.com by ietf.org id aa13194; 28 Jan 97 11:40 EST Received: by kentrox.com (/\==/\ Smail3.1.28.1 #28.5) id ; Tue, 28 Jan 97 08:38 PST Received: from kentrox.com (skeeter) by bertha.kentrox.com (4.1/SMI-4.1) id AA21414; Tue, 28 Jan 97 08:38:40 PST Received: by kentrox.com (4.1/SMI-4.1_KTX1.1) id AA11284; Tue, 28 Jan 97 08:38:39 PST Date: Tue, 28 Jan 1997 08:38:38 -0800 (PST) Sender:iesg-request@ietf.org From: Gary Hanson X-Sender: gary@skeeter To: iesg@ietf.org Cc: ion@nexen.com Subject: Re: Last Call: Multiprotocol Interconnect over Frame Relay to Standard In-Reply-To: <9701271450.aa07460@ietf.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I see one minor typo in the draft that was carried over from RFC 1490. In section 9 on page 26, there is a reference to "the encapsulation described within section 7." The referenced section number should be changed either to "section 4", or more precisely, to "section 4.2". Regards, Gary On Mon, 27 Jan 1997, The IESG wrote: > > The IESG has received a request from the Internetworking Over NBMA Working > Group to consider "Multiprotocol Interconnect over Frame Relay" > for the status of Standard. > > This action will Obsolete RFC 1294 and RFC 1490. > > 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 February 10, 1997. > > Files can be obtained via ftp://ds.internic.net/internet-drafts/ >   Received: from cnri by ietf.org id aa13949; 28 Jan 97 12:13 EST Received: from ietf.org by CNRI.Reston.VA.US id aa15202; 28 Jan 97 12:13 EST Received: from ietf.org by ietf.org id aa13935; 28 Jan 97 12:13 EST Received: from webserver.casc.com by ietf.org id aa13931; 28 Jan 97 12:13 EST Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id MAA13442; Tue, 28 Jan 1997 12:10:00 -0500 Received: from spice.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id MAA23145; Tue, 28 Jan 1997 12:12:47 -0500 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id MAA01128; Tue, 28 Jan 1997 12:12:48 -0500 Date: Tue, 28 Jan 1997 12:12:47 -0500 (EST) Sender:iesg-request@ietf.org From: "Andrew G. Malis" X-Sender: amalis@spice Reply-To: "Andrew G. Malis" To: Gary Hanson cc: iesg@ietf.org, ion@nexen.com Subject: Re: Last Call: Multiprotocol Interconnect over Frame Relay to Standard In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Gary, > I see one minor typo in the draft that was carried over from RFC 1490. > In section 9 on page 26, there is a reference to "the encapsulation > described within section 7." The referenced section number should > be changed either to "section 4", or more precisely, to "section 4.2". Thanks for the sharp eyes. I just started -03.nro to record this and other such fixes that come up during the last call. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@casc.com phone:508 952-7414 fax:508 392-9250 Cascade Communications Corp. 5 Carlisle Road Westford, MA 01886