Re: [icnrg] Adoption of 'Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic' (draft-gundogan-icnrg-ccnx-timetlv)

"Thomas C. Schmidt" <t.schmidt@haw-hamburg.de> Mon, 03 August 2020 09:16 UTC

Return-Path: <t.schmidt@haw-hamburg.de>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440393A0CFA for <icnrg@ietfa.amsl.com>; Mon, 3 Aug 2020 02:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.946
X-Spam-Level:
X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 G6yBkGeOHuIF for <icnrg@ietfa.amsl.com>; Mon, 3 Aug 2020 02:16:05 -0700 (PDT)
Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C943A0CF9 for <icnrg@irtf.org>; Mon, 3 Aug 2020 02:16:04 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.75,429,1589234400"; d="scan'208";a="66284150"
Received: from hub01.mailcluster.haw-hamburg.de ([141.22.24.50]) by mail3.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Aug 2020 11:16:01 +0200
Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 3 Aug 2020 11:16:02 +0200
Received: from [192.168.178.22] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 3 Aug 2020 11:16:01 +0200
To: <icnrg@irtf.org>
References: <68D3AAD3-59E1-43AE-8722-06776AED4607@dkutscher.net> <E979BEAD-A9D1-484B-A46F-87069859F3B6@ieee.org> <874kpnj3d6.fsf@gundogan.net> <BA249AC5-3673-4377-9199-D9A7AE4E3519@dkutscher.net> <aef5d1a9f0cb47c58e0422817db2ce7b@HUB01.mailcluster.haw-hamburg.de>
From: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
Message-ID: <ea23975f-85aa-3cab-825a-528f8bfd56b3@haw-hamburg.de>
Date: Mon, 3 Aug 2020 11:16:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <aef5d1a9f0cb47c58e0422817db2ce7b@HUB01.mailcluster.haw-hamburg.de>
Content-Type: text/plain; charset="iso-8859-3"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [141.22.250.35]
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/L1pXgH9mEh7XGKSAYAFr-8HdbCU>
Subject: Re: [icnrg] Adoption of 'Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic' (draft-gundogan-icnrg-ccnx-timetlv)
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 09:16:07 -0000

Hi all,

a process of developing and evolving experimental research RFCs seems 
very natural (and common) to me. The IETF continuously updates protocol 
standards not only for error correction, but also for improvements and 
new use cases.

I wonder why the IRTF should be more conservative with experimental RFCs?

Best,
  Thomas

On 03/08/2020 11:10, Hitoshi Asaeda wrote:
> Hi Dirk,
> 
> I don't believe you'd like to repeat we are not in SDO and 8609 is not PS/DS.
> 
> If we know a serious error or do have a very positive reason, we may try to update RFC. Otherwise, we do not need to update experimental RFCs.
> My another concern is changing these base RFCs may let people recognize CCNx is still an unstable protocol (well someone will say, yes. :)
> And as the fact, we already have implementations based on 8609 and 8569. Whether the RFCs are PS/DS or experimental or others, having multiple and different implementations based on these RFCs is very positive for the deployment. Supporting a new RFC is easier for these implementations but changing the supported RFC is more negative at least for me.
> 
> Regards,
> 
> Hitoshi
> 
> 
>> On Jul 31, 2020, at 22:46, Dirk Kutscher <ietf@dkutscher.net> wrote:
>>
>> Hi everyone,
>>
>> Hitoshi-san, let me ask you this way: what problems do you see with updating RFC8609?
>>
>> Best regards,
>> Dirk
>>
>>
>> On 31 Jul 2020, at 14:06, Cenk Gündoğan wrote:
>>
>>> Hello Hitoshi,
>>>
>>> thank you for your feedback, my comments follow further down inline.
>>>
>>> On Fri, Jul 31 2020 at 11:51 +0200, Hitoshi Asaeda wrote:
>>>
>>>> Hi,
>>>>
>>>> I don't deny the proposal itself but have a concern about the intention; "update" RFC8609.
>>>>
>>>> Why does this draft update RFC8609? Why can't we keep RFC8609 as is and propose the new type values for this proposal as the addition?
>>>> The time TLV proposed in this document can coexist with RFC8609 if you use the new type values. Why does this need to replace the time TLV defined in 8609? Is there any errata reported for the time TLV defined in 8609?
>>>
>>> the current version of this document describes a few alternatives on how
>>> to integrate the compressed time TLV into CCNx. One alternative proposes
>>> to use the Length (L) field of the InterestLifetime TLV to identify the
>>> included encoding (normal time (L>1) vs. compressed time (L==1)
>>> representation). This would require a change in RFC8609 (Section 3.4.1
>>> [1]).
>>>
>>> Another alternative might update the message ABNF in Section 2.1 [2] of
>>> RFC8569 to add a new top-level TLV for the compressed InterestLifeTime.
>>>
>>> [1] https://tools.ietf.org/html/rfc8609#section-3.4.1
>>> [2] https://tools.ietf.org/html/rfc8569#section-2.1
>>>
>>>>
>>>> My comment is that it is better to discuss this document without an intention of updating RFC8609.
>>>
>>> All proposed integration alternatives display advantages and
>>> disadvantages. Getting group feedback on this particular topic is quite
>>> valuable for the progression of this work. Thanks! We could also
>>> reiterate over the existing integration ideas again (on the list?) in
>>> order to stimulate new ideas and solutions (comparable to a draft
>>> presentation?).
>>>
>>> Best,
>>> Cenk
>>>
>>>>
>>>> Regards,
>>>>
>>>> Hitoshi
>>>>
>>>>
>>>>> On Jul 29, 2020, at 21:39, Dirk Kutscher <ietf@dkutscher.net> wrote:
>>>>>
>>>>> Hi ICNRG,
>>>>>
>>>>> This draft (https://datatracker.ietf.org/doc/draft-gundogan-icnrg-ccnx-timetlv/) is intended as an update to RFC 8609 (CCNx Messages in TLV Format).
>>>>>
>>>>> The authors have just submitted an update that addresses previously made technical comments.
>>>>>
>>>>> We believe that it would be appropriate to give change control to the Research Group, so the chairs would like to solicit statements indicating support for adoption or concerns against it from people who are 1) not co-authors and 2) have read the latest version.
>>>>>
>>>>> In case there are questions that you would like to discuss interactively, we should be able to make some time for that on the Monday Interim meeting -- let us know.
>>>>>
>>>>> Thanks and best regards,
>>>>>
>>>>> Chairs
>>>>>
>>>>> _______________________________________________
>>>>> icnrg mailing list
>>>>> icnrg@irtf.org
>>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>>>
>>>> _______________________________________________
>>>> icnrg mailing list
>>>> icnrg@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>>
>>> --
>>> 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
>>> Mail: cenk.guendogan@haw-hamburg.de
>>> Web: https://www.inet.haw-hamburg.de/
>>> _______________________________________________
>>> icnrg mailing list
>>> icnrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/icnrg
>>
>> _______________________________________________
>> icnrg mailing list
>> icnrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/icnrg
> 
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg
> 

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                  Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group   20099 Hamburg, Germany °
° http://inet.haw-hamburg.de/members/schmidt      Fon: +49-40-42875-8452 °