Subject: [ippm] Warren Kumari's No Objection on draft-ietf-ippm-alt-mark-13: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Tue, 28 Nov 2017 14:37:52 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-ippm-alt-mark-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Firstly, I'd strongly suggest that the authors address Eric's OpsDir review
(https://datatracker.ietf.org/doc/review-ietf-ippm-alt-mark-13-opsdir-telechat-vyncke-2017-11-21/).

I really like the concept / approach, but I think that there are many places
where the document hand-waves away some of the details - like how do I
configure this (and more importantly, how do I detect) so that I'm not making
in too many places, and having one device stomp on another devices' markings?
Section 3.1.1 says that it is desirable to have a single node coloring -- is
this supposed to mean a single node *per network* (which makes this useless)?
Or somehow per flow (then how do I know who's the right device to mark?)
Perhaps devices should watch for already colored packets if they are intending
to color, and alert on this case as an error?

More operational guidance would go a long way towards making this more
operational useful - as this is Experimental I'm not making this a discuss.

I had some comments and questions:
1: The document lists 8 authors above the fold. This may be must better as an
Editor (or two) and the rest moved to contributors.

2: The document is Experimental, but I don't really see (perhaps I missed it) a
description of the experiment to be performed -- Section 5.1 has a writeup of
experience gained from running this at TI, but that seems more like a separate
Informational document.

Nits:
Section 1.  Introduction
"The lack of adequate tools to measure packet loss with the desired accuracy
drove an effort to design a new method for the performance monitoring of live
traffic, possibly easy to implement and deploy." -- did you mean "possibly"
here? This makes it sound like having it easy to implement and deploy isn't a
goal/ desirable, more like a lucky coincidence if it happens...

Section 1.  Introduction
"In case the marking field is obtained by changing existing field values of" 
-- perhaps: "In cases where the marking..."? Actually, this whole sentence
feels a bit clumsy.

Section 2.  Overview of the method
"Since a flow is continuous and cannot be stopped when a counter has to be
read, it could be difficult to determine exactly when to read the counter. " --
I think that this would be better if it were "it can be difficult" or "it would
be difficult".

Section 3.1.  Packet loss measurement
"Traffic coloring could be done by R1 itself or by an upward router." -- what
is an "upward" router? Was this supposed to be upstream? Even if so, I think
that there needs to be more precision here.

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 29 Nov 2017 17:26:14 +0000

Hi Warren,
Thank you for your opinion of the document and for your comments.
See my answers inline tagged as [GF].

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: Warren Kumari [mailto:[email-masked]] 
Inviato: martedì 28 novembre 2017 23:38
A: The IESG
Cc: [email-masked]; Carlos Pignataro; [email-masked]; [email-masked]; [email-masked]
Oggetto: Warren Kumari's No Objection on draft-ietf-ippm-alt-mark-13: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Firstly, I'd strongly suggest that the authors address Eric's OpsDir review (https://datatracker.ietf.org/doc/review-ietf-ippm-alt-mark-13-opsdir-telechat-vyncke-2017-11-21/).

[GF]: Ok, I will double check but the comments from Eric should be addressed in -13 version

I really like the concept / approach, but I think that there are many places where the document hand-waves away some of the details - like how do I configure this (and more importantly, how do I detect) so that I'm not making in too many places, and having one device stomp on another devices' markings?
Section 3.1.1 says that it is desirable to have a single node coloring -- is this supposed to mean a single node *per network* (which makes this useless)?

[GF]: Agree, this is per flow not per network.

Or somehow per flow (then how do I know who's the right device to mark?) Perhaps devices should watch for already colored packets if they are intending to color, and alert on this case as an error?

[GF]: the right device designated for marking can be established by the filter criteria used to select the flow we want to measure.

More operational guidance would go a long way towards making this more operational useful - as this is Experimental I'm not making this a discuss.

I had some comments and questions:
1: The document lists 8 authors above the fold. This may be must better as an Editor (or two) and the rest moved to contributors.

2: The document is Experimental, but I don't really see (perhaps I missed it) a description of the experiment to be performed -- Section 5.1 has a writeup of experience gained from running this at TI, but that seems more like a separate Informational document.

[GF]: This can be discussed, also in my view the scope can be more than experimental

Nits:
Section 1.  Introduction
"The lack of adequate tools to measure packet loss with the desired accuracy drove an effort to design a new method for the performance monitoring of live traffic, possibly easy to implement and deploy." -- did you mean "possibly"
here? This makes it sound like having it easy to implement and deploy isn't a goal/ desirable, more like a lucky coincidence if it happens...

[GF]: Agree "possibly" can be omitted

Section 1.  Introduction
"In case the marking field is obtained by changing existing field values of" 
-- perhaps: "In cases where the marking..."? Actually, this whole sentence feels a bit clumsy.

[GF]: Agree, this paragraph can be moved later in the document

Section 2.  Overview of the method
"Since a flow is continuous and cannot be stopped when a counter has to be read, it could be difficult to determine exactly when to read the counter. " -- I think that this would be better if it were "it can be difficult" or "it would be difficult".

[GF]: Agree

Section 3.1.  Packet loss measurement
"Traffic coloring could be done by R1 itself or by an upward router." -- what is an "upward" router? Was this supposed to be upstream? Even if so, I think that there needs to be more precision here.

[GF]: Agree, "upward" is not necessary here

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 29 Nov 2017 13:36:37 -0600

I'm chiming in on one point, because I'm confused.

On Wed, Nov 29, 2017 at 11:26 AM, Fioccola Giuseppe <
[email-masked]> wrote:

> Cc: [email-masked]; Carlos Pignataro;
> [email-masked]; [email-masked]; [email-masked]
> Firstly, I'd strongly suggest that the authors address Eric's OpsDir
> review (https://datatracker.ietf.org/doc/review-ietf-ippm-alt-mark-
> 13-opsdir-telechat-vyncke-2017-11-21/).
>
> I really like the concept / approach, but I think that there are many
> places where the document hand-waves away some of the details - like how do
> I configure this (and more importantly, how do I detect) so that I'm not
> making in too many places, and having one device stomp on another devices'
> markings?
> Section 3.1.1 says that it is desirable to have a single node coloring --
> is this supposed to mean a single node *per network* (which makes this
> useless)?
>
> Perhaps devices should watch for already colored packets if they are
> intending to color, and alert on this case as an error?
>
> [GF]: the right device designated for marking can be established by the
> filter criteria used to select the flow we want to measure.
>
> 1: The document lists 8 authors above the fold. This may be must better as
> an Editor (or two) and the rest moved to contributors.
>
> 2: The document is Experimental, but I don't really see (perhaps I missed
> it) a description of the experiment to be performed -- Section 5.1 has a
> writeup of experience gained from running this at TI, but that seems more
> like a separate Informational document.
>

I'm not quite sure what Giuseppe is thinking here, but if "more than
experimental" means anything like "standards track", that's a conversation
we should have REALLY quickly.

https://tools.ietf.org/html/rfc2026#section-6.1.2 says that if this
document was Last Called as Experimental, approving it as Standards Track
requires a second IETF Last Call calling out the new Category, so would
need to slip from this week's telechat agenda.

We can process BCPs and Standards Track documents as Informational,
Experimental, or Historic without another Last Call, but we can't go the
other way.

So, please advise!

If I'm misunderstanding, that's also a fine response ...

Spencer

> Nits:
> Section 1.  Introduction
> "The lack of adequate tools to measure packet loss with the desired
> accuracy drove an effort to design a new method for the performance
> monitoring of live traffic, possibly easy to implement and deploy." -- did
> you mean "possibly"
> here? This makes it sound like having it easy to implement and deploy
> isn't a goal/ desirable, more like a lucky coincidence if it happens...
>
> read, it could be difficult to determine exactly when to read the counter.
> " -- I think that this would be better if it were "it can be difficult" or
> "it would be difficult".
>
> [GF]: Agree
>
> "Traffic coloring could be done by R1 itself or by an upward router." --
> what is an "upward" router? Was this supposed to be upstream? Even if so, I
> think that there needs to be more precision here.
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Nov 2017 14:47:00 -0500

On Wed, Nov 29, 2017 at 2:36 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
> On Wed, Nov 29, 2017 at 11:26 AM, Fioccola Giuseppe
> <[email-masked]> wrote:
>>
>> Hi Warren,
>> review

I'm assuming that that isn't the case - I was saying that I do not see
a good description of an experiment listed, and what I *did* see
(Section 5.1) could be ripped out and published as a separate
(Informational) document. Note that still wouldn't address my concerns
about the lack of an experiment description in this document, but
would at least make this document flow better.
I think that the way forward is one of:
a: adding in a description of the experiment (with metrics for success
/ failure),
b: remarking this document as Informational.

I would think that b is bestest, but leave that up to the AD / authors.

>
> https://tools.ietf.org/html/rfc2026#section-6.1.2 says that if this document
> was Last Called as Experimental, approving it as Standards Track requires a
> second IETF Last Call calling out the new Category, so would need to slip
> from this week's telechat agenda.
>

I'm assuming that we are misunderstanding...

W

>> read, it could be difficult to determine exactly when to read the counter. "
>> -- I think that this would be better if it were "it can be difficult" or "it
>> would be difficult".
>>
>> [GF]: Agree
>>
>> printing or use by anybody else is unauthorised. If you are not the intended
>> recipient, please delete this message and any attachments and advise the
>> sender by return e-mail, Thanks.
>>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 29 Nov 2017 14:16:32 -0600

Hi, Warren,

> >> Section 3.1.1 says that it is desirable to have a single node coloring

Understood. Ordinarily I let authors/shepherds/chairs/working groups take a
first pass at comment resolution, unless that looks unresponsive, but
everybody involved in processing this draft through AD Evaluation and Last
Call has been very responsive.

I chimed in because, if I DIDN'T misunderstand, the draft would need to
come off tomorrow's telechat agenda (yes, we can un-Approve a draft and
launch it into a second Last Call, but if we don't have to do that, I'd
prefer not to).

> document

That would be lovely :-)

Spencer

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 29 Nov 2017 22:05:36 +0000

Hi Spencer, Warren,
My sentence was simply misunderstood, the decision to have an experimental draft is absolutely confirmed.
Regarding the comment from Warren, I suggest to add in Section 5.1 more details of the experiment (some are already described)

Best Regards,

Giuseppe

Inviato da iPhone

Il giorno 29 nov 2017, alle ore 21:16, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> ha scritto:

Hi, Warren,

On Wed, Nov 29, 2017 at 1:47 PM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Nov 29, 2017 at 2:36 PM, Spencer Dawkins at IETF
<[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi Warren,
>> Da: Warren Kumari [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: [email-masked]<mailto:[email-masked]>; Carlos Pignataro;
>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Understood. Ordinarily I let authors/shepherds/chairs/working groups take a first pass at comment resolution, unless that looks unresponsive, but everybody involved in processing this draft through AD Evaluation and Last Call has been very responsive.

I chimed in because, if I DIDN'T misunderstand, the draft would need to come off tomorrow's telechat agenda (yes, we can un-Approve a draft and launch it into a second Last Call, but if we don't have to do that, I'd prefer not to).

That would be lovely :-)

Spencer

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Nov 2017 17:08:52 -0500

On Wed, Nov 29, 2017 at 5:05 PM, Fioccola Giuseppe <
[email-masked]> wrote:

> Regarding the comment from Warren, I suggest to add in Section 5.1 more
> details of the experiment (some are already described)
>
> Best Regards,
>
> Giuseppe
>

​Awesome, thanks.
W​

>
> Inviato da iPhone
>
> Il giorno 29 nov 2017, alle ore 21:16, Spencer Dawkins at IETF <
> [email-masked]> ha scritto:
>
> Hi, Warren,
>
> Understood. Ordinarily I let authors/shepherds/chairs/working groups take
> a first pass at comment resolution, unless that looks unresponsive, but
> * This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks. *
>
> *Rispetta l'ambiente. Non stampare questa mail se non è necessario.*
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 29 Nov 2017 22:55:31 +0000

Hi, Warren,

On Nov 29, 2017, at 2:47 PM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:

Hi Warren,

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: Warren Kumari [mailto:[email-masked]]
Inviato: martedì 28 novembre 2017 23:38
A: The IESG
Cc: [email-masked]<mailto:[email-masked]>; Carlos Pignataro;
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Oggetto: Warren Kumari's No Objection on draft-ietf-ippm-alt-mark-13:
(with COMMENT)

[GF]: Ok, I will double check but the comments from Eric should be
addressed in -13 version

[GF]: This can be discussed, also in my view the scope can be more than
experimental

Chiming in as shepherd, sharing a datapoint for your consideration.

At the time of the write-up, I brought up a similar question. At the end, in email conversations with the contributors and chairs, I ended up convinced that Experimental was the right intended status.

This is what I included in the writeup:

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

   The intended status is Experimental. When this work was first put
   together, it first described an operational experiment at Telecom Italia.
   Although the document is immensely more mature now, and the
   foundational elements of an experiment are tested, the measurement
   utility of this extension still is to be demonstrated at a variety of scales
   in a plurality of network conditions. Further, this specification does not
   define protocol extensions but instead a method which can be used by
   different protocols. Experimental is therefore the appropriate type of
   RFC, and it is indicated in the first page.

Thanks,

Carlos.

So, please advise!

W

Spencer

Nits:
Section 1.  Introduction

Section 1.  Introduction
"In case the marking field is obtained by changing existing field values
of"
-- perhaps: "In cases where the marking..."? Actually, this whole sentence
feels a bit clumsy.

[GF]: Agree

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Nov 2017 21:07:11 -0500

I'm not sure I fully understood -- are you saying that this used to
explain more what the experiment would be, and then, as this
progressed, they did much of the experiment, and now the document
describes how it all went, etc?
If so, this is a: interesting and b: cool!

Whatever the case, I'm (now) fine with the amount of discussion and am
fine with Experimental.

W

On Wed, Nov 29, 2017 at 5:55 PM, Carlos Pignataro (cpignata)
<[email-masked]> wrote:
> Hi, Warren,
>
> On Nov 29, 2017, at 2:47 PM, Warren Kumari <[email-masked]> wrote:
>
> At the time of the write-up, I brought up a similar question. At the end, in
> email conversations with the contributors and chairs, I ended up convinced
> that Experimental was the right intended status.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 29 Nov 2017 22:49:48 -0600

Hi, Giuseppe,

On Wed, Nov 29, 2017 at 4:08 PM, Warren Kumari <[email-masked]> wrote:

>
>
> On Wed, Nov 29, 2017 at 5:05 PM, Fioccola Giuseppe <giuseppe.fioccola@
> telecomitalia.it> wrote:
>
>> Hi Spencer, Warren,
>> My sentence was simply misunderstood, the decision to have an
>> experimental draft is absolutely confirmed.

Thanks for me as well. That's what I expected, but needed to ask today,
rather than tomorrow.

The slightly less misunderstanding Spencer

>> Understood. Ordinarily I let authors/shepherds/chairs/working groups
>> take a first pass at comment resolution, unless that looks unresponsive,
>> but everybody involved in processing this draft through AD Evaluation and
>> Last Call has been very responsive.
>>
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Fioccola Giuseppe <[email-masked]>
Date: Thu, 30 Nov 2017 10:05:13 +0000

Hi Warren,
Of course, your understanding is right.
You got the point, this is the reason why the document is experimental and this is the reason of my misunderstood sentence too :)

Thanks,

Giuseppe

-----Messaggio originale-----
Da: Warren Kumari [mailto:[email-masked]] 
Inviato: giovedì 30 novembre 2017 03:07
A: Carlos Pignataro (cpignata)
Cc: Spencer Dawkins at IETF; Fioccola Giuseppe; The IESG; [email-masked]; [email-masked]; IETF IPPM WG
Oggetto: Re: Warren Kumari's No Objection on draft-ietf-ippm-alt-mark-13: (with COMMENT)

I'm not sure I fully understood -- are you saying that this used to explain more what the experiment would be, and then, as this progressed, they did much of the experiment, and now the document describes how it all went, etc?
If so, this is a: interesting and b: cool!

Whatever the case, I'm (now) fine with the amount of discussion and am fine with Experimental.

W

On Wed, Nov 29, 2017 at 5:55 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> places where the document hand-waves away some of the details - like 
> how do I configure this (and more importantly, how do I detect) so 
> that I'm not making in too many places, and having one device stomp on another devices'
> markings?
> Section 3.1.1 says that it is desirable to have a single node coloring 
> -- is this supposed to mean a single node *per network* (which makes 
> this useless)?
>
> Or somehow per flow (then how do I know who's the right device to 
> mark?) Perhaps devices should watch for already colored packets if 
> they are intending to color, and alert on this case as an error?
>
> [GF]: the right device designated for marking can be established by 
> the filter criteria used to select the flow we want to measure.
>
> 1: The document lists 8 authors above the fold. This may be must 
> better as an Editor (or two) and the rest moved to contributors.
>
> it) a description of the experiment to be performed -- Section 5.1 has 
> a writeup of experience gained from running this at TI, but that seems 
> more like a separate Informational document.
>
> experimental" means anything like "standards track", that's a 
> conversation we should have REALLY quickly.
>
>
> At the time of the write-up, I brought up a similar question. At the 
> end, in email conversations with the contributors and chairs, I ended 
> up convinced that Experimental was the right intended status.
>
> Internet Standard, Informational, Experimental, or Historic)?  Why is 
> this the proper type of RFC?  Is this type of RFC indicated in the 
> title page header?
>
> document was Last Called as Experimental, approving it as Standards 
> Track requires a second IETF Last Call calling out the new Category, 
> so would need to slip from this week's telechat agenda.
>
> Experimental, or Historic without another Last Call, but we can't go 
> the other way.
>
> So, please advise!
>
> monitoring of live traffic, possibly easy to implement and deploy." -- 
> did you mean "possibly"
> "Since a flow is continuous and cannot be stopped when a counter has 
> to be read, it could be difficult to determine exactly when to read the counter. "
> -- I think that this would be better if it were "it can be difficult" 
> or "it would be difficult".
>
> [GF]: Agree
>
> "Traffic coloring could be done by R1 itself or by an upward router." 
> -- what is an "upward" router? Was this supposed to be upstream? Even 
> if so, I think that there needs to be more precision here.
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente 
> alle persone indicate. La diffusione, copia o qualsiasi altra azione 
> derivante dalla conoscenza di queste informazioni sono rigorosamente 
> vietate. Qualora abbiate ricevuto questo documento per errore siete 
> cortesemente pregati di darne immediata comunicazione al mittente e di 
> provvedere alla sua distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain 
> privileged information intended for the addressee(s) only. 
> Dissemination, copying, printing or use by anybody else is 
> unauthorised. If you are not the intended recipient, please delete 
> this message and any attachments and advise the sender by return e-mail, Thanks.
>

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

---

From: Fioccola Giuseppe <[email-masked]>
Date: Thu, 30 Nov 2017 10:10:46 +0000

Hi Spencer,
Great! It is important that we all agree.

Best Regards,

Giuseppe

Da: Spencer Dawkins at IETF [mailto:[email-masked]]
Inviato: giovedì 30 novembre 2017 05:50
A: Warren Kumari
Cc: Fioccola Giuseppe; The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Oggetto: Re: Warren Kumari's No Objection on draft-ietf-ippm-alt-mark-13: (with COMMENT)

Hi, Giuseppe,

On Wed, Nov 29, 2017 at 4:08 PM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Nov 29, 2017 at 5:05 PM, Fioccola Giuseppe <[email-masked]<mailto:[email-masked]>> wrote:
Hi Spencer, Warren,
My sentence was simply misunderstood, the decision to have an experimental draft is absolutely confirmed.
Regarding the comment from Warren, I suggest to add in Section 5.1 more details of the experiment (some are already described)

Best Regards,

Giuseppe

​Awesome, thanks.

Thanks for me as well. That's what I expected, but needed to ask today, rather than tomorrow.

W​

Inviato da iPhone

That would be lovely :-)

Spencer