[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Sounds like the only people that should be bothered by AOLs action
is their subscribers who will not be able to receive some *legitimate*
mail that was directed to them. If you contract with a service provider
to provide you with Internet mail service, you want to be able to recive
any mail directed to you. AOL doing this is only hurting their
customers who believe this is unfair (which if I were a customer, I
would view as unfair). What would really concern me is if other
providers think this is a *good* idea and such implementations spread.
If a large portion of their customers are unhappy, they will change
their behavior. I am curious if they have told their customers that
their actions, while *temporarily* blocking some spam, may also
deny them access to some legitimate mail? I suspect if they knew,
they would not be so happy with this *temporary* solution.
I hate bang (!) addresses because many MTAs deal with them
improperly, but I believe that !, %, or other source routes do have
legitimate uses, as presented well by others in this thread.
Received: from ietf.org by ietf.org id aa15586; 9 May 97 17:53 EDT
Received: from cnri by ietf.org id aa15434; 9 May 97 17:49 EDT
Received: from shiva.jussieu.fr by CNRI.Reston.VA.US id aa22317;
9 May 97 17:49 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id SAA10831
; Fri, 9 May 1997 18:54:14 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id SAA21357
; Fri, 9 May 1997 18:47:43 +0200 (MET DST)
Received: from fcgnet.com ([199.196.33.22])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with SMTP id SAA09601
; Fri, 9 May 1997 18:42:31 +0200 (METDST)
Received: from fcgmail4.fcgnet.com by fcgnet.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO)
id KAA00783; Fri, 9 May 1997 10:00:13 -0700
Received: by fcgmail4.fcgnet.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
id <01BC5C5D.128596F0 at fcgmail4.fcgnet.com>; Fri, 9 May 1997 09:40:47 -0700
Message-ID: <c=US%a=_%p=FCG%l=FCGMAIL4-970509164044Z-15273 at fcgmail4.fcgnet.com>
Sender:ietf-request at ietf.org
From: "Kern, Mark" <mkern at fcgnet.com>
To: "'2IN97 at prism.uvsq.fr'" <2IN97 at prism.uvsq.fr>,
"'congres at prism.uvsq.fr'" <congres at prism.uvsq.fr>,
"'BENKING at faw.uni-ulm.de'" <BENKING at faw.uni-ulm.de>
Subject: remove
Date: Fri, 9 May 1997 09:40:44 -0700
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
for those of you who are in the same boat I am in, and did not subscribe
to this list, I would recommend doing what I am now doing and send your
removal requests to root at prism.uvsq.fr and root at faw.uni-ulm.de and
hopefully those admins will become annoyed enough to remove us.
Received: from ietf.org by ietf.org id aa15799; 9 May 97 17:56 EDT
Received: from cnri by ietf.org id aa15658; 9 May 97 17:54 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22542;
9 May 97 17:54 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA15947>; Fri, 9 May 1997 14:50:59 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id OAA11587
; Fri, 9 May 1997 14:31:43 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id OAA07503
; Fri, 9 May 1997 14:08:41 +0200 (MET DST)
Received: from cf01 (cledf.edf.fr [192.54.193.133])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA05886
; Fri, 9 May 1997 14:08:39 +0200 (METDST)
Received: from clserv02.edf.fr (clserv02.edf.fr [130.98.118.118]) by cf01 (8.6.12/8.6.12) with ESMTP id OAA10408; Fri, 9 May 1997 14:08:11 +0200
Received: from cli51ak.der.edf.fr (cli51ak.der.edf.fr [130.98.32.66]) by clserv02.edf.fr (8.6.12/8.6.12) with ESMTP id OAA28106; Fri, 9 May 1997 14:08:20 +0200
Received: by cli51ak.der.edf.fr (SMI-8.6/SMI-SVR4)
id OAA18232; Fri, 9 May 1997 14:10:07 +0100
Sender:ietf-request at ietf.org
From: Daniel Glazman <Daniel.Glazman at der.edfgdf.fr>
Message-Id: <199705091310.OAA18232 at cli51ak.der.edf.fr>
Subject: Re: REMOVE
To: Giuseppe Fabio Campanale <campanal at rap3.cefriel.it>
Date: Fri, 9 May 1997 14:10:07 +0100 (WET DST)
Cc: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Reply-To: Daniel.Glazman at der.edf.fr
In-Reply-To: <33730D3B.55A at mailer.cefriel.it> from "Giuseppe Fabio Campanale" at May 9, 97 01:40:43 pm
X-Mailer: ELM [version 2.4 PL24 ME8]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Received: from ietf.org by ietf.org id aa16010; 9 May 97 17:57 EDT
Received: from cnri by ietf.org id aa15862; 9 May 97 17:56 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22600;
9 May 97 17:56 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA16044>; Fri, 9 May 1997 14:53:11 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id SAA04925
; Fri, 9 May 1997 18:01:30 +0200 (METDST)
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id RAA19351
; Fri, 9 May 1997 17:53:37 +0200 (MET DST)
Received: from Hypatia.Stanford.EDU (Hypatia.Stanford.EDU [36.9.0.122])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id RAA03701
; Fri, 9 May 1997 17:53:32 +0200 (METDST)
Received: from Turing.Stanford.EDU (Turing.Stanford.EDU [36.9.0.14]) by Hypatia.Stanford.EDU (8.8.5/8.8.3) with ESMTP id HAA22657; Fri, 9 May 1997 07:56:05 -0700 (PDT)
Received: from localhost (ole at localhost)
by Turing.Stanford.EDU (8.8.5/8.8.5) with SMTP id HAA11977;
Fri, 9 May 1997 07:56:57 -0700 (PDT)
X-Authentication-Warning: Turing.Stanford.EDU: ole owned process doing -bs
Date: Fri, 9 May 1997 07:56:56 -0700 (PDT)
Sender:ietf-request at ietf.org
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
X-Sender: ole at Turing.Stanford.EDU
To: "Michel Gardie (LOR-AIGRI)" <michel at hugo.int-evry.fr>
Cc: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: Re: remove
In-Reply-To: <Pine.SUN.3.95.970509160016.11149C-100000 at iznogoud>
Message-Id: <Pine.GSO.3.95.970509075451.11945A-100000 at Turing.Stanford.EDU>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
EVERYONE, PLEASE: Stop copying the entire list with your requests, send
your reply to the SENDER only. I am sure none of us wanted to be on these
list, but the traffic resulting from "remove me" requests is much greater
than the original message. And yes, I am contributing to the problem right
now, sorry!
Ole
-----------------------------------------------------------------
Ole J. Jacobsen, Senior Technical Advisor, Interop Company,
A division of SOFTBANK Forums, 303 Vintage Park Drive,
Foster City, California 94404-1138, USA.
Phone: +1 415-578-6988
Fax: Please don't, use e-mail instead.
E-mail: ole at csli.stanford.edu, ole at world.std.com, ole at interop.com
-----------------------------------------------------------------
Received: from ietf.org by ietf.org id aa16337; 9 May 97 18:06 EDT
Received: from cnri by ietf.org id aa16224; 9 May 97 18:04 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22807;
9 May 97 18:04 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA16448>; Fri, 9 May 1997 15:01:02 -0700
Received: from guillotin.prism.uvsq.fr ([193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id OAA12221
; Fri, 9 May 1997 14:41:59 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id OAA06940
; Fri, 9 May 1997 14:01:15 +0200 (MET DST)
Received: from cf01 (cledf.edf.fr [192.54.193.133])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA05173
; Fri, 9 May 1997 14:01:13 +0200 (METDST)
Received: from mailhub.sti.edfgdf.fr (mailhub.sti.edfgdf.fr [192.196.111.70]) by cf01 (8.6.12/8.6.12) with SMTP id OAA10102; Fri, 9 May 1997 14:01:32 +0200
Priority: normal
Message-Id:
<05FAB337311A2001*/c=fr/admd=atlas/prmd=edfgdf/o=notes/s=Pavard/g=Michel/@MHS>
Date: 09 May 1997 13:59:30 +0200
Sender:ietf-request at ietf.org
From: Michel PAVARD <Michel.Pavard at notes.edfgdf.fr>
To: Return requested <jpm at zuno.com>
Cc: Return requested <2IN97 at prism.uvsq.fr>,
Return requested <congres at prism.uvsq.fr>,
Return requested <BENKING at faw.uni-ulm.de>
Subject: RE: 21N97
Source-Info: From (or Sender) name not authenticated.
Received: from ietf.org by ietf.org id aa16583; 9 May 97 18:09 EDT
Received: from cnri by ietf.org id aa16486; 9 May 97 18:08 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22919;
9 May 97 18:08 EDT
Received: from shiva.jussieu.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA16596>; Fri, 9 May 1997 15:04:39 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id PAA15658
; Fri, 9 May 1997 15:24:05 +0200 (METDST)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id OAA09322
; Fri, 9 May 1997 14:29:31 +0200 (MET DST)
Received: from resu1.ulb.ac.be (resulb.ulb.ac.be [164.15.59.200])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA07545
; Fri, 9 May 1997 14:27:44 +0200 (METDST)
Received: from lit1.ulb.ac.be (lit1.ulb.ac.be [164.15.123.2]) by resu1.ulb.ac.be (8.6.10/3.12.0.ap (resu.test))
id OAA14092; Fri, 9 May 1997 14:25:23 +0200
Message-Id: <199705091225.OAA14092 at resu1.ulb.ac.be>
Received: by lit1.ulb.ac.be (SMI-8.6/ULB.940202)
id OAA24034; Fri, 9 May 1997 14:26:07 +0200
Date: Fri, 9 May 1997 14:26:07 +0200
Sender:ietf-request at ietf.org
From: Guy Latouche <latouche at lit.ulb.ac.be>
To: 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de
Subject: Re: 21N97
X-Sun-Charset: US-ASCII
Source-Info: From (or Sender) name not authenticated.
Whoever is responsible for these lists, fix the error
and remove me now.
I don't care to keep receiving angry messages from other
victims.
> From 2in97 at prism.uvsq.fr Fri May 9 12:42 MET 1997
> From: Benking Heiner <BENKING at faw.uni-ulm.de>
> Subject: Re: 21N97
> Encoding: 179 TEXT
>
>
>
> ----------
> > Von: 2IN97
> > An: congres
> > Betreff: 21N97
> > Datum: Mittwoch, 5. M{rz 1997 12:48
> >
> > I have just received part of a message about a call for papers but the
> > important part is missing. Would you send the message again, please?
> >
> > Regards,
> >
> > Niall O'Loughlin
> >
> >
> empty rooms in mental flats - looking for locomotion?
> in the last line you find some sources and orientation for this message
>
> maybe a starter for some exchange on the CLUB OF BUDAPEST discussion group
> list !??
>
> Heiner BENKING
>
>
> re: SHARING MENTAL HOMES - a QUEST for more MENTAL MOBILITY
>
>
> here an up-date and maybe a starter in form of a message just needed to send
> somewhere
>
> Heiner Benking
>
> _-_
>
> Dear list members,
> I try to bridge two lists, as the topics are too close
> and it gets boring always getting a grip or grasp and then letting go..
> Heiner
>
> > ----------
> > Von: owner-debono
> > An: DEBONO
> > Betreff: Creativity and Rods & Cones
> > Datum: Mittwoch, 7. Mai 1997 11:48
> >
> > In a message dated 97-05-06 11:01:15 EDT, you write:
> >
> > << ... Have you ever noticed how night vision works. Part of your mind
> picks
> > up clear images on the periphery of your line of sight, but when you shift
> > your focus to where the image was, it loses its definition. I think
> > creativity works a little like this: it occurs on the edge of our line of
> > sight. If we're not too focussed on what we're looking at, we notice the
> > creative image and try to bring it into focus, but if we persist in
> peering
> > straight ahead, we fail to notice that we even "saw" something "off to the
> > side"... I apologize if this musing is self-indulgent and thank you for
> the
> > provocation. >>
> >
> > Metaphors are the furnishings of our mental home. Thank you for making a
> > very insightful addition to my decor, although I can really only see this
> > item peripherally, I guess.
> >
> > Adam Hansen
> > The Generativity Group
>
> ----------
> > Von: list
> > An: unis
> > Cc: ThomasM451
> > Betreff: Re: simple language & Korea
> > Datum: Mittwoch, 7. Mai 1997 23:30
> >
> > In a message dated 97-05-07 16:17:07 EDT, you write:
> >
> > <<
> > In a message dated 97-05-07 02:07:35 EDT, Tom wrote:
> >
> > << I admitted up front that I knew nothing about Korea, except that they
> > are about to go to war again. What I am asking is not for "ideal"
> > situations, but fundamental situations. (this is the second time simple
> language has
> > been mistaken for idealistic language, interesting) The foundation for
> my
> > "fantasy" is simply the principle of a loving relationship - mutual
> synergy.
> >
> >
> > Hello:
> > If the language of form requires us to frame a discussion through a
> > particular lense, then we would need to agree to the form/lense up-front.
> We
> > would also be able to predict all the unconscious variables that would
> > surely 'come up' into our field of awareness, as a result of framing such
> a
> > discussion..........and without saying much more its clear to me why many
> > theorists state there is no such thing as com-unication, let alone
> 'simple
> > language'!
> >
> > My admittedlly incomplete appreciation of Stytematics has me feeling like
> we
> > are in all the forms at once. .....
>
> _____________________________________________
> BEGIN OF MESSAGE:
>
> Hi,
>
> Well I think our mental homes are 'not in order'. We try with precision,
> forcing focus on the specifics, but camouflage the whole' as Steve Kurtz
> once wrote, but not daring to look for the context, the relations and
> connections. As Kant was looking with his carcateristica universalis, i call
> it an 'organizing glass' into the inner structure (remember Alice in
> WONDERLAND) we can at least build a conceptual house of knowledge, beyond
> languages, if we restrict ourselves !! to the general overview, the birds
> eye.
> The result is that we can suddenly see and get awe as we grasp how little we
> know !! See wholeness and worldview discussion and the recent work on:
> Inviting and Sharing VIEWS, thoughts, adn Voices (available on request).
>
> I think this focussing on words, as some lists do, can work in coherent
> groups, but the moment you jump over the fence, you are lost, as the
> NOMINALISTS, go for 'exact words' their code, in a hierarchical order,
> knowledge trees. My position is absolutely to the contrary, I am a
> CONCEPTUALIST, looking for 'concepts in their context' and try to move,
> merge and transform along and across scales.
>
> We have, if we ever want to bridge 'schools' and mental territories have to
> see the deeper connections. The mind's eye pondering above shows the way!
>
> I would like to show that Einstein was pondering also about words:
>
> The word or the language, written or spoken,
> do not seem to have any impact (role)
> in the mechanism of my line of thought.
> The mental building blocks of thinking
> are certain signs/symbols and more or less clear pictures,
> which can be reproduced and combined at will (according desire/wish?)
>
> Albert Einstein
>
> maybe someone can help with the best words !?? as I only have a German
> version:
>
> Das Wort oder die Sprache, geschrieben oder gesprochen,
> scheinen im Mechanismus meines Gedankenablaufes
> }berhaupt keine Rolle zu spielen.
> Die psychischen Grundelemente des Denkens
> sind bestimmte Zeichen und mehr oder weniger klare Bilder,
> die nach Wunsch reproduziert und kombiniert werden k|nnen.
>
> Albert Einstein
>
>
> I would like to sum up by saying that I profit most by learning the style
> and the class of the different lists, my English is not good enough to
> discuss with any one of you 'seriously' (I appreciate the braod wandwith
> personal aprach anyway!)
>
> but I can tell you that we are all very close, but are typically not aware
> of it, all living in our private MENTAL HOMES, in cocoons, and ponder about
> details...
>
> As I like to share and feel that I live in some mental homes in parallel (my
> cognitive panorama) you are most welcome to visit and move in...
>
> warmely
>
> Heiner
> http://www.uia.org/uiadocs/spatialm.htm
> http://www.newciv.org/ISSS_Primer/seminrva.html
> http://heri.cicv.fr/council/speeches/benkingtxt.html
> http://aztlan.mty.itesm.mx/budapest/view/vl002p03.htm
>
>
>
>
Received: from ietf.org by ietf.org id aa20279; 9 May 97 20:00 EDT
Received: from soleil.uvsq.fr by ietf.org id aa20202; 9 May 97 19:56 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id BAA28189
for <ietf at ietf.org>; Sat, 10 May 1997 01:52:49 +0200 (METDST)
Received: from (daemon at localhost)
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) id BAA07358
; Sat, 10 May 1997 01:52:49 +0200 (MET DST)
Date: Sat, 10 May 1997 01:52:49 +0200 (MET DST)
Message-Id: <199705092352.BAA07358 at guillotin.prism.uvsq.fr>
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Majordomo at prism.uvsq.fr
Subject: Majordomo results
Reply-To: Majordomo at prism.uvsq.fr
Source-Info: From (or Sender) name not authenticated.
--
>>>> unsubscribe 2in97
**** unsubscribe: unknown list '2in97'.
**** Help for Majordomo at prism.uvsq.fr:
This is Brent Chapman's "Majordomo" mailing list manager, version 1.93.
In the description below items contained in []'s are optional. When
providing the item, do not include the []'s around it.
It understands the following commands:
subscribe <list> [<address>]
Subscribe yourself (or <address> if specified) to the named <list>.
unsubscribe <list> [<address>]
Unsubscribe yourself (or <address> if specified) from the named <list>.
get <list> <filename>
Get a file related to <list>.
index <list>
Return an index of files you can "get" for <list>.
which [<address>]
Find out which lists you (or <address> if specified) are on.
who <list>
Find out who is on the named <list>.
info <list>
Retrieve the general introductory information for the named <list>.
lists
Show the lists served by this Majordomo server.
help
Retrieve this message.
end
Stop processing commands (useful if your mailer adds a signature).
Commands should be sent in the body of an email message to
"Majordomo at prism.uvsq.fr".
Commands in the "Subject:" line NOT processed.
If you have any questions or problems, please contact
"Majordomo-Owner at prism.uvsq.fr".
Received: from ietf.org by ietf.org id aa21313; 9 May 97 20:46 EDT
Received: from barrio.redcape.com by ietf.org id aa21249; 9 May 97 20:44 EDT
Received: from barrio.redcape.com [208.206.180.103]
(HELO localhost)
by barrio.redcape.com (AltaVista Mail V1.0/1.0 BL18 listener)
id 0000_00c6_3373_c44a_14ed;
Fri, 09 May 1997 18:41:46 -0600
Message-ID: <3373C1DF.1CF9CE1C at redcape.com>
Date: Fri, 09 May 1997 18:31:27 -0600
Sender:ietf-request at ietf.org
From: "Mark A. Carlson" <mac at redcape.com>
Reply-To: mac at redcape.com
Organization: Redcape Software, Inc. -> http://www.redcape.com
X-Mailer: Mozilla 4.0b4 [en] (WinNT; I)
MIME-Version: 1.0
To: Valdis.Kletnieks at vt.edu
CC: postmaster at prism.uvsq.fr, ietf at ietf.org
Subject: Re: 21N97
X-Priority: 3 (Normal)
References: <199705091230.OAA05441 at donald.fokus.gmd.de > <199705091607.MAA22646 at black-ice.cc.vt.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Valdis.Kletnieks at vt.edu wrote:
>
>
> Argh. Yet Another Bozo added ietf at ietf.org to the 2IN97 mailing list.
I find it curious that these subscriptions are always forged on a
Europen server right before their weekend starts. That way we are
guarenteed at least two whole days of unsubscribe spams.
Pity the poor postmaster at prism.uvsq.fr that reads his mail on Monday.
Can't someone just forge an unsubscribe?
-- mark
Received: from ietf.org by ietf.org id aa01107; 9 May 97 23:29 EDT
Received: from callandor.cybercash.com by ietf.org id aa01041;
9 May 97 23:25 EDT
Received: by callandor.cybercash.com; id XAA13729; Fri, 9 May 1997 23:12:06 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma013725; Sat, 10 May 97 03:11:44 GMT
Received: from crockerdec.cybercash.com (loial.cybercash.com) by cybercash.com (4.1/SMI-4.1)
id AA03923; Fri, 9 May 97 23:17:22 EDT
Message-Id: <3.0.32.19970509232136.00b766bc at cybercash.com>
X-Sender: crocker at cybercash.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 09 May 1997 23:21:38 -0400
To: William Allen Simpson <wsimpson at greendragon.com>
Sender:ietf-request at ietf.org
From: Steve Crocker <crocker at cybercash.com>
Subject: Re: IETF mail list management suggestions
Cc: ietf at ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
Bill,
All of your suggestions are reasonable, but there's an easy way to deal
with specific problems like the one we've seen this week. The list
maintainer for the ietf list can simply set up a filter to discard incoming
mail from the errant mailing list. This problem has occured only
occasionally, so it's hard to gather the energy to build a solid, general
mechanism to prevent attacks like this forevermore. Maybe one will evolve
over time, but for the present, a little bit of mousetrapping at the ietf
site would do the trick.
Steve
----------------------------------
Steve Crocker Desk: +1 703 716 5214
CyberCash, Inc. Main: +1 703 620 4200
2100 Reston Parkway Fax: +1 703 620 4215
Reston, VA 22091 crocker at cybercash.com
Received: from ietf.org by ietf.org id aa11926; 10 May 97 9:28 EDT
Received: from merit.edu by ietf.org id aa11810; 10 May 97 9:23 EDT
Received: from Bill.Simpson.DialUp.Mich.Net (pm035-18.dialip.mich.net [141.211.7.29])
by merit.edu (8.8.5/8.8.5) with SMTP id JAA16229
for <ietf at ietf.org>; Sat, 10 May 1997 09:20:00 -0400 (EDT)
Date: Sat, 10 May 97 12:59:07 GMT
Sender:ietf-request at ietf.org
From: William Allen Simpson <wsimpson at greendragon.com>
Message-ID: <5846.wsimpson at greendragon.com>
To: Steve Crocker <crocker at cybercash.com>
Cc: ietf at ietf.org
Subject: Re: IETF mail list management suggestions
Source-Info: From (or Sender) name not authenticated.
> From: Steve Crocker <crocker at cybercash.com>
> All of your suggestions are reasonable, but there's an easy way to deal
> with specific problems like the one we've seen this week. The list
> maintainer for the ietf list can simply set up a filter to discard incoming
> mail from the errant mailing list.
Steve, I'm not sure that the other Steve (Coya) would agree with you.
He might have better things to do than constant vigilance.
Manual intervention is often too slow. As was noted earlier, this
attack was deliberately timed to be after business hours in France, so
that manual intervention would be precluded on that end.
And I don't see what the technical method would be to automatically
detect the errant mailing list. What part of the envelope would be
examined?
I prefer a technical solution over human intervention.
> This problem has occured only
> occasionally, so it's hard to gather the energy to build a solid, general
> mechanism to prevent attacks like this forevermore. Maybe one will evolve
> over time, but for the present, a little bit of mousetrapping at the ietf
> site would do the trick.
>
Actually, the mechanisms have already evolved. I believe that majordomo
and other list servers have both features:
4) members only postings
This would filter many (but not all) of the remove postings.
It would filter many (but not all) of the conference postings, too.
5) subscription handshake
This might have prevented the bogus subscription in the first place.
Together with #4, the subscription message would go to ietf.org, and
would not already be a member, and thus would bounce to the owner,
and the handshake would not occur.
This was definitely an attack. They subscribed ietf at isi.edu,
ietf at cnri.reston.va.us, ietf at ietf.org, end2end-interest, and
tcplw, as far as I know.
Do we need a special _mail_ security requirements, detailing how mailing
list software should be configured to prevent attacks?
Welcome to the global internet....
WSimpson at UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson at 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 aa13463; 10 May 97 11:13 EDT
Received: from cs.columbia.edu by ietf.org id aa13342; 10 May 97 11:06 EDT
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA15454; Sat, 10 May 1997 11:02:59 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA06887; Sat, 10 May 1997 11:02:53 -0400 (EDT)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <33748E1C.67F2 at cs.columbia.edu>
Date: Sat, 10 May 1997 11:02:52 -0400
Sender:ietf-request at ietf.org
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: William Allen Simpson <wsimpson at greendragon.com>
CC: ietf at ietf.org
Subject: Re: IETF mail list management suggestions
References: <5846.wsimpson at greendragon.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
We (James Sterbenz and I) know the culprits; this was pure stupidity on
their side, not an attack. They created a list of lists to advertise
some conferences (the mailing list names indicate as much), manually,
not realizing that anybody could send mail to that list of lists. We (on
various IEEE lists) have had to deal with them and their ilk before. The
uvsq postmaster responded last night and claims to have shut down the
lists, flushed the queues and promised to reprimand the offender/list
owner.
Note: a subscription handshake wouldn't have helped at all in this case,
as the lists were simply added to some file by hand.
--
Henning Schulzrinne email: schulzrinne at 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 aa13895; 10 May 97 11:44 EDT
Received: from ns.jck.com by ietf.org id aa13848; 10 May 97 11:43 EDT
Received: from tp7.Jck.com ("port 4412"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0E9Z25Y4R00ME6 at a4.jck.com>
for ietf at ietf.org; Sat, 10 May 1997 11:39:34 -0400 (EDT)
Date: Sat, 10 May 1997 11:39:28 -0400 (EDT)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: AOL mail traffic
In-reply-to: <199705091935.MAA01137 at leonid.genesyslab.com>
To: Leonid Yegoshin <egoshin at genesyslab.com>
Cc: ietf at ietf.org
Reply-to: John C Klensin <klensin at mci.net>
Message-id: <SIMEON.9705101128.M at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Fri, 09 May 1997 12:35:07 -0700 Leonid Yegoshin
<egoshin at genesyslab.com> wrote:
> Up to day source route in MAIL FROM: is used to delivery transport errors
> to non-Internet mail systems or to closed and _large_ networks with complex
> internal structure. If somebody try to remove this option from SMTP
> then he can setup new paradigma about mail transfering and this paradigma
> can influence DNS use in mail addressing.
Sorry. There was a long debate during the development of
RFC 1123. Some of us, who may have had few extra scars
from trying to manage gateways with complex environments
behind them, argued for exactly the interpretation you have
provided above. The most-cited example case involved
<@foo.bar.baz:xyz at site.bitnet>. We (and that position)
lost, partially because there were compelling arguments on
the other side.
The prevailing position, documented in RFC 1123 (and,
consistently in smtpupd-04) is that any host name that
appears in an address specification must be a resolvable,
FQDN. That forced the bitnet folks, and everyone with an
analogous situation, into either organizing FQDNs with MX
records (IMO, a Good Thing) or into percent-hacks (IMO, a
step in the wrong direction).
I'm not sure to this day that we made the right decision,
but I'm absolutely sure that _was_ the decision and that
the text is pretty clear (we took extra care with that
precisely because the issue was controversial).
So:
(i) Regardless of anything else, a source route (forward or
backward-pointing) that contains any host names that are
not FQDNs which are resolvable by all relay and delivery
MTAs which encounter the message, is invalid. That has
been the case at least since 1123 and, many would claim,
since RFC 974 (that is eleven years!).
(ii) So you can't expect source routes to work the way you
suggest above, and haven't been able to expect it for many
years. I, and at least some others, think that what AOL is
doing is dumb (but who will continue to defend their right
to do it) would be quite sympathetic to bouncing messages
that contain *invalid* source routes, especially if the
invalid part is the last-target address (e.g., "foo" in
<@a,@b:user at foo>).
(iii) Finally, the strongest motivations for getting rid of
source routes are ultimately connected to exactly what you
cite above as the reason for keeping them. The more
complex a network architecture gets, the more important it
becomes to put routing information into a dynamic/
resolution environment, not into messages (even temporarily
as those messages move through the network). So, there
is a right way to write "MAIL FROM:<@a,@b:user at c>", but it
isn't in the source route. It is:
MAIL FROM:<user at c>
and, in the DNS,
C. IN MX 10 C.
IN MX 20 B.
IN MX 30 A.
(where A, B, and C are FQDNs). Any additional special
routing information needed should be configured onto A and
B, but that is the same situation as in the source route.
With this approach, if you change the topology of the
internal or non-IP network, you just update the DNS as
appropriate -- you don't need to worry about an address
squirrelled by a remote system that still assumes the old
topology.
Again, RTFM --I (and others) shouldn't have to be
explaining this stuff on the IETF list.
john
Received: from ietf.org by ietf.org id aa14827; 10 May 97 12:54 EDT
Received: from shell1.aimnet.com by ietf.org id aa14761; 10 May 97 12:50 EDT
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id JAA06602; Sat, 10 May 1997 09:46:43 -0700 (PDT)
Date: Sat, 10 May 1997 09:46:42 -0700 (PDT)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
cc: William Allen Simpson <wsimpson at greendragon.com>, ietf at ietf.org
Subject: Re: IETF mail list management suggestions
In-Reply-To: <33748E1C.67F2 at cs.columbia.edu>
Message-ID: <Pine.SOL.3.95.970510094308.5732C-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sat, 10 May 1997, Henning Schulzrinne wrote:
> We (James Sterbenz and I) know the culprits; this was pure stupidity on
> their side, not an attack. They created a list of lists to advertise
> some conferences (the mailing list names indicate as much), manually,
> not realizing that anybody could send mail to that list of lists. We (on
> various IEEE lists) have had to deal with them and their ilk before. The
> uvsq postmaster responded last night and claims to have shut down the
> lists, flushed the queues and promised to reprimand the offender/list
> owner.
>
> Note: a subscription handshake wouldn't have helped at all in this case,
> as the lists were simply added to some file by hand.
I disagree... two of Bill's proposals would have cover this pretty well:
1. Subscribe to POST
2. Handsharke to SUBSCRIBE
They may have manually made the IETF at IETF.ORG the target of their list but
their list would have gotten continuous bounce messages because their
list wasn't a subscriber to the ietf list. Good chance they would have
woken up before doing the subscribe and in any case, having the
administrator of ietf at ietf.org able to unsubscribe them quickly would have
killed hundreds of posts going thru their multiplier.
Dave Morris
Received: from ietf.org by ietf.org id aa15144; 10 May 97 13:11 EDT
Received: from THOR.INNOSOFT.COM by ietf.org id aa15099; 10 May 97 13:10 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694)
id <01IIP7366IA899GSIA at INNOSOFT.COM> for ietf at ietf.org; Sat,
10 May 1997 10:05:02 PDT
Date: Sat, 10 May 1997 09:54:03 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Ned Freed <Ned.Freed at innosoft.com>
Subject: Re: AOL mail traffic
In-reply-to: "Your message dated Sat, 10 May 1997 11:39:28 -0400 (EDT)"
<SIMEON.9705101128.M at tp7.Jck.com>
To: John C Klensin <klensin at mci.net>
Cc: Leonid Yegoshin <egoshin at genesyslab.com>, ietf at ietf.org
Message-id: <01IIP8IJYEBW99GSIA at INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
References: <199705091935.MAA01137 at leonid.genesyslab.com>
Source-Info: From (or Sender) name not authenticated.
> (ii) So you can't expect source routes to work the way you
> suggest above, and haven't been able to expect it for many
> years. I, and at least some others, think that what AOL is
> doing is dumb (but who will continue to defend their right
> to do it) would be quite sympathetic to bouncing messages
> that contain *invalid* source routes, especially if the
> invalid part is the last-target address (e.g., "foo" in
> <@a,@b:user at foo>).
John, I don't think you understand exactly what AOL is doing here. They aren't
rejecting addresses that have invalid FQDNs in them; they are rejecting ANY
address that has a source route, regardless of whether or not it contains an
invalid FQDN. For example:
$ telnet/port=25 d.mx.aol.com
Trying... Connected to EMIN22.MX.AOL.COM.
220 emin22.mail.aol.com ESMTP Sendmail 8.8.5/8.8.5/AOL-1.0.1; Sat, 10 May 1997 12:53:01 -0400 (EDT)
helo sigurd.innosoft.com
250 emin22.mail.aol.com Hello SIGURD.INNOSOFT.COM [192.160.253.70], pleased to meet you
mail from:<@innosoft.com:ned at sigurd.innosoft.com>
553 <@innosoft.com:ned at sigurd.innosoft.com>... Source routed envelope sender rejected (See RFC 822, section 6.2.7)
Others have argued that this is a violation of the standards. I agree. I also
agree with you that AOL would be totally justified in rejecting addresses
that contain invalid FQDNs anywhere in them, but that's not what they are
doing at all. They are rejecting on the basis of form, not content.
I note in passing that AOL doesn't reject
ned%sigurd.innosoft.com at innosoft.com, although I would not be at all surprised
if this isn't next on the list.
Ned
Received: from ietf.org by ietf.org id aa00538; 10 May 97 23:46 EDT
Received: from hq.idt.net by ietf.org id aa00341; 10 May 97 23:41 EDT
Received: from mpark (ppp-20.ts-10.hck.idt.net [169.132.51.164]) by hq.idt.net (8.8.5/NETSYS-LEN) with SMTP id XAA29122 for <ietf at ietf.org>; Sat, 10 May 1997 23:37:27 -0400 (EDT)
Message-ID: <33753FFB.37B5 at corp.idt.net>
Date: Sat, 10 May 1997 23:41:47 -0400
Sender:ietf-request at ietf.org
From: Michael Park <mpark at corp.idt.net>
Reply-To: mpark at corp.idt.net
Organization: IDT Corporation
X-Mailer: Mozilla 3.01Gold (Win95; I)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: what is wrong with all of you?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Concerning 2IN97 at prism.uvsq.fr, congres at prism.uvsq.fr,
BENKING at faw.uni-ulm.de ...
stop sending senseless mail!
you just keep flooding and mass mailing everyone!
i, like you, did not subscribe to these lists.
it seems that the ietf mailing list address has been added to another
mailing list in europe, as result i have become a victim of this spam
stupidity.
THINK! use your brains! if you tried to remove yourself once with a
message to these damned lists (2IN97 at prism.uvsq.fr,
congres at prism.uvsq.fr, BENKING at faw.uni-ulm.de) and it didn't work, what
the hell makes you think it will work if you send your
REMOVE/UNSUBSCRIBE request an additional 5-10 times!
send mail to root or postmaster as i have, in an attempt to get removed
from this list. the next step may be to temporarily filter mail from the
offending hosts! but do not post to the lists in an attempt to remove
yourselves! it obviously hasn't worked for me and for many many many
others.. so what makes you think it'll work for you? THINK!
Received: from ietf.org by ietf.org id aa00536; 10 May 97 23:46 EDT
Received: from zephyr.isi.edu by ietf.org id aa00313; 10 May 97 23:40 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA03610>; Sat, 10 May 1997 20:36:34 -0700
Date: Sat, 10 May 1997 20:36:34 -0700
Sender:ietf-request at ietf.org
From: Jon Postel <postel at isi.edu>
Message-Id: <199705110336.AA03610 at zephyr.isi.edu>
To: wsimpson at greendragon.com
Subject: Re: IETF mail list management suggestions
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Bill:
Your points 1 & 2 are gratuitous nonsense.
There is no indication that either the forwarder at ISI.EDU or at
CNRI.RESTON.VA.US was involved in this list screw up in anyway.
--jon.
Received: from ietf.org by ietf.org id aa00659; 10 May 97 23:50 EDT
Received: from hq.idt.net by ietf.org id aa00596; 10 May 97 23:49 EDT
Received: from mpark (ppp-20.ts-10.hck.idt.net [169.132.51.164]) by hq.idt.net (8.8.5/NETSYS-LEN) with SMTP id XAA29503 for <ietf at ietf.org>; Sat, 10 May 1997 23:46:18 -0400 (EDT)
Message-ID: <3375420E.24EF at corp.idt.net>
Date: Sat, 10 May 1997 23:50:38 -0400
Sender:ietf-request at ietf.org
From: Michael Park <mpark at corp.idt.net>
Reply-To: mpark at corp.idt.net
Organization: IDT Corporation
X-Mailer: Mozilla 3.01Gold (Win95; I)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: suggestion!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
suggestion!
how about we all just relax and chill until monday?
M.
Received: from ietf.org by ietf.org id aa08231; 11 May 97 9:34 EDT
Received: from notes.ima.com by ietf.org id aa08111; 11 May 97 9:28 EDT
Received: from Lotus Notes by notes.ima.com
(IMA Internet Exchange 3.0 Enterprise Beta 2) id 00018798; Sun, 11 May 97 21:23:58 +0800
Mime-Version: 1.0
Date: Sun, 11 May 1997 21:14:31 +0800
Message-ID: <00018798.eval at ima.com>
Sender:ietf-request at ietf.org
From: Tim Kehres <kehres at ima.com>
Subject: Re: AOL mail traffic
To: Ned Freed <Ned.Freed at innosoft.com>
Cc: klensin at mci.net, egoshin at genesyslab.com, ietf at ietf.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Description: Reply
Source-Info: From (or Sender) name not authenticated.
Hello,
I suspect that there may be a lot more to the AOL decision than what has
been publically stated. Now, I certainly cannot speak in any context for
either Brad or AOL, however I do know that they have been the target
recently of *many* large spam attacks.
In one case, we had no choice in becoming involved as the spammers
had changed the headers around so as to appear to originate from IMA.COM,
our domain. Given the amount of heat we received over this does not make
me envy the position Brad must be in while trying to protect both AOL and
their user community. In the spams that pointed back to an IMA.COM
address, they were obviously fradulent attempts to part people with their
money through a New York PO Box. In talking with some of the other AOL
users about this, we were told that the hijacking of our domain name was
only a single instance of a much larger problem that they are starting to
see.
IMHO, arguing over wether or not an FQDN can be resolved is missing the
point. We've got some fairly high tech crooks out there these days, and
they're well beyond being stopped by a check this simple.
In another incident a few weeks ago, we noticed another attack, again for
some reason directed at AOL users being explicitely routed through one
of our local ISP's.
AOL perhaps has the misfortune of being one of the largest providers in
the world, in that it makes them more vunerable to these kind of malicous
attacks. I suspect that what we've observed locally is only a piece of what
AOL is trying to deal with and manage. Perhaps if there were only a way
in which we all could learn, and perhaps offer some constructive advice to
people like Brad, it might help all of us. The problem the way I see it at
this point is much bigger than a simple argument over protocol.
Best Regards,
Tim Kehres
International Messaging Associates Ltd
Ned Freed <Ned.Freed @ innosoft.com>
10/05/97 09:54
To: klensin @ mci.net
cc: egoshin @ genesyslab.com, ietf @ ietf.org (bcc: Tim Kehres/IMA)
Subject: Re: AOL mail traffic
> (ii) So you can't expect source routes to work the way you
> suggest above, and haven't been able to expect it for many
> years. I, and at least some others, think that what AOL is
> doing is dumb (but who will continue to defend their right
> to do it) would be quite sympathetic to bouncing messages
> that contain *invalid* source routes, especially if the
> invalid part is the last-target address (e.g., "foo" in
> <@a,@b:user at foo>).
John, I don't think you understand exactly what AOL is doing here. They aren't
rejecting addresses that have invalid FQDNs in them; they are rejecting ANY
address that has a source route, regardless of whether or not it contains an
invalid FQDN. For example:
$ telnet/port=25 d.mx.aol.com
Trying... Connected to EMIN22.MX.AOL.COM.
220 emin22.mail.aol.com ESMTP Sendmail 8.8.5/8.8.5/AOL-1.0.1; Sat, 10 May 1997
12:53:01 -0400 (EDT)
helo sigurd.innosoft.com
250 emin22.mail.aol.com Hello SIGURD.INNOSOFT.COM [192.160.253.70], pleased to
meet you
mail from:<@innosoft.com:ned at sigurd.innosoft.com>
553 <@innosoft.com:ned at sigurd.innosoft.com>... Source routed envelope sender
rejected (See RFC 822, section 6.2.7)
Others have argued that this is a violation of the standards. I agree. I also
agree with you that AOL would be totally justified in rejecting addresses
that contain invalid FQDNs anywhere in them, but that's not what they are
doing at all. They are rejecting on the basis of form, not content.
I note in passing that AOL doesn't reject
ned%sigurd.innosoft.com at innosoft.com, although I would not be at all surprised
if this isn't next on the list.
Ned
Received: from ietf.org by ietf.org id aa16088; 11 May 97 19:32 EDT
Received: from ns.jck.com by ietf.org id aa15971; 11 May 97 19:24 EDT
Received: from tp7.Jck.com ("port 4415"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0EA1I6W0300KQF at a4.jck.com>
for ietf at ietf.org; Sun, 11 May 1997 19:20:56 -0400 (EDT)
Date: Sun, 11 May 1997 19:20:55 -0400 (EDT)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: AOL mail traffic
In-reply-to: <01IIP8IJYEBW99GSIA at INNOSOFT.COM>
To: Ned Freed <Ned.Freed at innosoft.com>
Cc: Leonid Yegoshin <egoshin at genesyslab.com>, ietf at ietf.org
Reply-to: John C Klensin <klensin at mci.net>
Message-id: <SIMEON.9705111955.A at muahost.mci.net>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Sat, 10 May 1997 09:54:03 -0700 (PDT) Ned Freed
<Ned.Freed at innosoft.com> wrote:
> John, I don't think you understand exactly what AOL is doing here. They aren't
> rejecting addresses that have invalid FQDNs in them; they are rejecting ANY
> address that has a source route, regardless of whether or not it contains an
> invalid FQDN. For example:
>...
I do, indeed, understand what they are doing. It is a
violation of the protocols, modulo the right to refuse to
accept anything, for almost any reason, and I think I've
been trying to say that fairly consistently. And, as I've
also tried to say fairly consistently, I have trouble
imagining a purely technical reason, in a rational
environment with a simple server structure, why the
particular filter they are imposing would do much good
--especially since, as you point out, they are letting
other forms of explicit routing in addresses through.
But the portion of Leonid's note to which I was responding
suggested --at least the way I read it-- that there were
many systems involving internal IP networks or networks
connected to the Internet that were not using SMTP that
depended heavily on source routes and, if we changed the
standards (independent of anything AOL is doing) to further
deprecate source routes, we would cause irreparable damage
to that part of the infrastructure.
Now I suggest that such systems are seriously out of spec
and have been for years (I used to see a lot of them,
particularly the <@gateway:user at .bitnet> hack, but have
seen enough fewer recently to suspect that their numbers
are fewer than Leonid's note suggested).
So, once again:
* Does AOL have the "right" to reject on any basis they
feel like, no matter how dumb (or smart) you, I, or the
whole IETF think their criteria are?
--> Yes.
* If they do, what is "our" recourse?
--> Damn little. A few of their customers might
well vote with their feet, and mailing list
maintainers might decline to add AOL subscribers
if their list management software insists on
adding source routes.
* Should the software sending mail to AOL be using explicit
source routes?
--> Nope. RFC 1123 is pretty clear on that.
Smptupd-04, for whatever status it has, is even
more clear.
* Given the importance of source routes (presumably valid
ones) to the Internet infrastructure and their wide use,
should we go back and review, and possibly reverse, the
relatively consistent trend over the last ten years to
treat them as increasingly deprecated and, instead,
encourage their use?
--> Personally, I don't think so. People who disagree
should take that issue up on the DRUMS list, not
here.
* Given the number of systems and networks that are
connected to the Internet but that don't use
Internet-resolvable names or require special routing,
should we reverse the RFC 1123 decision and require only
that the next-hop (or, for reverse routes, the previous
hop) by a resolvable FQDN and make other "host names" in
source routes valid as long as their syntax conforms to the
rules?
--> Again, I don't think so. I would have favored this
at one stage, but I think it is too late. And this
issue was the only thing in Leonid's note which I
felt it useful to comment on and thought I commented
on in the note to which you responded. Again,
people who disagree should make their arguments on
the DRUMS list.
> I note in passing that AOL doesn't reject
> ned%sigurd.innosoft.com at innosoft.com, although I would not be at all surprised
> if this isn't next on the list.
Yep. And the fact that they aren't rejecting the above is
one of the reasons I believe (as do, apparently, many
others) that what they are doing is ineffectual. But "we"
can't change that: they will do whatever, in their
exclusive judgement, their business situation causes them
to conclude they need to do. My private speculations as to
why they might have concluded it is necessary aside (Brad
hasn't told me and, for antitrust reasons, I don't think I
want to know), they have clearly decided that their reasons
are more important than conformance to the standards in
terms of accepting marginal-case, but valid, syntax forms.
And, since no amount of either reasoning or flaming on the
IETF list seems likely to make a difference to that
decision, I think we should all go off and work some
problems that are amenable to solution.
john
Received: from ietf.org by ietf.org id aa18022; 11 May 97 22:19 EDT
Received: from cnri by ietf.org id aa17937; 11 May 97 22:15 EDT
Received: from SGI.COM by CNRI.Reston.VA.US id aa18496; 11 May 97 22:15 EDT
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id TAA24285
for <@sgi.engr.sgi.com:ietf at cnri.reston.va.us>; Sun, 11 May 1997 19:12:17 -0700
env-from (vjs at mica.denver.sgi.com)
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA08487 for ietf at cnri.reston.va.us; Sun, 11 May 1997 20:12:09 -0600
Date: Sun, 11 May 1997 20:12:09 -0600
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199705120212.UAA08487 at mica.denver.sgi.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: AOL mail traffic
Source-Info: From (or Sender) name not authenticated.
> From: John C Klensin <klensin at mci.net>
> .... And, as I've
> also tried to say fairly consistently, I have trouble
> imagining a purely technical reason, in a rational
> environment with a simple server structure, why the
> particular filter they are imposing would do much good
I've been trying to think of reasons why they are doing it. One idea
was that systems used to relay spam might rewrite the mail_from value
to use a source route. While that would be easy to do with even
ancient sendmail.cf, I've looked at mail_from's from 100's of examples
of relayed spam per day recently, and seen very little evidense for
that idea.
> ...
> > I note in passing that AOL doesn't reject
> > ned%sigurd.innosoft.com at innosoft.com, although I would not be at all surprised> if this isn't next on the list.
>
> Yep. And the fact that they aren't rejecting the above is
> one of the reasons I believe (as do, apparently, many
> others) that what they are doing is ineffectual.
The %-hack differs from RFC 822 source routes. Rejecting
ned%sigurd.innosoft.com at innosoft.com is exactly as (in)effectual as
rejecting ned!sigurd.innosoft.com at innosoft.com or
ned-sigurd.innosoft.com at innosoft.com. The %-hack is nothing more than
a widely used but completely private and individual convention. As far
as left-hand sides of other domains, you are supposed to ignore the
special featurs of %. If you treat "%" as nothing more than another
letter or digit throughout your system, then that is all it is to you.
That some other outfit uses % on the left of their domainname to invoke
relaying within their system is no more relevant or even knowable to
you than whether "ned" has an aliases file entry that points to
"you at some.other.com" and so invokes other kinds of relaying.
Maybe AOL uses RFC 822 source routes internally. Maybe source routes
injected from the outside would bypass other checks.
> But "we"
> can't change that: they will do whatever, in their
> exclusive judgement, their business situation causes them
> to conclude they need to do.
(hmmmph. and give up the grand usenet tradition of telling everyone
else how to run their business?--yes, I know I'm about to send this to
ietf at cnri.reston.va.us and not info.some.thing.)
> . My private speculations as to
> why they might have concluded it is necessary aside (Brad
> hasn't told me and, for antitrust reasons, I don't think I
> want to know), ...
It's too bad that defenses against spam must be based on "don't ask;
don't tell". I do not expect my speculations about AOL's reasons to be
answered.
Vernon Schryver, vjs at sgi.com
Received: from ietf.org by ietf.org id aa19670; 11 May 97 22:35 EDT
Received: from cnri by ietf.org id aa19631; 11 May 97 22:35 EDT
Received: from rip.psg.com by CNRI.Reston.VA.US id aa18826; 11 May 97 22:35 EDT
Received: by rip.psg.com
id m0wQktS-0007zaC; Sun, 11 May 97 19:31 PDT (Smail3.1.29.1#1)
Message-Id: <m0wQktS-0007zaC at rip.psg.com>
Date: Sun, 11 May 97 19:31 PDT
Sender:ietf-request at ietf.org
From: Randy Bush <randy at psg.com>
To: Vernon Schryver <vjs at mica.denver.sgi.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: AOL mail traffic
References: <199705120212.UAA08487 at mica.denver.sgi.com>
Source-Info: From (or Sender) name not authenticated.
> It's too bad that defenses against spam must be based on "don't ask;
> don't tell".
Purity through obscurity? Likely as effective in the long term as security
through obscurity.
randy
Received: from cnri by ietf.org id aa28055; 12 May 97 2:55 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa03522; 12 May 97 2:55 EDT
Received: from ietf.org by ietf.org id aa28046; 12 May 97 2:55 EDT
Received: from merit.edu by ietf.org id aa28042; 12 May 97 2:55 EDT
Received: from Bill.Simpson.DialUp.Mich.Net (pm002-27.dialip.mich.net [141.211.7.163])
by merit.edu (8.8.5/8.8.5) with SMTP id CAA26088
for <iesg at ietf.org>; Mon, 12 May 1997 02:52:09 -0400 (EDT)
Date: Mon, 12 May 97 06:26:26 GMT
Sender:iesg-request at ietf.org
From: William Allen Simpson <wsimpson at greendragon.com>
Message-ID: <5850.wsimpson at greendragon.com>
To: iesg at ietf.org
Cc: ietf at ietf.org
Subject: Re: IETF mail list management suggestions
Because of Jon's overweaning display of arrogance, this is a formal
request to the IESG to eliminate the extraneous ISI and CNRI forwarders.
> From: postel at ISI.EDU (Jon Postel)
> Your points 1 & 2 are gratuitous nonsense.
>
> There is no indication that either the forwarder at ISI.EDU or at
> CNRI.RESTON.VA.US was involved in this list screw up in anyway.
>
You should pay closer attention to detail before promulgating
disinformation. Choosing multiple copies of the same message from my
archive:
** CNRI **
Received: from ietf.org by volitans.MorningStar.Com (8.7.1/95070701)
id JAA02853; Fri, 9 May 1997 09:32:24 -0400 (EDT)
Received: from ietf.org by ietf.org id aa24289; 9 May 97 8:00 EDT
Received: from cnri by ietf.org id aa24137; 9 May 97 7:59 EDT
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa08021; 9 May 97 7:59 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA04523
; Fri, 9 May 1997 13:52:52 +0200 (METDST)
** ISI **
Received: from ietf.org by volitans.MorningStar.Com (8.7.1/95070701)
id JAA02943; Fri, 9 May 1997 09:34:54 -0400 (EDT)
Received: from ietf.org by ietf.org id aa24283; 9 May 97 8:00 EDT
Received: from cnri by ietf.org id aa24109; 9 May 97 7:59 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08022; 9 May 97 7:59 EDT
Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-27)
id <AA19886>; Fri, 9 May 1997 04:55:22 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA04523
; Fri, 9 May 1997 13:52:52 +0200 (METDST)
We received each IETF message 3 times: ietf at ietf.org, ietf at cnri and
ietf at isi.
I received 5 copies of most.
WSimpson at UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson at 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 aa04671; 12 May 97 10:22 EDT
Received: from ietf.ietf.org by ietf.org id aa04267; 12 May 97 10:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snmpv3 at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-snmpv3-v3mpc-model-00.txt
Date: Mon, 12 May 1997 10:09:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705121009.aa04267 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNMP Version 3 Working Group
of the IETF.
Title : Message Processing and Control Model for version 3 of
the Simple Network Management Protocol (snmpv3)
Author(s) : J. Case, D. Harrington
Filename : draft-ietf-snmpv3-v3mpc-model-00.txt
Pages : 21
Date : 05/09/1997
This document describes the SNMP version 3 Message Processing and Control
Model for use in the SNMPng architecture [SNMPng]. This model defines the
SNMP version 3 message format, and the procedure for coordinating the
processing of a message in SNMPv3 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-ietf-snmpv3-v3mpc-model-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-v3mpc-model-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snmpv3-v3mpc-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970509105409.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-v3mpc-model-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-v3mpc-model-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970509105409.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04670; 12 May 97 10:22 EDT
Received: from ietf.ietf.org by ietf.org id aa04289; 12 May 97 10:10 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: issll at mercury.lcs.mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-issll-is802-framework-02.txt
Date: Mon, 12 May 1997 10:10:12 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705121010.aa04289 at 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 over
Specific Link Layers Working Group of the IETF.
Title : A Framework for Providing Integrated Services Over
Shared and Switched LAN Technologies
Author(s) : A. Ghanwani, W. Pace, V. Srinivasan
Filename : draft-ietf-issll-is802-framework-02.txt
Pages : 18
Date : 05/09/1997
Traditionally, LAN technologies such as ethernet and token ring have been
required to handle best effort services only. No standard mechanism exists
for providing service guarantees on these media as will be required by
emerging and future multimedia applications. The anticipated demand for
such 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. It is therefore
necessary to enhance these technologies so that they are able to support
the Integrated Services. This memo describes a framework for providing the
functionality to support Integrated Services 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-ietf-issll-is802-framework-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-is802-framework-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-issll-is802-framework-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970509114624.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-is802-framework-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-is802-framework-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970509114624.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa08213; 12 May 97 12:21 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa12243; 12 May 97 12:21 EDT
Received: from ietf.org by ietf.org id aa08203; 12 May 97 12:21 EDT
Received: from zephyr.isi.edu by ietf.org id aa08190; 12 May 97 12:21 EDT
Received: from zen.isi.edu (zen-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA07702>; Mon, 12 May 1997 09:18:03 -0700
Date: Mon, 12 May 1997 09:18:01 -0700
Sender:iesg-request at ietf.org
From: postel at isi.edu
Posted-Date: Mon, 12 May 1997 09:18:01 -0700
Message-Id: <199705121618.AA28826 at zen.isi.edu>
Received: by zen.isi.edu (5.65c/4.0.3-6)
id <AA28826>; Mon, 12 May 1997 09:18:01 -0700
To: wsimpson at greendragon.com
Subject: Re: IETF mail list management suggestions
Cc: ietf at ietf.org, iesg at ietf.org
Bill:
Ok. If one is a lazy or incompetent list builder one gets multiple
pointers to the ietf list in one's "spam" or other mailing list due to
multiple forwarders or entry points to the list. So we can cut down on
the nuisance factor by eliminating these forwarders.
I was reacting to the implication that these forwarders made a
calculated attack on the list easier. I don't see why. If someone
wants to send a lot of junk to the list he can send a lot of junk to
the main entry point.
If anything is to seriously be done about preventing junk from being
distributed to the list it has to be done at the main entry point (on
ietf.org), and forwarders don't make that easier or harder.
We can go ahead and elininate the forwarders to reduce the nuisance
factor, and the serious steps you discussed in your other points still
needs to be addressed.
--jon.
Received: from cnri by ietf.org id aa09459; 12 May 97 13:13 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13351;
12 May 97 13:13 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA22071 at pad-thai.cam.ov.com>; Mon, 12 May 1997 15:10:49 GMT
Message-Id: <3.0.32.19970512111057.0119dc60 at linus.isoc.org>
X-Sender: burack at linus.isoc.org
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 12 May 1997 11:10:58 -0400
To: cat-ietf at mit.edu
From: Martin Burack <burack at isoc.org>
Subject: INET'97
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
Greetings. Because of your interest in security, electronic commerce, privacy, and
related areas, we thought you would want to know about the INET'97 conference,
taking place next month.
INET'97 is the crossroads at which the world's cyberspace leaders meet to exchange
experiences, share information, and shape the future of the Internet and its related
internetworking technologies. Regardless of your expertise, you'll come away with
plenty of practical ideas. It is the one Internet event you must not miss!
I look forward to seeing you there.
Marty Burack
Executive Director Internet Society burack at isoc.org
***********************************
PLENARY SPEAKERS
Dr. Glenn Ricart
Executive Vice President and Chief Technology Officer Novell, Inc.
Mr. Ira Magaziner
Senior Advisor to the President of the United States for Policy Development.
A Minister of the Malaysian government
***********************************
A SAMPLING OF INET'97 CONFERENCE SESSIONS (subject to change)
Security
Privacy on the Internet Seamless VPN
Network Access Control for DHCP Envir. E-mail Security Standards
Capability-Based Usage Control Scheme A System For Public Keys
for Network Transferring Objects Service
Internet Commerce
EDI: Concepts and Effects 3rd Gen Web Applications,
Residential Economics of Internet Access Using Internet & Intranets
What the Internet is Telling Us About Itself Small Businesses-Realities
Case Studies
A WWW Directory Service Architecture Online Stock Transactions
Norwegian Tourism Industry NII in Taiwan
Collaborative Environments
The WebDesk Framework Multi-User Domains
InterMUD Communications Multicasting
Network Technology and Engineering
Measurement and Statistics Network Technology
Routing Satellite-based Networking
ATM High Bandwidth Apps
Plus additional sessions on:
Policy and Regulation Education
User Applications Regional Development
A list of papers and panels, along with abstracts, can be viewed at:
http://www.isoc.org/inet97
*********************************************
INET97
"THE INTERNET: GLOBAL FRONTIERS"
The Seventh Annual Conference of the Internet Society
24-27 June 1997 Putra World Trade Center, Kuala Lumpur, Malaysia
Pre-Conference Events:
Technical Tutorial - June 23 and 24, 1997
K-12 Workshop - June 24, 1997
African Networking Symposium - June 24, 1997
Developing Countries Workshop - June 15-22, 1997
***********************************
The INET 97 registration fee covers attendance at all INET 97 conference sessions
June 24-June 27, 1997: Opening Reception, Gala evening, luncheons, coffee breaks,
and all conference materials, including the conference program, book of abstracts
and CD-ROM proceedings. Pre-conference events have separate registration fees.
DISCOUNTED ACCOMMODATIONS
Discounted housing accommodations are available at three lovely hotels: The
Pan Pacific Kuala Lumpur, The Legend and The Dynasty.
DISCOUNTED AIRLINE RESERVATIONS
Special INET97 airline rates are available for travel to and from Kuala Lumpur. The
negotiated arrangements will reflect savings on all flights, and a savings of 15-50%
on Malaysia Airlines, the Official Airline for INET97.
TOURS
Pre-and post-conference tours are available for INET 97 registrants. These tours emphasize
culture, people, flora and fauna, with choices for all ages and economic standing.
THE INTERNET SOCIETY (ISOC): is a nonprofit, non-governmental organization
providing leadership in the management of the many issues and concerns which the
new applications of the Internet are generating. Its diverse membership includes more
than 100 key organizations and about 7,000 individual members in 150 countries. ISOC also charters the IETF, IESG, and IAB.
For more information, or to register:
URL: http://www.isoc.org/inet97
Voice: +1 (703) 648-9888 Post: Internet Society
Fax: +1 (703) 648-9887 12020 Sunrise Valley Drive,
e-mail: <inet97 at isoc.org> Reston, Virginia U.S.A. 20191-3429
DON'T WAIT SIGN UP TODAY!
Received: from cnri by ietf.org id aa09626; 12 May 97 13:17 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa13455; 12 May 97 13:17 EDT
Received: from ietf.org by ietf.org id aa09618; 12 May 97 13:17 EDT
Received: from relay5.UU.NET by ietf.org id aa09601; 12 May 97 13:17 EDT
Received: from rodan.UU.NET by relay5.UU.NET with ESMTP
(peer crosschecked as: rodan.UU.NET [153.39.130.10])
id QQcpfw27500; Mon, 12 May 1997 13:14:03 -0400 (EDT)
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQcpfw28562; Mon, 12 May 1997 13:13:51 -0400 (EDT)
Message-Id: <QQcpfw28562.199705121713 at rodan.UU.NET>
To: postel at isi.edu
cc: wsimpson at greendragon.com, ietf at ietf.org, iesg at ietf.org
Sender:iesg-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: IETF mail list management suggestions
References: <199705121618.AA28826 at zen.isi.edu>
In-reply-to: Your message of "Mon, 12 May 1997 09:18:01 PDT."
<199705121618.AA28826 at zen.isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 May 1997 13:13:49 -0400
X-Orig-Sender: louie at uu.net
As I suggested once before, and quite seriously:
Why don't we apply for some of the "Internet Infrastructure" funds being
collected as part of the NIC contract to hire a body to moderate the IETF
mailing list. If they have spare time on their hands, they could help
moderate/admin some other IETF related lists as well.
Louis Mamakos
Received: from cnri by ietf.org id aa09878; 12 May 97 13:22 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa13544; 12 May 97 13:22 EDT
Received: from ietf.org by ietf.org id aa09845; 12 May 97 13:22 EDT
Received: from nacho.cisco.com by ietf.org id aa09826; 12 May 97 13:22 EDT
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 KAA21768; Mon, 12 May 1997 10:18:50 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id KAA10443; Mon, 12 May 1997 10:18:48 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v0300781baf9cf9cd5760 at [171.69.128.118]>
In-Reply-To: <5850.wsimpson at greendragon.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 May 1997 09:57:28 -0700
To: William Allen Simpson <wsimpson at greendragon.com>
Sender:iesg-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Re: IETF mail list management suggestions
Cc: iesg at ietf.org, ietf at ietf.org
At 6:26 AM +0000 5/12/97, William Allen Simpson wrote:
>Because of Jon's overweaning display of arrogance, this is a formal
>request to the IESG to eliminate the extraneous ISI and CNRI forwarders.
It is not within the purview of the IESG to shut down someone else's
forwarders. I guess I could shut down ietf at ietf.org if you like.
But the problem, Bill, is not at either site. The problem is the french
site just before both of them in your mailgrams:
Received: from ietf.org by volitans.MorningStar.Com (8.7.1/95070701)
id JAA02853; Fri, 9 May 1997 09:32:24 -0400 (EDT)
Received: from ietf.org by ietf.org id aa24289; 9 May 97 8:00 EDT
Received: from cnri by ietf.org id aa24137; 9 May 97 7:59 EDT
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa08021; 9 May 97
7:59 EDT
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr
[193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA04523
; Fri, 9 May 1997 13:52:52 +0200 (METDST)
** ISI **
Received: from ietf.org by volitans.MorningStar.Com (8.7.1/95070701)
id JAA02943; Fri, 9 May 1997 09:34:54 -0400 (EDT)
Received: from ietf.org by ietf.org id aa24283; 9 May 97 8:00 EDT
Received: from cnri by ietf.org id aa24109; 9 May 97 7:59 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08022; 9 May 97
7:59 EDT
Received: from soleil.uvsq.fr by venera.isi.edu (5.65c/5.61+local-27)
soleil.uvsq.fr has a list that points to ietf at venera.isi.edu and
ietf at cnri.reston.va.us. ietf at isi.edu contains a pointer to
ietf at cnri.reston.va.us, which in turn has a pointer to ietf at ietf.org.
Messages passed to either get forwarded as per the specification, and show
up in your in-box.
The thing which has to be fixed is this mailing list at soleil.uvsq.fr. I
have sent a note to postmaster at soleil.uvsq.fr asking them to do so promptly.
Until they do, may I suggest that you do what I do? I have a Eudora filter
that reads:
rule From:2IN97 at prism.uvsq.fr
id 8
incoming
manual
header =ABAny Header=BB
verb contains
value 2IN97 at prism.uvsq.fr
transfer Trash
That's just before the rule
rule From:savetrees.com
id 115
incoming
outgoing
manual
header From:
verb contains
value savetrees.com
conjunction or
header From:
verb contains
value cyberpromo.com
transfer Trash
Mailer programs have these nice features for reducing stomach acid and
introducing a small amount of sanity into the world. I use them
extensively...
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
Calvin and Hobbes (Bill Watterson)
Received: from ietf.org by ietf.org id aa11083; 12 May 97 14:01 EDT
Received: from merit.edu by ietf.org id aa10986; 12 May 97 14:00 EDT
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-21.dialip.mich.net [141.211.7.189])
by merit.edu (8.8.5/8.8.5) with SMTP id NAA08222
for <ietf at ietf.org>; Mon, 12 May 1997 13:56:14 -0400 (EDT)
Date: Mon, 12 May 97 17:39:00 GMT
Sender:ietf-request at ietf.org
From: William Allen Simpson <wsimpson at greendragon.com>
Message-ID: <5851.wsimpson at greendragon.com>
To: ietf at ietf.org
Subject: Re: IETF mail list management suggestions
Source-Info: From (or Sender) name not authenticated.
> From: Fred Baker <fred at cisco.com>
> It is not within the purview of the IESG to shut down someone else's
> forwarders. I guess I could shut down ietf at ietf.org if you like.
>
Thank you Fred, but I was operating under the assumption that as the old
ISI and CNRI list names were (in the past) "our" (that is, the IETF's)
formal and official list names, that their disposition was under "our"
purview, as opposed to the organization that was acting caretaker.
I have also suggested renaming ietf at ietf.org to ietf-discuss at ietf.org.
I would appreciate if that could be done in conjunction with a three-way
handshake registration.
I think it was "Tog on Interface" that recommends changing the name and
appearance of an object when you change its function. The ietf-announce
list was split off some time ago.
> The thing which has to be fixed is this mailing list at soleil.uvsq.fr. I
> have sent a note to postmaster at soleil.uvsq.fr asking them to do so promptly.
>
Thank you!
> Until they do, may I suggest that you do what I do? I have a Eudora filter
> that reads:
>...
> Mailer programs have these nice features for reducing stomach acid and
> introducing a small amount of sanity into the world. I use them
> extensively...
>
I appreciate that there are methods to filter out the mail after it has
arrived. I do some of them myself, although mine are written in C and
compiled into my source for the reader.... I suppose it is time for me
to "upgrade" to a commercial product, which would make such things
easier. ;-)
But, at 28.8Kbps, it takes 1/2 - 3/4 hours each day just to download my
email. It would be nice if the spam was deleted long before it got to me!
In addition, the tremendous wasted configuration effort of 1200 busy
IETF members is compounded over each such incident. Instead, the effort
could be a single configuration change by "our" central administrator.
I am not the first to ask for this. Please give my recommendations
serious consideration.
WSimpson at UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson at 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 aa11979; 12 May 97 14:26 EDT
Received: from venera.isi.edu by ietf.org id aa11891; 12 May 97 14:24 EDT
Received: from gpu.utcc.utoronto.ca by venera.isi.edu (5.65c/5.61+local-27)
id <AA15277>; Mon, 12 May 1997 11:20:50 -0700
Received: by gpu.utcc.utoronto.ca id <336724>; Mon, 12 May 1997 14:20:45 -0400
Newsgroups: info.ietf
Followup-To:
Distribution:
Organization: UTCNS Public Access
Sender:ietf-request at ietf.org
From: Alex Nishri <nishri at utcc.utoronto.ca>
To: ietf at isi.edu
Subject: Re: AOL mail traffic
Summary:
Keywords:
Message-Id: <97May12.142045edt.336724 at gpu.utcc.utoronto.ca>
Date: Mon, 12 May 1997 14:20:38 -0400
Source-Info: From (or Sender) name not authenticated.
The University of Toronto has had hundreds of messages destined to AOL
rejected. Every message starting with one delivered May 6 at 16:38 has been
affected. The error message is "Source routed envelope sender rejected
... (See RFC 822, section 6.2.7)" When I called AOL technical support
on May 9 I was told that the problem was caused by "a server being down".
I tried to argue that this explanation made no sense, but it was no use.
I called again today and when I argued forcefully I was told by AOL
technical support that nobody knows the phone number of the people who
maintain the AOL sendmail; they hope to get back to me in another day
when they reach them.
I just noticed the articles in info.ietf on this subject. Have others
gotten more progress on this issue?
Alex Nishri
Network Services
University of Toronto
email: alex.nishri at utoronto.ca
phone: 416-978-7109
Received: from ietf.org by ietf.org id aa13306; 12 May 97 14:55 EDT
Received: from ietf.ietf.org by ietf.org id aa13195; 12 May 97 14:52 EDT
To: IETF-Announce: ;
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Classical IP and ARP over ATM to Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 12 May 1997 14:52:17 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705121452.aa13195 at ietf.org>
The IESG has received a request from the Internetworking Over NBMA Working
Group to consider the following Internet-Drafts for publication as RFCs:
1. Classical IP and ARP over ATM <draft-ietf-ion-classic2-02.txt> for
the status of Proposed Standard. This document replaces RFC1577 and
R1626.
2. Inverse Address Resolution Protocol <draft-ietf-ion-inarp-update-01.txt>
for the status of Draft Standard. This replaces RFC1293.
3. Server Cache Synchronization Protocol (SCSP)
<draft-ietf-ion-scsp-01.txt> 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 at ietf.org or ietf at ietf.org mailing lists by May 26, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa13605; 12 May 97 14:59 EDT
Received: from ietf.ietf.org by ietf.org id aa13352; 12 May 97 14:56 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Message Submission and Relay to Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 12 May 1997 14:56:52 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705121456.aa13352 at ietf.org>
The IESG has received a request to consider Message Submission and
Relay <draft-gellens-submit-05.txt> as a Proposed Standard. This has
been reviewed in the IETF but is not the product of an IETF Working
Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by June 12, 1997
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa15238; 12 May 97 15:35 EDT
Received: from vnet.ibm.com by ietf.org id aa15049; 12 May 97 15:31 EDT
Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0570;
Mon, 12 May 97 15:27:29 EDT
Date: Mon, 12 May 97 15:15:11 EDT
Sender:ietf-request at ietf.org
From: "Cliff Wang ((919) 486 1255)" <cliff_wang at vnet.ibm.com>
To: ietf at ietf.org
Subject: Arp server list configuration method in Classic 2
Message-ID: <9705121531.aa15049 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
At the end of Classic2 draft section 5.2,
"By default, atm$arp-req-list MUST be configured using the MIB [18].
Manual configuration of the addresses and address lists presented in
this section is implementation dependent and beyond the scope of this
document; i.e. this memo does not require any specific configuration
method."
Can somebody specify why the arp server list must be configured using MIB?
This implies that each classic2 compliant client must have IPOA MIB
implemention with SET capability. However, due to security
concerns with SNMPv2, applications may elect not to use SNMP SET
functions.
It is my personal opinion that user may choose any method (config on the
router console, GUI config tool or use the MIB) to config the arp server list.
Classic2 draft here says "MUST be configured using the MIB". Personally, I
think this is a little too strict.
Cliff Wang
cliff_wang at vnet.ibm.com
Received: from cnri by ietf.org id aa16757; 12 May 97 16:23 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17595;
12 May 97 16:23 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA07778 at pad-thai.cam.ov.com>; Mon, 12 May 1997 18:30:27 GMT
Date: Mon, 12 May 1997 14:31:09 -0400
Message-Id: <9705121831.AA18315 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: John Linn <linn at cam.ov.com>
Cc: Marc Horowitz <marc at cygnus.com>, cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: John Linn's message of Thu, 08 May 1997 08:01:41 -0400,
<199705081201.IAA01232 at gza-client1.cam.ov.com>
Subject: Re: scope: HL vs ANSI C bindings
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Thu, 08 May 1997 08:01:41 -0400
From: John Linn <linn at cam.ov.com>
Had history evolved differently, we might have arrived at the result
Marc suggests. However, we've worked for some time with the
high-level specification and the C bindings within their established
scopes and relationships, both are now fairly mature documents, and
both would require non-trivial reworking to adapt to a new model; this
would add delay to the current process (which I believe to be near to
convergence) of advancing the C bindings and identifying specific
alignments needed in RFC2078bis.
I agree with John that we shouldn't make significant changes in the C
bindings document, vis-a-vis Marc's suggestion that we "move"
discussions about the semantics of the GSSAPI calls to the high-level
specification.
However, I do think that as we revise RFC2078bis, we should see if there
are any significant discussions about the GSSAPI semantics that should
be _copied_ to RFC2078bis. This does have the disadvantage of possibly
slowing down the work needed to revise RFC2078. However, if we assume
that we have convergence on the actual semantics which are defined in
the C bindings specification, hopefully it won't be much work to cut and
paste text from one document to another.
- Ted
Received: from ietf.org by ietf.org id aa20284; 12 May 97 18:37 EDT
Received: from SPOT.CS.UTK.EDU by ietf.org id aa20214; 12 May 97 18:33 EDT
Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
id SAA21136; Mon, 12 May 1997 18:29:23 -0400 (EDT)
Message-Id: <199705122229.SAA21136 at spot.cs.utk.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: John C Klensin <klensin at mci.net>
cc: Ned Freed <Ned.Freed at innosoft.com>,
Leonid Yegoshin <egoshin at genesyslab.com>, ietf at ietf.org, moore at cs.utk.edu
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Sun, 11 May 1997 19:20:55 EDT."
<SIMEON.9705111955.A at muahost.mci.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 May 1997 18:29:22 -0400
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
I disagree slightly with John on this issue.
> * Does AOL have the "right" to reject on any basis they
> feel like, no matter how dumb (or smart) you, I, or the
> whole IETF think their criteria are?
>
> --> Yes.
With very few exceptions, the SMTP protocol as defined in RFC 821 and
amended in RFC 1123 doesn't dictate conditions under which a message
must be accepted.
However, RFC 1123 specifically states (see below) that SMTP servers
MUST accept envelope source routes.
Does IETF have the "right" to tell AOL how to run its service?
Perhaps not, but neither do the standards support AOL's actions.
> * Should the software sending mail to AOL be using explicit
> source routes?
>
> --> Nope. RFC 1123 is pretty clear on that.
A lot hinges on the word "should"
Is it necessary or desirable for SMTP clients to use source routes? No.
Is it legal according to the standards? Yes.
RFC 1123 is clear about two things:
1. explicit source routes (in either the header or envelope) are discouraged
2. source routes in the message envelope MUST be accepted
In particular, section 5.2.6 says:
A receiver-SMTP MUST accept the explicit source route syntax in
***************************************************************
the envelope, but it MAY implement the relay function as
************
defined in section 3.6 of RFC-821. If it does not implement
the relay function, it SHOULD attempt to deliver the message
directly to the host to the right of the right-most "@" sign.
I interpret this as: "an SMTP server MUST NOT reject a message just
because the client used a source route in an envelope address."
Note the text in this paragraph, as well as the following discussion,
indicates that the author was thinking in terms of the RCPT command.
However, the phrase "the envelope" includes not just RCPT but also
MAIL (and presumably also SEND, SOML, and SAML).
(I do have a hard time reconciling "MUST accept" with "SHOULD attempt
to deliver". If an SMTP server accepts a message it has a
responsibility to attempt to deliver it.)
The RFC 1123 discussions predate my involvement in IETF work, so I
certainly don't presume to know their intent better than John.
But my point is that a reasonable person reading the standards could
easily conclude that it is perfectly legal, under some circumstances,
to send source routes in envelopes.
The DRUMS working group definitely needs to clear this up.
Keith
Received: from ietf.org by ietf.org id aa20962; 12 May 97 19:14 EDT
Received: from malibu.software.com by ietf.org id aa20901; 12 May 97 19:12 EDT
Received: from bonn.software.com ([10.3.91.11]) by malibu.software.com
(Post.Office MTA v3.1 release 0161 ID# 0-34567U50000L50000S50000)
with ESMTP id AAA482; Mon, 12 May 1997 16:13:15 -0700
X-Mailer: exmh version 1.6.6 3/24/96
To: Keith Moore <moore at cs.utk.edu>
cc: John C Klensin <klensin at mci.net>, Ned Freed <Ned.Freed at innosoft.com>,
Leonid Yegoshin <egoshin at genesyslab.com>, ietf at ietf.org
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Mon, 12 May 1997 18:29:22 EDT."
<199705122229.SAA21136 at spot.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 May 1997 16:02:59 -0700
Sender:ietf-request at ietf.org
From: Michael D'Errico <michael.derrico at software.com>
Message-ID: <19970512231315472.AAA482 at bonn.software.com>
Source-Info: From (or Sender) name not authenticated.
> With very few exceptions, the SMTP protocol as defined in RFC 821 and
> amended in RFC 1123 doesn't dictate conditions under which a message
> must be accepted.
>
> However, RFC 1123 specifically states (see below) that SMTP servers
> MUST accept envelope source routes.
I interpret that as a requirement to recognize the _syntax_ of source
routes, not that you have to deliver messages that use them. In other
words, a server MUST NOT respond with "501 Syntax error..." when con-
fronted with an address containing a source route.
Mike
Received: from ietf.org by ietf.org id aa21239; 12 May 97 19:21 EDT
Received: from SPOT.CS.UTK.EDU by ietf.org id aa21188; 12 May 97 19:21 EDT
Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
id TAA21381; Mon, 12 May 1997 19:16:35 -0400 (EDT)
Message-Id: <199705122316.TAA21381 at spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Michael D'Errico <michael.derrico at software.com>
cc: Keith Moore <moore at cs.utk.edu>, John C Klensin <klensin at mci.net>,
Ned Freed <Ned.Freed at innosoft.com>,
Leonid Yegoshin <egoshin at genesyslab.com>, ietf at ietf.org
Subject: Re: AOL mail traffic
In-reply-to: Your message of "Mon, 12 May 1997 16:02:59 PDT."
<19970512231315472.AAA482 at bonn.software.com>
Date: Mon, 12 May 1997 19:16:35 -0400
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> > With very few exceptions, the SMTP protocol as defined in RFC 821 and
> > amended in RFC 1123 doesn't dictate conditions under which a message
> > must be accepted.
> >
> > However, RFC 1123 specifically states (see below) that SMTP servers
> > MUST accept envelope source routes.
>
> I interpret that as a requirement to recognize the _syntax_ of source
> routes, not that you have to deliver messages that use them. In other
> words, a server MUST NOT respond with "501 Syntax error..." when con-
> fronted with an address containing a source route.
Seems like a stretch, especially given the need for backward
compatibility (at the time RFC 1123 was written) with RFC 821's
style of source-route processing.
Keith
Received: from ietf.org by ietf.org id aa21817; 12 May 97 19:42 EDT
Received: from zephyr.isi.edu by ietf.org id aa21709; 12 May 97 19:39 EDT
Received: from can.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA07855>; Mon, 12 May 1997 16:36:07 -0700
Date: Mon, 12 May 97 16:37:39 PDT
Sender:ietf-request at ietf.org
From: braden at isi.edu
Posted-Date: Mon, 12 May 97 16:37:39 PDT
Message-Id: <9705122337.AA09844 at can.isi.edu>
Received: by can.isi.edu (4.1/4.0.3-6)
id <AA09844>; Mon, 12 May 97 16:37:39 PDT
To: moore at cs.utk.edu, michael.derrico at software.com
Subject: Re: AOL mail traffic
Cc: klensin at mci.net, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
*> >
*> > However, RFC 1123 specifically states (see below) that SMTP servers
*> > MUST accept envelope source routes.
*>
*> I interpret that as a requirement to recognize the _syntax_ of source
*> routes, not that you have to deliver messages that use them. In other
*> words, a server MUST NOT respond with "501 Syntax error..." when con-
*> fronted with an address containing a source route.
*>
*> Mike
*>
*>
*>
Yes, but the cited paragraph of RFC 1123 (last non-DISCUSSION paragraph
of 5.2.6) has two sentences, and the second sentence pretty clearly
says that a receiver-SMTP SHOULD try to deliver the message directly
even if it does not implement source routing. [I think this is one of
those wishy-washy SHOULDs that is 95% of a MUST, but we couldn't quite
get there].
John Klensin probably wrote the paragraph, as a matter of fact.
Bob Braden
Received: from ietf.org by ietf.org id aa21818; 12 May 97 19:42 EDT
Received: from cnri by ietf.org id aa21648; 12 May 97 19:38 EDT
Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa21298;
12 May 97 19:38 EDT
Received: from Jupiter.Mcs.Net (karl at Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id SAA27778; Mon, 12 May 1997 18:35:05 -0500 (CDT)
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.5/8.8.2) id SAA00492; Mon, 12 May 1997 18:35:00 -0500 (CDT)
Message-ID: <19970512183500.57277 at Jupiter.Mcs.Net>
Date: Mon, 12 May 1997 18:35:00 -0500
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
To: Paul A Vixie <paul at vix.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: BIND 8.1-REL announcement
References: <199705062336.QAA13639 at wisdom.home.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.64
In-Reply-To: <199705062336.QAA13639 at wisdom.home.vix.com>; from Paul A Vixie on Tue, May 06, 1997 at 04:36:27PM -0700
Source-Info: From (or Sender) name not authenticated.
This code does not compile on FreeBSD.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 99 Analog numbers, 77 ISDN, http://www.mcs.net/
Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines!
Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
On Tue, May 06, 1997 at 04:36:27PM -0700, Paul A Vixie wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> This is the long-awaited successor to BIND Version 4 (i.e., 4.9.5 et al).
> Many private releases have been run by the BIND developer community, and
> several public releases have been tested by the Internet community at large.
>
> We run BIND 8.1 on the root name server we operate (F.ROOT-SERVERS.NET),
> and on all of our internal name servers (GW.HOME.VIX.COM, et al). BIND 8.1
> is known to be running successfully at UUNET PIPEX (24,000 zones) and a
> number of other large sites around the 'net.
>
> The changes from BIND 8.1-T5B to 8.1-REL are small, but no patch will be
> released since we would really like the "final cut" to be the only thing
> on any FTP caches.
>
> BIND 8 features are too numerous to mention here, but they include:
>
> -> DNS Dynamic Updates (RFC 2136).
> -> DNS Change Notification (RFC 1996).
> -> Completely new configuration syntax (and HTML docs for same).
> -> Flexible, categorized logging system (blackhole lame delegations!).
> -> IP-address-based access control for queries, zone transfers, and
> updates that may be specified on a zone-by-zone basis.
> -> More efficient zone transfers (no fork() on outbound!).
> -> Improved performance for servers with thousands of zones.
> -> get*by*() functions can now use Sun NIS if desired/available.
> -> Many bug fixes, including patches for all known security holes.
>
> See the CHANGES file in the source kit for a detailed listing of all changes.
>
> Bob and I would like to thank Viraj Bais of Intel for his reference
> implementation of Dynamic DNS, which 8.1's dynamic DNS is built upon. We'd
> also like to thank everyone who has sent us bug reports, patches, or
> operating system ports.
>
> The release files are:
>
> ftp://ftp.isc.org/isc/bind/src/8.1/bind-contrib.tar.gz ~same as 4.9.5
> ftp://ftp.isc.org/isc/bind/src/8.1/bind-contrib.tar.gz.asc PGP sig
> ftp://ftp.isc.org/isc/bind/src/8.1/bind-doc.tar.gz new HTML,MAN
> ftp://ftp.isc.org/isc/bind/src/8.1/bind-doc.tar.gz.asc PGP sig
> ftp://ftp.isc.org/isc/bind/src/8.1/bind-src.tar.gz 8.1 source
> ftp://ftp.isc.org/isc/bind/src/8.1/bind-src.tar.gz.asc PGP sig
>
> Those PGP signatures are signed with the new <pgpkey at isc.org> key, which has
> been submitted to the MIT key ring a lot of well known signatures on it.
> It can also be found at <URL:http://www.isc.org/isc/> along with a lot of
> other ISC related material that we hope you'll glance through. (If you see
> it as a crass request for funding, well, we didn't mean it to be "crass".)
>
> There is a newish mailing list: <bind-bugs at isc.org>. Submit bug reports to
> it so that both Bob Halley and Paul Vixie will see them, and they will be
> archived. This is not a mailing list in the traditional sense -- there are
> no external subscribers.
>
> Corresponding security fixes for BIND 4.9.5 will be released shortly, even
> though the release of BIND 8.1 officially puts BIND 4.9.5 in "end of life."
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
> Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
>
> iQCVAwUBM2/ACHcdkq6JcsfBAQEWFwP/WAldrVaypxOtjvkGgTyd4Kw6wbLovdBK
> kSIGgpEx9hrpBKpVSaY+PcBEAIQqrjVRGSDxmgSm/9UhDb0qd9Os8tZmM0CwZY6H
> IPWxyXoBFd0lly9ut+IPae0vkPTzmp8jwN5LoKb9YHvKHStoMq8dGkqHSo4DRT8U
> gyXFElUBJrw=
> =t/qo
> -----END PGP SIGNATURE-----
Received: from ietf.org by ietf.org id aa22489; 12 May 97 20:05 EDT
Received: from nacho.cisco.com by ietf.org id aa22405; 12 May 97 20:04 EDT
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 RAA07408; Mon, 12 May 1997 17:01:06 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id RAA10639; Mon, 12 May 1997 17:01:04 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v03007843af9d5e6b0cb1 at [171.69.128.118]>
In-Reply-To: <5851.wsimpson at greendragon.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 12 May 1997 16:59:52 -0700
To: William Allen Simpson <wsimpson at greendragon.com>
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Re: IETF mail list management suggestions
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 5:39 PM +0000 5/12/97, William Allen Simpson wrote:
>Thank you Fred, but I was operating under the assumption that as the old
>ISI and CNRI list names were (in the past) "our" (that is, the IETF's)
>formal and official list names, that their disposition was under "our"
>purview, as opposed to the organization that was acting caretaker.
I think if you check the alias files, you'll find that these are:
ietf at isi.edu:
alias ietf ietf at cnri.reston.va.us
ietf at cnri.reston.va.us:
alias ietf ietf at ietf.org
As Jon points out, there's no evidence that these lists are doing anything
other than forwarding traffic to ietf.org. That's what the mail headers you
posted said. What was messed up was the French connection, which we are
advised has long since ceased its bad behavior. If ISI's convenience
forwarder, and CNRI's legacy thingy for people who haven't glommed onto the
fact that using ietf.org is more fashionable these days, were to both go
away, it wouldn't stop people from sending to the ietf list. And if the guy
on the From line happens to be an ietf list subscriber, a source filter
doesn't top the message from bothering you.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
Calvin and Hobbes (Bill Watterson)
Received: from ietf.org by ietf.org id aa22488; 12 May 97 20:05 EDT
Received: from nacho.cisco.com by ietf.org id aa22395; 12 May 97 20:04 EDT
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 RAA07404; Mon, 12 May 1997 17:01:04 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id RAA10636; Mon, 12 May 1997 17:01:02 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v03007842af9d5df3f065 at [171.69.128.118]>
In-Reply-To: <Pine.SOL.3.95.970510094308.5732C-100000 at shell1.aimnet.com>
References: <33748E1C.67F2 at cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 12 May 1997 16:54:03 -0700
To: "David W. Morris" <dwm at xpasc.com>
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Re: IETF mail list management suggestions
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 9:46 AM -0700 5/10/97, David W. Morris wrote:
>their list would have gotten continuous bounce messages because their
>list wasn't a subscriber to the ietf list.
no, the issue is the From, not the To. They may have been subscribers to
each of the 50-odd lists they spammed.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
Calvin and Hobbes (Bill Watterson)
Received: from ietf.org by ietf.org id aa22660; 12 May 97 20:13 EDT
Received: from cnri by ietf.org id aa22621; 12 May 97 20:12 EDT
Received: from also.media.org by CNRI.Reston.VA.US id aa21837;
12 May 97 20:12 EDT
Received: (from carl at localhost)
by also.media.org (8.8.5/8.8.4/961211bjb)
id UAA08600; Mon, 12 May 1997 20:08:52 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Carl Malamud [IMS]" <carl at also.media.org>
Message-Id: <199705130008.UAA08600 at also.media.org>
Subject: Re: BIND 8.1-REL announcement
To: Karl Denninger <karl at mcs.net>
Date: Mon, 12 May 1997 20:08:52 -0400 (EDT)
Cc: paul at vix.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <19970512183500.57277 at Jupiter.Mcs.Net> from "Karl Denninger" at May 12, 97 06:35:00 pm
Organization: Internet Multicasting Service
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
We'd be pleased to have your FreeBSD port. Bind is
supported by donations from a very few corporate
contributors and by talented programmers such as
yourself who spend their time making code available
for others to use. We look forward to your
continued contributions to the Internet software
infrastructure.
Carl Malamud
Internet Software Consortium
http://www.isc.org/
According to Karl Denninger:
>
> This code does not compile on FreeBSD.
>
> --
> --
> Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
> http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
> | 99 Analog numbers, 77 ISDN, http://www.mcs.net/
> Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines!
> Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
>
> On Tue, May 06, 1997 at 04:36:27PM -0700, Paul A Vixie wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > This is the long-awaited successor to BIND Version 4 (i.e., 4.9.5 et al).
> > Many private releases have been run by the BIND developer community, and
> > several public releases have been tested by the Internet community at large.
> >
> > We run BIND 8.1 on the root name server we operate (F.ROOT-SERVERS.NET),
> > and on all of our internal name servers (GW.HOME.VIX.COM, et al). BIND 8.1
> > is known to be running successfully at UUNET PIPEX (24,000 zones) and a
> > number of other large sites around the 'net.
> >
> > The changes from BIND 8.1-T5B to 8.1-REL are small, but no patch will be
> > released since we would really like the "final cut" to be the only thing
> > on any FTP caches.
> >
> > BIND 8 features are too numerous to mention here, but they include:
> >
> > -> DNS Dynamic Updates (RFC 2136).
> > -> DNS Change Notification (RFC 1996).
> > -> Completely new configuration syntax (and HTML docs for same).
> > -> Flexible, categorized logging system (blackhole lame delegations!).
> > -> IP-address-based access control for queries, zone transfers, and
> > updates that may be specified on a zone-by-zone basis.
> > -> More efficient zone transfers (no fork() on outbound!).
> > -> Improved performance for servers with thousands of zones.
> > -> get*by*() functions can now use Sun NIS if desired/available.
> > -> Many bug fixes, including patches for all known security holes.
> >
> > See the CHANGES file in the source kit for a detailed listing of all changes.
> >
> > Bob and I would like to thank Viraj Bais of Intel for his reference
> > implementation of Dynamic DNS, which 8.1's dynamic DNS is built upon. We'd
> > also like to thank everyone who has sent us bug reports, patches, or
> > operating system ports.
> >
> > The release files are:
> >
> > ftp://ftp.isc.org/isc/bind/src/8.1/bind-contrib.tar.gz ~same as 4.9.5
> > ftp://ftp.isc.org/isc/bind/src/8.1/bind-contrib.tar.gz.asc PGP sig
> > ftp://ftp.isc.org/isc/bind/src/8.1/bind-doc.tar.gz new HTML,MAN
> > ftp://ftp.isc.org/isc/bind/src/8.1/bind-doc.tar.gz.asc PGP sig
> > ftp://ftp.isc.org/isc/bind/src/8.1/bind-src.tar.gz 8.1 source
> > ftp://ftp.isc.org/isc/bind/src/8.1/bind-src.tar.gz.asc PGP sig
> >
> > Those PGP signatures are signed with the new <pgpkey at isc.org> key, which has
> > been submitted to the MIT key ring a lot of well known signatures on it.
> > It can also be found at <URL:http://www.isc.org/isc/> along with a lot of
> > other ISC related material that we hope you'll glance through. (If you see
> > it as a crass request for funding, well, we didn't mean it to be "crass".)
> >
> > There is a newish mailing list: <bind-bugs at isc.org>. Submit bug reports to
> > it so that both Bob Halley and Paul Vixie will see them, and they will be
> > archived. This is not a mailing list in the traditional sense -- there are
> > no external subscribers.
> >
> > Corresponding security fixes for BIND 4.9.5 will be released shortly, even
> > though the release of BIND 8.1 officially puts BIND 4.9.5 in "end of life."
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: 2.6.2
> > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
> >
> > iQCVAwUBM2/ACHcdkq6JcsfBAQEWFwP/WAldrVaypxOtjvkGgTyd4Kw6wbLovdBK
> > kSIGgpEx9hrpBKpVSaY+PcBEAIQqrjVRGSDxmgSm/9UhDb0qd9Os8tZmM0CwZY6H
> > IPWxyXoBFd0lly9ut+IPae0vkPTzmp8jwN5LoKb9YHvKHStoMq8dGkqHSo4DRT8U
> > gyXFElUBJrw=
> > =t/qo
> > -----END PGP SIGNATURE-----
>
Received: from ietf.org by ietf.org id aa22796; 12 May 97 20:17 EDT
Received: from rover.cygnus.com by ietf.org id aa22750; 12 May 97 20:16 EDT
Received: (from marc at localhost) by rover.cygnus.com (8.8.5/8.6.12) id UAA01222; Mon, 12 May 1997 20:12:53 -0400 (EDT)
To: braden at isi.edu
Cc: moore at cs.utk.edu, michael.derrico at software.com, klensin at mci.net,
ietf at ietf.org
Subject: Re: AOL mail traffic
References: <9705122337.AA09844 at can.isi.edu>
Sender:ietf-request at ietf.org
From: Marc Horowitz <marc at cygnus.com>
Date: 12 May 1997 20:12:52 -0400
In-Reply-To: braden at isi.edu's message of Mon, 12 May 97 16:37:39 PDT
Message-ID: <t53u3k82prv.fsf at rover.cygnus.com>
Lines: 17
X-Mailer: Gnus v5.3/Emacs 19.34
Source-Info: From (or Sender) name not authenticated.
braden at isi.edu writes:
>> Yes, but the cited paragraph of RFC 1123 (last non-DISCUSSION paragraph
>> of 5.2.6) has two sentences, and the second sentence pretty clearly
>> says that a receiver-SMTP SHOULD try to deliver the message directly
>> even if it does not implement source routing. [I think this is one of
>> those wishy-washy SHOULDs that is 95% of a MUST, but we couldn't quite
>> get there].
>>
>> John Klensin probably wrote the paragraph, as a matter of fact.
5.2.6 also has some very strong wording *against* generating source
routes. Yet *eight years* later, people are still generating them?
It's fun to bash AOL (I do it, too), but they're not the only ones at
fault here.
Marc
Received: from ietf.org by ietf.org id aa23053; 12 May 97 20:25 EDT
Received: from shell1.aimnet.com by ietf.org id aa23007; 12 May 97 20:24 EDT
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id RAA19169; Mon, 12 May 1997 17:21:16 -0700 (PDT)
Date: Mon, 12 May 1997 17:21:16 -0700 (PDT)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: Fred Baker <fred at cisco.com>
cc: ietf at ietf.org
Subject: Re: IETF mail list management suggestions
In-Reply-To: <v03007842af9d5df3f065 at [171.69.128.118]>
Message-ID: <Pine.SOL.3.95.970512171452.1612A-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 12 May 1997, Fred Baker wrote:
> At 9:46 AM -0700 5/10/97, David W. Morris wrote:
> >their list would have gotten continuous bounce messages because their
> >list wasn't a subscriber to the ietf list.
>
> no, the issue is the From, not the To. They may have been subscribers to
> each of the 50-odd lists they spammed.
Yes, their list could have been a subscriber to the IETF list in which
case we would have gotten the junk any way. BUT if the suggested
subscribe handshake were in place, they would have had to intentionally
subscribe to the IETF list and respond to the challange. That should
have been enough to eliminate unintentional SPAM such as this event now
seems to be claimed to be.
Secondly, if the IETF list required subscribe for posting, it would have
been trivial for the IETF list admin to drop their subscription and cut
off the junk.
So I believe my assertion that they would have been getting not subscribed
bounce messages from the IETF list was correct.
Dave Morris
Received: from ietf.org by ietf.org id aa24844; 12 May 97 22:02 EDT
Received: from planet.earthcom.net by ietf.org id aa24684; 12 May 97 21:58 EDT
Received: from lipwin95.earthcom.net (hook18.uplink1.earthcom.net [206.26.134.168]) by planet.earthcom.net (8.8.4/8.6.9) with SMTP id WAA09348; Mon, 12 May 1997 22:06:03 -0400 (EDT)
Message-Id: <199705130206.WAA09348 at planet.earthcom.net>
Comments: Authenticated sender is <lipwin95 at [206.26.134.1]>
Sender:ietf-request at ietf.org
From: Gary <lipwin95 at usa.net>
To: Michael D'Errico <michael.derrico at software.com>,
Keith Moore <moore at cs.utk.edu>
Date: Mon, 12 May 1997 21:53:05 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: AOL mail traffic
Reply-to: lipwin95 at usa.net
CC: Keith Moore <moore at cs.utk.edu>, John C Klensin <klensin at mci.net>,
Ned Freed <Ned.Freed at innosoft.com>,
Leonid Yegoshin <egoshin at genesyslab.com>, ietf at ietf.org
Return-receipt-to: lipwin95 at usa.net
Priority: normal
In-reply-to: <199705122316.TAA21381 at spot.cs.utk.edu>
References: Your message of "Mon, 12 May 1997 16:02:59 PDT." <19970512231315472.AAA482 at bonn.software.com>
X-mailer: Pegasus Mail for Win32 (v2.50)
Source-Info: From (or Sender) name not authenticated.
This is my first post to this mailing list so please bear with me if
I do this wrong.
In my mind AOL just decided on its own new standard. Is AOL a
standard body? No, we are. The IETF is set up for this purpose. If
we wanted AOL to set the standards, we would all be sitting at our
computers listening to AOL busy signals. AOL has a clear
responsibility to follow those guidelines set forth by the IETF, the
accepted standards body of the Internet. If AOL does not believe that
they must go through proper channels then there should be some
recourse. I propose a penalty. We can't let a public organization
such as the IETF be pushed around by private companies. As for the
legalities of turning away the mail, I don't care. From the previous
post I would say it is pretty much agreed that AOL is one step ahead
of the IETF standards. The current standards make the actions of AOL
"illegal." Whether it was planned in future standards papers or not,
I believe AOL would do this anyway. If according to IETF standards
their actions are "illegal" then we must do something.
I am not suggesting any malictious actions, just some legal ones.
First, a petition of IETF members to Steve Case and the AOL
management. Second, a banning of all AOL employees from the IETF.
Then, if these two actions don't succeed, I suggest we appeal to
whoever controls the American NOC's to take away AOL's access. This
although drastic would get the message across quickly. If this is
impossible all service providers could consider AOL as a spamming
service. Their domains could be blocked and all mail to and from
them stopped. If this wouldn't get the message across, I don't know
what would.
Drastic? Yes!
Necessary?
I don't know!
Gary Lipner
lipwin95 at usa.net
Lipner Consulting
422 Shirley Avenue
Staten Island, N.Y. 10312
Phone (718) - 966 - 5056
Received: from cnri by ietf.org id aa03175; 12 May 97 23:13 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa00336; 12 May 97 23:13 EDT
Received: from ietf.org by ietf.org id aa03167; 12 May 97 23:13 EDT
Received: from mailhost.ipsilon.com by ietf.org id aa03153; 12 May 97 23:13 EDT
Received: from red.ipsilon.com (red.Ipsilon.COM [205.226.1.58]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id UAA25531; Mon, 12 May 1997 20:09:26 -0700
Received: from red.ipsilon.com by red.ipsilon.com (8.6.12) id UAA02698; Mon, 12 May 1997 20:09:26 -0700
Message-Id: <199705130309.UAA02698 at red.ipsilon.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Fred Baker <fred at cisco.com>
cc: William Allen Simpson <wsimpson at greendragon.com>, iesg at ietf.org,
ietf at ietf.org
Subject: Re: IETF mail list management suggestions
In-reply-to: Your message of "Mon, 12 May 1997 09:57:28 PDT."
<v0300781baf9cf9cd5760 at [171.69.128.118]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 May 1997 20:09:26 -0700
Sender:iesg-request at ietf.org
From: Greg Minshall <minshall at ipsilon.com>
Actually, isn't *one* possible protection to violate layering a bit and make
sure that "ietf at ietf.org" (or, possibly, one of the historical alternatives
like cnri and/or isi) is listed a "to:" or "cc:" line in the RFC822 headers
(doing this at the mailer at ietf.org)? It seems like almost all of this sort
of unintentional (and a lot of the intentional) junk we get would be caught by
such a filter.
Received: from ietf.org by ietf.org id aa03416; 12 May 97 23:20 EDT
Received: from cnri by ietf.org id aa03379; 12 May 97 23:20 EDT
Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa00422;
12 May 97 23:20 EDT
Received: from Jupiter.Mcs.Net (karl at Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id WAA10302; Mon, 12 May 1997 22:15:15 -0500 (CDT)
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.5/8.8.2) id WAA05771; Mon, 12 May 1997 22:15:15 -0500 (CDT)
Message-ID: <19970512221515.50847 at Jupiter.Mcs.Net>
Date: Mon, 12 May 1997 22:15:15 -0500
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
To: "Carl Malamud [IMS]" <carl at also.media.org>
Cc: Karl Denninger <karl at mcs.net>, paul at vix.com, ietf at CNRI.Reston.VA.US
Subject: Re: BIND 8.1-REL announcement
References: <19970512183500.57277 at Jupiter.Mcs.Net> <199705130008.UAA08600 at also.media.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.64
In-Reply-To: <199705130008.UAA08600 at also.media.org>; from Carl Malamud [IMS] on Mon, May 12, 1997 at 08:08:52PM -0400
Source-Info: From (or Sender) name not authenticated.
My point is that the release notes state that it builds on FreeBSD -- they
are incorrect. The problem is in the header files and structure includes,
and as such it is obvious that nobody actually tried it.
When I get it fixed (its not a priority item around here, but I did want to
experiement with it) I will submit the patches.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 99 Analog numbers, 77 ISDN, http://www.mcs.net/
Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines!
Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
On Mon, May 12, 1997 at 08:08:52PM -0400, Carl Malamud [IMS] wrote:
> We'd be pleased to have your FreeBSD port. Bind is
> supported by donations from a very few corporate
> contributors and by talented programmers such as
> yourself who spend their time making code available
> for others to use. We look forward to your
> continued contributions to the Internet software
> infrastructure.
>
> Carl Malamud
> Internet Software Consortium
> http://www.isc.org/
>
> According to Karl Denninger:
> >
> > This code does not compile on FreeBSD.
> >
> > --
> > --
> > Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
> > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
> > | 99 Analog numbers, 77 ISDN, http://www.mcs.net/
> > Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines!
> > Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
> >
> > On Tue, May 06, 1997 at 04:36:27PM -0700, Paul A Vixie wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > >
> > > This is the long-awaited successor to BIND Version 4 (i.e., 4.9.5 et al).
> > > Many private releases have been run by the BIND developer community, and
> > > several public releases have been tested by the Internet community at large.
> > >
> > > We run BIND 8.1 on the root name server we operate (F.ROOT-SERVERS.NET),
> > > and on all of our internal name servers (GW.HOME.VIX.COM, et al). BIND 8.1
> > > is known to be running successfully at UUNET PIPEX (24,000 zones) and a
> > > number of other large sites around the 'net.
> > >
> > > The changes from BIND 8.1-T5B to 8.1-REL are small, but no patch will be
> > > released since we would really like the "final cut" to be the only thing
> > > on any FTP caches.
> > >
> > > BIND 8 features are too numerous to mention here, but they include:
> > >
> > > -> DNS Dynamic Updates (RFC 2136).
> > > -> DNS Change Notification (RFC 1996).
> > > -> Completely new configuration syntax (and HTML docs for same).
> > > -> Flexible, categorized logging system (blackhole lame delegations!).
> > > -> IP-address-based access control for queries, zone transfers, and
> > > updates that may be specified on a zone-by-zone basis.
> > > -> More efficient zone transfers (no fork() on outbound!).
> > > -> Improved performance for servers with thousands of zones.
> > > -> get*by*() functions can now use Sun NIS if desired/available.
> > > -> Many bug fixes, including patches for all known security holes.
> > >
> > > See the CHANGES file in the source kit for a detailed listing of all changes.
> > >
> > > Bob and I would like to thank Viraj Bais of Intel for his reference
> > > implementation of Dynamic DNS, which 8.1's dynamic DNS is built upon. We'd
> > > also like to thank everyone who has sent us bug reports, patches, or
> > > operating system ports.
> > >
> > > The release files are:
> > >
> > > ftp://ftp.isc.org/isc/bind/src/8.1/bind-contrib.tar.gz ~same as 4.9.5
> > > ftp://ftp.isc.org/isc/bind/src/8.1/bind-contrib.tar.gz.asc PGP sig
> > > ftp://ftp.isc.org/isc/bind/src/8.1/bind-doc.tar.gz new HTML,MAN
> > > ftp://ftp.isc.org/isc/bind/src/8.1/bind-doc.tar.gz.asc PGP sig
> > > ftp://ftp.isc.org/isc/bind/src/8.1/bind-src.tar.gz 8.1 source
> > > ftp://ftp.isc.org/isc/bind/src/8.1/bind-src.tar.gz.asc PGP sig
> > >
> > > Those PGP signatures are signed with the new <pgpkey at isc.org> key, which has
> > > been submitted to the MIT key ring a lot of well known signatures on it.
> > > It can also be found at <URL:http://www.isc.org/isc/> along with a lot of
> > > other ISC related material that we hope you'll glance through. (If you see
> > > it as a crass request for funding, well, we didn't mean it to be "crass".)
> > >
> > > There is a newish mailing list: <bind-bugs at isc.org>. Submit bug reports to
> > > it so that both Bob Halley and Paul Vixie will see them, and they will be
> > > archived. This is not a mailing list in the traditional sense -- there are
> > > no external subscribers.
> > >
> > > Corresponding security fixes for BIND 4.9.5 will be released shortly, even
> > > though the release of BIND 8.1 officially puts BIND 4.9.5 in "end of life."
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: 2.6.2
> > > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
> > >
> > > iQCVAwUBM2/ACHcdkq6JcsfBAQEWFwP/WAldrVaypxOtjvkGgTyd4Kw6wbLovdBK
> > > kSIGgpEx9hrpBKpVSaY+PcBEAIQqrjVRGSDxmgSm/9UhDb0qd9Os8tZmM0CwZY6H
> > > IPWxyXoBFd0lly9ut+IPae0vkPTzmp8jwN5LoKb9YHvKHStoMq8dGkqHSo4DRT8U
> > > gyXFElUBJrw=
> > > =t/qo
> > > -----END PGP SIGNATURE-----
> >
>
Received: from ietf.org by ietf.org id aa08672; 13 May 97 2:08 EDT
Received: from mg134-105.ricochet.net by ietf.org id aa08527; 13 May 97 2:02 EDT
Received: (from egoshin at localhost) by leonid.genesyslab.com (8.7.5/8.7.3) id WAA00978; Mon, 12 May 1997 22:56:54 -0700
Date: Mon, 12 May 1997 22:56:54 -0700
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199705130556.WAA00978 at leonid.genesyslab.com>
To: ietf at ietf.org, klensin at mci.net
Subject: Re: AOL mail traffic
Source-Info: From (or Sender) name not authenticated.
Hi,
>From: John C Klensin <klensin at mci.net>
>
>But the portion of Leonid's note to which I was responding
>suggested --at least the way I read it-- that there were
>many systems involving internal IP networks or networks
>connected to the Internet that were not using SMTP that
>depended heavily on source routes and, if we changed the
>standards (independent of anything AOL is doing) to further
>deprecate source routes, we would cause irreparable damage
>to that part of the infrastructure.
>
>Now I suggest that such systems are seriously out of spec
>and have been for years (I used to see a lot of them,
>particularly the <@gateway:user at .bitnet> hack, but have
>seen enough fewer recently to suspect that their numbers
>are fewer than Leonid's note suggested).
Hm-m, I didn't expose any numbers... But I was busy in implementation
some Internet - non-Internet (DECNET-IV particular) mail gateway and
some Internet - large restricted network. From this experience I know
that there is the problem of delivering transport error messages back
to mail source. Of course, proposal of draft and RFC-1123 intention
is good decision, but ... if you have transparent DNS access via gates.
(access to MX records or something like it, of course).
Today there is strong tendency to close access to internal DNS
structure and this is in contradiction with proposal - generic "* MX"
is needed to deliver but ... it is also disapproved Internet community !
> --> Personally, I don't think so. People who disagree
> should take that issue up on the DRUMS list, not
> here.
I am sorry, you are right. But again, I insist on back compatibility,
and I think this issue is for this mail-list. (At least not exclusive
DRUMS list).
There are a lot of infrastructure which was configured once and
working. As example I can say about telephony - it use out of day technology,
expensive but it is work.
If we want setup new technology which can force a troubles in working
systems - let's try to use another TCP port.
>From: Marc Horowitz <marc at cygnus.com>
>
>5.2.6 also has some very strong wording *against* generating source
>routes. Yet *eight years* later, people are still generating them?
Yes.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa15914; 13 May 97 8:06 EDT
Received: from merit.edu by ietf.org id aa15744; 13 May 97 8:00 EDT
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-23.dialip.mich.net [141.211.7.191])
by merit.edu (8.8.5/8.8.5) with SMTP id HAA23895
for <ietf at ietf.org>; Tue, 13 May 1997 07:56:55 -0400 (EDT)
Date: Tue, 13 May 97 11:16:42 GMT
Sender:ietf-request at ietf.org
From: William Allen Simpson <wsimpson at greendragon.com>
Message-ID: <5857.wsimpson at greendragon.com>
To: ietf at ietf.org
Subject: Re: IETF mail list management suggestions
Source-Info: From (or Sender) name not authenticated.
> To: William Allen Simpson <wsimpson at greendragon.com>
> As Jon points out, there's no evidence that these lists are doing anything
> other than forwarding traffic to ietf.org. That's what the mail headers you
> posted said.
Yes, we agree. That's why I sent those headers. Jon, on the other
hand, wrote that:
There is no indication that either the forwarder at ISI.EDU or at
CNRI.RESTON.VA.US was involved in this list screw up in anyway.
They are involved. They are forwarding messages. They are not, in and
of themselves, doing anything evil. Forwarding messages is not, in and
of itself, evil.
And guns don't kill people, people kill other people.
The problem is that these "guns" are well-known. We received triplicate
evil mailings. This is not the first time that this has happened. You
would think that we might learn from experience.
My recommendation is that these "well-known" guns be retired, as they
have outlived their usefulness. They might be convenient to have under
the pillow for a few, but are a hindrance to the many, who had to clean
up the blood and debris.
These steps were to be taken in conjunction with other steps outlined in
my message. Please re-read it.
> ... And if the guy
> on the From line happens to be an ietf list subscriber, a source filter
> doesn't top the message from bothering you.
>
Certainly. We are agreed. So, what?
And automated spam mailers will probably eventually write three-way
handshake programs to subscribe themselves to the list before spamming,
and unsubscribe after spamming.
Take no actions because they might not be effective in all cases?
Is that the new credo of the IETF?
WSimpson at UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson at 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 aa16247; 13 May 97 8:22 EDT
Received: from niccolo.gsfc.nasa.gov by ietf.org id aa16209; 13 May 97 8:21 EDT
Received: from by niccolo.gsfc.nasa.gov (4.1/1.34)
id AB29431; Tue, 13 May 97 08:27:08 EDT
Received: from ccMail by cscgt.gsfc.nasa.gov
(IMA Internet Exchange 2.02 Enterprise) id 3785E690; Tue, 13 May 97 08:28:25 -0400
Mime-Version: 1.0
Date: Tue, 13 May 1997 08:13:55 -0400
Message-Id: <3785E690.1746 at cscgt.gsfc.nasa.gov>
Sender:ietf-request at ietf.org
From: Vincent Grimaldi <Vincent_Grimaldi at cscgt.gsfc.nasa.gov>
Subject: unsubsrcibe
To: ietf at ietf.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa16694; 13 May 97 8:37 EDT
Received: from ns.jck.com by ietf.org id aa16577; 13 May 97 8:35 EDT
Received: from tp7.Jck.com ("port 4295"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0EA4DHU2U0031K at a4.jck.com>
for ietf at ietf.org; Tue, 13 May 1997 08:32:19 -0400 (EDT)
Date: Tue, 13 May 1997 08:32:17 -0400 (EDT)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: AOL mail traffic
In-reply-to: <199705130556.WAA00978 at leonid.genesyslab.com>
To: Leonid Yegoshin <egoshin at genesyslab.com>
Cc: ietf at ietf.org
Reply-to: John C Klensin <klensin at mci.net>
Message-id: <SIMEON.9705130817.I at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Mon, 12 May 1997 22:56:54 -0700 Leonid Yegoshin
<egoshin at genesyslab.com> wrote:
> Hm-m, I didn't expose any numbers... But I was busy in implementation
> some Internet - non-Internet (DECNET-IV particular) mail gateway and
> some Internet - large restricted network. From this experience I know
> that there is the problem of delivering transport error messages back
> to mail source. Of course, proposal of draft and RFC-1123 intention
> is good decision, but ... if you have transparent DNS access via gates.
> (access to MX records or something like it, of course).
>...
Good analysis, wrong, IMO, conclusion. DECNET-IV, for
example, is very poor at carrying envelopes. If you depend
on the envelope to carry error return information, you
will, almost inevitably, end up either with users
generating "replies" to envelope addresses (prohibited by
RFC 822 -- although one might argue the language isn't
clear enough-- and more strongly in 822bis, aka
draft-ietf-drums-msgfmt-nn) or errors going to header
"from:" or "sender:" addresses. This has actually been a
huge source of problems in the past. The correct solution
involves two steps, both of which are very well documented
and have been around for a long time:
(1) Copy the backward-pointing address into a header
Return-path field at the point that you transition from an
Internet environment into some other one.
(2) Keep careful track of that header field and address
so that you don't accidentally fabricate extra,
conflicting, copies.
(3) As you move things through the private network, do
whatever is needed to maintain addressability within that
network and to be sure that, if you have to identify
or send something back to the public Internet, you can get
there, get the right information to the right places, and
undo any messes you have made to make things work
internally.
> Today there is strong tendency to close access to
internal DNS
> structure and this is in contradiction with proposal - generic "* MX"
> is needed to deliver but ... it is also disapproved Internet community !
Generic (I assume you mean "wildcard") MX turns out to not
be a wonderful solution as soon as there are multiple
points of attachment between your internal network and the
public Internet. But, while many of us don't like the
things for a variety of operational reasons, I don't think
there has ever been a prohibition on using them. But, more
to the point, if you really want a "hidden" internal DNS
structure, you don't want to use source routes -- they
expose the internal names and often the internal topology
and, in most cases I've heard of wanting to keep "internal"
DNS hidden, those are exactly the things one is trying to
protect.
> > --> Personally, I don't think so. People who disagree
> > should take that issue up on the DRUMS list, not
> > here.
>
> I am sorry, you are right. But again, I insist on back compatibility,
> and I think this issue is for this mail-list. (At least not exclusive
> DRUMS list).
Suit yourself. The unfortunate parts of continuing the
discussion here are that you irritate a lot of people who
aren't interested and, worse, some people who are won't see
your messages, either because they don't follow the IETF
list or because they have concluded that this message chain
has slipped too far down the S/N curve and started deleting
its transactions before reading them.
> There are a lot of infrastructure which was configured
>once and
>working. As example I can say about telephony - it use out
>of day technology,
>expensive but it is work.
Neither 1123 nor smtpupd-04 ban the use of source routes in
envelopes nor their syntax. I expect that SMTP receivers
will be required to recognize them forever and to do
something sensible with them. As I suggested earlier, you
are complaining about a problem that does not exist and is
not being seriously proposed.
> If we want setup new technology which can force a
>troubles in working
>systems - let's try to use another TCP port.
Go back and read through the original archives of the SMTP
Extensions WG, where this issue was discussed, several
times, at tedious and exhausting length. Perhaps someone
would like to review that history and the tradeoffs for
you, but it won't be me.
And none of this really has anything to do with AOL -- they
made an administrative decision to not handle certain types
of messages. They suggested, IMO in error, that they had
justification in existing standards or evolving drafts for
doing so -- a conclusion which which most of us disagree.
So they fell back on their perception of need to do
something administratively to protect their infrastructure
-- an argument which moves the problem out of the IETF
arena (if this were the worst applications protocol
violation, or even the worst mail protocol violation, being
practiced by a major company or product right now, I'd be
absolutely delighted and people who want to punish them
should think about that).
john
Received: from ietf.org by ietf.org id aa16698; 13 May 97 8:37 EDT
Received: from ns.jck.com by ietf.org id aa16578; 13 May 97 8:35 EDT
Received: from tp7.Jck.com ("port 4294"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0EA4DHU2O0031K at a4.jck.com>
for ietf at ietf.org; Tue, 13 May 1997 08:32:18 -0400 (EDT)
Date: Tue, 13 May 1997 08:32:12 -0400 (EDT)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: AOL mail traffic
In-reply-to: <9705122337.AA09844 at can.isi.edu>
To: braden at isi.edu
Cc: ietf at ietf.org, moore at cs.utk.edu, michael.derrico at software.com
Reply-to: John C Klensin <klensin at mci.net>
Message-id: <SIMEON.9705130812.H at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Mon, 12 May 1997 16:37:39 -0700 (PDT) braden at isi.edu
wrote:
> *> I interpret that as a requirement to recognize the _syntax_ of source
> *> routes, not that you have to deliver messages that use them. In other
> *> words, a server MUST NOT respond with "501 Syntax error..." when con-
> *> fronted with an address containing a source route.
>
> Yes, but the cited paragraph of RFC 1123 (last non-DISCUSSION paragraph
> of 5.2.6) has two sentences, and the second sentence pretty clearly
> says that a receiver-SMTP SHOULD try to deliver the message directly
> even if it does not implement source routing. [I think this is one of
> those wishy-washy SHOULDs that is 95% of a MUST, but we couldn't quite
> get there].
>
> John Klensin probably wrote the paragraph, as a matter of fact.
He probably did, indeed.
The problem, if I recall, was that we had a split between
people who thought that source routes were a scourge on the
landscape (a few of whom actually liked the %-hack and
wanted to standardize it and, potentially with it,
tampering with the LHS in non-delivery hosts) and people
who were either somewhat sympathetic to source routes
and/or wanted to go a bit slower about banning something
that was clearly permitted (and required) before. In
addition, there was a separate tension about how to
prohibit behavior that we didn't want but that couldn't be
identified on the wire: in this particular case, we knew we
could not prohibit SMTP receivers from deciding to decline
to accept a message for sundry administrative reasons but
there were some particular reasons for rejection -- not
liking the domain in the HELO command, presence of source
routes -- that we wanted to discourage. So the intent was,
as clearly as we could make it, to require that SMTP
receivers accept source routes and deliver the messages,
but the statement was, necessarily, close to the reading
quoted above: we could _prohibit_ returning a syntax error
(detectable on the wire) -- in essence, if someone wanted
to reject a message simply because it contained a source
route, they would have to lie about the reason.
john
Received: from ietf.org by ietf.org id aa17846; 13 May 97 9:07 EDT
Received: from egate2.citicorp.com by ietf.org id aa17752; 13 May 97 9:04 EDT
Received: by egate2.citicorp.com id AA02752
(InterLock SMTP Gateway 3.0 for ietf at ietf.org);
Tue, 13 May 1997 09:01:26 -0400
Message-Id: <199705131301.AA02752 at egate2.citicorp.com>
Received: by egate2.citicorp.com (Protected-side Proxy Mail Agent-1);
Tue, 13 May 1997 09:01:26 -0400
X-Orig-Sender: Private_User at citicorp.com
Date: Tue, 13 May 1997 09:00:38 -0400
Sender:ietf-request at ietf.org
From: Thomas Lo <thomas.lo at citicorp.com>
Organization: Citicorp
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m)
Mime-Version: 1.0
To: ietf at ietf.org
Subject: Please remove me from the mail list.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Please remove me from the mail list.
Thanks
Received: from ietf.org by ietf.org id aa18851; 13 May 97 9:46 EDT
Received: from titania.mainspring.com by ietf.org id aa18838; 13 May 97 9:46 EDT
Received: from emartin.mainspring.com ([144.203.1.10])
by titania.mainspring.com (Netscape Mail Server v2.0) with SMTP
id AAA368 for <ietf at ietf.org>; Tue, 13 May 1997 09:43:59 -0400
Message-ID: <33787495.2C75 at mainspring.com>
Date: Tue, 13 May 1997 10:03:01 -0400
Sender:ietf-request at ietf.org
From: Elise Martin <emartin at mainspring.com>
Reply-To: emartin at mainspring.com
Organization: Mainspring Communications, Inc.
X-Mailer: Mozilla 3.0 (Win95; U)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: remove
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
please remove me
Received: from cnri by ietf.org id aa19722; 13 May 97 10:03 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09515;
13 May 97 10:03 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <MAA12701 at pad-thai.cam.ov.com>; Tue, 13 May 1997 12:11:06 GMT
Message-Id: <199705131210.IAA07533 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: John Linn <linn at cam.ov.com>, Marc Horowitz <marc at cygnus.com>,
cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: scope: HL vs ANSI C bindings
In-Reply-To: Your message of "Mon, 12 May 1997 14:31:09 EDT."
<9705121831.AA18315 at dcl.MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 13 May 1997 08:10:55 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Ted writes:
> I agree with John that we shouldn't make significant changes in the C
> bindings document, vis-a-vis Marc's suggestion that we "move"
> discussions about the semantics of the GSSAPI calls to the high-level
> specification.
>
> However, I do think that as we revise RFC2078bis, we should see if there
> are any significant discussions about the GSSAPI semantics that should
> be _copied_ to RFC2078bis. This does have the disadvantage of possibly
> slowing down the work needed to revise RFC2078. However, if we assume
> that we have convergence on the actual semantics which are defined in
> the C bindings specification, hopefully it won't be much work to cut and
> paste text from one document to another.
>
> - Ted
I agree (as also stated in my 8 May message) with the goal of reflecting
within 2078bis those discussions from the C bindings which have semantic
implications and environment-independent scope. Recent list discussion
suggests to me that, in addition to the topics summarized in the 2 May
summary message, we should also take some action to align between the
RFC-2078 concept of major_status codes as a single space and the C bindings
concept of separate spaces for routine errors and supplementary info.
In particular: can we constrain the circumstances under which
supplementary info bits may be set along with a non-zero routine error,
and what, if any, constraints can be imposed on the set of supplementary
info bits returnable from a single call?
--jl
Received: from ietf.org by ietf.org id aa19916; 13 May 97 10:09 EDT
Received: from cnri by ietf.org id aa19772; 13 May 97 10:05 EDT
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa09550;
13 May 97 10:05 EDT
Received: from wisdom.home.vix.com (wisdom.home.vix.com [192.5.5.7])
by gw.home.vix.com (8.8.4/) via ESMTP id HAA28028
for <ietf at cnri.reston.va.us>; Tue, 13 May 1997 07:01:56 -0700
env-from (vixie at vix.com)
Received: by wisdom.home.vix.com; id HAA09334; Tue, 13 May 1997 07:01:56 -0700
Message-Id: <199705131401.HAA09334 at wisdom.home.vix.com>
X-Authentication-Warning: wisdom.home.vix.com: localhost [127.0.0.1] didn't use HELO protocol
To: ietf at CNRI.Reston.VA.US
Subject: Re: BIND 8.1-REL announcement
In-reply-to: Your message of "Mon, 12 May 1997 22:15:15 CDT."
<19970512221515.50847 at Jupiter.Mcs.Net>
Date: Tue, 13 May 1997 07:01:56 -0700
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Source-Info: From (or Sender) name not authenticated.
I dunno. I don't have a FreeBSD system. It was reported working on some
version of FreeBSD, which may not be the same version you're running.
Received: from ietf.org by ietf.org id aa20690; 13 May 97 10:19 EDT
Received: from ietf.ietf.org by ietf.org id aa20228; 13 May 97 10:16 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snmpv3 at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-snmpv3-lpm-01.txt
Date: Tue, 13 May 1997 10:16:54 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705131016.aa20228 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNMP Version 3 Working Group
of the IETF.
Title : Local Processing Model for version 3 of the Simple
Network Management Protocol (SNMPv3)
Author(s) : B. Wijnen, R. Presuhn, K. McCloghrie
Filename : draft-ietf-snmpv3-lpm-01.txt
Pages : 32
Date : 05/12/1997
This document describes the Local Processing Model (LPM) for SNMP version 3
for use in the SNMPng architecture [SNMPng-ARCH]. This document defines
the Elements of Procedure for accessing local management information.
This document also includes a MIB for remotely monitoring/managing
the configuration parameters for this 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-snmpv3-lpm-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-lpm-01.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snmpv3-lpm-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970512103510.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-lpm-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-lpm-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970512103510.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20687; 13 May 97 10:19 EDT
Received: from ietf.ietf.org by ietf.org id aa20284; 13 May 97 10:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: issll at mercury.lcs.mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-issll-isslow-svcmap-00.txt
Date: Tue, 13 May 1997 10:17:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705131017.aa20284 at 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 : Network Element Service Specification
for Low Speed Networks
Author(s) : S. Jackowski
Filename : draft-ietf-issll-isslow-svcmap-00.txt
Pages : 12
Date : 05/12/1997
This document defines the service mappings for controlled load and
guaranteed services over low-bitrate networks. These low bitrate networks
typically include components such as analog lines, ISDN connections and
sub-T1 rate links. The document specifies the per-network element packet
handling behavior, parameters required, traffic specification, policing
requirements, and traffic ordering relationships which are required to
provide both Guaranteed and Controlled Load service capabilities. It also
includes evaluation criteria for elements providing the service.
This document is a product of the IETF ISSL working group and is based on
[1] and [2] which describe modifications to the PPP protocol to enable
these services.
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-isslow-svcmap-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-isslow-svcmap-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-issll-isslow-svcmap-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970512103940.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-isslow-svcmap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-isslow-svcmap-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970512103940.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20689; 13 May 97 10:19 EDT
Received: from ietf.ietf.org by ietf.org id aa20247; 13 May 97 10:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-slp-02.txt
Date: Tue, 13 May 1997 10:17:00 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705131017.aa20247 at 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 : DHCP Options for Service Location Protocol
Author(s) : C. Perkins
Filename : draft-ietf-dhc-slp-02.txt
Pages : 3
Date : 05/12/1997
The Dynamic Host Configuration Protocol provides a framework for passing
configuration information to hosts on a TCP/IP network. Entities using the
Service Location Protocol need to find out the address of Directory Agents
in order to transact messages. In certain other instances they may need to
discover the correct scope to be used in conjunction with the service
attributes which are exchanged using the Service Location 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-dhc-slp-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-slp-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-slp-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970513100908.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-slp-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-slp-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970513100908.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20686; 13 May 97 10:19 EDT
Received: from ietf.ietf.org by ietf.org id aa20442; 13 May 97 10:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: namedroppers at internic.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dnsind-classless-inaddr-03.txt
Date: Tue, 13 May 1997 10:17:49 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705131017.aa20442 at 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 : Classless IN-ADDR.ARPA delegation
Author(s) : H. Eidnes, G. de Groot, P. Vixie
Filename : draft-ietf-dnsind-classless-inaddr-03.txt
Pages : 9
Date : 05/12/1997
This document describes a way to do IN-ADDR.ARPA delegation on non-octet
boundaries for address spaces covering fewer than 256 addresses. 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-dnsind-classless-inaddr-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-classless-inaddr-03.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-classless-inaddr-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970512154023.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-classless-inaddr-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-classless-inaddr-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970512154023.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20688; 13 May 97 10:19 EDT
Received: from ietf.ietf.org by ietf.org id aa20343; 13 May 97 10:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-idmr-cbt-arch-06.txt
Date: Tue, 13 May 1997 10:17:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705131017.aa20343 at 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 : Core Based Trees (CBT) Multicast Routing Architecture
Author(s) : A. Ballardie
Filename : draft-ietf-idmr-cbt-arch-06.txt
Pages : 24
Date : 05/12/1997
CBT is a multicast routing architecture that builds a single delivery tree
per group which is shared by all of the group's senders and receivers.
Most multicast algorithms build one multicast tree per sender (subnetwork),
the tree being rooted at the sender's subnetwork. The primary advantage of
the shared tree approach is that it typically offers more favourable
scaling characteristics than all other multicast algorithms. The
CBT protocol [1] is a network layer multicast routing protocol that builds
and maintains a shared delivery tree for a multicast group. The sending
and receiving of multicast data by hosts on a subnetwork conforms to the
traditional IP multicast service model [2].
CBT is progressing through the IDMR working group of the IETF.
The CBT protocol is described in an accompanying document [1].
For this, and all IDMR-related documents, see
http://www.cs.ucl.ac.uk/ietf/idmr
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-cbt-arch-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-arch-06.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-cbt-arch-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970512111333.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-cbt-arch-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-cbt-arch-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970512111333.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa22239; 13 May 97 10:44 EDT
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa10219;
13 May 97 10:44 EDT
Received: (from majordom at localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06855 for snmpv3-outgoing; Tue, 13 May 1997 10:18:49 -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snmpv3 at tis.com
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-snmpv3-usec-00.txt
Date: Tue, 13 May 1997 10:17:29 -0400
Message-ID: <9705131017.aa20317 at ietf.org>
Sender: owner-snmpv3 at 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 SNMP Version 3 Working Group
of the IETF.
Title : User-based Security Model for version 3 of the Simple
Network Management Protocol (SNMPv3)
Author(s) : U. Blumenthal, B. Wijnen
Filename : draft-ietf-snmpv3-usec-00.txt
Pages : 69
Date : 05/12/1997
This document describes the User-based Security Model (USEC) for SNMP
version 3 for use in the SNMPng architecture [SNMPng-ARCH]. This document
defines the Elements of Procedure for providing SNMP message level
security. This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this Security 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-ietf-snmpv3-usec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-usec-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snmpv3-usec-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970512110406.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-usec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-usec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970512110406.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa22570; 13 May 97 10:50 EDT
Received: from brittany.cisco.com by CNRI.Reston.VA.US id aa10333;
13 May 97 10:50 EDT
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by brittany.cisco.com (8.6.12/8.6.5) with ESMTP id HAA01239 for <extdom.snanaumib at aliashost.cisco.com>; Tue, 13 May 1997 07:42:58 -0700
Received: from ietf.org (ietf.org [132.151.1.19]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with SMTP id HAA09725 for <snanaumib at external.cisco.com>; Tue, 13 May 1997 07:42:57 -0700 (PDT)
Received: from ietf.ietf.org by ietf.org id aa20531; 13 May 97 10:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snanaumib at external.cisco.com
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-snanau-dlurmib-02.txt
Date: Tue, 13 May 1997 10:18:03 -0400
Sender: cclark at ietf.org
Message-ID: <9705131018.aa20531 at 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 DLUR
Author(s) : B. Clouston, B. Moore
Filename : draft-ietf-snanau-dlurmib-02.txt
Pages : 23
Date : 05/12/1997
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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snanau-dlurmib-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snanau-dlurmib-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970512161146.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snanau-dlurmib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snanau-dlurmib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970512161146.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24632; 13 May 97 11:32 EDT
Received: from ietf.ietf.org by ietf.org id aa20397; 13 May 97 10:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-idmr-cbt-spec-09.txt
Date: Tue, 13 May 1997 10:17:40 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705131017.aa20397 at 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 : Core Based Trees (CBT version 2) Multicast Routing --
Protocol Specification --
Author(s) : A. Ballardie
Filename : draft-ietf-idmr-cbt-spec-09.txt
Pages : 27
Date : 05/12/1997
This document describes the Core Based Tree (CBT version 2)) network layer
multicast routing protocol. CBT builds a shared multicast distribution tree
per group, and is suited to inter- and intra-domain multicast routing.
CBT may use a separate multicast routing table, or it may use that of
underlying unicast routing, to establish paths between senders and
receivers. The CBT architecture is described in [1].
This document is progressing through the IDMR working group of the IETF.
CBT related documents include [1, 5, 6]. For all IDMR-related documents,
see http://www.cs.ucl.ac.uk/ietf/idmr.
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-cbt-spec-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-spec-09.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-cbt-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970512111805.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-cbt-spec-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-cbt-spec-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970512111805.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25866; 13 May 97 12:01 EDT
Received: from cnri by ietf.org id aa25728; 13 May 97 11:59 EDT
Received: from ns.ibo.ch by CNRI.Reston.VA.US id aa11530; 13 May 97 11:59 EDT
Received: from cgchm.is.chbs by gatekeeper.chbs.ciba.com; (5.65v3.2/1.1.8.2/12Mar96-0208PM)
id AA28915; Tue, 13 May 1997 17:55:38 +0200
Received: from mta1.is.chbs by Central.CHBS.CIBA.COM
id AA13870; Tue, 13 May 1997 17:55:26 +0200 (5.65c8/Ciba2.0-C1.1)
Received: by mta1.is.chbs (5.65v3.2/DEC-Ultrix/4.3)
id AA18136; Tue, 13 May 1997 17:53:47 +0200
X400-Received: by /PRMD=CIBA/ADMD=ATTMAIL/C=CH/;
converted ((1) (0) (10021) (7) (1) (0) (1), (1) (0) (10021) (7) (1) (0) (6));
Relayed; 13 May 1997 11:36:57 +0500
X400-Received: by mta chbs-mta1 in /PRMD=ciba/ADMD=attmail/C=ch/;
converted ((1) (0) (10021) (7) (1) (0) (1), (1) (0) (10021) (7) (1) (0) (6));
Relayed; 13 May 1997 15:43:25 +0000
Date: 13 May 1997 15:43:25 +0000
X400-Originator: KEEVESU1 at PO02USTCAD.CIBAUSTCAD.usgr-msm3.usgr.mhs.ciba.com
X400-Mts-Identifier: [/PRMD=CIBA/ADMD=ATTMAIL/C=CH/;970513063657]
Sender:ietf-request at ietf.org
From: Keever Sue MSM TCAD US <KEEVESU1 at po02ustcad.cibaustcad.usgr-msm3.usgr.mhs.ciba.com>
To: Billy <ietf at CNRI.Reston.VA.US>
Subject: Are we connected????
Importance: normal
Autoforwarded: FALSE
Message-Id: <"0013E899.MAI*/PN=KEEVESU1/OU=PO02USTCAD/OU=CIBAUSTCAD/OU=usgr-msm3/OU=usgr/O=ciba/PRMD=ciba/ADMD=attmail/C=ch/"@MHS>
Original-Encoded-Information-Types: (2) (6) (3) (4) (11)
Content-Identifier: CSI NC V3.0
X400-Content-Type: P2-1988 (22)
Priority: normal
Source-Info: From (or Sender) name not authenticated.
Hey Dr. Bill ,
This is just a short note to see if we are connected. Are we? Let me know
. I'm usually in the office from 8:00 am to 7:00-8:00 pm so you can catch
me here. I'm not connected at home.
If this works say hi to Sarah and Heather!!!!!!!
Received: from ietf.org by ietf.org id aa26508; 13 May 97 12:19 EDT
Received: from THOR.INNOSOFT.COM by ietf.org id aa26466; 13 May 97 12:17 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694)
id <01IITBOMWZ8G99HEN0 at INNOSOFT.COM> for ietf at ietf.org; Tue,
13 May 1997 09:12:53 PDT
Date: Tue, 13 May 1997 09:00:52 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Ned Freed <Ned.Freed at innosoft.com>
Subject: Re: AOL mail traffic
In-reply-to: "Your message dated Tue, 13 May 1997 08:32:17 -0400 (EDT)"
<SIMEON.9705130817.I at tp7.Jck.com>
To: John C Klensin <klensin at mci.net>
Cc: Leonid Yegoshin <egoshin at genesyslab.com>, ietf at ietf.org
Message-id: <01IITDJXCSME99HEN0 at INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
References: <199705130556.WAA00978 at leonid.genesyslab.com>
Source-Info: From (or Sender) name not authenticated.
> And none of this really has anything to do with AOL -- they
> made an administrative decision to not handle certain types
> of messages. They suggested, IMO in error, that they had
> justification in existing standards or evolving drafts for
> doing so -- a conclusion which which most of us disagree.
> So they fell back on their perception of need to do
> something administratively to protect their infrastructure
> -- an argument which moves the problem out of the IETF
> arena (if this were the worst applications protocol
> violation, or even the worst mail protocol violation, being
> practiced by a major company or product right now, I'd be
> absolutely delighted and people who want to punish them
> should think about that).
A brief update on the AOL situation, if I may...
It seems AOL has changed their position on this. Specifically, their policy now
seems to be to ignore source routes entirely (perfectly legal according to the
standards and even a recommended form of behavior) and to instead insist that
the domain part of user at domain be a valid DNS domain (A, MX, or CNAME pointing
to A or MX). A 4xx error is returned if the domain isn't found.
I believe this behavior is fully legal according to current standards. And more
to the point, I think it is a very sensible setup to have, and I applaud AOL
for choosing this course of action over what they were doing before.
Finally, I think this illustrates quite nicely the importance of discussing
these sorts of issues publicly in forums such as this one. I cannot state as a
fact that this discussion was a factor in causing AOL's policy change, but it
seems fairly likely that it was.
Ned
P.S. Sample dialogue illustrating the new policy is attached below.
$ telnet/port=25 b.mx.aol.com
Trying... Connected to MRIN61.MX.AOL.COM.
220 mrin61.mail.aol.com ESMTP Sendmail 8.8.5/8.8.5/AOL-1.0.1; Tue, 13 May 1997 11:58:58 -0400 (EDT)
helo sigurd.innosoft.com
250 mrin61.mail.aol.com Hello SIGURD.INNOSOFT.COM [192.160.253.70], pleased to meet you
mail from:<@innosoft.com:ned at sigurd.innosoft.com>
250 <@innosoft.com:ned at sigurd.innosoft.com>... Sender ok
rset
250 Reset state
mail from:<@sigurd.innosoft.com:ned at innosoft.com>
250 <@sigurd.innosoft.com:ned at innosoft.com>... Sender ok
rset
250 Reset state
mail from:<@foo.bar:ned at innosoft.com>
250 <@foo.bar:ned at innosoft.com>... Sender ok
rset
250 Reset state
mail from:<@innosoft.com:ned at foo.bar>
450 <@innosoft.com:ned at foo.bar>... Sender domain not found in DNS, or not compliant with section 6.2.7 of RFC 822
Received: from ietf.org by ietf.org id aa26950; 13 May 97 12:46 EDT
Received: from soleil.uvsq.fr by ietf.org id aa26910; 13 May 97 12:45 EDT
Received: from localhost (localhost)
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with internal id DAA07917
; Tue, 13 May 1997 03:35:16 +0200 (METDST)
Date: Tue, 13 May 1997 03:35:16 +0200 (METDST)
Sender:ietf-request at ietf.org
From: Mail Delivery Subsystem <Mailer-Daemon at uvsq.fr>
Subject: Returned mail: Cannot send message within 3 days
Message-Id: <199705130135.DAA07917 at soleil.uvsq.fr>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="DAA07917.863487316/soleil.uvsq.fr"
Auto-Submitted: auto-generated (failure)
Source-Info: From (or Sender) name not authenticated.
This is a MIME-encapsulated message
--DAA07917.863487316/soleil.uvsq.fr
The original message was received at Sat, 10 May 1997 03:34:00 +0200 (METDST)
from rast.cisco.com [171.69.113.55]
----- The following addresses had permanent fatal errors -----
<@rast.cisco.com:majordomo at prism.uvsq.fr>
----- Transcript of session follows -----
451 <@rast.cisco.com:majordomo at prism.uvsq.fr>... rast.cisco.com: Name server timeout
Message could not be delivered for 3 days
Message will be deleted from queue
--DAA07917.863487316/soleil.uvsq.fr
Content-Type: message/delivery-status
Reporting-MTA: dns; soleil.uvsq.fr
Arrival-Date: Sat, 10 May 1997 03:34:00 +0200 (METDST)
Final-Recipient: rfc822; @rast.cisco.com:majordomo at prism.uvsq.fr
Action: failed
Status: 4.4.7
Last-Attempt-Date: Tue, 13 May 1997 03:35:16 +0200 (METDST)
--DAA07917.863487316/soleil.uvsq.fr
Content-Type: message/rfc822
Return-Path: <ietf at ietf.org>
Received: from rast.cisco.com (rast.cisco.com [171.69.113.55])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id DAA29948
for <@rast.cisco.com:majordomo at prism.uvsq.fr>; Sat, 10 May 1997 03:34:00 +0200 (METDST)
Date: Sat, 10 May 1997 03:34:00 +0200 (METDST)
From: ietf at ietf.org
Message-Id: <199705100134.DAA29948 at soleil.uvsq.fr>
To: @rast.cisco.com:majordomo at prism.uvsq.fr
unsubscribe 2in97
--DAA07917.863487316/soleil.uvsq.fr--
Received: from ietf.org by ietf.org id aa27284; 13 May 97 13:05 EDT
Received: from janus.border.com by ietf.org id aa27210; 13 May 97 13:04 EDT
Received: by janus.tor.securecomputing.com id <11649>; Tue, 13 May 1997 12:56:26 -0400
Message-Id: <97May13.125626edt.11649 at janus.tor.securecomputing.com>
To: Ned Freed <Ned.Freed at innosoft.com>
cc: John C Klensin <klensin at mci.net>,
Leonid Yegoshin <egoshin at genesyslab.com>, ietf at ietf.org, KnowlesB at aol.net
Subject: Re: AOL mail traffic
References: <199705130556.WAA00978 at leonid.genesyslab.com>
<01IITDJXCSME99HEN0 at INNOSOFT.COM>
In-reply-to: Ned.Freed's message of "Tue, 13 May 1997 12:00:52 -0400".
<01IITDJXCSME99HEN0 at INNOSOFT.COM>
Sender:ietf-request at ietf.org
From: "C. Harald Koch" <chk at tor.securecomputing.com>
Date: Tue, 13 May 1997 13:00:29 -0400
X-Orig-Sender: chk at tor.securecomputing.com
Source-Info: From (or Sender) name not authenticated.
In message <01IITDJXCSME99HEN0 at INNOSOFT.COM>, Ned Freed writes:
>
> I believe this behavior is fully legal according to current standards. And more
> to the point, I think it is a very sensible setup to have, and I applaud AOL
> for choosing this course of action over what they were doing before.
Agreed. Kudos to AOL (and, I assume, Brad Knowles) for this relaxation in
filtering (whatever the reason).
FWIW, we've taken steps to ensure that our product doesn't generate source
routes...
--
C. Harald Koch <chk at tor.securecomputing.com> +1.416.813.2054 (voice)
100 University Ave., 7th Floor, Toronto ON M5J 1V6 +1 416 813 2001 (fax)
"Madness takes its toll. Please have exact change."
-Karen Murphy <karenm at descartes.com>
Received: from ietf.org by ietf.org id aa27631; 13 May 97 13:19 EDT
Received: from verdi.nethelp.no by ietf.org id aa27479; 13 May 97 13:16 EDT
Received: (qmail 4983 invoked by uid 1001); 13 May 1997 17:12:00 +0000 (GMT)
To: Karl Denninger <karl at mcs.net>
Cc: ietf at ietf.org
Subject: Re: BIND 8.1-REL announcement
Sender:ietf-request at ietf.org
From: sthaug at 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, 13 May 1997 19:11:59 +0200
Message-ID: <4981.863543519 at verdi.nethelp.no>
Source-Info: From (or Sender) name not authenticated.
> My point is that the release notes state that it builds on FreeBSD -- they
> are incorrect. The problem is in the header files and structure includes,
> and as such it is obvious that nobody actually tried it.
>
> When I get it fixed (its not a priority item around here, but I did want to
> experiement with it) I will submit the patches.
Perhaps you should check your facts before you make such claims. It has
indeed been tried.
BIND 8.1-REL compiles out of the box (as in: make clean; make depend;
make) on FreeBSD-2.2 and FreeBSD-current. Unfortunately, it doesn't
compile out of the box on 2.1.7.1 (and older). See the posting below
for some more info.
Steinar Haug, Nethelp consulting, sthaug at nethelp.no
----------------------------------------------------------------------
From: sthaug at nethelp.no (Steinar Haug)
Subject: Re: FreeBSD compatibility and the INET6 issue
Date: 02 May 1997 20:59:46 GMT
Message-ID: <5kdkk2$nk5 at verdi.nethelp.no>
[Mike Tancsa]
| I am trying to compile the new 8.1 bind on a few FreeBSD boxes but keep
| getting errors similar to
|
| addr.c:144: `AF_INET6' undeclared (first use this function)
| addr.c:144: (Each undeclared identifier is reported only once
| addr.c:144: for each function it appears in.)
|
| Any ideas whats up ?
FreeBSD 2.1.7.1 (and older) doesn't have any AF_INET6 definition.
FreeBSD 2.2.1 (and newer) has it in /usr/include/sys/socket.h:
#define AF_INET6 28 /* IPv6 */
It may be sufficient to add this to a suitable include file.
(I did the original port of bind-8.1 to FreeBSD - but I never tested it
on a 2.1.x system, only on 2.2.x - for the simple reason that I didn't
have any 2.1.x system available.)
Steinar Haug, Nethelp consulting, sthaug at nethelp.no
Received: from cnri by ietf.org id aa00558; 13 May 97 16:10 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16020;
13 May 97 16:10 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <RAA16115 at pad-thai.cam.ov.com>; Tue, 13 May 1997 17:52:48 GMT
Message-Id: <199705131751.AA21518 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: RFC2078bis: draft actions and issues
To: John Linn <linn at cam.ov.com>
Date: Tue, 13 May 1997 13:51:29 -0400 (EDT)
Cc: cat-ietf at mit.edu
In-Reply-To: <199705021440.KAA21254 at gza-client1.cam.ov.com> from "John Linn" at May 2, 97 10:40:33 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Linn wrote:
>
> Here's my long-awaited working document for preparation of RFC2078bis,
>
> I: ACTIONS ASSUMED AGAINST RFC-2078:
>
> GENERAL:
> CREDENTIAL-RELATED:
> NEGOTIATION-RELATED:
Looks fine to me.
> NAME-RELATED:
>
> Remove GSS_S_BAD_NAMETYPE as return value from gss_duplicate_name(),
> gss_display_name(). For gss_compare_name(), constrain description of
> GSS_S_BAD_NAMETYPE return as being applicable only to attempted
> comparisons between incomparable name types.
>
> For gss_import_name() with GSS_C_NO_OID input_name_type, adopt
> cbind statement that a mechanism-specific default printable syntax
> for the associated name is used and state that GSS-V2 mechanism
> specifications shall define the corresponding processing to
> be performed by their mechanisms.
I had been asking for a slight change of gss_display_name():
I would like to see a permission that a gssapi mechanism implementation
may return GSS_C_NO_OID from gss_display_name() if (and only if)
the given internal name was created via import_name() and GSS_C_NO_OID
(to support layered multimechanisms).
>
> II: RESIDUAL ISSUES, DISTILLED:
>
> GENERAL ISSUES:
>
> Expand HL discussion of gss_display_status(), based on C bindings?
> The message_context() facility to iteratively return multiple status
> indicators doesn't appear in the HL spec at all. Should it? Martin
> Rex suggested (29 Jan 97) that it should, at least eventually.
> [PROPOSED ACTION: Leave RFC-2078 as is; another set of bindings for a
> different environment could plausibly return all translatable
> major_status or minor_status error information for a call within a
> single operation.]
It's funny: now that you mention it, I previously didn't realize that the
C-Bindings definition of gss_display_status() has one more output parameter
than the high level definition. Hmmm, this is slightly confusing.
My earlier comments (that I sent to you and John Wray) were mostly
targeted on the "composition" of the major_status value, rather than
the interative textual interpretation of a composite major_status
by gss_display_status(), although the latter is close to an
implication.
>
> NAME-RELATED ISSUES:
>
> Should UID name forms be indicated as optional and possibly
> environment-dependent, as they had been in RFC-1964? Should their
> descriptions be revised, and, if so, how? [PROPOSED ACTION: State as
> optional and environment-dependent. Leave descriptions as is.]
>
> Should user name form be indicated as optional and possibly
> environment-dependent, as it had been in RFC-1964? Should its
> description be revised, and, if so, how? [PROPOSED ACTION: State as
> optional and environment-dependent. Leave description as is.]
>
> Should Host-Based Service name form be stated as mandatory for the
> Internet environment? (Ted Ts'o recommends, 9 Apr 97) [PROPOSED
> ACTION: Discussion needed; absent follow-up, add no specific
> statement re mandatory vs. optional.]
All name forms should be indicated as optional in the API spec.
The individual mechanism specs are currently specifying rules and
status of nametypes.
RFC1964bis could mandate hostbased service names, GSS-API shouldn't
(btw. it would make SPKM non-compliant).
Currently, the two *_UID_* nametypes are said to refer to uid_t
(POSIX term) and therefore apply to POSIX systems only.
The "implicit" nametype GSS_C_NO_OID for gss_import_name() should
be mentioned in Section 4 of RFC2078bis.
I still am somewhat uncomfortable with description of GSS_C_NT_USER_NAME
in RFC2078, where it says "Its interpretation is OS-specific". It should
at least be changed to "may be OS-specific". In which respect is the
interpretation of gss_import_name("ftp/somehost",GSS_C_NT_USER_NAME)
guaranteed to be OS-specific (a) on Unix, (b) on MacIntosh...
I assume that most gss-krb5-mech implementations of GSS_C_NT_USER_NAME
are *NOT* OS-specific, i.e. don't do any OS-related checks of the supplied
printable name.
>
> Per late March-early April discussion, is it feasible or appropriate
> to define and adopt a generic "distributed user name" type? [PROPOSED
> ACTION: Add no new type at this time; consensus not apparent.]
When support of GSS_C_NO_OID for gss_import_name() is declared
mechanism-specific (instead of implementation-specific) and support
of GSS_C_NO_OID is strongly recommended to any mechanism that does
have a de-facto native nametype, then I don't have a need for
a generic "distributed user name".
-Martin
Received: from ietf.org by ietf.org id aa22562; 14 May 97 9:01 EDT
Received: from ietf.ietf.org by ietf.org id aa22175; 14 May 97 8:32 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: srv-location at tgv.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Service Location Protocol to Proposed Standard
Date: Wed, 14 May 1997 08:32:43 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705140832.aa22175 at ietf.org>
The IESG has approved the Internet-Draft "Service Location Protocol"
<draft-ietf-svrloc-protocol-17.txt> as a Proposed Standard. This
document is the product of the Service Location Protocol Working
Group. The IESG contact persons are Thomas Narten and Jeffrey
Burgan.
Technical Summary
The service location protocol provides a faremwork for registration,
discovery, and selection of network services in relatively
constrained topologies. It allows clients (i.e. those seeking to use
a particular service) to form queries for services that include
specific attributes of the desired service (eg, "I want a printer
with purple paper and pink printing").
Working Group Summary
This protocol is a product of the service location working group and
is a result of the merging of two different approaches that the
working group considered. There has been no dissent in the working
group. There are at least 5 efforts underway to implement the
protocol.
Protocol Quality
This protocol has been reviewed for the IESG by Thomas Narten and
Jeff Burgan, Internet Area Co-Directors.
Received: from ietf.org by ietf.org id aa23249; 14 May 97 9:26 EDT
Received: from ietf.ietf.org by ietf.org id aa23186; 14 May 97 9:23 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-mixer at innosoft.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: Mapping between X.400 and RFC-822/MIME Message
Bodies to Proposed Standard
Date: Wed, 14 May 1997 09:23:40 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705140923.aa23186 at ietf.org>
The IESG has publication of the following Internet-Drafts as
Proposed Standards:
o Mapping between X.400 and RFC-822/MIME Message Bodies
draft-ietf-mixer-bodymap-07.txt>
o X.400 image body parts
draft-ietf-mixer-images-01.txt>
o A MIME body part for FAX
draft-ietf-mixer-fax-01.txt>
o MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400
and RFC 822/MIME
<draft-kille-mixer-rfc1327bis-05.txt>
o Carrying PostScript in X.400 and MIME
<draft-ietf-mixer-postscript-01.txt>
The IESG also approved publication of A MIME body part for ODA
<draft-ietf-mixer-oda-01.txt> as an Experimental Protocol.
These documents are the product of the MIME - X.400 Gateway Working
Group. The IESG contact persons are Keith Moore and Harald Alvestrand.
Technical Summary
MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and
RFC 822/MIME <draft-kille-mixer-rfc1327bis-04.txt> is an update to RFC
1327 which specifies mappings between RFC822/SMTP and X.400 mail.
This update corrects several errors in RFC 1327, includes support for
MIME as well as Internet standards-track delivery status notifications
and SMTP extensions to request delivery reports, and defines a
standard notation for representation of address mapping and routing
information between X.400 and Internet mail.
Mapping between X.400 and RFC-822/MIME Message Bodies
<draft-ietf-mixer-bodymap-06.txt> describes mappings between MIME body
parts and their X.400 equivalents (when available), and vice versa.
X.400 image body parts <draft-ietf-mixer-images-01.txt> defines object
identifiers which allow the representation of popular MIME image/*
content-types as X.400(88) and later EXTERNALLY-DEFINED body parts.
These allow conveyance of MIME image formats in X.400.
A MIME body part for FAX <draft-ietf-mixer-fax-01.txt> specifies a
MIME canonical form for representation of the X.400 'g3fax'
content-type in MIME, and how to convert between the two
representations. This allows transmission of X.400 g3fax body parts
in MIME.
Carrying PostScript in X.400 and MIME <draft-ietf-mixer-postscript-01.txt>
defines two representations for PostScript documents in X.400(88).
These allow gatewaying of Postscript documents between MIME and X.400
systems.
Working Group Summary
There has been a lengthy discussion in the working group,
but little dissent on substantive issues.
Protocol Quality
Keith Moore reviewed the spec for IESG.
Received: from ietf.org by ietf.org id aa23467; 14 May 97 9:32 EDT
Received: from ietf.ietf.org by ietf.org id aa23420; 14 May 97 9:31 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: Deployment of the Internet White Pages
Service to BCP
Date: Wed, 14 May 1997 09:31:43 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705140931.aa23420 at ietf.org>
The IESG has approved the Internet-Draft "Best Current Practice for the
Internet White Pages Service" <draft-ietf-ids-ds-bcp-04.txt> for
publication as a Best Current Practices RFC, but with the following title:
Deployment of the Internet White Pages Service
This document is the product of the Integrated Directory Services
Working Group. The IESG contact person is Keith Moore.
Technical Summary
The document makes recommendations for provision of Internet White
Pages directory service: that organizations publish their
public directory information on the Internet (within the limits
of their countries' data privacy laws); that they use X.500 data
structures and naming for white pages information; that they
allow directory queries using the LDAP protocol; and that they
do not charge for such queries.
These recommendations are based on the widely acknowledged need
for white pages directory services, the availability of X.500/LDAP
technologies as compared to other technologies, the experience with
existing X.500 deployment. They are subject to change in the
future as more experience is gained with X.500 and LDAP, or when
better directory service technologies become available.
Working Group Summary
There was some discussion within the working group, especially
over concern about some limitations of X.500 naming and data
structures, and that recommendation of X.500 might deter
deployment of better directory technologies in the future.
However, there is little disagreement that X.500 and LDAP are
the best directory service protocols which are currently available
for widespread deployment.
The draft has benefited from several rounds of review within the
working group, and the group has reached consensus on the document's
wording.
Protocol Quality
Keith Moore reviewed the specification for IESG.
Received: from ietf.org by ietf.org id aa23579; 14 May 97 9:34 EDT
Received: from ietf.ietf.org by ietf.org id aa23539; 14 May 97 9:33 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: TCP and UDP over IPv6 Jumbograms to Proposed
Standard
Date: Wed, 14 May 1997 09:33:33 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705140933.aa23539 at ietf.org>
The IESG has approved the Internet-Draft "TCP and UDP over IPv6
Jumbograms" <draft-borman-jumbograms-01.txt> as a Proposed Standard.
This document is not the product of an IETF Working Group. The IESG
contact person is Jeff Burgan .
Technical Summary
IPv6 supports datagrams larger than 65535 bytes long (often referred
to as "jumbograms") through use of the IPv6 Jumbo Payload hop-by-hop
option. The UDP protocol has a 16-bit length field that keeps it from
being able to make use of jumbograms, and though TCP does not have a
length field, both the MSS option and the Urgent field are constrained
by 16-bits. This document describes some simple changes that can be
made to allow TCP and UDP to make use of IPv6 jumbograms.
Working Group Summary
The Working Group last call produced no issues with this document.
Protocol Quality
This document has been reviewed by Jeffrey Burgan and Thomas Narten
Received: from ietf.org by ietf.org id aa23914; 14 May 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa23807; 14 May 97 9:40 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
cc: ietf-muse at imc.org, ietf-smtp at imc.org, spam-list at psc.edu
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-eastlake-muse-02.txt
Date: Wed, 14 May 1997 09:40:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705140940.aa23807 at 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-02.txt
Pages : 22
Date : 05/12/1997
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. In
addition, authentication can make mail filtering more effective and
ubiquitous encryption indirectly makes all mail more secure be defeating
traffic analysis based on distinctions between encrypted and non-encrypted
mail and defeating bulk searching through insecure mail.
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
some authentication and confidentiality without user agent
change, and secure DNS for key distribution. These changes
also support limited host and domain level mail security policies.
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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-eastlake-muse-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-eastlake-muse-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970512161801.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-eastlake-muse-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-eastlake-muse-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970512161801.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23924; 14 May 97 9:41 EDT
Received: from ietf.ietf.org by ietf.org id aa23824; 14 May 97 9:40 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: namedroppers at internic.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dnsind-clarify-08.txt
Date: Wed, 14 May 1997 09:40:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705140940.aa23824 at 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-08.txt
Pages : 15
Date : 05/13/1997
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. Eight 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,
+ correct handling of zone cuts,
+ three minor issues concerning SOA records and their use,
+ the precise definition of the Time to Live (TTL)
+ Use of the TC (truncated) header bit
+ the issue of what is an authoritative, or canonical, name,
+ and the issue of what makes a valid DNS label.
The first six 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 specifications.
This versions adds one new minor clarification, to the definition and use
of the SOA.mname field, and some editorial cleanups. This paragraph will
be deleted from the final version of this document.
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-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-clarify-08.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-clarify-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970513085427.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-clarify-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-clarify-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970513085427.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24919; 14 May 97 9:59 EDT
Received: from ietf.ietf.org by ietf.org id aa24844; 14 May 97 9:57 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: Use and interpretation of HTTP version numbers to
Informational
Date: Wed, 14 May 1997 09:57:58 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705140957.aa24844 at ietf.org>
The IESG has reviewed the Internet-Draft "Use and interpretation of HTTP
version numbers" <draft-ietf-http-versions-01.txt> and recommends that it
be published by the RFC Editor as an Informational RFC. This document is
the product of the HyperText Transfer Protocol Working Group. The IESG
contact persons are Keith Moore and Harald Alvestrand.
Received: from ietf.org by ietf.org id aa25369; 14 May 97 10:03 EDT
Received: from ietf.ietf.org by ietf.org id aa25316; 14 May 97 10:01 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: Multicast Server Architectures for MARS-based ATM
multicasting. to Informational
Date: Wed, 14 May 1997 10:01:48 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705141001.aa25316 at ietf.org>
The IESG has reviewed the Internet-Draft "Multicast Server Architectures
for MARS-based ATM multicasting." <draft-ietf-ion-marsmcs-02.txt> and
recommends that it be published by the RFC Editor as an Informational
RFC. This document is the product of the Internetworking Over NBMA
Working Group. The IESG contact persons are Thomas Narten and Jeffrey
Burgan.
Received: from ietf.org by ietf.org id aa25879; 14 May 97 10:07 EDT
Received: from ietf.ietf.org by ietf.org id aa25845; 14 May 97 10:06 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-mixer at innosoft.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: MaXIM-11 - Mapping between X.400 / Internet mail
and Mail-11 mail to Experimental
Date: Wed, 14 May 1997 10:06:48 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705141006.aa25845 at ietf.org>
The IESG has reviewed the Internet-Draft "MaXIM-11 - Mapping between
X.400 / Internet mail and Mail-11 mail" <draft-ietf-mixer-mail11-00.txt>
and recommends that it be published by the RFC Editor as an Experimental
RFC. This document is the product of the MIME - X.400 Gateway Working
Group. The IESG contact persons are Keith Moore and Harald Alvestrand.
Received: from ietf.org by ietf.org id aa26061; 14 May 97 10:13 EDT
Received: from ietf.ietf.org by ietf.org id aa26020; 14 May 97 10:12 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: PPP Vendor Extensions to Informational
Date: Wed, 14 May 1997 10:12:17 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705141012.aa26020 at ietf.org>
The IESG has reviewed the Internet-Draft "PPP Vendor Extensions"
<draft-ietf-pppext-vendor-01.txt> and recommends that it be published by
the RFC Editor as an Informational RFC. This document is the product of
the Point-to-Point Protocol Extensions Working Group. The IESG contact
persons are Thomas Narten and Jeffrey Burgan.
Received: from ietf.org by ietf.org id aa26209; 14 May 97 10:17 EDT
Received: from ietf.ietf.org by ietf.org id aa26168; 14 May 97 10:16 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: NFS URL Scheme to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 14 May 1997 10:16:11 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705141016.aa26168 at ietf.org>
The IESG has received a request to consider NFS URL Scheme
<draft-callaghan-url-nfs-00.txt> as a Proposed Standard. This has
been reviewed in the IETF but is not the product of an IETF Working
Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by June 14, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from cnri by ietf.org id aa29729; 14 May 97 12:26 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11922;
14 May 97 12:26 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <OAA22272 at pad-thai.cam.ov.com>; Wed, 14 May 1997 14:31:09 GMT
Message-Id: <199705141430.KAA09435 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Martin.Rex at sap-ag.de
Cc: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: RFC2078bis: draft actions and issues
In-Reply-To: Your message of "Tue, 13 May 1997 13:51:29 EDT."
<199705131751.AA21518 at sap-ag.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 14 May 1997 10:30:52 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Martin writes:
>> For gss_import_name() with GSS_C_NO_OID input_name_type, adopt
>> cbind statement that a mechanism-specific default printable syntax
>> for the associated name is used and state that GSS-V2 mechanism
>> specifications shall define the corresponding processing to
>> be performed by their mechanisms.
>
>I had been asking for a slight change of gss_display_name():
>I would like to see a permission that a gssapi mechanism implementation
>may return GSS_C_NO_OID from gss_display_name() if (and only if)
>the given internal name was created via import_name() and GSS_C_NO_OID
>(to support layered multimechanisms).
At first thought, I could accept this restriction, given that
mechanisms would not be *required* to indicate GSS_C_NO_OID when
displaying a name imported with GSS_C_NO_OID and may instead normalize
such names to other of their supported types and display them using
those types. I'd like to hear others' opinions.
>> Expand HL discussion of gss_display_status(), based on C bindings?
>> The message_context() facility to iteratively return multiple status
>> indicators doesn't appear in the HL spec at all. Should it? Martin
>> Rex suggested (29 Jan 97) that it should, at least eventually.
>> [PROPOSED ACTION: Leave RFC-2078 as is; another set of bindings for a
>> different environment could plausibly return all translatable
>> major_status or minor_status error information for a call within a
>> single operation.]
>
>It's funny: now that you mention it, I previously didn't realize that the
>C-Bindings definition of gss_display_status() has one more output parameter
>than the high level definition. Hmmm, this is slightly confusing.
I think this aptly reflects the iterative interface, as defined in the
C bindings but which might not obtain in other environments. Are you
recommending an action to reduce confusion?
>> NAME-RELATED ISSUES:
>>
>> Should UID name forms be indicated as optional and possibly
>> environment-dependent, as they had been in RFC-1964? Should their
>> descriptions be revised, and, if so, how? [PROPOSED ACTION: State as
>> optional and environment-dependent. Leave descriptions as is.]
>>
>> Should user name form be indicated as optional and possibly
>> environment-dependent, as it had been in RFC-1964? Should its
>> description be revised, and, if so, how? [PROPOSED ACTION: State as
>> optional and environment-dependent. Leave description as is.]
>>
>> Should Host-Based Service name form be stated as mandatory for the
>> Internet environment? (Ted Ts'o recommends, 9 Apr 97) [PROPOSED
>> ACTION: Discussion needed; absent follow-up, add no specific
>> statement re mandatory vs. optional.]
>
>All name forms should be indicated as optional in the API spec.
>The individual mechanism specs are currently specifying rules and
>status of nametypes.
>RFC1964bis could mandate hostbased service names, GSS-API shouldn't
>(btw. it would make SPKM non-compliant).
I'll take this as one vote for a statement within 2078bis that
requirements for support or non-support of particular name types are
not specified within 2078bis, which would be a clarifying change
relative to the present spec's silence on the question. I think this
wording would be preferable to stating "optional", since that might be
considered as conflicting with a mechanism spec's requiring support
for a specific type. What do others think?
>Currently, the two *_UID_* nametypes are said to refer to uid_t
>(POSIX term) and therefore apply to POSIX systems only.
Should we remove the reference to uid_t from 2078bis, replacing it
with more generic wording there and deferring any reference to "uid_t"
to the C bindings?
>The "implicit" nametype GSS_C_NO_OID for gss_import_name() should
>be mentioned in Section 4 of RFC2078bis.
Agreed. The nametype representing "anonymous name" should be defined
there as well.
>I still am somewhat uncomfortable with description of GSS_C_NT_USER_NAME
>in RFC2078, where it says "Its interpretation is OS-specific". It should
>at least be changed to "may be OS-specific". In which respect is the
>interpretation of gss_import_name("ftp/somehost",GSS_C_NT_USER_NAME)
>guaranteed to be OS-specific (a) on Unix, (b) on MacIntosh...
>I assume that most gss-krb5-mech implementations of GSS_C_NT_USER_NAME
>are *NOT* OS-specific, i.e. don't do any OS-related checks of the supplied
>printable name.
I've no problem with downgrading to "may". Slightly more broadly,
perhaps we could replace the sentence with "Its syntax and
interpretation may be OS-specific." ??
>> Per late March-early April discussion, is it feasible or appropriate
>> to define and adopt a generic "distributed user name" type? [PROPOSED
>> ACTION: Add no new type at this time; consensus not apparent.]
>
>When support of GSS_C_NO_OID for gss_import_name() is declared
>mechanism-specific (instead of implementation-specific) and support
>of GSS_C_NO_OID is strongly recommended to any mechanism that does
>have a de-facto native nametype, then I don't have a need for
>a generic "distributed user name".
Given the current status of mechanism-specific gss_import_name()
support for GSS_C_NO_OID as a pending action against the spec, I take
this as withdrawal of a pending issue contingent on a strong
recommendation for GSS_C_NO_OID support for certain mechanisms. I'm
not sure how to interpret or specify the proposed constraining
statement, though, considering questions like:
- are there any probable mechanisms which are not structured around
internal use of one or more native name types?
- if a mechanism had co-equal internal support for two types, would
the recommendation apply to that mechanism?
- in light of the working proposal (per earlier in this message)
to defer support/non-support requirements for name types to other
documents, would other types warrant a comparable recommendation?
--jl
Received: from cnri by ietf.org id aa10503; 14 May 97 17:57 EDT
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa18150;
14 May 97 17:57 EDT
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id PAA28130 for telnet-ietf-list at bsdi.com; Wed, 14 May 1997 15:52:27 -0600 (MDT)
Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by external.BSDI.COM (8.8.5/8.8.2) with SMTP id PAA28123 for <telnet-ietf at bsdi.com>; Wed, 14 May 1997 15:52:25 -0600 (MDT)
Received: from RCHLAND by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8676;
Wed, 14 May 97 17:52:21 EDT
Reply-To: Paul Chmielewski <paulc at vnet.ibm.com>
Received: by po1 (AIX 3.2/UCB 5.64/4.7) id <AA33846> for telnet-ietf at bsdi.com; Wed, 14 May 1997 16:51:26 -0500
Received: via switchmail; Wed, 14 May 1997 16:51:26 -0500 (CDT)
Received: from arches.rchland.ibm.com via qmail
ID </afs/rchland.ibm.com/service/mailqs/q000/QF.4nSXDIs91ECWBEvVNV>;
Wed, 14 May 1997 16:51:17 -0500 (CDT)
Received: from arches.rchland.ibm.com via qmail
ID </afs/rchland.ibm.com/usr1/paulc/.Outgoing/QF.cnSXDIQ91ECW1r378H>;
Wed, 14 May 1997 16:51:16 -0500 (CDT)
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.arches.rchland.ibm.com.rs.aix41
via MS.5.6.arches.rchland.ibm.com.rs_aix41;
Wed, 14 May 1997 16:51:16 -0500 (CDT)
Message-Id: <AnSXDI491ECW5r36xG at rchland.ibm.com>
Date: Wed, 14 May 1997 16:51:16 -0500 (CDT)
From: Paul Chmielewski <paulc at vnet.ibm.com>
To: telnet-ietf at bsdi.com
Subject: SSL-enabled telnet
References: <8nSV9mc91ECWJr35Fr at rchland.ibm.com>
We are beginning to look at telnet over Secure Sockets Layer (SSL) as a
way to provide a secure telnet connection over the net. A question came
up as to when an SSL-enabled telnet session should begin encrypting the
data stream. Should the data stream be encrypted from the start,
including all the telnet option negotiations? Or would encryption begin
after the initial telnet negotiations? I would think that one would
want encryption from the start, but thought I'd ask.
Are there SSL-enabled telnet implementations out there and if so, is
encryption attempted prior to telnet option negotiation? I see that
somebody has at least gone as far as getting port 992 assigned for
secure telnet.
Thanks.
-Paul Chmielewski (paulc at vnet.ibm.com)
-AS/400 Communications Development
-IBM Rochester, MN
Received: from ietf.org by ietf.org id aa11643; 14 May 97 19:05 EDT
Received: from zephyr.isi.edu by ietf.org id aa11468; 14 May 97 18:57 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA21549>; Wed, 14 May 1997 15:54:18 -0700
Message-Id: <199705142254.AA21549 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2143 on Encapsulating IP with the SCSI
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 14 May 97 15:54:17 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2143:
Title: Encapsulating IP with the Small Computer
System Interface
Author: B. Elliston
Date: May 1997
Mailbox: ben.elliston at compucat.com.au
Pages: 5
Characters: 10749
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2143.txt
This document outlines a protocol for connecting hosts running the
TCP/IP protocol suite over a Small Computer System Interface (SCSI)
bus.
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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at 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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <970514155007.RFC at ISI.EDU>
SEND /rfc/rfc2143.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2143.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970514155007.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13607; 14 May 97 20:59 EDT
Received: from venera.isi.edu by ietf.org id aa13498; 14 May 97 20:54 EDT
Received: from gpu.utcc.utoronto.ca by venera.isi.edu (5.65c/5.61+local-27)
id <AA22941>; Wed, 14 May 1997 17:49:33 -0700
Received: by gpu.utcc.utoronto.ca id <336775>; Wed, 14 May 1997 20:48:57 -0400
Newsgroups: info.ietf
Followup-To:
Distribution:
Organization: UTCNS Public Access
Sender:ietf-request at ietf.org
From: Alex Nishri <nishri at utcc.utoronto.ca>
To: ietf at isi.edu
Subject: usa.net emulates AOL? (source routing)
Summary:
Keywords:
Message-Id: <97May14.204857edt.336775 at gpu.utcc.utoronto.ca>
Date: Wed, 14 May 1997 20:48:50 -0400
Source-Info: From (or Sender) name not authenticated.
We have many users here who are trying to send email to usa.net but
the mail is being rejected:
220 NetAddress (mx01) [2.1(c)] ready to rock at Wed, 14 May 1997 18:42:38 -0600
HELO utoronto.ca
250 (utoronto.ca) pleased to meet you.
MAIL FROM:<@bureau6.utcc.utoronto.ca:alex.nishri at utoronto.ca>
550 Invalid sender
This isn't too illuminating.
If you ignore the MX record (not a legit thing to do) and connect directly
to usa.net (a different) you get a better error message:
MAIL FROM:<@bureau6.utcc.utoronto.ca:alex.nishri at utoronto.ca>
418 <@bureau6.utcc.utoronto.ca:alex.nishri at utoronto.ca>... Can't resolve
your DNS name. You don't exist and are probably a spammer. If you believe
to have received this message in error, contact your site administrator.
Is this an eumlation of AOL's rejection of source routing on the SMTP
MAIL FROM?
Alex Nishri
Network Services
University of Toronto
email: alex.nishri at utoronto.ca
Received: from ietf.org by ietf.org id aa14363; 14 May 97 21:43 EDT
Received: from venera.isi.edu by ietf.org id aa14315; 14 May 97 21:41 EDT
Received: from gpu.utcc.utoronto.ca by venera.isi.edu (5.65c/5.61+local-27)
id <AA25266>; Wed, 14 May 1997 18:38:13 -0700
Received: by gpu.utcc.utoronto.ca id <336777>; Wed, 14 May 1997 21:38:06 -0400
Newsgroups: info.ietf
Sender:ietf-request at ietf.org
From: Alex Nishri <nishri at utcc.utoronto.ca>
To: ietf at isi.edu
Subject: usa.net emulates AOL? (source routing)
Summary:
Followup-To:
Distribution:
Organization: UTCNS Public Access
Keywords:
Message-Id: <97May14.213806edt.336777 at gpu.utcc.utoronto.ca>
Date: Wed, 14 May 1997 21:38:02 -0400
Source-Info: From (or Sender) name not authenticated.
We have many users here who are trying to send email to usa.net but
the mail is being rejected:
220 NetAddress (mx01) [2.1(c)] ready to rock at Wed, 14 May 1997 18:42:38 -0600
HELO utoronto.ca
250 (utoronto.ca) pleased to meet you.
MAIL FROM:<@bureau6.utcc.utoronto.ca:alex.nishri at utoronto.ca>
550 Invalid sender
This isn't too illuminating.
If you ignore the MX record (not a legit thing to do) and connect directly
to usa.net (a different) you get a better error message:
MAIL FROM:<@bureau6.utcc.utoronto.ca:alex.nishri at utoronto.ca>
418 <@bureau6.utcc.utoronto.ca:alex.nishri at utoronto.ca>... Can't resolve
your DNS name. You don't exist and are probably a spammer. If you believe
to have received this message in error, contact your site administrator.
Is this an eumlation of AOL's rejection of source routing on the SMTP
MAIL FROM?
Alex Nishri
Network Services
University of Toronto
email: alex.nishri at utoronto.ca
Received: from ietf.org by ietf.org id aa14529; 14 May 97 21:53 EDT
Received: from venera.isi.edu by ietf.org id aa14488; 14 May 97 21:52 EDT
Received: from works.ingrid.org by venera.isi.edu (5.65c/5.61+local-27)
id <AA26020>; Wed, 14 May 1997 18:48:34 -0700
Received: by works.ingrid.org (8.8.4/ingrid*mx2) with TCP; Thu, 15 May 1997 10:50:26 +0900 (JST)
Date: Thu, 15 May 1997 10:50:26 +0900 (JST)
Sender:ietf-request at ietf.org
From: Paul Francis <francis at works.ingrid.org>
Message-Id: <199705150150.KAA18333 at works.ingrid.org>
To: ietf at isi.edu, nishri at utcc.utoronto.ca
Subject: Re: usa.net emulates AOL? (source routing)
Source-Info: From (or Sender) name not authenticated.
>
> We have many users here who are trying to send email to usa.net but
> the mail is being rejected:
>
Come on people....surely there has got to be a more
appropriate place than the ietf mailing list to discuss this???
PF
Received: from cnri by ietf.org id aa29373; 15 May 97 7:17 EDT
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa06780;
15 May 97 7:17 EDT
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id FAA18289 for telnet-ietf-list at bsdi.com; Thu, 15 May 1997 05:13:14 -0600 (MDT)
Received: from dot.netrex.net (dot.netrex.net [206.253.225.51]) by external.BSDI.COM (8.8.5/8.8.2) with ESMTP id FAA18284 for <telnet-ietf at bsdi.com>; Thu, 15 May 1997 05:13:13 -0600 (MDT)
Received: from rgm3 (nsn1-gw5-xl1.netrex.com [206.253.228.11]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id HAA25397; Thu, 15 May 1997 07:13:09 -0400 (EDT)
Message-Id: <3.0.1.32.19970515070744.00b69630 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 15 May 1997 07:07:44 -0400
To: Paul Chmielewski <paulc at vnet.ibm.com>, telnet-ietf at bsdi.com
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: SSL-enabled telnet
In-Reply-To: <AnSXDI491ECW5r36xG at rchland.ibm.com>
References: <8nSV9mc91ECWJr35Fr at rchland.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 04:51 PM 5/14/97 -0500, Paul Chmielewski wrote:
SSH may be a better tool for this.
Or better yet, IPsec with user control via the APIs :)
>We are beginning to look at telnet over Secure Sockets Layer (SSL) as a
>way to provide a secure telnet connection over the net. A question came
>up as to when an SSL-enabled telnet session should begin encrypting the
>data stream. Should the data stream be encrypted from the start,
>including all the telnet option negotiations? Or would encryption begin
>after the initial telnet negotiations? I would think that one would
>want encryption from the start, but thought I'd ask.
>
>Are there SSL-enabled telnet implementations out there and if so, is
>encryption attempted prior to telnet option negotiation? I see that
>somebody has at least gone as far as getting port 992 assigned for
>secure telnet.
>
>Thanks.
>-Paul Chmielewski (paulc at vnet.ibm.com)
>-AS/400 Communications Development
>-IBM Rochester, MN
>
>
>
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa02509; 15 May 97 9:46 EDT
Received: from ietf.ietf.org by ietf.org id aa02343; 15 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hoffman-des40-00.txt
Date: Thu, 15 May 1997 09:41:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150941.aa02343 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Creating 40-Bit Keys for DES
Author(s) : P. Hoffman, R. Housley
Filename : draft-hoffman-des40-00.txt
Date : 05/14/1997
This document describes an method for shortening DES keys from 56 bits to
40 bits. The shortened keys are generally known as "DES-40". The motivation
for this weakening is that some localities (such as the United States) give
special preference to applications that use 40-bit keys. The weakened keys
are then used with the DES encryption algorithm in the same manner as
full-strength keys.
There are many possible methods for reducing a 56-bit key to a 40-bit key.
The method in this draft was chosen because one method is needed for
interoperability. Further, this method has been known to occaisionally
have been approved for export from the United States.
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-des40-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-des40-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hoffman-des40-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514135516.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-des40-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-des40-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514135516.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02847; 15 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa02370; 15 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: confctrl at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-url-00.txt, .ps
Date: Thu, 15 May 1997 09:41:58 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150941.aa02370 at 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 : SIP URL Scheme
Author(s) : H. Schulzrinne
Filename : draft-ietf-mmusic-sip-url-00.txt, .ps
Pages : 3
Date : 05/14/1997
A family of new URL schemes, "sip*:", is defined. It is used to establish
multimedia conferences using the Session Initiation Protocol (SIP).
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-sip-url-00.txt".
Or
"get draft-ietf-mmusic-sip-url-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sip-url-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mmusic-sip-url-00.txt".
Or
"FILE /internet-drafts/draft-ietf-mmusic-sip-url-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514164831.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-url-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mmusic-sip-url-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514164831.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02861; 15 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa02511; 15 May 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-urn-ietf-00.txt
Date: Thu, 15 May 1997 09:44:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150944.aa02511 at 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 : URN Namespace for RFC series documents
Author(s) : R. Moats
Filename : draft-ietf-urn-ietf-00.txt
Pages : 4
Date : 05/14/1997
A system for Uniform Resource Names (URNs) must be capable of supporting
new naming systems. As an example of the sort of information that needs to
be supplied when proposing new namepsaces, this document presents a naming
system based on the RFC family of documents (RFCs, STDs, and FYIs)
developed by the IETF and published by the RFC editor. This namespace can
be supported within the URN framework and the currently proposed syntax
for URNs.
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-ietf-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-ietf-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-urn-ietf-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514131911.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-ietf-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-ietf-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514131911.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02856; 15 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa02090; 15 May 97 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-namedpool-00.txt
Date: Thu, 15 May 1997 09:38:00 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150938.aa02090 at 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 Named Pool Request Option for DHCP
Author(s) : K. McGrew
Filename : draft-ietf-dhc-namedpool-00.txt
Pages : 4
Date : 05/14/1997
This option is used by a DHCP client to optionally identify the specific
named pool from which it should be assigned an IP address. The information
contained in this option is an ASCII text object that represents the named
pool from which the DHCP server assign an IP address to the DHCP 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-ietf-dhc-namedpool-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-namedpool-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-namedpool-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514154144.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-namedpool-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-namedpool-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514154144.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02855; 15 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa02217; 15 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-frnetmib-dte-svc-00.txt
Date: Thu, 15 May 1997 09:41:17 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150941.aa02217 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Management Information Base for Frame Relay DTE
Extensions for SVC's over Frame Relay
Author(s) : D. Cochrane
Filename : draft-ietf-frnetmib-dte-svc-00.txt
Pages : 20
Date : 05/14/1997
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 Frame Relay Switched
Virtual Circuit's.
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-frnetmib-dte-svc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-frnetmib-dte-svc-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-frnetmib-dte-svc-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514133607.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-frnetmib-dte-svc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-frnetmib-dte-svc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514133607.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02860; 15 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa02238; 15 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hoffman-smtp-ssl-02.txt
Date: Thu, 15 May 1997 09:41:24 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150941.aa02238 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SMTP Service Extension for Secure SMTP over TLS
Author(s) : P. Hoffman
Filename : draft-hoffman-smtp-ssl-02.txt
Pages : 4
Date : 05/14/1997
This document describes an extension to the SMTP service that allows an
SMTP server and client to use transport-layer security to provide private,
authenticated communication over the Internet. This gives SMTP agents the
ability to protect some or all of their communications from eavesdroppers
and attackers.
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-smtp-ssl-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-smtp-ssl-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hoffman-smtp-ssl-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514134032.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-smtp-ssl-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-smtp-ssl-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514134032.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02853; 15 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa02397; 15 May 97 9:42 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-jaye-trust-state-00.txt
Date: Thu, 15 May 1997 09:42:03 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150942.aa02397 at ietf.org>
--NextPart
A New 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.
Title : HTTP Trust Mechanism for State Management (Rev 1)
Author(s) : D. Jaye
Filename : draft-ietf-http-jaye-trust-state-00.txt
Pages : 8
Date : 05/14/1997
This document specifies an addition to the state management protocol
specified in RFC 2109. The intent is to provide a mechanism that allows
user agents to determine the trust and privacy policies of a server and to
accept or reject cookies based on that policy. Allowing the user to decide
whether to accept cookies based on the server's policies and trust level
provides control over privacy.
To provide such information about server privacy behavior, we assume the
existence of an independent Trust Authority (or authorities), such as
eTrust. The authority establishes levels of "trust" and can audit domains
to determine their adherence to a given level. It then issues TrustLabels,
in the form of signed PICS labels, to domains based on the trust level.
Passing those TrustLabels along with cookies allows the user-agent to
support cookie acceptance rules based on trust level.
This document describes a new header, Set-PICS-Cookie, that extends the
Set-Cookie2 header in RFC2109[Kristol] to allow PICS labels that certify
trust levels of domains (which we will call TrustLabels) to be sent along
with cookies.
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-jaye-trust-state-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-jaye-trust-state-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-jaye-trust-state-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514173245.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-jaye-trust-state-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-jaye-trust-state-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514173245.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02864; 15 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa02108; 15 May 97 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: harts at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-harts-guide-02.txt
Date: Thu, 15 May 1997 09:38:05 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150938.aa02108 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Humanities and Arts Working
Group of the IETF.
Title : Humanities and Arts: Sharing Center Stage on the
Internet
Author(s) : J. Max, S. Stoner
Filename : draft-ietf-harts-guide-02.txt
Pages : 37
Date : 05/14/1997
This document is designed primarily for individuals who have limited
knowledge of, or experience with, the Internet.
The purpose of this document is to provide members of the arts and
humanities communities with an introduction to the Internet
as a valuable tool, resource, and medium for the creation,
presentation, and preservation of arts and humanities-based content.
The intended audience is practicing artists, scholars, related
professionals, and others who's knowledge, expertise and support
is important to ensuring the arts and humanities are well-placed
in the global information infrastructure.
For purposes of simplicity this document will use the word "Artist" to mean
both Artist and Humanist: "all practitioners who work in the fields of the
visual, performance, and literary arts, as well as museum curators,
librarians, and others who are involved in the research, restoration, and
presentation of that which comprises our cultural heritage." (See Section
1.1 for further definitions of Arts and Humanitites.)
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-harts-guide-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-harts-guide-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-harts-guide-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514123131.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-harts-guide-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-harts-guide-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514123131.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02867; 15 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa02271; 15 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snanaumib at external.cisco.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-snanau-hprmib-02.txt
Date: Thu, 15 May 1997 09:41:34 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150941.aa02271 at 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 HPR
Author(s) : B. Clouston, B. Moore
Filename : draft-ietf-snanau-hprmib-02.txt
Pages : 39
Date : 05/14/1997
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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snanau-hprmib-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snanau-hprmib-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514134647.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snanau-hprmib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snanau-hprmib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514134647.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02858; 15 May 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa02316; 15 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-oncrpc-rpcsec_gss-04.txt
Date: Thu, 15 May 1997 09:41:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705150941.aa02316 at 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-04.txt
Pages : 21
Date : 05/14/1997
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-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-oncrpc-rpcsec_gss-04.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514135039.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-oncrpc-rpcsec_gss-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514135039.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06568; 15 May 97 11:42 EDT
Received: from cnri by ietf.org id aa06501; 15 May 97 11:40 EDT
Received: from h132-197-8-26.gte.com by CNRI.Reston.VA.US id aa11514;
15 May 97 11:40 EDT
Received: from [132.197.144.52] by gte.com (8.8.4/8.8.4)
X-Sender: bk00 at pophost.gte.com
Message-Id: <v03007822afa0da022f66 at [132.197.144.52]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 May 1997 11:27:27 -0400
To: enternet at bbn.com, comswtc at gmu.edu, ieeetcpc at ccvm.sunysb.edu,
ietf at CNRI.Reston.VA.US, itc at fokus.gmd.de, tccc at cs.umass.edu,
dbworld at cs.wisc.edu, cnom at maestro.bellcore.com
Sender:ietf-request at ietf.org
From: "Dr. Bhumip Khasnabish, +1-617-466-2080" <bhumip at gte.com>
Subject: advance program of ENM-97 (in conj. with ICC-97). thanks.
Cc: lrothstein at shl.com, ahmadi at engn.uwindsor.ca, braudyb at aol.com,
rlfike at aol.com, bran at silcom.com, bran at metacomm.com, just4net at aol.com,
dkirsch at networkdesigns.com, dkirsch at ensight.com, stanm at bellcore.com,
pogran at bbn.com, vkb at mailnet.ho.att.com, w2xd at aol.com,
kjoseph at ottawa.gdc.ca, aidarous at nortel.ca, kjl at bellcore.com,
bhumip at gte.com, sbw at ccrl.nj.nec.com, c.desmond at ieee.org, nkc at bellcore.com,
Ron.Horn.0090874 at nt.com, mouftah at eleceng.ee.queensu.ca,
t.stevenson at ieee.org, christos at ece.miami.edu,
Roberto.Saracco at cselt.stet.it, xrjo at atc.boeing.com,
wz at prosun.first.gmd.de, hegering at lrz-muenchen.de,
yoshida at netwk.ntt-at.co.jp, craig at bbn.com, yemini at cs.columbia.edu,
lanworks at delphi.com, ahmed at ece.concordia.ca, shervin_erfani at usa.racal.com,
knecht at mvuss.mv.lucent.com, a.pakstas at ieee.org, mike at sce.carleton.ca,
yang at trix.genie.uottawa.ca, rne at hybrid.com, dheer at lucent.com,
mmalek at lucent.com, sdp at bellcore.com, messer at eecs.berkeley.edu,
p.ray at st.nepean.uws.edu.au, bikim at etri.re.kr, etxkang at etri.re.kr,
brahim.maaref at imag.fr, michael.a.weinstein at att.com,
Ali.Marefat at prism.uvsq.fr, jingsha at aimquest.com, bumblis at mcc.com,
Liscano at iit.nrc.ca, qyu at dgp.toronto.ca, abu-hakim at iit.nrc.ca,
Impey at sel.iit.nrc.ca, liny at liny.csie.nctu.edu.tw,
v.mirchandani at ee.mu.oz.au, loureiro at dcc.ufmg.br, jmarcos at dcc.ufmg.br,
jwkhong at postech.ac.kr, pachi at arch4.att.com, clopez at sol.des.fi.udc.es,
dsanchez at sol.des.fi.udc.es, victor at sol.des.fi.udc.es,
avc at sol.des.fi.udc.es, jcoego at sol.des.fi.udc.es
Source-Info: From (or Sender) name not authenticated.
The advance program of ENM-97 is availabel at:
http://www.comsoc.org/confs/icc/97/enm/AP.html
Thanks.
Bhumip.
Thanks a lot,
with all the best wishes and regards,
-----------------------------------------------------------------------
Dr. Bhumip Khasnabish, GTE Labs. Inc., MS-48, Rm.4-292
40 Sylvan Road, Waltham, MA 02254, U.S.A.
Tel: +1-617-466-2080 (office), +1-617-647-5356 (Res.)
Fax +1-617-890-9320 (central), +1-617-466-2130 (dept.)
E-Mail: bhumip at gte.com, bhumip at acm.org, b.khasnabish at ieee.org
GTE IntraNet: http://cnsmacic.gte.com/users/bhumip/
Internet URL: http://www1.acm.org:82/~bhumip/
=====================================================================
Received: from ietf.org by ietf.org id aa08585; 15 May 97 12:29 EDT
Received: from cnri by ietf.org id aa08533; 15 May 97 12:27 EDT
Received: from leporello.cs.unibo.it by CNRI.Reston.VA.US id aa12364;
15 May 97 12:27 EDT
Received: from macbeth.cs.unibo.it by leporello.cs.unibo.it (5.67b/96.09.13)
id AA02471; Thu, 15 May 1997 18:22:20 +0200
Sender:ietf-request at ietf.org
From: Roberto Gorrieri <gorrieri at cs.unibo.it>
Received: by macbeth.cs.unibo.it (5.67b/CS-14.10.96)
id AA01071; Thu, 15 May 1997 18:22:20 +0200
Date: Thu, 15 May 1997 18:22:20 +0200
Message-Id: <199705151622.AA01071 at macbeth.cs.unibo.it>
To: IETF at CNRI.Reston.VA.US
Subject: ICALP'97
Source-Info: From (or Sender) name not authenticated.
*******************************************************
* *
* ICALP '97 *
* ========= *
* 24th International Colloquium on Automata, *
* Languages, and Programming *
* *
* Silver Jubilee of EATCS *
* *
* Bologna, Italy, July 7th - 11th, 1997 *
* *
*******************************************************
The (nearly) final program and information about the conference are
available per www under
http://www.cs.unibo.it/icalp97/
SPECIAL EVENT
^^^^^^^^^^^^^
On Wednesday, July 9th, Robin Milner and Maurice Nivat will receive a
Laurea Honoris Causa in Computer Science from the University of Bologna.
GRANTS
^^^^^^
A few UNESCO grants are still available for participants coming from
less developed countries.
Some EU grants are available for supporting the participation
of young researchers:
- only persons with nationality of one of the EU Member States
or of an Associated State may benefit directly from Commisssion
support;
- participants should be less than 35 on the 1st day of the conference.
Requests for grants should be sent (e-mail or fax) to the Conference
Office:
Italiana & Co. - ICALP'97
Via Altabella 3
I-40126 BOLOGNA (Italy)
Phone: + 39 51 228716
Fax: + 39 51 222881
Email: italiana at bo.nettuno.it
Please specify nationality, age, status and affiliation.
Received: from cnri by ietf.org id aa10702; 15 May 97 13:24 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13337;
15 May 97 13:24 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA11314 at pad-thai.cam.ov.com>; Thu, 15 May 1997 15:40:36 GMT
Message-Id: <337BACF7.59DD at frcl.bull.fr>
Date: Thu, 15 May 1997 17:40:23 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: CAT-IETF WG <cat-ietf at mit.edu>
Subject: SPNEGO
Precedence: bulk
Received: from cnri by ietf.org id aa11726; 15 May 97 14:00 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14176;
15 May 97 14:00 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA10702 at pad-thai.cam.ov.com>; Thu, 15 May 1997 15:33:22 GMT
Message-Id: <337BAB48.6D0E at frcl.bull.fr>
Date: Thu, 15 May 1997 17:33:12 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Revised draft for S(P)NEGO
Precedence: bulk
Received: from ietf.org by ietf.org id aa13379; 15 May 97 14:37 EDT
Received: from ietf.ietf.org by ietf.org id aa13211; 15 May 97 14:32 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-revised-enc-mode-00.txt
Date: Thu, 15 May 1997 14:32:24 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705151432.aa13211 at 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 : A revised encryption mode for ISAKMP/Oakley
Author(s) : R. Canetti, P. Cheng, H. Krawczyk
Filename : draft-ietf-ipsec-revised-enc-mode-00.txt
Pages : 6
Date : 05/06/1997
The ISAKMP/Oakley document [HC97] describes a proposed standard for using
the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain
authenticated and secret keying material for use with ISAKMP, and for other
security associations such as AH and ESP for the IETF IPsec DOI.
The public-key encryption method of carrying out Phase 1 of the
key exchange in the ISAKMP/Oakley document requires two public key
encryption and decryption operations from both the Initiator and
the Responder. The present document describes a small modification
to this method. The resulting method requires only one public key
encryption and decryption operation from each party, while maintaining
(and even improving on) the strong security properties of the
ISAKMP/Oakley public-key encryption mode.
Remark: This document is NOT self-contained. It uses notation and
definitions of [HC97]. It is best read in conjunction with [HC97].
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-revised-enc-mode-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-revised-enc-mode-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-revised-enc-mode-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970515142834.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-revised-enc-mode-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-revised-enc-mode-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970515142834.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13381; 15 May 97 14:37 EDT
Received: from ietf.ietf.org by ietf.org id aa13286; 15 May 97 14:34 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: mpls at external.cisco.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mpls-framework-00.txt (re-send)
Date: Thu, 15 May 1997 14:34:54 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705151434.aa13286 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Multiprotocol Label
Switching Working Group of the IETF.
Title : A Framework for Multiprotocol Label Switching
Author(s) : R. Callon, P. Doolan, N. Feldman, A. Fredette,
G. Swallow, A. Viswanathan
Filename : draft-ietf-mpls-framework-00.txt
Pages : 44
Date : 05/12/1997
This document discusses technical issues and requirements for the
Multiprotocol Label Switching working group. This is an initial draft
document, which will evolve and expand over time. It is the intent of this
document to produce a coherent description of all significant approaches
which were and are being considered by the working group. Selection of
specific approaches, making choices regarding engineering tradeoffs, and
detailed protocol specification, are outside of the scope of this
framework document.
Note that this document is at an early stage, and that most of the
detailed technical discussion is only in a rough form. Additional
text will be provided over time from a number of sources.
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-mpls-framework-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mpls-framework-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mpls-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970512165432.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-framework-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mpls-framework-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970512165432.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07870; 16 May 97 8:32 EDT
Received: from ietf.ietf.org by ietf.org id aa07629; 16 May 97 8:24 EDT
To: IETF-Announce: ;
cc: namedroppers at internic.net
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Clarifications to the DNS Specification to Proposed
Standard
Reply-to: iesg at ietf.org
Date: Fri, 16 May 1997 08:23:59 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705160824.aa07629 at ietf.org>
The IESG has received a request from the DNS IXFR, Notification, and
Dynamic Update Working Group to consider "Clarifications to the DNS
Specification" <draft-ietf-dnsind-clarify-08.txt> 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 at ietf.org or ietf at ietf.org mailing lists by May 29, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa08451; 16 May 97 8:51 EDT
Received: from ietf.ietf.org by ietf.org id aa08240; 16 May 97 8:49 EDT
To: IETF-Announce: ;
cc: namedroppers at internic.net
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Classless IN-ADDR.ARPA delegation to Proposed Standard
Reply-to: iesg at ietf.org
Date: Fri, 16 May 1997 08:49:26 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705160849.aa08240 at ietf.org>
The IESG has received a request from the DNS IXFR, Notification, and
Dynamic Update Working Group to consider "Classless IN-ADDR.ARPA
delegation" <draft-ietf-dnsind-classless-inaddr-03.txt> 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 at ietf.org or ietf at ietf.org mailing lists by May 29, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa09427; 16 May 97 9:26 EDT
Received: from ietf.ietf.org by ietf.org id aa09097; 16 May 97 9:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-mib-03.txt
Date: Fri, 16 May 1997 09:24:46 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705160924.aa09097 at 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 : Definitions of Managed Objects for Classical IP and ARP
Over ATM Using SMIv2
Author(s) : M. Greene, J. Luciani, K. White, T Kuo
Filename : draft-ietf-ion-mib-03.txt
Pages : 40
Date : 05/14/1997
The purpose of this memo is to define the Management Information Base (MIB)
for supporting Classical IP and ARP over ATM as specified in Classical IP
and ARP over ATM, refer to reference [3]. Support of an ATM interface by an
IP layer will require implementation of objects from several Managed
Information Bases (MIBs) as well as their enhancement in order to enable
usage of ATM transports. It is the intent of this MIB to fully adhere to
all prerequisite MIBs unless explicitly stated. Deviations will be
documented in corresponding conformance statements. The specification of
this MIB will utilize the Structure of Management Information (SMI) for
Version 2 of the Simple Network Management Protocol Version (refer to
RFC1902, reference [1]).
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-mib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-mib-03.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970514154817.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970514154817.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09425; 16 May 97 9:26 EDT
Received: from ietf.ietf.org by ietf.org id aa09228; 16 May 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-cat-snego-05.txt
Date: Fri, 16 May 1997 09:25:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705160925.aa09228 at 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 Simple and Protected GSS-API Negotiation Mechanism
Author(s) : E. Baize, D. Pinkas
Filename : draft-ietf-cat-snego-05.txt
Pages : 14
Date : 05/15/1997
This draft document specifies a Security Negotiation Mechanism for the
Generic Security Service Application Program Interface (GSS-API) which is
described in [1].
The GSS-API provides a generic interface which can be layered
atop different security mechanisms such that if communicating peers
acquire GSS-API credentials for the same security mechanism,
then a security context may be established between them (subject
to policy). However, GSS-API doesn't prescribe the method by
which GSS-API peers can establish whether they have a common
security mechanism.
The Simple and Protected GSS-API Negotiation Mechanism defined here is a
pseudo-security mechanism, represented by the object identifier
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables
GSS-API peers to determine in-band whether their credentials share common
GSS-API security mechanism(s), and if so, to invoke normal security context
establishment for a selected common security mechanism. This is most useful
for applications that are based on GSS-API implementations which support
multiple security mechanisms.
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-snego-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-snego-05.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-snego-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970515141338.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-snego-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-snego-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970515141338.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09430; 16 May 97 9:26 EDT
Received: from ietf.ietf.org by ietf.org id aa09190; 16 May 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-whois-url-01.txt
Date: Fri, 16 May 1997 09:25:02 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705160925.aa09190 at 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 : WHOIS++ URL Specification
Author(s) : M. Hamilton
Filename : draft-ietf-asid-whois-url-01.txt
Pages : 7
Date : 05/15/1997
This document defines a new Uniform Resource Locator (URL) scheme
"whois++", which provides a convention within the URL framework for
referring to WHOIS++ servers and the data held within them.
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-url-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-whois-url-01.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-whois-url-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970515140712.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-whois-url-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-whois-url-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970515140712.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09428; 16 May 97 9:26 EDT
Received: from ietf.ietf.org by ietf.org id aa09117; 16 May 97 9:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: agentx at fv.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-agentx-mib-00.txt
Date: Fri, 16 May 1997 09:24:55 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705160924.aa09117 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNMP Agent Extensibility
Working Group of the IETF.
Title : Definitions of Managed Objects for
Extensible SNMP Agents
Author(s) : M. Greene, S. Gudur
Filename : draft-ietf-agentx-mib-00.txt
Pages : 16
Date : 05/15/1997
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 objects managing SNMP agents that
use the Agent Extensibility (AgentX) Protocol.
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.
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-agentx-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-agentx-mib-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-agentx-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970515111423.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-agentx-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-agentx-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970515111423.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09426; 16 May 97 9:26 EDT
Received: from ietf.ietf.org by ietf.org id aa09259; 16 May 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-transition-02.txt
Date: Fri, 16 May 1997 09:25:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705160925.aa09259 at 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 to NHRP Transition
Author(s) : J. Luciani
Filename : draft-ietf-ion-transition-02.txt
Pages : 5
Date : 05/15/1997
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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-transition-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-transition-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970515143936.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-transition-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-transition-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970515143936.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa10197; 16 May 97 9:43 EDT
Received: from ietf.ietf.org by ietf.org id aa10115; 16 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-gahrns-imap-practice-02.txt
Date: Fri, 16 May 1997 09:41:07 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705160941.aa10115 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP4 Multi-Accessed Mailbox Practice
Author(s) : M. Gahrns
Filename : draft-gahrns-imap-practice-02.txt
Pages : 12
Date : 05/12/1997
IMAP4[rfc2060] is rich client/server protocol that allows a client to
access and manipulate electronic mail messages on a server. Within the
protocol framework, it is possible to have differing results for particular
client/server interactions. If a protocol does not allow for this, it is
often unduly restrictive.
For example, when multiple clients are accessing a mailbox and
one attempts to delete the mailbox, an IMAP4 server may choose to
implement a solution based upon server architectural
constraints or individual preference.
With this flexibility comes greater client responsibility. It is
not sufficient for a client to be written based upon the behavior
of a particular IMAP server. Rather the client must be based upon
the behavior allowed by the protocol.
By documenting common IMAP4 server practice for the case of
simultaneous client access to a mailbox, we hope to ensure the
widest amount of inter-operation between IMAP4 clients and 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-gahrns-imap-practice-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-practice-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-gahrns-imap-practice-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970516093852.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gahrns-imap-practice-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gahrns-imap-practice-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970516093852.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa10707; 16 May 97 9:56 EDT
Received: from venera.isi.edu by ietf.org id aa10584; 16 May 97 9:52 EDT
Received: from bureau6.utcc.utoronto.ca by venera.isi.edu (5.65c/5.61+local-27)
id <AA04233>; Fri, 16 May 1997 06:48:24 -0700
Received: from gpu.utcc ([128.100.102.1]) by bureau6.utcc.utoronto.ca with SMTP id <159812(3)>; Fri, 16 May 1997 09:48:21 -0400
Date: Fri, 16 May 1997 09:48:12 -0400
Sender:ietf-request at ietf.org
From: Alex Nishri <nishri at utcc.utoronto.ca>
X-Sender: nishri at gpu.utcc
Reply-To: alex.nishri at utoronto.ca
To: ietf at isi.edu
Subject: Re: usa.net emulates AOL? (source routing)
Message-Id: <Pine.SUN.3.93.970516094121.8474B-100000 at gpu.utcc>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
The fundamental issue is who sets & evolves Internet standards, large ISPs or
the IETF? What if a bunch of ISPs decide to reject IPv4 packets next month?
Which is the appropriate newsgroup or mailing list for this topic?
> Date: Wed, 14 May 1997 21:50:26 -0400
> From: Paul Francis <francis at works.ingrid.org>
> To: ietf at isi.edu, nishri at utcc.utoronto.ca
> Subject: Re: usa.net emulates AOL? (source routing)
>
> >
> > We have many users here who are trying to send email to usa.net but
> > the mail is being rejected:
> >
>
> Come on people....surely there has got to be a more
> appropriate place than the ietf mailing list to discuss this???
>
> PF
Received: from ietf.org by ietf.org id aa12966; 16 May 97 11:25 EDT
Received: from venera.isi.edu by ietf.org id aa12856; 16 May 97 11:22 EDT
Received: from callandor.cybercash.com by venera.isi.edu (5.65c/5.61+local-27)
id <AA06853>; Fri, 16 May 1997 08:18:46 -0700
Received: by callandor.cybercash.com; id LAA29925; Fri, 16 May 1997 11:08:22 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma029878; Fri, 16 May 97 11:08:07 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA02156; Fri, 16 May 97 11:13:48 EDT
Date: Fri, 16 May 1997 11:13:48 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at isi.edu
Subject: Re: usa.net emulates AOL? (source routing)
In-Reply-To: <Pine.SUN.3.93.970516094121.8474B-100000 at gpu.utcc>
Message-Id: <Pine.SUN.3.91.970516105912.1180D-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 16 May 1997, Alex Nishri wrote:
> Date: Fri, 16 May 1997 09:48:12 -0400
> From: Alex Nishri <nishri at utcc.utoronto.ca>
>
> The fundamental issue is who sets & evolves Internet standards, large ISPs or
> the IETF? What if a bunch of ISPs decide to reject IPv4 packets next month?
The IETF sets IETF standards and the ITU sets ITU standards and the IEEE sets
IEEE standards, etc. ISPs get to choose what standards they want to follow
and how closely, although, of course, their decisions in this area can have
impact on what services they can offer and their connectivity. In fact, I
would say that any large ISP sets quite a number of its own internal
standards for handling cusomters and infrastructure, etc.
The IETF has been successful because its standards have been the most
attractive. You sound as if you believe people/ISP should be forced to
follow IETF standards. Note that for some time many governments did (and some
may still do) order everyone to use and follow OSI standards. This
encouraged some people to view them as damaged goods which no one would want
to use unless they were being forced down peoples throats by bureaucrats.
And that is now some will start to view IETF standards if someone is holding
a gun to their head and ordering them to follow every letter in the
standards.
> Which is the appropriate newsgroup or mailing list for this topic?
There are mailing lists for ISP interoperation and policy, such as NANOG.
This mailing list's topic is the IETF and setting it's standards.
> > Date: Wed, 14 May 1997 21:50:26 -0400
> > From: Paul Francis <francis at works.ingrid.org>
> > To: ietf at isi.edu, nishri at utcc.utoronto.ca
> > Subject: Re: usa.net emulates AOL? (source routing)
> >
> > > We have many users here who are trying to send email to usa.net but
> > > the mail is being rejected:
> >
> > Come on people....surely there has got to be a more
> > appropriate place than the ietf mailing list to discuss this???
> >
> > PF
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at 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 aa13060; 16 May 97 11:27 EDT
Received: from venera.isi.edu by ietf.org id aa13008; 16 May 97 11:27 EDT
Received: from relay7.UU.NET by venera.isi.edu (5.65c/5.61+local-27)
id <AA07756>; Fri, 16 May 1997 08:23:36 -0700
Received: from rodan.UU.NET by relay7.UU.NET with ESMTP
(peer crosschecked as: rodan.UU.NET [153.39.130.10])
id QQcpuj12025; Fri, 16 May 1997 11:23:43 -0400 (EDT)
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQcpuj04735; Fri, 16 May 1997 11:23:32 -0400 (EDT)
Message-Id: <QQcpuj04735.199705161523 at rodan.UU.NET>
To: alex.nishri at utoronto.ca
Cc: ietf at isi.edu
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: usa.net emulates AOL? (source routing)
References: <Pine.SUN.3.93.970516094121.8474B-100000 at gpu.utcc>
In-Reply-To: Your message of "Fri, 16 May 1997 09:48:12 EDT."
<Pine.SUN.3.93.970516094121.8474B-100000 at gpu.utcc>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 16 May 1997 11:23:32 -0400
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
> The fundamental issue is who sets & evolves Internet standards, large ISPs or
> the IETF? What if a bunch of ISPs decide to reject IPv4 packets next month?
I'm guessing that they'll lose a bunch of customers, and market forces will
have it's way with them.
While the IETF certainly has an obvious role in defining protocol standards
and the like, it's certainly not an enforcement body or police force. I don't
see that debate of a particular company's business decisions is a particular
relevent topic for the IETF mailing list. Hell, I don't believe that
all the random call-for-papers or non-IETF conference announcements are, either.
Perhaps COM-PRIV, NANOG or related mailing lists would be a more "appropriate"
venue for this type of discussion. It's unlikely to lower the S/N ratio
much more.
Louis Mamakos
Received: from ietf.org by ietf.org id aa13848; 16 May 97 12:00 EDT
Received: from socks2.raleigh.ibm.com by ietf.org id aa13725;
16 May 97 11:57 EDT
Received: from rtpmail03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0)
id AA22490; Fri, 16 May 1997 11:53:55 -0400
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123])
by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA35512;
Fri, 16 May 1997 11:53:54 -0400
Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
id AA19174; Fri, 16 May 1997 11:53:06 -0400
Message-Id: <9705161553.AA19174 at cichlid.raleigh.ibm.com>
To: ietf at ietf.org
Cc: namedroppers at internic.net
Subject: Re: Last Call: The Kitchen Sink Resource Record to Proposed Standard
Date: Fri, 16 May 1997 11:53:06 -0400
Sender:ietf-request at ietf.org
From: Thomas Narten <narten at raleigh.ibm.com>
Source-Info: From (or Sender) name not authenticated.
Folks,
Speaking as an individual, I have a question about the document
draft-eastlake-kitchen-sink-02.txt (and Standards Track protocols in
general) that I'd be interested in getting other folks opinions on.
The DNSIND working group has requested that this document be issued as
a Standards Track document. I've always had the notion that Standards
Track protocols were those that were somehow "good" (or at a minimum
"not bad") for the Internet. That is, the IETF thinks that a protocol
is a reasonable way to solve a particular problem, and that folks are
encouraged to implement and deploy the protocol.
With that in mind, the document's introduction says:
> New RRs that are reasonably spartan and designed with some care are
> periodically added via the IETF standards process as new needs become
> apparent. But there are periodically people who want to put some
> complex and frequently large structured data in the DNS. They
> usually come up with some kludge way of reinterpreting the TXT RR,
> since that is one of the least constrained RR. This is likely a bad
> idea since all previous kludge ways to reinterpreting the TXT RR have
> sunk without a trace. (Well, if they actually got an RFC out, it's
> still there, but, practically speaking, nobody actually uses it.)
>
> If a new type of data is really needed for common use in the DNS, the
> best course is to design a new RR that efficiently meets the need
> through the IETF standards process.
>
> People who want to shoe-horn bulky or complex and obscurely
> structured data into the DNS, which may not appropriate there, don't
> want to hear that. This draft defines an extremely general and
> flexible RR which can be pointed out to such people. It includes
> representations of OSI ASN.1, MIME, and, recursively, DNS RRs.
Summarizing, I interpret the document as saying: the right thing to do
when placing a new kind of data in the DNS is to define a new
RR. However, folks don't want to do the right thing, so here's a
standard "wrong way" for them to solve their problem.
The question I have is whether the IETF should be giving Standards
Track status to protocols that even a document itself suggests is not
really the right way to solve a problem? Should such documents be made
Experimental rather than Standards Track?
My question is motivated by what happens long term, when the document
proceeds further down the Standards track to Draft and Full
Standard. Will the community ever want this protocol to be a full
Internet Standard? If the answer is no, Standards Track seems totally
inappropriate, and the IETF should not suggest otherwise by allowing
it to enter the Standards Track in the first place. At the same time,
I've had private conversations that suggest elevating documents to
Proposed is not considered a big deal, and they can be nixed later if
necessary. Thus, now is not the time to worry about these sorts of
issues.
The underlying meta question concerns what criteria should be used for
deciding Experimental vs. Standards Track. For Standards Track,
scalability, does no harm, can be made secure, and solves an important
problem would seem to be minimal considerations. Are there others?
In the case of this particular protocol, there may be scalability
issues. For example, suppose that 10 different applications go off and
use SINK RRs to do their thing. When any one of those applications
queries the DNS, it will get back *all* SINK RRs for a given name,
even though it doesn't want but the one associated with *that*
service. But only the application knows which RR is useful to it, so
the DNS has to return the entire RRSet (if each service had its own RR
type, the problem wouldn't exist -- an application could ask for the
RR of the specific type it wants). Consequently, SINK RRs seem to have
negative scaling properties. Only a limited number of different services
can use a SINK RR, because the sum of the sizes of all SINK RRs for a
name needs to be bounded to fit in a DNS response. If this is the
case, should we advocate deployment of SINK RRs?
Comments?
Thomas
Received: from ietf.org by ietf.org id aa14647; 16 May 97 12:32 EDT
Received: from venera.isi.edu by ietf.org id aa14585; 16 May 97 12:30 EDT
Received: from fw.reyrey.com by venera.isi.edu (5.65c/5.61+local-27)
id <AA15612>; Fri, 16 May 1997 09:27:16 -0700
Received: by fw.reyrey.com; id MAA05852; Fri, 16 May 1997 12:18:49 -0400 (EDT)
Received: from unknown(168.207.1.211) by fw.reyrey.com via smap (3.2)
id xma005736; Fri, 16 May 97 12:18:23 -0400
Received: (from mailgate at localhost) by mailgate.reyrey.com (951211.SGI.8.6.12.PATCH1042/8.6.12) id MAA10812 for ietf at isi.edu; Fri, 16 May 1997 12:20:40 -0400
Received: by h-or06nt01.or06.reyrey.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
id <01BC61DA.740E99D0 at h-or06nt01.or06.reyrey.com>; Fri, 16 May 1997 09:20:53 -0700
Message-Id: <c=US%a=_%p=Reynolds_?_Reyno%l=H-OR06NT01-970516162051Z-8699 at h-or06nt01.or06.reyrey.com>
Sender:ietf-request at ietf.org
From: "Wheeler, Jesse W" <jesse_wheeler at reyrey.com>
To: "'alex.nishri at utoronto.ca'" <alex.nishri at utoronto.ca>
Cc: "'ietf at isi.edu'" <ietf at isi.edu>
Subject: RE: usa.net emulates AOL? (source routing)
Date: Fri, 16 May 1997 09:20:51 -0700
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I think it's a good idea to remember that standards (especially
when involving something as dynamic as the Internet) are not
always set "in stone". It's up to the ISP as a whole to decide
if they want to conform to to a standard. If they choose not to
conform the end result will ether be that they will loose business
due to the fact that they cannot offer a compatible service or
they cannot even integrate cutting edge features into there service.
There are a few examples of this:
o The v.34 standard issue with early modem vendors. Some companies
decided that they would rather adopt an early standard rather than
wait
for the ITU and IEEE to approve one. Lucent and USR Robotics are
following
this same path with there war w/ X2 and flex on the 56k modems.
o Microsoft and Netscape browser wars. Both browsers are supporting
different
HTML standards that they have both "created".
Competition is one thing.. Compatibility is another.. The end user will
eventually
win or loose in this war, by having a product/perhaprial that works with
others, or
by having a product that doesn't work with anything.
---------------------------------------------------
Jesse W. Wheeler
QA/DOC
Reynolds and Reynolds
HSD Portland Operations
--------------------------------------------------------------------
>----------
>From: Louis A. Mamakos[SMTP:louie at uu.net]
>Sent: Friday, May 16, 1997 9:07 AM
>To: alex.nishri at utoronto.ca
>Cc: ietf at isi.edu
>Subject: Re: usa.net emulates AOL? (source routing)
>
>> The fundamental issue is who sets & evolves Internet standards, large ISPs
>>or
>> the IETF? What if a bunch of ISPs decide to reject IPv4 packets next month?
>
>I'm guessing that they'll lose a bunch of customers, and market forces will
>have it's way with them.
>
>While the IETF certainly has an obvious role in defining protocol standards
>and the like, it's certainly not an enforcement body or police force. I
>don't
>see that debate of a particular company's business decisions is a particular
>relevent topic for the IETF mailing list. Hell, I don't believe that
>all the random call-for-papers or non-IETF conference announcements are,
>either.
>
>Perhaps COM-PRIV, NANOG or related mailing lists would be a more
>"appropriate"
>venue for this type of discussion. It's unlikely to lower the S/N ratio
>much more.
>
>Louis Mamakos
>
>
Received: from ietf.org by ietf.org id aa17798; 16 May 97 14:49 EDT
Received: from merit.edu by ietf.org id aa17667; 16 May 97 14:45 EDT
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-15.dialip.mich.net [141.211.7.183])
by merit.edu (8.8.5/8.8.5) with SMTP id OAA05362;
Fri, 16 May 1997 14:41:21 -0400 (EDT)
Date: Fri, 16 May 97 18:14:04 GMT
Sender:ietf-request at ietf.org
From: William Allen Simpson <wsimpson at greendragon.com>
Message-ID: <5882.wsimpson at greendragon.com>
To: ietf at ietf.org
cc: namedroppers at internic.net
Subject: Re: Last Call: The Kitchen Sink Resource Record to Proposed
Source-Info: From (or Sender) name not authenticated.
> From: Thomas Narten <narten at cichlid.raleigh.ibm.com>
> My question is motivated by what happens long term, when the document
> proceeds further down the Standards track to Draft and Full
> Standard. Will the community ever want this protocol to be a full
> Internet Standard? If the answer is no, Standards Track seems totally
> inappropriate, and the IETF should not suggest otherwise by allowing
> it to enter the Standards Track in the first place. At the same time,
> I've had private conversations that suggest elevating documents to
> Proposed is not considered a big deal, and they can be nixed later if
> necessary. Thus, now is not the time to worry about these sorts of
> issues.
>
I don't think that this can be "Standards Track", because it would be
difficult if not impossible to "advance" it. How do you test
interoperability with all possible formats?
What we did in PPP WG was to publish "Vendor Specific" extensions as an
"Informational" update to RFC-1661. That way, we have a place to point
them, but the understanding that interoperability is not expected.
Funny thing, when the sink draft came out, I though it was a candidate
for the April 1 RFC. Only later did I learn that it was serious.
It's reasonably written, and probably serves a purpose, so we should
advance it as something, but Standards Track seems inappropriate to me,
too. Experimental?
WSimpson at UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson at 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 aa18031; 16 May 97 14:58 EDT
Received: from venera.isi.edu by ietf.org id aa17962; 16 May 97 14:57 EDT
Received: from cesit1.unifi.it by venera.isi.edu (5.65c/5.61+local-27)
id <AA24063>; Fri, 16 May 1997 11:53:52 -0700
Received: from INGFI1.ING.UNIFI.IT by CESIT1.UNIFI.IT (PMDF V5.0-4 #3688)
id <01IIY8UYKAHS0007FG at CESIT1.UNIFI.IT> for ietf at isi.edu; Fri,
16 May 1997 20:52:10 +0100 (MET)
Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Fri,
16 May 1997 20:52:05 +0200 (MET-DST)
Received: from ozon180.cs.dsi by aguirre.ing.unifi.it (4.1/SMI-4.1)
id AA08257; Fri, 16 May 1997 20:51:59 +0200
Received: by ozon180.cs.dsi (5.0/SMI-SVR4) id AA09765; Fri,
16 May 1997 20:52:01 +0200
Date: Fri, 16 May 1997 20:52:01 +0200
Sender:ietf-request at ietf.org
From: csmr98 at aguirre.ing.unifi.it
Subject: CFPs: 2nd Euromicro Work.Conf. on Soft.Maint. & Reeng., Florence
To: ietf at isi.edu
Message-Id: <9705161852.AA09765 at ozon180.cs.dsi>
Content-Transfer-Encoding: 7BIT
Source-Info: From (or Sender) name not authenticated.
From: csmr98 at aguirre.ing.unifi.it
Dear colleague:
Here is the call for papers for the 2nd EUROMICRO WORKING CONFERENCE on
SOFTWARE MAINTENANCE AND REENGINEERING which will be help in Florence,
Italy, in March 1998. Please accept our apologies if you receive multiple
copies of this call.
Please post and/or forward to all interested colleagues.
Thank you,
--------------------------------------------------------------------------
Call for Papers
---------------
2nd EUROMICRO WORKING CONFERENCE on
SOFTWARE MAINTENANCE AND REENGINEERING
Florence, Italy -- March 9-11, 1998
The purpose of the working conference is to promote discussion and
interaction about a series of topics which are yet underrepresented. We are
particularly interested in exchanging concepts, prototypes, research ideas,
and other results which could contribute to the academic arena and also
benefit business and industrial community. Researcher, practitioners,
technology transition experts, project managers, developers and users of
tools, are all welcome.
Topics of interest include but are not restricted to: Maintenance and
Reengineering Tools (CARE-Tools), Reverse Engineering Tools, Support of
Reengineering Tasks by CASE-Tools, Software Reusability, Tele-Maintenance
(Concepts, Experiences, Use of New Technologies), Maintainability of
Programming Languages (e.g., OOPLs), Models and Methods for Error Prediction,
Measurement of Software Quality, Maintenance Metrics, Formal Methods,
Maintenance and Reengineering of KBS, Reengineering and Reverse Engineering
Concepts, Experiences from Redesign and Reengineering Projects, Millennium
Problem (Year 2000), Euro Problem, Organizational Framework and Models for
"RE"-Projects, Software Evolution, Migration and Maintenance Strategies,
Design for Maintenance, Preventive Maintenance, Personnel Aspects of
Maintenance (Motivation, Team building), Third Party Maintenance, Empirical
Results about the Maintenance Situation in Businesses, Version and
Configuration Management, Legal Aspects and Jurisdiction, Organization and
Management of Large Maintenance Projects, Software Offloading, Related Areas
such as Software Documentation.
Program Committee:
V.S. Alagar, USA; A. Ambriola, I; G. Bakker, NL; K. Bennett, UK; A.
Bertolino, I; F. Brito e Abreu, P; G. Bucci, I; M. Campanai, I; A.
Cimitile, I; I. Classen, D; L. da F. Costa, BR; J.A. de La Puente, S; A.
Fantechi, I; J.-L. Hainaut, B; J. Harauz, CA; B. Henderson-Sellers, AU;
M. Hinchey, USA; F. Lehner, D; E.-A. Karlsson, S; T.M. Khoshgoftaar,
USA; P. Laplante, USA; S. Liu, J; M. Loewe, D; M. Marchesi, I; T.J.
Marlowe, USA; E. Miller, USA; J.-M. Morel, F; D. Natale, I; P. Nesi, I;
S. Nocentini, I; M. Pezze`, I; P.T. Poon, USA; L. Richter, CH; D.
Rombach, D; G. Sechi, I; J. Sommerville, UK; A. Stoyen, USA; J.
Taramaa, SF; H. Toetenel, NL; G. Tsai, USA; Y. Yamaguchi, J;
SUBMISSIONS: There are two types of papers: full length papers (not
exceeding 4000 words in length and including a 150-200 word abstract) and
short papers (not exceeding 2000 words in length and including a 75-100 word
abstract). Authors are strongly encouraged to send a PostScript version of
their paper by anonymous ftp to ftp.dsi.unifi.it and put this file into the
directory pub/CSMR98/incoming (in order to avoid overwritings, the
PostScript file should be named:<author_surname.firstname.date_of_birth>.ps).
In addition, they should send by e-mail to CSMR98 at ozon180.ing.unifi.it the
title of the paper, full names, affiliations, postal and e-mail addresses of
all authors, fax and telephone numbers. Alternatively, the paper can be
sent by postal mail. In that case, five copies of all the above items
should be sent to a program chairman.
Proceeding will be published by IEEE Computer Society. Full papers
exceeding 8 pages (short papers 4 pages) will be charged for pages in
excess.For more information please contact the organization at the
addresses:
csmr98 at ozon180.ing.unifi.it
http://www.isst.fhg.de/csmr
http://www.dsi.unifi.it/~nesi/csmr98.html
The DEADLINE for submissions is Sept. 15, 1997. Authors will be notified
of acceptance by Nov.25, 1997. The camera ready version of the paper will
be required by Dec. 25, 1997. The following signed information should be
included in the submission: All necessary clearances have been obtained for
the publication of this paper. If accepted, the author(s) prepare the
camera-ready manuscript in time for inclusion in the proceedings, and will
personally present the paper at the working conference.
SPECIAL SESSIONS: Sessions of special interest proposed by delegates will be
welcome. Please send suggestions to a program chairman before the closing
date of submissions.
Program Chair: Paolo Nesi
Dip. Sistemi e Informatica, Universita' degli Studi di Firenze
Via S. Marta, 3, 50139 Firenze, Italy
Tel: +39-55-4796523 Fax: +39-55-4796363
email: nesi at ingfi1.ing.unifi.it
csmr98 at ozon180.ing.unifi.it
Program co-Chair: Franz Lehner
Institute for Business Informatics, University of Regensburg
Universitatsstr, 31, D-93040 REGENSBURG, Germany
Tel.: +49-941-943-2734 Fax: +49-941-943-4986
email:Franz.Lehner at wiwi.uni-regensburg.de
Organizing Chair: Alessandro Fantechi
Dip. di Sistemi e Informatica, Universita' degli Studi di Firenze
Via S. Marta, 3, 50139 Firenze, Italy
Tel: +39-55-4796265 Fax: +39-55-4796363
email: fantechi at dsi.dsi.unifi.it
Local Chair: Maurizio Campanai
CESVIT (High-Tech Agency), Fortezza da Basso
Viale F. Strozzi 1, 50129 Firenze, Italy
Tel: +39-55-4619154 Fax: +39-55-485345
email: campanai at cesvit.it
General information
The conference will take place at Palazzo degli Affari, in the center of
Florence. Enquiries about the working conference arrangements should be
directed to the organizing chairman or to the local chairman.
Preregistration is suggested for the authors.
--------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa18905; 16 May 97 15:35 EDT
Received: from callandor.cybercash.com by ietf.org id aa18846;
16 May 97 15:34 EDT
Received: by callandor.cybercash.com; id PAA18144; Fri, 16 May 1997 15:20:33 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma018125; Fri, 16 May 97 15:20:20 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA08533; Fri, 16 May 97 15:26:03 EDT
Date: Fri, 16 May 1997 15:26:02 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: RE: CFPs: 2nd Euromicro Work.Conf. on Soft.Maint. & Reeng.
Message-Id: <Pine.SUN.3.91.970516151528.7977A-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I would like Fred Baker or whoever is appropirate to make a clear
statement of the policy of the IETF mailing list for annoucements such as
that below. Italy is a nice country. Software maintenance is an
important topic. But how much does it have to do with the IETF?
Just to let you know, my personal opinion is that the utility of mailing
lists is greatly reduced when they are diluted by unsolicited mass email
advertisements of marginal relevance like that below. I believe the IETF
list should have a simple policy: Only announcements of IETF and ISOC
events. Period. We need a bright line that everyone knows about and can be
easily applied.
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at 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: Fri, 16 May 1997 20:52:01 +0200
From: csmr98 at aguirre.ing.unifi.it
To: ietf at isi.edu
Subject: CFPs: 2nd Euromicro Work.Conf. on Soft.Maint. & Reeng., Florence
From: csmr98 at aguirre.ing.unifi.it
Dear colleague:
Here is the call for papers for the 2nd EUROMICRO WORKING CONFERENCE on
SOFTWARE MAINTENANCE AND REENGINEERING which will be help in Florence,
Italy, in March 1998. Please accept our apologies if you receive multiple
copies of this call.
Please post and/or forward to all interested colleagues.
Thank you,
--------------------------------------------------------------------------
Call for Papers
---------------
2nd EUROMICRO WORKING CONFERENCE on
SOFTWARE MAINTENANCE AND REENGINEERING
Florence, Italy -- March 9-11, 1998
The purpose of the working conference is to promote discussion and
interaction about a series of topics which are yet underrepresented. We are
particularly interested in exchanging concepts, prototypes, research ideas,
and other results which could contribute to the academic arena and also
benefit business and industrial community. Researcher, practitioners,
technology transition experts, project managers, developers and users of
tools, are all welcome.
Topics of interest include but are not restricted to: Maintenance and
Reengineering Tools (CARE-Tools), Reverse Engineering Tools, Support of
Reengineering Tasks by CASE-Tools, Software Reusability, Tele-Maintenance
(Concepts, Experiences, Use of New Technologies), Maintainability of
Programming Languages (e.g., OOPLs), Models and Methods for Error Prediction,
Measurement of Software Quality, Maintenance Metrics, Formal Methods,
Maintenance and Reengineering of KBS, Reengineering and Reverse Engineering
Concepts, Experiences from Redesign and Reengineering Projects, Millennium
Problem (Year 2000), Euro Problem, Organizational Framework and Models for
"RE"-Projects, Software Evolution, Migration and Maintenance Strategies,
Design for Maintenance, Preventive Maintenance, Personnel Aspects of
Maintenance (Motivation, Team building), Third Party Maintenance, Empirical
Results about the Maintenance Situation in Businesses, Version and
Configuration Management, Legal Aspects and Jurisdiction, Organization and
Management of Large Maintenance Projects, Software Offloading, Related Areas
such as Software Documentation.
Program Committee:
V.S. Alagar, USA; A. Ambriola, I; G. Bakker, NL; K. Bennett, UK; A.
Bertolino, I; F. Brito e Abreu, P; G. Bucci, I; M. Campanai, I; A.
Cimitile, I; I. Classen, D; L. da F. Costa, BR; J.A. de La Puente, S; A.
Fantechi, I; J.-L. Hainaut, B; J. Harauz, CA; B. Henderson-Sellers, AU;
M. Hinchey, USA; F. Lehner, D; E.-A. Karlsson, S; T.M. Khoshgoftaar,
USA; P. Laplante, USA; S. Liu, J; M. Loewe, D; M. Marchesi, I; T.J.
Marlowe, USA; E. Miller, USA; J.-M. Morel, F; D. Natale, I; P. Nesi, I;
S. Nocentini, I; M. Pezze`, I; P.T. Poon, USA; L. Richter, CH; D.
Rombach, D; G. Sechi, I; J. Sommerville, UK; A. Stoyen, USA; J.
Taramaa, SF; H. Toetenel, NL; G. Tsai, USA; Y. Yamaguchi, J;
SUBMISSIONS: There are two types of papers: full length papers (not
exceeding 4000 words in length and including a 150-200 word abstract) and
short papers (not exceeding 2000 words in length and including a 75-100 word
abstract). Authors are strongly encouraged to send a PostScript version of
their paper by anonymous ftp to ftp.dsi.unifi.it and put this file into the
directory pub/CSMR98/incoming (in order to avoid overwritings, the
PostScript file should be named:<author_surname.firstname.date_of_birth>.ps).
In addition, they should send by e-mail to CSMR98 at ozon180.ing.unifi.it the
title of the paper, full names, affiliations, postal and e-mail addresses of
all authors, fax and telephone numbers. Alternatively, the paper can be
sent by postal mail. In that case, five copies of all the above items
should be sent to a program chairman.
Proceeding will be published by IEEE Computer Society. Full papers
exceeding 8 pages (short papers 4 pages) will be charged for pages in
excess.For more information please contact the organization at the
addresses:
csmr98 at ozon180.ing.unifi.it
http://www.isst.fhg.de/csmr
http://www.dsi.unifi.it/~nesi/csmr98.html
The DEADLINE for submissions is Sept. 15, 1997. Authors will be notified
of acceptance by Nov.25, 1997. The camera ready version of the paper will
be required by Dec. 25, 1997. The following signed information should be
included in the submission: All necessary clearances have been obtained for
the publication of this paper. If accepted, the author(s) prepare the
camera-ready manuscript in time for inclusion in the proceedings, and will
personally present the paper at the working conference.
SPECIAL SESSIONS: Sessions of special interest proposed by delegates will be
welcome. Please send suggestions to a program chairman before the closing
date of submissions.
Program Chair: Paolo Nesi
Dip. Sistemi e Informatica, Universita' degli Studi di Firenze
Via S. Marta, 3, 50139 Firenze, Italy
Tel: +39-55-4796523 Fax: +39-55-4796363
email: nesi at ingfi1.ing.unifi.it
csmr98 at ozon180.ing.unifi.it
Program co-Chair: Franz Lehner
Institute for Business Informatics, University of Regensburg
Universitatsstr, 31, D-93040 REGENSBURG, Germany
Tel.: +49-941-943-2734 Fax: +49-941-943-4986
email:Franz.Lehner at wiwi.uni-regensburg.de
Organizing Chair: Alessandro Fantechi
Dip. di Sistemi e Informatica, Universita' degli Studi di Firenze
Via S. Marta, 3, 50139 Firenze, Italy
Tel: +39-55-4796265 Fax: +39-55-4796363
email: fantechi at dsi.dsi.unifi.it
Local Chair: Maurizio Campanai
CESVIT (High-Tech Agency), Fortezza da Basso
Viale F. Strozzi 1, 50129 Firenze, Italy
Tel: +39-55-4619154 Fax: +39-55-485345
email: campanai at cesvit.it
General information
The conference will take place at Palazzo degli Affari, in the center of
Florence. Enquiries about the working conference arrangements should be
directed to the organizing chairman or to the local chairman.
Preregistration is suggested for the authors.
--------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa21433; 16 May 97 17:26 EDT
Received: from peridot.cisco.com by ietf.org id aa21255; 16 May 97 17:20 EDT
Received: from abierman-ss20 (abierman-ss20.cisco.com [171.69.197.254]) by peridot.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id OAA16469; Fri, 16 May 1997 14:13:23 -0700 (PDT)
X-Orig-Sender: abierman at cisco.com
Message-ID: <337CCDF3.5B18 at cisco.com>
Date: Fri, 16 May 1997 14:13:23 -0700
Sender:ietf-request at ietf.org
From: Andy Bierman <abierman at cisco.com>
Organization: Cisco Systems, Inc.
X-Mailer: Mozilla 3.0C-CISCOEN8 (X11; U; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
CC: ietf at ietf.org
Subject: Re: CFPs: 2nd Euromicro Work.Conf. on Soft.Maint. & Reeng.
References: <Pine.SUN.3.91.970516151528.7977A-100000 at cybercash.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake 3rd wrote:
>
> I would like Fred Baker or whoever is appropirate to make a clear
> statement of the policy of the IETF mailing list for annoucements such as
> that below. Italy is a nice country. Software maintenance is an
> important topic. But how much does it have to do with the IETF?
>
> Just to let you know, my personal opinion is that the utility of mailing
> lists is greatly reduced when they are diluted by unsolicited mass email
> advertisements of marginal relevance like that below. I believe the IETF
> list should have a simple policy: Only announcements of IETF and ISOC
> events. Period. We need a bright line that everyone knows about and can be
> easily applied.
>
I find it useful to get 'call for papers' type email sent to
ietf at ietf.org.
It should be limited to 1 copy, and related to networking, but not
limited to IETF activities. This isn't nearly as offensive as
the high-volume, WG-specific threads that show up on this mailing
list from time to time. You can monitor IETF-only events by
subscribing to ietf-announce at ietf.org.
> Donald
Andy
>...
> --------------------------------------------------------------------------
> Call for Papers
> ---------------
>
> 2nd EUROMICRO WORKING CONFERENCE on
> SOFTWARE MAINTENANCE AND REENGINEERING
> Florence, Italy -- March 9-11, 1998
> >....
Received: from ietf.org by ietf.org id aa21856; 16 May 97 17:52 EDT
Received: from atlas.xylogics.com by ietf.org id aa21797; 16 May 97 17:50 EDT
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 RAA08534; Fri, 16 May 1997 17:44:14 -0400 (EDT)
Received: by huey.xylogics.com id AA19832 (4.1/UK-doug-951219);
Fri, 16 May 97 17:44:13 EDT
Sender:ietf-request at ietf.org
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Fri, 16 May 97 17:44:13 EDT
Message-Id: <19832.9705162144 at huey.xylogics.com>
To: dee at cybercash.com
Cc: ietf at ietf.org
In-Reply-To: <Pine.SUN.3.91.970516151528.7977A-100000 at cybercash.com> (dee at cybercash.com)
Subject: RE: CFPs: 2nd Euromicro Work.Conf. on Soft.Maint. & Reeng.
Source-Info: From (or Sender) name not authenticated.
> Just to let you know, my personal opinion is that the utility of mailing
> lists is greatly reduced when they are diluted by unsolicited mass email
> advertisements of marginal relevance like that below.
I agree that mass unsolicited email is a blight on the existence on the
Internet. However, I do not think that announcements for networking
conferences are beyond the scope of the list. I have gone to several
that I learned about from the IETF list. There's much worse trash on
here from time to time.
--
Gary Malkin Cheap, Fast, Good
(508) 916-4237 Pick two!
Received: from ietf.org by ietf.org id aa25700; 16 May 97 22:05 EDT
Received: from pong3.pacific.net.sg by ietf.org id aa25571; 16 May 97 22:01 EDT
Received: from commando (dyn88ppp228.pacific.net.sg [210.24.88.228])
by pong3.pacific.net.sg with SMTP
id JAA26331; Sat, 17 May 1997 09:53:27 +0800 (SGT)
Message-ID: <337D1043.727E at usa.net>
Date: Sat, 17 May 1997 09:56:19 +0800
Sender:ietf-request at ietf.org
From: Darrell Heng <hkheng at usa.net>
Reply-To: hkheng at usa.net
Organization: Singapore
X-Mailer: Mozilla 3.01 (Win95; I)
MIME-Version: 1.0
To: William Allen Simpson <wsimpson at greendragon.com>
CC: ietf at ietf.org, namedroppers at internic.net
Subject: Re: Last Call: The Kitchen Sink Resource Record to Proposed
References: <5882.wsimpson at greendragon.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
William Allen Simpson wrote:
>
> > From: Thomas Narten <narten at cichlid.raleigh.ibm.com>
> > My question is motivated by what happens long term, when the document
> > proceeds further down the Standards track to Draft and Full
> > Standard. Will the community ever want this protocol to be a full
> > Internet Standard? If the answer is no, Standards Track seems totally
> > inappropriate, and the IETF should not suggest otherwise by allowing
> > it to enter the Standards Track in the first place. At the same time,
> > I've had private conversations that suggest elevating documents to
> > Proposed is not considered a big deal, and they can be nixed later if
> > necessary. Thus, now is not the time to worry about these sorts of
> > issues.
> >
> I don't think that this can be "Standards Track", because it would be
> difficult if not impossible to "advance" it. How do you test
> interoperability with all possible formats?
>
> What we did in PPP WG was to publish "Vendor Specific" extensions as an
> "Informational" update to RFC-1661. That way, we have a place to point
> them, but the understanding that interoperability is not expected.
>
> Funny thing, when the sink draft came out, I though it was a candidate
> for the April 1 RFC. Only later did I learn that it was serious.
>
> It's reasonably written, and probably serves a purpose, so we should
> advance it as something, but Standards Track seems inappropriate to me,
> too. Experimental?
>
> WSimpson at UMich.edu
> Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
> BSimpson at MorningStar.com
> Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
pls remove me from your mass mailing list, thanks. i did not subscribe
to this column in the first place.
thanks.
regards,
heng
Received: from ietf.org by ietf.org id aa25699; 16 May 97 22:05 EDT
Received: from pong3.pacific.net.sg by ietf.org id aa25620; 16 May 97 22:02 EDT
Received: from commando (dyn88ppp228.pacific.net.sg [210.24.88.228])
by pong3.pacific.net.sg with SMTP
id JAA26505; Sat, 17 May 1997 09:54:45 +0800 (SGT)
Message-ID: <337D1092.7577 at usa.net>
Date: Sat, 17 May 1997 09:57:38 +0800
Sender:ietf-request at ietf.org
From: Darrell Heng <hkheng at usa.net>
Reply-To: hkheng at usa.net
Organization: Singapore
X-Mailer: Mozilla 3.01 (Win95; I)
MIME-Version: 1.0
To: Thomas Narten <narten at raleigh.ibm.com>
CC: ietf at ietf.org, namedroppers at internic.net
Subject: Re: Last Call: The Kitchen Sink Resource Record to Proposed Standard
References: <9705161553.AA19174 at cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Thomas Narten wrote:
>
> Folks,
>
> Speaking as an individual, I have a question about the document
> draft-eastlake-kitchen-sink-02.txt (and Standards Track protocols in
> general) that I'd be interested in getting other folks opinions on.
>
> The DNSIND working group has requested that this document be issued as
> a Standards Track document. I've always had the notion that Standards
> Track protocols were those that were somehow "good" (or at a minimum
> "not bad") for the Internet. That is, the IETF thinks that a protocol
> is a reasonable way to solve a particular problem, and that folks are
> encouraged to implement and deploy the protocol.
>
> With that in mind, the document's introduction says:
>
> > New RRs that are reasonably spartan and designed with some care are
> > periodically added via the IETF standards process as new needs become
> > apparent. But there are periodically people who want to put some
> > complex and frequently large structured data in the DNS. They
> > usually come up with some kludge way of reinterpreting the TXT RR,
> > since that is one of the least constrained RR. This is likely a bad
> > idea since all previous kludge ways to reinterpreting the TXT RR have
> > sunk without a trace. (Well, if they actually got an RFC out, it's
> > still there, but, practically speaking, nobody actually uses it.)
> >
> > If a new type of data is really needed for common use in the DNS, the
> > best course is to design a new RR that efficiently meets the need
> > through the IETF standards process.
> >
> > People who want to shoe-horn bulky or complex and obscurely
> > structured data into the DNS, which may not appropriate there, don't
> > want to hear that. This draft defines an extremely general and
> > flexible RR which can be pointed out to such people. It includes
> > representations of OSI ASN.1, MIME, and, recursively, DNS RRs.
>
> Summarizing, I interpret the document as saying: the right thing to do
> when placing a new kind of data in the DNS is to define a new
> RR. However, folks don't want to do the right thing, so here's a
> standard "wrong way" for them to solve their problem.
>
> The question I have is whether the IETF should be giving Standards
> Track status to protocols that even a document itself suggests is not
> really the right way to solve a problem? Should such documents be made
> Experimental rather than Standards Track?
>
> My question is motivated by what happens long term, when the document
> proceeds further down the Standards track to Draft and Full
> Standard. Will the community ever want this protocol to be a full
> Internet Standard? If the answer is no, Standards Track seems totally
> inappropriate, and the IETF should not suggest otherwise by allowing
> it to enter the Standards Track in the first place. At the same time,
> I've had private conversations that suggest elevating documents to
> Proposed is not considered a big deal, and they can be nixed later if
> necessary. Thus, now is not the time to worry about these sorts of
> issues.
>
> The underlying meta question concerns what criteria should be used for
> deciding Experimental vs. Standards Track. For Standards Track,
> scalability, does no harm, can be made secure, and solves an important
> problem would seem to be minimal considerations. Are there others?
>
> In the case of this particular protocol, there may be scalability
> issues. For example, suppose that 10 different applications go off and
> use SINK RRs to do their thing. When any one of those applications
> queries the DNS, it will get back *all* SINK RRs for a given name,
> even though it doesn't want but the one associated with *that*
> service. But only the application knows which RR is useful to it, so
> the DNS has to return the entire RRSet (if each service had its own RR
> type, the problem wouldn't exist -- an application could ask for the
> RR of the specific type it wants). Consequently, SINK RRs seem to have
> negative scaling properties. Only a limited number of different services
> can use a SINK RR, because the sum of the sizes of all SINK RRs for a
> name needs to be bounded to fit in a DNS response. If this is the
> case, should we advocate deployment of SINK RRs?
>
> Comments?
>
> Thomas
pls remove me from your mass mailing list, thanks. i did not subscribe
to this particular column in the first place.
thanks, and happy surfing.
regards,
heng
Received: from ietf.org by ietf.org id aa28050; 19 May 97 10:05 EDT
Received: from ietf.ietf.org by ietf.org id aa27662; 19 May 97 9:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-fritsche-ipv6-multicast-00.txt
Date: Mon, 19 May 1997 09:45:49 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705190945.aa27662 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dynamical routing (unicast and multicast)
for the Ipv6 protocol
Author(s) : W. Fritsch
Filename : draft-fritsche-ipv6-multicast-00.txt
Pages : 4
Date : 05/16/1997
Future communication networks will be based more and more on a dynamically
changing network topology. Therefore it is advantageous, to have routing
mechanisms, which will dynamically adapt their routing decisions to these
topology changes. This document describes a set of network protocols,
which realize such a dynamical routing of unicast and multicast packets
within communication networks based on IPv6. All used routing algorithms
will be immediately executed at the occurrence of any topology changes and
will therefore have already complete routing information at the receipt of
data packets.
For the unicasting the Shortest Path First (SPF) routing algorithm has be
chosen. This algorithm calculates the shortest, and therefore the optimal
routing paths within the routing area, by which it is sufficient for a
router, to compute a single routing tree for the whole area.
For the multicasting the Minimum Spanning Tree (MST) routing algorithm has
been chosen. This distributed algorithm prevents the occurrence of endless
routing loops, offers for distributed Address Groups nearly optimal results
in saving network bandwidth, and needs also only a single routing tree
for the whole area.
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-fritsche-ipv6-multicast-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-fritsche-ipv6-multicast-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-fritsche-ipv6-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970516121002.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-fritsche-ipv6-multicast-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-fritsche-ipv6-multicast-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970516121002.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29771; 19 May 97 11:23 EDT
Received: from ietf.ietf.org by ietf.org id aa29650; 19 May 97 11:17 EDT
To: IETF-Announce: ;
cc: namedroppers at internic.net
Subject: Last Call: Classless IN-ADDR.ARPA delegation to BCP
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
reply-to: iesg at ietf.org
Date: Mon, 19 May 1997 11:17:06 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705191117.aa29650 at ietf.org>
This is a updated last call announcement. The previous version
contained an incorrect intended status.
===================================================
The IESG has received a request from the DNS IXFR, Notification, and
Dynamic Update Working Group to consider "Classless IN-ADDR.ARPA
delegation" <draft-ietf-dnsind-classless-inaddr-03.txt> for the status
of Best Current Practice.
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 at ietf.org or ietf at ietf.org mailing lists by May 29, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from cnri by ietf.org id aa20341; 20 May 97 0:09 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa00795;
20 May 97 0:09 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <CAA29052 at pad-thai.cam.ov.com>; Tue, 20 May 1997 02:11:56 GMT
Date: Mon, 19 May 1997 22:11:51 -0400
Message-Id: <199705200211.WAA03506 at rsts-11.mit.edu>
To: linn at cam.ov.com
Cc: Martin.Rex at sap-ag.de, linn at cam.ov.com, cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: <199705141430.KAA09435 at gza-client1.cam.ov.com> (message from John
Linn on Wed, 14 May 1997 10:30:52 -0400)
Subject: Re: RFC2078bis: draft actions and issues
From: tytso at mit.edu
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Wed, 14 May 1997 10:30:52 -0400
From: John Linn <linn at cam.ov.com>
>I had been asking for a slight change of gss_display_name():
>I would like to see a permission that a gssapi mechanism implementation
>may return GSS_C_NO_OID from gss_display_name() if (and only if)
>the given internal name was created via import_name() and GSS_C_NO_OID
>(to support layered multimechanisms).
At first thought, I could accept this restriction, given that
mechanisms would not be *required* to indicate GSS_C_NO_OID when
displaying a name imported with GSS_C_NO_OID and may instead normalize
such names to other of their supported types and display them using
those types. I'd like to hear others' opinions.
This is fine with me.
I'll take this as one vote for a statement within 2078bis that
requirements for support or non-support of particular name types are
not specified within 2078bis, which would be a clarifying change
relative to the present spec's silence on the question. I think this
wording would be preferable to stating "optional", since that might be
considered as conflicting with a mechanism spec's requiring support
for a specific type. What do others think?
I continue to be concerned about what this does to application
portability for implementations of protocols such as POP and FTP. One
can solve this problem by prompting the user for the GSSAPI target name
(or making it a command-line option, etc.), but this is extremely
inconvenient for the user. Still, it's the only portable thing that a
GSSAPI application can do, if it can't depend on the SERVICE at HOST
syntax.
The real question is who do you make responsible for mapping a particlar
service/host? Should each individual application have to do this, or do
we push this work down into GSSAPI library?
I'd just as soon make it the responsibility for the GSSPAI library, and
if some mechanism (such as SPKM) doesn't have a algorithmic mapping from
SERVICE at HOST.NAME to a mechanism-specific name, then the implementation
could have a lookup table/file/database, maintained by the system
administrator, which could be used to perform this mapping.
There will be quite a few internet applications for which relying on the
SERVICE at HOST.NAME will make life much easier for the application writer,
instead of forcing each application writer to roll their own translation
layer.
>Currently, the two *_UID_* nametypes are said to refer to uid_t
>(POSIX term) and therefore apply to POSIX systems only.
Should we remove the reference to uid_t from 2078bis, replacing it
with more generic wording there and deferring any reference to "uid_t"
to the C bindings?
Yes.
>I still am somewhat uncomfortable with description of GSS_C_NT_USER_NAME
>in RFC2078, where it says "Its interpretation is OS-specific". It should
>at least be changed to "may be OS-specific". In which respect is the
>interpretation of gss_import_name("ftp/somehost",GSS_C_NT_USER_NAME)
>guaranteed to be OS-specific (a) on Unix, (b) on MacIntosh...
>I assume that most gss-krb5-mech implementations of GSS_C_NT_USER_NAME
>are *NOT* OS-specific, i.e. don't do any OS-related checks of the supplied
>printable name.
I've no problem with downgrading to "may". Slightly more broadly,
perhaps we could replace the sentence with "Its syntax and
interpretation may be OS-specific." ??
Fine with me....
- Ted
Received: from ietf.org by ietf.org id aa22357; 20 May 97 2:49 EDT
Received: from cnri by ietf.org id aa22263; 20 May 97 2:42 EDT
Received: from [140.114.26.62] by CNRI.Reston.VA.US id aa02126;
20 May 97 2:42 EDT
Received: from fibonacci.ee.nthu.edu.tw (fibonacci.ee.nthu.edu.tw [140.114.26.61])
by euclid (8.8.4/8.8.4) with SMTP
id NAA05870; Tue, 20 May 1997 13:40:05 +0800 (CST)
Message-ID: <338139B7.4DD9 at ee.nthu.edu.tw>
Date: Tue, 20 May 1997 13:42:15 +0800
Sender:ietf-request at ietf.org
From: Chi-chao Chao <ccc at ee.nthu.edu.tw>
Reply-To: ccc at ee.nthu.edu.tw
Organization: National Tsing Hua University
X-Mailer: Mozilla 3.01Gold (Win95; I)
MIME-Version: 1.0
To: tccc at cs.umass.edu, osimcast at bbn.com, sc6wg4 at ntd.comsat.com,
xtp-relay at cs.concordia.ca, hipparch at sophia.inria.fr, reres at laas.fr,
prs at masi.ibp.fr, ieeetcpc at ccvm.sunysb.edu, comswtc at gmu.edu,
ctc-members at redbank.tinac.com, ieee_rtc_list at cs.tamu.edu,
enternet at bbn.com, cnom at maestro.bellcore.com,
gcomlist1 at manjaro.ece.iit.edu, comsoc.bog at tab.ieee.org,
sigmedia at bellcore.com, comsoc.tac at tab.ieee.org, comsoc-gicb at ieee.org,
commsoft at cc.bellcore.com, BM-List1 at cs.ucdavis.edu,
modern-heuristics at uk.ac.mailbase.ucdavis.edu,
cellular at dfv.rwth-aachen.edu, cost237-transport at comp.lancs.ac.uk,
testnet at canarie.ca, ietf at CNRI.Reston.VA.US, itc at fokus.gmd.de,
comsoc-tcii at ieee.com, dbworld at cs.wisc.edu, ifip-6-1 at labs-n.bbn.com
CC: ccc at ee.nthu.edu.tw
Subject: CFP: ISCOM'97
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
=========================================================================
Apology if you receive multiple copies of this email. Thank you for
your
attention.
=========================================================================
CALL FOR PAPERS
1997 International Symposium on Communications
December 17 -- 19, 1997, National Tsing Hua University, Hsinchu, Taiwan
The 1997 International Symposium on Communications (ISCOM-97) is the 4th
biennial symposium organized by the academic, research and industrial
societies in communications in Taiwan and will be held at National Tsing
Hua University, Hsinchu, Taiwan, from Wednesday December 17, 1997 to
Friday December 19, 1997. An exhibition will be organized for local
industrial companies and development/research institutes. Detailed
information on accommodations, travel arrangements, excursions and the
technical program will be included in subsequent mailings or can be
reached
via WWW at http://www.ee.nthu.edu.tw/~iscom97/. Papers presenting new
results in the following areas are solicited:
* Wireless Communications * Antenna and Propagation
* Optical Communications * EM Waves and Microwave
Engineering
* Satellite Communications * Audio/Video Processing
* Communication and Coding Theory * Statistical Signal Processing
* High Speed Networks * Communication ICs
* Communication Software * VLSI for Signal Processing
* Personal Communication Systems * Telecommunication Services and
* Network Security Management
Prospective authors are invited to submit 4 copies of extended abstracts
of
no more than 4 pages. All the manuscripts must be written in English in
single-spaced single column on white papers. The top of the first page
of
each paper should include a title, authors' names, affiliations,
addresses,
phone/fax numbers, and email addresses if applicable. The indicated
corresponding author will receive an acknowledgement of his/her
submission.
Camera-ready full papers of accepted manuscripts will be published in a
hard-bound proceeding and distributed in the symposium. The deadline
for
submission of all extended abstracts is June 1, 1997 with notification
of
acceptance by August 1, 1997. Submission of camera-ready papers is by
September 15, 1997. All submitted extended abstracts should be sent to
one of the following addresses:
For submission from Asia:
Professor Makoto Takizawa
Department of Computers and Systems Engineering
Tokyo Denki University
Ishizaka, Hatoyama, Saitama 350-03, Japan
Email: taki at takilab.k.dendai.ac.jp
Fax: +81 492 96 6185 (or 0501)
For submission from North America:
Dr. Jonathan L. Wang
Bell Communications Research
331 Newman Springs Road
Red Bank, NJ 07701, USA
Email: jwang at cc.bellcore.com
Fax: +1 908 758 4370
For submission from local and other areas:
Professor Chung-Chin Lu
Department of Electrical Engineering
National Tsing Hua University
Hsinchu 30043, Taiwan
Email: iscom97 at ee.nthu.edu.tw
Fax: +886 3 571 5971
ORGANIZATION OF ISCOM-97
Advisory Committee:
Horst Bessai, University of Siegen
Jin-Fu Chang, National Taiwan University
Chun-Hsiung Chen, National Taiwan University
Wen-Tsuen Chen, National Tsing Hua University
Steve Cheng, Computer and Communication Research Laboratory, ITRI
Byeong Gi Lee, Seoul National University
Lin-Shan lee, Academia Sinica
Shu Lin, University of Hawaii
Ming L. Liou, Hong Kong University of Science and Technology
Ching-Ling Liu, Chung Shan Institute of Science and Technology
Hideo Miyahara, Osaka University
Hikmet Sari, Alcatel Telspace
Tjeng T. Tjhung, National University of Singapore
Jin-Tu Wang, Chung Hua Telecommunication Laboratory
Che-Ho Wei, National Chiao Tung University
General Chairman:
Hsiao-Chuan Wang, National Tsing Hua University
Program Co-Chairmen:
Makoto Takizawa, Tokyo Denki University
Jonathan L. Wang, Bell Communications Research
Chung-Chin Lu, National Tsing Hua University
SPONSORS OF ISCOM-97
Ministry of Education, Taiwan, ROC
National Science Council, Taiwan, ROC
Directorate General of Telecommunication, MOTC, Taiwan, ROC
Chung Hua Telecommunication Company
Computer and Communinication Research Laboratory, ITRI
IEEE Taipei Section
Chinese Institute of Electrical Engineering
IMPORTANT DATES
Submission Due: June 1, 1997
Acceptance Notice Sent: August 1, 1997
Camera-ready Papers Due: September 15, 1997
Received: from ietf.org by ietf.org id aa29285; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28509; 20 May 97 9:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-kazu-pgpmime-multisig-00.txt
Date: Tue, 20 May 1997 09:45:20 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200945.aa28509 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Multi-signature Extensions for PGP/MIME
Author(s) : K. Yamamoto
Filename : draft-kazu-pgpmime-multisig-00.txt
Pages : 6
Date : 05/19/1997
PGP/MIME provides single signature service of PGP in the context of MIME,
however, multiple signature service is desired for usability and
flexibility. For this purpose, this memo defines "Multipart/PGP-Signature"
used as the "protocol" parameter and the content type of the second
part of "Multipart/Signed".
Canonical MIME format used in PGP/MIME is reasonable but it is
not enough for some kinds of MIME objects, particularly for ISO 2022 text.
Thus, this memo extends the "micalg" parameter syntax as
"pgp-<hash-symbol>+<canform-symbol>" so that <canform-symbol>
can specify more specific canonicalization for signature calculation.
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-kazu-pgpmime-multisig-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kazu-pgpmime-multisig-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-kazu-pgpmime-multisig-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519122221.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kazu-pgpmime-multisig-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kazu-pgpmime-multisig-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519122221.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29279; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28487; 20 May 97 9:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-kazu-jmsg-sign-secmime-00.txt
Date: Tue, 20 May 1997 09:45:15 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200945.aa28487 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Japanese Message Signing Procedure
with Security Multipart
Author(s) : K. Yamamoto
Filename : draft-kazu-jmsg-sign-secmime-00.txt
Pages : 8
Date : 05/19/1997
This memo defines a signing procedure for Japanese message in the context
of security multipart. The procedure guarantees signature validity even if
messages are processed through message transfer agents which carelessly
transform character set encodings.
To sign Japanese message digitally, local forms such as EUC/Japanese,
Shift-JIS, etc., are first converted into the transfer form, ISO-2022-JP
with an appropriate set of MIME headers. Then it is duplicated into two
objects. The first object is transformed into the signature form defined in
this memo and a detached digital signature is calculated over it. A
"Multipart/Signed" part is created with the second object and the detached
digital signature. Japanese text is verified as the signature form instead
of the transfer form.
To encrypt Japanese message, the transfer form, ISO-2022-JP with an
appropriate set of MIME headers, is used.
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-kazu-jmsg-sign-secmime-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kazu-jmsg-sign-secmime-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-kazu-jmsg-sign-secmime-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519121941.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kazu-jmsg-sign-secmime-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kazu-jmsg-sign-secmime-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519121941.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29280; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28623; 20 May 97 9:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-unicast-aggr-00.txt
Date: Tue, 20 May 1997 09:47:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200947.aa28623 at ietf.org>
--NextPart
A New 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 : An IPv6 Aggregatable Global Unicast Address Format
Author(s) : R. Hinden, M. O'Dell, S. Deering
Filename : draft-ietf-ipngwg-unicast-aggr-00.txt
Pages : 9
Date : 05/19/1997
This document defines an IPv6 aggregatable global unicast address format
for use in the Internet. The address format defined in this document is
consistent with the IPv6 Protocol [IPV6] and the "IPv6 Addressing
Architecture" [ARCH]. It is designed to facilitate scalable Internet
routing.
This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
Address Format". RFC 2073 will become historic.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
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-unicast-aggr-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-aggr-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519133343.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-unicast-aggr-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519133343.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29281; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28604; 20 May 97 9:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-dhcp-dns-04.txt
Date: Tue, 20 May 1997 09:47:35 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200947.aa28604 at 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 : Interaction between DHCP and DNS
Author(s) : Y. Rekhter
Filename : draft-ietf-dhc-dhcp-dns-04.txt
Pages : 8
Date : 05/19/1997
DHCP provides a powerful mechanism for IP host autoconfiguration.
However, the autoconfiguration provided by DHCP does not include
updating DNS, and specifically updating the name to address and
address to name mappings maintained by DNS.
This document specifies how DHCP clients and servers should use
the Dynamic DNS Updates mechanism to update the DNS name to address
and address to name mapping, so that the mappings for DHCP clients
would be consistent with the IP addresses that the clients
acquire via DHCP.
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-dns-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcp-dns-04.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519155954.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-dhcp-dns-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519155954.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29287; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28626; 20 May 97 9:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-petke-remote-pass-auth-00.txt
Date: Tue, 20 May 1997 09:47:39 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200947.aa28626 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Remote Passphrase Authentication
Author(s) : G. Brown
Filename : draft-petke-remote-pass-auth-00.txt
Pages : 40
Date : 05/19/1997
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 scheme was inspired by Dave Raggett's Mediated Digest Authentication,
draft-ietf-http-mda-00.txt.
This specification is divided into five parts. Part Zero contains an
extended introduction to the problem and potential solutions. Part One
explains the mechanism. Part Two explains how to incorporate the mechanism
into HTTP. Part Three explains the protocol between the service and deity.
Part Four explains the GSS-API token formats. Feel free to start with Part
One; Part Zero provides background information and is not a prerequisite
for Part One.
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-remote-pass-auth-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-petke-remote-pass-auth-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-petke-remote-pass-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519162025.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-petke-remote-pass-auth-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-petke-remote-pass-auth-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519162025.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29286; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28585; 20 May 97 9:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-earhart-ap-spec-00.txt
Date: Tue, 20 May 1997 09:47:32 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200947.aa28585 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : AP -- Access Protocol
Author(s) : R. Earhart
Filename : draft-earhart-ap-spec-00.txt
Pages : 20
Date : 05/19/1997
The Access Protocol defines a standard extensible framework upon which
application-specific protocols may be layered, providing a piece of
infrastructure for a common class of internet 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-earhart-ap-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-earhart-ap-spec-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-earhart-ap-spec-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519151024.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-earhart-ap-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-earhart-ap-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519151024.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29289; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28687; 20 May 97 9:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-gahrns-imap-mailbox-referral-00.txt
Date: Tue, 20 May 1997 09:47:46 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200947.aa28687 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP4 Mailbox Referrals
Author(s) : M. Gahrns
Filename : draft-gahrns-imap-mailbox-referral-00.txt
Pages : 9
Date : 05/19/1997
When dealing with large amounts of users, messages and geographically
dispersed IMAP4 [RFC-2060] servers, it is often desirable to distribute
messages amongst different servers within an organization. For example an
administrator may choose to store user's personal mailboxes on a local
IMAP4 server, while storing shared mailboxes remotely on another server.
This type of configuration is common when it is uneconomical to store all
data centrally due to limited bandwidth or disk resources.
Mailbox referrals allow clients to seamlessly access mailboxes that are
distributed across several IMAP4 servers.
A referral mechanism can provide efficiencies over the alternative
"proxy method", in which the local IMAP4 server contacts the
remote server on behalf of the client, and then transfers the data
from the remote server to itself, and then on to the client. The
referral mechanism's direct client connection to the remote
server is often a more efficient use of bandwidth, and does not
require the local server to impersonate the client when
authenticating to the remote 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-gahrns-imap-mailbox-referral-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-mailbox-referral-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-gahrns-imap-mailbox-referral-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519170018.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gahrns-imap-mailbox-referral-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gahrns-imap-mailbox-referral-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519170018.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29581; 20 May 97 10:03 EDT
Received: from ietf.ietf.org by ietf.org id aa29216; 20 May 97 9:57 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-almesberger-00.txt
Date: Tue, 20 May 1997 09:57:51 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200957.aa29216 at 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 : 05/19/1997
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: 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 at 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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519150400.I-D at 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: <19970519150400.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29290; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28776; 20 May 97 9:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
cc: ipsec at tis.com
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-simpson-esp-des3-x-01.txt
Date: Tue, 20 May 1997 09:48:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200948.aa28776 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The ESP Triple DES Transform
Author(s) : P. Karn, P. Metzger, W. Simpson
Filename : draft-simpson-esp-des3-x-01.txt
Pages : 14
Date : 05/19/1997
This document describes the "Triple" DES-EDE3-CBC security transform for
the IP Encapsulating Security Payload (ESP).
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-simpson-esp-des3-x-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des3-x-01.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-simpson-esp-des3-x-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519172020.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-simpson-esp-des3-x-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-simpson-esp-des3-x-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519172020.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29278; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28668; 20 May 97 9:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-gahrns-imap-login-referrals-00.txt
Date: Tue, 20 May 1997 09:47:42 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200947.aa28668 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP4 Login Referrals
Author(s) : M. Gahrns
Filename : draft-gahrns-imap-login-referrals-00.txt
Pages : 4
Date : 05/19/1997
When dealing with large amounts of users and many IMAP4 [RFC-2060] servers,
it is often necessary to move users from one IMAP4 server to another. For
example, hardware failures or organizational changes may dictate such a
move.
Login referrals allow clients to transparently connect to an
alternate IMAP4 server, if their home IMAP4 server has changed.
A referral mechanism can provide efficiencies over the alternative "proxy
method", in which the local IMAP4 server contacts the remote server on
behalf of the client, and then transfers the data from the remote server to
itself, and then on to the client. The referral mechanism's direct client
connection to the remote server is often a more efficient use of bandwidth,
and does not require the local server to impersonate the client when
authenticating to the remote 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-gahrns-imap-login-referrals-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-login-referrals-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-gahrns-imap-login-referrals-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519165624.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gahrns-imap-login-referrals-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gahrns-imap-login-referrals-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519165624.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29288; 20 May 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa28622; 20 May 97 9:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-multicast-assgn-02.txt
Date: Tue, 20 May 1997 09:47:29 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705200947.aa28622 at 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-02.txt
Pages : 9
Date : 05/19/1997
This document defines the initial assignment of IPv6 multicast addresses.
It is based on the "IP Version 6 Addressing Architecture" [ADDARCH] and
current IPv4 multicast address assignment found in
<ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>.
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519133845.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-multicast-assgn-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519133845.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29956; 21 May 97 9:32 EDT
Received: from ietf.ietf.org by ietf.org id aa29493; 21 May 97 9:22 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
cc: ipsec at tis.com
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-simpson-esp-des1-v2-00.txt
Date: Wed, 21 May 1997 09:22:46 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705210922.aa29493 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The ESP DES-CBC Transform
Author(s) : P. Karn, P. Metzger, W. Simpson
Filename : draft-simpson-esp-des1-v2-00.txt
Pages : 13
Date : 05/19/1997
This document describes the DES-CBC security transform for the IP
Encapsulating Security Payload (ESP).
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-simpson-esp-des1-v2-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des1-v2-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-simpson-esp-des1-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970519171713.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-simpson-esp-des1-v2-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-simpson-esp-des1-v2-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970519171713.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa00199; 21 May 97 9:37 EDT
Received: from palrel3.hp.com by CNRI.Reston.VA.US id aa06302;
21 May 97 9:37 EDT
Received: from hprnd.rose.hp.com (daemon at hprnd.rose.hp.com [15.29.43.139]) by palrel3.hp.com with ESMTP (8.7.5/8.7.3) id GAA28289; Wed, 21 May 1997 06:33:42 -0700 (PDT)
Received: from hp.com by hprnd.rose.hp.com with ESMTP
(1.37.109.20/15.5+ECS 3.3) id AA140701549; Wed, 21 May 1997 06:32:29 -0700
Received: from ietf.org by hp.com with SMTP
(1.37.109.16/15.5+ECS 3.3) id AA269841548; Wed, 21 May 1997 06:32:28 -0700
Received: from ietf.ietf.org by ietf.org id aa29434; 21 May 97 9:22 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Cc: vgmib at hprnd.rose.hp.com
From: Internet-Drafts at ietf.org
Reply-To: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-vgmib-repeater-dev-04.txt
Date: Wed, 21 May 1997 09:22:19 -0400
Sender: cclark at ietf.org
Message-Id: <9705210922.aa29434 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the 100VG-AnyLAN MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for
IEEE 802.12 Repeater Devices
Author(s) : J. Flick
Filename : draft-ietf-vgmib-repeater-dev-04.txt
Pages : 60
Date : 05/20/1997
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 network repeaters
based on IEEE 802.12.
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-vgmib-repeater-dev-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-vgmib-repeater-dev-04.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-vgmib-repeater-dev-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970520101334.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-vgmib-repeater-dev-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-vgmib-repeater-dev-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970520101334.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa04267; 21 May 97 11:23 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07883;
21 May 97 11:23 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <NAA20755 at pad-thai.cam.ov.com>; Wed, 21 May 1997 13:31:35 GMT
Message-Id: <199705211331.JAA20393 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: tytso at mit.edu
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: RFC2078bis: draft actions and issues
In-Reply-To: Your message of "Mon, 19 May 1997 22:11:51 EDT."
<199705200211.WAA03506 at rsts-11.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 21 May 1997 09:31:23 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Ted writes:
> I'll take this as one vote for a statement within 2078bis that
> requirements for support or non-support of particular name types are
> not specified within 2078bis, which would be a clarifying change
> relative to the present spec's silence on the question. I think this
> wording would be preferable to stating "optional", since that might be
> considered as conflicting with a mechanism spec's requiring support
> for a specific type. What do others think?
>
> I continue to be concerned about what this does to application
> portability for implementations of protocols such as POP and FTP. One
> can solve this problem by prompting the user for the GSSAPI target name
> (or making it a command-line option, etc.), but this is extremely
> inconvenient for the user. Still, it's the only portable thing that a
> GSSAPI application can do, if it can't depend on the SERVICE at HOST
> syntax.
>
> The real question is who do you make responsible for mapping a particlar
> service/host? Should each individual application have to do this, or do
> we push this work down into GSSAPI library?
>
> I'd just as soon make it the responsibility for the GSSPAI library, and
> if some mechanism (such as SPKM) doesn't have a algorithmic mapping from
> SERVICE at HOST.NAME to a mechanism-specific name, then the implementation
> could have a lookup table/file/database, maintained by the system
> administrator, which could be used to perform this mapping.
>
> There will be quite a few internet applications for which relying on the
> SERVICE at HOST.NAME will make life much easier for the application writer,
> instead of forcing each application writer to roll their own translation
> layer.
Any sentiment for, or opposition to, a statement within 2078bis recommending
to GSS-V2 mechanism designers that the host-based service name type be
supported in the interests of portability, while still deferring the
actual statement for a particular mechanism to that mechanism's spec?
--jl
Received: from cnri by ietf.org id aa09732; 21 May 97 14:10 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10018;
21 May 97 14:10 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <OAA25080 at pad-thai.cam.ov.com>; Wed, 21 May 1997 14:14:12 GMT
Message-Id: <199705211414.KAA20544 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: CAT-WG Last-Call: draft-ietf-cat-snego-05.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 21 May 1997 10:14:00 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT/Negotiation fanciers:
Thanks to Denis Pinkas for producing this revised negotiation mechanism
I-D. With this message, I'm placing snego-05 into a two-week WG Last-Call,
to extend through Wednesday, 4 June, anticipating a subsequent request
to the IESG on behalf of the WG that the document be considered for
advancement to Proposed Standard.
--jl
------- Forwarded Message
Received: from ietf.org (from ietf.org [132.151.1.19]) by pad-thai.cam.ov.com
(8.8.5/) with SMTP
id <NAA08854 at pad-thai.cam.ov.com>; Fri, 16 May 1997 13:28:48 GMT
Received: from ietf.org by ietf.org id aa09326; 16 May 97 9:25 EDT
Received: from ietf.ietf.org by ietf.org id aa09228; 16 May 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: cat-ietf at mit.edu
Sender: ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-cat-snego-05.txt
Date: Fri, 16 May 1997 09:25:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705160925.aa09228 at 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 Simple and Protected GSS-API Negotiation Mechanism
Author(s) : E. Baize, D. Pinkas
Filename : draft-ietf-cat-snego-05.txt
Pages : 14
Date : 05/15/1997
This draft document specifies a Security Negotiation Mechanism for the
Generic Security Service Application Program Interface (GSS-API) which is
described in [1].
The GSS-API provides a generic interface which can be layered
atop different security mechanisms such that if communicating peers
acquire GSS-API credentials for the same security mechanism,
then a security context may be established between them (subject
to policy). However, GSS-API doesn't prescribe the method by
which GSS-API peers can establish whether they have a common
security mechanism.
The Simple and Protected GSS-API Negotiation Mechanism defined here is a
pseudo-security mechanism, represented by the object identifier
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables
GSS-API peers to determine in-band whether their credentials share common
GSS-API security mechanism(s), and if so, to invoke normal security context
establishment for a selected common security mechanism. This is most useful
for applications that are based on GSS-API implementations which support
multiple security mechanisms.
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-snego-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-snego-05.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-snego-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970515141338.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-snego-05.txt
- --OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-snego-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970515141338.I-D at ietf.org>
- --OtherAccess--
- --NextPart--
------- End of Forwarded Message
Received: from ietf.org by ietf.org id aa10809; 21 May 97 14:40 EDT
Received: from zephyr.isi.edu by ietf.org id aa10355; 21 May 97 14:25 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24)
id <AA18219>; Wed, 21 May 1997 11:22:00 -0700
Message-Id: <199705211822.AA18219 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2144 on CAST-128 Encryption Algorithms
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 21 May 97 11:22:00 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2144:
Title: The CAST-128 Encryption Algorithm
Author: C. Adams
Date: May 1997
Mailbox: cadams at entrust.com
Pages: 15
Characters: 37532
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2144.txt
There is a need in the Internet community for an unencumbered
encryption algorithm with a range of key sizes that can provide
security for a variety of cryptographic applications and protocols.
This document describes an existing algorithm that can be used to
satisfy this requirement.
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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should be sent
to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at 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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <970521105909.RFC at ISI.EDU>
SEND /rfc/rfc2144.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2144.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970521105909.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa13142; 21 May 97 16:07 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11591;
21 May 97 16:07 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA23200 at pad-thai.cam.ov.com>; Wed, 21 May 1997 18:42:37 GMT
Message-Id: <F0C5060A8699D011A2B100805F14C869C04CA1 at RED-75-MSG.dns.microsoft.com>
From: "Mike Swift (NT)" <mikesw at microsoft.com>
To: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu
Subject: RE: CAT-WG Last-Call: draft-ietf-cat-snego-05.txt
Date: Wed, 21 May 1997 11:18:39 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Precedence: bulk
I have a couple of comments.
At the bottom of page three, the mechanism for determining which
mechanism to use is layed out:
The target selects the value according to a simpleselection
criteria: it checks if the first entry from its own list ispresent in
the set offered by the initiator. If the entry is present,then it is the
agreed mechanism, if not then the second entry from itsown ordered list
is checked and the process continues until allentries have been checked.
Thus, the target's mechanism preferenceshave precedence when more than
one common mechanism is availablebetween the target and initiator. The
service flags that are requested by the initiator are not taken into
consideration to make the selectionbut are used to select the
appropriate options, should these options be supported by the mechanism.
I don't think the draft should specify what policy is used when
determining the chosen mechanism. This doesn't affect the wire format of
the protocol and some implementations may wish to optimize the number of
round-trips by choosing the preferred mechanism of client. In addition,
the context flags should be usable in the determination of a mechanism
to use - if a caller specifies particular capabilities that the server's
preferred package doesn't support, then there may be no sense in going
to the work of establishing a context at all.
On page seven, where the context flags are defined, the flag "confFlag
(5)" should be added for confidentiality support. In addition, it should
be noted that these flags may be extended if the GSS context requirement
flags are extended
- Mike Swift
> -----Original Message-----
> From: John Linn [SMTP:linn at cam.ov.com]
> Sent: Wednesday, May 21, 1997 7:14 AM
> To: cat-ietf at MIT.EDU
> Cc: linn at cam.ov.com
> Subject: CAT-WG Last-Call: draft-ietf-cat-snego-05.txt
>
> CAT/Negotiation fanciers:
>
> Thanks to Denis Pinkas for producing this revised negotiation
> mechanism
> I-D. With this message, I'm placing snego-05 into a two-week WG
> Last-Call,
> to extend through Wednesday, 4 June, anticipating a subsequent request
> to the IESG on behalf of the WG that the document be considered for
> advancement to Proposed Standard.
>
> --jl
>
Received: from cnri by ietf.org id aa14769; 21 May 97 17:06 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12286;
21 May 97 17:06 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA26882 at pad-thai.cam.ov.com>; Wed, 21 May 1997 19:19:24 GMT
Message-Id: <199705211918.AA03020 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: RFC2078bis: draft actions and issues
To: John Linn <linn at cam.ov.com>, tytso at mit.edu
Date: Wed, 21 May 1997 15:17:53 -0400 (EDT)
Cc: cat-ietf at mit.edu
In-Reply-To: <199705211331.JAA20393 at gza-client1.cam.ov.com> from "John Linn" at May 21, 97 09:31:23 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Linn wrote:
> Theodore Ts'o wrote:
> > [...]
> >
> > There will be quite a few internet applications for which relying on the
> > SERVICE at HOST.NAME will make life much easier for the application writer,
> > instead of forcing each application writer to roll their own translation
> > layer.
IMHO, no resonable application should *RELY* on host-based service names.
Applications should, however, support them for user convenience, and
they might try them as a fallback default.
>
> Any sentiment for, or opposition to, a statement within 2078bis recommending
> to GSS-V2 mechanism designers that the host-based service name type be
> supported in the interests of portability, while still deferring the
> actual statement for a particular mechanism to that mechanism's spec?
A recommendation for host-based service names in 2078bis is fine
with me, but keep in mind that host-based service names alone are
definitely insufficient for portability.
It's ok for a portable implementation to try to derive the name from
the transport connection information, if the user doesn't supply
the target name seperately.
But due to the nature of (1) the given transport connection information,
(2) the given mechanism and the configuration/installation of the
(3) target and/or (4) local machine or software, it is very well possible
that neither (a) a name at all, nor (b) the correct name can be derived.
A portable application *MUST* be prepared to handle this situation;
it *MUST* accept a explicit target name and it *MUST* ask the user to
supply (the correct) one if any preconfigured or algorithmic target
name selection/transformation fails. This is especially necessary
for (2) and (3), where even administrative skill and power might be
insufficient to make a given name translation machinery work.
There is a possible nightmare for novice administrators in the
commercial environment when the automatic or (pre-)configured
transformation of a host-based service name into some kind of
"principal name" involves under-cover operations like DNS-canonicalization,
since the user database and the DNS are by no means synchronized
and there may be some old/outdated/interfering information in the
local hosts file. I have seen this happening to a Kerberos+Unix wizard! ;-)
I do even feel slightly uncomfortable with term "host-based service name".
The internet has evolved beyond using hostnames for connection
establishment or target selection for quite a while already,
so this apparently self-explaining term might be misleading, because
it is based on the relation of hostname<->destination address from
the past instead of the present and future.
The information that is given to an IP protocol stack to open
a connection is an IP address an a port number. How these two
parameters are derived from user input has been changing over time.
The current practice in the internet is to use abstract service names
for the target, *NOT* hostnames. They just look like hostnames or
aliases, because that's what is available in existing name-resolvers
(i.e. A and CNAME records in DNS, hostname and aliases in /etc/hosts ...).
Many administrators set up services aliases like "www.company.com"
"ftp.university.edu" and map them to a specific hostname (CNAME) or
directly to an IP-Address of some host. Some even map it
to multiple IP-Addresses of different hosts and hand them
out in round-robin for load-balancing between hosts.
This is not future, this is present and past, and the last one is
an example that Kerberos cannot really handle so far.
The only translation of hostnames that DNS does *MOST* of the time
(not always) is into IP-Addresses. Translation into a "canonical hostname"
frequently fails (btw. it isn't required to work). Translation
from IP-Address back into a hostname also fails quite often. Where it
actually works, it doesn't always (and needn't) relate to the forward mapping.
Example:
Published name: www.hilton.com
A-Record in DNS for www.hilton.com: (21-May-97) 139.61.7.12
canonical DNS name for www.hilton.com: (21-May-97) www.hilton.com
reverse mapping of 139.61.7.21: (21-May-97) fails
Hostname of machine www: (21-May-97) wwwhilt
canonical DNS name for wwwhilt.hilton.com: (21-May-97) wwwhilt.hilton.com
A-Record in DNS for wwwhilt.hilton.com: (21-May-97) 139.61.7.21
(no answer to internet)
Not really related to GSS-API: the Server Certificate of
https://www.hilton.com contains the "service entry" www.hilton.com,
not the wwwhilt.hilton.com.
btw. they changed the IP-Address of their local nameserver
but didn't synchronize the IP-Address change with their parent
domain (yet), so the NS glue record in their parent domain is wrong.
Finally, I do want to retain the notion of a "generic" security service
API, not an "Hostname-requiring" one, especially when "hostname"
becomes arbitrarily fuzzy by things like a DNS-canonicalization.
-Martin
Received: from cnri by ietf.org id aa16648; 21 May 97 18:50 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13554;
21 May 97 18:50 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <VAA11773 at pad-thai.cam.ov.com>; Wed, 21 May 1997 21:47:16 GMT
Date: Wed, 21 May 1997 17:47:03 -0400
Message-Id: <9705212147.AA27772 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Marc Horowitz <marc at cygnus.com>
Cc: Martin.Rex at sap-ag.de, linn at cam.ov.com, cat-ietf at mit.edu
In-Reply-To: Marc Horowitz's message of 21 May 1997 17:09:13 -0400,
<t53k9ksedmu.fsf at rover.cygnus.com>
Subject: Re: RFC2078bis: draft actions and issues
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
I agree with Marc's comments, especially the one about applications
being able to accept an explicit target name type as well as explicit
target name. There should reasonable defaults using the host-based
service name type in the absense of user-specified overrides (or
appropriate configuration information in a file or registry) as well,
IMHO.
- Ted
Received: from cnri by ietf.org id aa17299; 21 May 97 19:39 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14099;
21 May 97 19:39 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <VAA08004 at pad-thai.cam.ov.com>; Wed, 21 May 1997 21:09:38 GMT
To: Martin.Rex at sap-ag.de
Cc: John Linn <linn at cam.ov.com>, tytso at mit.edu, cat-ietf at mit.edu
Subject: Re: RFC2078bis: draft actions and issues
References: <199705211918.AA03020 at sap-ag.de>
From: Marc Horowitz <marc at cygnus.com>
Date: 21 May 1997 17:09:13 -0400
In-Reply-To: Martin Rex's message of Wed, 21 May 1997 15:17:53 -0400 (EDT)
Message-Id: <t53k9ksedmu.fsf at rover.cygnus.com>
Lines: 33
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Martin Rex <martin.rex at sap-ag.de> writes:
>> But due to the nature of (1) the given transport connection information,
>> (2) the given mechanism and the configuration/installation of the
>> (3) target and/or (4) local machine or software, it is very well possible
>> that neither (a) a name at all, nor (b) the correct name can be derived.
>> A portable application *MUST* be prepared to handle this situation;
>> it *MUST* accept a explicit target name and it *MUST* ask the user to
>> supply (the correct) one if any preconfigured or algorithmic target
>> name selection/transformation fails. This is especially necessary
>> for (2) and (3), where even administrative skill and power might be
>> insufficient to make a given name translation machinery work.
1) I don't believe that a user should ever be *prompted* for this
sort of information. It doesn't work, and it annoys the user :-)
Having a dialog box, command line flag, or environment variable is
reasonable.
2) It depends on the protocol. For instance, ftpsec requires that
the host-based service name type be used. Since ftp is an internet
host-based service (sooner or later, you open up a TCP connection,
QED), this is reasonable, too. You can make DNS arguments, but the
reality of the Internet is that if DNS is broken, *lots* of things
don't work right. After routing, DNS is probably the most important
service to the smooth running of the Internet.
3) The application must also be prepared to accept an explict target
name*type* as well as an explicit target name. This goes along with
my believe that importing a name with GSS_C_NO_OID as the nametype is
practically useless, although I'm not going to block consensus over
it.
Marc
Received: from cnri by ietf.org id aa17451; 21 May 97 19:50 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14188;
21 May 97 19:50 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA15108 at pad-thai.cam.ov.com>; Wed, 21 May 1997 22:21:08 GMT
Message-Id: <199705212221.AA03613 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: target name discovery
Orig-To: cat-ietf at mit.edu
To: cat-ietf at mit.edu
Date: Wed, 21 May 1997 18:19:23 -0400 (EDT)
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
I am short of implementing target name discovery and have noticed
that there are some problems. Currently I am implementing the
"default acceptor credential selection" accompanying the initial
context establishment token (at the application layer).
When the local gssapi mechanism successfully accepts a user-supplied
printable name as a target, then there is absolutely no guarantee
that the same printable name will be accepted at the acceptor side.
On top of that: what is "the same printable name" in the face of
locale differences, codepage differences (like EBCDIC-evils) and
local gssapi configuration files/attributes that influence the name
canonicalization. Dealing with codepages or Unicode cross-plattform
is non-trivial, especially when you are not really supposed to make
assumptions about "printable information".
The only "portable" name representation available to the application
seems to be the new v2 exported_name. It is supposed to be portable
within the same mechanism. Unfortunately I don't see how this could
work *with* snego (although I plan to always ask for specific mechanisms,
ignoring snego where available).
-Martin
Received: from cnri by ietf.org id aa18012; 21 May 97 20:33 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14537;
21 May 97 20:33 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <VAA10918 at pad-thai.cam.ov.com>; Wed, 21 May 1997 21:39:21 GMT
Message-Id: <199705212139.AA26996 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: RFC2078bis: draft actions and issues
Orig-To: marc at cygnus.com (Marc Horowitz)
To: tytso at mit.edu, linn at cam.ov.com, cat-ietf at mit.edu
Date: Wed, 21 May 1997 17:36:49 -0400 (EDT)
In-Reply-To: <t53k9ksedmu.fsf at rover.cygnus.com> from "Marc Horowitz" at May 21, 97 05:09:13 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Marc Horowitz wrote:
>
> Martin Rex <martin.rex at sap-ag.de> writes:
>
> >> But due to the nature of (1) the given transport connection information,
> >> (2) the given mechanism and the configuration/installation of the
> >> (3) target and/or (4) local machine or software, it is very well possible
> >> that neither (a) a name at all, nor (b) the correct name can be derived.
> >> A portable application *MUST* be prepared to handle this situation;
> >> it *MUST* accept a explicit target name and it *MUST* ask the user to
> >> supply (the correct) one if any preconfigured or algorithmic target
> >> name selection/transformation fails. This is especially necessary
> >> for (2) and (3), where even administrative skill and power might be
> >> insufficient to make a given name translation machinery work.
>
> 1) I don't believe that a user should ever be *prompted* for this
> sort of information. It doesn't work, and it annoys the user :-)
> Having a dialog box, command line flag, or environment variable is
> reasonable.
I think this depends on the application.
But if the application aborts, it is a good idea to point out to
the user possible ways to work around the problem, including how
to supply a target name seperately.
Another possibility might be for the application layer protocol
to implement a "knock-knock who are you?" protocol to find out
the target name, and then have the user confirm if he wants to
try that name instead.
>
> 2) It depends on the protocol. For instance, ftpsec requires that
> the host-based service name type be used. Since ftp is an internet
> host-based service (sooner or later, you open up a TCP connection,
> QED), this is reasonable, too. You can make DNS arguments, but the
> reality of the Internet is that if DNS is broken, *lots* of things
> don't work right. After routing, DNS is probably the most important
> service to the smooth running of the Internet.
Agreed. Your requirement seems acceptable for ftpsec.
>
> 3) The application must also be prepared to accept an explict target
> name*type* as well as an explicit target name. This goes along with
> my believe that importing a name with GSS_C_NO_OID as the nametype is
> practically useless, although I'm not going to block consensus over
> it.
Although a target name discovery as outlined above may be harder to
implement, it will be *MUCH* easier to sell to your customer.
In my implementation I only support compiled in nametypes,
which have to be prefixed to the actual target name as <Letter>+':'
where Letter := ( u | s | p )
u=GSS_C_NT_USER_NAME, s=GSS_C_NT_HOSTBASED_SERVICE and
p=<explicit mechanism-dependent OID; functionally equiv. to GSS_C_NO_OID>
-Martin
Received: from cnri by ietf.org id aa18156; 21 May 97 20:44 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14661;
21 May 97 20:44 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA06591 at pad-thai.cam.ov.com>; Wed, 21 May 1997 20:55:22 GMT
Message-Id: <199705212054.AA19114 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: CAT-WG Last-Call: draft-ietf-cat-snego-05.txt
To: Mike Swift <mikesw at microsoft.com>, linn at cam.ov.com
Date: Wed, 21 May 1997 16:25:44 -0400 (EDT)
Cc: cat-ietf at mit.edu
In-Reply-To: <F0C5060A8699D011A2B100805F14C869C04CA1 at RED-75-MSG.dns.microsoft.com> from "Mike Swift" at May 21, 97 11:18:39 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Mike Swift wrote:
>
> I have a couple of comments.
> At the bottom of page three, the mechanism for determining which
> mechanism to use is layed out:
> The target selects the value according to a simpleselection
> criteria: it checks if the first entry from its own list ispresent in
> the set offered by the initiator. If the entry is present,then it is the
> agreed mechanism, if not then the second entry from itsown ordered list
> is checked and the process continues until allentries have been checked.
> Thus, the target's mechanism preferenceshave precedence when more than
> one common mechanism is availablebetween the target and initiator. The
> service flags that are requested by the initiator are not taken into
> consideration to make the selectionbut are used to select the
> appropriate options, should these options be supported by the mechanism.
>
> I don't think the draft should specify what policy is used when
> determining the chosen mechanism. This doesn't affect the wire format of
> the protocol and some implementations may wish to optimize the number of
> round-trips by choosing the preferred mechanism of client. In addition,
> the context flags should be usable in the determination of a mechanism
> to use - if a caller specifies particular capabilities that the server's
> preferred package doesn't support, then there may be no sense in going
> to the work of establishing a context at all.
>
> On page seven, where the context flags are defined, the flag "confFlag
> (5)" should be added for confidentiality support. In addition, it should
> be noted that these flags may be extended if the GSS context requirement
> flags are extended
That's actually interesting. I agree with Mike Swift that the context
attribute handling defined for base GSS-API doesn't scale/fit for
the negotiation mechanism.
The flags listed in snego are those features that can be "requested"
via gss_init_sec_context() (as documented in RFC2078 2.2.1).
confFlag is a features that can be returned, but not requested.
As documented, all of the flag input values are "feature request"
that may or may not be granted/provided. Absence of a requested
feature will not abort a context establishment. A initiator or
acceptor that is uncomfortable with the resulting features from
a context establishment is supposed to abort and delete the
context. This may result in unecessary overhead when the interoperable
intersection of features provided by the client's and server's
mechanism doesn't meet either one's requirements, but was still
considered acceptable. For a negotiation mechanism, when
(either or both) mechanism preference lists outweigh the requested
feature flags, this might actually prevent successful context
establishment.
I have the feeling that it should be possible for the negotiation
mechanism to specify which context feature flags are considered
a requirement by both initiator and acceptor, and the required features
should precede the preference list.
Off-hand, I don't have an idea how to:
- distinuish "required" from "nice-to-have" context features,
i.e. declare a feature "required"
- request "integrity" and "confidentiality"
but I think this would be very, very valuable.
Since snego uses the regualar GSS-API calls, an extensions may
have to be folded into v2 as well?!
-Martin
Received: from cnri by ietf.org id aa01127; 22 May 97 5:16 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03563;
22 May 97 5:16 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <HAA04382 at pad-thai.cam.ov.com>; Thu, 22 May 1997 07:08:34 GMT
Message-Id: <33846F3F.65C5 at frcl.bull.fr>
Date: Thu, 22 May 1997 09:07:27 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: CAT-IETF WG <cat-ietf at mit.edu>
Cc: John Linn <linn at cam.ov.com>
Subject: Re: CAT-WG Last-Call: draft-ietf-cat-snego-05.txt
References: <199705211414.KAA20544 at gza-client1.cam.ov.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
CAT/Negotiation fanciers:
Before leaving my office least week, I (unsucessfully) sent two messages
to indicate the major changes I made in SPNEGO. Unfortunately two empty
messages went out.
I addressed the two sets of comments received from Mike Swift and John
Linn.
The major changes are:
1) The addition of ContextFlags in NegTokenInit with :
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
2) The addition of negResult in NegTokenTarg with:
negResult [0] ENUMERATED {
accept_completed (0),
accept_incomplete (1),
reject (2) }
The later allows to address the tricky case mentionned by John.
Denis.
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa05582; 22 May 97 9:42 EDT
Received: from ietf.ietf.org by ietf.org id aa05352; 22 May 97 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-kane-00.txt
Date: Thu, 22 May 1997 09:35:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705220935.aa05352 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : VLS Protocol Specification
Author(s) : L. Kane, K. Dobbins, R. Soczewinksi
Filename : draft-rfced-info-kane-00.txt
Pages : 92
Date : 05/21/1997
The Virtual LAN Link State Protocol (VLSP) is part of the
InterSwitch Message Protocol (ISMP). ISMP was designed to
facilitate interswitch communication within distributed determine
and maintain a fully connected mesh topology graph of the
switch fabric. Each switch maintains an identical database
describing the topology. Call-originating switches use
the topology database to determine the path over which
to route a call connection.
VLSP provides support for equal-cost multipath routing, and
recalculates routes quickly in the face of topological changes,
utilizing a minimum of routing protocol traffic.
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-kane-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-kane-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-kane-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970521111510.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-kane-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-kane-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970521111510.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05584; 22 May 97 9:42 EDT
Received: from ietf.ietf.org by ietf.org id aa05208; 22 May 97 9:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-tls at consensus.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-tls-protocol-03.txt
Date: Thu, 22 May 1997 09:31:02 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705220931.aa05208 at ietf.org>
--NextPart
A Revised 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.
Note: This revision reflects comments received during the last call period.
Title : The TLS Protocol Version 1.0
Author(s) : T. Dierks, C. Allen
Filename : draft-ietf-tls-protocol-03.txt
Pages : 70
Date : 05/21/1997
This document specifies Version 1.0 of the Transport Layer Security (TLS)
protocol, which is at this stage is strictly based on the Secure Sockets
Layer (SSL) version 3.0 protocol, and is to serve as a basis for future
discussions. The TLS protocol 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-ietf-tls-protocol-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tls-protocol-03.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tls-protocol-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970521163139.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-tls-protocol-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tls-protocol-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970521163139.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05583; 22 May 97 9:42 EDT
Received: from ietf.ietf.org by ietf.org id aa05226; 22 May 97 9:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-bcast-02.txt
Date: Thu, 22 May 1997 09:31:08 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705220931.aa05226 at 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.
Note: This revision reflects comments received during the last call period.
Title : IP Broadcast over ATM Networks
Author(s) : T. Smith, G. Armitage
Filename : draft-ietf-ion-bcast-02.txt
Pages : 14
Date : 05/21/1997
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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-bcast-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-bcast-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970521164318.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-bcast-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-bcast-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970521164318.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa10291; 22 May 97 12:26 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08811;
22 May 97 12:26 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <OAA14324 at pad-thai.cam.ov.com>; Thu, 22 May 1997 14:18:20 GMT
Message-Id: <3.0.1.16.19970522101655.2dbff454 at world.std.com>
X-Sender: dpj at world.std.com
X-Mailer: Windows Eudora Light Version 3.0.1 (16)
Date: Thu, 22 May 1997 10:16:55 -0400
To: cat-ietf at mit.edu
From: "David P. Jablon" <dpj at world.std.com>
Subject: Re: open issues on pk-init
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
Brian raised some interesting issues in "Open items on pk-init".
I was dismayed to see the removal of the encrypted Diffie-Hellman
approach for private key retrieval in pk-init-03. When it was
added in -02, I thought it was a step in the right direction.
One of the general benefits of many forms of public-key methods
is to remove opportunities for network dictionary attack
on a password.
>2. Due to an editorial oversight, the private key retrieval request
> defined in Section 3.4 is defined as being sent in the clear. It
> should instead be encrypted using the user's long term key (the
> same one being used in the main authentication).
>
> The response should also be encrypted; the problem that arises there
> is where the key used to encrypt the response would come from. The
> easiest method is to use the same encryption key as is used for the
> main authentication. This means, however, that the private key
> preauth is still susceptible to dictionary attacks.
>
> This appears to be a problem with any approach (aside from
> bootstrapping an encryption key with something like SPEKE). The
> only solution apparent at present that doesn't suffer from the
> performance hits of SPEKE is simply to institute a strong password
> policy.
This points out that there's no free lunch. It appears that you have
to do something with a PK operation to prevent the dictionary
attacks, whether its a signature, a sealed message, or a
password-authenticated DH exchange like SPEKE or DH-EKE.
I haven't seen open discussion of "performance hits" for any of
these approaches on this list.
>[...]
>7. The language in referring to the "Digital Signature" option is
> deprecatory.
>
> My personal opinion is that it *ought* to be deprecatory. As
> mentioned in the draft, this option requires the client to generate
> a random key, which we don't like nearly as much as the KDC making
> up a random key. Thus, the option might be used primarily as a
> fallback when the standard pk-init exchange is infeasible.
>[...]
Hopefully, clients with strong random number generation capability
will become the norm. As long as warning language clearly
indicates that a lack of such capability is the reason for concern,
it seems appropriate.
-- David
------------------------------------
David P. Jablon
Tel: +1 508 898 9024
http://world.std.com/~dpj/
E-mail: dpj at world.std.com
Received: from cnri by ietf.org id aa17869; 22 May 97 18:14 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa13299; 22 May 97 18:14 EDT
Received: from ietf.org by ietf.org id aa17860; 22 May 97 18:14 EDT
Received: from odb.rhein-main.de by ietf.org id aa17846; 22 May 97 18:14 EDT
Received: from in.rhein-main.de by odb.rhein-main.de with cbsmtp
(Smail3.2 #2) id m0wUg3w-0007SOC; Fri, 23 May 1997 00:10:20 +0200 (MET DST)
Received: by incom.rhein-main.de (Smail3.1.29.1 #2)
id m0wUeya-0005nMC; Thu, 22 May 97 22:00 MET
Message-Id: <m0wUeya-0005nMC at incom.rhein-main.de>
Sender:iesg-request at ietf.org
From: Winfried Koenig <win at in.rhein-main.de>
Subject: Classless IN-ADDR.ARPA delegation
To: iesg at ietf.org, ietf at ietf.org
Date: Thu, 22 May 1997 22:00:43 +0100 (MET)
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1194
Sorry, I hope draft-ietf-dnsind-classless-inaddr-03.txt
is not the final version. In the spirit of the Robustness
Principle: "Be liberal in what you accept, and conservative
in what you send" I recomment to replace the '/' characters
in the zone names of the draft by one of the characters
'a' .. 'z# or '-'.
The reason is, there are a lot of programs and scripts for
DNS support and some of these will break with the character
'/' in zone names. Zone names are often used to generate
Filenames and the '/' character is used as Unix directory
delimiter. ...
An other broken tool is the program "host" from the version
4.9.5-P1 of the bind distribution. Compiled with gcc on
solaris 2.4 or 2.5 it can't resolve the address 195.88.2.129.
$ host 195.88.2.129
Host not found, try again.
but there is no problem with the address 195.88.2.133.
$ host 195.88.2.133
Name: inaddr-test133.ipf.de
Address: 195.88.2.133
Aliases:
For the first address you have to lookup in the zone
128/30.2.88.195.IN-ADDR.ARPA. The other address uses
132-30.2.88.195.IN-ADDR.ARPA.
--
Winfried Koenig, Arendsstrasse 12, D-63075 Offenbach
Phone: +49 69 868707, Mail: <win at in.rhein-main.de>
Received: from cnri by ietf.org id aa02959; 23 May 97 5:24 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03623;
23 May 97 5:24 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <HAA24767 at pad-thai.cam.ov.com>; Fri, 23 May 1997 07:49:26 GMT
Message-Id: <3385CA89.1495 at frcl.bull.fr>
Date: Fri, 23 May 1997 09:49:13 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
Mime-Version: 1.0
To: Martin.Rex at sap-ag.de
Cc: Mike Swift <mikesw at microsoft.com>, linn at cam.ov.com, cat-ietf at mit.edu
Subject: Re: CAT-WG Last-Call: draft-ietf-cat-snego-05.txt
References: <199705212054.AA19114 at sap-ag.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Martin Rex wrote:
>
> Mike Swift wrote:
> >
> > I have a couple of comments.
> > At the bottom of page three, the mechanism for determining which
> > mechanism to use is layed out:
> > The target selects the value according to a simpleselection
> > criteria: it checks if the first entry from its own list ispresent in
> > the set offered by the initiator. If the entry is present,then it is the
> > agreed mechanism, if not then the second entry from itsown ordered list
> > is checked and the process continues until allentries have been checked.
> > Thus, the target's mechanism preferenceshave precedence when more than
> > one common mechanism is availablebetween the target and initiator. The
> > service flags that are requested by the initiator are not taken into
> > consideration to make the selectionbut are used to select the
> > appropriate options, should these options be supported by the mechanism.
> >
> > I don't think the draft should specify what policy is used when
> > determining the chosen mechanism. This doesn't affect the wire format of
> > the protocol and some implementations may wish to optimize the number of
> > round-trips by choosing the preferred mechanism of client. In addition,
> > the context flags should be usable in the determination of a mechanism
> > to use - if a caller specifies particular capabilities that the server's
> > preferred package doesn't support, then there may be no sense in going
> > to the work of establishing a context at all.
The question is whether or not we should specify the logic of the target
for the choice. If we do, it is possible to run some tests to verify
that
two different implementations from two different vendors behave in the
same
way ... otherwise it looks like a random choice among the list of the
server.
I still think that we should specify the logic of the target.
The second point is that with RFC 2078 a context is indeed established
even
if the requested flags cannot be honored. Unless we change 2078, there
is
no reason that SPNEGO should work in a different way.
> > On page seven, where the context flags are defined, the flag "confFlag
> > (5)" should be added for confidentiality support. In addition, it should
> > be noted that these flags may be extended if the GSS context requirement
> > flags are extended
>
> That's actually interesting. I agree with Mike Swift that the context
> attribute handling defined for base GSS-API doesn't scale/fit for
> the negotiation mechanism.
>
> The flags listed in snego are those features that can be "requested"
> via gss_init_sec_context() (as documented in RFC2078 2.2.1).
> confFlag is a features that can be returned, but not requested.
Correct. This is the reason why this flag is not present.
> As documented, all of the flag input values are "feature request"
> that may or may not be granted/provided. Absence of a requested
> feature will not abort a context establishment. A initiator or
> acceptor that is uncomfortable with the resulting features from
> a context establishment is supposed to abort and delete the
> context. This may result in unecessary overhead when the interoperable
> intersection of features provided by the client's and server's
> mechanism doesn't meet either one's requirements, but was still
> considered acceptable. For a negotiation mechanism, when
> (either or both) mechanism preference lists outweigh the requested
> feature flags, this might actually prevent successful context
> establishment.
>
> I have the feeling that it should be possible for the negotiation
> mechanism to specify which context feature flags are considered
> a requirement by both initiator and acceptor, and the required features
> should precede the preference list.
>
> Off-hand, I don't have an idea how to:
> - distinuish "required" from "nice-to-have" context features,
> i.e. declare a feature "required"
> - request "integrity" and "confidentiality"
>
> but I think this would be very, very valuable.
> Since snego uses the regualar GSS-API calls, an extensions may
> have to be folded into v2 as well?!
As said earlier I am reluctant to extend SPNEGO features unless we
change
the Base GSS-API as well. The merrit of doing so is small compared to
the non-compatibility we will experience. Another argument is that this
would
postpone the adoption of SPNEGO for another 6 months or more.
The IETF is supposed to work faster that ISO ... :-)
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from cnri by ietf.org id aa04166; 23 May 97 7:06 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa04528; 23 May 97 7:06 EDT
Received: from ietf.org by ietf.org id aa04154; 23 May 97 7:06 EDT
Received: from munnari.OZ.AU by ietf.org id aa04140; 23 May 97 7:06 EDT
Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56)
id LA32061; Fri, 23 May 1997 21:01:58 +1000 (from kre at munnari.OZ.AU)
X-Mailer: exmh version 2.0gamma 1/27/96
To: Winfried Koenig <win at in.rhein-main.de>
Cc: iesg at ietf.org, ietf at ietf.org
Subject: Re: Classless IN-ADDR.ARPA delegation
In-Reply-To: Your message of "Thu, 22 May 1997 22:00:43 +0100."
<m0wUeya-0005nMC at incom.rhein-main.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 23 May 1997 21:01:57 +1000
Message-Id: <27457.864385317 at munnari.OZ.AU>
Sender:iesg-request at ietf.org
From: Robert Elz <kre at munnari.oz.au>
Date: Thu, 22 May 1997 22:00:43 +0100 (MET)
From: Winfried Koenig <win at in.rhein-main.de>
Message-ID: <m0wUeya-0005nMC at incom.rhein-main.de>
Sorry, I hope draft-ietf-dnsind-classless-inaddr-03.txt
is not the final version.
On the contrary, I certainly would prefer if it is, exactly as it is now.
In the spirit of the Robustness
Principle: "Be liberal in what you accept, and conservative
in what you send" I recomment to replace the '/' characters
in the zone names of the draft by one of the characters
'a' .. 'z# or '-'.
Those are just examples - and ones I think very worth keeping,
if for no other reason to assist in making quite clear that DNS
names are not limited to being alphanumeric and hyphen strings
(and dots to separate the labels).
The reason is, there are a lot of programs and scripts for
DNS support and some of these will break with the character
'/' in zone names.
Then they ought be fixed. Maybe this draft will provide the impetus.
Zone names are often used to generate
Filenames and the '/' character is used as Unix directory
delimiter. ...
Sure - if you're building such a zone, and you use the zone name
that way, then you wouldn't use '/' in the name, that is an individual
choice.
I absolutely applaud the use if the '/' in the examples in the draft,
and would object violently if any form of "name correctness" attempted
to cause that to be changed. I would not agree to requiring use of the
'/' anywhere, but this draft requires nothing, it is simply the description
of a useful technique.
kre
Received: from cnri by ietf.org id aa05994; 23 May 97 9:09 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05848;
23 May 97 9:09 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <LAA14897 at pad-thai.cam.ov.com>; Fri, 23 May 1997 11:51:09 GMT
Message-Id: <199705231151.HAA23748 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: target name discovery
In-Reply-To: Your message of "Wed, 21 May 1997 18:19:23 EDT."
<199705212221.AA03613 at sap-ag.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 23 May 1997 07:51:01 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Martin writes:
> When the local gssapi mechanism successfully accepts a user-supplied
> printable name as a target, then there is absolutely no guarantee
> that the same printable name will be accepted at the acceptor side.
> On top of that: what is "the same printable name" in the face of
> locale differences, codepage differences (like EBCDIC-evils) and
> local gssapi configuration files/attributes that influence the name
> canonicalization. Dealing with codepages or Unicode cross-plattform
> is non-trivial, especially when you are not really supposed to make
> assumptions about "printable information".
>
This seems accurate to me; there's no assumption that the printable form
of a particular name as it appears on one system will necessarily match
the printable form of that name as it appears somewhere else.
> The only "portable" name representation available to the application
> seems to be the new v2 exported_name. It is supposed to be portable
> within the same mechanism. Unfortunately I don't see how this could
> work *with* snego (although I plan to always ask for specific mechanisms,
> ignoring snego where available).
Good observation. Considering it in terms of specific document impact, I
believe that (in conjunction with the inclusion of some discussion about
aspects of negotiating vs. non-negotiating mechanisms), the comment re
mech_type input to GSS_Canonicalize_name, which now states "must be
explicit mechanism, not default specifier" should be broadened to
also exclude negotiated mechanisms. (We <c|sh>ould then have a subdiscussion
about whether GSS_S_BAD_MECH or GSS_S_FAILURE should be returned if
a negotiated mechanism's mech_type is passed in, since that mechanism
*is* supported by the implementation for other operations, even though
not for this one...)
--jl
Received: from cnri by ietf.org id aa06182; 23 May 97 9:16 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa05983; 23 May 97 9:16 EDT
Received: from ietf.org by ietf.org id aa06174; 23 May 97 9:16 EDT
Received: from netmail1.austin.ibm.com by ietf.org id aa06158;
23 May 97 9:16 EDT
Received: from mojave.austin.ibm.com (mojave.austin.ibm.com [9.53.150.115]) by netmail1.austin.ibm.com (8.6.12/8.6.11) with SMTP id IAA59995; Fri, 23 May 1997 08:12:24 -0500
Received: from mojave.austin.ibm.com (loopback [127.0.0.1]) by mojave.austin.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id IAA38798; Fri, 23 May 1997 08:12:24 -0500 (CDT)
Message-Id: <199705231312.IAA38798 at mojave.austin.ibm.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Winfried Koenig <win at in.rhein-main.de>
cc: iesg at ietf.org, ietf at ietf.org
Subject: Re: Classless IN-ADDR.ARPA delegation
In-reply-to: <m0wUeya-0005nMC at incom.rhein-main.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 23 May 1997 08:12:24 -0500
Sender:iesg-request at ietf.org
From: Dave Marquardt <marquard at austin.ibm.com>
On Thu, 22 May 1997 22:00:43 +0100 (MET) Winfried Koenig wrote:
> The reason is, there are a lot of programs and scripts for
> DNS support and some of these will break with the character
> '/' in zone names. Zone names are often used to generate
> Filenames and the '/' character is used as Unix directory
> delimiter. ...
So don't use a zone name with a '/' in it to generate zone
filenames. Or don't use zone names with '/' in them--the way I read
the draft, that's certainly an administrator's choice.
--
Dave Marquardt
SMTP: marquard at austin.ibm.com
VNET: MARQUARD at AUSTIN
T/L 678-1139
+1 512 838-1139
Received: from ietf.org by ietf.org id aa06766; 23 May 97 9:29 EDT
Received: from dot.netrex.net by ietf.org id aa06554; 23 May 97 9:27 EDT
Received: from rgm3 (nsn1-gw5-xl1.netrex.com [206.253.228.11]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id JAA13624 for <ietf at ietf.org>; Fri, 23 May 1997 09:23:51 -0400 (EDT)
Message-Id: <3.0.1.32.19970523092337.009d92c0 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 23 May 1997 09:23:37 -0400
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Anti Spam legislation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
For those of you involved with dealing with SPAM. Here is something for
you to chew on.
For the rest, I appologize for the long re-post here.
Resent-Date: Thu, 22 May 1997 20:47:29 -0700 (PDT)
Date: Thu, 22 May 1997 20:46:50 -0700 (PDT)
From: Phil Agre <pagre at weber.ucsd.edu>
To: rre at weber.ucsd.edu
Subject: anti-spam bill
Resent-Message-Id: <"ECtb7.A.5jG.sMRhz"@weber>
Resent-From: rre at weber.ucsd.edu
Reply-To: rre-maintainers at weber.ucsd.edu
X-Url: http://communication.ucsd.edu/pagre/rre.html
X-Mailing-List: <rre at weber.ucsd.edu> archive/latest/1609
X-Loop: rre at weber.ucsd.edu
Resent-Sender: rre-request at weber.ucsd.edu
[Although I am not an attorney and have not seen any analysis of this
bill, to my untrained eye it certainly seems like a step in the right
direction. It is interesting and a little scary, however, to catalog
every passage in the bill that invokes a technical term. What happens
when the architecture of the Internet changes so that the evils of spam
can be perpetrated in ways not envisioned by this bill, or so that the
existing terms change their meanings enough that the bill starts having
unintended consequences, covering either too many actions, or too few,
or both? In any case, I would remind us that several people have made
their names swearing everlasting enmity to government regulation of the
Internet. Will those folks be taking a stand against this bill? Hmm?]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was forwarded through the Red Rock Eater News Service (RRE).
Send any replies to the original author, listed in the From: field below.
You are welcome to send the message along to others but please do not use
the "redirect" command. For information on RRE, including instructions
for (un)subscribing, send an empty message to rre-help at weber.ucsd.edu
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[Related materials at http://www.senate.gov/~murkowski/commercialemail ]
Please note throughout S. 771,
Commission refers to the Federal Trade Commission,
not the Federal Communications Commission
S. 771 BILL TEXT
Be it enacted by the Senate and House of Representatives of the
United States of America in Congress assembled,
SECTION 1. SHORT TITLE.
This Act may be cited as the ``Unsolicited Commercial Electronic Mail
Choice Act of 1997''.
SEC. 2. FINDINGS.
Congress makes the following findings:
(1) The Internet is a worldwide network of information that growing
numbers of Americans use on a regular basis for educational and
personal activities.
(2) Electronic mail messages transmitted on the Internet constitute an
increasing percentage of communications in the United States.
(3) Solicited commercial electronic mail is a useful and
cost-effective means for Americans to receive information about a
business and its products.
(4) The number of transmissions of unsolicited commercial electronic
mail advertisements has grown exponentially over the past several
years as the technology for creating and transmitting such
advertisements in bulk has made the costs of distribution of such
advertisements minimal.
(5) Individuals have available no effective means of differentiating
between unsolicited commercial electronic mail advertisements and
other Internet communications.
(6) The transmitters of unsolicited commercial electronic mail
advertisements can easily move from State to State.
(7) Individuals and businesses that receive unsolicited commercial
electronic mail advertisements often pay for the costs of such receipt
,including the costs of Internet access and long distance telephone
charges.
(8) Unsolicited commercial electronic mail can be used to advertise
legitimate services and goods but is also used for fraudulent and
deceptive purposes in violation of Federal and State law.
(9) Individuals and companies that use unsolicited commercial
electronic mail for fraudulent and deceptive purposes often use
fraudulent identification information in such electronic mail, making
it impossible for a recipient to request to be removed from the
mailing list or for law enforcement authorities to identify the
sender.
(10) The inability of recipients of unsolicited commercial electronic
mail to identify the senders of such electronic mail or to prevent its
receipt impedes the flow of commerce and communication on the Internet
and threatens the integrity of commerce on the Internet.
(11) Internet service providers are burdened by the cost of equipment
necessary to process unsolicited commercial electronic mail.
(12) To facilitate the development of commerce and communication on
the Internet, unsolicited commercial electronic mail should be readily
identifiable and filterable by individuals and Internet service
providers.
SEC. 3. REQUIREMENTS RELATING TO TRANSMISSIONS OF UNSOLICITED
COMMERCIAL ELECTRONIC MAIL.
(a) Information on Advertisement.
(1) Requirement.
Unless otherwise authorized pursuant to a provision of section 7, a
person who transmits an electronic mail message as part of the
transmission of unsolicited commercial electronic mail shall cause to
appear in each electronic mail message transmitted as part of such
transmission the information specified in paragraph (3).
(2) Placement.
* (A) Advertisement.
The information specified in subparagraph (A) of paragraph (3)
shall appear as the first word of the subject line of the
electronic mail message without any prior text or symbol.
* (B) Other information.
The information specified in subparagraph (B) of that paragraph
shall appear prominently in the body of the message.
(3) Covered information.
The following information shall appear in an electronic mail message
under paragraph (1):
* (A) The term ``advertisement''.
* (B) The name, physical address, electronic mail address, and
telephone number of the person who initiates transmission of the
message.
(b) Routing Information.
All Internet routing information contained within or accompanying an
electronic mail message described in subsection (a) shall be valid
according to the prevailing standards for Internet protocols.
(c) Effective Date.
The requirements in this section shall take effect 30 days after the
date of enactment of this Act.
SEC. 4. FEDERAL REGULATION OF UNSOLICITED COMMERCIAL ELECTRONIC MAIL.
(a) Transmissions.
(1) In general.
Upon notice from a person of the person's receipt of electronic mail
in violation of a provision of section 3 or 7, the Commission
* (A) may conduct an investigation to determine whether or not the
electronic mail was transmitted in violation of the provision; and
* (B) if the Commission determines that the electronic mail was
transmitted in violation of the provision, may
+ (i) impose upon the person initiating the transmission a
civil fine in an amount not to exceed $11,000;
+ (ii) commence in a district court of the United States a
civil action to recover a civil penalty in an amount not to
exceed $11,000 against the person initiating the
transmission; or
+ (iii) both impose a fine under clause (i) and commence an
action under clause (ii).
(2) Deadline.
The Commission may not take action under paragraph (1)(B) with
respect to a transmission of electronic mail more than 2 years
after the date of the transmission.
(b) Administration.
(1) Notice by electronic means.
The Commission shall establish an Internet web site with an
electronic mail address for the receipt of notices under
subsection (a).
(2) Information on enforcement.
The Commission shall make available through the Internet web site
established under paragraph (2) information on the actions taken
by the Commission under subsection (a)(1)(B).
(3) Assistance of Federal Communications Commission.
The Federal Communications Commission may assist the Commission in
carrying out its duties this section.
SEC. 5. ACTIONS BY STATES.
(a) In General.
Whenever an attorney general of any State has reason to believe
that the interests of the residents of that State have been or are
being threatened or adversely affected because any person is
engaging in a pattern or practice of the transmission of
electronic mail in violation of a provision of section 3 or 7, the
State, as parens patriae, may bring a civil action on behalf of
its residents to enjoin such transmission, to enforce compliance
with the provision, to obtain damages or other compensation on
behalf of its residents, or to obtain such further and other
relief as the court considers appropriate.
(b) Notice to Commission.
(1) Notice.
The State shall serve prior written notice of any civil action
under this section upon the Commission and provide the Commission
with a copy of its complaint, except that if it is not feasible
for the State to provide such prior notice, the State shall serve
written notice immediately upon instituting such action.
(2) Rights of commission.
Upon receiving a notice with respect to a civil action under
paragraph (1), the Commission shall have the right
+ (A) to intervene in the action;
+ (B) upon so intervening, to be heard in all matters arising
therein; and
+ (C) to file petitions for appeal.
(c) Actions by Commission.
Whenever a civil action has been instituted by or on behalf of the
Commission for violation of a provision of section 3 or 7, no
State may, during the pendency of such action, institute a civil
action under this section against any defendant named in the
complaint in such action for violation of any provision as alleged
in the complaint.
(d) Construction.
For purposes of bringing a civil action under subsection(a),
nothing in this section shall prevent an attorney general from
exercising the powers conferred on the attorney general by the
laws of the State concerned to conduct investigations or to
administer oaths or affirmations or to compel the attendance of
witnesses or the production of documentary or other evidence.
(e) Venue; Service of Process.
Any civil action brought under subsection (a)in a district court
of the United States may be brought in the district in which the
defendant is found, is an inhabitant, or transacts business or
wherever venue is proper under section 1391 of title 28, United
States Code. Process in such an action may be served in any
district in which the defendant is an inhabitant or in which the
defendant may be found.
(f) Actions by Other State Officials.
Nothing in this section may be construed to prohibit an authorized
State official from proceeding in State court on the basis of an
alleged violation of any civil or criminal statute of the State
concerned.
(g) Definition.
In this section, the term ``attorney general'' means the chief
legal officer of a State.
SEC. 6. INTERNET SERVICE PROVIDERS.
(a) Exemption for Certain Transmissions.
The provisions of this Act shall not apply to a transmission of
electronic mail by an interactive computer service provider unless
the provider initiates the transmission.
(b) Notice of Transmissions from Commission.
Not later than 72 hours after receipt from the Commission of
notice that its computer equipment may have been used by another
person to initiate a transmission of electronic mail in violation
of a provision of section 3 or 7, an interactive computer service
provider shall
(1) provide the Commission such information as the Commission
requires in order to determine whether or not the computer
equipment of the provider was used to initiate the transmission;
and
(2) if the Commission determines that the computer equipment of
the provider was used to initiate the transmission, take
appropriate actions to terminate the use of its computer equipment
by that person.
(c) Notice of Transmissions from Private Individuals.
(1) In general.
Subject to paragraph (2), not later than 14 days after receipt
from a private person of notice that its computer equipment may
have been used by another person to initiate a transmission of
electronic mail in violation of a provision of section 3 or 7, an
interactive computer service provider shall
+ (A) transmit the notice to the Commission together with such
information as the Commission requires in order to determine
whether or not the computer equipment of the provider was
used to initiate the transmission; and
+ (B) if the Commission determines that the computer equipment
of the provider was used to initiate the transmission, take
appropriate actions to terminate the use of its computer
equipment by that person.
(2) Minimum notice requirement.
An interactive computer service provider shall transmit a notice
under paragraph (1) with respect to a particular transmission of
electronic mail only if the provider receives notice with respect
to the transmission from more than 100 private persons.
(d) Blocking Systems.
(1) Requirement.
Each interactive computer service provider shall make available to
subscribers to such service a system permitting such subscribers,
upon the affirmative electronic request of such subscribers, to
block the receipt through such service of any electronic mail that
contains the term``advertisement'' in its subject line.
(2) Notice of availability.
Upon the applicability of this subsection to an interactive
computer service provider, the provider shall
+ (A) notify each current subscriber, if any, to the service of
the blocking system provided for under paragraph (1); and
+ (B) notify any new subscribers to the service of the blocking
system.
(3) Blocking by provider.
An interactive computer service provider may, upon its own
initiative, block the receipt through its service of any
electronic mail that contains the term ``advertisement'' in its
subject line.
(4) Applicability.
The requirements in paragraphs (1) and (2) shall apply
+ (A) beginning 1 year after the date of enactment of this Act,
in the case of an interactive computer service provider
having more than 25,000 or more subscribers; and
+ (B) beginning 2 years after that date, in the case of an
interactive computer service provider having less than 25,000
subscribers.
(e) Records.
An interactive computer service provider shall retain records of
any action taken on a notice received under this section for not
less than 2 years after the date of receipt of the notice.
(f) Construction.
Nothing in this section may be construed to require an interactive
computer service provider to transmit or otherwise deliver any
electronic mail message containing the term ``advertisement'' in
its subject line.
(g) Definition.
In this section, the term ``interactive computer service
provider'' has the meaning given that term in section 230(e)(2) of
the Communications Act of 1934 (47 U.S.C. 230(e)(2)).
SEC. 7. RECEIPT OF TRANSMISSIONS BY PRIVATE PERSONS.
(a) Termination of Transmissions.
(1) Request.
A person who receives a transmission of unsolicited commercial
electronic mail not otherwise authorized under this section may
request, by electronic mail to the same electronic mail address
from which the transmission originated, the termination of
transmissions of such mail by the person initiating the
transmission.
(2) Deadline.
A person receiving a request for the termination of transmissions
of electronic mail under this subsection shall cease initiating
transmissions of electronic mail to the person submitting the
request not later than 48 hours after receipt of the request.
(b) Affirmative Authorization of Transmissions Without
Information.
(1) In general.
Subject to paragraph (2), a person may authorize another person
to initiate transmissions to the person of unsolicited commercial
electronic mail without inclusion in such transmissions of the
information required by section 3.
(2) Termination.
+ (A) Notice.
A person initiating transmissions of electronic mail under
paragraph (1) shall include, with each transmission of such
mail to a person authorizing the transmission under that
paragraph, notice that the person authorizing the
transmission may request at any time the recommencement of
the inclusion in such transmissions of the information
required by section 3.
+ (B) Deadline.
A person receiving a request under this paragraph shall
include the information required by section 3 in all
transmissions of unsolicited commercial electronic mail to
the person making the request beginning not later than 48
hours after receipt of the request.
(c) Constructive Authorization of Transmissions Without
Information.
(1) In general.
Subject to paragraph (2), a person who secures a good or service
from, or otherwise responds electronically to, an offer in a
transmission of unsolicited commercial electronic mail shall be
deemed to have authorized transmissions of such mail without
inclusion of the information required under section 3 from the
person who initiates the transmission providing the basis for such
authorization.
(2) Termination.
+ (A) Request.
A person deemed to have authorized the transmissions of
electronic mail under paragraph (1) may request at any time
the recommencement of the inclusion in such transmissions of
the information required by section 3.
+ (B) Deadline.
A person receiving a request under this paragraph shall
include the information required by section 3 in all
transmissions of unsolicited commercial electronic mail to
the person making the request beginning not later than 48
hours after receipt of the request.
(d) Effective Date of Termination Requirements.
Subsections (a), (b)(2), and(c)(2) shall take effect 30 days after
the date of enactment of this Act.
SEC. 8. ACTIONS BY PRIVATE PERSONS.
(a) In General.
Any person adversely affected by a violation of a provision of
section 3 or 7, or an authorized person acting on such person's
behalf, may, within 1 year after discovery of the violation, bring
a civil action in a district court of the United States against a
person who has violated the provision. Such an action may be
brought to enjoin the violation, to enforce compliance with the
provision, to obtain damages, or to obtain such further and other
relief as the court considers appropriate.
(b) Damages.
(1) In general.
The amount of damages in an action under this section for a
violation specified in subsection (a) may not exceed $5,000 per
violation.
(2) Relationship to other damages.
Damages awarded for a violation under this subsection are in
addition to any other damages awardable for the violation under
any other provision of law.
(c) Cost and Fees.
The court, in issuing any final order in any action brought under
subsection (a), may award costs of suit and reasonable attorney
fees and expert witness fees for the prevailing party.
(d) Venue; Service of Process.
Any civil action brought under subsection (a)in a district court
of the United States may be brought in the district in which the
defendant is found, is an inhabitant, or transacts business or
wherever venue is proper under section 1391 of title 28, United
States Code. Process in such an action may be served in any
district in which the defendant is an inhabitant or in which the
defendant may be found.
SEC. 9. RELATION TO STATE LAWS.
(a) State Law Applicable Unless Inconsistent.
The provisions of this Act do not annul, alter, or affect the
applicability to any person, or otherwise exempt from the
applicability to any person, of the laws of any State with respect
to the transmission of unsolicited commercial electronic, except
to the extent that those laws are inconsistent with any provision
of this Act,and then only to the extent of the inconsistency.
(b) Requirement Relating to Determination of Inconsistency.
The Commission may not determine that a State law is inconsistent
with a provision of this Act if the Commission determines that
such law places greater restrictions on the transmission of
unsolicited commercial electronic mail than are provided for under
such provision.
SEC. 10. DEFINITIONS.
In this Act:
(1) Commercial electronic mail. The term ``commercial electronic
mail''means any electronic mail that
+ (A) contains an advertisement for the sale of a product or
service;
+ (B) contains a solicitation for the use of a toll-free
telephone number or a telephone number with a 900 prefix the
use of which connects the user to a person or service that
advertises the sale of or sells a product or service; or
+ (C) contains a list of one or more Internet sites that
contain an advertisement referred to in subparagraph (A) or a
solicitation referred to in subparagraph (B).
(2) Commission.
The term ``Commission'' means the Federal Trade Commission.
(3) State.
The term ``State'' means any State of the United States, the
District of Columbia, Puerto Rico, Guam, American Samoa, the
United States Virgin Islands, the Commonwealth of the Northern
Mariana Islands, the Republic of the Marshall Islands, the
Federated States of Micronesia, the Republic of Palau, and any
possession of the United States.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa06930; 23 May 97 9:31 EDT
Received: from atlantis.erlm.siemens.de by ietf.org id aa06730;
23 May 97 9:29 EDT
Received: from tcenter.erlm.siemens.de (tcenter.erlm.siemens.de [193.25.63.21]) by atlantis.erlm.siemens.de (8.7.5/8.7.3) with ESMTP id PAA07996 for <ietf at ietf.org>; Fri, 23 May 1997 15:25:02 +0200 (MET DST)
Received: from erlm245a.it.erlm.siemens.de (erlm245a.it.erlm.siemens.de [193.25.63.46]) by tcenter.erlm.siemens.de (8.7.5/8.7.3) with SMTP id PAA02844 for <ietf at ietf.org>; Fri, 23 May 1997 15:21:20 +0200 (MET DST)
Received: by erlm245a.it.erlm.siemens.de with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52)
id <01BC678D.69D94E70 at erlm245a.it.erlm.siemens.de>; Fri, 23 May 1997 15:24:32 +0200
Message-ID: <c=DE%a=DBP%p=SCN%l=ERLM245A-970523132431Z-496 at erlm245a.it.erlm.siemens.de>
Sender:ietf-request at ietf.org
From: Hernandez Miguel <Miguel.Hernandez at it.erlm.siemens.de>
To: 'IETF' <ietf at ietf.org>
Subject: unsuscribe
Date: Fri, 23 May 1997 15:24:31 +0200
Return-Receipt-To: <Miguel.Hernandez at it.erlm.siemens.de>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsuscribe
+----------------------------------------------------+
* SIEMENS AG
* Information Technology Services
* for Industrial Plants
* Technology Center
* ANL A45-AM
* M.A.Hernandez y Coll
* Head of Section
* P.O.Box 830951 Mch-P
* D-81730 Munich R.64.630
+-----------------------------------------------------+
* Phone: 0049-89-636-47580
* Mobil: 0171-3378732
* PCFax: 0049-89-636-47713
* Fax : 0049-89-636-47586
+-----------------------------------------------------+
* e-mail:
* miguel.hernandez at erlm.siemens.de
* Internet:
* http://www.anl.siemens.de/it-dl
* Intranet:
* http://www.erlm.siemens.de
+-----------------------------------------------------+
Received: from ietf.org by ietf.org id aa07179; 23 May 97 9:37 EDT
Received: from ietf.ietf.org by ietf.org id aa06912; 23 May 97 9:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-nai-03.txt
Date: Fri, 23 May 1997 09:30:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705230931.aa06912 at ietf.org>
--NextPart
A Revised 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 : The Network Access Identifier
Author(s) : B. Aboba
Filename : draft-ietf-roamops-nai-03.txt
Pages : 4
Date : 05/22/1997
In order to enhance the interoperability of roaming and tunneling services,
it is desirable to have a standardized method for identifying users. This
document proposes syntax for the Network Access Identifier (NAI). It is
expected that this will be of interest for support of roaming as well as
tunneling. "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-nai-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-nai-03.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-nai-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970522155135.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-nai-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-nai-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970522155135.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07197; 23 May 97 9:37 EDT
Received: from ietf.ietf.org by ietf.org id aa06828; 23 May 97 9:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-newman-url-imap-09.txt
Date: Fri, 23 May 1997 09:30:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705230930.aa06828 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP URL Scheme
Author(s) : C. Newman
Filename : draft-newman-url-imap-09.txt
Pages : 16
Date : 05/22/1997
IMAP [IMAP4] is a rich protocol for accessing remote message stores. It
provides an ideal mechanism for accessing public mailing list archives as
well as private and shared message stores. This document defines a URL
scheme for referencing objects on an IMAP 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-newman-url-imap-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-url-imap-09.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-newman-url-imap-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970522153001.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-newman-url-imap-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-newman-url-imap-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970522153001.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07194; 23 May 97 9:37 EDT
Received: from ietf.ietf.org by ietf.org id aa06808; 23 May 97 9:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-goland-state-token-00.txt
Date: Fri, 23 May 1997 09:30:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705230930.aa06808 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : State Tokens and Preconditions for HTTP
Author(s) : Y. Goland, E. Whitehead
Filename : draft-goland-state-token-00.txt
Pages : 4
Date : 05/22/1997
There are times when a principal will want to predicate successful
execution of a method on the current state of a resource. While HTTP/1.1
provides a mechanism for conditional execution of methods using entity tags
via the "If-Match" and "If-None-Match" headers, the mechanism is not
sufficiently extensible to express conditional statements involving more
generic state indicators, such as lock tokens.
This draft defines the term "state token" as an identifier for a state of a
resource. This draft defines requirements for state tokens and provides a
state token syntax, along with two new headers which are used to express
method preconditions using state tokens.
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-goland-state-token-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-goland-state-token-00.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-goland-state-token-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970522152713.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-goland-state-token-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-goland-state-token-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970522152713.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07191; 23 May 97 9:37 EDT
Received: from ietf.ietf.org by ietf.org id aa06884; 23 May 97 9:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-urn-naptr-05.txt
Date: Fri, 23 May 1997 09:30:40 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705230930.aa06884 at 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-05.txt
Pages : 13
Date : 05/22/1997
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).
The requirements document for URN resolution systems[15] defines the
concept of a "resolver discovery service". This document describes the
first, experimental, RDS. It is implemented by 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.
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-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-05.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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-urn-naptr-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970522170701.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-naptr-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-naptr-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970522170701.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab07179; 23 May 97 9:37 EDT
Received: from ietf.ietf.org by ietf.org id aa06913; 23 May 97 9:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-imprev-02.txt
Date: Fri, 23 May 1997 09:30:16 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705230931.aa06913 at ietf.org>
--NextPart
A Revised 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, J. Lu, J. Alsop, J. Ding, W. Wang
Filename : draft-ietf-roamops-imprev-02.txt
Pages : 32
Date : 05/22/1997
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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-imprev-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-imprev-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970522154716.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-imprev-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-imprev-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970522154716.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07199; 23 May 97 9:37 EDT
Received: from ietf.ietf.org by ietf.org id aa06862; 23 May 97 9:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-radius at livingston.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-radius-eap-02.txt
Date: Fri, 23 May 1997 09:30:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705230930.aa06862 at ietf.org>
--NextPart
A Revised 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 : Extensible Authentication Protocol Support in RADIUS
Author(s) : P. Calhoun, A. Rubens, B. Aboba
Filename : draft-ietf-radius-eap-02.txt
Pages : 13
Date : 05/22/1997
The Extensible Authentication Protocol (EAP) is a PPP extension that
provides support for additional authentication methods within PPP.
This document describes how the EAP-Message and Signature attributes
may be used for providing EAP support within RADIUS.
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-eap-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-eap-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-radius-eap-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970522155724.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-eap-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-eap-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970522155724.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07800; 23 May 97 9:42 EDT
Received: from ietf.ietf.org by ietf.org id aa07714; 23 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-mitsuru-02.txt
Date: Fri, 23 May 1997 09:41:28 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705230941.aa07714 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A MAPOS version 1 Extension - Switch-Switch Protocol
Author(s) : K. Murakami, M. Maruyama
Filename : draft-rfced-info-mitsuru-02.txt
Pages : 21
Date : 05/22/1997
This document describes a MAPOS version 1 extension, SSP (Switch Switch
Protocol). MAPOS is a multiple access protocol for transmission of
network-protocol packets, encapsulated in High-Level Data Link Control
(HDLC) frames, over SONET/SDH. In MAPOS network, a SONET switch provides
the multiple access capability to end nodes. SSP is a protocol of Distance
Vector family and provides unicast and broadcast/multicast routing for
multiple SONET switch 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-rfced-info-mitsuru-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-mitsuru-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-mitsuru-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970522160138.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-mitsuru-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-mitsuru-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970522160138.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07799; 23 May 97 9:42 EDT
Received: from ietf.ietf.org by ietf.org id aa07680; 23 May 97 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-ken-02.txt
Date: Fri, 23 May 1997 09:41:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705230941.aa07680 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A MAPOS version 1 Extension - Node Switch Protocol
Author(s) : K. Murakami, M. Maruyama
Filename : draft-rfced-info-ken-02.txt
Pages : 6
Date : 05/22/1997
This document describes a MAPOS extension, Node Switch Protocol, for
automatic node address assignment. MAPOS is a multiple access protocol for
transmission of network-protocol datagrams, encapsulated in High-Level Data
Link Control (HDLC) frames, over SONET/SDH. NSP automates the HDLC address
configuration of each node. Using NSP, a node retrieves its HDLC address
from the switch to which it is connected.
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-ken-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-ken-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 at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-ken-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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970522152307.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-ken-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-ken-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970522152307.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12775; 23 May 97 13:12 EDT
Received: from zephyr.isi.edu by ietf.org id aa12530; 23 May 97 13:06 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
id <AA13971>; Fri, 23 May 1997 10:00:57 -0700
Message-Id: <199705231700.AA13971 at zephyr.isi.edu>
To: IETF-Announce: ;
To: Internet-Monthly-Report-People: ;
Subject: Internet Monthly Report for April, 1997
Cc: imr-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 May 97 10:00:56 PDT
Sender:ietf-announce-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
--NextPart
The Internet Monthly Report for April, 1997 is now available
at the following location:
URL= ftp://ftp.isi.edu/in-notes/imr/imr9704.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 at 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 at 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 IMR9704.TXT. For example,
IMR9704.TXT is the report for April 1997.
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 at ISI.EDU with
the message body help: ways_to_get_imrs. For example:
To: rfc-info at 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 IMR9704.TXT is the report for April 1997).
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 at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9704
--OtherAccess
Content-Type: Message/External-body;
name="imr9704.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 aa12773; 23 May 97 13:12 EDT
Received: from zephyr.isi.edu by ietf.org id aa12605; 23 May 97 13:08 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
id <AA14249>; Fri, 23 May 1997 10:03:55 -0700
Message-Id: <199705231703.AA14249 at zephyr.isi.edu>
To: ietf at ietf.org, imr at isi.edu
Subject: Internet Monthly Report for April, 1997
Cc: imr-ed at isi.edu
Date: Fri, 23 May 97 10:03:55 PDT
Sender:ietf-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
Source-Info: From (or Sender) name not authenticated.
April 1997
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-ED at 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 at 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 at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at 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 April 1997
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 12
US Domain Registry. . . . . . . . . . . . . . . . . . . page 13
MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 16
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 17
IANA REPORT . . . . . . . . . . . . . . . . . . . . . . . page 18
RFC EDITOR REPORT . . . . . . . . . . . . . . . . . . . . page 18
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 20
TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 25
IMR Editor [Page 2]
Internet Monthly Report April 1997
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
----------------------------
Internet Monthly Report for April
1. The IETF returns to Europe for the summer meeting in Munich,
Germany from August 11-15, 1997. Our hosts for this meeting will
be Digi/ISOC.DE. The final meeting of the year will be held in
the D.C. area, hosted by Newbridge.
Once all arrangements have been made, notifications will be sent
to the IETF Announcement list. Remember that information on
future meetng sites can always be found in the file
0mtg-sites.txt, located on the IETF shadow directories. Of
course, this information is provided on the Web. The IETF's URL
is:
http://www.ietf.org/
2. The minutes of the IESG teleconferences be found on all the IETF
shadow directories in the iesg directory.
The following IESG minutes have been added:
March 20, 1997 (iesg.97-03-20)
3. The IESG approved or recommended the following two Protocol
Actions during the month of April:
o URN Syntax for publication as a Proposed Standard.
o MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS for
publication as a Proposed Standard.
4. 25 Last Calls were issued by the IESG during the month of April:
o RSVP Cryptographic Authentication <draft-ietf-rsvp-md5-02> for
consideration as a Proposed Standard.
IMR Editor [Page 3]
Internet Monthly Report April 1997
o Integrated Services Management Information Base
<draft-ietf-intserv-mib-05> for consideration as a Proposed
Standard.
o General Characterization Parameters for Integrated Service
Network Elements <draft-ietf-intserv-charac-02> for
consideration as an Informational RFC.
o Specification of Guaranteed Quality of Service
<draft-ietf-intserv-guaranteed-svc-07> for consideration as a
Proposed Standard.
o Specification of the Controlled-Load Network Element Service
<draft-ietf-intserv-ctrl-load-svc-04> for consideration as a
Proposed Standard.
o A One-Time Password System <draft-ietf-otp-01> for
consideration as a Draft Standard.
o OSPF Version 2 <draft-ietf-ospf-version2-11> for consideration
as a Standard.
o Integrated Services Management Information Base Guaranteed
Service Extensions <draft-ietf-intserv-guaranteed-mib-03> for
consideration as a Proposed Standard.
o Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification <draft-ietf-rsvp-spec-14> for consideration as a
Proposed Standard.
o The TLS Protocol Version 1.0 <draft-ietf-tls-protocol-02> for
consideration as a Proposed Standard.
o Network Element Service Specification Template
<draft-ietf-intserv-svc-template-03> for consideration as an
Informational RFC.
o Resource ReSerVation Protocol (RSVP) Version 1 Applicability
Statement Some Guidelines on Deployment
<draft-ietf-rsvp-intsrv-analysis-00> for consideration as an
Informational RFC.
o RSVP Extensions for IPSEC Data Flows <draft-berger-rsvp-ext-07>
for consideration as a Proposed Standard.
IMR Editor [Page 4]
Internet Monthly Report April 1997
o Communicating Presentation Information in Internet Messages:
The Content-Disposition Header Field
<draft-moore-mime-cdisp-00> for consideration as a Proposed
Standard.
o RTP Payload Format for H.263 Video Streams
<draft-ietf-avt-rtp-payload-03> for consideration as a Proposed
Standard.
o The Use of RSVP with IETF Integrated Services
<draft-ietf-intserv-rsvp-use-01> for consideration as a
Proposed Standard.
o The Kitchen Sink Resource Record
<draft-eastlake-kitchen-sink-02> for consideration as a
Proposed Standard.
o RSVP Management Information Base <draft-ietf-rsvp-mib-05> for
consideration as a Proposed Standard.
o IPv6 Router Alert Option
<draft-ietf-ipngwg-ipv6router-alert-01> for consideration as a
Proposed Standard.
o RTP Payload for Redundant Audio Data
<draft-perkins-rtp-redundancy-03> for consideration as a
Proposed Standard.
o Resource ReSerVation Protocol (RSVP) -- Version 1 Message
Processing Rules <draft-ietf-rsvp-procrules-00> for
consideration as an Informational RFC.
o Telnet Comport Control Option <draft-clark-telnet-control-02>
for consideration as a Proposed Standard.
o MIME Parameter Value and Encoded Word Extensions: Character
Sets, Languages, and Continuations <draft-freed-pvcsc-02> for
consideration as a Proposed Standard.
o The "data" URL scheme <draft-masinter-url-data-03> for
consideration as a Proposed Standard.
o Returning Values from Forms: multipart/form-data
<draft-masinter-form-data-00> for consideration as a Proposed
Standard.
IMR Editor [Page 5]
Internet Monthly Report April 1997
5. There were 107 Internet-Draft Actions during the month of April:
(ospf) o OSPF Version 2 <draft-ietf-ospf-version2-11.txt>
(svrloc) o Service Location Protocol
<draft-ietf-svrloc-protocol-17.txt>
(none) o Routing Aspects Of IPv6 Transition
<draft-ietf-ngtrans-routing-aspects-03.txt>
(atommib) o Definitions of Supplemental Managed Objects for ATM
Management <draft-ietf-atommib-atm2-09.txt>
(none) o Distance-Vector Multicast Routing Protocol MIB
<draft-thaler-dvmrp-mib-04.txt>
(cat) o Independent Data Unit Protection Generic Security
Service Application Program Interface: C-bindings
<draft-ietf-cat-idup-cbind-03.txt>
(none) o Common NNTP Extensions
<draft-barber-nntp-imp-07.txt>
(cat) o The Simple and Protected GSS-API Negotiation
Mechanism <draft-ietf-cat-snego-04.txt>
(mixer) o Mapping between X.400 and RFC-822/MIME Message
Bodies <draft-ietf-mixer-bodymap-07.txt>
(ion) o Classical IP and ARP over ATM
<draft-ietf-ion-classic2-02.txt>
(none) o Simple Authentication and Security Layer (SASL)
<draft-myers-auth-sasl-10.txt>
(ids) o A Common Schema for the Internet White Pages
Service <draft-ietf-ids-iwps-schema-spec-05.txt>
(ion) o Definitions of Managed Objects for Classical IP and
ARP Over ATM Using SMIv2
<draft-ietf-ion-mib-02.txt>
(http) o PEP - an Extension Mechanism for HTTP
<draft-ietf-http-pep-03.txt>
(applmib) o Definitions of System-Level Managed Objects for
Applications <draft-ietf-applmib-sysapplmib-08.txt>
(ion) o Server Cache Synchronization Protocol (SCSP)
<draft-ietf-ion-scsp-01.txt>
(none) o Internet Security Transform Enhancements
<draft-simpson-ipsec-enhancement-01.txt>
(ids) o Best Current Practice for the Internet White Pages
Service <draft-ietf-ids-ds-bcp-04.txt>
(none) o TCP Control Block Interdependence
<draft-touch-tcp-interdep-01.txt>
(oncrpc) o RPC: Remote Procedure Call Protocol Specification
Version 2 <draft-ietf-oncrpc-remote-03.txt>
(none) o Voice Profile for Internet Mail - version 2
<draft-ema-vpim-05.txt>
(ipngwg) o IPv6 Router Alert Option
<draft-ietf-ipngwg-ipv6router-alert-01.txt>
IMR Editor [Page 6]
Internet Monthly Report April 1997
(agentx) o Agent Extensibility (AgentX) Protocol Version 1
<draft-ietf-agentx-ext-pro-03.txt>
(none) o VENUS - Very Extensive Non-Unicast Service
<draft-armitage-ion-venus-02.txt>
(asid) o Lightweight Directory Access Protocol (v3): UTF-8
String Representation of Distinguished Names
<draft-ietf-asid-ldapv3-dn-03.txt>
(stdguide) o Guide for Internet Standards Writers
<draft-ietf-stdguide-ops-03.txt>
(otp) o OTP Extended Responses <draft-ietf-otp-ext-02.txt>
(none) + The TACACS+ Protocol <draft-grant-tacacs-00.txt>
(mboned) o Administratively Scoped IP Multicast
<draft-ietf-mboned-admin-ip-space-02.txt>
(none) o Internet Cache Protocol (ICP), version 2
<draft-wessels-icp-v2-02.txt>
(none) o PDC/NetApp Backup Protocol
<draft-stager-pdc-netapp-backup-02.txt>
(ion) + Inverse Address Resolution Protocol
<draft-ietf-ion-inarp-update-00.txt>
(none) o PF_KEY Key Management API, Version 2
<draft-mcdonald-pf-key-v2-02.txt>
(snanau) o Definitions of Managed Objects for HPR
<draft-ietf-snanau-hprmib-01.txt>
(snanau) o Definitions of Managed Objects for DLUR
<draft-ietf-snanau-dlurmib-01.txt>
(none) o The Kitchen Sink Resource Record
<draft-eastlake-kitchen-sink-02.txt>
(rps) o Routing Policy Specification Language (RPSL)
<draft-ietf-rps-rpsl-02.txt, .ps>
(drums) o Message Format Standard
<draft-ietf-drums-msg-fmt-01.txt>
(none) o Telnet Comport Control Option
<draft-clark-telnet-control-02.txt>
(none) o IP over MAPOS Version 1
<draft-rfced-info-maruyama-01.txt>
(none) o IMAP4 Referrals
<draft-gahrns-imap-referrals-02.txt>
(calsch) o Core Object Specification - Issues Document
<draft-ietf-calsch-ical-issues-01.txt>
(none) o MAPOS - Multiple Access Protocol over SONET/SDH
Version 1 <draft-maruyama-mapos-sonet-01.txt>
(fax) o Tag Image File Format (TIFF) - Class F
<draft-ietf-fax-tiff-01.txt>
(ion) + Intra-LIS IP multicast among routers over ATM using
Sparse Mode PIM
<draft-ietf-ion-intralis-multicast-00.txt>
IMR Editor [Page 7]
Internet Monthly Report April 1997
(none) o APPN Implementer's Workshop Closed Pages Document
DLSw v2.0 Enhancements
<draft-rfced-info-bryant-01.txt>
(radius) o RADIUS Server MIB
<draft-ietf-radius-servmib-03.txt>
(radius) o RADIUS Client MIB
<draft-ietf-radius-clientmib-02.txt>
(none) o IMAP4 Multi-Accessed Mailbox Practice
<draft-gahrns-imap-practice-01.txt>
(asid) o The LDAP URL Format
<draft-ietf-asid-ldapv3-url-01.txt>
(asid) o The String Representation of LDAP Search Filters
<draft-ietf-asid-ldapv3-filter-01.txt>
(none) o A Stream Cipher Encryption Algorithm
<draft-thayer-cipher-01.txt>
(none) + RETHER : A Protocol for Real-Time Traffic Support
on Ethernet <draft-chitra-rether-00.txt>
(dhc) + An Inter-server Protocol for DHCP
<draft-ietf-dhc-interserver-alt-00.txt>
(none) + Data Over Cable Service (DOCS) Radio Frequency (RF)
Interface Management Information Base (MIB)
<draft-anderson-docs-rf-mib-00.txt>
(ion) + A Distributed NHRP Service Using SCSP
<draft-ietf-ion-scsp-nhrp-00.txt>
(ion) + A Distributed ATMARP Service Using SCSP
<draft-ietf-ion-scsp-atmarp-00.txt>
(none) + UTF-8, a transformation format of Unicode and ISO
10646 <draft-yergeau-utf8-rev-00.txt>
(none) + NETBLT (Network Block Transfer Protocol)
<draft-white-protocol-stack-00.txt>
(asid) + An Approach for Using LDAP as a Network Information
Service <draft-ietf-asid-nis-schema-00.txt>
(none) + Switched Fabric Connection Tap (SFCT) Protocol
<draft-rfced-info-grant-00.txt>
(none) + SBCD Protocol Specification
<draft-rfced-info-ruffen-00.txt>
(none) + Address Resolution and Location Discovery (ARLD)
Protocol <draft-rfced-info-dobbins-00.txt>
(none) + Loop-free Interswitch Message Path (LSMP) Protocol
<draft-rfced-info-benoit-00.txt>
(none) + Network Security For Large Trade Shows
<draft-rfced-info-gwinn-00.txt>
(none) + Network Security For Large Trade Shows
<draft-rfced-info-gwinn-00.txt>
(find) + Hierarchical Extensions to the Common Indexing
Protocol <draft-ietf-find-cip-hierarchy-00.txt>
IMR Editor [Page 8]
Internet Monthly Report April 1997
(asid) + LDAP Control Extension for Server Side Sorting of
Search Results
<draft-ietf-asid-ldapv3-sorting-00.txt>
(none) + HTTP based Spatial and Temporal Searching.
<draft-vangulik-http-search-00.txt>
(intserv) + A Measurement Based Admission Control Algorithm for
Controlled-Load Service
<draft-ietf-intserv-control-flow-00.txt>
(none) + IPSEC File Import/Export Format
<draft-thayer-sec-exp-00.txt>
(none) + SIEVE: A Mail Filtering Language
<draft-showalter-sieve-00.txt>
(none) + Hierarchical HTTP Routing Protocol
<draft-vinod-icp-traffic-dist-00.txt>
(none) + HTTP/1.1 Operation without a Clock
<draft-lawrence-http-noclock-00.txt>
(none) + The Java LDAP Application Program Interface
<draft-weltman-java-ldap-00.txt>
(urn) + Using Existing Bibliographic Identifiers as Uniform
Resource Names <draft-ietf-urn-biblio-00.txt>
(acap) + ACAP TYPE Extension
<draft-ietf-acap-type-ext-00.txt>
(none) + Comparison of Tag Switching and Cell Switch Router
<draft-ohba-tagsw-vs-csr-00.txt>
(none) o XODL: External Object Description Language
<draft-long-external-obj-lang-01.txt>
(none) + Application of Internet Cache Protocol (ICP),
version 2 <draft-wessels-icp-v2-appl-00.txt>
(disman) + Event MIB <draft-ietf-disman-event-mib-00.txt>
(none) + A MAPOS version 1 Extension - Switch-Switch
Protocol <draft-rfced-info-mitsuru-00.txt>
(disman) + Expression MIB
<draft-ietf-disman-express-mib-00.txt>
(disman) + Management Target MIB
<draft-ietf-disman-mgt-target-mib-00.txt>
(disman) + Notification MIB
<draft-ietf-disman-notify-mib-00.txt>
(mboned) + Administratively Scoped IP Multicast
<draft-ietf-mboned-oops-disregard-00.txt>
(rsvp) + Partial Service Deployment in the Integrated
Services Architecture
<draft-ietf-rsvp-partial-service-00.txt>
(none) + Schema for Storing Calendaring Information in a
Directory Service <draft-dun-calsch-schema-00.txt>
(none) + A Primer On Internet and TCP/IP Tools and Utilities
<draft-rfced-info-kessler-00.txt>
(none) + The CAST-128 Encryption Algorithm
<draft-rfced-info-adams-00.txt>
IMR Editor [Page 9]
Internet Monthly Report April 1997
(none) + MAPOS Version 1 Assigned Numbers
<draft-rfced-info-murakami-00.txt>
(none) + A MAPOS version 1 Extension - Switch-Switch
Protocol <draft-rfced-info-mitsuru-00.txt>
(ipsec) + The ESP RC5-CBC Algorithm
<draft-ietf-ipsec-esp-rc5-cbc-00.txt>
(acap) + ACAP Datatyping and Datatyping Discovery
<draft-ietf-acap-dewinter-dtype-00.txt>
(none) + E-Mail Headers to Facilitate Mailing List
Subscriptions and Unsubscriptions
<draft-costales-subscribe-00.txt>
(none) + THE TRANSMISSION OF IP OVER THE VERTICAL BLANKING
INTERVAL OF A TELEVISION SIGNAL
<draft-panabaker-ip-vbi-00.txt>
(none) + DHCP Options For Host System Characteristics
<draft-dittert-host-sys-char-00.txt>
(snmpv3) + Architecture for the Next Generation Simple Network
Management Protocol (SNMPng)
<draft-ietf-snmpv3-next-gen-arch-00.txt>
(printmib) + Job Monitoring MIB - V0.81
<draft-ietf-printmib-job-monitor-00.txt>
(avt) + RTP Payload Format for MPEG1/MPEG2 Video
<draft-ietf-avt-mpeg-new-00.txt>
(none) + Security-Oriented Extension to Mobile IP (SOMIP)
<draft-chuahli-mobileip-somip-00.txt>
(none) + Referral Whois (RWhois) Protocol V1.5
<draft-rfced-info-williamson-00.txt>
(none) + SNDM Protocol Specification
<draft-rfced-info-livingston-00.txt>
(none) + IP Header Compression over PPP
<draft-engan-ip-compress-00.txt>
(snmpv3) + Local Processing Model for the Next Generation
<draft-ietf-snmpv3-lpm-00.txt>
(none) + IMAP4 Namespace
<draft-gahrns-imap-namespace-00.txt>
IMR Editor [Page 10]
Internet Monthly Report April 1997
7. 13 RFCs were published during this period
RFC2100 I (none) The Naming of Hosts
RFC2116 I (ids) X.500 Implementations Catalog-96
RFC2129 I (none) Toshiba's Flow Attribute Notification
Protocol (FANP) Specification
RFC2130 I (none) The Report of the IAB Character Set
Workshop held 29 February - 1 March, 1996
RFC2131 DS (dhc) Dynamic Host Configuration Protocol
RFC2132 DS (dhc) DHCP Options and BOOTP Vendor Extensions
RFC2133 I (ipngwg) Basic Socket Interface Extensions for IPv6
RFC2135 I (none) Internet Society By-Laws
RFC2136 PS (dnsind) Dynamic Updates in the Domain Name System
(DNS UPDATE)
RFC2137 PS (dnssec) Secure Domain Name System Dynamic Update
RFC2138 PS (radius) Remote Authentication Dial In User Service
(RADIUS)
RFC2139 I (radius) RADIUS Accounting
RFC2140 I (none) TCP Control Block Interdependence
IMR Editor [Page 11]
Internet Monthly Report April 1997
INTERNET PROJECTS
-----------------
INTERNIC
--------
REGISTRATION SERVICES
Current Status
April:
Email: 372,040
Phone: 49,305
Updates: 145,812
Gopher connections: 203,907 retrievals: 457,367
WAIS connections: 773,665 retrievals: 410,002
FTP connections: 1,104,582 retrievals: 2,211,133
Telnet: 1,263,547
Http: 57,626,159
Whois Queries: 19,814,905
Total Registrations: 116,366
Rich Landers <richl at internic.net>
INTERNIC DIRECTORY AND DATABASE SERVICES
As planned, we moved our primary server to a new location on April
25. The primary server was out of service for most of the day, but
both backups were available.
The Netfind Seed Database for April contains about 1.3 million
entries. Growth was somewhat less than normal since we changed the
database generation process to improve the accuracy of the
database. We continue to generate the database from data
maintained by the registries, but we also check to see if the
domain name defined by the record actually exists in DNS. Since
this check requires a large number of DNS lookups, we do not check
every entry every month. We do a different part of the database
each month.
IMR Editor [Page 12]
Internet Monthly Report April 1997
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at 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 <rvh at ds.internic.net>
THE US DOMAIN REGISTRY
The US Domain registration form is now available online at
http://www.isi.edu/us-domain.
The US Domain has the maps of all the delegated special domains
online at http://www.isi.edu/us-domain.
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).
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 of that locality.
A new policy has been added regarding the charges for the domain
name passed on during delegation. The administrator of the
locality has to notify one year in advance before charging for
those domains.
US DOMAIN ADMINISTRATIVE INFORMATION
====================================
EMAIL/FAX 2910
PHONE 450
-----------------------------
Total Contacts 3360
IMR Editor [Page 13]
Internet Monthly Report April 1997
DELEGATIONS(3rd level) 149
DELEGATIONS(4th level) 61
FORWARDED REQUESTS: 1273
OTHER US DOMAIN MSGS: 1877
-----------------------------
Total 3360
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.
MAJOR SUBDOMAINS DELEGATED
==========================
K12 CC TEC STATE LIB MUS GEN DST COG
===================================================================
52 38 34 47 40 26 26 10 6
===================================================================
THIRD LEVEL DELEGATIONS
========================
LIB.WY.US. Libraries, Wyoming.
LOCALITIES
==========
We delegated 149 localities in Arizona, Alabama, Arkansas,
California, Georgia, Illinois, Kansas, Pennsylvania, Indiana,
Massachusetts, Maryland, Missouri, Michigan, Minnesota, Mississipi,
Nebraska, New Hampshire, North Carolina, New Jersey, New York,
Ohio, Virginia, Wisconsin and Wyoming this month.
IMR Editor [Page 14]
Internet Monthly Report April 1997
OTHER US DOMAIN DELEGATIONS THIS MONTH
======================================
OPENDOOR.CORVALLIS.OR.US. CI.TANEYTOWN.MD.US.
WATSONVILLE.LIB.CA.US. CITYHALL.CI.CHENOA.IL.US.
ADAMS-MORGANf.WASHINGTON.DC.US. DUPONT-CIRCLE.WASHINGTON.DC.US.
M-STREET-GEORGETOWN.WASHINGTON.DC.US. NEW-YORK-AVE.WASHINGTON.DC.US.
MARYLAND-AVE.WASHINGTON.DC.US. EMBASSY-ROW.WASHINGTON.DC.US.
INDEPENDENCE-AVE.WASHINGTON.DC.US. P-STREET.WASHINGTON.DC.US.
CONSTITUTION-AVE.WASHINGTON.DC.US. POTOMAC-STREET.WASHINGTON.DC.US.
NEW-JERSEY-AVE.WASHINGTON.DC.US. K-STREET.WASHINGTON.DC.US.
VERMONT-AVE.WASHINGTON.DC.US. VIRGINIA-AVE.WASHINGTON.DC.US.
WES-WATKINS.TEC.OK.US. G-STREET.WASHINGTON.DC.US.
14TH-STREET.WASHINGTON.DC.US. 19TH-STREET.WASHINGTON.DC.US.
COLUMBUS-CIRCLE.WASHINGTON.DC.US. SCOTT-CIRCLE.WASHINGTON.DC.US.
MT-VERNON-CIRCLE.WASHINGTON.DC.US. H-STREET.WASHINGTON.DC.US.
THOMAS-CIRCLE.WASHINGTON.DC.US. HAMILTON-PLACE.WASHINGTON.DC.US.
LAFAYETTE-SQUARE.WASHINGTON.DC.US. STATE-PLACE.WASHINGTON.DC.US.
WEST-EXECUTIVE-DRIVE.WASHINGTON.DC.US. E-STREET.WASHINGTON.DC.US.
EAST-EXECUTIVE-DRIVE.WASHINGTON.DC.US. CI.CLAY-CENTER.NE.US.
MADISON-DRIVE.WASHINGTON.DC.US. CHAMBER.AMHERST.VA.US.
TREEBEARD.BONE-CAVE.TN.US. YHSCNJ.HIGHLAND-PARK.NJ.US.
ARDMOREPUBLIC.LIB.OK.US. SBVWCD.DST.CA.US.
EVRCD.DST.CA.US. RESERVATIONS.CHAMA.NM.US.
HCS.HUDSONVILLE.MI.US. CO.CLARKE.VA.US.
CI.ISSAQUAH.WA.US. CTSRR.CHAMA.NM.US.
HUNT.PORTLAND.OR.US. WPUMC.PORTLAND.OR.US.
CI.NORTH-HEMPSTEAD.NY.US. BARRACUDAS.PORTLAND.OR.US.
CI.PETERSBURG.NE.US. KEITHWILHITE.SCROGGINS.TX.US.
CI.GREENFIELD.NH.US. VERMILIONNET.ORR.MN.US.
RESIDENT-DNS.TWINSBURG.OH.US. JAMES.GRAHAM.TX.US.
RESIDENT-DNS.VALLEY-CITY.OH.US. CI.WEST-POINT.NE.US.
RESIDENT-DNS.CHATHAM.OH.US. AQUACULTURE-SCH.TEC.CT.US.
CONNECTICUT-AVENUE.WASHINGTON.DC.US.
----------------------------------------------------------------------
URL: http://www.isi.edu/us-domain/
Shanthi Ranganathan (US-Domain at ISI.EDU)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IMR Editor [Page 15]
Internet Monthly Report April 1997
MERIT INTERNET ENGINEERING
--------------------------
This report summarizes April 1997 activities of Merit's Internet
Engineering group on behalf of the Routing Arbiter (RA) service and
other projects.
Two new mailing lists have been created by the Route Server Next
Generation project. Both lists were established in response to a
discussion at the February 1997 Route Server BOF, held at the San
Francisco NANOG. The first list, RS-discuss at merit.edu, provides a
forum for discussing Route Server technology, pros and cons of the
service, issues with the existing service, and suggestions for
improvement. Abha Ahuja, Brad Robertson, Bill Norton, and Jake
Khuon of the RSng staff hope that the list will stimulate broad
discussion in the Internet community, addressing not only specific
RSng issues, but also issues related to the use of Route Servers
worldwide. The second list, RS-announce at merit.edu, will be used for
announcements of Route Server maintenance and outages. We
recommend that all organizations peering with the Route Servers at
the exchange points subscribe to this list.
To subscribe to the new lists, send a message to
majordomo at merit.edu with the following in the body of the message:
subscribe rs-discuss
or:
subscribe rs-announce
For more information about the Route Server Next Generation
project, see:
http://www.rsng.net
Merit staff members Sue Hares, Bill Norton, Craig Labovitz, Jerry
Winters, and Jake Khuon attended the 38th IETF in Memphis during
the week of December 9. Hares, who has been proposed as Chair of
the Internet Research Task Force's Routing Research Group, chaired
the Inter-Domain Routing Working Group meeting. Labovitz
demonstrated the NetNow and ASExplorer tools to ISPs and other
researchers. IETF was also the site of an informal Merit GateD
Consortium meeting led by Hares.
IMR Editor [Page 16]
Internet Monthly Report April 1997
Merit's Routing Arbiter Database support staff is playing an
integral role in implementing the next-generation Routing Policy
Specification Language (RPSL), which will replace RIPE-181 (RFC
1786) as the language used to express routing policy in the RADB
and other Internet Routing Registry databases. The new language is
being developed by the IETF Routing Policy System Working Group,
which is chaired by Cengiz Alaettinoglu of the USC Information
Sciences Institute and Daniel Karrenberg of the RIPE Network
Coordination Centre. RPSL offers many powerful new capabilities,
most notably the ability to express routing policy much more
precisely than in RIPE-181.
Craig Labovitz' paper, "Internet Routing Instability," has been
accepted to SIGCOMM '97. Co-authored with student Robert Malan and
Professor Farnam Jahanian of the University of Michigan Department
of Electrical Engineering and Computer Science, the paper examines
the BGP updates exchanged between ISP border routers at the MAE-
East, AADS, Sprint, and PacBell NAPs, and at MAE-West. The authors
describe several unexpected trends in routing instability, and
examine a number of anomalies and pathologies observed in the
exchange of inter-domain routing information. The researchers then
show that the volume of these routing updates is several orders of
magnitude more than expected and that the majority of this routing
information is redundant, or pathological. Furthermore, the
analysis reveals several unexpected trends and ill-behaved
systematic properties in Internet routing. Several explanations
for these anomalies are put forth and evaluated with regard to
their potential impact on the Internet infrastructure.
The National Science Foundation funded much of Labovitz' research
as part of Merit's Routing Arbiter project, a partnership with the
USC Information Sciences Institute.
Susan R. Harris (srh at merit.edu)
UCL
----
Our CAIRN Link is now operational.
A number of IETF WGs were attended in Memphis, as well as LSMA and
IDMR being co-chaired. We presented at others, and wrote up the
minutes for the new IRTF Reserarch Group on Reliable Multicast.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
IMR Editor [Page 17]
Internet Monthly Report April 1997
IANA REPORT
-----------
Here is the IANA monthly report for April 1997:
AS Numbers: Blocks 1
Cable Address Blocks 2
Country Codes 2
DHCP Options 1
IPv4 Address Space 3
Media Types 1
Multicast Addresses: Individual 2
Multicast Addresses: Blocks 1
Private Enterprise Numbers 65
Port Assignments 55
SMI Numbers 5
Josh Elliott <elliott at isi.edu>
RFC EDITOR REPORT
-----------------
This is a summary of Request for Comments Editor activity for the
month of April, 1997:
TIME IN QUEUE
DOCUMENTS New* 30 days 60 days 90 days TOTAL
------------------------------------------------------------------
|
Beginning of 0 4 2 10 | 38
month |
|
New 22 0 0 0 | 22
|
|
Processed 5 4 2 2 | 13
------------------------------------------------------------------
|
End of month 17 0 0 8 | 25
* New RFCs added to queue throughout the month
IMR Editor [Page 18]
Internet Monthly Report April 1997
The Requests for Comments (RFCs) are a series of notes, started in
1969, about the Internet (originally the ARPANET). The notes
discuss many aspects of computing and computer communication
focusing in networking protocols, procedures, programs, and
concepts, but also including meeting notes, opinion, and sometimes
humor. The specification documents of the Internet protocol suite,
as defined by the Internet Engineering Task Force (IETF) and its
steering group (the IESG), are published as RFCs.
RFCs-to-be are edited by the RFC Editor. RFCs enter the RFC
Editor's work queue either by an action of the IESG or by
independent submission. Most independent submissions are referred
to the IESG to check for overlap with IETF work. The IESG might
put a hold on a document to gather more input from its members.
The wait for an RFC to be published varies as there can be
unforeseen complications (typically editorial matters that need
clarification from the author). Documents can be removed from the
publication queue if they are found to be insufficient or incorrect
or if the IESG asks the author to join work already in progress in
the IETF.
Mary Kennedy <rfc-ed at isi.edu>
IMR Editor [Page 19]
Internet Monthly Report April 1997
CALENDAR
--------
Last update 05/08/97
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:
<meeting-planning at ietf.org>
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
-------
<http://www.ietf.org/home.html> Click on the link for "meetings" and
you should find an entry "listing of other Internet related events".
************************************************************************
1997
-----------
May 11 TERENA Technical Committee Edinburgh, Scotland
May 11-12 TERENA TF and WG Groups Edinburgh, Scotland
May 12-15 8th JENC8 Edinburgh, Scotland
May 12-15 MWCN '97 First Int'l Workshop on
Mobile & Wireless Communications
Networks Paris, France
IMR Editor [Page 20]
Internet Monthly Report April 1997
May 12-16 IFIP/IEEE San Diego, CA
May 13-14 EWOS Assembly Brussels
May 15-16 TERENA General Assembly Edinburgh, Scotland
May 19-21 NOSSDAV'97 - 7th Int'l Workshop on Ntwk & Oper
for Digital Audio & Video St. Louis, MO
May 21-23 RIPE 27 Dublin
May 21-23 ECMAST'97 (European Conf. on
Multimedia Applications, Services,
and Techniques Milano, Italy
May 27-29 IS&N '97 4th Int'l Conf. on
Intelligence in Services & Networks Como, Italy
May 28-30 ETW'97 IEEE Europen Test Wrkshop Cagliari,Italy
May 28-30 Web Developer '97 Chicago, IL
Jun. 2-3 IEEE Internet Computing New Orleans, LA
Jun. 2-6 IEEE Multimedia Systems '97 Ottawa, CANADA
Jun. 3-5 Internet World Mexico '97 Mexico City, Mexico
Jun. 6 DANTE Shareholders Amsterdam
Jun. 8-12 ICC '97 (joint with ENM) Montreal, CANADA
Jun. 9 TERENA Executive Committee Amsterdam
Jun. 9-13 OIW (Firm)
Jun. 9-13 ANSI X3T11 (host by Boeing) Seattle, WA
Jun. 10-12 IEEE 802.10 Interim Meeting Alexandria, VA
Jun. 11-12 IEEE Enterprise Networking
Miniconference 1997 (ENM-97) Montreal, CANADA
Jun. 16-18 EEMA'97 Netherlands
Jun. 16-19 3rd Conf on Object-Oriented
Technologies and Systems
(COOTS '97) Portland, Oregon
Jun. 16-20 EWOS Workshops Brussels
Jun. 17 EEMA General Assembly Maastricht
Jun. 23 CCIRN Kuala Lumpur
Jun. 23-25 4th IEEE Wrkshp on the Architecture and
Implementation of High Performance
Communication Systems (HPCS'97) Sani Beach, Greece
Jun. 15-22 Internet Society's Workshop on
Network technology for
countries in the early stages
of Internet networking Kuala Lumpur, Malaysia
Jun. 24 Internet Society's Education
(K-12) Workshop Kuala Lumpur, Malaysia
Jun. 24 Internet Society's African
Networking Symposium Kuala Lumpur, Malaysia
Jun. 24-27 INET '97 Kuala Lumpur, Malaysia
Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI
Jul. 7-11 24th Int'l Colloquium on Automata,
Languages & Programming
(ICALP '97) Bologna, Italy
Jul. 14-17 5th TCL/TK Workshop Boston, MA
IMR Editor [Page 21]
Internet Monthly Report April 1997
Jul. 14-18 ANSI X3T10 '97
Jul. 14-17 APPN Implementers Workshop San Jose, CA
Jul. 17-19 VTIC-97 San Jose CA
Jul. 20-25 ATM Forum Montreal, CANADA
Jul. 23-26 ACM DL '97 2nd ACM Int'l
Conf. on Digital Libraries Philadelphia, PA
Jul. 24-25 DMS '97 Vancouver, 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 DCI's Internet Expo Boston, MA
Aug. 13-15 IEEE 25th Annual Int'l Computer Software and
Application Conference Washington, DC
Sep. RIPE28 TBD
Sep 2-5 1997 Int'l Conference
Intelligent Networks and
Intelligence in Networks Paris, France
Sep. 8-12 ANSI X3T10 '97
Sep. 8-12 OIW (Firm)
Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland
Sep. 10-12 IDMS '97 w/ ACM SIGMM, GMD, IEEE
Darmstadt, Germany
Sep. 11-12 4th Int'l Workshop on
Community Networking (IEEE) Atlanta, Georgia
Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France
Sep. 16-17 EWOS Assembly Brussels
Sep. 21-26 ATM Forum Paris, France
Sep. 26-30 3rd ACM/IEEE on Mobile Computing
& Networking 1997 (MobiCom'97) Budapest, Hungary
Oct. 6-10 ANSI X3T11 (host by FSI) Tucson, AZ
Oct. 7-10 COMDEX Internet '97 and Object World '97
Internet Forum Europe (IFE) & Object
World Frankfurt (OWF) Frankfurt, Germany
Oct. 15-17 ACM SIGPLAN - Conf. on
Domain-Specific Languages Santa Barbara, CA
Oct. 23-24 TERENA General Assembly Madrid
Oct. 23-25 ETSI Nice, France
Oct. 26-31 LISA '97 - 11th Systems
Administration Conference San Diego, CA
Oct. 27-31 EWOS Workshops Brussels
Oct. 28-31 IEEE Int'l Conf. on
Network Protocols Atlanta, GA
Nov. 3-5 Int'l Test Conference 1997
Sheraton Washington Hotel Washington, DC
Nov. 3-7 ANSI X3T10 '97
IMR Editor [Page 22]
Internet Monthly Report April 1997
Nov. 3-7 SPIE Int'l Symposium
Voice, Video & Data Communications
Conf. on Performance & Control of
Network System - Special Session on
Switching & Traffic Mgmt in
High Speed Networks Dallas, TX
Nov. 3-7 2nd French/Brazilian Symposium
on Distributed System Architectures:
Telecommunication Multimedia Architectures
Ceara, Brazil
Nov. 8-14 ACM MULTIMEDIA '97 Seattle, WA
Nov. 10-14 IEEE 802 Plenary Queen Elizabeth, Montreal
Nov. 12-13 CEN/CENELEC/ETSI Brussels
Nov. 19-21 ICCC'97 Cannes, France
Nov. 24-26 PROMSMmNet '97
Multimedia Networking Santiago, Chile
Nov. 30-Dec 5 ATM Forum Singapore
Dec. 1-3 30th IEEE/ACM Int'l Symposium
on Microarchitecture RTC, NCA
Dec. 1-5 ANSI X3T11 (host by DPT) Orlando, FL
Dec. 2-3 EWOS Assembly Brussels
Dec. 8-12 40th IETF (tentative) Washington, DC
Host by NewBridge
Dec. 8-12 OIW (Firm)
Dec. 9-12 WITS (Workshop on Internet Technology
and Systems) Monterey, CA
TELECOM '97 Asia (Venue and Dates to be Determined)
1998
-----------
Jan 6-8 W3C Interest Group Mtg TBA
Jan 26-29 7th Security Symposium San Antonio, TX
Feb. 8-13 ATM Forum TBA
Feb 7-9 DCI'S Internet Expo San Jose, CA
Mar. 9-13 IEEE 802 Plenary Irvine, CA
Mar. 29-Apr 2 IEEE INFOCOM '98 - Hotel Nikko San Francisco, CA
Apr. 3-4 IEEE "OPENARCH '98" San Francisco, CA
Apr. 12-17 WWW7 Brisbane, Australia
Apr. 19-24 ATM Forum TBA
Apr 20-22 W3C Interest Group Mtg TBA
SPRING 1998 TELECOM '97 Africa Midrand, South Africa
Spring 1998 41st IETF (Tentative) TBD
Summer 1998 42nd IETF (Tentative) Chicago, IL
Jun 13-17 USENIX '98 Technical Conf. New Orleans, LA
Jun 16-18 DCI's Internet Expo Chicago, IL
Jul. 6-10 IEEE 802 Plenary San Diego, CA
Jul. 26-31 ATM Forum TBA
IMR Editor [Page 23]
Internet Monthly Report April 1997
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
Sep 1-3 DCI's Internet Expo Boston, MA
Oct. 4-9 ATM Forum TBA
Oct 20-22 W3C Interest Group Mtg TBA
Nov. 9-13 IEEE 802 Plenary Albuquerque, NM
Nov. 30-Dec 4 ATM Forum TBA
Dec. 6-11 12th Systems Administration Conf.
(LISA '98) Boston, MA
1999
-----
Feb 23-25 W3C Interest Group Mtg TBA
May 31-Jun 4 WWW8 Toronto, CANADA
Jun 4-6 W3C Interest Group Mtg TBA
Sep 21-23 W3C Interest Group Mtg TBA
Oct. 8-14 TELECOM '99 Geneva, Switzerland
IMR Editor [Page 24]
Internet Monthly Report April 1997
TERENA CALENDAR OF EVENTS
--------------------------
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 <secretariat at terena.nl>.
**********************************************************************
NAME / DATE LOCATION
TERENA General Assembly
GA7
15-16 May Edinburgh
GA8
23-24 October Madrid
TERENA Executive Committee
9 June Amsterdam
TERENA Technical Committee
11 May Edinburgh
TF and WG Groups
11-12 May Edinburgh
TF-TEN
15-16 May Edinburgh
Tutorial Meetings
16 May Edinburgh
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CEN/CENELEC/ETSI
----------------
12-13 November Brussels
CCIRN
-----
23 June Kuala Lumpur
IMR Editor [Page 25]
Internet Monthly Report April 1997
DANTE Shareholders
------------------
6 June Amsterdam
EEMA
----
General Assembly
17 June Maastricht
ETSI
----
Seminar
5-7 May Brussels
EWOS
----
EWOS Assembly 3, 13-14 May Brussels
EWOS Assembly 4, 16-17 September "
EWOS Assembly 5, 2-3 December "
Workshops
38: 16-20 June Brussels
39: 27-31 October "
IETF
---
39, 11-15 August Munich, Germany
40, 8-12 December (tentative) Washington, DC
43, 6-11 December 1998 Adelaide,
Australia
NATO
----
Workshop
5-9 May Edinburgh
RIPE
----
RIPE27
21-23 May Dublin
RIPE28
September tbd
IMR Editor [Page 26]
Internet Monthly Report April 1997
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TERENA CONFERENCES
JENC8 - 8th Joint European Networking Conference
"Diversity and Integration: The New European Networking Landscape"
12-15 May
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
* Security and Management Issues
* Information Systems and Distributed Applications
* Economic and Political Issues
Programme to be found on:
http://www.terena.nl/conf/jenc8/programme-main.html
For further 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: <jenc8-sec at terena.nl>
http://www.terena.nl/jenc8
or
JENC8 Local Organization
c/o Concorde Services Ltd
Unit 5, SECC
Glasgow, G3 8YW, Scotland
email: <jenc8 at ed.ac.uk>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
IMR Editor [Page 27]
Internet Monthly Report April 1997
OTHER CONFERENCES
The Arab World and the Information Society - Regional Symposium
---------------------------------------------------------------
5-9 May
Tunis, Tunisia
Organized by ITU and UNESCO, in cooperation with the government of
Tunisia
and in the framework of RAITNET (Regional Arab Information Technology
Network)
For information see www site: http://www.irsit.rnrt.tn/symposium
and/or email <symposium at irsit.rnrt.tn>
"Flexible Learning on the Information Superhighway 1997" (FLISH97)
------------------------------------------------------------------
19-20 May
Sheffield Hallam University, Sheffield, UK
Including the traditional teaching uses of the Internet (computer
conferencing and the Web), will be the whole range of services on the
Internest, as well as real-time audio and video
services migrating from ISDN and the broadband services.
Information and applications obtainable from Hallam University at:
fax number +44 114 253 3161
IS&N '97
4th International Conference on Intelligence in Services & Networks
-------------------------------------------------------------------
27-29 May
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
IMR Editor [Page 28]
Internet Monthly Report April 1997
Online Cooperation Berlin
International Conference on Teleworking
---------------------------------------
June
Hotel Intercontinental, Berlin, Germany
Aims to provide a showcase and forum for leading edge development in
cooperation
services as well as building on the interest being shown in Europe
"online
work",
cooperation technologies and internet-based sersvices.
Organized by ICEF
For information email <100770.3.3 at compuserve.com>
ECOOP'97
11th European Conference on Object-Oriented Programming
-------------------------------------------------------
9-13 June
University of Jyvdskyld, Jyvdskyld, Finland
For information see www page:
http://www.trese.cs.utwente.nl/ecoop97 or
http://www.ecoop97.jyu.fi
EEMA'97 - Annual Conference and Exhibition
Electronic Commerce and Messaging in Europe, "The Premier European
Forum
for Advanced Business"
------------------------------------------------------------------
15-18 June
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 see www site: http://www.eema.org/
IMR Editor [Page 29]
Internet Monthly Report April 1997
MADEIRA'97
2nd International Distributed Conference on Network Interoperability
--------------------------------------------------------------------
16-18 June
Madeira
Organized by ACTS project GINA and sponsored by the European
commission,
this conference is open for all involved in networking solutions for
information society.
Paper submission by 28 February
Contact for information and submissions email <rao at telscom.ch
Local organizer email <rp at cet.pt
BBCC - Broadband Communications for Research and Education -
Collaboration between Russia and the European Union
------------------------------------------------------------
17-18 June
Moscow, Russia
Organized by EC DG-XIII/B, RFBR, N.D. Zelinsky Institute, Open Society
Institute.
Theme of the conference is the building of broadband networks in
Russia and
their use
for computer-supported cooperative work (CSCW) in research and
education
All information about this conference available on URL:
http://www.free.net/Projects/NICE/BBCC/main.en.html
INET'97 - Workshop
------------------
15-21 June
Kuala Lumpur, Malaysia
Focus of the workshop will be upon assisting countries that are either
not
yet connected to the Internet or are in the process of developing and
enhancing an initial national Internet.
For copy of announcement e-mail <workshop-apply at isoc.org>
Apply for admission by 7 February 1997 to e-mail
<workshop-application at isoc.org>
IMR Editor [Page 30]
Internet Monthly Report April 1997
INET'97
7th Annual Internet Society Conference
---------------------------------------
24-27 June
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.
-information on INET97, the K-12 workshop, the Tutorials, and the
associated Developing Countries Workshop, along with an abstract
submission
form, can be found on the ISOC web page:
http://isoc.org/inet
or, for information via e-mail:
- for details of submission procedure email
<inet-program-interest at isoc.org>
- for other information email <inet97 at isoc.org>
FIRST - Forum of Incident Response and Security Teams
9th Annual Computer Security Incident Handling Workshop
-------------------------------------------------------
23-27 June
Marriott Hotel, Bristol, England
This annual workshop is part of FIRST's ongoing program of education
and
raising awareness for its members and others.
Paper submission deadline 15 January
For information see: http://www.first.org/
NORDUnet ' 97 - Nordic Internet Conference
------------------------------------------
29 June - 1 July
Reykjavik, Iceland
Topics: Organization of the Internet; Internet and Society;
Information
Services;
Internet Technical Development
For information see web page: http://www.isnet.is/nordunet97/
or email Sigurdur Jonsson <sigjons at isnet.is>
IMR Editor [Page 31]
Internet Monthly Report April 1997
Seminar on Internet and UNIX Security
-------------------------------------
2 July
Reykjavik, Iceland
Seminar by Rik Farrow, instructor, author of UNIX System Security
Information on web page: http://www.isnet.is/nordunet97/
FMOODS'97 - Second IFIP Interrnational Workshop on
Formal Methods for Open-based Distributed Systems
-----------------------------------------------------
21-23 July
Canterbury, United Kingdom
Objective is to provide an integrated forum for the presentation of
research in several related fields.
Paper submission deadline 14 January 1997
For all information: e-mail <fmoods97-request at uck.ac.uk> or
web page: http://alethea.u,c.ac.uk/Dept/Computing/Research/NDS/FMOODS/
ICTE Oslo 1997
4th Annual International Conference on Technology and Education
---------------------------------------------------------------
10-13 August
University of Oslo, Norway
For all information about the programme/registrations, see web site:
http://www.icte.org
For queries, email: <icte at icte.org>
Eleventh International Unicode Conference & Global Computing Showcase
---------------------------------------------------------------------
3-5 September
San Jose, CA, USA
Software Development and the Internet: Going Global with Unicode (R)
This conference will address all issues and topics relating to global
computing with Unicode
Paper submission by 18 April
For information see www site: http://www.unicode.org
or email: <info at global-conference.com>
IMR Editor [Page 32]
Internet Monthly Report April 1997
Forum: Europe/North America/Japan
Smart Communities : Shaping the Future
Economic Development in a Global Information Society
----------------------------------------------------
8-12 September
Nice, France and Rome, Italy (simultanteously)
Promoted by DGXIII. Will cover a wide range of issues and development
in
the field of
telecommunications policy and ICT applications.
Further informations to become available.
IDMS'97
European Workshop on Interactive Distributed Multimedia Systems and
Telecommunication Services
-------------------------------------------------------------------
10-12 September
Darmstadt, Germany
In cooperation with ACM SIGM, Gesellschaft fuer Informatik, GMD, IEEE
Computer Society and VDE ITG
The purpose of this 4th 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.
Paper submission due 1 March 1997
For additional information se www: http://www.th-darmstadt.de/idms97
9th Annual EAIE Conference
(European Association for International Education)
--------------------------------------------------
"Boundaries and Bridges in International Education"
20-22 November
Barcelona, Spain
For further information contact:the EAIE Secretariat at:
email: <eaie at eaie.nl
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
IMR Editor [Page 33]
Received: from ietf.org by ietf.org id aa16753; 23 May 97 15:42 EDT
Received: from yourpalsat.netmeg.net by ietf.org id aa16611; 23 May 97 15:37 EDT
Received: from greatkhan.netmeg.net (greatkhan.netmeg.net [208.139.83.2])
by yourpalsat.netmeg.net (8.8.5/8.8.4) with SMTP
id PAA28236 for <ietf at ietf.org>; Fri, 23 May 1997 15:33:30 -0400
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0wV05q-0001VZC; Fri, 23 May 97 15:33 EDT
Message-Id: <m0wV05q-0001VZC at netmeg.net>
Date: Fri, 23 May 97 15:33 EDT
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: Anti Spam legislation
In-Reply-To: <3.0.1.32.19970523092337.009d92c0 at dilbert.is.chrysler.com>
Source-Info: From (or Sender) name not authenticated.
Robert Moskowitz <rgm3 at chrysler.com> wrote:
>For those of you involved with dealing with SPAM. Here is something for
>you to chew on.
Actually, there are two U.S. bills currently in the works, each taking
a very different approach to the problem. There's the one from Senator
Murkowski that was included in the message you forwarded. Then there's
one from Representative Chris Smith which was developed with the help
of CAUCE (<http://www.cauce.org/>).
Info on Rep Smith's bill...
<http://www2.cauce.org/Smith.bill.intro.html>
Info on Senator Murkowski's bill...
<http://www.senate.gov/~murkowski/commercialemail/>
For folks who want to argue the pros and cons, there are a number of
threads discussing these bills in <news:news.admin.net-abuse.email>
Matt
Received: from ietf.org by ietf.org id aa17140; 23 May 97 15:47 EDT
Received: from zephyr.isi.edu by ietf.org id aa17009; 23 May 97 15:45 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
id <AA23713>; Fri, 23 May 1997 12:41:59 -0700
Message-Id: <199705231941.AA23713 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2146 on U.S. Government Internet Domain Names
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 23 May 97 12:41:58 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2146:
Title: U.S. Government Internet Domain Names
Author: Federal Networking Council
Date: May 1997
Mailbox: execdir at fnc.gov
Pages: 12
Characters: 26564
Updates/Obsoletes: 1816
URL: ftp://ds.internic.net/rfc/rfc2146.txt
This memo provides an update and clarification to RFC 1816. This
document describes the registration policies for the top-level domain
".GOV".
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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at 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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <970523123057.RFC at ISI.EDU>
SEND /rfc/rfc2146.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2146.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970523123057.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa18113; 23 May 97 16:26 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11746;
23 May 97 16:26 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA26960 at pad-thai.cam.ov.com>; Fri, 23 May 1997 18:48:57 GMT
Message-Id: <F0C5060A8699D011A2B100805F14C869C75D89 at RED-75-MSG.dns.microsoft.com>
From: "Mike Swift (NT)" <mikesw at microsoft.com>
To: D.Pinkas at frcl.bull.fr, Martin.Rex at sap-ag.de
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Subject: Snego & GSS V2
Date: Fri, 23 May 1997 11:47:47 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Precedence: bulk
I think that by specifying the logic used by the server will limit the
usefulness of this draft - if the defined behavior doesn't match what is
needed by a particular software vendor, they will have no choice but to
go outside of SPNEGO. However, by just recommending a policy for the
target and not mandating it we can increase the usage of SPNEGO. I don't
think that being able to verify that two implementations behave the same
is enough of a justification to limit the protocol - while it is useful,
the fact that the client & server can authenticate should be the
overriding concern. One way to think about this is that the target's
ordering of mechanisms is dynamic - no where does it mention that the
list must be fixed for all clients. The target can re-order its list of
mechanisms (in whatever way it feels is reasonable and secure) based on
the initial token sent by the client.
As to the issue of negotiating confidentiality & integrity, I think
these are among the two most important things that can be negotiated. I
can see why they may not be necessary for a normal GSS implementation -
either the protocol supports them or it doesn't, and the caller is free
to use the services if they are available. However, in the presence of
negotiation it is critical that it be possible to request such services.
I think it is worth adding a conf_req_flag and anon_req_flag to the
GSS_init_sec_context call. It requires no additional work for existing
providers because they already return the flags if confidentiality or
integrity is available, and for a negotiating package they are useful in
determing what mechanism to use.
- Mike
> -----Original Message-----
> From: Denis Pinkas [SMTP:D.Pinkas at frcl.bull.fr]
> Sent: Friday, May 23, 1997 9:49 AM
>
> The question is whether or not we should specify the logic of the
> target
> for the choice. If we do, it is possible to run some tests to verify
> that
> two different implementations from two different vendors behave in the
> same
> way ... otherwise it looks like a random choice among the list of the
> server.
>
> I still think that we should specify the logic of the target.
>
> The second point is that with RFC 2078 a context is indeed established
> even
> if the requested flags cannot be honored. Unless we change 2078, there
> is
> no reason that SPNEGO should work in a different way.
>
>
> > > On page seven, where the context flags are defined, the flag
> "confFlag
> > > (5)" should be added for confidentiality support. In addition, it
> should
> > > be noted that these flags may be extended if the GSS context
> requirement
> > > flags are extended
> >
> > That's actually interesting. I agree with Mike Swift that the
> context
> > attribute handling defined for base GSS-API doesn't scale/fit for
> > the negotiation mechanism.
> >
> > The flags listed in snego are those features that can be "requested"
> > via gss_init_sec_context() (as documented in RFC2078 2.2.1).
> > confFlag is a features that can be returned, but not requested.
>
> Correct. This is the reason why this flag is not present.
>
>
> > As documented, all of the flag input values are "feature request"
> > that may or may not be granted/provided. Absence of a requested
> > feature will not abort a context establishment. A initiator or
> > acceptor that is uncomfortable with the resulting features from
> > a context establishment is supposed to abort and delete the
> > context. This may result in unecessary overhead when the
> interoperable
> > intersection of features provided by the client's and server's
> > mechanism doesn't meet either one's requirements, but was still
> > considered acceptable. For a negotiation mechanism, when
> > (either or both) mechanism preference lists outweigh the requested
> > feature flags, this might actually prevent successful context
> > establishment.
> >
> > I have the feeling that it should be possible for the negotiation
> > mechanism to specify which context feature flags are considered
> > a requirement by both initiator and acceptor, and the required
> features
> > should precede the preference list.
> >
> > Off-hand, I don't have an idea how to:
> > - distinuish "required" from "nice-to-have" context features,
> > i.e. declare a feature "required"
> > - request "integrity" and "confidentiality"
> >
> > but I think this would be very, very valuable.
>
> > Since snego uses the regualar GSS-API calls, an extensions may
> > have to be folded into v2 as well?!
>
> As said earlier I am reluctant to extend SPNEGO features unless we
> change
> the Base GSS-API as well. The merrit of doing so is small compared to
> the non-compatibility we will experience. Another argument is that
> this
> would
> postpone the adoption of SPNEGO for another 6 months or more.
>
> The IETF is supposed to work faster that ISO ... :-)
>
> Denis
>
> --
>
> Denis Pinkas Bull S.A. E-mail :
> D.Pinkas at frcl.bull.fr
> Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
> 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa19102; 23 May 97 17:12 EDT
Received: from zephyr.isi.edu by ietf.org id aa19014; 23 May 97 17:08 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
id <AA28621>; Fri, 23 May 1997 14:04:11 -0700
Message-Id: <199705232104.AA28621 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2147 on TCP and UDP over IPv6 Jumbograms
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 23 May 97 14:04:11 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2147:
Title: TCP and UDP over IPv6 Jumbograms
Author: D. Borman
Date: May 1997
Mailbox: dab at bsdi.com
Pages: 3
Characters: 6383
Updates: 1883
URL: ftp://ds.internic.net/rfc/rfc2147.txt
This document describes some simple changes that can be made to allow
TCP and UDP to make use of IPv6 jumbograms. This document is a
product of the IPng 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at 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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <970523124254.RFC at ISI.EDU>
SEND /rfc/rfc2147.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2147.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970523124254.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19188; 23 May 97 17:15 EDT
Received: from zephyr.isi.edu by ietf.org id aa19151; 23 May 97 17:15 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
id <AA23002>; Fri, 23 May 1997 12:29:42 -0700
Message-Id: <199705231929.AA23002 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2145 on HTTP Version Numbers
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 23 May 97 12:29:42 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2145:
Title: Use and Interpretation of HTTP Version Numbers
Author: J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk
Date: May 1997
Mailbox: mogul at wrl.dec.com, fielding at ics.uci.edu,
jg at w3.org, frystyk at w3.org
Pages: 7
Characters: 13659
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2145.txt
HTTP request and response messages include an HTTP protocol version
number. Some confusion exists concerning the proper use and
interpretation of HTTP version numbers, and concerning
interoperability of HTTP implementations of different protocol
versions. This document is an attempt to clarify the situation.
This document is a product of the HyperText Transfer Protocol Working
Group of the IETF.
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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at 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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <970523122438.RFC at ISI.EDU>
SEND /rfc/rfc2145.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2145.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970523122438.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19267; 23 May 97 17:18 EDT
Received: from pax.cavebear.com by ietf.org id aa19225; 23 May 97 17:17 EDT
Received: from localhost by CaveBear.com (SMI-8.6/SMI-SVR4)
id OAA13253; Fri, 23 May 1997 14:13:49 -0700
Date: Fri, 23 May 1997 14:13:48 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Karl Auerbach <karl at cavebear.com>
Reply-To: karl at cavebear.com
To: Robert Moskowitz <rgm3 at chrysler.com>
cc: ietf at ietf.org
Subject: Re: Anti Spam legislation
In-Reply-To: <3.0.1.32.19970523092337.009d92c0 at dilbert.is.chrysler.com>
Message-ID: <Pine.SOL.3.96.970523140150.13241A-100000 at pax.cavebear.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
