[Idr] Mail regarding draft-liang-idr-flowspec-v1-time

Stewart Bryant <stewart.bryant@gmail.com> Fri, 15 July 2016 16:49 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEFA12D81D; Fri, 15 Jul 2016 09:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level:
X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 qqlddO3djhBB; Fri, 15 Jul 2016 09:49:24 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 19ADB12D78F; Fri, 15 Jul 2016 09:49:12 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id f126so32998413wma.1; Fri, 15 Jul 2016 09:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:subject:from:message-id:date:user-agent:mime-version; bh=8j8e4XTugvzpwgQv4n434DzI2h6oyAn39YIuBaqYvFE=; b=kSlEVCC+X0Cw0KHoPSMsZwgkrRnZnw8vB/cqESRF2evfRlHJfJWLPiSIW+cSTWlhUk cRFeKELrfM8FlIMVNNrr1eLLH8k+3f0bGkHYKYYvl6Qo7wF9SleenufeoFuDsQNgg1Cq +qh6ZQt8ITVAV151V/Kx9p6AjsJEw3qGkByHgFw7WChiJy4h/1WmWGVMY8jvdIU1rHcZ CVrtkByGJLlYHq0BsqZJv3bP3XhWqlx4cwseZuB1latOyDLzRjKhP5kInnjkF9z51SFG gibcqVdUr/B+vDNVAJi5PrvldIWJ9ImID74Ki2W4CeA+F7gfQpWU2DiezY2TaK3rbrNw kxDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:subject:from:message-id:date:user-agent :mime-version; bh=8j8e4XTugvzpwgQv4n434DzI2h6oyAn39YIuBaqYvFE=; b=lhynGSQ/GcxHAob/J1G7Zp3eE3oTC8n5XPe5wSOcdp+QHhfag5X6bQypEWMAnwPB04 G2NE5s7hmNqGdBigSFDvnIKjs97COem+yAFR7LOMLCr1BoY3JfAZzmWTbERAAEI2n6wQ CoA/rp/sFim1x3IRxlHLRtqU/1U66xVCDrp/+0tkfgMFBPaEtiBw1jNlquxPwwhbJP7h k1Jh+rmFcFjwsAIBBTgJjZyPIUvoRPqtF+1ohejqqRt9RoxdoSKqc5yxWGJBoj3+fvCz 9RWWl7NytBjpiNmmlsZd074L3gieREwtGzts/rVZk7T4SA9c02u8ESo6+FqQyXTOp/gw J8cg==
X-Gm-Message-State: ALyK8tLeyxwzyK/ilgLfFDalGQpGI8bwDdQWIGYXxnJWZddjk3/EZplt6pV/S7mH7FXSEA==
X-Received: by 10.28.30.1 with SMTP id e1mr12815842wme.77.1468601350199; Fri, 15 Jul 2016 09:49:10 -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 a203sm170024wma.0.2016.07.15.09.49.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jul 2016 09:49:09 -0700 (PDT)
To: draft-liang-idr-flowspec-v1-time@ietf.org, idr@ietf.org
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <de0f22db-2875-6beb-473a-43cb335a9269@gmail.com>
Date: Fri, 15 Jul 2016 17:49:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------D0581DF5FE27F643A8778DC3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3DU7agzNey-yyv8B7f4NK833oHI>
Subject: [Idr] Mail regarding draft-liang-idr-flowspec-v1-time
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jul 2016 16:49:26 -0000

Hi

You seem to have specified this using 32bit Unix time.

To quote that well known reference Wikipedia:

  * At 03:14:08 UTC on Tuesday, 19 January 2038,32-bit versions of the
    Unix time stamp will cease to work
    <https://en.wikipedia.org/wiki/Year_2038_problem>, as it will
    overflow the largest value that can be held in a signed 32-bit
    number (7FFFFFFF_16 or2,147,483,647
    <https://en.wikipedia.org/wiki/2147483647>). Before this moment,
    software using 32-bit time stamps will need to adopt a new
    convention for time stamps,^[20]
    <https://en.wikipedia.org/wiki/Unix_time#cite_note-28> and file
    formats using 32-bit time stamps will need to be changed to support
    larger time stamps or a different epoch. If unchanged, the next
    second will be incorrectly interpreted as 20:45:52 Friday
    13 December 1901 UTC.


2038 is not actually that far away, and looks like it will need a 
protocol re-spin to fix.  It would seem to be a good idea to avoid this 
at design time by using a larger field for seconds, or an epoch that is 
less than  46 years old, or include an epoch for the BGP session (which 
allows compact representation and no practical end date)?

Regards

Stewart