Subject: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jan 2018 19:42:55 -0800

Ben Campbell has entered the following ballot position for
charter-ietf-taps-01-00: 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-taps/

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

Do I read correctly that the only change from the previous charter is to remove
the paragraph about coordinating with TCPINC? If so, I'm not sure that change
is important enough to justify rechartering, but I won't get in the way if
other people agree with it.

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 24 Jan 2018 10:53:07 +0100

Hi Ben,

this change rather removed the restriction to not analyze features of 
security protocols (other than tcpinc); this is mainly the first 
sentence. As we see a closer integration of TLS with QUIC and we in 
general think that security features are important, it is actually an 
important change to allow us to do some additional work in this space.

Mirja

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jan 2018 08:38:05 -0600

Hi, Ben,

On Wed, Jan 24, 2018 at 3:53 AM, Mirja Kühlewind <[email-masked]>
wrote:

> security protocols (other than tcpinc); this is mainly the first sentence.
> As we see a closer integration of TLS with QUIC and we in general think
> that security features are important, it is actually an important change to
> allow us to do some additional work in this space.
>

What Mirja said, but more than that - when I chartered TAPS, I was thinking
about choosing between transport protocols, but that's morphing into
choosing paths based on the way each potential path supports those
transport protocols, and paths can differ in the way they treat transport
security. So the working group should be including transport security in
its analysis, and that was excluded in the current charter.

Does that help?

Spencer

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Jan 2018 09:40:44 -0600

> On Jan 24, 2018, at 3:53 AM, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Ben,
> 
> this change rather removed the restriction to not analyze features of security protocols (other than tcpinc); this is mainly the first sentence. As we see a closer integration of TLS with QUIC and we in general think that security features are important, it is actually an important change to allow us to do some additional work in this space.

I had read that to just move the restriction not to work on security into the “out of scope” section above, but I can see that there could be a difference between “won’t work on security protocols” and “won’t analyze the features of security protocols”. Were those statements intended to prohibit substantially different things?

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Jan 2018 09:42:19 -0600

> On Jan 24, 2018, at 8:38 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Ben,
> 
> On Wed, Jan 24, 2018 at 3:53 AM, Mirja Kühlewind <[email-masked]> wrote:
> Hi Ben,
> 
> What Mirja said, but more than that - when I chartered TAPS, I was thinking about choosing between transport protocols, but that's morphing into choosing paths based on the way each potential path supports those transport protocols, and paths can differ in the way they treat transport security. So the working group should be including transport security in its analysis, and that was excluded in the current charter.
> 
> Does that help?

Yes, and it answers the question I just asked in response to Mirja’s email :-)

Would it make sense to put “include transport security in it’s analysis” in the explicitly in-scope bits?

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 Jan 2018 06:51:34 -0600

Hi, Ben,

>
> What Mirja said, but more than that - when I chartered TAPS, I was
thinking about choosing between transport protocols, but that's morphing
into choosing paths based on the way each potential path supports those
transport protocols, and paths can differ in the way they treat transport
security. So the working group should be including transport security in
its analysis, and that was excluded in the current charter.
> Does that help?

Yes, and it answers the question I just asked in response to Mirja’s email
:-)

Would it make sense to put “include transport security in it’s analysis” in
the explicitly in-scope bits?

That doesn't seem obviously wrong.

We may have been more focused on removing the prohibition than saying what
should happen, now that the prohibition has been removed :-)

Let me talk to the TAPSters about specific wording.

And thanks for asking.

Spencer