Sorry I wasn't clear: what is the benefit of specifying the algorithm,
when simply popping out another PRF will in just about any instance do
the job (unless you are reinitializing the PRF with the same seed)?
There seems to be a disconnect here:
We want an algorithm that, roughly
And I would
observe that the DAD problem cannot be solved ina reliable way.
Could you please elaborate?
(Moving to the ipv6 mailing list, as this is way too detailed for the main IETF
list.)
The goal is to use the same address when repeatedly visiting the same network.
However, since we
On 04/23/2013 12:55 PM, Christian Huitema wrote:
And I would observe that the DAD problem cannot be solved ina
reliable way.
Could you please elaborate?
(Moving to the ipv6 mailing list, as this is way too detailed for the
main IETF list.)
The goal is to use the same address when
On 04/23/2013 01:37 PM, Fernando Gont wrote:
On 04/23/2013 12:55 PM, Christian Huitema wrote:
And I would observe that the DAD problem cannot be solved ina
reliable way.
Could you please elaborate?
(Moving to the ipv6 mailing list, as this is way too detailed for the
main IETF list.)
The
On 04/23/2013 11:41 AM, Christian Huitema wrote:
You might argue that, clearly, the autoconf prefix needs to be part
of the seed (I'd personally not expect developers to figure this
one out).
This is the kind of attitude that really does not go well with actual
developers. You are basically
If I'm the guy producing a spec, my goal is to produce a spec that is clear
as possible, and only leave open those bits that are necessary to leave open.
Well, that might work for internal specs when you are managing a project, but
that's probably not the right way to approach standards. A
On 04/23/2013 07:45 PM, Christian Huitema wrote:
If I'm the guy producing a spec, my goal is to produce a spec that
is clear as possible, and only leave open those bits that are
necessary to leave open.
Well, that might work for internal specs when you are managing a
project, but that's
RJ == RJ Atkinson rja.li...@gmail.com writes:
RJ I oppose Eliot's proposed edits on grounds that they would
RJ reduce the clarity of the specification and also would reduce
RJ IETF and WG consensus about this specification.
Ran, I just checked, and you don't seem to be a 6man
Sam Hartman wrote:
RJ Atkinson rja.li...@gmail.com writes:
RJ I oppose Eliot's proposed edits on grounds that they would
RJ reduce the clarity of the specification and also would reduce
RJ IETF and WG consensus about this specification.
Ran, I just checked, and you don't
Hi, Eliot,
On 04/22/2013 01:20 AM, Eliot Lear wrote:
In the process of doing the apps area review, I came across some points
that were not related to applications. The basis for these comments is
precisely the sentiment that Russ Housley expressed, which is that the
specification is done
Hi Fernando,
Thanks very much for your response.
On 4/22/13 6:06 PM, Fernando Gont wrote:
Hi, Eliot,
On 04/22/2013 01:20 AM, Eliot Lear wrote:
In the process of doing the apps area review, I came across some points
that were not related to applications. The basis for these comments is
At 09:56 AM 4/22/2013, Sam Hartman wrote:
RJ == RJ Atkinson rja.li...@gmail.com writes:
RJ I oppose Eliot's proposed edits on grounds that they would
RJ reduce the clarity of the specification and also would reduce
RJ IETF and WG consensus about this specification.
Ran, I just
Eliot,
am Mon, Apr 22, 2013 at 06:22:24PM +0200 hast du folgendes geschrieben:
I asked the above question because it is at least conceivable that at
some point host portion != 64 bits and this is the only place in the
document where the requirement is stated. Yes, screwing with the 64
bit
Hi, Eliot,
On 04/22/2013 11:22 AM, Eliot Lear wrote:
With this
document, I wonder if quite a bit could be removed.
Specifically, a great deal of discussion goes into the PRF involving DAD
counters, etc, when all that is needed is a suitable PRF.
Not sure what you mean...What's thetext that
Hi,
snip
I'm not thinking of today but the future. And yes, another
argument would be that there isn't enough address space for this to be
effectively private. Those are two different issues, but fixing the
boundary here reminds me of mistakes we made with IPv4 way back when.
In
H Fernando,
On 4/22/13 9:23 PM, Fernando Gont wrote:
There seems to be a disconnect here:
We want an algorithm that, roughly speaking, whenever you connect to the
same network, gives you the same address. But such address should be
different for each network you connect to.
Thank you, and
16 matches
Mail list logo
