Subject: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 21 Jan 2015 12:13:12 -0800

Alissa Cooper has entered the following ballot position for
charter-ietf-dbound-00-01: 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:
http://datatracker.ietf.org/doc/charter-ietf-dbound/

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

I agree with the suggestion of removing the additional information
section at the end. Add one sentence to the body of the charter about the
PSL if you want, but having that whole section in the charter seems
unnecessary.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Jan 2015 13:46:37 -0800

> PSL if you want, but having that whole section in the charter seems

Unnecessary for the folk who already have enough background in the
topic, yes.  But this is an unusual and therefore unfamiliar topic.

The purpose of the additional text is as an aid at inclusiveness, by
virtue of making it easier for a broader base of folk to figure out
whether or how this activity might be relevant to them.

We tend to write our charters for insiders who already know quite a bit.
 We ought to make the charter more helpful for others.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 21 Jan 2015 14:35:31 -0800

There's likely some compromise about PSL as background - although I think
Alissa's spot on. PSL really is more of a footnote.

Groaning about the PSL, while satisfying to some, seemed to rob the group
of cycles and productivity for a fairly protracted period vs focusing on
core problem.

Jothan Frakes
Tel: +1.206-355-0230

On Wed, Jan 21, 2015 at 1:46 PM, Dave Crocker <[email-masked]> wrote:

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Jan 2015 14:40:40 -0800

On 1/21/2015 2:35 PM, Jothan Frakes wrote:
> Groaning about the PSL, while satisfying to some,

Which text in the draft charter would you class as 'groaning' and why?

Again, the purpose of the extra tutorial material was to aid those
lacking sufficient background on the proposed effort.

d/

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 21 Jan 2015 15:09:15 -0800

By my read, Page 3, final paragraph is a fairly good example of where
"several inherent limitations" of the PSL are described.

   Unfortunately, the public suffix list has several inherent
   limitations.  To begin with, it is a list that is separately
   maintained from the list of DNS delegations.  As a result, the data
   in the public suffix list can diverge from the actual use of the DNS.
   Second, because its semantics are not the same as those of the DNS,
   it does not capture unusual features of the DNS that are a
   consequence of its structure (see [RFC1034
<http://tools.ietf.org/html/rfc1034>] for background on that
   structure).  Third, as the size of the root zone grows, keeping the
   list both accurate and synchronized with the expanding services will
   become difficult and unreliable.  Perhaps most importantly, it puts
   the power of assertion about the operational policies of a domain
   outside the control of the operators of that domain, and in the
   control of a third party possibly unrelated to those operators.

Though PSL is very widely used, it seems a missed opportunity to perhaps
instead simply abstract things in a sentence or two to define how the use
of static lists for DBOUND-esque purpose by developers and integrators is
really the issue / problem to be solved.

Jothan Frakes
Tel: +1.206-355-0230

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 21 Jan 2015 15:41:34 -0800

> We ought to make the charter more helpful for others.

I think the main goal of a charter should be to precisely define the scope of the work of the WG. Extraneous words leave the door open for scope creep. In this case, I think all of the additional context that a newcomer would need to understand the work of this proposed WG can fit into a sentence or two about the PSL. The rest of the text belongs in the problem statement document. We should prioritize precise scoping over tutorials in our charters.

Alissa

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 21 Jan 2015 18:47:13 -0500

Hi Jothan,

On Jan 21, 2015, at 6:09 PM, Jothan Frakes <[email-masked]> wrote:

> By my read, Page 3, final paragraph is a fairly good example of where "several inherent limitations" of the PSL are described.
> 
> 
>    consequence of its structure (see [RFC1034] for background on that
> Though PSL is very widely used, it seems a missed opportunity to perhaps instead simply abstract things in a sentence or two to define how the use of static lists for DBOUND-esque purpose by developers and integrators is really the issue / problem to be solved.

In general, I agree with you. But in cases where we're trying to spin up a new effort to solve a problem people might, at first glance, think is already solved by existing technology, they will-- and should-- ask pretty quickly why we think the new effort is worth the pain. (This happens on a regular basis with DNS, DHCP, and other infrastructure protocols: "Can't you just use $option we standardized five years ago?")

I think what we have in the DBOUND charter, while admittedly awkward, helps by anticipating the question "Why isn't the PSL close enough to something like a solution here?" In turn, that gets us to the closely related question, for a potential participant in the effort, of "Why is participating in this WG and eventually deploying what it comes up with likely to be a better use of my time, and solve more of a problem I actually have, than living with the PSL, what I can come up with on my own, and other similar technologies?"

Thus, I see value in having the explanatory material readily available to anyone looking at what the WG is trying to do and assessing whether contributing is worth their while. I don't mind it being in the charter, but citing the problem statement draft may actually be enough for the purpose too.

best,
Suzanne

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 21 Jan 2015 19:04:00 -0500

> I think the main goal of a charter should be to precisely define the scope of the work of the WG. Extraneous words leave the door open for scope creep. In this case, I think all of the additional c…

This is the flip side of what I was trying to say a few minutes ago.

The charter was largely drafted before we had the problem statement (http://datatracker.ietf.org/doc/draft-sullivan-dbound-problem-statement/) in i-d form. The last couple of paragraphs of Section 2 of the draft is a start at equivalent text to the supporting material in the draft charter.

I do think defending the choice to charter the WG, and for a participant to spend time on it, needs to address "why isn't the PSL a solution?" in some easily referenced form. But I'm increasingly inclined to agree it doesn't have to be the charter.

thanks,
Suzanne

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Jan 2015 16:27:51 -0800

Alissa,

On 1/21/2015 3:41 PM, Alissa Cooper wrote:
> I think the main goal of a charter should be to precisely define the
> scope of the work of the WG. 

     https://www.ietf.org/wg/ >

     "WG charters state the scope of work for group, and lay out goals
and milestones that show how this work will be completed."

and:

     RFC 2418 - WG Guidelines & Procedures, Section 2.2 Charter

starts with text that is similar.

These seem in line with your narrow scope for the text.  However, when
we get down to the RFC discussion of the charter:

     Description of working group

Things get a little more interesting. It includes:

      By
      reading this section alone, an individual should be able to decide
      whether this group is relevant to their own work.

and possibly relevant:

     To facilitate evaluation of the intended work and to provide on-
      going guidance to the working group, the charter must describe the
      problem being solved and should discuss objectives and expected
      impact with respect to:

         - Architecture
         - Operations
         - Security
         - Network management
         - Scaling
         - Transition (where applicable)

which suggests that a charter needs to establish its context meaningfully.

That is what that extra text is for.

> Extraneous words leave the door open for
> scope creep.

That's an impressively generic assertion.

Let me try to match it:

     The less helpful a charter is for those not already involved in the
IETF work, the less inclusive with be working group participation.

d/

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 21 Jan 2015 16:45:40 -0800

I am a volunteer on the PSL.  I am not trying to perpetuate its use or
defend it here.

What I may be poorly articulating is that the issues / problems to solve
with DBOUND are being solved with static lists in general.  PSL is just one
of the more glaring examples of static-lists being maintained outside of
the DNS, outside the control of operators by third parties.  These exist
within the public and private / proprietary realm, though PSL has pretty
much become the alpha public list after the IANA TLD List from the Root
Zone.  The point is that focusing on PSL might not help other static list
managers to identify DBOUND as something to watch.

Focusing on the problem being things DBOUND is needed for, and how static
lists have become a solution space - and how the solution space might need
to evolve away from static lists seems a good course forward as opposed to
PSL being the problem seems important.

Jothan Frakes
Tel: +1.206-355-0230

On Wed, Jan 21, 2015 at 4:04 PM, Suzanne Woolf <[email-masked]>
wrote:

> scope of the work of the WG. Extraneous words leave the door open for scope
> creep. In this case, I think all of the additional context that a newcomer
> would need to understand the work of this proposed WG can fit into a
> sentence or two about the PSL. The rest of the text belongs in the problem
> statement document. We should prioritize precise scoping over tutorials in
> our charters.
>
> The charter was largely drafted before we had the problem statement (
> http://datatracker.ietf.org/doc/draft-sullivan-dbound-problem-statement/)
> in i-d form. The last couple of paragraphs of Section 2 of the draft is a
> start at equivalent text to the supporting material in the draft charter.
>
> I do think defending the choice to charter the WG, and for a participant
> to spend time on it, needs to address "why isn't the PSL a solution?" in
> some easily referenced form. But I'm increasingly inclined to agree it
> doesn't have to be the charter.
>
>
> thanks,
> Suzanne
>
>
>
>
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 21 Jan 2015 16:57:50 -0800

Hi Dave,

> That is what that extra text is for.

The text you quote could easily support either your argument or mine. Given that I balloted no objection to sending this for external review (and that Suzanne has suggested a useful path forward), I doubt that further discussion along these lines is a good use of anyone’s time.

> IETF work, the less inclusive with be working group participation.

I don’t see any reason why that’s true, given that we have and make use of lots of ways of making WG participation inclusive that go far beyond telling people to go read the charter. Furthermore, if prospective participants can’t take the time to click a link and find the same text in the problem statement, I would worry about their ability to contribute meaningfully in the WG.

Anyway, like I said, we all have more important fish to fry ...

Alissa

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Jan 2015 17:11:58 -0800

On 1/21/2015 4:57 PM, Alissa Cooper wrote:
> The text you quote could easily support either your argument or mine.
> Given that I balloted no objection to sending this for external
> review (and that Suzanne has suggested a useful path forward), I
> doubt that further discussion along these lines is a good use of
> anyone’s time.

Yeah, the latter text I cited is a long way from precisely stating
specific requirements.  But that's ok; I was more interested in its role
as at least providing a basis for what I'm suggesting than in its being
definitive for or against.

As for your noting that this pertains to a no objection comment, ADs
have periodically justified using a Discuss by saying that 'comments' on
a non-blocking vote often get ignored.  Especially since you are
certainly not the first to express concern over the verbosity, I thought
it worth pursuing.

At a higher level, I think that clarity about the target reader of a
charter, and focusing on helping them, is useful...

As for Suzanne's suggestion, charter development included discussion
about internal vs. external background material.  External (eg, citing
the I-D) is certainly far better than saying nothing.

However Internal significantly reduces the reader's effort at getting
'gist' infomration.  Having to go another document doesn't sound
onerous, but it's reliably demonstrated to be a meaningful barrier; that
means fewer folk who see the charter will get background they need.

And just for grins I'll raise a counter-point concerning the verbosity.
 The intended benefit of it has been explained.  As for viewing it as
'too much' verbosity, my question is:  What's the damage of retaining
that purportedly extra text?

d/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Jan 2015 22:04:21 -0500

I think this is an important point. The issue is not PSL as such, but static lists generally. Perhaps we could make that amendment to the proposed change?  Considering its prominence, saying, "…static lists (like that most prominent one, the PSL)…" would maybe make the point while yet referring to something familiar. 

A

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On Jan 21, 2015, at 19:45, Jothan Frakes <[email-masked]> wrote:
> 
> I am a volunteer on the PSL.  I am not trying to perpetuate its use or defend it here.  
> 
> What I may be poorly articulating is that the issues / problems to solve with DBOUND are being solved with static lists in general.  PSL is just one of the more glaring examples of static-lists being maintained outside of the DNS, outside the control of operators by third parties.  These exist within the public and private / proprietary realm, though PSL has pretty much become the alpha public list after the IANA TLD List from the Root Zone.  The point is that focusing on PSL might not help other static list managers to identify DBOUND as something to watch.
> 
> Focusing on the problem being things DBOUND is needed for, and how static lists have become a solution space - and how the solution space might need to evolve away from static lists seems a good course forward as opposed to PSL being the problem seems important. 
> 
> 
> 
> Jothan Frakes
> Tel: +1.206-355-0230
> 
> 
>> On Wed, Jan 21, 2015 at 4:04 PM, Suzanne Woolf <[email-masked]> wrote:
>>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Jan 2015 08:05:45 +0100

Hi,

> scope of the work of the WG. 

+1.
> Extraneous words leave the door open for scope creep.

Well that and confusion.  There needs to be a succinct problem
statement, a succinct statement as to what is in scope, what is out of
scope, and any starting points.

But this having been said, there's no real possibility for scope creep
here if the front matter (before Background) is correctly written.  And
so my suggestion is to focus on the front matter.

Eliot

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2015 03:58:57 -0000

In article <[email-masked]> you write:
>I think this is an important point. The issue is not PSL as such, but static lists generally.
>Perhaps we could make that amendment to the proposed change?  Considering its prominence, saying,
>"…static lists (like that most prominent one, the PSL)…" would maybe make the point while yet
>referring to something familiar. 

But is the problem with the PSL that it's static, that it's maintained
by a third party, that it only has one boundary per tree branch, or
what?

The answer to all of the questions other than Alyssa's is "if we knew
the answer we wouldn't need this WG".

R's,
John