IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods
RFC 6879

Note: This ballot was opened for revision 04 and is now closed.

(Ron Bonica) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-01-09 for -05)
No email
send info
For the record, let me cut and paste it here what has been discussed with the authors.
From the charter, I believe that this document fits the following:

   1. To undertake scenario descriptions, including documentation of
   current capability inventories and existing BCPs, for enterprise
   networks, including managed and unmanaged elements. These texts should
   contribute towards a gap analysis and provide an agreed basis for
   subsequent WG rechartering towards development of solutions (which may
   be more appropriate for other WGs to undertake) and improved practices.
   Operator input will be of high value for this text.

Reading this reading, I asked myself: what is the specific scope of this
document? I see a mix of scenarios, listing of the existing solutions,
best current practices (corrected btw in the version 5), etc... and 
I'm wondering where this document
fits in all the IPv6 documents renumbering documents: RFC 5887, this
document, Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-01, rfc4192, etc...
By "etc", I mean searching for "renum" in
It seems that many of these documents have the same type of content. Too
many actually. Don't get me wrong, there is good text in this document.

Bottom line: if someone is interested in renumbering, what is the
ordered list of documents to be read, with the respective content. My
conclusion is that there will be a lot of overlap. I would happy to
stand corrected.

Note: I did my home work trying to find the answer: read RFC 5887,
      listened to the IETF 85 meeting recording, etc...

Answer from Brian Carpenter

    This is a tricky point. RFC 5887 could probably never have been developed
    by a WG - in fact it was a non-IAB revisit of an IAB document (RFC 1900).
    And it succeeded, because 6renum was chartered. But 6renum was not
    chartered to design solutions or even to write a cookbook. I believe
    that the nature of the present draft is only to describe the situation
    and the existing tools.

    At some point the IESG will be given draft-ietf-6renum-gap-analysis
    which "briefly introduces the existing mechanisms that could
    be utilized for IPv6 site renumbering and tries to cover most of the
    explicit issues and requirements of IPv6 renumbering. Through the gap
    analysis, the document provides a basis for future works..."

    I think that the whole picture will be clearer then - and the IESG
    will hopefully decide which of the gaps require IETF action.

    draft-carpenter-6renum-next-steps-00 may also help to answer
    your question.

While the draft improves from version 4 to 5, for example by removing the BCP, I'm not totally convinced by the usefulness of this yet-another document. However, I won't get in the way of its publication. Specifically because my concern is not really actionable at this point in time.

Dynamic Host configuration Protocol -> Dynamic Host Configuration Protocol

(Ralph Droms) No Objection

Comment (2013-01-09 for -05)
No email
send info
Minor suggestion: the "Information Refresh Time Option"
(RFC 4242) is useful for managing the lifetime of
configuration information provided through DHCPv6 when
a host has no leased addresses (section 4.2).

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-01-08 for -05)
No email
send info
Just wondering - would use of e.g. amazon EC2 or equivalent
might be relevant for any of this, e.g. if the service
provider for such a thing used IPv6 addresses for access
controls or something.  Maybe that's theoretical for now
though or you don't consider that part of an enterprise
network, either of which seem reasonable.

(Brian Haberman) No Objection

Comment (2013-01-04 for -05)
No email
send info
I have no objection to the publication of this document, but I do have a question (that is not DISCUSS worthy).

The primary focus of this document appears to be the actual address configuration issues surrounding a renumbering event.  While DNS, ACLs, and firewall rules are briefly mentioned, I am curious as to the lack of mention, in any detail, of text-based configuration files.  Was that aspect considered?

(Russ Housley) No Objection

Barry Leiba No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) (was Discuss) No Objection

(Sean Turner) No Objection

Comment (2013-01-08 for -05)
No email
send info
s2: r/[RFC4057] is a/[RFC4057] as a