Subject: Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6Support Required for all IP-capable nodes) to Proposed Standard

From: "George, Wesley" <[email-masked]>
Date: Mon, 22 Aug 2011 13:12:54 -0400

From: "t.petch" <[email-masked]>
To: <[email-masked]>
Reply-to: [email-masked]
Subject: Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6Support Required for all IP-capable nodes) to Proposed Standard

I find this document utterly bizarre and think it would seriously damage the
Internet to publish it.
____________
WEG] well, I find the vehemence of your statement a bit bizarre, but I would like to address your concerns if possible. Please explain how a recommendation to support IPv6 is going to "seriously damage the internet."

The idea that ipv6 should be regarded as normal, as of equal standing to ipv4 is
fine, the sort of statement that the IAB should make, or have made, as an RFC or
in some other form.
____________
WEG] Agree. IETF has remained version-agnostic for some time now. But they have not made anything like the statement that this draft makes, which is that IPv6 will be necessary because IPv4 is going to have difficulties in continuing to provide the same level of service post-exhaustion. In the authors' opinions, it is long overdue as guidance to implementers, so we made the statement in the hopes that we'd reach consensus, which in a way is a stronger statement than something coming out of the IAB anyway.

But this I-D claims
" Updates [RFC1122] to clarify that this document, especially in
section 3, primarily discusses IPv4 where it uses the more generic
term "IP" and is no longer a complete definition of "IP" or the
Internet Protocol suite by itself. "

IPv4 is a phenomenal success, and RFC1122 is a key part of that. IPv4 was a
confused jumble, as IPv6 is now, and RFC1122, with another two or so I-Ds, cut
through the cruft and rendered it usable. IPv6 desparately needs an equivalent
to RFC1122, as a trawl of the v6ops list archives shows, and clearly this I-D is
never going to be it, but claiming that this I-D provides an update to RFC1122,
coupled
with its title, gives the message that there is not going to be such an I-D;
IPv6 will remain a confused jumble (and so is unlikely ever to emulate the
success of IPv4).
___________
WEG] Ignoring for a moment the commentary on the state of the IPv6 RFCs vs IPv4, and the need for a "rosetta stone," I'll note that the choice to update several IP(v4) RFCs was something that has been controversial based on Intarea LC feedback as well, but we believed necessary to provide the linkage between the two. Honestly, I would have rather seen IETF issue formal updates to the existing "IP" RFCs to include IPv6, rather than building an entirely parallel set of documents, but here we are, so we made a choice. It would be helpful to understand whether your resistance to this document is solely due to the decision to have this be standards track, to update several existing RFCs, or both vs the general recommendation that implementers should support IPv6. While I believe that removing the update references will reduce the impact of the document, I am not opposed to issuing a new version of the document that does so and keeps to simply documenting the requirements for IPv6 support if consensus supports that action.

Thanks
Wes George

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.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 23 Aug 2011 11:08:56 -0400

This document really wants to be a BCP that makes deployment and strategy
recommendations.  But for some reason it has been disguised as a standards
track document (i.e., as a protocol specification), and the result is that
RFC 2119 language is being used in a very peculiar way.  I think this is
what is responsible for the impression that the document is "bizarre".

Some examples:

      a best effort SHOULD be made to update existing hardware and software
      to enable IPv6 support.

RFC 2119 language is used to distinguish optional from mandatory features in
an implementation.  But "a best effort ... to update existing hardware and
software" does not seem to be a feature of an implementation.  I just don't
understand what this statement requires, or how one would tell if a given
implementation is compliant with it or not.

        Current IP implementations SHOULD support IPv6.

Presumably, "current" implementations support whatever they support, I don't
really understand what is being required here.  

        New IP implementations MUST support IPv6.

Is there some objective difference between a "new" implementation and a
"current" implementation?  How many lines of code have to change before a
"current" implementation becomes a "new" one?

But I don't really see why "new" vs. "current" is even relevant.  If there
were a lot of folks writing IP implementations from scratch, using only the
RFCs for guidance, it would be really important to make sure they know about
IPv6.  Does anyone think that that's a real problem?

It may be a problem that new products continue to come out without IPv6
support, but in general, those new products use current implementations.  So
again, there doesn't actually seem to be a useful requirement expressed.

      IPv6 support MUST be equivalent or better in quality and
      functionality when compared to IPv4 support in an IP
      implementation.

So if the v6 support has more bugs than the v4 support (and hence lesser
quality), the implementation would be out of compliance with standards?  I
don't think IETF standards set quality metrics on implementations.

As for functionality, consider the following bit of functionality: the
ability to communicate with an IPv4-only host.  This is a piece of
functionality that v4 support has but v6 support doesn't.  So I guess no
implementation could ever meet the "requirements" of this document.

Finally:

      MUST NOT require IPv4 for proper and complete function.

Suppose the "proper and complete" function of a box requires the downloading
of updates from a server the box cannot necessarily reach using IPv6.  Then
IPv4 would be required for proper and complete function of the box.  Or
perhaps the box is a network monitoring appliance of some sort, and has to
use both IPv4 and IPv6 to do its job.  In this case too, v4 is required for
"proper and complete" function, but that shouldn't lead anyone to say that
the box is non-compliant with IETF standards.

This document just does not say what it means.  The RFC 2119 language is not
being used in the usual manner, it's really being used for its rhetorical
value.  This is not appropriate.

---

From: "t.petch" <[email-masked]>
Date: Wed, 24 Aug 2011 12:10:59 +0200

<tp>inline</tp>
----- Original Message -----
From: "George, Wesley" <[email-masked]>
To: <[email-masked]>; "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 22, 2011 7:12 PM

I find this document utterly bizarre and think it would seriously damage the
Internet to publish it.
____________
WEG] well, I find the vehemence of your statement a bit bizarre, but I would
like to address your concerns if possible. Please explain how a recommendation
to support IPv6 is going to "seriously damage the internet."

The idea that ipv6 should be regarded as normal, as of equal standing to ipv4 is
fine, the sort of statement that the IAB should make, or have made, as an RFC or
in some other form.
____________
WEG] Agree. IETF has remained version-agnostic for some time now. But they have
not made anything like the statement that this draft makes, which is that IPv6
will be necessary because IPv4 is going to have difficulties in continuing to
provide the same level of service post-exhaustion. In the authors' opinions, it
is long overdue as guidance to implementers, so we made the statement in the
hopes that we'd reach consensus, which in a way is a stronger statement than
something coming out of the IAB anyway.

But this I-D claims

IPv4 is a phenomenal success, and RFC1122 is a key part of that. IPv4 was a
confused jumble, as IPv6 is now, and RFC1122, with another two or so I-Ds, cut
through the cruft and rendered it usable. IPv6 desparately needs an equivalent
to RFC1122, as a trawl of the v6ops list archives shows, and clearly this I-D is
never going to be it, but claiming that this I-D provides an update to RFC1122,
coupled
with its title, gives the message that there is not going to be such an I-D;
IPv6 will remain a confused jumble (and so is unlikely ever to emulate the
success of IPv4).
___________
WEG] Ignoring for a moment the commentary on the state of the IPv6 RFCs vs IPv4,
and the need for a "rosetta stone," I'll note that the choice to update several
IP(v4) RFCs was something that has been controversial based on Intarea LC
feedback as well, but we believed necessary to provide the linkage between the
two. Honestly, I would have rather seen IETF issue formal updates to the
existing "IP" RFCs to include IPv6, rather than building an entirely parallel
set of documents, but here we are, so we made a choice. It would be helpful to
understand whether your resistance to this document is solely due to the
decision to have this be standards track, to update several existing RFCs, or
both vs the general recommendation that implementers should support IPv6.

<tp>
A general recommendation for implementers (and operators?) to support IPv6
is fine.  The part I am objecting to is having a standards track document
claiming to
update documents such as RFC1122.

Someone attracted by the title, and then seeing what the actual updates are to
RFC1122 etc, will, I fear, regard this as ridiculous, and will think that if
there is no
real update to RFC1122, or a fresh document for IPv6, then the IETF cannot be
serious about IPv6.  I believe that an IPv6 equivalent to RFC1122 etc is needed
now, and agree with Brian that
"draft-ietf-6man-node-req-bis is a step on the way."
but only a step.

Tom Petch
</tp>

While I believe that removing the update references will reduce the impact of
the document, I am not opposed to issuing a new version of the document that
does so and keeps to simply documenting the requirements for IPv6 support if
consensus supports that action.

Thanks
Wes George