Tony Hain wrote:
Your arguments make no sense. Any service that has an MX creates
absolutely no cost, and the fallback to only makes one last
attempt to deliver the mail before giving up. Trying to force the
recipient MTA to publish an MX to avoid delivery failure on the
sending MTA is
Due to our business characteristics, we usually transfer large volumes of
data such as engineering or architectural drawings across long distances. We
needed a WAN optimization solution that would provide our remote employees
the same application access environment as in our headquarters, together
While reviewing the documents I tried to determine how the 4 streams
currently defined in RFC4844 fit into the framework.
Although the stream is not specifically mentioned it is clear that the
incoming rights document applies to the IETF Stream.
To me it is clear that a contribution to
I have seen a number of problems recently with bis documents
accidentally ignoring changes introduced by the RFC Editor to the
original RFC. In some cases this has gone unnoticed all the way until
IETF Last Call.
The problem is that authors start with THEIR version of the source code
for the
Adrian Farrel wrote:
Good point Jari,
Can I also remind you to check in the RFC Errata pages to make sure you pick
up any errors that have been flagged since RFC publication.
Of course you mean the *relevant* errata - the RFC Erratas page is so
full of junk these days that it is
Stewart, Adrian,
Of course you mean the *relevant* errata
Right. Generally speaking, I would go over the reported erratas and see
which ones of them need to be adopted. Some might even need WG discussion.
Jari
___
IETF mailing list
IETF@ietf.org
On Wed, 26 Mar 2008, IAB Chair wrote:
The document can be found at:
http://www.ietf.org/internet-drafts/draft-iab-protocol-success-03.txt
The document seems to be in good shape and is useful.
Two comments:
Case study A4 discusses inter-domain multicast vs application
overlays. It seems as
You are completely incorrect in describing MX records as no more than an
optimization. The MX record defines the mail SERVICE. An A or record
defines a HOST.
Nor am I rewriting history here, the early RFCs that describe the emergence of
the mail service and the DNS make it very clear
Keith Moore wrote:
Tony Hain wrote:
Your arguments make no sense. Any service that has an MX creates
absolutely no cost, and the fallback to only makes one last
attempt to deliver the mail before giving up. Trying to force the
recipient MTA to publish an MX to avoid delivery failure
--On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman [EMAIL PROTECTED]
wrote:
I would think that the document would gain in clarity if it explicitly
ties the incoming rights to the streams as defined in RFC4844 and also
explicitly calls out that if new streams would be defined those should
*
* Good point Jari,
*
* Can I also remind you to check in the RFC Errata pages to make sure you
pick
* up any errors that have been flagged since RFC publication.
*
* Adrian
Enter the RFC number to the RFC Editor search engine at
http://www.rfc-editor.org/rfcsearch.html.
The key issue here is whether people who rely on are likely to
achieve their desired result. Today it does not matter because anyone
who relies on alone with no A fallback is going to receive almost
no mail.
That in turn is going to depend on whether software implementations are
written
--On Thursday, 27 March, 2008 12:31 -0700 Hallam-Baker,
Phillip [EMAIL PROTECTED] wrote:
The key issue here is whether people who rely on are
likely to achieve their desired result. Today it does not
matter because anyone who relies on alone with no A
fallback is going to receive
While not really disagreeing with Leslie and Olaf, I would
point out that the IPR WG was chartered to look at
IETF documents. We can have a meta-discussion about
where the clarifications belong, but it seems to me
that the WG consensus definitely assumed that scope
and no wider scope. I'd be happy
--On Thursday, 27 March, 2008 09:00 +0200 Matti Aarnio
[EMAIL PROTECTED] wrote:
On Wed, Mar 26, 2008 at 10:46:37AM -0400, Tony Hansen wrote:
[EMAIL PROTECTED] wrote:
...
It would be needed until IPv6 takes over.
It will be needed even *after* IPv6 takes over. There will
be
On Wed, Mar 26, 2008 at 10:46:37AM -0400, Tony Hansen wrote:
[EMAIL PROTECTED] wrote:
...
It would be needed until IPv6 takes over.
It will be needed even *after* IPv6 takes over. There will
be lots of queries for A records long after the majority
of hosts don't have A
--On Wednesday, 26 March, 2008 14:26 -0700 Hallam-Baker,
Phillip [EMAIL PROTECTED] wrote:
I don't undestand the reasoning here.
My understanding is that we implicitly deprecated receivers
relying on fallback to A in 2821.
We did no such thing.
Section 5 makes it clear
that you
--On Wednesday, 26 March, 2008 14:26 -0700 Hallam-Baker,
Phillip [EMAIL PROTECTED] wrote:
I don't undestand the reasoning here.
My understanding is that we implicitly deprecated receivers
relying on fallback to A in 2821.
We did no such thing.
Section 5 makes it
On Thu, 27 Mar 2008, Matti Aarnio wrote:
There will be lots of legacy codes using legacy APIs for long future.
I do use getaddrinfo() API myself, and permit it do all queries to
get addresses. Thus it will also query for A in addition to .
It can even be ordered to ignore IPv4 or IPv6
In an IETF that believes the potential recursion of URNs and
NAPTR records is reasonable, it is really hard for me to get
excited about that one possible extra lookup. YMMD, of course.
I can't get excited about this either.
Doug's issue, which sparked off this latest debate, would
In an IETF that believes the potential recursion of URNs and
NAPTR records is reasonable, it is really hard for me to get
excited about that one possible extra lookup. YMMD, of course.
I can't get excited about this either.
Doug's issue, which sparked off this latest debate,
On 27 Mar 2008, at 20:38 , Mark Andrews wrote:
OTOH, I think standardizing this convention makes all sorts of
sense, but
not, of course, in 2821bis.
Why not in 2821bis? Is 2821bis really that time critical?
I would prefer to see the empty field intention implicit in MX 0 .
On 27 Mar 2008, at 20:38 , Mark Andrews wrote:
OTOH, I think standardizing this convention makes all sorts of
sense, but
not, of course, in 2821bis.
Why not in 2821bis? Is 2821bis really that time critical?
I would prefer to see the empty field intention implicit in MX 0
--On Friday, 28 March, 2008 11:38 +1100 Mark Andrews
[EMAIL PROTECTED] wrote:
OTOH, I think standardizing this convention makes all sorts
of sense, but not, of course, in 2821bis.
Why not in 2821bis? Is 2821bis really that time critical?
It is on its way to Draft Standard. This
Total of 257 messages in the last 7 days.
script run at: Fri Mar 28 00:53:01 EDT 2008
Messages | Bytes| Who
+--++--+
6.23% | 16 | 5.84% | 102664 | [EMAIL PROTECTED]
4.28% | 11 | 7.20% | 126614 | [EMAIL
That is all well and good, but it is completely of value to the receiving
MTA, and under their complete control. There is nothing that requires a
receiving MTA to follow this model, despite what others may see as value.
well, if you want to receive mail from other domains without special
The IESG has no problem with the publication of 'NAT and Firewall
Traversal Issues of Host Identity Protocol (HIP) Communication'
draft-irtf-hiprg-nat-04.txt as an Informational RFC.
The IESG would also like the RFC-Editor to review the comments in the
datatracker
The IESG has approved the following document:
- 'The Transport Layer Security (TLS) Protocol Version 1.2 '
draft-ietf-tls-rfc4346-bis-10.txt as a Proposed Standard
This document is the product of the Transport Layer Security Working
Group.
The IESG contact persons are Tim Polk and Pasi
A new Request for Comments is now available in online RFC libraries.
RFC 5198
Title: Unicode Format for Network Interchange
Author: J. Klensin, M. Padlipsky
Status: Standards Track
Date: March 2008
Mailbox:[EMAIL
29 matches
Mail list logo
