Sunset4 Charter
charter-ietf-sunset4-02

[Ballot block]
A purely editorial DISCUSS (as discussed live with Ralph)

... facilitate the graceful "sunsetting"
  of the IPv4 Internet in areas where IPv6 has been deployed. This
  includes the act of shutting down IPv4 itself, ...

So we agree that, right now, we have IPv4 + IPv6, and that this WG should help shutting down IPv4.
However, this following sentence is incorrect.

  As a rule, deployment scenarios considered by the working group
  shall include IPv6-only nodes and networks.

... because it tells that the only scenarios that the WG will consider are the IPv6-only.

This also contradicts:
Sep 2013 - Submit provisioning methods to signal a dual-stack host to disable the use of IPv4 to IESG for consideration as Proposed Standard

[Ballot comment]
Two minor points I hope can be looked at...

1. I continue to hate the use of "freely" in the first paragraph. Can you consider "readily"?

2. We have a rule and a work item that appear to be in conflict:

  As a rule, deployment scenarios considered by the working group
  shall include IPv6-only nodes and networks.

  ...and...

  * Provisioning methods to signal a dual-stack host to disable or
    depreference the use of IPv4

  I'm not saying which is wrong, but one of them must be.

[Ballot comment]
Question for clarification:
What is a 'provisioning method' mentioned in this item:
"Provisioning methods to signal a dual-stack host to disable or depreference the use of IPv4."?

[Ballot comment]
IPv4 addresses were never "freely available", and I think we should steer well clear of language that will be a red rag to those who found it hard to get their hands on blocks of addresses. You might get away with "once considered plentiful" which is probably what you are trying to say.

[Ballot block]
The charter says:

  The initial work items are:

  * NAT64 port allocation and address sharing methods involving
    scenarios where an IPv6-only node is present (and NAT44, as it
    overlaps NAT64 address sharing and port use).

Then later in Goals and Milestones:

  Jun 2013 - Submit NAT64 port allocation and address sharing methods
              to IESG for consideration as an Informational RFC

So, it turns out that Robert was correct during our discussion of charters in Atlanta: I wouldn't have noticed the problem with the bit in the body of the charter had I not seen the proposed milestone to fulfill that bit of the charter.

You propose a work item of creating a set of methods for NAT64 port allocation and address sharing for IPv6-only nodes. That sounds like perfectly reasonable protocol work. But then I don't get why this is listed in the milestones as an Informational document. Either I don't understand the work item, or your milestone is wrong. Please explain.