Sure, this is fine with me. Will add it to the next rev.
(B
(BHesham
(B
(B > -Original Message-
(B > From: [EMAIL PROTECTED]
(B > [mailto:[EMAIL PROTECTED]
(B > Sent: Wednesday, April 27, 2005 4:21 AM
(B > To: Soliman, Hesham
(B > Cc: ipv6@ietf.org
(B > Subject: Forward: Re: IPv6
Hello,
I've noticed that the latter of Section 7.2.5 of 2461bis was improved
very much in the 02 version:
===
If the target's Neighbor Cache entry is in any state other than
INCOMPLETE when the advertisement is received, th
On Tue, 15 Feb 2005, Erik Nordmark wrote:
So I'd suggest adding a sentence at the start of the second paragraph:
This specification has no explicit support for hosts to perform
inbound load balancing.
and rewording the rest to start with
Routers can perform inbound load bala
Pekka Savola wrote:
Inbound load balancing - Nodes with replicated interfaces may want
to load balance the reception of incoming packets across
multiple network interfaces on the same link. Such nodes
have multiple link-layer addresses assigned to the same
On Tue, 15 Feb 2005, Soliman, Hesham wrote:
> This does not solve my wording issue. The paragraph just describes
> how _routers_ perform inbound load balancing. How about hosts which
> don't send RAs?
=> What do you suggest?
The paragraph now reads:
Inbound load balancing - Nodes with replic
> On Thu, 10 Feb 2005, Soliman, Hesham wrote:
> [lifetimes which decrement in real time]
> > > > > ==> AFAIK, the first option has not been implemented; I've
> > > > > at least not seen
> > > > > in done. Therefore unless someone shows that there are two
> > > > > implementations
> > > > >
On Thu, 10 Feb 2005, Soliman, Hesham wrote:
[lifetimes which decrement in real time]
> > > ==> AFAIK, the first option has not been implemented; I've
> > > at least not seen
> > > in done. Therefore unless someone shows that there are two
> > > implementations
> > > of this, this must be removed.
[mailto:[EMAIL PROTECTED]
(B > Sent: Friday, February 11, 2005 3:11 PM
(B > To: Erik Nordmark
(B > Cc: Pekka Savola; Soliman, Hesham; IPv6 WG
(B > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt
(B >
(B >
(B > Catching up a possibly minor point of an old thr
[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "IPv6 WG" ; "Pekka Savola"
<[EMAIL PROTECTED]>
Sent: Saturday, February 12, 2005 1:40 AM
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt
> Catching up a possibly minor point of an old thread...
>
Catching up a possibly minor point of an old thread...
> On Thu, 13 Jan 2005 10:39:15 -0800 (PST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> ==> AFAICS, you can remove 'both the Override flag is clear and' here,
>> because the same result happens if the Override flag is set.
> No. Th
Pekka, all,
Sorry for the delay in resolving this but there were too many comments
and too little time! Seems like most of your comments were clearly addressed
by me or other people on the list and most are being put in the next rev
(thanks).
But I'm going to address the unresolved ones so far.
Jinmei,
On Thu, 2005-01-13 at 21:48, JINMEI Tatuya / çæéå wrote:
>
> BTW: do we really need this level of detailed inspection to meet the
> two-implementation requirement for a DS? When I raised a similar
> question when we discussed how we should deal with the M/O flags in
> rfc2462bis wrt thi
Hi Jinmei,
(B
(B> BTW: do we really need this level of detailed inspection to meet the
(B> two-implementation requirement for a DS? When I raised a similar
(B> question when we discussed how we should deal with the M/O flags in
(B> rfc2462bis wrt this requirement, I was told that we usually o
On Fri, 14 Jan 2005, JINMEI Tatuya / [ISO-2022-JP] ¿ÀÌÀãºÈ wrote:
BTW: do we really need this level of detailed inspection to meet the
two-implementation requirement for a DS?
That is a matter of interpretation. Traditionally, the ADs have not
required them, but personally I think the spirit of
> On Thu, 13 Jan 2005 10:39:15 -0800 (PST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> - a time that decrements in real time,
>> that is, one that will result in a
>> Lifetime of zero at the specified
>> time in the future, or
>>
>> - a fixed time that stays the same in
>> consecutive
Hi Pekka,
On Thu, 13 Jan 2005, Pekka Savola wrote:
..
>That approach is correct, but beacause the "two hour rule" applies to
>the on-link prefixes, it's not "immediately".
Not really. This two hour minimum applies only to stateless autoconf.
Cheers
Suresh
-
Pekka Savola wrote:
It is an odd "SHOULD" in that it doesn't add a requirement on
implemetors of
ND, but instead states a requirement on some potential other protocol
which
uses proxy NAs.
But I do think that MIPv6 is an example of this. Even with multiple
Home Agents
on the same home link, MIPv
> >> ==> 'or the source chooses to ignore unauthenticated Redirect
> >> messages' smells quite a bit from a leftover of IPsec
> AH times. Reword?
> >
> > Can't SeND nodes choose to ignore redirects that aren't
> protected by SeND?
>
> Sure. I was just referring this editorially, t
> On Tue, 14 Dec 2004, Pekka Savola wrote:
> I went through one implementation and have a couple of additional
> comments wrt suitability for DS/clarify.
>
> 1) section 6.2.5: when AdvSendAdvertisements changes to FALSE, you
> SHOULD send a final RA with zero Router Lifetime.
>
> At least a cou
On Thu, 13 Jan 2005, Erik Nordmark wrote:
A proxy MAY multicast Neighbor Advertisements when its link-layer
address changes or when it is configured (by system management or
other mechanisms) to proxy for an address. If there are multiple
nodes that are providing proxy services for
[This got stuck in my outbox]
> - a time that decrements in real time,
> that is, one that will result in a
> Lifetime of zero at the specified
> time in the futur
On Dec 22, 2004, at 15:07, Pekka Savola wrote:
Inline..
On Sat, 18 Dec 2004, Soliman, Hesham wrote:
> substantial
> ---
>
> ==> this spec needs at least an IANA Considerations section,
> stating at
> least:
>1) the allocation guidelines for ND option types/codes
> (Standards Action?
> I
Inline..
On Sat, 18 Dec 2004, Soliman, Hesham wrote:
> substantial
> ---
>
> ==> this spec needs at least an IANA Considerations section,
> stating at
> least:
>1) the allocation guidelines for ND option types/codes
> (Standards Action?
> IETF Consensus?)
>2) that no IANA action is
Pekka,
Thanks for the comments.
My response inline. If I don't address a comment below, it means
I have no problem updating the draft with the comment.
Others please take a look and voice opinions if you have them.
We should try to make this LC have a deadline :)
> substantial
> ---
Pekka,
At 12:40 AM 12/15/2004, Pekka Savola wrote:
On Tue, 14 Dec 2004, Pekka Savola wrote:
In short, this still needs at least one revision. Jinmei also had some
O/M/DHCPv6 consistency issues which probably need to be addressed. There
is some specification which I don't think has been implemen
On Tue, 14 Dec 2004, Pekka Savola wrote:
In short, this still needs at least one revision. Jinmei also had some
O/M/DHCPv6 consistency issues which probably need to be addressed. There is
some specification which I don't think has been implemented and should be
removed unless anyone jumps up.
On Mon, 1 Nov 2004, Brian Haberman wrote:
This begins a 2 week IPv6 working group last call on recycling:
Title : Neighbor Discovery for IP version 6 (IPv6)
Author(s) : T. Narten, et al.
Filename: draft-ietf-ipv6-2461bis-01.txt
Pages : 8
> > at Draft Standard. Substantive comments should be directed to
> > the mailing list. Editorial comments can be sent to the document
> > editor. This last call will end on 11/15/2004.
>
> I've not gone through the entire document (it's so huge...), but I'd
> like to make some points at
Thanks for the comments.
(B
(B
(B > > at Draft Standard. Substantive comments should be directed to
(B > > the mailing list. Editorial comments can be sent to the document
(B > > editor. This last call will end on 11/15/2004.
(B >
(B > I've not gone through the entire document (it's so h
> On Mon, 1 Nov 2004 09:43:39 -0500,
> Brian Haberman <[EMAIL PROTECTED]> said:
> This begins a 2 week IPv6 working group last call on recycling:
> Title : Neighbor Discovery for IP version 6 (IPv6)
> Author(s) : T. Narten, et al.
> Filename
30 matches
Mail list logo
