Re: [sunset4] [v6ops] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt

Lee Howard <lee@asgard.org> Mon, 21 August 2017 13:29 UTC

Return-Path: <lee@asgard.org>
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4791329F2 for <sunset4@ietfa.amsl.com>; Mon, 21 Aug 2017 06:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxxCTpqxoguu for <sunset4@ietfa.amsl.com>; Mon, 21 Aug 2017 06:29:26 -0700 (PDT)
Received: from atl4mhob12.registeredsite.com (atl4mhob12.registeredsite.com [209.17.115.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC361132A25 for <sunset4@ietf.org>; Mon, 21 Aug 2017 06:29:25 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob12.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7LDTNS2002258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <sunset4@ietf.org>; Mon, 21 Aug 2017 09:29:23 -0400
Received: (qmail 15214 invoked by uid 0); 21 Aug 2017 13:29:23 -0000
X-TCPREMOTEIP: 68.100.68.25
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 21 Aug 2017 13:29:22 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Mon, 21 Aug 2017 09:29:18 -0400
From: Lee Howard <lee@asgard.org>
To: "STARK, BARBARA H" <bs7652@att.com>, Fred Baker <fredbaker.ietf@gmail.com>, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
CC: "sunset4@ietf.org" <sunset4@ietf.org>
Message-ID: <D5C057BB.820F4%lee@asgard.org>
Thread-Topic: [sunset4] [v6ops] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sunset4/q3lXJl9abKHhKf4_Drj6Y0hXg_Y>
Subject: Re: [sunset4] [v6ops] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: sunset4 working group discussion list <sunset4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sunset4>, <mailto:sunset4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sunset4/>
List-Post: <mailto:sunset4@ietf.org>
List-Help: <mailto:sunset4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sunset4>, <mailto:sunset4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Aug 2017 13:29:28 -0000


On 8/17/17, 4:58 PM, "sunset4 on behalf of STARK, BARBARA H"
<sunset4-bounces@ietf.org on behalf of bs7652@att.com> wrote:

>> >> The question I would ask is whether on-demand IPv4 makes sense.
>> > 
>> >I think "on-demand IPv4" would be rather easy with PPPoE. Many (telco)
>> >ISPs are still using PPPoE, and there's still a lot of equipment and
>> >routers that support it.
>> 
>> That’s exactly how it reads in the gapanalysis draft: it makes sense
>>for PPPoE.
>> 
>> However, I will argue to both working groups that we should find an
>>operator
>> who thinks this is a good idea. I hope we can get them to write it up.
>>If there
>> is no such operator, we should remove the section (or at most, footnote
>>it as
>> an idea somebody once thought of).
>
>On-demand IPv4 is unrealistic in today's world. To be useful, it requires
>a majority of customers have no chatty-to-the-Internet IPv4 apps on their
>home network. That's many years away, given continuing sales of IPv4-only
>"Smart" TVs and Blu-ray players.
>
>As for documenting how to do PPPoE on demand, I consider that
>unnecessary. It's already known how to do that. The code, equipment, and
>operational expertise already exists -- especially among ISPs with a
>history of using PPPoE. BBF even has RG requirements documented for it,
>and network element and architecture requirements. I see no need to
>create additional documentation in IETF. IETF has never been a good place
>to document anything substantive related to PPPoE (PPPoE is not an IETF
>standard; it was published as an "independent submission" informational
>RFC because no IETF WG would touch it).
>
>I don't care strongly whether or not on-demand IPv4 is removed from the
>gapanalysis draft (which I think is what Lee suggested). But I do find it
>odd that it should be removed just because it would only be useful during
>the actual sunset of IPv4 (and not in near-term deployments).


I agree that the scope of sunset4-gapanalysis includes the long term.

If IPv4-on-demand (or specifically the PPPoE version) were completely out
of the question of ever being used, I would continue advocating for the
section to be removed. But I think you’re saying that it will be used, but
that the people most likely to use it don’t know it yet. In that case,
let’s leave it in.

Lee