solved the problem.
Ron
-Original Message-
From: Geoff Huston [mailto:g...@apnic.net]
Sent: Monday, December 03, 2012 6:25 PM
To: Ronald Bonica
Cc: Randy Bush; IETF Discussion
Subject: Re: Last Call: draft-bonica-special-purpose-03.txt (Special
On 04/12/2012, at 9:30 AM, Ronald Bonica rbon...@juniper.net 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
On 30/11/2012, at 7:55 AM, The IESG iesg-secret...@ietf.org wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Special-Purpose Address Registries'
draft-bonica-special-purpose-03.txt as Best Current Practice
The IESG plans to make
On 30/11/2012, at 8:14 AM, Randy Bush ra...@psg.com 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
On 30/11/2012, at 9:31 AM, Randy Bush ra...@psg.com 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
On 29/11/2012, at 2:36 AM, George, Wes wesley.geo...@twcable.com 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
On 29/11/2012, at 3:32 AM, Eliot Lear l...@cisco.com 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
On 28/11/2012, at 5:00 AM, Barry Leiba barryle...@computer.org wrote:
On Tue, Nov 27, 2012 at 12:25 PM, Dale R. Worley wor...@ariadne.com 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
, at 6:09 AM, Robert Elz k...@munnari.oz.au wrote:
Date:Wed, 21 Nov 2012 17:16:58 +1100
From:Geoff Huston g...@apnic.net
Message-ID: 99b9866c-41d6-4784-aa69-cd25e5910...@apnic.net
I have no idea whether the allocation requested is reasonable or not,
I haven't read
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
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
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 IANA
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:
- add a
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
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
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 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
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
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
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
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 list
Ietf@ietf.org
https://www1.ietf.org/mailman
- 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.
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
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
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
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
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
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
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,
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 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
believe, a central matter in any version of an
RFC Editor Charter.
regards,
Geoff
At 02:00 AM 31/05/2006, Brian E Carpenter wrote:
Look at draft-ietf-newtrk-docid-00.txt
This isn't really a chartering issue, IMHO.
Brian
Stewart Bryant wrote:
Robert Sayre wrote:
On 5/26/06, Geoff
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
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
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
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
charter. 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
-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 appears to be a factual error here.
regards,
Geoff Huston
(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.
snip
Comments welcome.
Well, I have only one comment. This is great!
A
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.
You mean something like http://draft
* 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
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: Update: IETF Trust Consensus Call
Date: Wed
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 these
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
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
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
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
to the 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
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 held
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
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 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:
-
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
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 reviewed by
:[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 that being a non-voting member is being a
second
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
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
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
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
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
Baker 2002 - 2005
Margaret Wasserman 2003 - 2006
(*) Current term expires May 2004
Thanks,
Geoff Huston
Executive Director, IAB
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
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
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
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
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
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
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 you point out below, NAT's may have
caused people to use
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 about 1
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
72 matches
Mail list logo
