Return-Path: 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 92B4912DC79 for ; Thu, 17 Mar 2016 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 tqbTI9nseNl0 for ; Thu, 17 Mar 2016 10:36:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC91C12DD0C for ; Thu, 17 Mar 2016 10:28:26 -0700 (PDT) Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 036B347728; Thu, 17 Mar 2016 13:28:25 -0400 (EDT) From: "Marc Blanchet" To: "Lee Howard" Date: Thu, 17 Mar 2016 13:28:24 -0400 Message-ID: In-Reply-To: References: <56E9A555.7000808@forthnet.gr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_29648457-B8D4-413A-9AC5-8D4F710AB7D1_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "sunset4@ietf.org" Subject: Re: [sunset4] Declaring IPv4 Historic X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 17:36:47 -0000 --=_MailMate_29648457-B8D4-413A-9AC5-8D4F710AB7D1_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 17 Mar 2016, at 6:35, Lee Howard wrote: > On 3/16/16, 7:26 PM, "sunset4 on behalf of Tassos Chatzithomaoglou" > wrote: > >> I support the idea of this draft, but... >>> The IETF does not update Historic RFCs. Therefore, the IETF will >>> no >>> longer work on IPv4 technologies, including transition >>> technologies. >> ...i would like to see included some clarifications about the >> transition >> technologies. >> It seems risky to "abandon" softwires/behave work without having good >> exposure on operators. >> It's like we assume that everything transition-related will either >> work >> fine or won't be needed. > > This is one of the most common comments I¹ve gotten so far. I do > think > there¹s operational experience with all of the major transition > technologies, but they¹re all still fairly new. > > What would folks think of modifying the statement from: > the IETF will no > longer work on IPv4 technologies, including transition > technologies. > > > To: > the IETF will no > longer develop new IPv4 technologies, including IPv4-IPv6 > transition > technologies. I like it better. I would suggest « including IPv4 to IPv6 transition technologies. (to avoid excluding NAT64 and related that are needed for the next decade… > > I¹d like to get across the idea that new development will be in IPv6, > not > IPv4. The IPv4 spec itself won¹t be updated at all (once it¹s > Historic), > but transition technologies could be revised for operational and > security > reasons. Also, I feel pretty strongly (but will listen to consensus) > that > it¹s too late to develop any new transition (or life-extension) > technologies. I agree, except for v6 to v4 such as NAT64. Marc. > >> >> Also i would to have more information about the draft's effect on >> DHCP >> and any new options may come out. > > What would you like it to say? > Can we stop it with new DHCP (v4) options, and just put them in IPv6? > Do > we need to list all IPv4-specific protocols and technologies and > specify > whether they can be revised? > > > >> >> -- >> Tassos > > Thanks, > > Lee > > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 --=_MailMate_29648457-B8D4-413A-9AC5-8D4F710AB7D1_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 17 Mar 2016, at 6:35, Lee Howard wrote:

On 3/16/16, 7:26 PM, "sunset4 on behalf of Tassos Chatzit= homaoglou"
<sunset4-bounces@ietf.org on behalf of achatz@forthnet.gr> wrote:

I support the idea of this draft, but...

The IETF does not update Historic RFCs. Therefore, the I= ETF will no
longer work on IPv4 technologies, including transition technologies.

...i would like to see included some clarifications about= the transition
technologies.
It seems risky to "abandon" softwires/behave work without having good
= exposure on operators.
It's like we assume that everything transition-related will either work fine or won't be needed.

This is one of the most common comments I=C2=B9ve gotten = so far. I do think
there=C2=B9s operational experience with all of the major transition
technologies, but they=C2=B9re all still fairly new.

What would folks think of modifying the statement from: the IETF will no
longer work on IPv4 technologies, including transition technologies.

To:
the IETF will no
longer develop new IPv4 technologies, including IPv4-IPv6 transition technologies.

I like it better. I would suggest =C2=AB=C2=A0including I= Pv4 to IPv6 transition technologies. (to avoid excluding NAT64 and relat= ed that are needed for the next decade=E2=80=A6

I=C2=B9d like to get across the idea that new development= will be in IPv6, not
IPv4. The IPv4 spec itself won=C2=B9t be updated at all (once it=C2=B9s H= istoric),
but transition technologies could be revised for operational and security=
reasons. Also, I feel pretty strongly (but will listen to consensus) that=
it=C2=B9s too late to develop any new transition (or life-extension)
technologies.

I agree, except for v6 to v4 such as NAT64.

Marc.

Also i would to have more information about the draft's e= ffect on DHCP
and any new options may come out.

What would you like it to say?
Can we stop it with new DHCP (v4) options, and just put them in IPv6? Do<= br> we need to list all IPv4-specific protocols and technologies and specify<= br> whether they can be revised?

--
Tassos

Thanks,

Lee

sunset4 mailing list
sunset4@ietf.org
https://www.iet= f.org/mailman/listinfo/sunset4

--=_MailMate_29648457-B8D4-413A-9AC5-8D4F710AB7D1_=--