I hope that we can discuss this as soon as possible. Until then, I
will try to refrain from sending any more messages on this topic as I
don't believe that this will be productive. People on this mail list
might want to consider to do the same thing.
Thanks,
David Kessens
Operations
- Forwarded message from Dean Anderson [EMAIL PROTECTED] -
FYI: I am being threatened for posting operationally relevant
criticism of
mis-operation of the F DNS Root server on the DNSOP list.
--
-- Forwarded message --
Date: Fri, 23 Sep 2005 15:55:20 -0700
I thought it was interesting that there were 8 areas at the time RFC 2418
was written and I couldn't see anything in the 50% of it I read that hinted
at 8 being a problem (and there are only 7 now I believe?).
The way I see it is that in many ways everyone subscribed to this list is an
AD for
What fascinates me about p2p is that it was clearly the
next Big Thing, but there seems to be no feedback loop
operating whatsoever.
At the risk of birthing a much unwanted tangent, I think it would have been
somewhat egocentric for the IETF to do anything that lent legitimacy to the
p2p
It would seem we will all be in violation of Canadian law (as will the IETF
as an organization) when we convene for IETF 64. Those canucks apparently
regulate the term Engineer and the use of Software, Network, or Systems
Engineer is um apparently not allowed. I wonder if they'll put Dave
There's a difference between take our course and we certify that you
are an engineer and my job title is engineer.
Not in Canada. The word itself is regulated and can not be used in a job
title or function unless you are a member of their engineers society. A
candle maker can not call
Even though I benefit from this change, I disagree with it
in principle
because there are too many people out there running around calling
themselves engineers who don't have a clue. If/when there are a
non-trivial number of schools offerring degrees in network
engineering,
Basically, a NAT is just a simple and general-purpose way
to implement
a proxy.
It does play the role of a proxy nobody has ordered and nobody does
even no it exists. So it does breake security by providing a
proxy that should bo be there in the first place.
I don't understand
Two will leave but only one shall return...I'm by no means suggesting
that's a desirable approach to decision making but we've managed to get
ourselves into a place where I think it's now the best way out. Fortunately
since this incompatibility will result in email that should have been
received
AM
To: Nicholas Staff
Cc: IETF General Discussion Mailing List
Subject: Re: Stopping loss of transparency...
On 18-aug-2005, at 6:10, Nicholas Staff wrote:
Does this work on port 443? I would assume the SSL security checks
wouldn't accept this.
I believe the FQDN is not encrypted
yes , thats exactly what it does , they call it Portal-Guided
Entrance on port :80 and 443.
Does this work on port 443? I would assume the SSL security checks
wouldn't accept this.
I believe the FQDN is not encrypted, though the part of the
url after the
FQDN is (so one
On 17-aug-2005, at 15:34, Marc Manthey wrote:
Just to be sure: what were talking about is that when a customer
gets up in the morning and connects to www.ietf.org they get
www.advertising-down-your-throat.de instead, right?
yes , thats exactly what it does , they call it
Why doesn't someone just ask Russ what he meant and be done with it?
-Nick
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Michael Thomas
Sent: Friday, August 12, 2005 7:24 AM
To: Harald Tveit Alvestrand
Cc: Michael Thomas; ietf@ietf.org
John,
The way I understand it, an RFC is only historic(al) if the technology it
defines is no longer in use.
An obsolete RFC means the technology is still being used, but some part of
the specification (obsolete RFC) has been updated. An obsolete RFC can
still be a standard as the RFC that
Keith (and anyone interested in this thread that doesn't have me on ignore),
I think as has already been suggested we are having two different
discussions masquerade as one. I obviously can't speak for Robert but it
seems to me he is not saying the IESG ought to approve every (or any)
extension
I agree that no noise usually means agreement, but once a counterpoint has
been raised I don't know how to tell which side the silent people are
agreeing with.
I'm not saying I see all angles to this but it seems like Robert really has
some strong logic behind him - If assigning the registration
You could also reasonably rule it obnoxious, childish, and pubescent.
Moreover since according to your earlier post you don't think fact is an
acceptable defense of a personal attack your response is at best a curious
double standard. Unless of course your comment about it being fact was just
TIME OUT.
1. There was a last call for a BCP
2. It was suggested the BCP was at least in part based on erroneous data
3. Examples were given to support that claim.
4. Harald shared that he was irritated (thereby irritating the few of us who
weren't).
5. You (gja) write you think this past week
PROTECTED]
Sent: Tuesday, June 28, 2005 10:28 AM
To: Nicholas Staff
Cc: 'Dean Anderson'; 'Harald Tveit Alvestrand'; ietf@ietf.org
Subject: Re: I'm not going to listen to this any more.
Nick,
I could, but I won't. You and Dean may not realise just how annoying and
irrelevant your public quarrel
I've been holding off comenting on this issue because in the context of this
mailing list my knowledge of the policies of the IETF and IANA is basically
zero.
The thing is I think Robert is right about the tone and assumed purpose of
this rejection. It reads like a letter from someone playing
]
To: Nicholas Staff [EMAIL PROTECTED]; iesg@ietf.org;
ietf@ietf.org
Sent: Monday, June 20, 2005 9:09 PM
Subject: Re: Last Call: 'Email Submission Between Independent Networks' to
BCP - Clarification
See what worries me is when you didn't understand the relevence of my
post
you didn't ask me one
- Original Message -
From: Bill Sommerfeld [EMAIL PROTECTED]
To: Nicholas Staff [EMAIL PROTECTED]
Cc: Tony Finch [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org
Sent: Tuesday, June 21, 2005 5:34 AM
Subject: Re: Last Call: 'Email Submission Between Independent Networks'
toBCP
: Carl Hutzler [EMAIL PROTECTED]
To: iesg@ietf.org; ietf@ietf.org
Sent: Tuesday, June 21, 2005 5:57 AM
Subject: Re: Last Call: 'Email Submission Between Independent Networks' to
BCP - Clarification
[EMAIL PROTECTED] wrote:
On Tue, 2005-06-21 at 00:28, Nicholas Staff blames the victims:
whats
]
Best regards,
Nick Staff
- Original Message -
From: Dave Crocker [EMAIL PROTECTED]
To: Nicholas Staff [EMAIL PROTECTED]; iesg@ietf.org;
ietf@ietf.org
Sent: Sunday, June 19, 2005 11:15 AM
Subject: Re: Last Call: 'Email Submission Between Independent Networks' to
BCP - Clarification
Dean,
I couldn't agree with you more - thanks for saying it.
whats funny to me is if anything would have given spammers a reason to
exploit open relays it would have been the blacklists. I mean when you
arbitrarily blacklist millions of their ISP's addresses you leave them with
no other
Because I have already recieved several comments relating to one aspect of
my original post I thought a clarification was in order as I didn't explain
myself properly and there is some misunderstanding.
When I wrote that nobody would be complaining if spam primarily consisted
of Bloomingdale's
26 matches
Mail list logo
