Subject: [Wpack] Éric Vyncke's No Objection on charter-ietf-wpack-00-04: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Sun, 02 Feb 2020 07:54:28 -0800

Éric Vyncke has entered the following ballot position for
charter-ietf-wpack-00-04: 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.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wpack/

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

Interesting work to be done. As I have some non-blocking comments/questions
(see below), I have entered a 'no objection' but this is mostly a 'yes'.

Suggest to replace 'Three examples to" by 'Three use cases to" in the first
goal.

Unsure whether "Constraints on how clients load the formats" can be parsed as a
goal.

No mention of interaction with other IETF WG.

May I assume that WPACK also encompass the naming / retrieval of those web
package ?

Nit " above properties. * Support", insert a CRLF ?

Nit: should "DRM" be expanded ?

---

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 04 Feb 2020 13:23:16 +0000

Hi Éric,
Thank you for your comments. My replies below:

> Suggest to replace 'Three examples to" by 'Three use cases to" in the first

Changed, thank you.

> Unsure whether "Constraints on how clients load the formats" can be parsed as a

Good point. I need to check Jeffrey what was intended here.

> No mention of interaction with other IETF WG.

Good point. I added "The WPACK working group will work closely with the HTTPbis working group."
 
> May I assume that WPACK also encompass the naming / retrieval of those web

No. I think this is standard HTTP (which is HTTPBIS WG) or some peer-to-peer mechanism.
> Nit " above properties. * Support", insert a CRLF ?

Done.

> Nit: should "DRM" be expanded ?

I added expanded version just in case.

Best Regards,
Alexey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 4 Feb 2020 10:34:42 -0800

> Good point. I need to check Jeffrey what was intended here.

This comes from a discussion at the BoF over my initial non-goal of
"Defining the details of how web browsers load the formats and interact
with any protocols we define here." The minutes record:

   - MT: one thing missing is one clear articilation of he constraints
   people running this should operate in order to maintain guaratnees. agree
   with dkg. we are setting a new bar that require meeting a brand new set of
   requirements. that relates to things that mnot, jeffrey havem mentioned.
   along with personalisation. we should capture these and do an anaylsis to
   ensure that we can get this right. ...
   - ben schwarz: i agree with MT. 'out of scope for how browsers load
   format' -- no, we should list constraints. this could actually be a victory
   for privacy over HTTPs e.g. if servers push bundles this may have better
   privacy properties.

I think Martin was suggesting that the IETF-side specifications should
include requirements on the client that ensure the security properties we
want, even though we wouldn't include detailed algorithms for how a web
browser builds a Document object out of the formats. I don't have strong
opinions on how to word that goal.

Jeffrey

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 05 Feb 2020 10:38:22 +0000

On Tue, Feb 4, 2020, at 6:34 PM, Jeffrey Yasskin wrote:
> On Tue, Feb 4, 2020 at 5:24 AM Alexey Melnikov <[email-masked]> wrote:
> This comes from a discussion at the BoF over my initial non-goal of "Defining the details of how web browsers load the formats and interact with any protocols we define here." The minutes record:
>  * MT: one thing missing is one clear articilation of he constraints people running this should operate in order to maintain guaratnees. agree with dkg. we are setting a new bar that require meeting a brand new set of requirements. that relates to things that mnot, jeffrey havem mentioned. along with personalisation. we should capture these and do an anaylsis to ensure that we can get this right. ...
>  * ben schwarz: i agree with MT. 'out of scope for how browsers load format' -- no, we should list constraints. this could actually be a victory for privacy over HTTPs e.g. if servers push bundles this may have better privacy properties.
> I think Martin was suggesting that the IETF-side specifications should include requirements on the client that ensure the security properties we want, even though we wouldn't include detailed algorithms for how a web browser builds a Document object out of the formats. I don't have strong opinions on how to word that goal.

Ok. I changed the sentence to read:

"Specifying constraints on how clients load the formats without describing specific loading algorithm to help achieve the above goals."

If you think that further changes are needed, please let me know.

Best Regards,
Alexey

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 05 Feb 2020 11:53:09 +0100

On Wed, Feb 5, 2020, at 11:38, Alexey Melnikov wrote:
> "Specifying constraints on how clients load the formats without 
> describing specific loading algorithm to help achieve the above goals."

Though it says what we want, I found this particularly hard to parse.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 5 Feb 2020 13:23:17 +0000

Thank you Alexey, this is exactly what I was looking for: this sentence now parses as a goal 😉

-éric

From: Alexey Melnikov <[email-masked]>
Date: Wednesday, 5 February 2020 at 11:39
To: Jeffrey Yasskin <[email-masked]>
Cc: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Martin Thomson <[email-masked]>
Subject: Re: [Wpack] Éric Vyncke's No Objection on charter-ietf-wpack-00-04: (with COMMENT)

On Tue, Feb 4, 2020, at 6:34 PM, Jeffrey Yasskin wrote:
On Tue, Feb 4, 2020 at 5:24 AM Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:

This comes from a discussion at the BoF over my initial non-goal of "Defining the details of how web browsers load the formats and interact with any protocols we define here." The minutes record:
·         MT: one thing missing is one clear articilation of he constraints people running this should operate in order to maintain guaratnees. agree with dkg. we are setting a new bar that require meeting a brand new set of requirements. that relates to things that mnot, jeffrey havem mentioned. along with personalisation. we should capture these and do an anaylsis to ensure that we can get this right. ...
·         ben schwarz: i agree with MT. 'out of scope for how browsers load format' -- no, we should list constraints. this could actually be a victory for privacy over HTTPs e.g. if servers push bundles this may have better privacy properties.
I think Martin was suggesting that the IETF-side specifications should include requirements on the client that ensure the security properties we want, even though we wouldn't include detailed algorithms for how a web browser builds a Document object out of the formats. I don't have strong opinions on how to word that goal.

Best Regards,
Alexey