Peter, Tatuya
(B
(BThanks for catching that.
(B
(BComments below
(B
(B > > On page 59, 7.2.5 is written:
(B > ->
(B > > If the Neighbor Cache entry is not in INCOMPLETE state,
(B > the receiving
(B > >node performs the following steps:
(B >
(B > > - It records the link-layer
Ran Liebermann wrote:
> On 25/04/05, Brian E Carpenter wrote:
> > Until 6LSA explains how it will restore the label to its
> > original value, or the IETF changes its mind about immutability
> > of the label, this just isn't going to happen. I think that's
> > why the 6LSA people wrote their recent
On Tue, 26 Apr 2005, Ralph Droms wrote:
I can think of several possible resolutions:
1. just say that it's host/network administrator's responsibility to
provide consistent parameters/configurations. In this sense, the
combination of a) and b) above is just a configuration error.
This would
Comments in line...
On Fri, 2005-04-22 at 16:30 +0300, Pekka Savola wrote:
> On Fri, 22 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] ÂÂÂÃ wrote:
> [...]
> > then the host will try the "Host Configuration Behaviour"
> > (Solicit/Advertise/Request/Reply exchanges), but the server does not
> > resp
Forwarded to include dhc WG in conversation about M/O flags.
- Ralph
Forwarded Message
> From: JINMEI Tatuya / çæéå <[EMAIL PROTECTED]>
> To: Pekka Savola <[EMAIL PROTECTED]>
> Cc: IPv6 WG
> Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt
> Date: Tue, 26 Apr 2
Hello,
As far as I know there has been no response at the list on this subject:
http://www.ietf.org/mail-archive/web/ipv6/current/msg04465.html
so I'm going to give it a second try, based on the relevant discussion
at the Minneapolis meeting.
According to the (draft) minutes of the meeting
(ht
> On Fri, 25 Mar 2005 11:18:52 +0100,
> Grubmair Peter <[EMAIL PROTECTED]> said:
> On page 59, 7.2.5 is written:
->
> If the Neighbor Cache entry is not in INCOMPLETE state, the receiving
>node performs the following steps:
> - It records the link-layer address in the Neighbor C
> On Fri, 22 Apr 2005 16:30:02 +0300 (EEST),
> Pekka Savola <[EMAIL PROTECTED]> said:
>> 2. allow a host to fall-back to Information Configuration Behaviour in
>> such a case. This is not 100% compliant with the DHCPv6
>> specification, though.
>>
>> 3. make small updates on the DHCPv6
