But this is just an instance of the general case that some
source-destination address pairs work better than others.
Address selection heuristics don't do a good job solving this
problem - to solve this problem the network actually needs to tell
the host which source-destination address
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
On 20-sep-2007, at 21:10, Stephen Sprunk wrote:
First of all, litigation isn't the only way to get something
done, and second, do don't know that until you try.
If you try to revoke someone's /8 or /16, you can bet that they're
going to sue you.
So? The RIRs and ICANN have deep pockets.
On 20-sep-2007, at 21:19, Stephen Sprunk wrote:
Sometimes ignoring a problem really does make it go away.
Install a workaround, on the other hand, and the brokenness
remains non-obvious so it persists.
If often persists whether it remains non-obvious or not. I can't
count how many hotels
Paul Hoffman wrote:
Why the IETF? Why not ISOC, an organization that has expertise and
experience is asking such questions? ISOC already has local chapters
throughout the world, ISOC has a friendly membership policy, and ISOC
has good relations with the IETF for discussing proposed
Welcome,
I'm a system administrator of a secondary school, and ive
installed a spam filter a couple days ago, to prevent
spam. The problem is the various spam images
there is used graphical attachments, a lot of different words
to advertise their products. Now I have strong filter, so I
More opportunities of the request card:
If it would br given an quota for each e-mail domains to send
application request card, that is more possibility to stop spanning,
because, the spammers want to get connection thosands of users.
But if there is already a relationship between 2 address,
On Fri, Sep 21, 2007 at 12:44:48PM +0200,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote
a message of 59 lines which said:
I think to need an new e-mail rules, to stop this madness. I
call it application card.
Please, please, please, a *lot* of time and effort have been devoted
to the
Thus spake Keith Moore [EMAIL PROTECTED]
At the same time, IETF needs to understand that optimizing for
deployability first and scalability second often succeeds whereas
the reverse often fails. We need to understand how to design
protocols that can be deployed quickly and yet be upgraded
Stephen Sprunk wrote:
Thus spake Keith Moore [EMAIL PROTECTED]
At the same time, IETF needs to understand that optimizing for
deployability first and scalability second often succeeds whereas the
reverse often fails. We need to understand how to design protocols
that can be deployed quickly
Paul Vixie has asked me to more widely state a comment made last May
on the v6ops mailer. Please understand that this is not a formal
statement of Cisco's (e.g., this is not a press release signed off by
the Cisco Legal, corporate PR, product line management, or marketing
departments), it
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED]
On 20-sep-2007, at 21:10, Stephen Sprunk wrote:
First of all, litigation isn't the only way to get something done, and
second, do don't know that until you try.
If you try to revoke someone's /8 or /16, you can bet that they're going
to
Ted, speaking as an individual.
I completely agree that personnel decisions of ADs should be able to
be appealed. I actually considered proposing text modifications to
make it clear that there might be circumstances where it would be
appropriate for the IESG to resolve the conflict.
I and I
At 12:34 PM +0200 9/21/07, Patrick Vande Walle wrote:
I founded an ISOC chapter some years ago among others to see how users
could provide input to the standards development process. However, there
is no mechanism to consult, collect and present such information in an
organized way.
You could
All,
First, I would like ask people to move the ULA-C discussion off
the IETF main list. We have a chartered working group (IPv6;
to change to 6MAN in the next couple of days) that has an
official work item to look at ULA-C. The best way to progress
the topic is to participate that WG's effort.
Eliot Lear wrote:
there was something of a view that the whole point of
MXes was for the MX relay to bridge between online and offline devices.
It was well understood at the time that MANY more systems were in fact
on the networks that you mentioned than were on the ARPANET. And I
Ted:
With great respect, I must disagree. The appeal says: It is the
position of the appellants that this removal violates the IETF
process by which working groups are governed. This say to me that
the appellants believe that Cullen Jennings violated IETF process by
replacing the GEOPRIV
Seems to me that what you are saying amounts to the statement that PI space
cannot exist by definition. If there is address space that is routable on an
Internet-wide basis it is by definition routable Internet space and no PI space.
If someone needs such space they need to obtain an IP address
Stephen Sprunk wrote:
SCO had deep pockets too. IBM, Novell, etc. had much, much deeper
pockets. Do you really think ARIN or ICANN could take on titans such
as GE, IBM, ATT, Xerox, HP, Apple, Ford, Halliburton, Eli Lilly,
Prudential, and Merck? Even _one_ of them? ARIN would be squashed
At 1:16 PM -0400 9/21/07, Russ Housley wrote:
Ted:
With great respect, I must disagree. The appeal says: It is the position of
the appellants that this removal violates the IETF process by which working
groups are governed. This say to me that the appellants believe that Cullen
Jennings
On 21-sep-2007, at 17:56, Fred Baker wrote:
There is an obvious inherent bug in that, which has been observed
in the IPv4 Internet with respect to RFC 1918 and martian prefixes.
Administrations that don't apply the policy to deny ULAs will
accept them, which will have the effect of leaking
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED]
On 20-sep-2007, at 21:19, Stephen Sprunk wrote:
Sometimes ignoring a problem really does make it go away.
Install a workaround, on the other hand, and the brokenness
remains non-obvious so it persists.
If often persists whether it remains
--On Wednesday, 19 September, 2007 19:42 +0200 Eliot Lear
[EMAIL PROTECTED] wrote:
Here our views of history differ. I can't say that I had a
gray beard at the time, nor that I was at all involved in the
design, but I was there, and I think there was something of a
view that the whole
Ted:
To begin with, I want to say that I agree with your perception of the
appeal process. It is an important conflict resolution tool.
The first thing that was done in the drafting of the appeal response
was to list each of the claims in the appeal. That is why the
introduction lists
Stephen Sprunk wrote:
So? The RIRs and ICANN have deep pockets.
SCO had deep pockets too. IBM, Novell, etc. had much, much deeper
pockets. Do you really think ARIN or ICANN could take on titans such
as GE, IBM, ATT, Xerox, HP, Apple, Ford, Halliburton, Eli Lilly,
Prudential, and Merck?
You seem to be of the impression that whether something works is
binary. If a hack works in some situations and breaks things in
others, does it work or is it broken? Note that different people will
come up with different opinions on whether the hack works or not,
depending on what apps they
Hallam-Baker, Phillip wrote:
Seems to me that what you are saying amounts to the statement that PI space
cannot exist by definition. If there is address space that is routable on an
Internet-wide basis it is by definition routable Internet space and no PI
space.
There can be such a
At 3:49 PM -0400 9/21/07, Russ Housley wrote:
As a concrete suggestion:
The IESG re-affirms that its reading of RFC 2026 is that any action made by
an Area
Director or the IESG may by made the subject of the conflict resolution
mechanisms
set out in Section 6.5 of RFC 2026. The IESG further
IESG Response to the Appeal Against the Removal of the Co-chairs of the
GEOPRIV Working Group
Introduction
This is the IESG response to the appeal by Randall Gellens, Allison
Mankin, and Andy Newton posted at:
http://www.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf
A new Request for Comments is now available in online RFC libraries.
RFC 4965
Title: CableLabs - IETF Standardization Collaboration
Author: J-F. Mule, W. Townsley
Status: Informational
Date: September 2007
Mailbox:
A new Request for Comments is now available in online RFC libraries.
RFC 5062
Title: Security Attacks Found Against the
Stream Control Transmission Protocol (SCTP) and
Current Countermeasures
Author: R.
A new Request for Comments is now available in online RFC libraries.
RFC 4960
Title: Stream Control Transmission Protocol
Author: R. Stewart, Ed.
Status: Standards Track
Date: September 2007
Mailbox:[EMAIL
A new Request for Comments is now available in online RFC libraries.
RFC 5061
Title: Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration
Author: R. Stewart, Q. Xie,
M. Tuexen, S.
33 matches
Mail list logo
