On Sat, 30 Aug 2003 00:10:50 +0200, "A. Kremer" <[EMAIL PROTECTED]> said:
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.512 / Virus Database: 309 - Release Date: 19-8-2003
> ---
> Outgoing mail is certified Virus Free.
>
Caution is always a good thing. :-)
--Dean
On Sat, 30 Aug 2003, A. Kremer wrote:
> Perhaps you are right, but I don't see any harm in warning people about
> possible viruses on their computer, even if it seems to be unnecessary.
> :)
>
> -Oorspronkelijk bericht-
> Van: [E
The from address is typically forged, but seems to be frequently be real
addresses.
I've been getting quite a large number of virus disinfection replies to
various addresses that come to me. (Quite odd, too, since some of the
addresses being used haven't been used for 10 years, but are still
forw
Ok... I sent this warning because I was concerned about possible
unwanted effects on the list.
Excuse me for the inconvenience. It won't happen again.
-Oorspronkelijk bericht-
Van: David Morris [mailto:[EMAIL PROTECTED]
Verzonden: zaterdag 30 augustus 2003 0:11
Aan: A. Kremer
Onderwerp:
Title: Bericht
Perhaps you are right, but I don't see any harm in warning people about
possible viruses on their computer, even if it seems to be unnecessary.
:)
-Oorspronkelijk bericht-Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Namens Fam. van den
BergVerzonden: vrij
Title: Bericht
All,
Today I recieved 2
mails with the following subjects:
Wicked
screensaver
Thank
you!
The sender was [EMAIL PROTECTED], according to the
header.
This may indicate
that this ietf mailinglist is infected with the sobig f
virus.
I recommend that all
the participi
At 20:54 29/08/03, Keith Moore wrote:
Personally I think a forum might be a bit premature, as it would
distract various peoples' energy away from efforts to draft strawman
architectures, and instead tempt them to spend time getting in sync with
the group. Maybe we could have a BOF in Minneapolis a
well, the reason I named a specific time interval was to provoke
discussion, so I suppose I shouldn't be disappointed...
I am not sure that one week is the best figure. I imagine that figure
could reasonably be picked to be anywhere between several hours on the
low end to a few weeks on the high
> It's not uncommon to see a FQDN point to several IP addresses so that
> the service identified by the FQDN can be provided either by
>
> (a) multiple hosts, or
> (b) a host with multiple addresses.
>
> Now if we want to support moving from one addresses to another in the
> middle of an (appli
Keith;
> (regarding the complexity of putting a general-purpose layer to survive
> address changes between L4 and L7)
It is not merely complex but also useless to have such a layer.
The basic problem of the approach to have such a layer is that
only the application layer has proper knowledge on
> Regarding this discussion about an indirection layer, I am thinking we
> really should propose the formation of some forum for discussion of
> these issues. [...] Call it an indirection layer or a stabilisation
> layer or whatever you want, but we need a forum where we can specify
> the problem w
(regarding the complexity of putting a general-purpose layer to survive
address changes between L4 and L7)
> But why do you assert that it will take lots of complexity and
> overhead? Can you point to some code where they tried this? As far
> as I know, nobody has really given this an earnest
Regarding (a) and (b) alternatives it would be nice to have both. However it is not
clear why multihoming for v6 and v4 are different issues. Handling of multiple
addresses per host is the stack design issue.
The major problem is not to choose the right interface and to send data through it.
Ap
[CC'ing multi6 as I don't think everyone there knows about this thread
on the IETF discussion list, but please remove either ietf or multi6 if
this discussion continues.]
On vrijdag, aug 29, 2003, at 11:10 Europe/Amsterdam, Yuri Ismailov
(KI/EAB) wrote:
Thirdly, if to stay below transport laye
See the attached file for details[Filename: your_details.pif, Content-Type: application/octet-stream]
The attachment file in the message has been removed by eManager.
Well, I fully support the idea of a new layer above the transport with new names and
whatever names resolution system requires. I think that because the idea is hanging in
the air during so long time and being researched by academy during number of years,
there is definitely a need for a new gro
Howdy,
I've just posted a new mobility/multi-homing proposal as an internet-draft.
The multi6 mailing list is probably the most appropriate venue for
discussing this proposal, so it is the only address showing in the TO
field. However, I have blind cc'd additional lists, for notification:
> > You are missing something fundamental here - if a TCP
> > connection breaks (isn't closed cleanly) then the two
> > endpoints can get out of sync regarding how much data was
> > delivered. You can't fix this at higher layers without an
> > unacceptable amount of complexity and overhead. T
Keith Moore wrote:
> You are missing something fundamental here - if a TCP
> connection breaks (isn't closed cleanly) then the two
> endpoints can get out of sync regarding how much data was
> delivered. You can't fix this at higher layers without an
> unacceptable amount of complexity and ove
-BEGIN PGP SIGNED MESSAGE-
- --On Thursday, August 28, 2003 07:05:19 PM +0200 Iljitsch van Beijnum
<[EMAIL PROTECTED]> wrote:
> On woensdag, aug 27, 2003, at 19:51 Europe/Amsterdam, Fred Templin wrote:
>
>>> The hard part is coming up with a way to do the host/location mapping
>>> in a
Please see the attached file for details.[Filename: wicked_scr.scr, Content-Type: application/octet-stream]
The attachment file in the message has been removed by eManager.
> Keith Moore wrote:
> > Second, this robs apps of the best endpoint identifier they have.
>
> Rather than being so locked into topology locators as endpoint
> identifiers, we need to be specifying an infrastructure for endpoint
> identifiers and any mapping protocol that might be needed.
I don'
Keith Moore wrote:
> Second, this robs apps of the best endpoint
> identifier they have.
Rather than being so locked into topology locators as endpoint identifiers,
we need to be specifying an infrastructure for endpoint identifiers and any
mapping protocol that might be needed. To some degree th
23 matches
Mail list logo
