Subject: [ippm] Mirja Kühlewind's No Objection on draft-ietf-ippm-alt-mark-13: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Sat, 11 Nov 2017 07:15:02 -0800

Mirja Kühlewind 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:
----------------------------------------------------------------------

A couple of high level comments on the structure and intention of this document:

1) As the shepherd write-up states „this specification does not define protocol
extensions but instead a method which can be used by different protocols“
therefore I think it should be informational.

2) I think section 5.1 should be moved to the appendix or even into a new
document that could be send to the ISE. If the intention is that DSCP marking
is explained as an example, there is no need to talk about Telecom Italia or
any specific details of their implementation. The level of detail for the DCSP
approach should stay similar as for sections 5.2-5.4 with no need to mention
that this is in use by Telecom Italia. Respectively, section 8 does also not
need to name Telecom Italia’s deployment but can simply refer to the use of
DSCP as one example.

3) There is quite some redundancy in the text that could be removed and would
make the document shorter and even easier to read. Respectively, I don’t think
section 7 as well as some of the motivation text in the intro is needed.

Nits:
1) maybe s/a live traffic flow/an active traffic flow/ … not sure what is meant
with „live“ here. 2) In section 9, this is incorrect: „Nevertheless, the method
implies modifications on the fly to the IP header of data packets…“ as using
DSCP is just one possible implementation. It should say probably
instead: „Nevertheless, the method implies modifications on the fly to a header
or encapsulation of the data packets…“ Similarly, this sentence should be
adapted: „The privacy concerns of network measurement are limited because the
method only relies on information contained in the IP header without any
release of user data.“

---

From: Fioccola Giuseppe <[email-masked]>
Date: Sun, 12 Nov 2017 04:55:20 +0000

Hi Mirja,
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: Mirja Kühlewind [mailto:[email-masked]] 
Inviato: sabato 11 novembre 2017 16:15
A: The IESG
Cc: [email-masked]; Carlos Pignataro; [email-masked]; [email-masked]; [email-masked]
Oggetto: Mirja Kühlewind'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.)

1) As the shepherd write-up states „this specification does not define protocol extensions but instead a method which can be used by different protocols“ therefore I think it should be informational.

[GF]:Ok, good.

2) I think section 5.1 should be moved to the appendix or even into a new document that could be send to the ISE. If the intention is that DSCP marking is explained as an example, there is no need to talk about Telecom Italia or any specific details of their implementation. The level of detail for the DCSP approach should stay similar as for sections 5.2-5.4 with no need to mention that this is in use by Telecom Italia. Respectively, section 8 does also not need to name Telecom Italia’s deployment but can simply refer to the use of DSCP as one example.

[GF]: If needed we can investigate how to reduce section 5.1. Please note that some sentences have been added (also to this section) during the IETF Last Call reviews. In addition the level of detail in 5.1 is different than 5.2-5.4 because this experimental use case have no dedicated document. I think the number of mentions of Telecom Italia can be further reduced (e.g. in the title of section 5.1 and more) but I would suggest to leave a few, because this company employs this technology for the first time. Agree, Section 8 should omit any references to Telecom Italia. 

3) There is quite some redundancy in the text that could be removed and would make the document shorter and even easier to read. Respectively, I don’t think section 7 as well as some of the motivation text in the intro is needed.

[GF]: Yes, section 7 is not crucial also in my view (and some sentences that can be moved in the introduction).

Nits:
1) maybe s/a live traffic flow/an active traffic flow/ … not sure what is meant with „live“ here. 2) In section 9, this is incorrect: „Nevertheless, the method implies modifications on the fly to the IP header of data packets…“ as using DSCP is just one possible implementation. It should say probably
instead:
„Nevertheless, the method implies modifications on the fly to a header or encapsulation of the data packets…“ Similarly, this sentence should be
adapted: „The privacy concerns of network measurement are limited because the method only relies on information contained in the IP header without any release of user data.“

[GF]: Ok, consider it done.

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: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sun, 12 Nov 2017 13:05:15 +0800

Hi Guiseppe,

please see below.

> Am 12.11.2017 um 12:55 schrieb Fioccola Giuseppe <[email-masked]>:
> 
> Hi Mirja,

This is only my recommendation. Please wait for more feedback from the other IESG members on this and confirm with the responsible AD (Spencer), and the working group, before you do any changes here.

> [GF]: If needed we can investigate how to reduce section 5.1. Please note that some sentences have been added (also to this section) during the IETF Last Call reviews. In addition the level of deta…

The nicer way to do is, would be to have a section (5.1) on DSCP that is on a similar level of details than the other subsections, and add a separate section on implementation experience. We have often these sections in drafts that report on existing implementations that, however, are usually removed before final publication (because their are mostly intended for wg-internal information). Therefore if you want to keep an implementation report in the draft, it would probably more appropriate to move that to the appendix.

Mirja 

> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Fioccola Giuseppe <[email-masked]>
Date: Sun, 12 Nov 2017 05:28:44 +0000

Hi Mirja,
Please see my answers below, tagged as [GF].

Giuseppe

-----Messaggio originale-----
Da: Mirja Kuehlewind (IETF) [mailto:[email-masked]] 
Inviato: domenica 12 novembre 2017 06:05
A: Fioccola Giuseppe
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
Oggetto: Re: [ippm] R: Mirja Kühlewind's No Objection on draft-ietf-ippm-alt-mark-13: (with COMMENT)

Hi Guiseppe,

please see below.

[GF]: Yes I know.

[GF]: Yes, it makes sense. Thanks for your suggestion and for the shared experience on previous documents. I think that this point will also be discussed with the other IESG members, the responsible AD Spencer and the IPPM WG in order to find the agreed solution.

Mirja

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 13 Nov 2017 12:50:45 +0800

Hi, Guiseppe,

On Sun, Nov 12, 2017 at 1:28 PM, Fioccola Giuseppe <
[email-masked]> wrote:

> Oggetto: Re: [ippm] R: Mirja Kühlewind's No Objection on
> draft-ietf-ippm-alt-mark-13: (with COMMENT)
>
> Hi Guiseppe,
>
> please see below.
>
> > Cc: [email-masked]; Carlos Pignataro;
> [email-masked]; [email-masked]; [email-masked]
> > 1) As the shepherd write-up states „this specification does not define
> protocol extensions but instead a method which can be used by different
> protocols“ therefore I think it should be informational.
> >
> > [GF]:Ok, good.
>
> This is only my recommendation. Please wait for more feedback from the
> other IESG members on this and confirm with the responsible AD (Spencer),
> and the working group, before you do any changes here.
>
> [GF]: Yes I know.
>
> >
> > 2) I think section 5.1 should be moved to the appendix or even into a
> new document that could be send to the ISE. If the intention is that DSCP
> marking is explained as an example, there is no need to talk about Telecom
> Italia or any specific details of their implementation. The level of detail
> for the DCSP approach should stay similar as for sections 5.2-5.4 with no
> need to mention that this is in use by Telecom Italia. Respectively,
> section 8 does also not need to name Telecom Italia’s deployment but can
> simply refer to the use of DSCP as one example.
> >
> > [GF]: If needed we can investigate how to reduce section 5.1. Please
> note that some sentences have been added (also to this section) during the
> IETF Last Call reviews. In addition the level of detail in 5.1 is different
> than 5.2-5.4 because this experimental use case have no dedicated document.
> I think the number of mentions of Telecom Italia can be further reduced
> (e.g. in the title of section 5.1 and more) but I would suggest to leave a
> few, because this company employs this technology for the first time.
> Agree, Section 8 should omit any references to Telecom Italia.
>
> The nicer way to do is, would be to have a section (5.1) on DSCP that is
> on a similar level of details than the other subsections, and add a
> separate section on implementation experience. We have often these sections
> in drafts that report on existing implementations that, however, are
> usually removed before final publication (because their are mostly intended
> for wg-internal information). Therefore if you want to keep an
> implementation report in the draft, it would probably more appropriate to
> move that to the appendix.
>
> [GF]: Yes, it makes sense. Thanks for your suggestion and for the shared
> experience on previous documents. I think that this point will also be
> discussed with the other IESG members, the responsible AD Spencer and the
> IPPM WG in order to find the agreed solution.

Count on it :-)

Spencer