ere is something left in the address cupboard marked 'E"
that conceivably is there to use if we really _have_ to.
Geoff Huston
At 06:19 PM 20/04/2004, Iljitsch van Beijnum wrote:
I was wondering if there are any plans to change the status of the class E
address space (240.0.0.0 - 25
I believe we are in complete agreement when you say:
My comfort level would be much higher if by the time that we need the
extra address space, we have a fighting chance of actually being able to
use it. So I think it would be a good idea to make it very clear that
implementations must, in the
At 7:57 PM +0200 9/6/04, Harald Tveit Alvestrand wrote:
It seems to me that we are rapidly converging on one point of total IETF
consensus:
Putting the IETF administrative function under ISOC requires a documented
IETF-ISOC agreement (call it an MoU, a contract or something else - it IS
a doc
I would like to correct a few numbers in Tony's comments based on my work
in this area that Tony has referred to.
The least squares best fit of advertised address space in the IPv4 domain
over the past 5 years is a consumption rate of 4 /8s per year, slightly
less than half of Tony's number
Ev
Chair should be a
liaison or a full member of the IAOC. There are multiple trade-offs
here, and this should be discussed by the community.]
During the Plenary last wednesday there were suggestions/proposals to
make IAB chair a voting member.
That makes a lot of sense to me
Geoff Huston
rom: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Steve Silverman
> Sent: Monday, November 15, 2004 9:43 AM
> To: Geoff Huston; Wijnen, Bert (Bert); [EMAIL PROTECTED]
> Subject: RE: AdminRest: IASA BCP: Should IAB chair be a
> voting member of IAOC
>
> It would seem to me
At 11:04 PM 17/11/2004, Margaret Wasserman wrote:
I have some comments on Section 5.3 of the IASA BCP, "Other ISOC Support".
The first paragraph of this section says:
Other ISOC support shall be based on the budget process as specified
in Section 6. ISOC will deposit the yearly amount (as ag
At 08:15 PM 17/11/2004, Olaf M. Kolkman wrote:
On Tue, 16 Nov 2004 15:57:37 -0800
Bob Hinden <[EMAIL PROTECTED]> wrote:
> We should be proactive and create a morality area in the IETF. The
> morality ADs can review and vote Discuss if the Morality Considerations
> section in drafts being reviewe
At 12:15 AM 27/11/2004, Wijnen, Bert (Bert) wrote:
In revision draft-ietf-iasa-bcp-00.txt we have text in sections
5 through 5.4 about IASA funding and where the money needs to
be kept. Specifically, the current text suggests that there
is/are one or more IASA specific bank accounts. Namely:
- Sec
At 04:34 AM 2/12/2004, Margaret Wasserman wrote:
At 3:41 PM +0100 12/1/04, Brian E Carpenter wrote:
Yes, I've always assumed there will be an MOU between IETF and ISOC,
both to recognize the BCP when we have it, and to make explicit some
of these boundary conditions.
This is interesting, because I
At 10:54 AM 2/12/2004, [EMAIL PROTECTED] wrote:
On 1 dec 2004, at 22.35, Sam Hartman wrote:
I had sort of assumed this BCP would be the MOU to the extent that one
existed.
I think that there has to be an equivalent document on the ISOC side as
indicated by Geoff, i.e. a document indicating accepta
I think you are wanting to say that "donation of funds to the IETF be
placed under the exclusive control of the IETF support program within
ISOC". This phrasing is slightly stronger than the irrevocable commitment
phrase, but does fall just short of explicitly stating 'distinct fund
account hel
Fred,
I would certainly add my voice in support of the Internet Society adopting
a specific resolution of adoption of this document (the IASA BCP,
referenced, as Scott mentions, by its RFC number). This is clear
demonstration of a level of organizational commitment that endures beyond
the curre
IETF process signing off on this document
for publication as a BCP.
Regards,
Geoff
At 02:50 PM 14/12/2004, Fred Baker wrote:
At 12:22 PM 12/14/04 +1100, Geoff Huston wrote:
I would certainly add my voice in support of the Internet Society
adopting a specific resolution of adoption of this
So instead of:
The chair of the IAOC may be removed at any time by the affirmative
vote of two-thirds of the voting members of the IAOC, or as a result
of his or her departure from the IAOC.
we could say
If the chair leaves the IAOC, or if two thirds of the voting IAOC members
vote in
I believe that the concept that "meeting registration fees must cover all
IETF suport costs" is, a best, an historical statement (and not even
correct in that context). With the changes with the IASA activity I believe
we have the opportunity to get this right, rather than muddling around
atte
And there is some risk (small, I think) of people pushing others to
endorse them. This would seem easier with a public list, because the
nomcom is not left wondering why they got the supportive email.
A risk not without quite extensive precedent over the years, and the
concept of overt electio
It seems to me that what would be required to do so would be three
statements:
ISOC's appointees do not represent ISOC, in the same way that IAB
and IESG appointees do not represent the IAB or IESG. They serve
the entire community.
Nomcom appointees do not represent a subclass of a
At 01:50 PM 12/11/2005, John wrote:
To avoid extra overload from the co-chairs during the session, and if we
want to make it more strict, if any of the presenters is not done with
his/her slides, he will not be able to talk.
"more strict"
sorry, but that's just not on - if all we are thes
riences in a related area, I cannot respond
affirmatively to this Consensus Call on the IETF on the document as it
currently stands.
regards,
Geoff Huston
At 09:38 AM 24/11/2005, Leslie Daigle wrote:
Forwarded on behalf of Lucy.
Leslie.
Original Message
Subject: Upd
* I infer that the IAOC has concluded that the present
draft agreement is about as good as we are going to get,
at least without abandoning this path, discarding the
work of the last nine or ten months, and trying
something else entirely.
The inference
(1) yes, (2) yes, (3) XML primary, and (4) see (3).
(for what its worth)
At 07:00 AM 29/11/2005, Bob Braden wrote:
*>
*>
*> Hence the desire to have the RFC Editor use xml2rfc, rather than nroff.
*>
Dave,
I am afraid you are injecting confusion. Use nroff for what? The RFC
Editor
At 02:17 AM 30/11/2005, Yaakov Stein wrote:
Henrik
> Anyway, I've added text-to-pdf conversion for all RFCs and IDs under
the URL http://tools.ietf.org/pdf/,
> so you can get pdf- conversions of our various documents.
> Comments welcome.
Well, I have only one comment. This is great!
A simple
At 09:00 AM 30/11/2005, Henrik Levkowetz wrote:
Hi Geoff,
on 2005-11-29 20:38 Geoff Huston said the following:
> At 02:17 AM 30/11/2005, Yaakov Stein wrote:
[...]
>>It would be great if I could write
>>http://tools.ietf.org/pdf/draft-ietf-pwe3-satop
>
> true.
>
&
The default setting in Firefox (and possibly safari) is to use OCSP for
validation of certificates where OCSP is referenced. The *.ietf.org
certificate has as part of the Authority Information Field the value;
OCSP: URI: http://ocsp.starfieldtech.com
This url is unreachable from many non-US sit
Like Steve Bellovin, I have always believed that I've been treated
accurately and fairly and I really don't understand what this
thread is all about.
Yes, I stand by what I said in that article. If you disagree with
my perspective on this topic, then perhaps you may want to followup
with me dir
I've been looking at this as well and reported on the relative amount
of IPv6 traffic over the past 4 years at the most recent NANOG (http://www.potaroo.net/presentations/2008-10-13-ipv6-deployment.pdf
)
in recent times I am also seeing 0.5% of hosts preferring to use IPv6
to access a dual-s
Following consultation with the
Internet Area ADs, this document is being progressed as an individual
submission to the IESG.
regards,
Geoff Huston
(SHIM6 co-chair)
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
I also note that draft-huston-ipv6-iana-specials-01.txt (currently with David
Kessens in AD review) advocates formalizing this with the creation of an IANA
IPv6 special use registry.
A further revision of the document appears to be appropriate in this case to
correct what appear
n
of publication-
ready documents in a specified set of document formats and fold the publication
and repository management tasks into the IETF Secretariat function.
regards,
Geoff Huston
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
To quote from the Carpenter draft:...
"One approach to resolving the current crisis in Internet
performance is to institute an efficient system of
inter-carrier settlements."
Progress is often hard when you are heading in off in the weeds.
Try http://www.potaroo.net/ispcol/2005-01/interconn.h
Brian,
Actually the document I referenced is also around 9 years old - so even then
we were having a Fine Debate about settlement systems in this industry.
The introduction of "Content" into this debate has also been interesting
with the earliest intersection of the two groups (ISPs and content
The real issue is that Geoff's linear projections against the
current .75
/8's per month going out from the RIRs to hit a 2012 date don't
match the
historical growth.
I suppose I should respond here, particularly as the quote about using linear
models is not a correct one.
The projection mo
On 5/25/06 at 4:30 PM -0400, Sam Hartman wrote:
Ultimately, the rfc-editor function needs to be accountable to the IETF
community because we're the ones paying for it.
when you assert that
"Ultimately, the rfc-editor function needs to be accountable to the
IETF community"
it makes s
Sayre wrote:
On 5/26/06, Geoff Huston <[EMAIL PROTECTED]> wrote:
Delving down a bit here, I suspect that, as always, the longstanding issue
here is the actual level of 'independence" of the RFC Editor, and the
potential for a player to perform an end run around the IETF Internet
St
At 01:33 PM 3/06/2006, Steven Blake wrote:
I am concerned about the conclusion reached in this document (that HD
ratios > 0.8 and closer to 0.94 should be considered when making address
allocations to larger providers).
This is a topic of interest both to the IETF and to regional addressing
p
At 02:52 PM 4/06/2006, Steven Blake wrote:
> Your representation as to the document's conclusions is simply not
> supported by the document itself.
Geoff,
I don't understand why you think my paraphrase of your document's
conclusions (including the quoted text above) is unfair or inaccurate.
I
At 06:31 AM 19/07/2006, Paul Hoffman wrote:
At 8:27 PM +0200 7/18/06, Henrik Levkowetz wrote:
Should we require that the current availability through rsync and ftp
is continued?
Maybe I'm being a bit pedantic here, but there is no RFC (or even Internet
Draft) describing rsync. Of course, runn
At 03:48 AM 28/10/2006, Bernard Aboba wrote:
Joe Abley said:
"Apologies to all concerned if I'm rudely pointing out the elephant in the
living room. This is one of two separate specifications for DLV. The
document at
http://www.isc.org/pubs/tn/isc-tn-2006-1.txt
describes an approach called
and the IESG may be of the view that the requested allocation
is sufficiently small so as to present no particular concern one way
or another.
regards,
Geoff Huston
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
But, with the expanded space, there is an issue of how to transition
to the larger numbers. This is a software problem as much as
anything. Until all software understands the bigger numbers, people
will want to continue using the 16-bit ones.
I had a shot at documenting this in the form of a
Perhaps requesting volunteers to help would reduce the work load?
The IAB did that. I *am* the volunteer :-)
I expect my www.iab.org backlog to be cleared before the end of this week.
I trust that these belated material include the ietf 69 proceedings
Thursday evening plenary?
Seems to
As for the address issue, I have to agree with PHB here as well: If these
addresses are usable in a reasonable time frame then we shouldn't be quick to
give them up for private use and if they are unusable in a reasonable time
frame it really doesn't matter what we do with them. So I guess the que
Keith Moore wrote:
One thing I'm pretty sure of is that allocating this space for another
RFC1918-like private network block isn't going to solve the collision
problem. I could see more utility in letting this be space for "router"
use only, say to allow cable ISPs to assign such addresses to
no
his instruction to IANA, I'm lead to the response to the IESG that:
1. Should this document be published?
No - I do not see adequate rational for this instruction to IANA.
2. If so...
N/A
regards,
Geoff Huston
___
Ietf mailing lis
- in the absence of full signing of the DNS from the root down, just how
many DLV spots must a resolver look in? It seems that proliferation of
DLV lookup points is no better (and arguably much worse) than the
original problem of piecemeal DNSSEC deployment - that of key hunting.
Hop
siderations,
and this document should reference them as informative references. I refer
to draft-iab-sec-cons-03.txt and RFC 2434. Consideration should be given to
publishing the draft-iab-sec-cons document concurrently with this document.
thanks,
Geoff Huston
(*)
Fred Baker 2002 - 2005
Margaret Wasserman 2003 - 2006
(*) Current term expires May 2004
Thanks,
Geoff Huston
Executive Director, IAB
A good and simple way to do this would be to create a file that matches
the draft filename without the version number (would this be that
tombstone thingy you guys keep talking about?) and say something like
"version 34 was submitted 2003-04-05" or "version 00 was deleted 1970-01-01"
You can
There's a plot of the bgp table size on an hourly
basis since 1994 at http://www.telstra.net/ops/bgptable.html
As Bill points out, this data does depend on your location
within the network topology - the above url looks at the
world from the edge of AS1221.
Geoff
> % Hi all.
> % I have read t
goofy british plug they use in HongKong?
> > flipped pairs like hongkong?
I haven't had to use a spade phone plug for over 5 years
in Australia
RJ-11's are pretty much the rule in Australian hotels these days.
---
Geoff Huston Chief Scientist, Internet
Telstra Str
and burn - this is one of them. On the other hand even doing
nothing will be a problem - we appear to have resumed exponential
growth of the routing system again, presumably as multi-homing at
the edges starts to be more and more common.
Geoff Huston
>> If it isn't an address issue, is it a routing issue? Is it that the
>> routing tables/protocols/hardware can't handle the large number of
>> routes? Are ISPs refusing to carry reasonable routes? Seems to me if
>> the entire address space was broken up into subnets of 4096, there
>> would be
At 12/16/00 10:02 PM -0500, J. Noel Chiappa wrote:
> > From: Geoff Huston <[EMAIL PROTECTED]>
>
> > There are strong indications that NAT is one factor behind this part of
> > the BGP table.
>
>I'm afraid I'm missing the logic here. As
At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote:
>The flaw in your argument is that you're assuming that the only reason
>to do NAT is because of the address space problem. My concern is that
>it may turn out that some transport/routing people may conclude that we
>may also need to do NAT to
At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote:
>The flaw in your argument is that you're assuming that the only reason
>to do NAT is because of the address space problem. My concern is that
>it may turn out that some transport/routing people may conclude that we
>may also need to do NAT to
>If people want tutorials, then I think we should have them
Did you see the Security Tutorial in the IETF 49 Agenda that was scheduled
on Sunday?
I'm unsure as to the number of folk who attended or their impressions of
what they got out of it, or what the IETF fgot out of it, as I have not
>Your message is generally well put. However, while it is possible to send
>the packets on the wire, the fundamental underlying scaling point, the
>routing system, has not been properly addressed. Perhaps a solution can be
>retrofitted in, but then again, who knows? This, I thought, was
>the
>
>Quite simply, a bunch of us *are* searching for a paradigm shift. Geoff's
>good work in this area reveals the complexity of the whys and wherefores
>of the routing system. Given that 8+8 was a serious consideration (and to
>some deserves some amount of revisiting -- at least as a starting
The essence of the architecture of mobility is to allow the identity of the
mobile device to remain constant while allowing the identity of the
location of the device within the network to vary. The dynamic DNS
approach attempts to bind the domain name as the device's persistent
identity and
ural
change, and I suspect is addressed to the IETF community in general
rather than more directly to Marshall and myself as the listed authors
of the pact draft. As I have already taken up probably too much
reader's time and patience in this response, I trust you will excuse
me if I do not continue here with any specific comments on your
suggestions.
kind regards,
Geoff Huston
>> In Section 6:
>>
>> "It is suggested to IANA to temporarily avoid allocating any
>> other address block the same /12 prefix the EID /16 prefix
>> belongs to. This is to accommodate future requests of EID
>> space without fragmenting the EID addressing space."
>>
>> Shouldn't that be under
nd if this doesn't become a success we have a bunch of /48 prefixes to the
>> separate PITRs in the BGP table. It won't be much, otherwise we would have
>> declared success. So the risk of messing the BGP table up is very limited.
>> And when can tell people: if you are bothered by those more-specifics in
>> your routing table you can always deploy your own PITRs and filter the
>> more-specifics at your border. That might keep everyone happy.
>>
>> What do you think?
>>
>> Thanks,
>> Sander
>>
> ___
> lisp mailing list
> l...@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
--
Geoff Huston
Chief Scientist, APNIC
+61 7 3858 3100
g...@apnic.net
of stakeholders in supporting the potential
requirements of a broad base of deployment of LISP in the Internet's
routing environment.
We do not support the publication of this draft as an Informational RFC.
regards,
John Curran,
Paul Wilson, and
Geoff Huston
elf and noone else
On 22/11/2012, at 6:09 AM, Robert Elz wrote:
>Date:Wed, 21 Nov 2012 17:16:58 +1100
>From:Geoff Huston
>Message-ID: <99b9866c-41d6-4784-aa69-cd25e5910...@apnic.net>
>
> I have no idea whether the allocation requested is r
On 28/11/2012, at 5:00 AM, Barry Leiba wrote:
> On Tue, Nov 27, 2012 at 12:25 PM, Dale R. Worley wrote:
>>
>>> That attendance showed me that most of the IETF meeting was a
>>> waste of time, that it was e-mail that was the main vehicle for work,
>>> and I think that the IETF web site has it a
On 29/11/2012, at 2:36 AM, "George, Wes" wrote:
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
>> John Leslie
>>
>>I'm increasingly seeing a "paradigm" where the review happens
>> _before_ adoption as a WG draft. After adoption, there's a great lull
>> until the
On 29/11/2012, at 3:32 AM, Eliot Lear wrote:
>
> On 11/28/12 12:57 PM, Randy Bush wrote:
>>> I'm increasingly seeing a "paradigm" where the review happens _before_
>>> adoption as a WG draft.
>> and one consequence is that the design gets done outside of the ietf
>> process.
>>
>
> But this i
On 30/11/2012, at 7:55 AM, The IESG wrote:
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Special-Purpose Address Registries'
> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> fi
On 30/11/2012, at 8:14 AM, Randy Bush wrote:
>> I'll note that it seems possible that overspecifying process
>> could potentially cause more protests rather than fewer.
>
> or good folk just walking away. there is a reason we are at the ietf
> and not the itu. rule obsessed and process hidebo
On 30/11/2012, at 9:31 AM, Randy Bush wrote:
> hi geoff,
>
> i get your point. but it sure is convenient to find everything in one
> place. can your issues be addressed by adding an attribute(s) to the
> entries?
Convenience vs maning a semantic distinction overt.
Yes, it is possible to ad
your message:
>
> On 11/29/12 4:26 PM, Geoff Huston wrote:
>
>> I also disagree with the approach to publish the intended contents of this
>> special purpose registry as an RFC ans the registry itself is the intended
>> mode of authoritatively describing those resources
On 04/12/2012, at 9:30 AM, Ronald Bonica wrote:
> Geoff, Randy,
>
> Having reflected on your comments, I think that the two of you may be
> approaching the same problem from two directions. I will try my best to
> articulate the problem. When we agree that we have a common understanding of
>
> Please take a look and tell me if we have solved the problem.
>
> Ron
>
>
>> -Original Message-
>> From: Geoff Huston [mailto:g...@apnic.net]
>> Sent: Monday, December 03, 2012 6:25 PM
>> To: Ronald Bonica
>>
I'm in favor of the proposed action and the clarification of HISTORIC as
proposed in the new section.
Geoff
On 26/07/2011, at 12:30 AM, Ronald Bonica wrote:
> Folks,
>
> After some discussion, the IESG is attempting to determine whether there is
> IETF consensus to do the following:
>
> - a
On 21/03/2009, at 3:18 AM, Iljitsch van Beijnum wrote:
On 19 mrt 2009, at 7:43, Lixia Zhan"
Are we ready to adopt the policy that forbids IPv6 NAT traversal
mechanisms?
no.
This industry needs standards, and relies on standards.
For many years the Internet Engineering Task Force has v
lifetime of this number pool.
The second, http://www.potaroo.net/tools/asn32/ looks at the entirety
of the 32 bit AS number pool.
regards,
Geoff Huston
On 24/04/2009, at 1:13 AM, Russ Housley wrote:
I thought that the whole community would like to be aware of this
status.
Russ
From
On 24/08/2009, at 6:38 AM, Marshall Eubanks wrote:
On Aug 23, 2009, at 4:19 PM, Jari Arkko wrote:
Further discussion would be useful on one issue that was brought to
our attention.
The issue is the status of 128.66.0.0/16. This block, TEST-B, has
been used for example purposes. There is
On 29/08/2009, at 2:50 PM, Jari Arkko wrote:
I'd like to push back a little on this. My personal preference is a
specification style which makes everything very explicit. If a block
has been used for examples, I think we owe it to the reader to say
what its fate was. I do agree though tha
79 matches
Mail list logo
