Subject: [sunset4] addition to gap-analysis

From: "Howard, Lee" <[email-masked]>
Date: Tue, 30 Sep 2014 09:14:51 -0400

I've been revising draft-george-ipv6-required based on notes from the last
IETF meeting and the mailing list. As discussed, I've removed the
recommendation to review the previous gap analysis efforts, and as we
discussed, that work ought to be included in the sunset4 gap analysis
document.

Specifically, I think it should be added to section 2 of the gap analysis:
2.  Related Work

   [RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794],
   [RFC3795] and [RFC3796] contain surveys of IETF protocols with their
   IPv4 dependencies.

I would add, from draft-george:
<t>Additionally, although reviews in RFC's <xref
      target="RFC3789">3789</xref> through RFC3796 ensured that IETF
standards
      then in use could support IPv6, no IETF-wide effort has been
undertaken
      to ensure that the issues identified in those drafts are all
addressed,
      nor to ensure that standards written after RFC3100 (where the
previous
      review efforts stopped) function properly on IPv6-only networks.</t>

<t>The IETF needs to ensure that existing standards and protocols have
been
actively reviewed, and any parity gaps either identified so that they can
be fixed, or documented as unnecessary to address because it is unused or
        superseded by other features.</t>

     <t>First, the IETF must review RFCs 3789-3796 to ensure that any gaps
in
      specifications identified in these documents and still in active use
      have been updated as necessary to enable operation in IPv6-only
      environments (or if no longer in use, are declared historic).</t>

<t>Second, the IETF must review documents written after the
      existing review stopped (according to RFC 3790, this review stopped
with
      approximately RFC 3100) to identify specifications where IPv6-only
      operation is not possible, and update them as necessary and
appropriate,
      or document why an identified gap is not an issue i.e. not necessary
for
      functional parity with IPv4.</t>

<t>This document does not recommend excluding Informational and
      BCP RFCs as the previous effort did, due to changes in the way that
      these documents are used and their relative importance in the RFC
      Series. Instead, any documents that are still active (i.e. not
declared
      historic or obsolete) and the product of IETF consensus (i.e. not a
      product of the ISE Series) should be included. In addition, the
reviews
      undertaken by RFC 3789-96 were looking for "IPv4 dependency" or
"usage
      of IPv4 addresses in standards". This document recommends a slightly
      more specific set of criteria for review: review should include
      consideration of whether the specification can operate in an
environment
      without IPv4. Reviews should include guidance on the use of 32-bit
      identifiers that are commonly populated by IPv4 addresses. Reviews
      should include consideration of protocols on which specifications
depend
      or interact, to identify indirect dependencies on IPv4. Finally,
reviews
      should consider how to migrate from an IPv4 environment to an IPv6
      environment.</t>

I have left out discussion of how to do this work, since it was unclear
whether consensus existed to include it in the document. The words are
still immortalized in
http://tools.ietf.org/html/draft-george-ipv6-support-02 if we need them.

I'm happy to help with support in this document, as needed.

Lee

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.