Subject: Re: New Non-WG Mailing List: Mpvdapi

From: Randy Bush <[email-masked]>
Date: Thu, 02 Apr 2015 09:28:16 -0700

> A new IETF non-working group email list has been created.
> 
> List address: [email-masked]
> Archive: http://www.ietf.org/mail-archive/web/mpvdapi/
> To subscribe: https://www.ietf.org/mailman/listinfo/MPVDAPI
> 
> Purpose:
> 
> MPVD API design is very important for MPVD concept of MIF working
> group, MIF working group decide to write MPVD API document by build a
> design team, this mailing list is try to help the design team to
> discuss the main issues and write the document.
> 
> -The IETF Area to which the list belongs 
> -The URL or other instructions for subscribing to the listInternet Area 
> 
> For additional information, please contact the list administrators.

perhaps expanding some acronyms would be helpful for the reader who is
not deeply involved in multi-person venereal diseases.

< to decode >

as mailing list announcements are posted to a broad list, they should
not assume only the in-crowd will be reading them.

randy

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 2 Apr 2015 13:53:47 -0400

+100

Every announcement to the IETF announce list that current contains
only the acronym for an IETF Working Group is fundamentally defective.
This needs to be fixed so that every such message contains an
occurrence of the expansion of the acronym.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 12:55:32 -0500

Almost an April 1st announcement...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Apr 2015 15:01:26 -0400

> not deeply involved in multi-person venereal diseases.

Or you could just google mpvd and notice that the document referenced in the announcement is third on the list of results.   Or accept that if you don't know what the acronym means, and didn't bother to read the referenced document when it was last-called about a month ago, that maybe you aren't going to be interested in participating in the design team for which the mailing list was created.

I will of course admit that the snarky comments are much more fun to come up with, but on a practical level I don't think they add any value, and the person who composed the announcement with which you are finding fault might consider them a poor reward for his efforts within the IETF, which, like all of our efforts, are imperfect.

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Apr 2015 12:07:57 -0700

> I will of course admit that the snarky comments are much more fun to
> come up with, but on a practical level I don't think they add any
> value,

qed

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 2 Apr 2015 14:11:32 -0500

PvD is

Provisioning Domain (PvD) which is a consistent set of network
   configuration information

MPvD is multiple provisioning domain

Behcet

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Apr 2015 16:10:34 -0400

>> discuss the main issues and write the document.
...
> not deeply involved in multi-person venereal diseases.

He...

A good point.  We actually have made a change that's supposed to help
here.  The non-WG mailing list requests that we send to the
secretariat used to have a "short description" line, which would
almost never be enough information.  We added a second "somewhat
longer description" line for the announcement.  What you see above is
the result of that, and you can be thankful that it's at least useful
once you get the acronyms expanded.

So what we have to do now is have the discipline to expand the
acronyms.  Thanks for calling attention to that, and for the...
interesting guess at a possible expansion.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Apr 2015 14:34:12 -0700

> interesting guess at a possible expansion.

Mailing list descriptions and wg charters need to be written for an
audience that is not already part of an effort's core team, if the IETF
has interest in being actively inclusive.

There is a very large gap between acronym-encrusted and terse, versus
verbose tutorial, language.

In order to get a basic understand of topic and scope for what is being
describe, text should not require deep expertise or additional effort
beyond simply reading what is being circulated.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Bob Hinden <[email-masked]>
Date: Thu, 2 Apr 2015 17:42:32 -0700

Barry,

> On Apr 2, 2015, at 1:10 PM, Barry Leiba <[email-masked]> wrote:
> 
>>> Purpose:
>>> 

It more than expanding the acronyms.  In this case expanding the acronyms wouldn’t solve the problem, the actual text is pretty broken.  It is one run-on sentence.

We could do a lot better here.

Bob

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Apr 2015 18:18:51 -0700

> It more than expanding the acronyms.  In this case expanding the
> acronyms wouldn’t solve the problem ...
> 

the problem is that these are not written with the general ietf audience
in mind, meaning folk from optical to apps [0].  they are written for folk
already familiar with the subject.

randy

---

[0] - well, i guess we now cover politics and social behavior too,
      pretty much everything except simplicity and sparce design

---

From: Bob Hinden <[email-masked]>
Date: Fri, 3 Apr 2015 08:30:52 -0700

Randy,

> On Apr 2, 2015, at 6:18 PM, Randy Bush <[email-masked]> wrote:
> 

I agree.  If these notices are sent to the IETF list, they should be written to be understandable to the general IETF audience.  Otherwise, what is the point of sending them to the IETF list.

Bob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 3 Apr 2015 11:55:30 -0400

> I agree.  If these notices are sent to the IETF list, they should be written to be understandable to the general IETF audience.  Otherwise, what is the point of sending them to the IETF list.

Another part of the problem is that often pre-WG lists are formed on
the basis of a solution rather than a set of requirements.

Often the solutions in question are hobbyhorses or factional and
acronyms are used to bias the decision.

For example, lets say there was a nonWG list looking at email security
approaches using the DNS, using DNSSEC, using DANE. These are actually
very different statements. The first is a research proposal, the
second is an engineering effort, the third is a fan club.

There is a big difference between focus and censorship. The way a lot
of folk try to get their way is to frame the scope of a problem so
that their proposal is the only one that fits. That is a good way to
get your way in IETF, it is a losing prospect when you are trying to
get deployment.

If people don't even want to have open discussion in non-WG lists then
the epistemic closure is complete.

---

From: Benson Schliesser <[email-masked]>
Date: Fri, 03 Apr 2015 10:03:06 -0700

> the basis of a solution rather than a set of requirements.

On the other hand, a solution implemented in running code helps the 
process. If our goal is interoperable specifications (e.g. standards) 
then it's good to use such solutions as a basis. There still is value in 
understanding the context (requirements, use-cases, etc) but IMHO we 
should remember that those are ancillary.

Cheers,
-Benson

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 3 Apr 2015 13:12:40 -0400

I totally agree. There is far too much focus on nailing down %100 of requirements in the recent IETF past, hindering progress on solutions.  Both implementations and requirements are refined by the iterative process of implementation and deployment feedback.

Tom

> On Apr 3, 2015, at 1:03 PM, Benson Schliesser <[email-masked]> wrote:
> 
> On the other hand, a solution implemented in running code helps the process. If our goal is interoperable specifications (e.g. standards) then it's good to use such solutions as a basis. There still is value in understanding the context (requirements, use-cases, etc) but IMHO we should remember that those are ancillary.
> 
> Cheers,
> -Benson
> 
>

---

From: "Russ White" <[email-masked]>
Date: Fri, 3 Apr 2015 15:37:04 -0400

> I totally agree. There is far too much focus on nailing down %100 of
> requirements in the recent IETF past, hindering progress on solutions.
Both
> implementations and requirements are refined by the iterative process of
> implementation and deployment feedback.

We do seem to have lost at least some of -- "build a flexible protocol
around a core set of problems, get it done, and then modify it later." We
seem to be in "boil the ocean" mode almost constantly any more.

Russ