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

Hitoshi Asaeda <> Mon, 25 April 2022 10:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADD393A1828 for <>; Mon, 25 Apr 2022 03:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.11
X-Spam-Status: No, score=-7.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mlL72AHCd6qC for <>; Mon, 25 Apr 2022 03:18:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F19E3A17E5 for <>; Mon, 25 Apr 2022 03:18:32 -0700 (PDT)
Received: by with SMTP id c23so25974544plo.0 for <>; Mon, 25 Apr 2022 03:18:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h6jYeJz7opD/i3xyEFmAqrVJFQnIPNa4Wft+paUBN6I=; b=QEf2qbJrZK0HAV09raSSmKlYNJDrCqTR45iEKu05BtSRIPzoiT5QH5d0N9OhBk0eMk mtFnjCv5omYh9VWrQVJ02cvUnDzYN6FRqPpMp9NRWHkJrkU/DHU5rR7rpX9+NxzQh9mS nNm/j8DFumO0mjP2kmb3dduvvXaHwv9/kFueM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h6jYeJz7opD/i3xyEFmAqrVJFQnIPNa4Wft+paUBN6I=; b=6CPQlE09I+9f3XZF/RTST4giDmLF4AF/Py6y33CAm7SFTjHf0Vn6HWpXLdKSS/PT7R 1M0wjTnyYjOMTRtAsD+oT83hv7s12vEE2Emi4jTi6S/7DhhXj96e0KGaGHmz5xaN5/Ye m90d5rUFE9+ZcII6DRKXQH1/COxMeqwn5QOeYtnXubnanPzvNjh3JqgNOYrF36Th6Eng oFNCoByPQm0ZV7vmT3CBjD3Vz9w0o9mCH/L5hAfsscHNzgCI6xBspoXvrxUzcDMf+8Xy JXsjDOa8iy7b9/eqE/2xYIDMo6KlCuUG7FSUr0/J5RoscNeDvWChu3bQyBpGOci5aRrM rQig==
X-Gm-Message-State: AOAM531W0+bKP9VgYS3Pn6nMBtei60WiZ/wpAYA7uJKvPN3pqvFA7cDQ /keskS3AKvz2ecVNKJFEEBb/Jg==
X-Google-Smtp-Source: ABdhPJxpUX8pLrAK53VSGjHERp7bkwQfJ9cEwUL0EZo/mMcH1h7yzsW9WLDfvOXBrYC/rXRu4xqwCA==
X-Received: by 2002:a17:90b:1192:b0:1cb:59d0:d06f with SMTP id gk18-20020a17090b119200b001cb59d0d06fmr30525810pjb.127.1650881910851; Mon, 25 Apr 2022 03:18:30 -0700 (PDT)
Received: from ( []) by with ESMTPSA id u26-20020a63471a000000b003aa1ad643bdsm9497010pga.47.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Apr 2022 03:18:30 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.\))
From: Hitoshi Asaeda <>
In-Reply-To: <>
Date: Mon, 25 Apr 2022 19:18:27 +0900
Cc: Colin Perkins <>, The IRSG <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Jérôme François <>
X-Mailer: Apple Mail (2.3693.
Archived-At: <>
Subject: Re: [icnrg] [irsg] IRSG review request draft-irtf-icnrg-ccninfo-08
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: Mon, 25 Apr 2022 10:19:06 -0000

Dear Jérôme,

Thank you very much for your careful review.
I've just submitted the revised draft.
Please check the revision and the following reply.

> On Apr 8, 2022, at 16:21, Jérôme François <> wrote:
> 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).

Thanks for your comment. I changed section 1.1 to clarify above points. Could you check section 1.1 of the revised draft?

> 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

Thanks. We added the definitions of publisher and consumer with the reference, RFC8793 (ICN terminology).

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

> - 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 ?

I see. I changed the definition as follows:
"A node that implements stateful forwarding in the path between consumer and publisher."

> 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

Thanks. Done.

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

Thanks. Done.

> - 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?

> - page 11: “and __THE__ Request block TLV (Figure 7)”

Good catch, thanks. This should be Figure 10. Fixed.

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

Right. I corrected "The number of routers ...".

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

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

> - page 23 and page 24: “it it terminates the Request...”: remove one “it”

Thanks. Done.

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

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.

If there are still unclear statements/points, please tell me.




> _______________________________________________
> icnrg mailing list