On Jun 25, 2010, at 09:56, Brian E Carpenter wrote:
trying v6 for a couple of seconds before trying v4 in parallel
I don't think this is realistic for applications like the Web, where people are
now creating Youtube-Spots with high-speed cameras that show, in slow-motion, a
potato cannon
On 2010-06-25 20:08, Carsten Bormann wrote:
On Jun 25, 2010, at 09:56, Brian E Carpenter wrote:
trying v6 for a couple of seconds before trying v4 in parallel
I don't think this is realistic for applications like the Web, where people
are now creating Youtube-Spots with high-speed cameras
On Jun 25, 2010, at 16:16, Brian E Carpenter wrote:
initial phase of contact with a server
To get the front page of the New York Times (http://www,nytimes.com), a
server a couple of minutes ago meant
http://admin.brightcove.com/
http://b.scorecardresearch.com/
http://creativeby1.unicast.com/
Phillip:
Obviously, I was not General AD when this happened. However, I was
Security AD at the time, so I was involved in the discussions that
included the whole IESG.
I made my reply to your posting because I want people to realize that
there is another side to the story. We need to learn
Scott Lawrence wrote:
The main drawback of this would be
that a document would sometimes need to exist for longer as an I-D while
implementations are developed, but balancing that is the fact that those
implementations would then inform the first RFC version rather than some
subsequent
I've mentioned this to Russ privately, but it's worth saying it out loud ...
Phillip:
Obviously, I was not General AD when this happened. However, I was
Security AD at the time, so I was involved in the discussions that
included the whole IESG.
I made my reply to your posting because I want
The ISD proposal
required the IESG spend a lot of time that the individuals simply did
not have.
so the IESG insisted - that was not the opinion of the newtrk chair
(who thought that ISDs would likely reduce the load on ADs
Further, this came at a very, very bad time
and that, apparently,
I support publication of this document as Proposed Standard. The
DISTRIBUTIONS, MODERATORS, MOTD, and SUBSCRIPTIONS commands have been
implemented in INN for years and are supported by many NNTP clients, and
the additional status flags in LIST ACTIVE have been in use in INN for
many years.
LIST
I can't remember offhand if DNS got to full standard or not, lets say for
the sake of argument that it did.
If we want to make a significant change to DNS, such as yank out some
features that were never used, we have a minimum of about six years before
the change can be made.
First we would have
I strongly disagree with the use of NAPTR. It has a ridiculous amount of
power and mechanism. SRV is well supported in servers, NAPTR is not.
The process of standards making is to eliminate unnecessary flexibility. In
this case the configuration of the caldav Web host is not relevant to the
Hi Ben,
First of all, I sincerely appreciate your review work on our I-D.
I tried to address all of your comments with a revised version:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-04.txt
The difference between version 03-and version-04
[Sorry, got Cullens' out of thread, did not realize there was more debate
since, replying to a number of different posters here]
I really do not like the idea of a new RR unless it can be shown that SRV is
not sufficient.
There are still issues deploying new RRs. Windows DNS does not provide an
Nah, the service provider tells the client what to use via SRV records.
In most cases the service provider is going to know if IPv4 or IPv6 is going
to work better. They use different DNS names for the v4 and v6 interfaces
and prioritize them accordingly.
In most cases though the server is going
Code will be used for decades which is why IPv4 will always be with us.
The IPv4-6 transition will inevitably take place in middleboxes. Most actual
networks will use IPv4 internally and IPv6 will be an Inter-Network
protocol.
Trying to code for the end state before the middlebox spec is known
Has anyone talked to anyone in the applications world about this?
The use of a new DNS Resource Record creates far more problems than any of
these proposed discovery mechanisms offer. No matter how much the DNSEXT
people want to believe that adding DNS records is not an issue, the fact is
that it
Yes, I agree that the IETF has become a lot more open than the
self-perpetuating cabal that ran it during the mid 90s.
We no have de-facto term limits for ADs and it is no longer considered
acceptable for an AD to chair a working group (excepting process related
groups chaired by the IETF chair).
Am I the only person that thinks that if shaving 50ms off HTTP latency is a
worthwhile goal it would be more appropriate to look at a DNS based
signaling mechanism that is going to support that goal (and also do the
right thing for IPv4/6) rather than look at various ways to coax the desired
Hi all,
I haven't been able to find it but maybe someone knows here: Have there
been a protocol defined for checking whether TCP peer is alive or not?
(I mean one that plays well with networks with various latencies and
throughputs and won't congest the network even if used on a wide scale.)
Phillip,
On Jun 25, 2010, at 10:06 AM, Phillip Hallam-Baker wrote:
Am I the only person that thinks that if shaving 50ms off HTTP latency is a
worthwhile goal it would be more appropriate to look at a DNS based signaling
mechanism that is going to support that goal (and also do the right
On Friday 25 June 2010 20:46:45 ext Martin Sustrik, you wrote:
I haven't been able to find it but maybe someone knows here: Have there
been a protocol defined for checking whether TCP peer is alive or not?
(I mean one that plays well with networks with various latencies and
throughputs and
Rémi Denis-Courmont wrote:
On Friday 25 June 2010 20:46:45 ext Martin Sustrik, you wrote:
I haven't been able to find it but maybe someone knows here: Have there
been a protocol defined for checking whether TCP peer is alive or not?
(I mean one that plays well with networks with various
I trust you are familiar with section 4.2.3.6 of RFC 1122.
Bob Braden
On 6/25/2010 10:46 AM, Martin Sustrik wrote:
Hi all,
I haven't been able to find it but maybe someone knows here: Have there
been a protocol defined for checking whether TCP peer is alive or not?
(I mean one that plays
On Friday 25 June 2010 21:10:45 ext Martin Sustrik, you wrote:
Rémi Denis-Courmont wrote:
On Friday 25 June 2010 20:46:45 ext Martin Sustrik, you wrote:
I haven't been able to find it but maybe someone knows here: Have there
been a protocol defined for checking whether TCP peer is alive or
Bob Braden wrote:
I trust you are familiar with section 4.2.3.6 of RFC 1122.
Yes. I am aware of it.
I was just interested in whether the behaviour have been defined for
those who need early failure detection (systems with failover
capabilities) and are willing to pay for the additional
Rémi Denis-Courmont wrote:
What I had in mind whether there ever been an attempt to define dynamic
keepalive algorithm that adjusts keepalive intervals according to the
observed throughput and roundtrip latency figures (dynamic in the same
way as CC dynamically adjusts throughput).
Any ideas?
On Thursday, June 24, 2010 22:01 Phillip Hallam-Baker wrote:
snip/
We currently have the idiotic position where RFC821 is a full standard and
RFC2821 which obsoletes it is not.
Why is this idiotic. RFC 821 needed to be obsoleted. It had some features that
needed to be removed, and some
Hi Ted,
The mechanism's not in TCP because the definition of a failed peer is
application dependent. A chemical plant automation application probably
has different requirements about when to treat a peer as failed than an
application that updates cute cat pictures, or one that keeps internet
I was just interested in whether the behaviour have been defined for those
who need early failure detection (systems with failover capabilities) and
are willing to pay for the additional bandwidth used (financial sector).
Why didn't you say so in the first place?
I believe that the common
In message 0ddf0b8f-4d3e-42d7-97c5-944cb0171...@tzi.org, Carsten Bormann writ
es:
On Jun 25, 2010, at 16:16, Brian E Carpenter wrote:
initial phase of contact with a server
To get the front page of the New York Times (http://www,nytimes.com), a serv
er a couple of minutes ago meant
Phillip Hallam-Baker wrote:
What really worries me is that there are people who are busy inventing new
discovery mechanisms for Internet protocols via HTTP who are completely
ignoring the existing DNS infrastructure.
Well, I'm worried about the security nightmare that is going to
happen when
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'The OAM Acronym Soup '
draft-ietf-opsawg-mpls-tp-oam-def-06.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 Deployment in Internet Exchange Points (IXPs) '
draft-ietf-v6ops-v6inixp-08.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the Audio/Video Transport WG (avt)
to consider the following document:
- 'Forward-shifted RTP Redundancy Payload Support '
draft-ietf-avt-forward-shifted-red-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has approved the following document:
- 'ZRTP: Media Path Key Agreement for Unicast Secure RTP '
draft-zimmermann-avt-zrtp-22.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Robert
A new Request for Comments is now available in online RFC libraries.
RFC 5904
Title: RADIUS Attributes for IEEE 802.16
Privacy Key Management Version 1 (PKMv1)
Protocol Support
Author: G. Zorn
Status:
35 matches
Mail list logo
