Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6Support Required for all IP-capable nodes) to Proposed Standard
"t.petch" <daedulus@btconnect.com> Wed, 24 August 2011 11:18 UTC
Return-Path: <daedulus@btconnect.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6482521F8AD6 for <ietf@ietfa.amsl.com>; Wed, 24 Aug 2011 04:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.963
X-Spam-Level:
X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSr+fp2yDpNh for <ietf@ietfa.amsl.com>; Wed, 24 Aug 2011 04:18:41 -0700 (PDT)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 6A26121F8AD3 for <ietf@ietf.org>; Wed, 24 Aug 2011 04:18:40 -0700 (PDT)
Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2bthomr14.btconnect.com with SMTP id EBS43307; Wed, 24 Aug 2011 12:14:46 +0100 (BST)
Message-ID: <00ad01cc6246$23e143a0$4001a8c0@gateway.2wire.net>
From: "t.petch" <daedulus@btconnect.com>
To: "George, Wesley" <wesley.george@twcable.com>, ietf@ietf.org
References: <34E4F50CAFA10349A41E0756550084FB0D5571BD@PRVPEXVS04.corp.twcable.com>
Subject: Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6Support Required for all IP-capable nodes) to Proposed Standard
Date: Wed, 24 Aug 2011 12:10:59 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E54DD25.004A, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.24.102414:17:7.944, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __HAS_HTML, HTML_NO_HTTP, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4E54DD27.0194, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: draft-ietf-intarea-ipv6-required@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2011 11:18:42 -0000
<tp>inline</tp> ----- Original Message ----- From: "George, Wesley" <wesley.george@twcable.com> To: <ietf@ietf.org>; "t.petch" <daedulus@btconnect.com> Cc: <draft-ietf-intarea-ipv6-required@tools.ietf.org> Sent: Monday, August 22, 2011 7:12 PM From: "t.petch" <daedulus@btconnect.com> To: <ietf@ietf.org> Reply-to: daedulus@btconnect.com 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. <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