Re: [icnrg] [irsg] IRSG review request draft-irtf-icnrg-ccninfo-08

Jérôme François <jerome.francois@inria.fr> Fri, 08 April 2022 07:21 UTC

Return-Path: <jerome.francois@inria.fr>
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 B25293A0E5A; Fri, 8 Apr 2022 00:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr
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 5s7eFLTN2qdG; Fri, 8 Apr 2022 00:21:49 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 ABD083A0E54; Fri, 8 Apr 2022 00:21:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=message-id:date:mime-version:subject:to:references:from: in-reply-to; bh=yjr7F8Qa0+Vw5b/AbG5wbYe4tPoXUn4aLNF+DBQCzzY=; b=HC9w4P38e61s9Ky0PdJUq87mpzyAETgYGTsFdLuQ+6uoIyXigbU4c3gB iR8Fnx1B6YLcmASpzoTw0rW0TIML8MTGEYf/Fo8JwWUxF0HjF9OterADS ZJuqEjclvQzROeW5f/rR639STIP2slXE7ba6/xRYeD8vM1BsNu8d97gQ7 I=;
Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jerome.francois@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos; i="5.90,244,1643670000"; d="scan'208,217"; a="10946431"
Received: from 45.3.103.84.rev.sfr.net (HELO [192.168.1.81]) ([84.103.3.45]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 09:21:45 +0200
Content-Type: multipart/alternative; boundary="------------P8QSRTNNpm0qHVToqF3q0606"
Message-ID: <776cd07a-69ff-c692-38e3-e13a8f00e55c@inria.fr>
Date: Fri, 08 Apr 2022 09:21:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.7.0
Content-Language: en-US
To: Colin Perkins <csp@csperkins.org>, The IRSG <irsg@irtf.org>, draft-irtf-icnrg-ccninfo.authors@ietf.org, icnrg@irtf.org
References: <689A205C-B767-40D4-B11E-B0376396B946@csperkins.org> <630B08F2-26BC-4B2F-912E-5A77755D32EA@csperkins.org>
From: Jérôme François <jerome.francois@inria.fr>
In-Reply-To: <630B08F2-26BC-4B2F-912E-5A77755D32EA@csperkins.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/21SuPY9xb6b5PCNtZxpGprHiaDU>
Subject: Re: [icnrg] [irsg] IRSG review request draft-irtf-icnrg-ccninfo-08
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: Fri, 08 Apr 2022 07:21:58 -0000

Dear Colin, IRSG members and draft authors,

Sorry for  providing my review late but below are my comments for 
draft-irtf-icnrg-ccninfo-08.

Best regards
Jérôme

-----------------

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).

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 “prepare” 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 = 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’m not sure this is clearly stated 
somewhere (even in other sections).


Some detailed comments per section below:

Section 2.1 (definition):
- add the definitions of publisher and consumer as these terms are widely used in 
the text then
- 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?
- router definition: Unclear what is meant by “facilitates”. 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 ?

Section 3:
- page 9: “the Request and Reply Type values in the fixed header are”: use 
“PacketType values” to refer to packet format in figure 3
- page 9 “The CCNinfo Request and Reply messages MUST ...”: move/merge this 
sentence as first in the previous paragraph as this sounds a bit redundant here.
- 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.
- page 11: “and __THE__ Request block TLV (Figure 7)”
- page 12 SkipHop: “Routers corresponding to the value specified” → “The number of 
routers corresponding...” (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.
- “request arrival time” 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 
“the timestamp specifying the arrival time of the CCNinfo Request packet at a 
specific router” but the timestamp the CCNinfo user create the request (section 
4,1, p. 21). If if I’m right, you could also think changing the term “request 
arrival time” by something more relevant in Request block TLV.
- page 23 and page 24: “it it terminates the Request...”: remove one “it”
- section 5.6: I appreciate this section as I have in mind this kind of complex 
example when reading previous sections.
- section 8,2: precise what is meant by “identified”. 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)?