On 13 Apr 2000, Marc Horowitz wrote:
> Vijay Gill <[EMAIL PROTECTED]> writes:
>
> >> think this would be more of an end system issue rather than a "core" or a
> >> "backbone" issue, where the end system is the box prior to the ISP handoff
> >> and not quite under the ISP's control and not the en
At 10:49 AM 13/04/00 -0700, Eliot Lear wrote:
>Part of the problem here is that a knife may be used as a food utensil or a
>weapon. Safe handling, however, is always required, and should be
>documented.
Granted.
>I would add two other comments. I tried to locate the RFC for HTTP/0.9,
>but the
(2) option is the best of all from my view point but you could use some real
time OS like VxWorks
or Nuclues
> -Original Message-
> From: du pot [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 13, 2000 2:05 PM
> To: [EMAIL PROTECTED]
> Subject: Request for Information
>
>
> Hello,
>
>
Hello,
I am doing my Masters in US. I have a few ideas for my masters' project.
I request you to comment about these ideas, and help me choosing the best
out of these.
1. Real time video transmission using Java.
2. Internet telephony using Java.
3. Remote network management using Java.
4. Vide
Part of the problem here is that a knife may be used as a food utensil or a
weapon. Safe handling, however, is always required, and should be
documented.
I would add two other comments. I tried to locate the RFC for HTTP/0.9,
but the best I could find was a reference to a CERN ftp site for the
Hello Vernon,
At 21:48 12/04/00 -0600, you wrote:
>I also think you need to give up the idea of
>having computers make value judgements, but maybe that's just my lack of
>imagination.
>
Sure that computers will improve doing judgements, but don´t lost the main
force on Interenet, there are hund
Hehe
-Original Message-
From: Randy Bush [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 12, 2000 11:32 PM
To: ietf
Subject: eating our own dogfood
rip.psg.com:/usr/home/randy/mp3/neil_young> nslookup ietf.org.
Server: cache.psg.com
Address: 147.28.0.3
*** No address (A) records av
In message <[EMAIL PROTECTED]>, Matt Crawford typed:
>>> The source address of a datagram was an architectural mistake, and should
>>> never have been in the mandatory packet format.
>>Nahh, the mistake was ignoring the source address when routing & forwarding.
thats an implementation det
At 04:45 PM 11/04/00 -0700, Eliot Lear wrote:
>I wonder if any of the authors has explored the risks of modifying data in
>flight. How could this be abused by interlopers and evil doers? If I
>could hack into a router implementing NECP, what damage could I do? Could
>I start a nasty little Java
> I don't want to change it (as if I could!), my purpose was to point out
> that our current network is the sum of our mistakes, not the network
> equivalent of the Mount Sinai tablets.
no disagreement there. but the original mistakes in TCP/IP were more-or-less
designed to work together. whe
Peter,
you are missing the point, and your arguments are unpersuasive.
Keith
Keith,
At 07:59 PM 11/04/00 -0400, Keith Moore wrote:
> > This was a choice - in some larger sense, if sourcing other-owned IP
> > addresses or TCP connections is considered an architectural problem,
> > needs to come down from above, rather than up from WREC.
>
>sounds like a convenient excuse t
Vernon,
At 04:47 PM 11/04/00 -0600, Vernon Schryver wrote:
>Call me a non-team playing scab, but I refuse to the honor the old guild
>work rule that limits the questions I can consider. If sourcing
>other-owned etc. or anything else is an architectural or other problem,
>then professional pride
Vijay Gill <[EMAIL PROTECTED]> writes:
>> Any specific ISP's that one could care to name? Coming from an ISP, what
>> I've seen in general is that most routers have just enough cycles in the
>> forwarding path to keep up with the offered traffic, much less sit around
>> watching for SYN's in fli
List:
I would like to extend an invitation to the IETF list to read "The
Bell" -- the first newsletter entirely dedicated to Internet voting and
collaborative decision-making in Internet protocols (including the use
of digital certificates and the resulting security/privacy concerns from
pote
15 matches
Mail list logo
