Re: [icnrg] Moving NRS documents to RG documents

[Ravi Ravindran <[e-mail]>]

I support adoption of these documents as RG item, we also had argued for the need of differentiating application identifiers and network identifiers in the ICN layer particularly to support routing and mobility functions in https://tools.ietf.org/html/draft-azgin-icnrg-ni-02, among other usages it may serve.

Regards,
Ravi

From: icnrg [mailto:[e-mail]] On Behalf Of Cedric Westphal
Sent: Friday, July 27, 2018 1:37 AM
To: Lixia Zhang <[e-mail]>
Cc: icnrg <[e-mail]>
Subject: Re: [icnrg] Moving NRS documents to RG documents

Hi Lixia,

Comments in line.

C.

From: icnrg [mailto:[e-mail]] On Behalf Of Lixia Zhang
Sent: Thursday, July 26, 2018 8:40 AM
To: Börje Ohlman
Cc: icnrg; David Oran; Dirk Kutscher
Subject: Re: [icnrg] Moving NRS documents to RG documents

On Jul 24, 2018, at 2:38 AM, Börje Ohlman <[e-mail]<mailto:[e-mail]>> wrote:

Based on the discussion at the ICNRG meeting in Montreal the chairs would like to propose to move the following documents to RG documents.

  *   Requirements for Name Resolution Service in ICN - https://datatracker.ietf.org/doc/draft-jhong-icnrg-nrs-requirements/
  *   Architectural Considerations of ICN using Name Resolution Service - https://datatracker.ietf.org/doc/draft-hong-icnrg-icnnrs/

The main motivation is that the discussion on the pros and cons of using Name Resolution Systems (NRS) is a recurring topic in the RG. We think these documents are a good way to document the discussion and preserve it for future reference.
It can be noted that NRS is a critical component in some ICN architectures, e.g. DONA, PSIRP/PURSUITE, NetInf, Mobility First and IDNet.

I wonder whether the chairs could help clarify
1/ which of the above mentioned projects are still being actively pursued?

CW: the projects may not be actively pursued and may have evolved into new projects. The issue of name resolution is still critical.

2/ If some of then are no longer being actively pursued, what may be perceived benefits to this set of stopped projects from adopting the above documents.

CW: I do not think that the point of RG adoption is to provide benefits to stopped projects! Rather, it is to discuss the issue of name resolution. These previous projects do provide some light on the issue, however.

3/ step up a level: do we have a common ICN architecture framework?  or we have a set of such frameworks?

CW: I don’t think there is a common ICN architecture framework, but there are some overarching principles. One such principle is addressing common by name, and with this comes the issue of name resolution.

Best,

C.

Disclaimer: I have not read the above 2 documents and I missed all the discussions on these documents.

We would like to hear from the list if the ICNRG at large agrees with this assessment.
To be clear, we do *not* think these documents, in their current state, are ready for publication or a RG last call. What we propose is to move them to become RG documents and to make NRS architectural considerations and potential NRS requirements a RG work item. Next steps will be to further evolve these documents to make them the reference we need for future discussions. The goal should not be to define or prescribe how NRS should be used in ICN, but rather document design options, pros and cons with the use of NRS and to describe/document existing NRS implementations and the experience from using them.

I feel a bit confused: if NRS is not perceived as an important piece in ICN architecture, then why should this ICNRG spend its time and efforts on this?

Llxiia