Hello, Teemu.
My comments are below.
2008/10/23 <[EMAIL PROTECTED]>:
> Hi,
>
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>>Behalf Of ext Ted Lemon
>>Sent: 16 October, 2008 20:49
>>To: Iljitsch van Beijnum
>>Cc: David W. Hankins; [EMAIL PROTECTED]; List Mail
Hello, Teemu.
A few comments are added below.
2008/10/23 <[EMAIL PROTECTED]>:
> Hi,
>
> Used link-layer does have an impact: on cellular networks the link-layer is
> nowadays most often opened on-demand (i.e. when an application starts), or
> quickly reopened e.g. if network connection is temp
Hello, David.
A few comments are inserted.
2008/10/23 David W. Hankins <[EMAIL PROTECTED]>:
> Just a few things that I think are potential factual errors or
> misreads that need clarifying.
>
> On Tue, Oct 14, 2008 at 09:48:42AM +0200, Iljitsch van Beijnum wrote:
>> It's not a question of "problem
Hello, Tony.
Thank you for your agreement and interests in the issues being
addressed by the draft "draft-cha-ipv6-ra-mo-00.txt".
Since I feel that we need to discuss how to solve the issues more, I
would like to insert my comments as below.
2008/10/24 Tony Hain <[EMAIL PROTECTED]>:
> I agree wi
> As for dealing with conflicting M&O, just XOR the received set.
Before the world erupts over trivia, that should have said OR
I clearly need more sleep,
Tony
IETF IPv6 working group mailing list
ipv6@ietf.org
Administr
I agree with Joseph that these should be combined and published.
As for dealing with conflicting M&O, just XOR the received set. When the
state changes from 1 to 0 (actually in either direction), after a random
delay re-query DHCP to verify the lease time/config information. In a
managed configur
Replying to your change of subject, not (necessarily) the message
itself:
At the last IETF meeting, I captured a bunch of wireless traffic
during the plenary with the idea to analyze the broadcasts to see how
much airtime they take up. Unfortunately, I didn't get around to it
and deleted
On 17 okt 2008, at 22:54, Bernie Volz (volz) wrote:
In my view, I believe encouraging implementers to use the M & O bits
is
a good thing (the RFC 2462 "should") but a client's local policy
should
be able to override that (always on, never on, or "use M&O" if
possible).
Fully agree. However
On 16 okt 2008, at 19:48, Ted Lemon wrote:
The whole notion that we need
to specify a binary format for every new piece of data that may need
to be configured and then wait until both clients and servers are
updated is completely outdated.
Updating an XML schema every time you get a new option
Hi,
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>Behalf Of ext Ted Lemon
>Sent: 16 October, 2008 20:49
>To: Iljitsch van Beijnum
>Cc: David W. Hankins; [EMAIL PROTECTED]; List Mailing; DHC WG
>Subject: Re: [dhcwg] Brokenness of specs w.r.t. client
>behavior
Hi,
Used link-layer does have an impact: on cellular networks the link-layer is
nowadays most often opened on-demand (i.e. when an application starts), or
quickly reopened e.g. if network connection is temporarily lost for any reason.
In the future always-on connectivity becomes more commonplac
Just a few things that I think are potential factual errors or
misreads that need clarifying.
On Tue, Oct 14, 2008 at 09:48:42AM +0200, Iljitsch van Beijnum wrote:
> It's not a question of "problematic yes/no". More multicasts means less
> performance for other stuff. Obviously ARP and ND already
On Fri, Oct 17, 2008 at 05:31:54PM -0700, JINMEI Tatuya / 神明達哉 wrote:
> In this case, the DHCPv6 server (or a relay, which would also rely on
> a router and wouldn't work in this situation anyway) can send out an
> RA with the router lifetime being 0 and with a prefix information
> option. The ser
Hi Fred,
How do you see RANGER fitting into the requirements for carriers to supply
IP support (v4/v6) to mobile devices? Especially requirements that are
similar to the enterprise ones that you describe?
Eric
Templin, Fred L writes:
This message is to introduce a new Internet-Draft title
14 matches
Mail list logo
