> On Thu, 28 Apr 2005 12:37:39 +0300,
> Jari Arkko <[EMAIL PROTECTED]> said:
>> Does this simple answer address your question? If not, please explain
>> the point (that I could not understand). If it does, do you want to
>> update the draft regarding this issue? E.g., do you want to em
> On Thu, 28 Apr 2005 09:40:44 -0400,
> Russ Housley <[EMAIL PROTECTED]> said:
> Looks good to me.
Okay, thanks. Since some others also agreed with this approach (and
there has been no objection), I'll soon close this issue with the
proposed resolution.
> Comment from Russ Housley:
>
> I suggest adding another event to section 5.3. Consider an event
> that indicates that the physical network connectivity may have
> changed. Such events include a carrier down/carrier sequence on
> an Ethernet NIC, a change of SSID on an 802.11 network, o
> Comment from Russ Housley:
>
> I suggest adding another event to section 5.3. Consider an event
> that indicates that the physical network connectivity may have
> changed. Such events include a carrier down/carrier sequence on
> an Ethernet NIC, a change of SSID on an 802.11 network, o
There has been no comment on this issue. I'll simply close it without
taking any action on the document (as proposed below).
> In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
>
> > There is a lot of normative dependency on the recycling DS of
> > Neighbory Discovery which
There has been no comment on this issue. I'll simply close it without
taking any action on the document (as proposed below).
> In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
>
> > There is a lot of normative dependency on the recycling DS of
> > Neighbory Discovery which
There has been no comment on this issue. I'll simply close it without
taking any action on the document (as proposed below).
> In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
>
> > There is a lot of normative dependency on the recycling DS of
> > Neighbory Discovery which
There has been no comment on this issue. I'll simply close it without
taking any action on the document (as proposed below).
> In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
>
> > There is a lot of normative dependency on the recycling DS of
> > Neighbory Discovery which
> On Thu, 28 Apr 2005 09:43:35 -0400,
> Russ Housley <[EMAIL PROTECTED]> said:
> Looks okay to me, with one change:
> s/accept point/access point/
Ah, yes, of course. Thanks!
JINMEI, Tatuya
Communicatio
Brian Haberman wrote:
It may be close to the border, but I don't think it crosses it. The
reader does not have to understand SEND in order to implement
or understand this specification.
However, if we determine that a normative reference is needed, we
can pursue a variance on the down-ref issue.
All,
Based on the list discussion and comments received privately,
the chairs see a strong consensus forming on the centrally-
allocated ULA document. At this time, we will not continue work
on this draft. We will monitor the use and issues raised with the
locally-assigned ULAs. If issues w
Peter,
On Apr 28, 2005, at 7:16, Grubmair Peter wrote:
Ideas something like this have been proposed several times. I don't
remember the conclusion of the discussion on each one of them, but, in
any event, this is clearly beyond the scope of rfc2462bis.
OK,
Another suggestion.
Instead of turning of
On Apr 28, 2005, at 5:37, Jari Arkko wrote:
JINMEI Tatuya wrote:
1. change the references to RFC2402 (IPsec-AH) to references to
RFC3971(SEND), and
This is the right thing to do.
I agree as well.
2. categorize the new reference as informative
Ok, but a bit bordline case, perhaps. Is this the
onl
Looks okay to me, with one change:
s/accept point/access point/
Russ
At 04:21 AM 4/28/2005, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
Hello,
In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
> I suggest adding another event to section 5.3. Consider an ev
Jim,
Thanks for the heads-up.
Please ensure that any BOF you hold does not conflict with either the MPLS
or CCAMP working group meetins. I predict that many people will wish to
attend all three meetings.
After a preliminary reading of draft-chakravorty-6lsa-01.txt it seems to
me that what you ar
Looks good to me.
Russ
At 04:10 AM 4/28/2005, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
Hello,
In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
> RFC 3756 says that IPsec really does not work for neighbor
> discovery. Even if it does work in some cases,
> Ideas something like this have been proposed several times. I don't
> remember the conclusion of the discussion on each one of them, but, in
> any event, this is clearly beyond the scope of rfc2462bis.
OK,
Another suggestion.
Instead of turning off loop-back supression of WLAN,
Another solutio
> On Thu, 28 Apr 2005 12:37:44 +0300,
> Jari Arkko <[EMAIL PROTECTED]> said:
>> 2. categorize the new reference as informative
>>
> Ok, but a bit bordline case, perhaps. Is this the
> only way to have a reference to SEND and advance/keep
> the current 2462 standard level?
Do you have an
JINMEI Tatuya wrote:
Was there an analysis of the configuration consistency rule
(section 5.6) of accepting the most recent information, while
trying to secure both DHCPv6 and ND/addrconf (SEND)?
As far as I know, there was no such analysis. But honestly speaking,
I don't understand the poin
JINMEI Tatuya wrote:
1. change the references to RFC2402 (IPsec-AH) to references to
RFC3971(SEND), and
This is the right thing to do.
2. categorize the new reference as informative
Ok, but a bit bordline case, perhaps. Is this the
only way to have a reference to SEND and advance/keep
the c
> On Thu, 28 Apr 2005 10:50:23 +0200,
> Grubmair Peter <[EMAIL PROTECTED]> said:
> On page 25 of 2662bis 07 draft the difficulties for loopback and dad
> are explainded.
> Maybe dedection of loopbacks (of NS) could be supported by adding
> a new option either as NS option or as destinatio
On page 25 of
2662bis 07 draft the difficulties for loopback and dad
are
explainded.
Maybe dedection of
loopbacks (of NS) could be supported by adding
a new option either
as NS option or as destination header option.
This option should
carry a random identifier of sufficient len
Hello,
In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
> I suggest adding another event to section 5.3. Consider an event
> that indicates that the physical network connectivity may have
> changed. Such events include a carrier down/carrier sequence on
> an Ethernet NIC, a
Hello,
In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
> RFC 3756 says that IPsec really does not work for neighbor
> discovery. Even if it does work in some cases, there is not
> enough detail in this document to say how to use it. SEND
> is the answer, of course. Ho
Hello,
In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
> Was there an analysis of the configuration consistency rule
> (section 5.6) of accepting the most recent information, while
> trying to secure both DHCPv6 and ND/addrconf (SEND)?
As far as I know, there was no such an
25 matches
Mail list logo
