Renumbering Still Needs Work
draft-carpenter-renum-needs-work-05

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Renumbering still needs work' to Informational RFC

The IESG has approved the following document:

- 'Renumbering still needs work '
   <draft-carpenter-renum-needs-work-05.txt> as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Dan Romascanu.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt

Ballot Text

Technical Summary

    This document reviews the existing mechanisms for site renumbering
    for both IPv4 and IPv6, and identifies operational issues with those
    mechanisms.  It also summarises current technical proposals for
    additional mechanisms.  Finally there is a gap analysis identifying
    possible areas for future work.

Working Group Summary

    This is an individual submission. Discussion took place in OPSAREA
    meetings and on the OPSAREA list. All the comments made were
    constructive suggestions and no dissent was noted. Although the 
    proposed status of the document is Informational the editors and the 
    sponsoring AD decided to run an IETF Last Call because of the 
    various areas that the content relates to. 

Document Quality

    This is not a protocol spec. It is clearly written with thorough
    references.

Personnel

    Dan Romascanu is the sponsoring Area Director. 
  
RFC Editor Note

 Please make the following changes: 

1. in Section 2.5: s/MS Exchange/Windows Server/

2. in Section 5.1.1: 

OLD:
   Until this ambiguous behaviour is clearly resolved by the IETF,
   operational problems are to be expected, since different host
   operating systems have taken different approaches.  This makes it
   difficult or impossible for a site network manager to configure
   routers and DHCPv6 servers in such a way that all hosts boot in a
   consistent way.  If one operating system starts a DHCPv6 client by
   default, and another one starts it only when it receives the M bit,
   and yet another uses SLAAC even if the M bit is set, systematic
   address management becomes impossible.

NEW:
   Until this ambiguous behaviour is clearly resolved by the IETF,
   operational problems are to be expected, since different host
   operating systems have taken different approaches.  This makes it
   difficult for a site network manager to configure systems in such
   a way that all hosts boot in a consistent way.  Hosts will start
   SLAAC if so directed by appropriately configured RA messages.
   However, if one operating system also starts a DHCPv6 client by
   default, and another one starts it only when it receives the M bit,
   systematic address management is impeded.

3. in Section 6.3: s/DNSOPS WG is working/DNSOP WG has considered/

RFC Editor Note