Subject: [icnrg] Moving NRS documents to RG documents

From: Börje Ohlman <[email-masked]>
Date: Tue, 24 Jul 2018 09:38:43 +0000

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.

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.

    Börje, Dave & Dirk

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 26 Jul 2018 08:39:31 -0700

On Jul 24, 2018, at 2:38 AM, Börje Ohlman <[email-masked]> wrote:
> Requirements for Name Resolution Service in ICN - https://datatracker.ietf.org/doc/draft-jhong-icnrg-nrs-requirements/ <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/ <https://datatracker.ietf.org/doc/draft-hong-icnrg-icnnrs/>
> 

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

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.

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

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

> 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 architect…

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

---

From: Jungha Hong <[email-masked]>
Date: Fri, 27 Jul 2018 08:35:24 +0000

Dear Lixia,

Let me try to answer to your questions as an author of the NRS drafts.

The projects metioned by chairs are no longer actively pursued.

But those projects were used to be representatives of ICN project and they all used NRS as a critical component.

In other words, those projects were not proposing NRS system itself. NRS was just utilized for their own purpose.

Although those projects are stoped, we can still reference them as ICN projects which used NRS as a componet.

I guess this is why the chairs mentioned those projects even though they are no longer pursued.

I would like to clarify the purpose of the two dafts here again.

We are not insisting to put NRS in ICN architecture.

We are discussing things that need to be considered when NRS is used as a component in ICN architecture for a certain reason.

In this context, I would like to ask ICNRGer to consider the adoption of the two drafts as the RG  documents.

Lixia, thanks for your comments.

Thanks,

Jungha Hong

________________________________
보낸 사람 : "Lixia Zhang" <[email-masked]>
보낸 날짜 : 2018-07-27 00:40:02 ( +09:00 )
받는 사람 : Börje Ohlman <[email-masked]>
참조 : icnrg <[email-masked]>, David Oran <[email-masked]>, Dirk Kutscher <[email-masked]>
제목 : Re: [icnrg] Moving NRS documents to RG documents

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

class="Apple-interchange-newline">
Based on the discussion at the ICNRG meeting in Montreal the chairs would like to propose to move the following documents to RG documents.

Llxiia

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 27 Jul 2018 08:36:53 +0000

Hi Lixia,

Comments in line.

C.

From: icnrg [mailto:[email-masked]] 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

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

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.

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.

Llxiia

---

From: Luca Muscariello <[email-masked]>
Date: Sun, 29 Jul 2018 15:36:46 +0200

I agree that the topic is important and central to this RG, as Cedric said,
and in favour of the adoption.
However I think that the first draft, which I read, needs quite a lot of
work to present requirements of NRS in the different use cases mentioned
therein,  in particular in terms of details and applicability.
But I'm sure this lack of work is an additional reason for this draft to be
adopted by the RG.

I did not read the second draft yet.

Luca

On Fri, Jul 27, 2018 at 10:37 AM Cedric Westphal <[email-masked]>
wrote:

> Hi Lixia,
>
>
>
> Comments in line.
>
>
>
> C.
>
>
>
> *From:* icnrg [mailto:[email-masked]] *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
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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
>
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>