Re: [icnrg] [irsg] Review of "Architectural Considerations of ICN using Name Resolution Service"

Jungha Hong <jhong@etri.re.kr> Tue, 19 January 2021 04:58 UTC

Return-Path: <jhong@etri.re.kr>
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 713733A1182 for <icnrg@ietfa.amsl.com>; Mon, 18 Jan 2021 20:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dooray.com
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 Egv2O7h3hJdm for <icnrg@ietfa.amsl.com>; Mon, 18 Jan 2021 20:58:14 -0800 (PST)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65F53A117F for <icnrg@irtf.org>; Mon, 18 Jan 2021 20:58:12 -0800 (PST)
Received: from unknown (HELO send001-relay.gov-dooray.com) (211.180.235.152) by 129.254.9.16 with ESMTP; 19 Jan 2021 13:58:07 +0900
X-Original-SENDERIP: 211.180.235.152
X-Original-MAILFROM: jhong@etri.re.kr
X-Original-RCPTTO: icnrg@irtf.org
Received: from [10.162.225.109] (HELO send002.gov-dooray.com) ([10.162.225.109]) by send001-relay.gov-dooray.com with SMTP id 383f3d09600666e2; Tue, 19 Jan 2021 13:58:10 +0900
DKIM-Signature: a=rsa-sha256; b=ZRCW/1y5zY+cl8P9peFCdmJuz3rCmQOZgOkseurxf1959nFMzPxz5fLO89U6cu/IBmQHn/I0hu v80f5TxTE1quJHBSM/3hjwQWKtLTqk3lTavpepgFe+O+JURFu1QZxubsfg1M06E+fQ2im5AVmqix k9S4ww2QkDwrIFiubFdrIPbjuB8m5mZ58PuQv/CJPvVaRiDx5yMBwj7zTKYoKqFNkrT10481e1YG 6AlO70iehbw+A/tF/gwi8MKntYWE4RuxHwu84QGf8QOGWarnuD6OiwVjFWCnyqhqbmd84qH+0P3z K7oqTxLDwTOqWee7zbBKHYYWH1LMhOzlHLBhmLxg==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=c5khTxDeuTeoc0/5yeY4+H2C29Q8TAHP9jsmMxb913Y=; h=From:To:Subject:Message-ID;
Received: from [129.254.70.83] (HELO 129.254.70.83) ([129.254.70.83]) by send002.gov-dooray.com with SMTP id a30bffc1600666e1; Tue, 19 Jan 2021 13:58:09 +0900
From: Jungha Hong <jhong@etri.re.kr>
To: Colin Perkins <csp@csperkins.org>, Dirk Kutscher <ietf@dkutscher.net>
Cc: Christopher Wood <caw@heapingbits.net>, draft-irtf-icnrg-nrsarch-considerations@ietf.org, icnrg@irtf.org
Message-ID: <m843qeuhmwmr.m843qeuixs3i.g1@dooray.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
X-Dsn-Request: true
X-Dooray-Agent: mail-api
X-Dooray-Mail-Id: 2925343524993603507
Importance: Normal
X-Priority: Normal
X-MSMail-Priority: Normal
Sender: jhong@etri.re.kr
Date: Tue, 19 Jan 2021 13:58:08 +0900 (KST)
References: <18a6633f-53af-4fdb-b815-8708ec0344ee@www.fastmail.com> <3794AC60-E4AC-4CEC-B4D0-819DFAA97742@csperkins.org> <4D9180E0-7A46-4696-A020-853EC7B97A88@dkutscher.net>
In-Reply-To: <4D9180E0-7A46-4696-A020-853EC7B97A88@dkutscher.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/QR9sMGK1jTf51Q3fcHsNuv2NBvQ>
Subject: Re: [icnrg] [irsg] Review of "Architectural Considerations of ICN using Name Resolution Service"
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: Tue, 19 Jan 2021 04:58:17 -0000

Dear Chris,

Thanks for your valuable comments.
We will try to improve the draft soon by clarifying the issues identified in the comments as much as possible. 

Thanks,
Jungha Hong



-----Original Message-----
From:  "Dirk Kutscher" <ietf@dkutscher.net>
To:     "Colin Perkins" <csp@csperkins.org>rg>; 
Cc:     "Christopher Wood" <caw@heapingbits.net>et>;   <draft-irtf-icnrg-nrsarch-considerations@ietf.org>rg>;   <icnrg@irtf.org>rg>; 
Sent:  2021-01-18 (월) 18:20:18 (UTC+09:00)
Subject: Re: [icnrg] [irsg] Review of "Architectural Considerations of ICN using Name Resolution Service"

Thanks, Chris!

What do the authors think?

Dirk


On 15 Jan 2021, at 19:35, Colin Perkins wrote:

> Chris – Thank you for the review!
>
> It seems there’s some discussion, and possibly a revised draft, 
> needed to address these comments, before the draft can proceed in the 
> publication process.
>
> Colin
>
>
>> On 11 Jan 2021, at 14:54, Christopher Wood <caw@heapingbits.net> 
>> wrote:
>>
>> Document: draft-irtf-icnrg-nrsarch-considerations-05
>>
>> The summary of the review is: Ready with issues
>>
>> Comments:
>>
>> Given that this is a considerations document for ICNRG, I think the 
>> level of detail is probably fine here. My biggest concern is the lack 
>> of discussion around NRS mapping management. The document states:
>>
>>   When an NRS is utilized in an ICN architecture, security threats 
>> may
>>   increase in various aspects...
>>
>> And then briefly describes "Name Space Management." It states that 
>> producer authentication is required, but I would like to see some 
>> more discussion there. In particular, is authentication required for 
>> only insertion into the NRS? What about updates or removal? 
>> (Something like BEAD [1] might help deal with deletion.)
>>
>> On a related topic, how do clients (resolvers) know if they received 
>> the most up-to-date version of an NRS mapping? Should these be stored 
>> in cacheable content objects, or in new protocol messages that are 
>> not cached? This relates to the discussion around mobility, and I'm 
>> not sure how much detail you want to add here. Maybe just mentioning 
>> the possibility of stale content as a consideration will suffice.
>>
>> Lastly, how a NRS impacts client behavior seems a bit unclear at the 
>> moment. This document seems to suggest that names can only map to 
>> other NDOs, and not, for example, prefixes. Should it be possible to 
>> query the NRS with a name prefix, and the NRS performs LPM to return 
>> the mapped value? What are the implications for clients if they can 
>> query by prefix? Should they always query the NRS before sending an 
>> interest for a name?
>>
>> I hope this helps.
>>
>> Best,
>> Chris
>>
>> [1] https://arxiv.org/pdf/1512.07311.pdf
>
>
> -- 
> Colin Perkins
> https://csperkins.org/
>
>
>
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg