(1) This draft is aimed at being an Informational RFC is the appropriate type because
it provides clarifying information and suggested behaviors to address issues
experienced in existing implementations.
(2) IESG Approval Announcement
Technical Summary:
This document sets forth recommendations intended to improve CPE default behavior on IPv6 networks.
Specifically, it aims to clarify certain timer interactions on dynamic prefixes and improve behavior
in scenarios where network configuration information becomes invalid without explicit signaling
of that condition.
Document Quality:
The document so far has been approved by the V6OPS working group (successful working group
last call). The document does not specify new protocol, but rather changes to the default parameters
in existing protocols.
Personnel
Owen DeLong is the Document Shepherd
Fred Baker and Ron Bonica are the WG chairs
Warren Kumari is the responsible AD.
(3) Shepherd’s review
Prior to becoming shepherd, I was significantly involved in reviewing each revision of the document
and provided feedback and contributed improvements at each step. I have been active in the
debate of this I-D on the working group mailing list. This version of the document is ready for
publication. While there remains one dissenter in the working group, the working group has
reached consensus. His concerns are a particular corner case where DHCPv6 is being used to
distribute effectively static addresses.
(4) Shepherd’s concerns
I have no concerns about the depth or breadth of the reviews that have been performed.
Through the three revisions, the document has received substantial comments from the working
group and significantly improved with each revision as a result. Author has been very responsive
and incorporated feedback very well.
(5) Special Reviews Needed
I do not believe any special reviews are necessary for this document. The HOMENET
working group may wish to review this document as the proposed change in default behavior
could affect their work, but we believe the proposals here would be beneficial in such an
environment.
(6) Shepherd’s Concerns or issues
I have no concerns or issues with the document in its current form.
(7) IPR disclosures
There are no relevant IPR disclosures in this document. The document does not touch on
any technologies other than those in existing RFCs developed within the IETF.
(8) IPRs referencing this document
No IPR disclosures have been filed referencing this document and for the reasons stated in the
previous section, it is very unlikely one would be filed.
(9) WG consensus strength
This document had good participation and discussion in the working group and received fairly
broad support both prior to and during WG last call.
(10) Dissent
There remains one dissenter, but I would not characterize his discontent as extreme, nor has
he threatened appeal. His concern relates to a corner case where DHCP is being used by an
ISP to distribute (through DHCPv6-PD) a static prefix address which does not change. He is
concerned that the proposed default behavior here could either increase his configuration
complexity or result in an unnecessary local outage in the event that he loses connectivity
to his service provider. Multiple alternative solutions were suggested to him on the mailing
list. Since this document specifies only default behavior and does not preclude vendors
from providing knobs to alter that behavior, I believe his objection was more than adequately
addressed.
(11) ID nits
No nits found (once I got past the fact that the NITS interface via URL doesn’t cope well
with this draft for reasons beyond me). Feeding it the raw text worked fine.