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
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
i
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 despe
Alain Durand <[EMAIL PROTECTED]> wrote:
|On Feb 8, 2004, at 3:02 PM, Dan Lanciani wrote:
|>
|> In the past we were unable to come up with a value for ``long enough''
|> which
|> is in any meaningful way different from ``forever.''
|
|There is a simple business model to solve this problem:
|long e
Tim Chown wrote:
>With 1,000 billion entries, it might also become a large database...
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?
When thi
% > 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 ownership should be dist
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 pr
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, 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
On Feb 8, 2004, at 3:02 PM, Dan Lanciani wrote:
In the past we were unable to come up with a value for ``long enough''
which
is in any meaningful way different from ``forever.''
There is a simple business model to solve this problem:
long enough == as long as you pay for it.
This is the same as an
On Feb 7, 2004, at 5:45 AM, Bill Manning wrote:
% 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 or
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 disappe
% 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
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' addre
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 prett
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
fundamentall
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
t
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 monetary
Christian,
At 10:07 PM 2/5/2004, Christian Huitema wrote:
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
Christian,
At 10:11 PM 2/5/2004, Christian Huitema wrote:
> 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 ag
Erik,
At 05:41 PM 2/5/2004, Erik Nordmark wrote:
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??
Reasonable point. I
On Wed, 4 Feb 2004, Bob Hinden wrote:
> > > I agree this could be stated better. I think it would be good to
> > > change it to "Any router that is used between sites", as it is
> > > not the routing protocols doing the filtering, but the router based
> > > on it's configuration.
> >
> >But th
> 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 na
>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??
Erik
> >For future study names with Local IPv6 addresses may b
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.,
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 i
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 bad
> 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 mone
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
> > eno
Pekka,
As I am packing for a 3.5 week trip, I don't have time to go into full
detail. I mostly disagree with you on the big points (your smaller
points are fine), but these are not new arguments anyway.
> 1) specifying just one allocator to the end-sites; this is always bad
> and prone to create
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.tx
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 w
>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 we MUST assign the
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
I had raised a number of issues with pervious versions of this draft, and
subsequently I've worked with the draft's authors on this.
I'd like to provide the WG with the comment that this draft resolves the
issues I've raised and
I support it moving forward.
thanks,
Geoff
At 08:22 AM 27/01/200
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 th
37 matches
Mail list logo
