From nobody Tue May 31 12:59:18 2022 Return-Path: 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 1D96DC15AAF3; Tue, 31 May 2022 12:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0rmRZyMVzz7; Tue, 31 May 2022 12:59:10 -0700 (PDT) Received: from mx2.mythic-beasts.com (mx2.mythic-beasts.com [46.235.227.24]) (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 E2499C15BFF4; Tue, 31 May 2022 12:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=3K+ZPKLvoV618S59HrFdrRp5zL3Vvdk6Hpt79OfrT6g=; b=yBr/3XR2OG65/p4kC5GDFaupng vURGbUGDui+GfkbrGL6e5Aya/KhtKrRgItN9Y8xtzOd4Uf5p9uAmwzOpt50ZY5OLhvz4DOGVZFVXU eVWmqGz4QDfS71CDpj5QtBbHARP3evGAAeyOqCf+Q98nK39wcfcs7joWsWiPqZEY4Rl2lF9lLebq5 1KgSOY+leghhV4YoqPZK+4Vx5J7JFdtlQ6Ql5gH3JpyV9hPjMLeZvdE6WZ1PqxGzpcW/WIz/tUwBB NKf3Fakc8M+zomaJCajKpb6h7gXc18qdvejuwhtmuj7DoGG1nj59gEcgFx32VEhCgPGMOdMkRdEMe hFUpbqAA==; Received: from [81.187.2.149] (port=33867 helo=[192.168.0.67]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1nw80w-0006bo-ON; Tue, 31 May 2022 20:58:55 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Colin Perkins In-Reply-To: <31d9accd-51ef-5327-48cb-e6280a6e4c1f@inria.fr> Date: Tue, 31 May 2022 20:58:41 +0100 Cc: Hitoshi Asaeda , draft-irtf-icnrg-ccninfo.authors@ietf.org, icnrg@irtf.org, The IRSG Content-Transfer-Encoding: quoted-printable Message-Id: References: <689A205C-B767-40D4-B11E-B0376396B946@csperkins.org> <630B08F2-26BC-4B2F-912E-5A77755D32EA@csperkins.org> <776cd07a-69ff-c692-38e3-e13a8f00e55c@inria.fr> <1638C3AD-A918-4521-A247-2221F80B879D@ieee.org> <31d9accd-51ef-5327-48cb-e6280a6e4c1f@inria.fr> To: =?utf-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= X-Mailer: Apple Mail (2.3445.104.21) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [icnrg] [irsg] IRSG review request draft-irtf-icnrg-ccninfo-08 X-BeenThere: icnrg@irtf.org X-Mailman-Version: 2.1.34 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, 31 May 2022 19:59:16 -0000 Thanks, J=C3=A9r=C3=B4me. Colin > On 31 May 2022, at 09:48, J=C3=A9r=C3=B4me Fran=C3=A7ois = wrote: >=20 > Hi, >=20 > I'll check that by the end of the week. >=20 > jerome >=20 > Le 31/05/2022 =C3=A0 00:46, Colin Perkins a =C3=A9crit : >> Hi J=C3=A9r=C3=B4me, Hitoshi, all. >>=20 >> Thanks for the update. J=C3=A9r=C3=B4me, can you please confirm = whether this latest version addresses your comments? >>=20 >> Thanks, >> Colin >>=20 >>=20 >>=20 >>=20 >>> On 25 Apr 2022, at 11:18, Hitoshi Asaeda = wrote: >>>=20 >>> Dear J=C3=A9r=C3=B4me, >>>=20 >>> Thank you very much for your careful review. >>> I've just submitted the revised draft. >>> Please check the revision and the following reply. >>>=20 >>>> On Apr 8, 2022, at 16:21, J=C3=A9r=C3=B4me Fran=C3=A7ois = wrote: >>>>=20 >>>> Dear Colin, IRSG members and draft authors, >>>>=20 >>>> Sorry for providing my review late but below are my comments for = draft-irtf-icnrg-ccninfo-08. >>>>=20 >>>> Best regards >>>> J=C3=A9r=C3=B4me >>>>=20 >>>> ----------------- >>>>=20 >>>> In general, the draft is well written but there some parts would = merit clarification. Below are my comments, suggestions and questions = (which actually reflects some lack of clarity IMHO). >>>>=20 >>>> Section 3 about the message formats is not easy to follow because = it is unclear how these messages will be used. Of course, answers comes = in the next section 4 but as section 3 is quite long I think this could = be improved by extending a bit the overview given in section 1 to = =E2=80=9Cprepare=E2=80=9D the reader for section 3. For instance in = section 1, we can easily understand the flow of request and reply = messages but with not so much regarding their content. My suggestions = are to comment more on figure 1 and 2 in order to highlight the = different structures used in messages afterwards (request header blocks, = report blocks, reply blocks) and when they are added. At a first = glance, when I read report block I was thinking this was related to = reply (somehow I thought reply =3D report). Of course when I read again = I saw this is not but as the term can be little confusing, clarifying = and emphasizing would avoid confusion. You can for example distinguish = what information would be set in the request message and the information = set in the reply. For replies, there are possibly multiple reply = sub-blocks but it remains unclear for me what each sub-block should = contain. I guess when there are multiple objects matching the prefix in = the request but I=E2=80=99m not sure this is clearly stated somewhere = (even in other sections). >>> Thanks for your comment. I changed section 1.1 to clarify above = points. Could you check section 1.1 of the revised draft? >>>=20 >>>> Some detailed comments per section below: >>>>=20 >>>> Section 2.1 (definition): >>>> - add the definitions of publisher and consumer as these terms are = widely used in the text then >>> Thanks. We added the definitions of publisher and consumer with the = reference, RFC8793 (ICN terminology). >>>=20 >>>> - CCNinfo user is also a node but a node (based on your definition) = can be router, publisher or consumer. So, is CCNinfo user a consumer = node? Or something different? >>> I see your point. In the revision of the terminology section we = mentioned that the CCNinfo user is: >>> "A node that initiates the CCNinfo Request, which is consumer or = router that invokes the CCNinfo user program with the name prefix of the = content. The CCNinfo user program, such as "ccninfo" command described = in Appendix A or other similar commands, initiates the Request message = to obtain routing path and cache information." >>>=20 >>>> - router definition: Unclear what is meant by =E2=80=9Cfacilitates=E2= =80=9D. Facilitates would suppose that is something not mandatory but = which can help. Without router, content retrieval cannot be done I guess = so the routers enable content retrieval ? >>> I see. I changed the definition as follows: >>> "A node that implements stateful forwarding in the path between = consumer and publisher." >>>=20 >>>> Section 3: >>>> - page 9: =E2=80=9Cthe Request and Reply Type values in the fixed = header are=E2=80=9D: use =E2=80=9CPacketType values=E2=80=9D to refer to = packet format in figure 3 >>> Thanks. Done. >>>=20 >>>> - page 9 =E2=80=9CThe CCNinfo Request and Reply messages MUST = ...=E2=80=9D: move/merge this sentence as first in the previous = paragraph as this sounds a bit redundant here. >>> Thanks. Done. >>>=20 >>>> - Figure 6: I was wondering if there is a particular reason to have = the request block TLV apart from other blocks (request header and = report). If yes, you could mention it in the doc. >>> Good point. I explained the reason as follows: >>> "Request header block TLV and Report block TLV(s) are contained in = the hop-by-hop header, as those might change from hop to hop. Request = block TLV is encoded in the PacketPayload TLV by content forwarder as = the protocol message itself." >>> Does this make sense? >>>=20 >>>> - page 11: =E2=80=9Cand __THE__ Request block TLV (Figure 7)=E2=80=9D= >>> Good catch, thanks. This should be Figure 10. Fixed. >>>=20 >>>> - page 12 SkipHop: =E2=80=9CRouters corresponding to the value = specified=E2=80=9D =E2=86=92 =E2=80=9CThe number of routers = corresponding...=E2=80=9D (as this is a value not a set of routers right = ?). State that this will correspond to the first routers in the paths = toward the publisher. >>> Right. I corrected "The number of routers ...". >>>=20 >>>> - =E2=80=9Crequest arrival time=E2=80=9D is used both in request = block and report blocks with the same definition. My understanding is = that request block is inserted by the initiator (CCNinfo user), so the = request arrival time in that case seems to not be =E2=80=9Cthe timestamp = specifying the arrival time of the CCNinfo Request packet at a specific = router=E2=80=9D but the timestamp the CCNinfo user create the request = (section 4,1, p. 21). If if I=E2=80=99m right, you could also think = changing the term =E2=80=9Crequest arrival time=E2=80=9D by something = more relevant in Request block TLV. >>> Well, "request arrival time" is the time that each router receives = the Request message. So, the name of this field can be same. Do you = think the following statement clarifies the point? >>> "The Request Arrival Time is a 32-bit NTP timestamp specifying the = arrival time of the CCNinfo Request message at the router." >>>=20 >>>> - page 23 and page 24: =E2=80=9Cit it terminates the Request...=E2=80= =9D: remove one =E2=80=9Cit=E2=80=9D >>> Thanks. Done. >>>=20 >>>> - section 5.6: I appreciate this section as I have in mind this = kind of complex example when reading previous sections. >>> Thanks. >>>=20 >>>> - section 8,2: precise what is meant by =E2=80=9Cidentified=E2=80=9D.= I understand that if a router hides itself you can just know there was = a router but you cannot know its id (so IMHY it is not really identify = but you can detect there is a hidden router)? >>> Thank you for pointing this out. Your understanding is correct. >>> In fact, this statement describes the same point mentioned in = section 8.1. Therefore I remove this sentence. >>>=20 >>> If there are still unclear statements/points, please tell me. >>>=20 >>> Thanks! >>>=20 >>> Regards, >>>=20 >>> Hitoshi >>>=20 >>>=20 >>>> _______________________________________________ >>>> 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 >=20 --=20 Colin Perkins https://csperkins.org/