On Wed Mar 29 03:08:59 2006, Brett Thorson wrote:
I think it interesting that the great minds of the IETF are
discussing in
depth something that is probably just slightly more important than
the
outcome of this week's American Idol contest. Oh well, here are my
two
cents...
There's several
Cookies seem to be a scarce resource, so why not bring your own darn
cookies to the meeting, and you wouldn't have a problem. Seriously, stop
by a local grocery store, and plop down $3 and buy whatever kind of
cookies make you the most happy. Aggravation avoided.
That's a very
Hi Jordi,
On Friday 24 March 2006 06:10, JORDI PALET MARTINEZ wrote:
Not really. If you look to the recent sponsors, the current one and
the next one, they are all European companies, hosting IETF in
North America.
Actually it can be presented in the other way around, as they host
here, 50%
On Tue, Mar 28, 2006 at 06:47:46AM -0800, Dave Crocker wrote:
[EMAIL PROTECTED] wrote:
ah yes, the IETF as a FormulaOne race car.
I'll approach CocaCola Visa for branding rights
if that would help (esp for those folks denied a 770)
ah yes, the ad absurdem form of
Hi Julien,
I guess is a question of planning.
I tend to book my flights at least 3 months ahead.
Then a flight Madrid-Europe-Madrid, for example, could be so law as 80 Euros
(replace Europe with Munich, London, Paris, Brussels, or any other preferred
EU destination).
For the same period (a
Well, in the case of IPv6 we're currently playing in a sandbox 1/8 the
size of the available address space. So if what you say is true, and we
manage to use up an exponential resource in linear time, then we can
change our approach and try again with the second 1/8 of the space,
without having to
Jordi,
You are speaking about low cost flights. I am sure they are readily
available from/to any capital like Madrid, but what about other
places. When I want to go from a secondary french city to a secondary
city in germany without over the week-end stay (say monday-thursday)
the prices can
On Tue, Mar 28, 2006 04:12:24PM -0500, Noel Chiappa allegedly wrote:
locators are a lot easier to deal with if they're
location-independent
Huh? Did you mean identifiers are a lot easier to deal with
if they're location-independent?
I really was talking about
You didn't mean locators are a lot easier to deal with if the name
has nothing to do with where the thing it names is, you meant
locators are a lot easier to deal with if their meaning (i.e. the
thing they are bound to) is the same no matter where you are when
you evaluate them.
This is a
On 29-mrt-2006, at 16:17, Keith Moore wrote:
it would be okay if the only apps you needed to run were two-party
apps. in other words, it's not just users and hosts that need
addresses to be the same from everywhere in the network - apps need
stable addressing so that a process on host A
it would be okay if the only apps you needed to run were two-party
apps. in other words, it's not just users and hosts that need
addresses to be the same from everywhere in the network - apps need
stable addressing so that a process on host A can say to a process on
host B, contact this
We could ask the IEEE, since the relationship between the WiFi folks and
IEEE 802.11 seems to be somewhat similar.
One of the problems I see is that many of the industry associations (SIP
Forum, IPv6 forum, to name two I'm somewhat familiar with) tend to focus
on service providers, not
On 29-mrt-2006, at 16:43, Keith Moore wrote:
it would be okay if the only apps you needed to run were two-
party apps. in other words, it's not just users and hosts that
need addresses to be the same from everywhere in the network -
apps need stable addressing so that a process on host A
it would be okay if the only apps you needed to run were
two-party apps. in other words, it's not just users and hosts
that need addresses to be the same from everywhere in the
network - apps need stable addressing so that a process on host
A can say to a process on host B, contact this process
Hi Julien,
Well, that's not the case in Spain. If instead of Madrid I'm in small city
like Valencia, Murcia, Bilbao, etc., typically the cost different will be
only 10-15 Euros more. The companies make the money from the big hop, and if
necessary subsidize part of the small one to sell more
Jeroen Massar wrote:
I guess you missed out on:
http://www.iana.org/assignments/ipv6-address-space
I declined to co-author it, as a matter of fact. It started as GUSL
(Globally Unique Site Locals), did you miss that season? Read the dark
side stuff I will post later...
Austin Schutz wrote:
On 29-mrt-2006, at 18:34, Keith Moore wrote:
- DNS is often out of sync with reality
Dynamic DNS updates are your friend.
From an app developer's point-of-view, DDNS is worthless. DDNS is far
from universally implemented, and when it is implemented, it's often
implemented badly. DDNS can
Point made many times, and the proof is in the pudding: if they're using
it so widely it means it works for them.
Actually, no. The world is full of examples of practices and mechanisms
that are widely adopted and entrenched that work very poorly. You only
have to look at any day's
- DNS is often out of sync with reality
Dynamic DNS updates are your friend.
From an app developer's point-of-view, DDNS is worthless. DDNS is far
from universally implemented, and when it is implemented, it's often
implemented badly. DDNS can actually makes DNS a less reliable source
of
Are you saying that ENUM is a dead end?
F.
--
[EMAIL PROTECTED]
819 692 1383
On Wed, 29 Mar 2006, Keith Moore wrote:
- DNS is often out of sync with reality
Dynamic DNS updates are your friend.
From an app developer's point-of-view, DDNS is worthless. DDNS is far
from universally
Iljitsch van Beijnum wrote:
...including the RIR reserves which are at an
all time high of nearly 400 million)
Also, keep in mind that the RIRs are not the only ones to have reserves.
The address space itself has reserves, class E for example. ISPs have
reserves, and customer have reserves too
Francois Menard wrote:
Are you saying that ENUM is a dead end?
F.
--
[EMAIL PROTECTED]
819 692 1383
ENUM is a dead born child.
ENUM is supposed to be good for VoIP. Well, I do have VoIP but my VoIP
does work allthough ENUM does not. My router could use ENUM - but which
one should I ask,
From: Michel Py [EMAIL PROTECTED]
We aren't *ever* going to give everyone PI space (at least, PI space
in whatever namespace the routers use to forward packets) ...
Routing (i.e. path-finding) algorithms simply cannot cope with
tracking 10^9 individual destinations (see
On Thu Mar 30 00:06:25 2006, JFC (Jefsey) Morfin wrote:
Now, consider that in that city one does go by street numbers but
by building names. As we did for a very long time and many still
do. So our building is named by the City Registry Innovation
House - and if a day it is scrapped and
Brian E Carpenter wrote:
Keith Moore wrote:
It will also be a more open process. Today, in my opinion, having to
negotiate with each possible sponsor in secret, is a broken concept,
and
against our openness.
I'm a lot more concerned about openness in IETF protocol development.
some
At 01:28 30/03/2006, Dave Cridland wrote:
On Thu Mar 30 00:06:25 2006, JFC (Jefsey) Morfin wrote:
Now, consider that in that city one does go by street numbers but
by building names. As we did for a very long time and many still
do. So our building is named by the City Registry Innovation
At 20:46 29/03/2006, Michel Py wrote:
Just to make it clear: I'm not in denial and v4 exhaustion is not FUD,
but the Internet is not going to stop the day after we allocate the last
bit of v4 space either.
The issue is not so much when we will be prevented from doing what we
currently do. It
Thus spake Noel Chiappa [EMAIL PROTECTED]
From: Michel Py [EMAIL PROTECTED]
We aren't *ever* going to give everyone PI space (at least, PI space
in whatever namespace the routers use to forward packets) ...
Routing (i.e. path-finding) algorithms simply cannot cope with
Iljitsch van Beijnum writes:
So how big would you like addresses to be, then?
It's not how big they are, it's how they are allocated. And they are
allocated very poorly, even recklessly, which is why they run out so
quickly. It's true that engineers always underestimate required
capacity, but
Title: Re: Making IETF happening in different regions
Definitively, from Europe, for me seems the most
expensive Australia, thenAsia Pacific/Africa...
... and for those of us on the "outskirts" of
Europe,
the ratio in flight prices to the US as compared to
the EU
can easily exceed a
Title: Re: Making IETF happening in different regions
these days, many IETFer are from asia. Asia cities
also should be a choice. actually, the accommodations in many asia cities are
very cheap while the flight price to ASIA is not much different from the price
of flight to america or
On 29/03/2006, at 5:10 AM, Scott Leibrand wrote:
On 03/28/06 at 7:00am +0200, Anthony G. Atkielski
[EMAIL PROTECTED] wrote:
Agreed, but they reduce the amount of money you must pay to your ISP
each month by a factor of ten or more.
Your ISP charges you 9 times as much for IPv4 addresses
The IESG has received a request from the Public-Key Infrastructure (X.509) WG
to consider the following document:
- 'Update to DirectoryString Processing in the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile '
The IESG has approved the following document:
- 'JavaScript Object Notation (JSON) '
draft-crockford-jsonorg-json-04.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 Scott Hollenbeck.
A URL
The IESG has approved the following document:
- 'Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0 '
RFC 2613 as a Draft Standard
This document is the product of the Remote Network Monitoring Working Group.
The IESG contact persons are Bert Wijnen and David Kessens.
A
The IESG has approved the following document:
- 'Encapsulation Methods for Transport of Frame Relay Over MPLS Networks '
draft-ietf-pwe3-frame-relay-07.txt as a Proposed Standard
This document is the product of the Pseudo Wire Emulation Edge to Edge Working
Group.
The IESG contact persons
The IESG has approved the following document:
- 'The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) '
draft-songlee-aes-cmac-prf-128-03.txt as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG
The IESG has approved the following document:
- 'A Roadmap for TCP Specification Documents '
draft-ietf-tcpm-tcp-roadmap-06.txt as an Informational RFC
This document is the product of the TCP Maintenance and Minor Extensions
Working Group.
The IESG contact persons are Jon Peterson and
A new Request for Comments is now available in online RFC libraries.
RFC 4441
Title: The IEEE 802/IETF Relationship
Author: B. Aboba, Ed.
Status: Informational
Date: March 2006
Mailbox:[EMAIL PROTECTED]
A new Request for Comments is now available in online RFC libraries.
RFC 4430
Title: Kerberized Internet Negotiation of Keys
(KINK)
Author: S. Sakane, K. Kamada,
M. Thomas, J. Vilhuber
Status:
A new Request for Comments is now available in online RFC libraries.
RFC 4450
Title: Getting Rid of the Cruft:
Report from an Experiment in Identifying
and Reclassifying Obsolete Standards Documents
Author: E.
A new Request for Comments is now available in online RFC libraries.
RFC 4443
Title: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6
(IPv6) Specification
Author: A. Conta, S.
42 matches
Mail list logo
