On 8/21/07, Keith Moore [EMAIL PROTECTED] wrote:
Roger Jørgensen wrote:
I am fully aware of that it will very likely be more than one subnet at some
point, that is why the last paragraph was included. Anyway, the important
point is that we probably should have two different type of
no. the important point is that all users need to initially have enough
address space that they can attach not just multiple networks, but
multiple layers of networks, at that point. trying to define the
difference between the two types of end-users is silly. the reason that
IPv6 has so
On 22-aug-2007, at 4:39, RJ Atkinson wrote:
In one's home network, which was and is the subject of this thread,
one ought not worry about backhoes taking out the cabling in the
attic. Since the uplink to the ISP would have a router in any
event, the part that might need to be redundant (i.e.
On 21-aug-2007, at 21:04, Tony Finch wrote:
So what you're saying is that any mail server should be able to
source
messages from any mail user using any email address in any domain.
Sorry, that's not a reasonable desire in my opinion.
How else do you implement forwarding?
Well, most
I'm not sure we need to debate the subnet vs. bridging
question. Of course bridging will go a long way; yet I
don't think anyone on this thread wants to claim that
we should limit home networks to it.
The crux of the issue is the unpredictability of what
will happen with technology, a particular
On 22-aug-2007, at 4:54, Jun-ichiro itojun Hagino wrote:
that's true, but when link MTU is different, it gets very nasty.
IEEE 802 standards do not permit variation in the link MTU
for Ethernet. Attempts to persuade IEEE 802 to approve use
of jumbo-MTUs (e.g. 9180 bytes + Ethernet
Ah. I must admit that I find the whole concept of informational
documents a heck of a lot less useful, but your reading of 2026 is of
course correct. I'll probably still end up treating informational
documents as close to ietf consensus statements (but not
recommendations) in my head because
Part of the problem may be historical: Requirement documents are a
relatively recent phenomena and likely postdate 2026. I suspect the
original intent of informational documents was to document non-IETF
protocols for the benefit of implementors, as well as record various
other
Hi Henning,
many of these document are turned into a religious thing and then every time
you suggest something your solution is compared against some of these
documents. As document author you are often not excited about this approach.
Examples:
* RFC 3693 (Geopriv Requirements)
* EAP
Hannes -- for the record EAP Keying Framework is destined
to become a Proposed Standard. It was also developed by a
consensus process in the WG, and extensively discussed
(perhaps even for too long). Not sure its a good example to
use in this discussion. I do agree with your point otherwise,
Henning == Henning Schulzrinne [EMAIL PROTECTED] writes:
Henning Rather than an IESG note or in addition to, I think the
Henning author should clearly state, in the abstract, that this
Henning is a personal opinion only.
I don't think my personal opinion would make a very useful
On Wed, 22 Aug 2007, Iljitsch van Beijnum wrote:
Well, most people understand forwarding to be encapsulating the original
message in a new message of your own in some way, so that it appears to come
from the forwarder rather than the original sender.
See RFC 2821 section 3.4 for the meaning I
Sam,
I reviewed your document on Requirements for Web Authentication Resistant to
Phishing. I think the document is very useful. Here are some comments:
The document provides guidance on designing secure authentication mechanisms
for Web services. The goal is to replace HTML-form- and
--On Wednesday, 22 August, 2007 10:40 -0400 Sam Hartman
[EMAIL PROTECTED] wrote:
Henning == Henning Schulzrinne [EMAIL PROTECTED]
writes:
Henning Rather than an IESG note or in addition to, I
think the Henning author should clearly state, in the
abstract, that this Henning is
Hi.
Both your and Eric's comments need a longer response.
It was my intent to use strong and weak password equivelantsin the
same way as the IAB document. We agree on what the IAB document
defines the terms to mean. I'll go look through my text and clarify
what needs clarification.
I'm
I have no problem breaking bounce/redirect. Yes, it has its uses, but
so do open relays, which we don't have anymore. The current levels of
mail abuse means that it's necessary to throw away a little baby with
the bathwater to keep the toxic waste out of the bath.
sorry, this is a nonstarter.
Keith Moore wrote:
I have no problem breaking bounce/redirect. Yes, it has its uses, but
so do open relays, which we don't have anymore. The current levels of
mail abuse means that it's necessary to throw away a little baby with
the bathwater to keep the toxic waste out of the bath.
sorry,
Michael Thomas wrote:
Keith Moore wrote:
I have no problem breaking bounce/redirect. Yes, it has its uses, but
so do open relays, which we don't have anymore. The current levels of
mail abuse means that it's necessary to throw away a little baby with
the bathwater to keep the toxic waste out
Henning Schulzrinne wrote:
Part of the problem may be historical: Requirement documents are a
relatively recent phenomena and likely postdate 2026. I suspect the
original intent of informational documents was to document non-IETF
protocols for the benefit of implementors, as well as record
Henning,
Some WGs issue Informational RFCs that represent WG consensus, but
which are not viewed as suitable Standards track documents, for
various reasons. For example, RFC 3647 is one of the most widely
cited of the PKIX RFCs, yet it is Informational because its a policy
and procedures
On 22-aug-2007, at 19:57, Keith Moore wrote:
I have no problem breaking bounce/redirect. Yes, it has its uses, but
so do open relays, which we don't have anymore. The current levels of
mail abuse means that it's necessary to throw away a little baby with
the bathwater to keep the toxic waste
Iljitsch van Beijnum wrote:
Obviously life is a bit more complex than add PKI and signature to
From: and stir. If I get a letter addressed to me from the tax
people, I'll take it, regardless of how it happened to arrive. Junk
mail on the other hand (the paper variety) will meet the inside of
Sam Hartman wrote:
Ah. I must admit that I find the whole concept of informational
documents a heck of a lot less useful, but your reading of 2026 is of
course correct. I'll probably still end up treating informational
documents as close to ietf consensus statements (but not
recommendations)
I.e., a new mail protocol will have to
address things like forwarding and mailinglists explicitly.
Not protocol. A new email architecture will have to address all these
things explicitly, but the protocols may indeed be usable as is, or with
minor changes.
The point is that we need to examine
Sam,
You said the following on BCPs on the EMU list recently. (The context
is irrelevant, I think, but please feel free to bring in the context if
you deem it necessary.)
I'd like to understand whether we can meet all the requirements of that
BCP
For some reason that sounded odd to me,
A new Request for Comments is now available in online RFC libraries.
BCP 133
RFC 5033
Title: Specifying New Congestion Control Algorithms
Author: S. Floyd, M. Allman
Status: Best Current Practice
Date: August 2007
A new Request for Comments is now available in online RFC libraries.
RFC 5013
Title: The Dublin Core Metadata Element
Set
Author: J. Kunze, T. Baker
Status: Informational
Date: August 2007
Mailbox:
27 matches
Mail list logo
