Dear all,
Sorry if you receive multiple copies of this! I sent it to all the lists with
potentially interested folks... (this should be okay to do according to
RFC5434, which says "various mailing lists").
A community of interest is being formed to gauge whether there is sufficient
interest t
Hi folks,
I would just like to add that our studies are ongoing, and
this:
> variety of Internet paths. It observes that on average, IP options
> introduce between 7% and 26% (for different sets of paths at different
> times) of additional delay. The article says that "In any case, the
> additi
LS, ...?
* What about fairness issues and TCP-friendliness?
SUBMISSION OF PAPERS:
Prospective authors are invited to submit an extended abstract (about 1.5 to
2 pages) to Michael Welzl ([EMAIL PROTECTED]) in postscript, PDF or
Word 97 format.
English is the official language of SCI 2001, thus
e to get some cooperation
and discussion going. I set up the page at
http://www.tk.uni-linz.ac.at/~michael/ptp/
in support of this mail. If you want to participate, please join
the list (details at the site).
Kind regards,
Michael Welzl
PS: Feel free to forward this to anybody you think might be
at way to teach your kids how the 'net
works, too.
http://www.warriorsofthe.net/
Also note that I'm by now means involved with this project (wish I was :) ),
I'm just impressed by it.
Cheers,
Michael Welzl
tachments: I explained the consequences
of big attachments and told them if they don't want the receiver to
get angry at them, they should ask before sending a big attachment.
As a definition of "big", I said "1 MB and more".
To me, this makes sense; I believe we can avoid some of those problems
through user education.
Regards,
Michael Welzl
ow this protocol could be turned NAT friendly. I doubt that it's possible.
I expect some people to yell "bad design" then; but how would you provide
this functionality? Certain things simply can't be done if we strictly
stick with an end2end point of view - and I would of course be glad if
someone tells me I'm wrong and comes up with a solution:)
Regards,
Michael Welzl
Hi all,
What is the best way to deal with the RFC status in normative references?
Should I only use normative references on "Standard" RFC's although
"Proposed Standard" RFC's may already obsolete them and contain better
information?
Should I give a choice?
Example:
(Y = Proposed Standard, obso
