On 17 jul 2008, at 23.33, IETF Chair wrote:
The IESG is considering an experiment for IETF 73 in Minneapolis, and
we would like community comments before we proceed. Face-to-face
meeting time is very precious, especially with about 120 IETF WGs
competing for meeting slots. Several WGs are
On 8 jul 2008, at 20.41, Keith Moore wrote:
1) I do understand where the current last 64 bits are EUId comes
from.
2) Someone (I think it was Keith Moore) said that if the scheme
doesn't work for servers AND hosts (i.e no difference) it's a bad
scheme. I sort of agree with that, but the
(Apologies for the late reply)
On 4 jul 2008, at 15.10, John C Klensin wrote:
--On Friday, 04 July, 2008 10:46 +0200 Kurt Erik Lindqvist
[EMAIL PROTECTED] wrote:
On 3 jul 2008, at 15.57, Jeroen Massar wrote:
On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote:
[..]
However
On 3 jul 2008, at 15.57, Jeroen Massar wrote:
On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote:
[..]
However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not
explicitly configured on the sending server; instead, it is being
implicitly
configured through ip6 autoconf
On 3 jul 2008, at 15.57, Jeroen Massar wrote:
On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote:
[..]
However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not
explicitly configured on the sending server; instead, it is being
implicitly
configured through ip6 autoconf
On 14 mar 2008, at 13.01, Jari Arkko wrote:
We should also implement future IPv6 experiments and network
deployments.
But why I'm really sending this e-mail is to suggest that IPv6 might
not
be the only topic for such future efforts. Here's a challenge for the
RAI folks: What about
I just wanted to clarify one of the points on my Wed plenary slides.
The Code Sprint was organised by the IETF tools-team , and credit for
getting that organised and successful should go to the tools-team and
Bill and Henrik! I don't think we can enough appreciate the work that
The community was told at the IETF 69 Wednesday Evening Plenary
Session to expect a meeting fee increase for IETF 70 in Vancouver.
The purpose of this message it to advise you of the amount of the
increase and provide the reasons for the increase.
We are into September, which means
The community was told at the IETF 69 Wednesday Evening Plenary
Session to expect a meeting fee increase for IETF 70 in Vancouver.
The purpose of this message it to advise you of the amount of the
increase and provide the reasons for the increase.
We are into September, which means
The IAOC will again be holding open office hours in Parlor A on
Wednesday 16.00-17.00
Thursday 16.00-17.00
On behalf of the IAOC
- kurtis -
___
IETF-Announce mailing list
IETF-Announce@ietf.org
The IAOC will again be holding open office hours in Parlor A on
Wednesday 16.00-17.00
Thursday 16.00-17.00
On behalf of the IAOC
- kurtis -
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
All,
The IAOC minutes are posted, whenever available, at http://
iaoc.ietf.org/minutes.html. Since the days of the IASA transition
team, Marshall Eubanks has acted alone as the scribe for the IAOC.
On behalf of the IAOC I would like to take this opportunity to thank
Marshall
All,
The IAOC minutes are posted, whenever available, at http://
iaoc.ietf.org/minutes.html. Since the days of the IASA transition
team, Marshall Eubanks has acted alone as the scribe for the IAOC.
On behalf of the IAOC I would like to take this opportunity to thank
Marshall
On 6 nov 2006, at 22.05, Patrik Fältström wrote:
On 17 okt 2006, at 09.33, John C Klensin wrote:
Of course, as suggested in earlier notes, I'd find the idea of
endorsements (supporters) completely acceptable and even a
good idea (i) if anyone in who participates actively in the IETF
could do
I did this the last time we where in San Diego. The only thing to be
concerned about is at least United operated small planes with not to
good frequency (at least then) and tends to fill up on Saturday
afternoon and Sunday morning (I noticed).
Then going from International to domestic at
On 28 mar 2006, at 18.00, Hallam-Baker, Phillip wrote:
From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED]
NAT is a dead end. If the Internet does not develop a way
to obsolete
NAT, the Internet will die. It will gradually be replaced
by networks
that are more-or-less IP based
On 28 mar 2006, at 00.11, Keith Moore wrote:
NAT is a done deal. It's well supported at network edges. It solves
the addressing issue, which was what the market wanted. It voted
for NAT with
dollars and time. It is the long term solution - not because it is
better, but
because
On 28 mar 2006, at 13.46, Keith Moore wrote:
NAT is a dead end. If the Internet does not develop a way to
obsolete NAT, the Internet will die. It will gradually be
replaced by networks that are more-or-less IP based but which
only run a small number of applications, poorly, and
On 3 mar 2006, at 17.58, Peter Dambier wrote:
To best of my knowledge, that there are no new Chinese root-
servers - despite what the press says. And at least we have not
seen a drop in queries to our anycast instance in Beijing yet so
there even seems to be data to support that...
But
On 3 mar 2006, at 18.15, Joe Baptista wrote:
Kurt Erik Lindqvist wrote:
To best of my knowledge, that there are no new Chinese root-
servers - despite what the press says. And at least we have not
seen a drop in queries to our anycast instance in Beijing yet so
there even seems
On 5 mar 2006, at 11.11, Peter Dambier wrote:
Kurt Erik Lindqvist wrote:
On 3 mar 2006, at 18.15, Joe Baptista wrote:
Kurt Erik Lindqvist wrote:
To best of my knowledge, that there are no new Chinese root-
servers - despite what the press says. And at least we have
not seen a drop
On 2 mar 2006, at 09.26, Mohsen BANAN wrote:
More than 5 years ago I predicted what the Chinese
government announced today.
What happened today:
http://english.people.com.cn/200602/28/eng20060228_246712.html
http://www.interfax.cn/showfeature.asp?aid=10411slug=INTERNET-
On 6 okt 2005, at 10.00, JFC (Jefsey) Morfin wrote:
We now have 1.5 billions (most of the Internet users and many more)
who will access the NewStar root file.
As Spencer pointed out - you won't. .gprs is for the infrastructure
that the users are connected to.
Besides that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The Internet Engineering Task Force (IETF) is responsible for
developing and defining the standards and protocols that make up the
Internet. The IETF was established in 1986, and has since then been
the center of development for the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2005-01-14, at 11.50, Brian E Carpenter wrote:
John C Klensin wrote:
... but I note that we are still turning over rocks from
which new issues crawl.
And the first year of operation will certainly reveal
other issues, which may move faster
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
Please find below an updated version of the IAD job announcement. This
is based on the feedback we received here on the list, as well as on
feedback received from a professional. The comment period this time
will be until Sunday
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
please find below the draft call for applications for the IAD position.
The current timeline for moving forward is as follows
DEC 18 Send out call for applications to
o IETF-Announce list
o ISOC announcement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-12-13, at 08.41, Bernard Aboba wrote:
Margaret Wasserman wrote:
ISOC's finances are already audited by an independent auditing firm
on a
yearly basis.
Yes -- but the yearly audit typically isn't focused on validating
whether
the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-12-09, at 17.02, Bernard Aboba wrote:
Suggest this be rewritten to:
The IAOC is accountable for the structure of the IASA and thus decides
which functions are to be outsourced. All outsourcing must be via
well-defined contracts or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-12-09, at 16.58, Bernard Aboba wrote:
Section 5.1
For bookkeeping purposes, funds managed by IASA should be accounted
for
in a separate set of accounts which can be rolled-up periodically to
the
equivalent of a balance sheet and a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-11-20, at 05.13, JFC (Jefsey) Morfin wrote:
This does not mean that you are bound to a single number, the same you
are not bound to a single mobile. Let not think the users should do
it the way I think, but I am to permit the users to do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-11-18, at 10.26, JFC (Jefsey) Morfin wrote:
This is for example what the French FCC is investigating in public
questionnaire right now, and I suppose they are not alone. A number
users will get at birth or creation (with additional ones
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-11-18, at 19.30, Franck Martin wrote:
For the moment what I'm working on is on ensuring that countries can
get assigned a reasonable amount of IPv6 space. A lot of countries are
below radar in the IPv6 assignement. When you have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-11-08, at 14.28, Bill Manning wrote:
That's inconsistent with the published policy.
No. See above.
When there is an inconsistency, you can't fix it by adding more data.
You need to remove/change something. The fact that the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-11-08, at 22.22, Iljitsch van Beijnum wrote:
On 8-nov-04, at 19:31, Kurt Erik Lindqvist wrote:
Well, the RIRs will actually hand out address-space explicitly saying
they make no guarantees for routability. If you apply for IPv4 PI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-11-08, at 21.55, JORDI PALET MARTINEZ wrote:
Hi Harald, Marcia,
I'm not sure what is the problem, but as you probably know, we still
don't
have IPv6 in the IETF61 network, which is really bad.
The worst thing is not getting anyone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We must be talking about two different Internets.
- - kurtis -
On 2004-05-19, at 21.46, jfcm wrote:
At 18:12 19/05/04, Kurt Erik Lindqvist wrote:
- I talk of real world when you talk of the current (unsecure and
overloaded?) implementation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- I talk of real world when you talk of the current (unsecure and
overloaded?) implementation of the current DNS architecture.
In what way overloaded? Do you have any pointers? Proof? Data?
The problem we face is an old and too large unique
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-05-19, at 00.54, Dean Anderson wrote:
On 18 May 2004, Paul Vixie wrote:
The result is a service which has never been down hard, not ever,
not for
any millisecond out of the last 15 years. This is strength by
diversity.
This isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-05-11, at 23.55, Dean Anderson wrote:
On Tue, 11 May 2004, Joe Abley wrote:
For the benefit of less-operational people here who don't see humour
in
this, 198.32.176.0/24 is the PAIX IPv4 peering fabric in the Bay Area.
This block is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I thought I needed to pay to get to most ITU standards. But I might be
wrong.
I can't see how personal closed discussions relate to open
standardization. Are you saying that you want to have an open process,
as long as you have a direct channel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-05-17, at 00.22, Dean Anderson wrote:
On Sun, 16 May 2004, Thomas Bocek wrote:
Hi
Im confused with the fact than the number of root servers is limited
to 13.
From RFC 3226:
The current number of root servers is limited to 13 as
02/12/03, Kurt Erik Lindqvist wrote:
Hasn't this idea been killed enough? I am a newbie on the Internet
(only been here since 1988) and _I_ am fed up with this discussion.
Hi! Kurt,
did not see that one. I will respond it because it may help you
understanding. I am also a newbie as I only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I agree and realize this. However, the let's take that argument out
in the open and not hide it behind national security.
I regret such an agressiveness. I simply listed suggestions I
collected to ask warning, advise, alternative to problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The post KPQuest updates are a good example of what Govs do not
want
anymore.
I can't make this sentence out. Do you mean the diminish of KPNQwest?
In that case, please explain. And before you do: I probably know more
about KPNQwest than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On onsdag, dec 3, 2003, at 04:12 Europe/Stockholm, Franck Martin wrote:
ITU is worried like hell, because the Internet is a process that
escapes the Telcos. The telcos in most of our world are in fact
governments and governments/ITU are saying
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On fredag, nov 28, 2003, at 20:10 Europe/Stockholm, Anthony G.
Atkielski wrote:
Ah, I see what you mean now. However, the devision is a done deal as
RFC 3513 mandates that all unicast IPv6 addresses except the ones
starting with the bits 000
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The post KPQuest updates are a good example of what Govs do not want
anymore.
I can't make this sentence out. Do you mean the diminish of KPNQwest?
In that case, please explain. And before you do: I probably know more
about KPNQwest than anyone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This being said, I note that this thread is only oriented to
prospective numbering issues. May I take from that that none of the
suggested propositions rises any concern ?
In particular, that there is no problem with two parallel roots file
if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- Do not flood root servers with reverse lookup queries for
private addresses (I want my traceroutes to work on the
inside of the network too, so I long ago configured reverse
lookup for private addresses on my internal DNS servers).
Kurt Erik
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On måndag, okt 13, 2003, at 18:58 Europe/Stockholm, Michel Py wrote:
- Do not flood root servers with reverse lookup queries for private
addresses (I want my traceroutes to work on the inside of the network
too, so I long ago configured
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
| I don't think another 10% load on the root nameservers is a huge
deal,
| so I wouldn't use the word harmful but I guess this is a special
case
Again. You'll have to ask the operators of the root-zone if they
consider 11-14% a big deal.
By-the-way, Neulevel (.us and .biz) did an experiment along these
lines
back in May of this year. It was short lived. At the time I thought
it
was a bad thing, and I still do. And at the time I wrote and sent to
the
ICANN board an evaluation of the risks of that experiment.
.nu have been
On onsdag, aug 27, 2003, at 18:20 Europe/Stockholm, Jeroen Massar wrote:
The multi6 wg has been working on locator/identifier separation as a
way to solve the multihoming in IPv6 problem for a while now.
And ever since they haven't progressed much unfortunatly :(
Hard to tell. There are two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you use LDP, it is NOT a routing protocol. The specific mode of
use
(targeted LDP) is already described in RFC 3036. The FECs are
different, but
the FEC TLV was defined in such a way as to be extensible.
And when you want to do this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- we must not overload routing protocols and such infrastructure
(IMHO,
this seems an inevitable path the work would go towards..)
If you use LDP, it is NOT a routing protocol. The specific mode of use
(targeted LDP) is already described in
How about the cost of legitimate emails that get filtered and never
read. Not everyone scans the list to check for false positives.
In a major example of false positives, we already have examples of one
real cost of spam. AOL (as one example of many) has declared ranges of
IP addresses marked
On lördag, maj 31, 2003, at 06:12 Europe/Stockholm, Michel Py wrote:
Rob Austein wrote
Traffic statistics (as seen from my cave, your mileage
may vary) for the last seven days on the [EMAIL PROTECTED]
mailing list.
Thanks for posting this. I was about to join another poster in saying
that you
David,
let's not mix the problem with provider independent addressspace with
the SL issue. The first needs to be solved anyway, and SLs are not the
answer.
Best regards,
- kurtis -
What happens when you change providers?
Rgds,
-drc
On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie
layers above it and a dangerous blow to the hour glass model.
Looking at what is going on in the IETF, I think we are talking about
first aid rather than trying to prevent the blow as such. That happened
along time ago...:-(
But yes, we need to protect the architectural model or discuss a new
Because such thing does not exist, it's called PI and is not available
to IPv6 end-sites. And if it ever is, it will cost money or other
annoyances to obtain.
SLs won't come for free either. Architecture aside, I prefer people
that use a service to pay for it rather than the community as such.
I can't find the mail address of the IETF56 NOC, but in Continental7
there is a overlap on channel 6 between two basestations, but you might
already know that.
ietf56 00:0C:30:25:9C:DF 11
15 Managed unknown No (null)
ietf56
Speaking from a purely extremely selfish point of view, as a North
American, how much would it help if we were to cut back to one meeting
outside North America every 5-6 IETF's, instead of once a year, which
seems to be the current rate?
I was not able to get travel funding to go to Yokohama, and
Be liberal in what you accept seems a good philosophy for reading
this
list...
As a very intelligent man told me once - The good thing about
'Subject' is that you know what you can delete without reading it.
- kurtis -
I think this is a really, really, really bad idea. This is my first IETF.
I had read all the drafts of what interested me before going here. I
thought that was enough. Boy was I wrong. I am now also subscribed to the
mailiglists...
However, I have been to several of the other gatherings of the
I think this is a really, really, really bad idea. This is my first IETF.
I had read all the drafts of what interested me before going here. I
thought that was enough. Boy was I wrong. I am now also subscribed to the
mailiglists...
However, I have been to several of the other gatherings of
ipv6 is working just fine even here at IETF49 venue, it's so much more
convenient than IPv4, for couple of reasons.
We can't use IPv6 until multihoming issues are properly solved
and global routing table size and the number of ASes are
controlled to be below reasonable upper
67 matches
Mail list logo
