Discuss comment from Allison Mankin:
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)?
We seem to reach a consensus on this issue through a discussion at
Discuss comment from Allison Mankin:
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)?
We seem to reach a consensus on this issue through a discussion at
We seem to reach a consensus on this issue with the following
resolution:
Change the references to IPsec Authentication Header to
references to SEND [RFC3971], and categorize the new reference as
informative.
For relevant discussion at the wg list, see the list thread starting
We seem to reach a consensus on this issue with the following
resolution:
Change the references to IPsec Authentication Header to
references to SEND [RFC3971], and categorize the new reference as
informative.
For relevant discussion at the wg list, see the list thread starting
We seem to reach a consensus on this issue with the following
resolution:
Change the references to IPsec Authentication Header to
references to SEND [RFC3971], and categorize the new reference as
informative.
For relevant discussion at the wg list, see the list thread starting
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 not
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 not
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 not
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 not
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, or
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, or
[EMAIL PROTECTED] - Thu Sep 02 11:59:56 2004]:
Based on a discussion in the list, this issue will be closed
with a slightly different resolution:
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
[EMAIL PROTECTED] - Fri Aug 20 15:21:14 2004]:
Proposed Resolution:
- add a reference to RFC3810 as well as to RFC2710
- make a small modification to the 5th paragraph of section 5.4.2 to:
(snip)
See the following link and its follow-ups for more details:
[EMAIL PROTECTED] - Fri Aug 20 15:21:14 2004]:
Proposed Resolution:
- add a reference to RFC3810 as well as to RFC2710
- make a small modification to the 5th paragraph of section 5.4.2 to:
(snip)
See the following link and its follow-ups for more details:
[EMAIL PROTECTED] - Fri Aug 20 15:11:28 2004]:
Proposed resolution:
- replace multicast interface with multicast-capable interface in
Section 5.1
- modify the definition of link in Section 2 a little bit like:
link - a communication facility or medium over which nodes can
[EMAIL PROTECTED] - Fri Aug 20 15:07:04 2004]:
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an
[EMAIL PROTECTED] - Fri Aug 20 15:07:04 2004]:
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an
[EMAIL PROTECTED] - Fri Aug 20 15:07:04 2004]:
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an objection, please speak up ASAP.
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an objection, please speak up ASAP.
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an objection, please speak up ASAP.
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an objection, please speak up ASAP.
Proposed resolution:
- replace multicast interface with multicast-capable interface in
Section 5.1
- modify the definition of link in Section 2 a little bit like:
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately
Proposed resolution:
- replace multicast interface with multicast-capable interface in
Section 5.1
- modify the definition of link in Section 2 a little bit like:
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately
Proposed resolution:
- replace multicast interface with multicast-capable interface in
Section 5.1
- modify the definition of link in Section 2 a little bit like:
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately
Proposed Resolution:
- add a reference to RFC3810 as well as to RFC2710
- make a small modification to the 5th paragraph of section 5.4.2 to:
Note that when a node joins a multicast address, it typically sends
a Multicast Listener Discovery (MLD) report message [RFC2710] for
the
There appears to be nothing we can do for this. Also, the
issue is well-known, has been well described in the past RFCs,
and has been dealt with anyway, so this is not an issue that
can prevent the document from moving forward.
This issue is therefore rejected.
There appears to be nothing we can do for this. Also, the
issue is well-known, has been well described in the past RFCs,
and has been dealt with anyway, so this is not an issue that
can prevent the document from moving forward.
This issue is therefore rejected.
A resolution was proposed along with the one for issue 275.
There has been no objection to the resolution, so I'm going
to close this issue. The resolution will appear in the next
revision of the draft.
IETF IPv6 working
[EMAIL PROTECTED] - Mon Feb 09 06:37:31 2004]:
Proposed Resolution (revised): revise the latter part of
Section 5.4.2 as follows:
The proposed change was incorporated in the latest draft (00),
and I've not seen any objections to it. I now conclude
everyone is fine with the resolution and
No opinions, so I'll adopt the resolution of do nothing as
I proposed on the list, and close this issue.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
No opinions, so I'll adopt the resolution of do nothing as
I proposed on the list, and close this issue.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
Proposed Resolution: revise section 5.7 as follows.
5.7 Retaining Configured Addresses for Stability
An implementation that has stable storage may want to retain
addresses in the storage when the addresses were acquired using
stateless address autoconfiguration. Assuming the lifetimes
Proposed Resolution: revise section 5.7 as follows.
5.7 Retaining Configured Addresses for Stability
An implementation that has stable storage may want to retain
addresses in the storage when the addresses were acquired using
stateless address autoconfiguration. Assuming the lifetimes
This is an editorial fix, and was approved by
Pekka Savola who originally raised the issue.
This issue is now closed.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
An editorial fix.
This issue is now closed.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
No objection to the proposed resolution, so
the issue is closed. Please revisit the issue
if you have a different opinion.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
No objection to the proposed resolution, so
the issue is closed. Please revisit the issue
if you have a different opinion.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
No objection to the proposed resolution, and the
issue is closed. Please revisit the issue if you
have a different opinion.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
No objection to the proposed resolution, and the
issue is closed. Please revisit the issue if you
have a different opinion.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
No objection to the resolution (which is just
a result of a previous ML discussion we already
agreed). This issue is now closed.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
No objection to the proposed resolution and at least one person agreed
on the resolution in ML. The issue is now closed. If you have a
different opinion, please revisit the issue.
IETF IPv6 working group mailing list
[EMAIL
No objection to the proposed resolution and at least one person agreed
on the resolution in ML. The issue is now closed. If you have a
different opinion, please revisit the issue.
IETF IPv6 working group mailing list
[EMAIL
This is almost an editorial fix, and the change
was included in the latest I-D.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Proposed Resolution: do nothing for this.
Reason: this is actually a non issue (see the previous comment
on the trucker).
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
45 matches
Mail list logo
