Subject: [Qirg] Review of draft-irtf-qirg-principles-02

From: VAN DEN BOSSCHE Mathias <[email-masked]>
Date: Mon, 9 Dec 2019 09:48:56 +0000

Dear all,

I did some review work of draft-irtf-qirg-principles-02. The document is really well done, and the effort to
non quantum readers is visible (and appreciated, even by a QFT-background guy like me).

I introduce below (in basic ascii mode) a number of proposed changes/comments/questions to be discussed.
Some are typos, some a clarifications, few are more fundamental.
The idea is to fill the 'Discussion' and 'Decision' fields for each point.

I let you go through it. We could maybe set a date to close this.

All the best !

Mathias

====

Doc: draft-irtf-qirg-principles-02

ID : MVDB 01

Page/section: p 6/ § 3

Proposal/Question:
I would change the title of §3 to _Entanglement as the
fundamental resource_

Explanation:
The fact is that a service is an action, while a resource
is something you can create, quantify and manage. There is
a targeted service is to "distribute entanglement". BTW
the document mentions entanglement as a resource §§ 4.4.2.1
and 5.6.1, so that would improve consistency.

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 02

Page/section: p 7/ § 3

Proposal/Question:
than -> then line 9 of p 7

Explanation:
typo

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 03

Page/section: p 9/ § 4.2

Proposal/Question:
change
Any of the four Bell pair state above will do as it is
possible ....
to
Any of the four Bell-pair states above will do, as it
is possible ....

Explanation:
typo + some clarity

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 04

Page/section: p 10 / § 4.3 (last 3 lines)

Proposal/Question:

change
The unknown quantum state that was transmitted never entered the
network itself. Therefore, the network needs to only be able to
reliably produce Bell pairs between any two nodes in the network.

to
change
The unknown quantum state that was transmitted was never fed into
network itself. Therefore, the network needs to only be able to
reliably produce Bell pairs between any two nodes in the network,
and perform BSM with external qbits to be transmitted.

Explanation:
* It is a delicate concept to explain that the network is here only
to create a direct end-to-end link, which is then used directly
by the end nodes without having the intermediate nodes to handle it.
* The interface function (the BSM with external qbits) I think is
still part of the network and should not be forgotten

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 05

Page/section: p 10 / § 4.4.1

Proposal/Question:

The title could be _4.4.1 _Elementary link generation_ instead.

The expected contribution should include at least 3 main parts
* Create the BPS
* Store the entangled members of non-local BPS
* Monitor the entanglement resource level on each link

Explanation
The other aspects of entanglement life cycle are well described
in the subsequent sections, it looks like this one is dedicated
to elementary links, right?
Everyone will have in mind the function to create BPS across the
elementary links, but we should first not forget the fact that
they need be stored (esp. in the light of the asynchronous use
mentioned further in the document). And then this stored entanglement
will be the resource to be monitored on each elementary link,
because it will be consumed and it will expire (by decoherence).
Monitoring will detect low levels and trigger regeneration.

Can we agree on that before developing further?

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 07

Page/section: p 11 / § 4.4.2

Proposal/Question:

Augment

The problem with generating entangled pairs directly across a link is
that its efficiency decreases with its length. Beyond a few 10s of
kms the rate is effectively zero and due to the no-cloning theorem we
cannot simply amplify the signal. The solution is entanglement
swapping.
with

The problem with generating entangled pairs directly across a link is
that its efficiency decreases with its length. Beyond a few 10s of
kms in optical fibre or 1000s of kms in free space [ESA, Micius], the
rate is effectively zero and due to the no-cloning theorem we cannot
simply amplify the signal. The solution to propagate entanglement at
large distances is entanglement swapping.

Explanation:

The two kinds of links (fibre & free space) shall be mentioned for
completeness. They are not competing, rather complementary, and both
will require swapping and routing devices anyway. Free-space to satellites
will allow having fewer nodes on the path, the goal being to improve
capacity.

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 08

Page/section: p 12 / § 4.4.2

Proposal/Question:

Add at the end of the section:
<<
Entanglement swapping allows entanglement to exist at larger distances
than what the entangled degrees of freedom can propagate. Yet one should
keep in mind that the capacity of the network still decreases with the
number of swapping nodes (all other parameters being kept fixed). So
entanglement swapping solves the problem of existence of long distance
entanglement, but not that of performance of the end-to-end link.

Explanation:
This
- clarifies the role of entanglement swapping in the network as a system
- allows identifying different way of attacking the problem of performance.

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 09

Page/section: p 12 / § 4.4.2.2

Proposal/Question:

Change

2. An identifier that allows the application to unambiguously
determine which qubits at the two end-points belong to which
entangled pair.

to

2. An identifier that allows the applicatqion to unambiguously
determine which qubits at the two end-points belong to which
entangled pair (including end-point identification).

Explanation:
For more clarity

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 10

Page/section: p 12 / § 4.4.2.2

Proposal/Question:

Add

4. An estimate of the expiry date of the BSP.

Explanation:

It might not be relevant in the first networks where decoherence
will require fast consumption of the created entanglement resource,
but we hope that this constraint will be relaxed, and that this
will become a relevant network management information.

Alternatively create a §4.4.2.3 on entanglement storage

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 11

Page/section: p 13ff / § 5

Proposal/Question:

>From that point on, the document mentions abundantly the term of
'repeaters'. I recommend to give it up and use a more accurate term
such as swapper or router (that are introduced in the document) or
propagator (that's my QFT background).

Explanation

I know the term is pretty much used already, but here is my argument.

Although it is a convenient term for those who have a classical
network background (where it is fairly transparent), it is abusive
in the case of entanglement networks. The fact is that nothing is
repeated, it is just blank entanglement that is forwarded, swapped,
propagated commuted (as in the old telephone systems where an operator
had to plug a wire between two lines nodes to connect two network
segments and allow an end-to-end line to exist). It repeats no data
(as the considerations at the end of the document insist on).

Using the term of repeater is confusing, and leads to wrong understanding
and then inadequate decisions.

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 12

Page/section: p 14 / § 5.1 (3.)

Proposal/Question:

Change

This implies ... store temporary state as the ...

to

This implies ... store the received temporary state as the ...

Explanation:

If I understand the sentence right.

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 14

Page/section: p 18 / § 5.5.1

Proposal/Question:

Change

"The memory lifetime depends on the particular physical setup, but the
highest achievable values currently are on the order of seconds."

to

"The memory lifetime depends on the particular physical setup. This
is object of intense research. Current setups achieve lifetime
up to the order of seconds, but promising approaches should allow a
significant expansion of this value"

Explanation:

I came across a paper [Nature _517_, 177 (2015)]  that claimed
6h coherence time with Europium ion spins that are "optically addressable".
Since I am no experimentalist, I do not know what intricacies this
setup might require. I do not know either whether this result is
object of controversy. But if this is not the case, I would suggest
changing the text to something less hard on memory lifetimes.

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 15

Page/section: p 18 (and 19) / § 5.5.1 (and 5.5.2)

Proposal/Question:

Explain why it might be more cost efficient to use short lifetimes.

Explanation:

It might be a valid choice, but it deserves motivation. Do not
forget that anything expensive produced in mass figures becomes
inexpensive.

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 16

Page/section: p 18 / § 5.5.2

Proposal/Question:

It is not clear what the mentioned success rate of 1e-3 addresses.
I understand it is the rate of success to create a BPS by pumping
a non-linear crystal with a suitable pump. Is it this? Or is it
the probability that BSM effectively entangles 2 BPS? Or is it
something else?

It is tempting with this figure to compute the capacity of an
n-hop path. But is they the correct needed information?

Explanation:

See above

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 17

Page/section: p 21 / § 5.6.1 (5.)

Proposal/Question:

I propose to remove the considerations on QKD, or at least
to reduce them drastically.

Explanation:

There might be other solutions to secure the control plane other
than QKD. It is true that once optical links are available, it
is tempting to implement QKD protocols, but is it the right moment
to highlight a particular solution?

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 18

Page/section: p 22 / § 5.6.2 (3.)

Proposal/Question:

Change

"This point is crucial in enabling the reuse of resources of a
network and (...)"

to

"This point is crucial in optimising the use of entanglement
resources of a network and (...)"

Explanation:

If I understand right, this is clearer.

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 19

Page/section: p 24 / § 5.6.2 (6.)

Proposal/Question:

Question : do you consider parallelising over the same path with
e.g. multiplexed optical channels, or do you consider also
parallelising over different paths? In which case it could be
mentioned.

Explanation:

N/A

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 20

Page/section: p 24 / § 5.6.2 (7.)

Proposal/Question:

I would suggest giving synchronisation accuracy needs here.
Not necessarily the figure but a least the relationship
with the source rate etc.

Explanation:

This would allow assessing what is feasible and what is not.
At some point, synchronisation may be much more demanding than
what you can do with GNSS (~ 0.1 ns). As a matter of fact, the
network its might become itself a big machine to measure the
metric of space time on Earth...

Discussion:

TBD

Decision:

TBD

---

Doc: draft-irtf-qirg-principles-02

ID : MVDB 21
Page/section: p 24 / § 6

Proposal/Question:

Change

"Even though no user data enters a quantum network security is listed
as an explicit goal (...)"

to

"Even though no user data enters a quantum network, security is listed
as an explicit goal (...)"

Explanation:

Typo

Discussion:

TBD

Decision:

TBD

[@@ THALES ALENIA SPACE INTERNAL @@]

---

From: Gelard Patrick <[email-masked]>
Date: Thu, 12 Dec 2019 13:39:43 +0000

Hello Mathias,

Proposal/Question:

Explanation

Discussion:

Doesn't that close the door of all-photonic quantum "repeater" : https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201907sr3.html - Experimental quantum repeater without quantum memory : https://www.nature.com/articles/s41566-019-0468-5 ?
Quantum repeaters-important components of a scalable quantum internet-enable entanglement to be distributed over long distances. The standard paradigm for a quantum repeater relies on the necessary, demanding requirement of quantum memory. Despite significant progress, the limited performance of quantum memory means that making practical quantum repeaters remains a challenge. Remarkably, a proposed all-photonic quantum repeater avoids the need for quantum memory by harnessing the graph states in the repeater nodes. Here we perform an experimental demonstration of an all-photonic quantum repeater.

Rodney Van Meter wrote : An interesting question is whether nodes can be transmit-only, without memory.

A+
/Patrick

De : Qirg <[email-masked]> De la part de VAN DEN BOSSCHE Mathias
Envoyé : lundi 9 décembre 2019 10:49
À : [email-masked]
Objet : [Qirg] Review of draft-irtf-qirg-principles-02

Dear all,

All the best !

Mathias

====

ID : MVDB 01

Page/section: p 6/ § 3

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 02

Page/section: p 7/ § 3

Proposal/Question:

Explanation:
typo

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 03

Page/section: p 9/ § 4.2

Proposal/Question:
change

Explanation:
typo + some clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 04

Proposal/Question:

change

to
change

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 05

Proposal/Question:

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 07

Proposal/Question:

Augment

with

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 08

Proposal/Question:

Explanation:
This

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 09

Proposal/Question:

Change

to

Explanation:
For more clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 10

Proposal/Question:

Add

Explanation:

Alternatively create a §4.4.2..3 on entanglement storage

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 11

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 12

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 14

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 15

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 16

Proposal/Question:

Explanation:

See above

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 17

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 18

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 19

Proposal/Question:

Explanation:

N/A

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 20

Proposal/Question:

Explanation:

metric of space time on Earth....

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 21
Page/section: p 24 / § 6

Proposal/Question:

Change

to

Explanation:

Typo

Discussion:

TBD

Decision:

TBD

---

From: Rodney Van Meter <[email-masked]>
Date: Fri, 13 Dec 2019 15:41:15 +0900

Mathias, thanks for the feedback!  Much appreciated.  We’ll make sure the comments get addressed.

We definitely want to keep all-photonic implementations in the loop.

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
[email-masked]

> On Dec 12, 2019, at 22:39, Gelard Patrick <[email-masked]> wrote:
> 
> Hello Mathias,
>  
> Proposal/Question: 
>  
> Doesn't that close the door of all-photonic quantum “repeater” : https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201907sr3.html <https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201907sr3.html> - Experimental quantum repeater without quantum memory : https://www.nature.com/articles/s41566-019-0468-5 <https://www.nature.com/articles/s41566-019-0468-5>?
> Quantum repeaters—important components of a scalable quantum internet—enable entanglement to be distributed over long distances. The standard paradigm for a quantum repeater relies on the necessary, demanding requirement of quantum memory. Despite significant progress, the limited performance of quantum memory means that making practical quantum repeaters remains a challenge. Remarkably, a proposed all-photonic quantum repeater avoids the need for quantum memory by harnessing the graph states in the repeater nodes. Here we perform an experimental demonstration of an all-photonic quantum repeater.
>  
> The idea is to fill the ‘Discussion’ and ‘Decision’ fields for each point.
>  
> Alternatively create a §4.4.2...3 on entanglement storage
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> metric of space time on Earth.....
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg

---

From: VAN DEN BOSSCHE Mathias <[email-masked]>
Date: Fri, 13 Dec 2019 07:52:59 +0000

Dear Patrick, dear all,

Indeed I understand too, that memories are not necessary for ultra fast fully synchronized all phtonics repeaters.
This means that there might be optional and mandatory features, to be standardized as such. Memory would then be mandatory.
The truth is that I am contaminated by the satellite link case where memories should bridge link availability gaps.

Have a nice day

Mathias

De : Gelard Patrick [mailto:[email-masked]]
Envoyé : jeudi 12 décembre 2019 14:40
À : VAN DEN BOSSCHE Mathias; [email-masked]
Objet : RE: Review of draft-irtf-qirg-principles-02

Hello Mathias,

Proposal/Question:

Explanation

Discussion:

A+
/Patrick

De : Qirg <[email-masked]<mailto:[email-masked]>> De la part de VAN DEN BOSSCHE Mathias
Envoyé : lundi 9 décembre 2019 10:49
À : [email-masked]<mailto:[email-masked]>
Objet : [Qirg] Review of draft-irtf-qirg-principles-02

Dear all,

All the best !

Mathias

====

ID : MVDB 01

Page/section: p 6/ § 3

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 02

Page/section: p 7/ § 3

Proposal/Question:

Explanation:
typo

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 03

Page/section: p 9/ § 4.2

Proposal/Question:
change

Explanation:
typo + some clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 04

Proposal/Question:

change

to
change

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 05

Proposal/Question:

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 07

Proposal/Question:

Augment

with

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 08

Proposal/Question:

Explanation:
This

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 09

Proposal/Question:

Change

to

Explanation:
For more clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 10

Proposal/Question:

Add

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 11

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 12

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 14

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 15

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 16

Proposal/Question:

Explanation:

See above

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 17

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 18

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 19

Proposal/Question:

Explanation:

N/A

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 20

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 21
Page/section: p 24 / § 6

Proposal/Question:

Change

to

Explanation:

Typo

Discussion:

TBD

Decision:

TBD

---

From: Gelard Patrick <[email-masked]>
Date: Fri, 13 Dec 2019 08:54:32 +0000

Dear Mathias,

I don't think that the goal of the irtf-girg-principle document is to make requirement (should ..., must ...) concerning the artitecture of a quantum internet.  Satellite can be use in different use case even this one : Entanglement over global distances via quantum repeaters with satellite links - https://arxiv.org/abs/1410.5384.

The main concept, behind all-photonic quantum repeater, is analogous to the idea behind measurement-based quantum computation. In time-reversal scenario one can reverse the order of the measurements, what can perhaps be used to limit synchronization constraint. It seems to me that there is still a lot of research to be done before closing the doors too early .
Thus, In a document whose purpose is to set out high-level principles, should such a requirement (mandatory) about memory be included ?

Best regards
/Patrick

De : VAN DEN BOSSCHE Mathias <[email-masked]>
Envoyé : vendredi 13 décembre 2019 08:53
À : Gelard Patrick <[email-masked]>
Cc : [email-masked]
Objet : RE: Review of draft-irtf-qirg-principles-02

Dear Patrick, dear all,

Have a nice day

Mathias

De : Gelard Patrick [mailto:[email-masked]]
Envoyé : jeudi 12 décembre 2019 14:40
À : VAN DEN BOSSCHE Mathias; [email-masked]<mailto:[email-masked]>
Objet : RE: Review of draft-irtf-qirg-principles-02

Hello Mathias,

Proposal/Question:

Explanation

Discussion:

A+
/Patrick

Dear all,

All the best !

Mathias

====

ID : MVDB 01

Page/section: p 6/ § 3

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 02

Page/section: p 7/ § 3

Proposal/Question:

Explanation:
typo

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 03

Page/section: p 9/ § 4.2

Proposal/Question:
change

Explanation:
typo + some clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 04

Proposal/Question:

change

to
change

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 05

Proposal/Question:

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 07

Proposal/Question:

Augment

with

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 08

Proposal/Question:

Explanation:
This

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 09

Proposal/Question:

Change

to

Explanation:
For more clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 10

Proposal/Question:

Add

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 11

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 12

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 14

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 15

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 16

Proposal/Question:

Explanation:

See above

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 17

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 18

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 19

Proposal/Question:

Explanation:

N/A

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 20

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 21
Page/section: p 24 / § 6

Proposal/Question:

Change

to

Explanation:

Typo

Discussion:

TBD

Decision:

TBD

---

From: VAN DEN BOSSCHE Mathias <[email-masked]>
Date: Fri, 13 Dec 2019 08:54:46 +0000

Sorry memory would then be _optional_ !

Mathias

De : Qirg [mailto:[email-masked]] De la part de VAN DEN BOSSCHE Mathias
Envoyé : vendredi 13 décembre 2019 08:53
À : Gelard Patrick
Cc : [email-masked]
Objet : Re: [Qirg] Review of draft-irtf-qirg-principles-02

Dear Patrick, dear all,

Have a nice day

Mathias

Hello Mathias,

Proposal/Question:

Explanation

Discussion:

A+
/Patrick

Dear all,

All the best !

Mathias

====

ID : MVDB 01

Page/section: p 6/ § 3

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 02

Page/section: p 7/ § 3

Proposal/Question:

Explanation:
typo

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 03

Page/section: p 9/ § 4.2

Proposal/Question:
change

Explanation:
typo + some clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 04

Proposal/Question:

change

to
change

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 05

Proposal/Question:

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 07

Proposal/Question:

Augment

with

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 08

Proposal/Question:

Explanation:
This

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 09

Proposal/Question:

Change

to

Explanation:
For more clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 10

Proposal/Question:

Add

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 11

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 12

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 14

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 15

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 16

Proposal/Question:

Explanation:

See above

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 17

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 18

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 19

Proposal/Question:

Explanation:

N/A

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 20

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 21
Page/section: p 24 / § 6

Proposal/Question:

Change

to

Explanation:

Typo

Discussion:

TBD

Decision:

TBD

---

From: VAN DEN BOSSCHE Mathias <[email-masked]>
Date: Fri, 13 Dec 2019 08:58:25 +0000

Agreed - I mean : I understand that this orientation document is not a normative one - but rather the support for a discussion of what could be the normative document content. This is why I identify two kinds of requirements (mandatory/optional). Nothing more at this time - especially not yet what is mandatory or optional!

De : Gelard Patrick [mailto:[email-masked]]
Envoyé : vendredi 13 décembre 2019 09:55
À : VAN DEN BOSSCHE Mathias
Cc : [email-masked]
Objet : RE: Review of draft-irtf-qirg-principles-02

Dear Mathias,

Best regards
/Patrick

De : VAN DEN BOSSCHE Mathias <[email-masked]<mailto:[email-masked]>>
Envoyé : vendredi 13 décembre 2019 08:53
À : Gelard Patrick <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: Review of draft-irtf-qirg-principles-02

Dear Patrick, dear all,

Have a nice day

Mathias

Hello Mathias,

Proposal/Question:

Explanation

Discussion:

A+
/Patrick

Dear all,

All the best !

Mathias

====

ID : MVDB 01

Page/section: p 6/ § 3

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 02

Page/section: p 7/ § 3

Proposal/Question:

Explanation:
typo

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 03

Page/section: p 9/ § 4.2

Proposal/Question:
change

Explanation:
typo + some clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 04

Proposal/Question:

change

to
change

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 05

Proposal/Question:

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 07

Proposal/Question:

Augment

with

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 08

Proposal/Question:

Explanation:
This

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 09

Proposal/Question:

Change

to

Explanation:
For more clarity

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 10

Proposal/Question:

Add

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 11

Explanation

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 12

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 14

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 15

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 16

Proposal/Question:

Explanation:

See above

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 17

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 18

Proposal/Question:

Change

to

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 19

Proposal/Question:

Explanation:

N/A

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 20

Proposal/Question:

Explanation:

Discussion:

TBD

Decision:

TBD

---

ID : MVDB 21
Page/section: p 24 / § 6

Proposal/Question:

Change

to

Explanation:

Typo

Discussion:

TBD

Decision:

TBD