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

["STARK, BARBARA H" <[e-mail]>]

> >> 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). The analysis does not appear to be written to only discuss near-term problems that might be experienced and potential near-term solutions. This particular section clearly notes that it is only relevant for the time period when IPv4 really is sunsetting. I could certainly envision this might be used many years from now when current dual stack providers start turning down IPv4. It also seems odd to remove the gap analysis just because no-one today wants to deploy it today (which, as the analysis says, would not be a good idea) or document in IETF how to do something that is well-documented elsewhere and wouldn't be useful until years from now. The gap analysis does point to where the solution is currently documented.
Barbara