Subject: [nmrg] call for adoption as RG document : draft-zhou-nmrg-digitaltwin-network-concepts

From: "Ciavaglia, Laurent" <[email-masked]>
Date: Fri, 10 Dec 2021 12:01:34 +0000

Dear NMRG,

This message starts the call for adoption as RG document for:
Digital Twin Network: Concepts and Reference Architecture - draft-zhou-nmrg-digitaltwin-network-concepts
https://datatracker.ietf.org/doc/draft-zhou-nmrg-digitaltwin-network-concepts/

Please let us know if you support or not the work becoming a RG document.
In all cases, provide detailed comments to support your opinion and send them on the mailing list.
We are particularly interested in assessing the following aspects:

  1.  NMRG being a *research* group it is important to articulate well the problem(s), challenge(s) and research questions.
  2.  Is the scientific soundness of the draft satisfying? (quality of the scientific proposition, rigor of the method, impact) ; "the measure of success is the quality and impact of the research results" [RFC2014]
  3.  As the document proposes an *architecture*, it is important to provide a clear scope and positioning of this architecture with respect to network management/automation/operation frameworks and where/how the proposed architecture will prove useful or aims at replacing/augmenting certain functionality

The procedure for RG document adoption and important criteria are detailed here: https://mailarchive.ietf.org/arch/msg/nmrg/CVEyLUvfxJk1Ud5WdM9Y5LGvQmU

Given the time of the year, this call for adoption is open for four weeks and ends on January 7th, 2022.

Best regards, NMRG chairs
Laurent & Jérôme

---

From: "maqiufang (A)" <[email-masked]>
Date: Mon, 13 Dec 2021 11:18:37 +0000

Hi, all
I have read the draft and support this work to become a RG document.
I believe that a common understanding of basic definition and architecture of digital twin networks is of great significance for the continuous research of digital twin.

I have one question regarding the reference architecture: do we allow the application layer to interact with physical network directly?
The user intent needs to be reflected into physical network after being tested/diagnosed on the virtual twin network, but do we allow applications to interact directly with the physical layer here?
Or do we think that physical network should only be controlled by digital twin network?

Best Regards,
Qiufang Ma

From: nmrg [mailto:[email-masked]] On Behalf Of Ciavaglia, Laurent
Sent: Friday, December 10, 2021 8:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: [nmrg] call for adoption as RG document : draft-zhou-nmrg-digitaltwin-network-concepts

Dear NMRG,

---

From: "Cheng Zhou" <[email-masked]>
Date: Tue, 14 Dec 2021 20:06:13 +0800

Hi Qiufang, 

Thanks for your support and good question.

Our understanding is that the application is using digital twin network layer to control the physical network indirectly. This way, control changes can be simulated and verified before being deployed onto physical network.

So, we think the application layer to interact with physical network directly is not in the scope of this draft.

Thanks and Best Regards,

Cheng Zhou 

发件人: nmrg [mailto:[email-masked]] 代表 maqiufang (A)
发送时间: 2021年12月13日 19:19
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [nmrg] call for adoption as RG document : draft-zhou-nmrg-digitaltwin-network-concepts

Hi, all

Best Regards,

Qiufang Ma

Dear NMRG,

2.       Is the scientific soundness of the draft satisfying? (quality of the scientific proposition, rigor of the method, impact) ; “the measure of success is the quality and impact of the research results” [RFC2014]

Laurent & Jérôme

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 17 Dec 2021 18:47:41 +0800

Hi All,

The draft proposes the conception, architecture, and scenarios of digitaltwin network, which is valuable to network measurement, and also meaningful to the evolution of the network.  

It has been discussed several times and is mature enough. So I support the adoption. 

Regards,
Peng Liu

[email-masked]
 
From: Ciavaglia, Laurent
Date: 2021-12-10 20:01
To: [email-masked]
CC: [email-masked]

Please let us know if you support or not the work becoming a RG document.
In all cases, provide detailed comments to support your opinion and send them on the mailing list.
We are particularly interested in assessing the following aspects:
NMRG being a *research* group it is important to articulate well the problem(s), challenge(s) and research questions. 
Is the scientific soundness of the draft satisfying? (quality of the scientific proposition, rigor of the method, impact) ; “the measure of success is the quality and impact of the research results” [RFC2014]
As the document proposes an *architecture*, it is important to provide a clear scope and positioning of this architecture with respect to network management/automation/operation frameworks and where/how the proposed architecture will prove useful or aims at replacing/augmenting certain functionality

---

From: "King, Daniel" <[email-masked]>
Date: Sat, 25 Dec 2021 00:07:58 +0000

Hi RG,

Having read the draft, I think it's a valuable work item for the RG, and I support the adoption of the I-D. However, significant work by the authors and input from the RG will be required, as expected with a recently adopted document.

In response to the questions posed:

Q1.  NMRG being a *research* group, it is important to articulate well the problem(s), challenge(s) and research questions.

Yes, but. The document would benefit from several significant updates that are proposed in more detail below.

Q2. Is the scientific soundness of the draft satisfying? (quality of the scientific proposition, rigor of the method, impact) ; "the measure of success is the quality and impact of the research results" [RFC2014]

Within reason. The document is informational and provides an overview of the digital twin network state of the art. It would benefit from resequencing sections and more academic research papers/journals that also cite common challenges. The authors discuss a broad set of use cases. It may be better to focus on one or two initially and go deeper in the discussion.

3.  As the document proposes an *architecture*, it is important to provide a clear scope and positioning of this architecture with respect to network management/automation/operation frameworks and where/how the proposed architecture will prove useful or aims at replacing/augmenting certain functionality.

I think the document's readability would be improved if the authors made the core requirements and research challenge more evident/earlier in the document, perhaps as research questions raised by the authors and citing other research (a few links provided below) that highlights challenges. Then when the authors present the architecture and functional components, they could may how it solves the specific challenges outlined earlier in the document.

Please find my specific comments and numerous editorial suggestions and questions below.

1. Introduction

Replace: "The fast growing of network scale and the increased demand placed on these networks, requires them to accommodate and adapt dynamically to customer needs, implying a big challenge to network operators."

With: "The fast growth of network scale and the increased demand placed on these networks require them to accommodate and adapt dynamically to customer needs, implying a significant challenge to network operators."

Replace: "Indeed, network operation and maintenance are becoming more complex due to the higher complexity of the managed networks and their sophisticated services."

With: "Indeed, network operation and maintenance are becoming more complex due to the higher complexity of the managed networks and their sophisticated services."

Replace: "full lifecycle and full business data-driven."

With: "full lifecycle and comprehensive business data-driven."

Replace: "The main difference compared to traditional network management system is the use of interactive virtual-real mapping to build closed-loop network automation."

With: "The main difference compared to traditional network management systems is interactive virtual-real mapping to build closed-loop network automation."

Replace: " Having an emulation platform that allows to reliably represent the state of a network is more dependable than a simulation platform."

With: " An emulation platform that highlights the state of network reliability provides a more helpful simulation platform."

Replace: " Service impact analysis tasks will also be facilitated."

With: " In addition, service impact analysis tasks will also be facilitated."

At this point, I just exported the text I-D into an MS Word document, enabled change markers and edited directly. I will provide this to the authors as an MS Word file.

2. Requirements Language

As an informational document, do you need to use specific requirement language? If you intend to have hard and soft requirements in future discussions, it may make more sense to keep this section.

3. Definitions and Acronyms

This section feels a little light given the various technology areas you discuss. Also, it only provides expanded acronym definitions, and I would think some definitions such as "digital twin" would also be helpful.

4. Definition of Digital Twin Network

The concept of "digital twin" predates 2003 (Michael Grieves). My understanding is "digital twin" was initially coined by NASA in the 1970s during the Apollo 13 program so that terrestrial engineers could model the extra-terrestrial effects on  Apollo 13 objects and systems. You might want to update your etymology and add a citation, such as "S. Ferguson, "Apollo 13: The First Digital Twin", Article by Siemens Blogs, April 14, 2020. https://blogs.sw.siemens.com/simcenter/apollo-13-the-first-digital-twin/"

Before you define "digital twin network", you might want to enlighten the readers about the "digital twin" concept. This might be a definition in section 3., or a paragraph in section 5 along the lines of:

"A digital twin is a virtual representation of the real-time digital counterpart, including physical objects, systems or processes. A digital twin is generated by gathering data and simulating the environment so that machine learning reasoning may be applied, often the entire lifecycle of the object or system is also represented."

<<

It may be useful to highlight the differences between a digital "model", "shadow" or " clone" of a system, and "digital twin". A key difference will be the direction of data between the physical and virtual systems. For instance, you might state:

"Typically, when using a digital twin the system is generated and then synchronized using data flows in both directions between physical and digital components, so that control data can be sent and changes between the physical and digital objectives and systems are automatically represented. This behavior is unlike a digital model, shadow or clone, which are synchronized manually,  lack control data, and will not have a full cycle of data integrated."

<<

This section then launches into the discussion of the "digital twin network". It proposes "Key Elements of Digital Twin Network" which on my initial readthrough, read like functional components, which then leads into architecture later in the document. It may be better to reorganise the document for the reader to clearly state the general problem scope, then research challenges and requirements not just in this document but also from other research papers. Then you can highlight your architecture and functional components as a way to address those research challenges.

Several journals refer to digital twin research challenges for specific vertical industries (with a focus on manufacturing and healthcare), I appreciate this document is focused on the telco network research, but it may be worth highlighting other research efforts as there seem to be several common challenges across technology areas. In addition, this document may benefit from a specific section on telco networking use cases, including smart cities and next generation infrastructure. Then you can summarise some of the more pertinent research challenges outlined in several documents I found relevant:

ITU-T Representative use cases and key network requirements for Network 2030

https://www.itu.int/en/ITU-T/focusgroups/net2030/Documents/Technical_Report.pdf

Digital Twin: Enabling Technologies, Challenges and Open Research

https://ieeexplore.ieee.org/abstract/document/9103025

Digital Twin: Values, Challenges and Enablers

https://arxiv.org/abs/1910.01719

Connecting the Twins: A Review on Digital Twin Technology & its Networking Requirements

https://www.sciencedirect.com/science/article/pii/S1877050921006694

Digital Twin: Values, Challenges and Enablers From a Modeling Perspective

https://ieeexplore.ieee.org/document/8972429

Digital Twin Technologies and Smart Cities

https://citations.springernature.com/book?doi=10.1007/978-3-030-18732-3

Smart Cities with Digital Twin Systems for Disaster Management

https://ascelibrary.org/doi/full/10.1061/%28ASCE%29ME.1943-5479.0000779

Realizing the Digital Twin Transition for Smart Cities

https://portal.dnb.de/opac.htm?method=simpleSearch&cqlMode=true&query=idn%3D1240130449

The Convergence of Digital Twin, IoT, and Machine Learning: Transforming Data into Action

https://link.springer.com/chapter/10.1007/978-3-030-18732-3_1

The Role of Digital Twin in Optical Communication: Fault Management, Hardware Configuration, and Transmission Simulation

https://ieeexplore.ieee.org/abstract/document/9356524

Digital Twin for 5G and Beyond

https://ieeexplore.ieee.org/abstract/document/9374645

Digital Twin in Industry 4.0: Technologies, Applications and Challenges

https://ieeexplore.ieee.org/abstract/document/8972134

Have you considered a section/sub-section on developing standards (use cases, requirements and architecture) efforts for digital twin network technologies?

Digital Twin Manufacturing Framework: https://www.iso.org/standard/75066.html

Focus Group on Technologies for Network 2030 (FG NET-2030): https://www.itu.int/en/ITU-T/focusgroups/net2030/Documents/Technical_Report.pdf

Joint Advisory Group (JAG) Group on Emerging Technology and Innovation (JETI) https://jtc1info.org/technology/advisory-groups/jeti/

Several recent technologies discussed in the IRTF/IETF are applicable digital twin networks. I think the document would benefit from a section on "Enabling Technologies" to support the proposed architecture and functional components. These advanced/recent technologies are related to:

- Network connectivity

- Real-time data communication, ultra-low latency and time-based networking

- Collaboration management, conflict detection and resolution

- Data privacy and integrity, trust and security

Indeed, several exciting research challenges exist for digital twin networking. Still, you might also document/cite recent implementations and highlight deficiencies, and in some cases, gaps are highlighted in the implementation documentation, such as:

Digital Twins for IoT Applications: A Comprehensive Approach to Implementing IoT Digital Twins

https://www.semanticscholar.org/paper/A-Comprehensive-Approach-to-Implementing-IoT-Twins/5d0482cf23a52da8cf7bf8be05e1e483dc296bf0

I hope these thoughts and suggestions are helpful.

BR, Dan.

From: nmrg <[email-masked]> On Behalf Of Ciavaglia, Laurent
Sent: 10 December 2021 12:02
To: [email-masked]
Cc: [email-masked]
Subject: [External] [nmrg] call for adoption as RG document : draft-zhou-nmrg-digitaltwin-network-concepts

This email originated outside the University. Check before clicking links or attachments.
Dear NMRG,

This message starts the call for adoption as RG document for:
Digital Twin Network: Concepts and Reference Architecture - draft-zhou-nmrg-digitaltwin-network-concepts
https://datatracker.ietf.org/doc/draft-zhou-nmrg-digitaltwin-network-concepts/<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhou-nmrg-digitaltwin-network-concepts%2F&data=04%7C01%7Ckingd%40live.lancs.ac.uk%7C52f2f1ce1a56405824ba08d9bbd4e2aa%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C0%7C637747346297798837%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=BVMByqjHFN0OKdWT3G5M4RrGL%2BaPZ1Bxorxn23xJ0hQ%3D&reserved=0>

The procedure for RG document adoption and important criteria are detailed here: https://mailarchive.ietf.org/arch/msg/nmrg/CVEyLUvfxJk1Ud5WdM9Y5LGvQmU<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fnmrg%2FCVEyLUvfxJk1Ud5WdM9Y5LGvQmU&data=04%7C01%7Ckingd%40live.lancs.ac.uk%7C52f2f1ce1a56405824ba08d9bbd4e2aa%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C0%7C637747346297798837%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Wz5A%2BUG2BTW97t746YhlsagW0fKebZUDtxyoLubkRuc%3D&reserved=0>

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 27 Dec 2021 11:11:09 +0000

Dear Laurent, all,

After reading the draft I support its adoption as RG document.

In respect to the points you raise, here are my views:

1.       NMRG being a *research* group it is important to articulate well the problem(s), challenge(s) and research questions.
This document clearly address a very relevant research topic which is the definition of network digital twin, as well as it proposes an initial architecture. In my view it is well stated, despite some aspects could be better clarified, as stated below when answering point 3.

I think so.

3.       As the document proposes an *architecture*, it is important to provide a clear scope and positioning of this architecture with respect to network management/automation/operation frameworks and where/how the proposed architecture will prove useful or aims at replacing/augmenting certain functionality
With respect to the propose architecture, I think it is a good proposition. However, I think some points need better clarification:

-          In page 5, in the first paragraph after the bullets it is mentioned that it is expected the DT to control the physical network. This is also reflected in the architecture figure by means of an specific control interface from the DT to the physical network. I think this control capability should be better explained, including scope, situations for that, etc. Is this control expected to happen with/without supervision? Is it directly interacting with the physical network elements, through a control element (maybe with some associated policies), etc?

-          After Figure 2, when describing options for physical networks, a number of non-IETF networks are enumerated. Not sure if we should limit the scope to IETF technologies in this sense, since those are the ones that the research of IRTF can influence directly.

-          When referring to base and functional models it would be nice to refer to existing IETF models that could exemplify the purpose of the DT architecture. This would help to understand the areas of future work, as well.

-          The architecture assumes a DT management entity, but the responsibilities of this entity are both: (1) managing the emulated nodes and (2) manage the overall DT. It would be probably better to separate these two roles on independent entities.

-          It is not clear if the physical network in the architecture contains both network elements and the control and managing entities acting on those elements. I assume yes, but some explicit statement in that respect would be beneficial.

-          The architecture assumes applications on top of the DT that could provide conventional OAM actions. This implies in my view the need of emulating as well the different NMSs/SDN controllers of the physical network that could be in place since the expectation would be to have similar integration in both the DT and the physical network. Is this the expectation in the draft?

Best regards,

Luis

De: nmrg <[email-masked]> En nombre de Ciavaglia, Laurent
Enviado el: viernes, 10 de diciembre de 2021 13:02
Para: [email-masked]
CC: [email-masked]
Asunto: [nmrg] call for adoption as RG document : draft-zhou-nmrg-digitaltwin-network-concepts

Dear NMRG,

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 27 Dec 2021 19:20:18 +0000

Hi all,

I support adoption of the document.  Articulation of the concepts and issues behind "digital twin networks" are an important relevant topic for management research and work item for NMRG and I would like to see the RG produce a corresponding document as output.

That said, I think in its current state, the document still needs improvement in a number of areas.  I am, however, willing to the give the document a benefit of a doubt as I view it as being still quite "early" and hence by the nature of things as somewhat immature.  For example, figure 1 has IMHO a key omission in that it does not depict the "original" of the twin.  Also, if research challenges are to be part of the document, then section 7 needs to be significantly expanded (too superficial for my taste, needs to e.g. elaborate more on the synchronization challenge of keeping the twins in sync, on the real-time challenge given the nature of distributed systems, propagation delays, and corresponding limitations of the problem that a DT network can address, issues and limits of emulation (and the degree to which you can mimic dynamic behaviors at the level of the DT) vs real-time compliance assessment with models, and more.

On the research side, the idea behind DT networks is reminiscent of earlier work from the 1990ies that should be referenced/acknowledged.  Examples include the Shadow MIB concept (implemented eg in the OSIMIS platform at the time), in which a representation of the network in a management platform was acted on by by applications, with active objects being responsible for their synchronization, similarly Inductive Modeling Technique (as implemented by Cabletron Spectrum at the time), presumably also references from the the TMN and ISO/OSI management arena.

With that, responses to the questions inline, <ALEX>

--- Alex

From: nmrg <[email-masked]> On Behalf Of Ciavaglia, Laurent
Sent: Friday, December 10, 2021 4:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: [nmrg] call for adoption as RG document : draft-zhou-nmrg-digitaltwin-network-concepts

Dear NMRG,

This message starts the call for adoption as RG document for:
Digital Twin Network: Concepts and Reference Architecture - draft-zhou-nmrg-digitaltwin-network-concepts
https://datatracker.ietf.org/doc/draft-zhou-nmrg-digitaltwin-network-concepts/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhou-nmrg-digitaltwin-network-concepts%2F&data=04%7C01%7Calex%40futurewei.com%7C0e064bc4bd9145988ae808d9bbd4da68%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637747345168002596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=akA6wURdYwMLvDoFWt%2B9U3QQ2Rs6qT%2F79VUWaJEhoVM%3D&reserved=0>

Please let us know if you support or not the work becoming a RG document.
<ALEX> Yes, I support </ALEX>
In all cases, provide detailed comments to support your opinion and send them on the mailing list.
We are particularly interested in assessing the following aspects:

  1.  NMRG being a *research* group it is important to articulate well the problem(s), challenge(s) and research questions.
<ALEX> If it is to address research questions, this should probably be reflected in title or abstract.  The topic is certainly relevant for research and IMHO appropriate for NMRG to tackle. </ALEX>

  1.  Is the scientific soundness of the draft satisfying? (quality of the scientific proposition, rigor of the method, impact) ; "the measure of success is the quality and impact of the research results" [RFC2014]
<ALEX> As mentioned earlier, references to previous work need to be expanded on.  Section 7, which discusses key challenges, is at the moment still underdeveloped and will need to be significantly expanded. </ALEX>

  1.  As the document proposes an *architecture*, it is important to provide a clear scope and positioning of this architecture with respect to network management/automation/operation frameworks and where/how the proposed architecture will prove useful or aims at replacing/augmenting certain functionality
<ALEX> I think the architecture that is described is clear enough, will be useful, and provides a sufficient basis for going forward.</ALEX>

The procedure for RG document adoption and important criteria are detailed here: https://mailarchive.ietf.org/arch/msg/nmrg/CVEyLUvfxJk1Ud5WdM9Y5LGvQmU<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fnmrg%2FCVEyLUvfxJk1Ud5WdM9Y5LGvQmU&data=04%7C01%7Calex%40futurewei.com%7C0e064bc4bd9145988ae808d9bbd4da68%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637747345168002596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=s6O633naLQfEhLNxsE5%2F0GgiipKy0AZ6GDFsQZ2jBLY%3D&reserved=0>

---

From: "Cheng Zhou" <[email-masked]>
Date: Fri, 31 Dec 2021 23:38:08 +0800

Hi Alex, 

Thank you very much for your valuable comments. 

Please check  my initial reply inline. We will update the draft later after in-depth study on your comments. 

Best  Regards,

Cheng Zhou (on behalf of authors)

发件人: nmrg [mailto:[email-masked]] 代表 Alexander Clemm
发送时间: 2021年12月28日 03:20
收件人: Ciavaglia, Laurent; [email-masked]
抄送: [email-masked]
主题: Re: [nmrg] call for adoption as RG document : draft-zhou-nmrg-digitaltwin-network-concepts

Hi all,

I support adoption of the document.  Articulation of the concepts and issues behind “digital twin networks” are an important relevant topic for management research and work item for NMRG and I would like to see the RG produce a corresponding document as output.  

That said, I think in its current state, the document still needs improvement in a number of areas.  I am, however, willing to the give the document a benefit of a doubt as I view it as being still quite “early” and hence by the nature of things as somewhat immature.  For example, figure 1 has IMHO a key omission in that it does not depict the “original” of the twin.  Also, if research challenges are to be part of the document, then section 7 needs to be significantly expanded (too superficial for my taste, needs to e.g. elaborate more on the synchronization challenge of keeping the twins in sync, on the real-time challenge given the nature of distributed systems, propagation delays, and corresponding limitations of the problem that a DT network can address, issues and limits of emulation (and the degree to which you can mimic dynamic behaviors at the level of the DT) vs real-time compliance assessment with models, and more.  

<Authors> Accept your suggestion. We will revise the draft in next version via 1) describing more on the ‘original’ of the twin, and 2) expending research challenges. 

<Authors> Thanks for the information. We will study the mentioned earlier techniques related to digital twin network, then revise the draft via referring more in related section (e.g. either introduction section) 

--- Alex

Dear NMRG,

https://datatracker.ietf.org/doc/draft-zhou-nmrg-digitaltwin-network-concepts/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhou-nmrg-digitaltwin-network-concepts%2F&data=04%7C01%7Calex%40futurewei.com%7C0e064bc4bd9145988ae808d9bbd4da68%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637747345168002596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=akA6wURdYwMLvDoFWt%2B9U3QQ2Rs6qT%2F79VUWaJEhoVM%3D&reserved=0> 

<Authors> Accept your suggestion and will revise in next version.

<Authors> Accept your suggestion and will revise in next version.

The procedure for RG document adoption and important criteria are detailed here: https://mailarchive.ietf.org/arch/msg/nmrg/CVEyLUvfxJk1Ud5WdM9Y5LGvQmU <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fnmrg%2FCVEyLUvfxJk1Ud5WdM9Y5LGvQmU&data=04%7C01%7Calex%40futurewei.com%7C0e064bc4bd9145988ae808d9bbd4da68%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637747345168002596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=s6O633naLQfEhLNxsE5%2F0GgiipKy0AZ6GDFsQZ2jBLY%3D&reserved=0> 

Laurent & Jérôme