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 258B613476B; Thu, 28 Sep 2017 10:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Jie48fKpUw69; Thu, 28 Sep 2017 10:27:17 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B74134769; Thu, 28 Sep 2017 10:27:16 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u138so3703666wmu.5; Thu, 28 Sep 2017 10:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=LkLJevFwk6LV0zSZpHiU/9ykgRf5MdGqTOWsRdKA1zY=; b=OK0JdWsCJ54brjKXfTjkYPeEGyWvn7RaAt4JfNbb3W6+F3Bdb+y2Syda3biAjBdNnO hEBwX4EmPLheQ9y3RvlhuABKNCg8hTIDY0C+A8WFJKnKXx97DCE4fDP41+ncy+wjypJC M4cGzjGF1ehVhx4Hn0vM9R0XE7lM8lFuVJigITvdsx5KQ0X/PzeZRHsHr/jf20TNtFsD iZoL6bBd6BYYsDgPZeakrRBPvLeCw8CFMasTtf6I96YfWk5RVoXgTU9ogUlPlglLRl7Y aGDDjDuAsdaP/oM4DsW8+rmCO+Ux9A/pbI8dAYHDzpJO7v2+I5DgUeb/iwx2Ok7tAnSw K7Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=LkLJevFwk6LV0zSZpHiU/9ykgRf5MdGqTOWsRdKA1zY=; b=SL33HDMt/+aYzbjrO7TKI43BlYAJjkIXcNmnk11KaVTY0QHYV8nrKTZWXEbSLir+q/ xDa4QP7NTf98XOQDPeOE8eR8r9rb2brjCRgR5gK+dSjlvmgGD6zfUxilDha1zxcwZ3ni r317sUjPUbFMtoYG7E9XW2M4M08KKewAW2hrznfkQEHu8awvSTWQhQWTfp+rfWDG4es8 IwRtgM5H9hZqsjlls5gRfrYUrPzgtAvlQV61kj1+s9YUVhDnnF0HqycDyOXcztDw7hA0 doaQqVA1czz9a2NVEhnpMGP/Qr/8wiq8z9r1QTRj4wi+7SsbNP8WCIL/kUCHpAQMK7AE AQNw== X-Gm-Message-State: AHPjjUiys4fZM2Y2JgcHwc0wqYNCXpWe6wR2yfMa8nVP3MTOMCn3r8w9 PGqRo+4/8d6nPI0Oqd7qasucJNok X-Google-Smtp-Source: AOwi7QAl4ekas1fXKbSMs4541rdovYXU/acBUhwO6vE4TDobuX+6AeIaswcha+C3gkycqu88K/6znA== X-Received: by 10.80.149.219 with SMTP id x27mr6590357eda.146.1506619634773; Thu, 28 Sep 2017 10:27:14 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 6sm1751041ede.81.2017.09.28.10.27.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 10:27:14 -0700 (PDT) To: Lee Howard , Phillip Hallam-Baker , IETF Discussion Mailing List Cc: IETF-Announce , sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <9637bbf6-82a2-c94d-0b3d-238501e7679a@gmail.com> Date: Thu, 28 Sep 2017 18:27:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B39CE4A22FB8BEFD14B2C360" Content-Language: en-GB Archived-At: Subject: Re: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 17:27:25 -0000 This is a multi-part message in MIME format. --------------B39CE4A22FB8BEFD14B2C360 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Set aside that we will develop IPv6 as necessary. I am sure we will do that. I can see lots of down side in making this declaration, which may be interpreted as we intend, but more likely as others with political or commercial ambition spin it. Making this statement has the potential to develop into a huge inter-SDO fight. I am not at all clear on the upside. We should make declarations about IPv6, but remain silent on IPv4. - Stewart On 28/09/2017 17:18, Lee Howard wrote: > > > From: sunset4 > on behalf of Phillip Hallam-Baker > > > Date: Thursday, September 28, 2017 at 10:34 AM > To: IETF Discussion Mailing List > > Cc: >, > >, > >, IETF-Announce > >, > > > Subject: Re: [sunset4] Last Call: > (IETF: End Work on IPv4) to > Proposed Standard > > I remain opposed for the reason I gave last time this was > proposed: The IETF should retain control of IPv4 and any statement > to the effect that the IETF will no longer work on IPv4 will > inevitably lead to formation of an IPv4 legacy standards group in > competition with IETF. > > > That would be an interesting development. But the document is hard to > interpret as “The IETF has abdicated responsibility for IPv4.” For > instance, the third sentence: > Until the time when IPv4 is no longer in > wide use and/or declared historic, the IETF needs to continue to > update IPv4-only protocols and features for vital operational or > security issues. > Similarly: > Some changes may be necessary in IPv4 protocols to > facilitate decommissioning IPv4 in a way that does not create > unacceptable impact to applications or users. > And also: > The IESG will review proposed working group charters to ensure that > work will be capable of operating without IPv4, except in cases of > IPv4 security, transition, and decommissioning work. > Finally, looking at the number of times we have actually Updated > RFC791 "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL > SPECIFICATION” (four times, if I recall correctly) suggests to me that > a competing standards body created for the purpose of updating IPv4 > would find itself with little to do. > > > Like it or not, FORTRAN and COBOL are still in common use a full > 40 years after they were functionally obsolete. I see no reason to > believe that anyone will need more than 32 bits of addressing for > their home network. There being no compelling reason for my coffee > pot to be able to talk to the entire Internet, I have a compelling > reason to prevent it doing so. > > Rather than sunset IPv4, I would sunset IPv4 as an Internet > protocol and relegate it to use as a network protocol only. > > > Then change the name to NPv4? > > Do we care what people do on their private networks? Is it any of our > business? > > Lee > --------------B39CE4A22FB8BEFD14B2C360 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Set aside that we will develop IPv6 as necessary. I am sure we will do that.

I can see lots of down side in making this declaration, which may be interpreted as we intend, but more likely as others with political or commercial ambition spin it. 

Making this statement has the potential to develop into a huge inter-SDO fight.

I am not at all clear on the upside.

We should make declarations about IPv6, but remain silent on IPv4.

- Stewart

On 28/09/2017 17:18, Lee Howard wrote:


From: sunset4 <sunset4-bounces@ietf.org> on behalf of Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thursday, September 28, 2017 at 10:34 AM
To: IETF Discussion Mailing List <ietf@ietf.org>
Cc: <sunset4@ietf.org>, <sunset4-chairs@ietf.org>, <draft-ietf-sunset4-ipv6-ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>, <terry.manderson@icann.org>
Subject: Re: [sunset4] Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4) to Proposed Standard

I remain opposed for the reason I gave last time this was proposed: The IETF should retain control of IPv4 and any statement to the effect that the IETF will no longer work on IPv4 will inevitably lead to formation of an IPv4 legacy standards group in competition with IETF.

That would be an interesting development. But the document is hard to interpret as “The IETF has abdicated responsibility for IPv4.” For instance, the third sentence:
Until the time when IPv4 is no longer in
   wide use and/or declared historic, the IETF needs to continue to
   update IPv4-only protocols and features for vital operational or
   security issues.
Similarly:
Some changes may be necessary in IPv4 protocols to
   facilitate decommissioning IPv4 in a way that does not create
   unacceptable impact to applications or users. 

        
And also:

        
   The IESG will review proposed working group charters to ensure
      that work will be capable of operating without IPv4, except in
      cases of IPv4 security, transition, and decommissioning work.

        



        
Finally, looking at the number of times we have actually Updated RFC791 "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION” (four times, if I recall correctly) suggests to me that a competing standards body created for the purpose of updating IPv4 would find itself with little to do.

        

      

      
        

          

            


            

            
Like it
              or not, FORTRAN and COBOL are still in common use a full
              40 years after they were functionally obsolete. I see no
              reason to believe that anyone will need more than 32 bits
              of addressing for their home network. There being no
              compelling reason for my coffee pot to be able to talk to
              the entire Internet, I have a compelling reason to prevent
              it doing so.

            


            

            
Rather
              than sunset IPv4, I would sunset IPv4 as an Internet
              protocol and relegate it to use as a network protocol
              only.

          

        

      
      


      

      
Then change the name to NPv4?

      


      

      
Do we care what people do on their private networks? Is it
        any of our business?

      


      

      
        

          
Lee

        

      
        

          


          

        

      
    

    

  


--------------B39CE4A22FB8BEFD14B2C360--