[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]





Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10192;
          9 Aug 93 12:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10181;
          9 Aug 93 12:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23738;
          9 Aug 93 12:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10171;
          9 Aug 93 12:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10144;
          9 Aug 93 12:46 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa23722; 9 Aug 93 12:46 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA22856; Mon, 9 Aug 93 09:47:24 PDT
Received: from pepper.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
	id AA08766; Mon, 9 Aug 93 09:47:26 PDT
Received: from yikes.Eng.Sun.COM by pepper.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17788; Mon, 9 Aug 93 09:51:41 PDT
Date: Mon, 9 Aug 93 09:51:41 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chuck McManis <Chuck.McManis at eng.sun.com>
Message-Id: <9308091651.AA17788 at pepper.Eng.Sun.COM>
To: ietf at CNRI.Reston.VA.US
Subject: Predicting the future
X-Sun-Charset: US-ASCII


Clearly the problem here is that no one can adequately predict what will
happen five years from now. The comment Louis Mamakos made that went

    "I was a case where 'everyone' was certain we would 'transition'
     from to the holy grail that was CLNP and OSI."

could just as easily become

    "I was a case where 'everyone' was certain we would 'transition'
     to <IPng candidate>."

So lets just take it as a given that _nothing_ YOU can do will _guarantee_
that the strategy that YOU believe is the Right strategy will become the
next Standard.

We should stop bickering about all of the alleged conspiracies
going on and get back to the real questions of understanding the choices
before us, and making them the best possible choices. This group
(the Internet) has a wonderful tendency of ferreting out things that
actually work and using them rather than being "sold" on things they
haven't actually seen. Trust that this tendency will continue and any
successful conspirator will be defeated by usability. (Not technical
superiority, usability superiority.)

No back to our regularly scheduled argument, :-)
--Chuck


Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10390;
          9 Aug 93 12:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10382;
          9 Aug 93 12:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23975;
          9 Aug 93 12:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10366;
          9 Aug 93 12:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10362;
          9 Aug 93 12:56 EDT
Received: from lager.cisco.com by CNRI.Reston.VA.US id aa23959;
          9 Aug 93 12:56 EDT
Received: by lager.cisco.com id AA27553
  (5.67a/IDA-1.5); Mon, 9 Aug 1993 09:56:42 -0700
Date: Mon, 9 Aug 1993 09:56:42 -0700
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tony Li <tli at cisco.com>
Message-Id: <199308091656.AA27553 at lager.cisco.com>
To: Kunihiro Taniguchi <taniguti at nwk.cl.nec.co.jp>
Cc: iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: CIDR Documents to Proposed Standard


   In case that a router receives a ICMP NETWORK REDIRECT packet, what should
   the router do? 

Routers are not supposed to listen to redirects, so it should drop the
redirect. 

Tony


Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11976;
          9 Aug 93 14:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11966;
          9 Aug 93 14:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27212;
          9 Aug 93 14:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11949;
          9 Aug 93 14:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11878;
          9 Aug 93 14:22 EDT
Received: from gateway.mitre.org by CNRI.Reston.VA.US id aa27154;
          9 Aug 93 14:22 EDT
Return-Path: <barns at cove.mitre.org>
Received: from cove.mitre.org by gateway.mitre.org (5.61/SMI-2.2)
	id AA28884; Mon, 9 Aug 93 14:23:09 -0400
Received: by cove.mitre.org (4.1/SMI-4.1)
	id AA06382; Mon, 9 Aug 93 14:22:33 EDT
Message-Id: <9308091822.AA06382 at cove.mitre.org>
To: ietf at CNRI.Reston.VA.US
Cc: barns at cove.mitre.org
Subject: New US MIL-STD Profiles for TCP/IP Coming
Date: Mon, 09 Aug 93 14:22:32 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: barns at cove.mitre.org

Yes!  And let me now preface the rest of this note by saying:

*I didn't invent this idea, so please don't flame me if you don't like it*

I'm only passing along information.  While I might be educated or
entertained by a Cc of your responses, I'm not responsible for whatever
goes on.

Clearly this *might* have procurement implications, so if you are a
vendor of TCP/IP products, you should probably think about this at least
long enough to decide whether you ought to care.  I don't know whether
the IAB hierarchy ought to care.  Here's the info for any who want it.

There is an effort in progress to write a multi-part Profile (in the OSI
sense) for Joint Task Force data communications systems using TCP/IP.  The
forum for this is an Ad Hoc Working Group of Working Group 1 (Lower Layers)
of the Data Communications Protocol Standards Technical Management Panel
(DTMP) which is an instrumentality of the US Department of Defense that
is orchestrated by the Center for Standards in the Defense Information
Systems Agency.

The Profiles are TR-10000 style documents and they also include PICS
proformas (for the uninitiated, this means conformance requirements).
The drafts I have seen are A-profiles for SMTP (in two parts) and SNMP,
and a T-profile in many parts for stacks of TCP/UDP/ICMP/IP over various
lower layers (802.3 and some HDLC variations - more to come perhaps).

I'm not in the business of distributing big hardcopy documents and the
drafts are too full of tables to be asciified in my "spare time".  So I
must refer interested readers to the CFS.  The CFS point of contact
for this activity is Greg Scott <scottg at cc.ims.disa.mil>, (908) 532-7726.
He has expressed his desire to generate interest in the profile from
people in the know.  I think the working group meetings are "open" (but
you probably have to preregister, and there might be complexities for
non-US citizens) - Ask Mr. Scott if you're interested.

/Bill Barns
 (speaking for no one)


Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12098;
          9 Aug 93 14:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12088;
          9 Aug 93 14:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27341;
          9 Aug 93 14:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12076;
          9 Aug 93 14:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12026;
          9 Aug 93 14:25 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa27279;
          9 Aug 93 14:25 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id al20692;
          9 Aug 93 18:14 GMT
Date: Mon, 9 Aug 93 18:20 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Now is the time for radical thinking...
Message-Id: <54930809182045/0003858921NA2EM at mcimail.com>

As the corporate support person that has to explain the INTERNET to my
corporate colleagues, and as a concerned observer of the IPng process,

I call for a serious rethinkly of the IPng process.


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.