Subject: [Dbound] Charter feedback

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 4 Dec 2014 12:10:08 -0800

So far the feedback about the charter has said approximately nothing
negative at all about the definition problem space or the deliverables, and
only complained that it's too long because there's too much background.

I'll take a swing at trimming it, but I'm not sure I can come up with
much.  I think all of the text we have either explains the problem or
constrains our activity by describing what we know won't work.

Anyone have any suggestions?

-MSK

---

From: Casey Deccio <[email-masked]>
Date: Thu, 4 Dec 2014 15:25:29 -0500

> Anyone have any suggestions?

I can get integrate the text more suitable for a background/problem
statement into the problem statement draft that is under revision (and I
haven't yet posted as a 00), so it can be referenced from the charter,
making the charter less noisy.

Casey

---

From: Dave Crocker <[email-masked]>
Date: Thu, 04 Dec 2014 20:00:14 -0800

> making the charter less noisy.

Please do not do that.

Charters have two different purposes.  One is essentially as a work
contract between the working group and the IETF, stating scope, schedule
and deliverables.

But the other purpose is to recruit participants.  If you require
potential participants to go search for other text before they can
understand the basic problem being tackled, they won't bother.

For wide benefit, a charter needs to be sufficient as a standalone document.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 05 Dec 2014 15:32:43 +0900

Hello Murray,

On 2014/12/05 05:10, Murray S. Kucherawy wrote:
> much.

Please do. Every line less is a win.

> I think all of the text we have either explains the problem or

Often there is explicit and implicit duplication between the problem 
space definition and the deliverables, which can be eliminated.

Regards,   Martin.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 05 Dec 2014 06:35:38 -0800

> Please do. Every line less is a win.

I'm curious about the basis for claiming this.

Will it improve working group functioning?  Will it improve wg
participation recruitment?

What will be the significant operational benefit?

d/

---

From: Kurt Andersen <[email-masked]>
Date: Fri, 5 Dec 2014 10:04:18 -0800

On Thu, Dec 4, 2014 at 8:00 PM, Dave Crocker <[email-masked]> wrote:

> Charters have two different purposes  . . .
>

I agree with this. Having the charter be as self-contained as possible is a
significant benefit. Given the linguistic contortions that we went through
to explain what DBOUND is about, I am in favor of sticking with the charter
largely as proposed without any major removals.

We can have a more verbose, independent though related problem statement
that helps to explore the problem space, but I think that taking any of the
components out of this proposed charter would be a net negative change.

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2014 19:16:49 -0000

>What will be the significant operational benefit?

tl;dr

This cuts both ways, of course.

R's,
John

PS: You'll not I'm not asking for charter changes.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 06 Dec 2014 07:42:32 +0100

Hi Murray,

On 12/4/14, 9:10 PM, Murray S. Kucherawy wrote:
> negative at all about the definition problem space or the
> deliverables, and only complained that it's too long because there's
> too much background.
>

I think the text is really just good enough, with one possible
exception.  You point to a list of documents as possible starting
points.  My experience is that it saves a whole lot of time and effort
if the organizers can consolidate their work into a single proposal as a
starting point, perhaps with a handful of open design questions.  It's
not always possible, but if you don't you have to establish rough
consensus for which one to move forward with.

Eliot

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 07 Dec 2014 18:18:06 +0900

[just for the record]

> I'm curious about the basis for claiming this.

Of course this doesn't work in isolation. Otherwise, a charter of 0 
lines would be best, but that's obviously not going to work.

> Will it improve working group functioning?

Concisely described deliverables and concisely described "out of bounds" 
items should indeed improve working group functioning.

> Will it improve wg

A shorter, easier to read charter should be more inviting for potential 
participants. In addition, shorter text helps people who's mother tongue 
is not English.

Regards,   Martin.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 7 Dec 2014 21:03:07 +0800

The problem with "single proposal" in this case is that the different use cases appear not to be amenable to a single solution. 

A

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On Dec 6, 2014, at 14:42, Eliot Lear <[email-masked]> wrote:
> 
> Hi Murray,
> 
>> So far the feedback about the charter has said approximately nothing negative at all about the definition problem space or the deliverables, and only complained that it's too long because there's too much background.
>> 
>> I'll take a swing at trimming it, but I'm not sure I can come up with much.  I think all of the text we have either explains the problem or constrains our activity by describing what we know won't work.
>> 
> I think the text is really just good enough, with one possible exception.  You point to a list of documents as possible starting points.  My experience is that it saves a whole lot of time and effort if the organizers can consolidate their work into a single proposal as a starting point, perhaps with a handful of open design questions.  It's not always possible, but if you don't you have to establish rough consensus for which one to move forward with.
> 
> Eliot
> 
> _______________________________________________
> Dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound

---

From: Dave Crocker <[email-masked]>
Date: Sun, 07 Dec 2014 08:39:42 -0800

> The problem with "single proposal" in this case is that the different use cases appear not to be amenable to a single solution. 

Folks,

While we've had discussion of use cases and the charter makes quick
reference to some examples, I'm not sure we've established a nice,
representative sample of concrete and detailed existing (or desired) use
cases for everyone to use at a collective target.

The PSL establishes one, very clear and strong use case, of course.
While it's obviously well-established I, personally, don't adequately
understand the nature and details of the web cross-domain
name-equivalence one well enough. Careful uses cases can greatly help wg
participants and potential adopters get a shared understanding of goals
and scope.

It could help to develop detailed text that specifies a number (3-5?) of
scenarios that we are seeking to satisfy, stated in largely
non-technical terms and from the perspective of usage, covering who,
what and why, but not how.

The charter isn't the place for this, except as tersely as the current
draft already does, and I don't think it requires a standalone document,
longer term.  Still it could be useful to develop it as a draft now,
later perhaps merging it into a foundational document.

d/

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2014 20:35:12 -0000

>cases for everyone to use at a collective target.

We haven't.  I thought we were trying to do that a couple of months
ago but we seem to have gotten distracted.

It appears to be very hard for people to describe use cases without
immediately diving into solutions, or into restatements of the problem
that assume particular approaches to solutions.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 07 Dec 2014 12:52:54 -0800

> participants. In addition, shorter text helps people who's mother tongue

There is a balance needed between conciseness and completeness.

For example, a nice, short charter that assumes too much prior knowledge
for the reader is a less effective charter, if soliciting outside folk
is a goal, no matter their native tongue.

I've sent some suggestions to Murray, to makes things just a little bit
shorter.  But not significantly.

If you have specific suggestions, please also send them in.

d/

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 7 Dec 2014 16:14:50 -0500

> participants and potential adopters get a shared understanding of goals

I suspect the reason you don't understand that is because, as near as
I can tell, nobody does.  At bottom that observation is what motivated
me to start work on this problem some time ago.

In the large, the issue is that any use of the PSL reads from
assertions (about certain parts of the hierarchy and the in-protocol
administrative boundaries of the DNS) some security properties of
services operated at a given DNS name or pair of names.  The precise
security properties being inferred vary somewhat depending on what is
being done, what the developer who created the code thought the
important set of threats were, and sometimes the settings the user has
selected in the client software.  But the pairwise relationship is, in
every case, the actual decision that is being made (even when that is
not the way it's implemented today because of the way the PSL works).

Moreover, "web security people" (i.e. on the web security list) tell
me that the proposals we've discussed so far will never be useful for
the same-origin policy, because to do a same-origin comparison you
need port information too.  I find this claim completely mystifying,
because in the PSL you don't have that port information, so I don't
understand where this requirement comes from.  That suggests to me
that the details of the same-origin policy are actually murky to the
people who assert what its properties are.

I have tried very carefully to avoid the term "equivalence" in
whatever I've written about this, because it's a word that just
invites confusion.  But I suspect it'll be hard to get away from due
to the "same origin policy" name.

I have no idea whether any of that background helps, but I thought it
might allow some others to see what is motivating at least my thinking
on some of this.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sun, 07 Dec 2014 22:28:22 +0100

Andrew,

> people who assert what its properties are.

If by same origin policy we are talking about whether http://example.com
== https//example.com, this is known not to be a safe assumption, absent
additional information, and is the source of a substantial amount of
work in HTTPBIS.  But I also don't see how that applies here for the
reasons you state, although I could imagine a risk argument being made
about this mechanism versus the PSL.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 7 Dec 2014 16:52:03 -0500

On Sun, Dec 07, 2014 at 10:28:22PM +0100, Eliot Lear wrote:
> == https//example.com,

No.  My understanding of what same-origin policy means in this context
is that, for the purposes of running (say) javascript, can I use
something I got from the [scheme][host][port] source in the context of
[scheme2][host2][port2]?  AFAICT, the actual way this works in
practice is that scheme and scheme2 are always the same and are almost
always either http or https, port and port2 are always the same and
are usually 80 or 443, and the real question is whether host and host2
are "the same" for these purposes.  But I suppose someone who knows
the code could correct me.  Anyway, one of the various drafts I spit
up on this topic had a complicated mechanism for including schemes and
ports, which lasted until the very same people told me it was way too
complicated and nobody could understand it so useless.  Since it also
seemed like a hideous wart to me, I ripped it all out again.

The usual example is running some javascript from http://example.com
on http://label.example.com.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Sun, 07 Dec 2014 15:07:40 -0800

> that assume particular approaches to solutions.

It's nearly always true for IETF work.  Something about being engineers...

But absent a shared sense of use cases, debates about solution choices
frequently entail differences in each person's (private) selections of
use cases.

So it's less that my solution choice is better than yours but that mine
suits my use cases better, and your preference suits yours.

d/

---

From: Gervase Markham <[email-masked]>
Date: Tue, 09 Dec 2014 10:13:08 +0000

On 07/12/14 21:14, Andrew Sullivan wrote:
> I can tell, nobody does.

https://tools.ietf.org/html/draft-abarth-principles-of-origin-00
?

Also
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
http://www.w3.org/Security/wiki/Same_Origin_Policy

> people who assert what its properties are.

The port has to be the same.

if (port1 == port2)

does not require any sort of list lookup :-)

Gerv

---

From: "John Levine" <[email-masked]>
Date: 9 Dec 2014 16:50:57 -0000

>does not require any sort of list lookup :-)

I believe the concern that Andrew was passing along is that the
boundaries for port 80 traffic might be different than the boundaries
for port 443 or port 25.

To me, this is deep into "don't do that" territory, but they said what
they said.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Dec 2014 11:36:09 +0100

Hi John,
> To me, this is deep into "don't do that" territory, but they said what

I'm sorry to belabor this, but does anyone have a real example of that? 
A reference will do.

Eliot