Re: [icnrg] Fwd: New Version Notification for draft-gundogan-icnrg-ccnx-timetlv-01.txt

"Mosko, Marc <>" <> Tue, 10 March 2020 06:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DF583A08E7 for <>; Mon, 9 Mar 2020 23:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I-kzSvd4EiRw for <>; Mon, 9 Mar 2020 23:09:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 831F83A08E0 for <>; Mon, 9 Mar 2020 23:09:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=C/A0LcCoQERglotqz+T3T0ApTsKiSU5q5R8n+q3efvpq4gIFqeTVj37TnDjqVMPgKxOgLkRunMa8pXZGm5XLNmxDeygdWKFL3GMkGSLOSyGkhEpQUHDbex/JSpV0NOBd6phaPrCXvOzUjVl1uvliz8D0FAk6zBmXu4+C9zRbVkuU8Mplw+hLhIOJSvCFLtCkq6MBHr1y0jkI734A7p6VTSCvM+DFm0QbddQV6OxRgqaSNcbWEIDmNQ7zgujohB+Eyaxw82P9QmVeRk0nz2PJ9EqcnsRJJq3ZCPHagSqXoSFcVEKxH6b/yyFwTqwmzul+C6pYM6YyaqHOoPyquJ7vzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=0ClWZkwCOJk+/sZzut5LL1NLE+Jq9A2L55RkzzLYxSY=; b=DZ65FOdziiL6UCpTyfCKMoSvuj9x4ZzIUAgybZdPDj6wF9FwuRSO8XoBcXfQa7fNVpfZZIZqdGkYC6mQWQHnzvuCDTyaw/5FiyMsW2ANQ8zjGuXJon0EqCoq2IYNWBiKVsUNvjC9P+bfTyouma+h3lgWiWMtz06AAzx10xbdZPMWTjHiBWItIhd56rAHFXwh6IXorB+Bkyd4hjeONY7x/Er7Lc9SwEoUBRRCMW0UnizGX4snWoNtp8bHphsFXvAy9XMRe8H2nevVbRfvL4Fm1XUyKKzx9gQNxdnSwpv871LMho+H5yI2WSmmBpu0COI/B7IJmXBarzcfGNrRA/C2Dw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-parc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0ClWZkwCOJk+/sZzut5LL1NLE+Jq9A2L55RkzzLYxSY=; b=rmRZTj4XkRV30+9AwfSEzYA32BIVf+1Agx2CRsA3oOjj1AkI+my2WHBIi1iN3wuRqVrhlTAi/hvKw8qt6+dsD1O1Ugk7OkBb5NFjVenWfAFFWkOw5Dc9DwX8DgMREa5DLK8rkVBDK6Duui19u7H9cVJOhTDxjffmSOMLZ57VPmA=
Received: from (2603:10b6:a03:110::17) by (2603:10b6:a03:b4::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Tue, 10 Mar 2020 06:09:39 +0000
Received: from ([fe80::507e:3768:eb66:1e91]) by ([fe80::507e:3768:eb66:1e91%5]) with mapi id 15.20.2793.013; Tue, 10 Mar 2020 06:09:39 +0000
From: "Mosko, Marc <>" <>
To: Cenk Gündoğan <>, ICNRG <>
Thread-Topic: [icnrg] Fwd: New Version Notification for draft-gundogan-icnrg-ccnx-timetlv-01.txt
Thread-Index: AQHV9kVbnyGWOaKssEGAxqn1XCwu/6hA4xEA
Date: Tue, 10 Mar 2020 06:09:39 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 827da33b-e642-4f74-92c9-08d7c4b99ddb
x-ms-traffictypediagnostic: BYAPR15MB2838:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 033857D0BD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39850400004)(376002)(366004)(346002)(396003)(199004)(189003)(9686003)(6512007)(2616005)(6486002)(66574012)(186003)(26005)(33656002)(71200400001)(966005)(36756003)(36542004)(316002)(66476007)(110136005)(478600001)(15650500001)(66946007)(66556008)(76116006)(64756008)(81156014)(86362001)(81166006)(8676002)(5660300002)(8936002)(3450700001)(66446008)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB2838;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ppFijscATLcqNgcj5HxGFzGewKo+Q5mC4d631XTplQm0BCoVB8/FhSFRnMWfSZexPjjIhy7asD3aKMhzx14oznLFjnhXoboHMN4sSx09SEee36ztyRdlYvXL3pUGG5wNjxYAfy3z4ctr2P4W5lJ+hCSHWG3e2UBFAFxbHUuujY+wbtHA8Je3DT/YRJbLTTk2YqpIZVM86KzWKVbOpXaZ8tybbuQkNKSpwgpnC+60p9SZwc77vU2eqc9LQi56/0zJ9zBWLj1uLtP6vGr7tGUGi2D8gueFqcoH/ReZ7Tup4RwRqIXoURP6+NroTujB+BUJ0RE8/Iv9CGDH9EIfOr4LsY2sp5xQ18KQZHbQmbrxNrL+kGQqKFR0lMKQpLdGPdcdGbSjVGXiHy6WcfGJpPwc7m+CnEsudnXoUAtjPLuh8DcxbAcNpIjT3MlD8L1wSLDoUzN5ytRvZ4Pg+hUJZ5zrDaDPccpiuzrzM6XFcguVcR5BDZaXEnFvdce5s1Mpxvlh9ewqFANBh0ZIDfZCqkfNng==
x-ms-exchange-antispam-messagedata: qxynl4KGJASr85VSNYTrZh60DNJKSMyXWNoAF9SUe69iffoZqicCAYFPvmephQGCt0LWCrqSPQs8vYpmzdKox6QtU2ekjijlxkyhoLqsz4dkwVoIbjrTK3cO7IyXX7GZLGYC1wmCzo7KQSex7pTm5g==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 827da33b-e642-4f74-92c9-08d7c4b99ddb
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 06:09:39.0582 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 733d6903-c9f1-4a0f-b05b-d75eddb52d0d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yN/z1El1iczvhUoQptJ1wimViY07GbFVB0gyvtzXSTTI3dHqYtgKxaD/fMxz8cJW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2838
Archived-At: <>
Subject: Re: [icnrg] Fwd: New Version Notification for draft-gundogan-icnrg-ccnx-timetlv-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Mar 2020 06:09:45 -0000

I think this draft is very clear and easy to follow.  The only addition I would make is to include an appendix with a few test vectors, say 0, a subnormal, and a normal or two.  Or put them in the main text as examples.

One question to consider is, would there be more possible time encodings beyond this?  Do we need a way to clearly distinguish between time encodings for fields, or is inferring the encoding based on the length acceptable?  I would probably rule out a nested encoding, as that is counter-productive when trying to introduce a 1 byte scheme. 


On 3/9/20, 12:03 PM, "icnrg on behalf of Cenk Gündoğan" < on behalf of> wrote:

    Dear ICNRG,
    we updated our CCNx Time TLV draft to include the following changes:
    * we removed the previously included discussion on using a time base TLV
      for (absolute) RecommendedCacheTime (RCT) TLVs in content objects. The
      current approach interprets RCT as absolute (normal behavior) for UTC
      timestamps (8 octets), and as relative for a compact timestamp (1
    * we added an explicit configuration for exponent, mantissa, and bias to
      Section 4. That configuration yields a milli second resolution for
      lower time values and can also (with low resolution) reaches values
      has high as ~4 years.
    * we added a few alternatives to section 5 (CCNx protocol integration)
      to provide more material for discussions. This topic needs to converge
      to a distinct solution, though.
    As always, any feedback is highly appreciated.
    On Mon, Mar 09 2020 at 19:42 +0100, wrote:
    > A new version of I-D, draft-gundogan-icnrg-ccnx-timetlv-01.txt
    > has been successfully submitted by Cenk Gundogan and posted to the
    > IETF repository.
    > Name:		draft-gundogan-icnrg-ccnx-timetlv
    > Revision:	01
    > Title:		An Alternative Delta Time encoding for CCNx using Interval Time from RFC5497
    > Document date:	2020-03-09
    > Group:		Individual Submission
    > Pages:		8
    > URL:  
    > Status:
    > Htmlized:
    > Htmlized:
    > Diff: 
    > Abstract:
    >    CCNx utilizes Delta Time for a number of functions.  When using CCNx
    >    in environments with constrained nodes and/or bandwidth constrained
    >    networks, it is valuable to have a compressed representation of delta
    >    time.  In order to do so, either accuracy or dynamic range has to be
    >    sacrificed.  Since the current uses of delta time do not require both
    >    simultaneously, one can consider a logarithmic encoding such as that
    >    specified in RFC5497.  This document updates _CCNx messages in TLV
    >    Format_ (RFC8609) to specify this alternative encoding.
    > Please note that it may take a couple of minutes from the time of submission
    > until the htmlized version and diff are available at
    > The IETF Secretariat
    Cenk Gündoğan
    Hamburg University of Applied Sciences
    Dept. of Computer Science / Internet Technologies Group
    Berliner Tor 7, 20099 Hamburg, Germany
    Fon: +49 40 42875 - 8426