Zefram [EMAIL PROTECTED] wrote:
|The allocation bitmap would be 128GiB. That fits onto one current
|commodity hard disk. Are we really quibbling over who's going to have
|to pay for eternal reliable storage of such a trifling dataset?
Not really. It's just folks grasping at straws in a
Dan Lanciani wrote:
As I recall, at one point someone set up a proof-of-concept auto-allocator
just to show how easy it was to hand out prefixes. It was shut down very
quickly. :( I'd like to know who ``requested'' this...
As I recall, it was claiming to actually allocate prefixes. I don't
Zefram [EMAIL PROTECTED] wrote:
|Dan Lanciani wrote:
|As I recall, at one point someone set up a proof-of-concept auto-allocator
|just to show how easy it was to hand out prefixes. It was shut down very
|quickly. :( I'd like to know who ``requested'' this...
|
|As I recall, it was claiming to
On Mon, Feb 09, 2004 at 08:27:04AM -0800, Alain Durand wrote:
Bill,
This is exactly what the local addr draft is all about with the current
text that makes
allocation permanent.
As a side note, the document talks about allocations, not delegations.
- Alain.
OK, but I think we
On Mon, Feb 09, 2004 at 09:16:49AM -0800, Alain Durand wrote:
Billing recurrent fees is a way to guaranty that the database will be
maintainable.
With 1,000 billion entries, it might also become a large database...
Tim
On Mon, 2004-02-09 at 12:22, Tim Chown wrote:
On Mon, Feb 09, 2004 at 09:16:49AM -0800, Alain Durand wrote:
Billing recurrent fees is a way to guaranty that the database will be
maintainable.
With 1,000 billion entries, it might also become a large database...
That's why proof of
Alain Durand [EMAIL PROTECTED] wrote:
|I think people are confusing the notion of 'permanent' and 'stable'
|addresses.
On the contrary, I think that it has not yet been demonstrated that they
are different for practical purposes. An address that has been around for
100 years but which
% One snag is that if they are temporary, it will inevitably lead to returns
% that don't happen, and the original and new owners both using the prefix,
% which will cause confusion/ambiguity/lack of uniqueness, which is thus breaking
% the original goal of the draft. There's enough under the /7
While doing those edits, why not also remove the dictate to give
permanent allocations from this document?
After all, this is also an operational/business discussion, not a
technical one.
- Alain.
On Feb 5, 2004, at 10:07 PM, Christian Huitema wrote:
From what I have read so far, the
I disagree; the technical issue is stability. We want these allocations to
be permanent to make them attractive in a technical analysis -- this
encourages their use in those cases where we believe they should be used
(as opposed to having users preferentially use self-assigned prefixes which
Alain Durand wrote:
While doing those edits, why not also remove the dictate to give
permanent allocations from this document?
After all, this is also an operational/business discussion, not a
technical one.
It looks pretty technical to me. Permanent versus temporary allocation
fundamentally
On Fri, Feb 06, 2004 at 08:05:17PM +, Zefram wrote:
Alain Durand wrote:
While doing those edits, why not also remove the dictate to give
permanent allocations from this document?
After all, this is also an operational/business discussion, not a
technical one.
It looks pretty
Trying to make a synthesized answer...
I think people are confusing the notion of 'permanent' and 'stable'
addresses.
The case made for those local addresses was to be independent from ISP,
either to isolate from ISP changes or in the case of intermittent
connection.
This require 'stable'
Is it only I that find it odd that talking about Multicast DNS
is viewed to be in-scope for this document, while talking about the
applicability issues for the addresses *defined by this document*
is stated to be out of scope??
Erik
For future study names with Local IPv6 addresses may be
From what I have read so far, the monetary payment appears to be one of
the weakest point of the proposal. I suggest that the monetary
consideration in the draft be removed, and that the precise method used
to implement the registration be left to the registry. Specifically, I
suggest in section
Is it only I that find it odd that talking about Multicast DNS
is viewed to be in-scope for this document, while talking about the
applicability issues for the addresses *defined by this document*
is stated to be out of scope??
I agree with Erik on this point.
For future study names
Pekka,
At 12:13 PM 2/3/2004, Pekka Savola wrote:
Inline..
likewise...
On Tue, 3 Feb 2004, Bob Hinden wrote:
The text in the IANA considerations section calls for the IANA to set up a
allocation authority for the centrally assigned ULA prefixes. The exact
details of how to do this (i.e., one
Pekka,
Thanks for the comments. I will respond to the substantial issues and
semi-editorial in your email. The editorial ones look fine and should be
to include them in the next version of the draft.
substantial
---
1) specifying just one allocator to the end-sites; this is always
Inline..
On Tue, 3 Feb 2004, Bob Hinden wrote:
The text in the IANA considerations section calls for the IANA to set up a
allocation authority for the centrally assigned ULA prefixes. The exact
details of how to do this (i.e., one or many organizations doing the
assignments, who it is,
On Mon, 26 Jan 2004, Brian Haberman wrote:
This is the start of an IPv6 working group last call on:
Title : Unique Local IPv6 Unicast Addresses
Author(s) : R. Hinden, B. Haberman
Filename: draft-ietf-ipv6-unique-local-addr-02.txt
On Mon, 2 Feb 2004, Brian E Carpenter wrote:
1) specifying just one allocator to the end-sites; this is always bad
and prone to create monsters such as ICANN.
7 That's unfair language. ICANN is not a monopolist.
It seems like that the model should be provided to support
enough
Well, I just feel quite uncertain of the current model -- we're
basically telling IANA to find someone to build a monopoly by selling
IP addresses. Not so different from what RIRs do, of course, but at
least they pretend the addresses don't cost anything. Here we WANT
them to cost money.
I think this is vitally necessary and ready to go to the IESG.
If proof be needed, I heard yesterday something that I found extraordinary
until I thought about it. It seems that major companies considering
selling a division are now routinely renumbering the entire division into
Net 10 prior to
Brian Haberman wrote:
All,
This is the start of an IPv6 working group last call on:
Title : Unique Local IPv6 Unicast Addresses
Author(s) : R. Hinden, B. Haberman
Filename: draft-ietf-ipv6-unique-local-addr-02.txt
Pages : 16
Christian Huitema wrote:
Locally assigned global IDs MUST be generated with a pseudo-random
algorithm consistent with [RANDOM].
I would have like to see some stronger wording to explain that, in the
self assigned case,
choosing FD00::/48 is a very bad idea.
The draft already says that
25 matches
Mail list logo
