Subject: "why I quit writing internet standards"

From: "George, Wes" <[email-masked]>
Date: Mon, 14 Apr 2014 11:08:10 -0400

I’m surprised that no one has sent this out yet: http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/

"Summary: After contributing to standards organizations for more than seven years, engineer Vidya Narayanan decided it was time to move on. Although she still believes that these organizations make the Internet a better place, she wonders about the pace of change versus the pace of organizations."

My thoughts-

There are some nuggets of truth in what she says in this article, and in some of the comments. I think that the problems are real, so there’s value in taking the criticism constructively, despite the fact that the author chose to focus on the problems without any suggestions of solutions.

"while the pace at which standards are written hasn’t changed in many years, the pace at which the real world adopts software has become orders of magnitude faster."
…
"Running code and rough consensus, the motto of the IETF, used to be realizable at some point. … In the name of consensus, we debate frivolous details forever. In the name of patents, we never finish.”
…
"Unless these standards organizations make radical shifts towards practicality, their relevance will soon be questionable.”

I don’t have too many big ideas how to fix these problems, but I’ll at least take a crack at it in order to spur discussion. My paraphrase of the problem and some discussion follows.

- We’ve lost sight of consensus and are too often derailed by a vocal minority of those willing to endlessly debate a point.

Part of the solution to that is reiterating what consensus is and is not, such as draft-resnick-on-consensus so that we don’t confuse a need for consensus with a need for unanimity. Part of the solution is IETF leadership helping to identify when we have rough consensus encumbered by a debate that will never resolve itself, without quieting actual disagreement that needs continued discussion in order to find a compromise. I don’t have good suggestions on how to make that second half better.

- We don’t have nearly enough focus on running code as the thing that helps to ensure that we’re using our limited cycles on getting the right things out expediently, and either getting the design right the first time, or failing quickly and iterating to improve

The solution here may be that we need to be much more aggressive at expecting any standards track documents to have running code much earlier in the process. The other part of that is to renew our focus on actual interop standards work, probably by charter or in-group feedback, shift focus away from BCP and info documents. Perhaps when considering whether to proceed with a given document, we need test as to whether it’s actively helpful/needed and ensure that we know what audience would be looking at it, rather than simply ensuring that it is “not harmful” and mostly within the WG’s chartered focus.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: David Meyer <[email-masked]>
Date: Mon, 14 Apr 2014 08:57:14 -0700

On Mon, Apr 14, 2014 at 8:08 AM, George, Wes <[email-masked]> wrote:
> I’m surprised that no one has sent this out yet:
> http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/
>
> "Summary: After contributing to standards organizations for more than seven
> years, engineer Vidya Narayanan decided it was time to move on. Although she
> still believes that these organizations make the Internet a better place,
> she wonders about the pace of change versus the pace of organizations."
>
> My thoughts-
>
> There are some nuggets of truth in what she says in this article, and in
> some of the comments. I think that the problems are real, so there’s value
> in taking the criticism constructively, despite the fact that the author
> chose to focus on the problems without any suggestions of solutions.
>
> "while the pace at which standards are written hasn’t changed in many years,
> the pace at which the real world adopts software has become orders of
> magnitude faster."
> …
> "Running code and rough consensus, the motto of the IETF, used to be
> realizable at some point. … In the name of consensus, we debate frivolous
> details forever. In the name of patents, we never finish.”
> …
> "Unless these standards organizations make radical shifts towards
> practicality, their relevance will soon be questionable.”
>
> I don’t have too many big ideas how to fix these problems, but I’ll at least
> take a crack at it in order to spur discussion. My paraphrase of the problem
> and some discussion follows.
>
> - We’ve lost sight of consensus and are too often derailed by a vocal
> minority of those willing to endlessly debate a point.
>
> Part of the solution to that is reiterating what consensus is and is not,
> such as draft-resnick-on-consensus so that we don’t confuse a need for
> consensus with a need for unanimity. Part of the solution is IETF leadership
> helping to identify when we have rough consensus encumbered by a debate that
> will never resolve itself, without quieting actual disagreement that needs
> continued discussion in order to find a compromise. I don’t have good
> suggestions on how to make that second half better.
>
> - We don’t have nearly enough focus on running code as the thing that helps
> to ensure that we’re using our limited cycles on getting the right things
> out expediently, and either getting the design right the first time, or
> failing quickly and iterating to improve
>
> The solution here may be that we need to be much more aggressive at
> expecting any standards track documents to have running code much earlier in
> the process. The other part of that is to renew our focus on actual interop
> standards work, probably by charter or in-group feedback, shift focus away
> from BCP and info documents. Perhaps when considering whether to proceed
> with a given document, we need test as to whether it’s actively
> helpful/needed and ensure that we know what audience would be looking at it,
> rather than simply ensuring that it is “not harmful” and mostly within the
> WG’s chartered focus.

My friend @colin_dixon pointed this out to me yesterday, and I've been
giving it quite a bit of thought since then (I have a nascent blog on
the topic of how open source and standards orgs might
productively/efficiently work together; follow up to
http://www.sdncentral.com/education/david-meyer-reflections-opendaylight-open-source-project-brocade/2014/03).

What I can say is that after seeing the kind of progress that several
open source communities make (they do epitomize the best of the IETF's
running code/rough consensus ethic), one does have to wonder if
traditional standards making is either obsolete or in dire need of a
make over. What is needed, IMO, is a reimagining of how the standards
process interacts with the open source movement specifically focused
on how they can compliment one another.

--dmm

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 12:02:05 -0400

>> on how they can compliment one another.

Funny - I spent years pointing out to folks the advantages of the RFC 
process and IETF, over traditional standards bodies and procedures 
(e.g., ISO).  And here we are thinking about IETF as "traditional."

Then again, the current DMARC debacle presents a cautionary tale of more 
ad hoc approaches.

One example that comes to mind is RSS and Atom - started outside, then 
pulled under the IETF process.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Alia Atlas <[email-masked]>
Date: Mon, 14 Apr 2014 12:07:41 -0400

> on how they can compliment one another.

[Alia] It would be very useful to have a functional model for how the
two can compliment each other.  We also tend to talk about open-source
as a single monolith - when it can have very different models for
accepting in changes, how and who runs the community, who is really
participating (open source doesn't mean non-corporate) etc.   Some of
what the IETF does is the architecture and requirements thinking about
how the solution should fit in - while some of the open-source is
about getting a solution implemented ASAP.   IMHO, a spiral is useful
with an easy way of interaction.  With I2RS, as a WG chair, I
suggested having experimental drafts describing solutions that were
being implemented - but haven't seen any.   A question is what is
needed to encourage the interactions.

[Alia] Diversity of implementation is important as is stability of a
standard and it being understood how to change/upgrade for different
versions.  These don't come automatically via open-source.

Regards,
Alia

---

From: Christian de Larrinaga <[email-masked]>
Date: Mon, 14 Apr 2014 17:09:38 +0100

Two observations.

First her point that the pace of change at " which the real world adopts
software has become orders of magnitude faster."

This is true at the applications layer but Internet layer has not seen
fast adoption of new services and protocols by networks. IPv6 has been
dismally slow.  This maybe one reason why IoT deployments are focussing
at application layer services and ignoring IP other than implement
ICE/STUN/TURN which otherwise would be unrequired complication.

Much of this has been outside standardisation controls being in the
decision making hands of the financial managers of network operators and
their customers.

Secondly maybe she should have stood for the IAB. We should have people
involved who are prepared to shake not just the cobwebs but the
spiders.  Somehow the link between having power (knowledge etc) for
defining "standards" and having the power to define their adoption have
diverged.

If true then IETF could benefit from having more users and operators (of
all sizes and shapes) involved - perhaps?

C

George, Wes wrote:
> I’m surprised that no one has sent this out
> yet: http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/
>
> "Summary: After contributing to standards organizations for more than
> seven years, engineer Vidya Narayanan decided it was time to move on.
> Although she still believes that these organizations make the Internet
> a better place, she wonders about the pace of change versus the pace
> of organizations."
>
> My thoughts-
>
> There are some nuggets of truth in what she says in this article, and
> in some of the comments. I think that the problems are real, so
> there’s value in taking the criticism constructively, despite the fact
> that the author chose to focus on the problems without any suggestions
> of solutions.
>
>     "while the pace at which standards are written hasn’t changed in
>     many years, the pace at which the real world adopts software has
>     become orders of magnitude faster."
>     …
>     "Running code and rough consensus, the motto of the IETF, used to
>     be realizable at some point. … In the name of consensus, we debate
>     frivolous details forever. In the name of patents, we never finish.”
>     …
> I don’t have too many big ideas how to fix these problems, but I’ll at
> least take a crack at it in order to spur discussion. My paraphrase of
> the problem and some discussion follows.
>
> Part of the solution to that is reiterating what consensus is and is
> not, such as draft-resnick-on-consensus so that we don’t confuse a
> need for consensus with a need for unanimity. Part of the solution is
> IETF leadership helping to identify when we have rough consensus
> encumbered by a debate that will never resolve itself, without
> quieting actual disagreement that needs continued discussion in order
> to find a compromise. I don’t have good suggestions on how to make
> that second half better.
>
> - We don’t have nearly enough focus on running code as the thing that
> helps to ensure that we’re using our limited cycles on getting the
> right things out expediently, and either getting the design right the
> first time, or failing quickly and iterating to improve
>
> expecting any standards track documents to have running code much
> earlier in the process. The other part of that is to renew our focus
> on actual interop standards work, probably by charter or in-group
> feedback, shift focus away from BCP and info documents. Perhaps when
> considering whether to proceed with a given document, we need test as
> to whether it’s actively helpful/needed and ensure that we know what
> audience would be looking at it, rather than simply ensuring that it
> is “not harmful” and mostly within the WG’s chartered focus.
>
> Thanks,
>
>   
>
> Wes George
>
>
> ------------------------------------------------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is intended
> solely for the use of the individual or entity to which it is
> addressed. If you are not the intended recipient of this E-mail, you
> are hereby notified that any dissemination, distribution, copying, or
> action taken in relation to the contents of and attachments to this
> E-mail is strictly prohibited and may be unlawful. If you have
> received this E-mail in error, please notify the sender immediately
> and permanently delete the original and any copy of this E-mail and
> any printout.

-- 
Christian de Larrinaga
FBCS, CITP, MCMA
-------------------------
@ FirstHand
-------------------------
+44 7989 386778
[email-masked]
-------------------------

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Apr 2014 09:11:26 -0700

On Mon, Apr 14, 2014 at 8:08 AM, George, Wes <[email-masked]>wrote:

>  I'm surprised that no one has sent this out yet:
> Although she still believes that these organizations make the Internet a
> better place, she wonders about the pace of change versus the pace of
> organizations."
>
>  My thoughts-
>
> some of the comments. I think that the problems are real, so there's value
>  "while the pace at which standards are written hasn't changed in many
> years, the pace at which the real world adopts software has become orders
> of magnitude faster."
> ...
>
>
I think this issue (used to be called "timeliness") is critical and
continues to be overlooked.
The charter milestones are just not that relevant to the process, and it
shows.
It takes a long time to go from individual I-D -00 to RFC.

IMO all WGs behind schedule should be taking steps to finish faster, like
monthly virtual interim meetings, real interim meetings, etc.  More remote
meeting and project management tools might help some.

> realizable at some point. ... In the name of consensus, we debate frivolous
> details forever. In the name of patents, we never finish."
> ...
> practicality, their relevance will soon be questionable."
>
>   I don't have too many big ideas how to fix these problems, but I'll at
> least take a crack at it in order to spur discussion. My paraphrase of the
> problem and some discussion follows.
>
>  - We've lost sight of consensus and are too often derailed by a vocal
> not, such as draft-resnick-on-consensus so that we don't confuse a need for
> consensus with a need for unanimity. Part of the solution is IETF
> leadership helping to identify when we have rough consensus encumbered by a
> debate that will never resolve itself, without quieting actual disagreement
> that needs continued discussion in order to find a compromise. I don't have
> good suggestions on how to make that second half better.
>
>
Consensus is the real commodity here.
Perhaps vendors are figuring out they can get a better outcome by
contributing
to corporate open-source projects instead of SDOs.
Customers just want software that works with their equipment.

Vendor engineers just want to work together to produce a solution
that meets the requirements for the specific upcoming release.
There is no way for "bad actors" who want to stall or delay the
effort to have any influence on the engineering.  There is no
tail-heavy review process to introduce extraordinary delays.

>  - We don't have nearly enough focus on running code as the thing that
> helps to ensure that we're using our limited cycles on getting the right
> things out expediently, and either getting the design right the first time,
> or failing quickly and iterating to improve
>
>
With the open-source approach to consensus, running code is the entire
focus.
This is a bug and a feature.  The documentation quality is much higher in
the IETF.

> expecting any standards track documents to have running code much earlier
> in the process. The other part of that is to renew our focus on actual
> interop standards work, probably by charter or in-group feedback, shift
> focus away from BCP and info documents. Perhaps when considering whether to
> proceed with a given document, we need test as to whether it's actively
> helpful/needed and ensure that we know what audience would be looking at
> it, rather than simply ensuring that it is "not harmful" and mostly within
> the WG's chartered focus.
>
>
Generally it is very time-consuming to implement a protocol I-D in progress.
The draft will change so radically and so often before the final RFC is
published,
that lots of code will get re-written in the effort.  People are told "too
bad, it's
just a work-in-progress", but that doesn't help promote early
implementations.

The IETF needs to reduce the cost of consensus somehow.

 Thanks,
> Wes George
Andy

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 14 Apr 2014 17:17:01 +0100

I was thinking of why many quit reviewing adopted IETF drafts (or even quit
participating). In my situation there is a draft adopted in 6Lo WG and
still the author does not answer my question reminder, and it may make me
quit reviewing as well. I think IETF does not have problem of
participants quit to write but participants quit to review and contribute
more into drafts.

AB

On Monday, April 14, 2014, George, Wes wrote:

>  "while the pace at which standards are written hasn’t changed in many
> not, such as draft-resnick-on-consensus so that we don’t confuse a need for
> that needs continued discussion in order to find a compromise. I don’t have
> helps to ensure that we’re using our limited cycles on getting the right
> proceed with a given document, we need test as to whether it’s actively
> it, rather than simply ensuring that it is “not harmful” and mostly within
> the WG’s chartered focus.
>
>  Thanks,
>
>
>
> Wes George
>
>
> ------------------------------
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 11:19:32 -0500

The IETF, when it is functioning well, does a good job of documenting, debugging and refining work that is brought to us.   When we innovate, it's usually some team of individuals who has the innovative idea, and then they decide they want to do it in the context of the IETF.   There's nothing wrong with doing this, but there is a cost to doing it.   We can certainly work to minimize the cost that we impose, but I don't think we ought to change the basic mechanism whereby we do standards in order to optimize this use case: in doing so we would be letting go of what we do well.

An open source project that gets a prototype working well may or may not actually have something.   To the extent that they have made an incremental change to an existing standard, or layered what they have done on top of existing standards, there may well be little left to do.   Then the IETF process may feel like a straitjacket.

On the other hand, consider a project like Diaspora (in the abstract, please—I am not suggesting the IETF take it on).   Diaspora was invented by people who didn't entirely know what they were doing, and exists essentially as an implementation, not as a standard.   When I've looked at hacking on it, I've thrown my hands up in disgust because there's no documentation at the level that would allow me to do an independent implementation.   I think the security is also half-baked, and could have benefited from some IETF process.

Projects _like_ this can definitely benefit from IETF process.   Up to a point, you are innovating and learning, and probably the most heavyweight IETF-like process you can afford is to publish work in progress through the ISE, or as individual submissions.   But at some point you have something that you think is a result, and then it's time to write an interoperable implementation and get some peer review to shake out issues.   This is when the IETF can help, and when the IETF should help.

So I don't mean to say there's no problem here to solve, but I think the basic idea that because open source is innovating without us, we need to fundamentally change what we do, is mistaken.

To put it more positively, I think that IETF is an enabling technology for open source, and that there is a strong positive feedback loop between a successful open source project and a successful, related IETF process.   And this is true even in cases where some participants are doing closed-source projects.

So I think the things Wes outlined as weaknesses in the IETF are quite correct, and we should work on them, but let's not throw the baby out with the bathwater.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Apr 2014 12:34:40 -0400

George, Wes <[email-masked]> wrote:
    > - We don’t have nearly enough focus on running code as the thing that helps to
    > ensure that we’re using our limited cycles on getting the right things out
    > expediently, and either getting the design right the first time, or failing
    > quickly and iterating to improve

    > The solution here may be that we need to be much more aggressive at expecting
    > any standards track documents to have running code much earlier in the
    > process.

For instance, had DMARC proponents and/or Yahoo, spent some time making sure
that there was some running code for mailing list use, life would be better.

I'm not entirely clear how it was that we produced/funded (more) running code in the
1990s.  Maybe this is a false idea; it could be that there was less code then
than there is now.   I will posit several factors:
  1) there was less working occuring, and perhaps over a longer time period
     (where time is subject to perception as well as reality), such that
     code became mature sooner in the specification process, and/or there
     were simply more volunteers willing to produce it.

  2) many companies were much smaller, and it was easier to get line managers
     to see why they wanted to be directly involved, even lead, efforts.

  3) it wasn't so much the dotcom boom which made money available via VCs,
     but rather that the (ultimately unstainable) revenue doubling, quarter
     over quarter which made resources available for prototypes.

  4) there were some clear institutions (MIT, CMU, Berkeley, LLBL, UW) where
     some good reference implementations were developed by students, faculty,
     staff.  And don't forget WIDE and USAGI!!!

When I founded Xelerance, it was with the idea that multiple large
organizations were shipping IPsec code on Linux, and would rather pay a
company a maintenance fee than attempt to manage the process internally.
We got some work funded, but we never got enough funding to get ahead of
the standardization process and write code will an ID was still young.
Overall, that effort failed.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 14 Apr 2014 12:48:36 -0400

AB

One thing I've stumbled across as WG Chair and Attempting to shepherd 
documents through the process is if you're not vigilant, that some 
comments or questions get lost in the process.

I like where httpbis WG has gone in using github for tracking issues 
raised during the document process. I think it has two useful cases: 1) 
when working with other groups outside IETF, it presents a nice 'neutral 
spot' for collaboration, and 2) their issue tracker is more lightweight 
and robust than the existing tools.

I think Ted's comment is right - we innovate when some group tries 
something to see if makes them more productive.

tim

On 4/14/14, 12:17 PM, Abdussalam Baryun wrote:
> I was thinking of why many quit reviewing adopted IETF drafts (or
> even quit participating). In my situation there is a draft adopted in
> 6Lo WG and still the author does not answer my question reminder, and
> it may make me quit reviewing as well. I think IETF does not have
> problem of participants quit to write but participants quit to review
> and contribute more into drafts.
>
> AB
>
>     "Summary: After contributing to standards organizations for more
>     than seven years, engineer Vidya Narayanan decided it was time to
>     move on. Although she still believes that these organizations make
>     the Internet a better place, she wonders about the pace of change
>     versus the pace of organizations."
>
>     My thoughts-
>
>     There are some nuggets of truth in what she says in this article,
>     and in some of the comments. I think that the problems are real, so
>     there’s value in taking the criticism constructively, despite the
>     fact that the author chose to focus on the problems without any
>     suggestions of solutions.
>
>         "Running code and rough consensus, the motto of the IETF, used
>         to be realizable at some point. … In the name of consensus, we
>         debate frivolous details forever. In the name of patents, we
>         never finish.”
>         …
>         "Unless these standards organizations make radical shifts
>         towards practicality, their relevance will soon be questionable.”
>
>     I don’t have too many big ideas how to fix these problems, but I’ll
>     at least take a crack at it in order to spur discussion. My
>     paraphrase of the problem and some discussion follows.
>
>     - We’ve lost sight of consensus and are too often derailed by a
>     vocal minority of those willing to endlessly debate a point.
>
>     need for consensus with a need for unanimity. Part of the solution
>     is IETF leadership helping to identify when we have rough consensus
>     quieting actual disagreement that needs continued discussion in
>     order to find a compromise. I don’t have good suggestions on how to
>     make that second half better.
>
>     - We don’t have nearly enough focus on running code as the thing
>     that helps to ensure that we’re using our limited cycles on getting
>     the right things out expediently, and either getting the design
>     right the first time, or failing quickly and iterating to improve
>
>     considering whether to proceed with a given document, we need test
>     as to whether it’s actively helpful/needed and ensure that we know
>     what audience would be looking at it, rather than simply ensuring
>     that it is “not harmful” and mostly within the WG’s chartered focus.
>
>     Thanks,____
>
>     __ __
>
>     Wes George____
>
>
>     proprietary information, which is privileged, confidential, or
>     subject to copyright belonging to Time Warner Cable. This E-mail is
>     intended solely for the use of the individual or entity to which it
>     is addressed. If you are not the intended recipient of this E-mail,
>     you are hereby notified that any dissemination, distribution,
>     copying, or action taken in relation to the contents of and
>     attachments to this E-mail is strictly prohibited and may be
>     unlawful. If you have received this E-mail in error, please notify
>     the sender immediately and permanently delete the original and any
>     copy of this E-mail and any printout.
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Apr 2014 09:56:16 -0700

On Mon, Apr 14, 2014 at 9:07 AM, Alia Atlas <[email-masked]> wrote:

> seven
> years,
> least
> not,
> >> such as draft-resnick-on-consensus so that we don't confuse a need for
> leadership
> >> continued discussion in order to find a compromise. I don't have good
> helps
> >> to ensure that we're using our limited cycles on getting the right
> things
> earlier in
> >> with a given document, we need test as to whether it's actively
> >> rather than simply ensuring that it is "not harmful" and mostly within
> the
> >> WG's chartered focus.
> >

+1

I was going to mention OpenDaylight as a cooperation model.
I think their goal is to provide implementation feedback to
the I2RS, NETMOD, and other WGs.

The corporate acceptance of open-source software is the key trend.
I would not characterize any of these well-funded projects as
quick-and-dirty, or "solution implemented ASAP" (any more than
every commercial project I've worked on in my career. :-)

> versions.  These don't come automatically via open-source.
Right.  Vendors have to decide to contribute engineering hours to a project,
similar to the decision to let engineers contribute to SDOs.

Open-source software can move the "standards boundary"
and achieve multi-vendor support at the north-bound API only.
For example, a vendor can provide a proprietary Python plug-in
(e.g. OpenStack Neutron) for an open-source platform, without
standardizing the south-bound protocols.

Regards,
Andy

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 14 Apr 2014 19:01:05 +0200

Hi,

I read the post from Vidya and I have to say I totally agree with her. As to running code, in particular, my impression is that if you are used to implement prototypes of ongoing standards and you're neither a big company nor a member of the IETF elite of gurus, the best you can buck for is an informational "call flows" RFC. Standards Track stuff is left to those who (seem to) do the high-level specification work. This happens because people seem to rush for editing documents as soon as a new WG is chartered, but then they progressively reduce efforts when such a WG starts to lose momentum and is not latest fashion any longer.
Finally, coming to interoperability, it is hard to work on it if your implementation is the only one available. In the long run, I do acknowledge the fact that you get tired of doing all that hard work and investing so many cycles in a highly underestimated engineering activity.

My two cents,

Simon

> Overall, that effort failed.

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 13:07:17 -0400

It probably also helped, back in the day, that so many people working on 
protocols were doing so under funded grants.

Miles

Simon Pietro Romano wrote:
> Hi,
>
> I read the post from Vidya and I have to say I totally agree with her. 
> As to running code, in particular, my impression is that if you are 
> used to implement prototypes of ongoing standards and you're neither a 
> big company nor a member of the IETF elite of gurus, the best you can 
> buck for is an informational "call flows" RFC. Standards Track stuff 
> is left to those who (seem to) do the high-level specification work. 
> This happens because people seem to rush for editing documents as soon 
> as a new WG is chartered, but then they progressively reduce efforts 
> when such a WG starts to lose momentum and is not latest fashion any 
> longer.
> Finally, coming to interoperability, it is hard to work on it if your 
> implementation is the only one available. In the long run, I do 
> acknowledge the fact that you get tired of doing all that hard work 
> and investing so many cycles in a highly underestimated engineering 
> activity.
>
> My two cents,
>
> Simon
>
>
>> George, Wes <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>> that helps to
>>> expecting
>> Michael Richardson <[email-masked] 
>> <mailto:[email-masked]>>, Sandelman Software Works
>  e-mail: [email-masked] <mailto:[email-masked]>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 10:12:14 -0700

On Mon, Apr 14, 2014 at 8:08 AM, George, Wes <[email-masked]>wrote:

> [...]

Hi Wes,

I'm so glad you posted this.  I imagine there's a large community of
engineers, open source and otherwise, that avoid getting involved in
standards work in the first place specifically for the reasons this article
and this thread are highlighting.

There's a large part of my time in the IETF, spanning several employers of
varying sizes, that has been frustrating because there are serious pain
points that need solving, but even creative solutions are often stymied by
a wall of objection rather than curiosity and exploration.  It's exhausting
to want to make the Internet work better but be told time and again that
it's as good as it can get, and that fixing what's broken would cost too
much because any useful change would just be too disruptive (though
sometimes only to a vocal minority).  Worse, I've bought the argument, and
thus (sadly) started doing the same thing to others, in direct conflict
with my open source roots and other similar influences.

The DMARC issue at hand is possibly a good, though extreme, example.  Part
of the email community is suffering a great deal of pain because of the
abuse brought about by the fact that definitions made 30 years ago have
evidently not scaled to the modern Internet.  Previous efforts at solutions
have drawn huge investments of time and energy, but ultimately have had
limited (i.e., almost no) effect in the name of being purely incremental
and non-disruptive, brought on by a few who cling tenaciously to the status
quo.  Finally one operator had enough and did something terribly drastic,
presumably because no solution has been forthcoming in a decade or more.
>From where I sit, it looks a lot like we, the IETF, have failed to produce
workable solutions, opting instead to come to consensus on a "Sorry, it is
what it is" posture.  This is the result.

I believe in standards work, and I find the work very stimulating when it
actually makes progress.  But I also get tired sometimes of having to
explain to my employers, who foot the bill for my participation, why I'm
still going, because the impact just isn't there.

-MSK

---

From: David Meyer <[email-masked]>
Date: Mon, 14 Apr 2014 10:14:16 -0700

On Mon, Apr 14, 2014 at 9:56 AM, Andy Bierman <[email-masked]> wrote:
>> >> in

BTW, this is one area where the open source development methodology
(and communities) doesn't operate in the same way traditional
standards orgs do (e.g., IETF). Code diversity arises *inside the
project* (in the same way consensus does). Note that this is
fundamentally different than the black box model that we have at the
IETF, and is one of the key reasons while multiple implementations are
important; we can't see anything but what's on the wire. Obviously
this is (fundamentally) not the case with open source. In addition, if
all we can see is what's on the wire then it makes very good sense to
also want to be able to verify whether a protocol is sufficiently
specified to enable interoperable implementations.

A  question one might ask to try to elucidate the difference is
whether it makes sense to ask if there are multiple interoperable
implementations of say, OpenStack? Equivalently, does it make sense to
ask what interoperates with OpenStack?

--dmm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 10:14:19 -0700

> Then again, the current DMARC debacle presents a cautionary tale of more
DMARC's proponents tried to come to the IETF to form a working group so
that it could undergo the rigors of standards development, and thus not be
as "ad hoc" as you're describing.  It was not accepted, on the basis that,
in essence, the work was already done so there's nothing for the IETF to
contribute.

(If I've mischaracterized this, I'm happy to be corrected.)

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 10:17:23 -0700

> that there was some running code for mailing list use, life would be
They did, and there is:

https://launchpad.net/mailman/2.1/2.1.16

-MSK

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 13:36:49 -0400

Murray S. Kucherawy wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>

Well... an awful lot of folks run other list software - listserve, 
listproc, majordomo, ezmlm, sympa (what I run) - it might have 
represented good citizenship if Yahoo had contributed patches to, say, 
the top half dozen open-source list management packages, and had 
discussions with the commercial vendors - before propagating p=reject.

Miles

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 Apr 2014 17:44:51 -0400

> "while the pace at which standards are written hasn't changed in

This is key, in a way.  But the pace at which software has been
adopted hasn't changed.  Nor has the pace at which the real world
adopts *interoperable protocols* changed -- and that has always been
much slower.  What has happened is that a lot of the focus (and money
and employment) has moved from adopting new protocols to adopting new
software, software which is under no interoperation constraints.

A simpler comparison is between the compilers for two languages:
Fortran and Perl.  There have been many, many Fortran compilers
written, and at any era, there has been the effort to standardize the
language that the compilers accept, so that a program can be compiled
using more than one compiler.  In reality, to ensure that the
compilers interoperate.

Now look at Perl.  There has only been one compiler in all of history,
so that any Perl program that works on one computer works on every
computer that implements Perl -- because it's always run using the
same compiler.

In this case, it is a side-effect of open source, I think, because
open source eliminates the financial pressure on computer vendors to
write their own compilers for a language.

A similar thing has been happening in other fields.  An internal
feature can be added to Apache and distributed to the world in
months.  But adding a feature to HTTP can take years, because it has
to be designed and implemented to be interoperable -- in this case,
between the HTTP servers and the HTTP clients.

In the current Internet business, a lot of the new business is at the
application layer, and it is composed of "walled garden" web sites,
which don't have to interoperate with anything else.  In the more
elaborate cases, the user's web browser effectively downloads the
client software at the point when the user accesses the server.  There
are no true interoperability constraints.

In situations where you are going to need "two independently-developed
interoperable implementations", a standards process is still needed.
But there are a lot of high-profile situations where that isn't
needed.

In regard to speeding up the standards process, it's clear that in
most cases, the process could in principle be carried out much faster.
In all the cases I've observed, the major problem is that the
participants can only spend a small fraction of their working hours on
the standards discussion.  I assume this is because it's rare that
getting the standard completed is gating to shipping their employer's
product.

Dale

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Apr 2014 23:28:20 -0400

> (If I've mischaracterized this, I'm happy to be corrected.)

If that's true, it's my impression it's true because the DMARC proponents 
insisted any possible working group charter preclude meaningful changes to the 
base specification because the work was already done.

Personally, I was kind of OK with the current plan, although I thought it far 
from ideal because I thought there was a clear understanding among the DMARC 
proponents about what kinds of domains p=reject was appropriate for (not ones 
with real users that commonly use use cases for which p=reject is 
problematic).

Now that that clearly isn't the case, I think the plan needs to be revisited.

Scott K

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 23:41:03 -0400

> Now that that clearly isn't the case, I think the plan needs to be revisited.

It it was clearly understood about when p=reject is/is not appropriate - 
and someone (who's corporate name begins with Y) misapplied it - is this 
not akin to the propagation of corrupted routing data, and meriting a 
comparable response from all concerned?  If done intentionally, with 
knowledge of the potential consequences - does this not tread into the 
grounds of a DDoS attack, and merit comparable response?  And if the 
perpetrator does not act to roll back their action - does that not merit 
a strong response?

I believe that there are laws against "knowingly caus[ing] the 
transmission of a program, information code, or command, and as a result 
of such conduct, intentionally causes damages without authorization to a 
protected computer” (That's from the Computer Fraud and Abuse Act.)

And.. just for the heck of it.. I reported this to CERT.  The impact on 
the systems I run has been far higher than, say, the Heartbeat 
vulnerability.  Kind of interested to see what kind of response I get.

Miles Fidelman

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Apr 2014 21:10:38 +0300

Vidya brings up some interesting points, some of it IETF-related but also some that relates how the world is evolving. For instance, the open source trend. 

But to pick another trend, so many things can now be built without any permission from anyone - including SDOs. We call this permissionless innovation, and it is a good thing. The Internet has grown, and it is not our task at the IETF to do everything, we should, however, care about evolving the core protocols.

One of Vidya's examples was the Internet of Things, and she wondered how little standards work is needed. But that is not an accident, it is by design. From my perspective what happened was that link layer technology developed to make the physical level connectivity possible and existing Internet protocols were sufficient to do 98% of what was needed. As an example, I see most of Internet of Things gadgets running on the web protocol stack. Because it just works, it is widely available, goes through every firewall, and so on. These are good things. As a consequence, places like IETF or IEEE are not developing thousands of applications for the Internet of Things, the vendors are. The union of the meter manufacturers are. And so on. There is still some core standards development necessary - as witnessed at the IETF in the form of mesh routing protocol work, various IPv6 over Foo working groups, the 6LO* working groups, the lightweight web/security protocol working groups, and so on. Fundamental and necessary efforts, but in numbers 1000x less than efforts higher up.

The IETF has its place, but it is more about being useful to the open source efforts, the permissionless innovators, and the like than trying to compete with them. How can we do this best? One avenue is working on tools that the permissionless innovation, SDN, virtualisation, IOT, and web development revolutions need underneath. We have active developments at the IETF on all of those fronts, and I suspect more is coming.

There are certainly also IETF process/organisation things that we should work on to improve. We do. Here are some things that I would like to see:

  o  Are there ways to work to mutual benefit with open source efforts (those that would benefit from an IETF-like environment)?

  o  Recognising that many successful cases of Internet technology development have been about some people somewhere making something that later required standards at which point the IETF took over. Learning to do this, and learning to do it well is important.

  o  How can we better build specs to (rough) consensus, including making sure that (an understood) vocal minority opinion does not block progress?

  o  More focus on running code.

(All my personal opinions, of course.)

Jari

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 15 Apr 2014 18:26:56 +0000

>  o  How can we better build specs to (rough) consensus, including making sure that (an understood) vocal minority opinion does not block progress?

Apply KISS . . .

>  o  More focus on running code.

. . . after this.

— 
Bjoern A. Zeeb             "Come on. Learn, goddamn it.", WarGames, 1983

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 15 Apr 2014 17:49:41 -0500

>    o  Are there ways to work to mutual benefit with open source efforts (those that would benefit from an IETF-like environment)?

... skipping down to

>    o  More focus on running code.

In roughly 2002-2004, the IETF had conversations about a specification 
level,

     Standards Track RFC > new specification level > Internet-Draft,

including a variety of proposals for "Working Group Snapshots"/"Stable 
Snap Shots". The idea was that you could declare a specific 
Internet-Draft "good enough for now", for a variety of reasons (which 
varied from proposal to proposal), and one of the reasons could be 
"we're going to stop working on this draft until we get some 
implementation experience".

Perhaps that would help us be more responsive to open source projects. 
Right now, their choices are either to implement based on an 
Internet-Draft (which gets deployed about the time it expires) or slog 
all the way to some flavor of RFC. In principle, Experimental should be 
a lower bar than Proposed Standard, but I'm not sure how much lower the 
bar is in practice.

("Maybe we don't need full IETF consensus on your idea before you figure 
out whether your idea is horrible" :-)

Spencer

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Apr 2014 01:03:38 +0200

On 16 Apr 2014, at 00:49, Spencer Dawkins <[email-masked]> wrote:

> The idea was that you could declare a specific Internet-Draft "good enough for now", for a variety of reasons (which varied from proposal to proposal), and one of the reasons could be "we're going to stop working on this draft until we get some implementation experience".

Working groups can do that today.

E.g., httpbis calls out some of their HTTP/2.0 drafts as “implementation drafts”.

Giving this qualification a slightly more formal standing (as in a place in the datatracker, an easily accessible list of implementation drafts on the web site, etc.) might help inform implementers that aren't following the entire WG mailing list traffic whether it is time to go ahead implementing.

(Of course, the interesting part will be how to properly manage the expectation of stability.)

Grüße, Carsten

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 15 Apr 2014 18:44:44 -0500

> Giving this qualification a slightly more formal standing (as in a place in the datatracker, an easily accessible list of implementation drafts on the web site, etc.) might help inform implementers…

Exactly.

> (Of course, the interesting part will be how to properly manage the expectation of stability.)

Indeed. Some proposals included a longer-than-six-months expiration 
date, and some other proposals established an archival series (the 
documents weren't called RFCs).

There are various ways to go. We'd just need to pick one.

Spencer

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 16 Apr 2014 15:31:53 +0200

On 16 Apr 2014, at 01:44, Spencer Dawkins <[email-masked]> wrote:

> Indeed. Some proposals included a longer-than-six-months expiration date, and some other proposals established an archival series (the documents weren't called RFCs).
> 

And, convincing the IESG to start treating "Experimental" as exactly what you describe (and what, I believe, they were intended for) is simply not doable?

FWIW, my personal belief is that "running code" should be a requirement for anything going std. track -- and that a (mandatory) period as Experimental prior to go std. track would yield the stable spec against which to reasonably build code, and run (interoperability) tests, fix bugs, etc. If after (pulling a number out my hat here) a year as Experimental there's no running code, then that's probably a good indicator, also, as to if this is something the IETF should bother doing....

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 16 Apr 2014 10:01:31 -0400

On 4/16/2014 9:31 AM, Thomas Clausen wrote:
> 
> FWIW, my personal belief is that "running code" should be a
> requirement for anything going std. track -- and that a (mandatory)
> period as Experimental prior to go std. track would yield the stable
> spec against which to reasonably build code, and run
> (interoperability) tests, fix bugs, etc. If after (pulling a number
> out my hat here) a year as Experimental there's no running code, then
> that's probably a good indicator, also, as to if this is something
> the IETF should bother doing....
> 

If there's no running code, or pretty concrete plans and commitments
to get there, then there's really no need for an Experimental RFC that
will get a number and last forever.  An I-D that expires in direct
conjunction with the interest and energy in it is just fine.

Experimental RFCs are for things that we're encouraging folks to get
out and play with in multiple implementations, perhaps on the real
Internet or under some specific conditions, but which may have sharp
edges or explode on impact, and need a bit more work to figure out
if we can seriously recommend the world to depend on them as Standards.

-- 
Wes Eddy
MTI Systems

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Apr 2014 17:14:42 +0300

> conjunction with the interest and energy in it is just fine.

Except that an I-D usually doesn’t get IANA allocations, so you use a number from the private space, and you have to coordinate with anyone who wants to interoperate about which private number to use.

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 16 Apr 2014 16:19:13 +0200

On 16 Apr 2014, at 16:01, Wesley Eddy <[email-masked]> wrote:

> out and play with in multiple implementations,

Isn't that *exactly* what we want to see happen before we propose things as standards?

I think that Spencer's thesis was that it didn't happen because "implementing towards something that isn't stable and which expires" (and I-D) wasn't attractive, and the bar for std.track was too high, so "something with a lower bar, which is stable and archival, but which isn't a PS" would be helpful? 

That "something" could conveniently be Experimental. 

Experimental exists already, and the experiment targeted (at least, the RTG ADs insist on Exp RFCs carrying an explicit section describing that) would simply be "to build a few implementations and see if they interoperate". (Of course, things with "sharp edges" or "things to figure out" would have a different "The Experiment" section ... )

The only required "process change" would be, that ADs treat "Experimental" as "Experimental" in their evaluation, and not at std. track (which they, currently, do). 

> perhaps on the real

Fair enough, but almost orthogonal to the point I am trying to make: going std. track without running code (it has happened, and it is happening) makes even less sense than going experimental without running code.

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 16 Apr 2014 10:31:42 -0400

On 4/16/2014 10:14 AM, Yoav Nir wrote:
> 
>> 
>> If there's no running code, or pretty concrete plans and
>> commitments to get there, then there's really no need for an
>> Experimental RFC that will get a number and last forever.  An I-D
>> that expires in direct conjunction with the interest and energy in
>> it is just fine.
> 
> Except that an I-D usually doesn’t get IANA allocations, so you use a
> number from the private space, and you have to coordinate with anyone
> who wants to interoperate about which private number to use.
> 

Sounds like a protocol design issue, in not supporting experimental
codepoint usage very well.

We fixed that recently in TCP, for instance, such that experimental
options can be used by anyone (see RFC 6994), as an example.

In any case, getting registry values only requires an RFC if it's a
really important protocol that the IESG won't approve the value for
otherwise.

-- 
Wes Eddy
MTI Systems

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 16 Apr 2014 10:32:33 -0400

> Fair enough, but almost orthogonal to the point I am trying to make: going std. track without running code (it has happened, and it is happening) makes even less sense than going experimental witho…

With DMARC as a really clear-and-present example of the dangers of not 
being more explicit about the process.

Miles Fidelman

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 16 Apr 2014 09:48:15 -0500

> Except that an I-D usually doesn’t get IANA allocations, so you use a number from the private space, and you have to coordinate with anyone who wants to interoperate about which private number to u…

All this is true, AFAICT.

In a private conversation yesterday with My Esteemed Colleague From 
Dublin, he asked why I thought we needed to pick AN answer, out of all 
the possible ways for working groups to do what we're talking about here.

Stephen was right - we don't have to pick AN answer. What's appropriate 
for some proposals may not be appropriate for other proposals (and IANA 
considerations would be one of several flavors of constraints that would 
vary across proposals).

But I think picking a few answers would be helpful.

One of the suggestions in this thread was that we put specifications 
that are thought ready for prototyping in the same place, so people who 
want to contribute to the process as implementers know where to look. 
Not saying that's the right thing to do, but it's probably something 
worth thinking about (rather than, "for that specification, in that 
working group, if they think it's ready for prototyping, you should look 
THERE, but for this other specification ...").

Finally, I'll say what I usually say at this point in the conversation, 
which is that when we were talking about stuff like this in the early 
2000s, the expectation was that we would wait until we had IETF 
consensus to modify our process BCPs. It turns out that's a really high 
bar. The IESG ended up approving https://tools.ietf.org/html/rfc3933 as 
one way to try things without making irrevocable changes to the way 
things work for everyone.

RFC 3933 is still in effect (as BCP 93), and it allows experiments with 
changes to BCPs that would go away if they turn out to be bad ideas. 
There are probably one or two reasonable process experiments that would 
be appropriate as we try to figure out ways to (as Jari suggested):

   o  ... work to mutual benefit with open source efforts (those that 
would benefit from an IETF-like environment)?

   o  ... better build specs to (rough) consensus, including making sure 
that (an understood) vocal minority opinion does not block progress?

   o  ... focus on running code.

As we said at the IETF 89 Admin Plenary when discussing TRAM and DART, 
the IESG can move pretty quickly when we get coherent proposals. Please 
talk amongst yourselves, if this matters to you.

Spencer, who (full disclosure) was co-author on RFC 3933, speaking only 
as a retired process wonk

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 16 Apr 2014 16:24:42 +0200

> Except that an I-D usually doesn’t get IANA allocations, so you use a number from the private space, and you have to coordinate with anyone who wants to interoperate about which private number to u…

Hum....I do know that there are experimental protocols that have IANA allocations (though, that may be from the olden days), and I think that there's nothing preventing an Experimental from setting up IANA registries on its own.

Furthermore, that "coordination" you talk about....wouldn't simply documenting that in the Experimental RFC suffice:

	"For the purpose of the experiments, documented in this RFC, use UDP port XXXXX, 
	 message type YYY, and error codes A, B and C from the register xxxx. Note that these
	 codepoints all are from the private/experimental spaces of their respective registries, and
	 that therefore this section does not represent IANA allocations"

Sure, the RFC would get an RFC number, but that's about it.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 16 Apr 2014 07:32:38 -0800

On 4/16/14 6:19 AM, Thomas Clausen wrote:
> I think that Spencer's thesis was that it didn't happen because
> "implementing towards something that isn't stable and which expires"
> (and I-D) wasn't attractive, and the bar for std.track was too high,
> so "something with a lower bar, which is stable and archival, but
> which isn't a PS" would be helpful?

I think that the terrain has changed a bit, or at least
that's certainly what the author of the blog post is
suggesting.  Implementation seemed to be de-emphasized
for some period, precisely because of the issues you
mention, but we're seeing more work being brought to the
IETF being driven by implementation (and here I'm
thinking of things like HIP and certificate transparency)
and frankly they seem to go a lot more smoothly in
terms of IETF process, as well.  Chartering seems to to
more smoothly and the work progresses more quickly.
The "open source" question really seems to be more
about collaboration than to do specifically with
licensing.

I'm not sure that the IETF should get more directly
involved with supporting implementation efforts but I
do think that we should recognize that work coming
in that's already been implemented tends to be more
fully-baked and privilege that in some way.  One worries
about that encouraging crappy implementation, but I'm
not sure that crappy implementation is much worse than
no implementation.

Melinda

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Apr 2014 18:08:33 +0200

> That "something" could conveniently be Experimental. 

Experimental means something different in the IETF, as in:

“This is a finished specification, but we are really not sure this will work until we have run an experiment.
Don’t base any plans on the assumption that this experiment will succeed.”

Implementation draft means:

“This is still subject to change, but we promise to be frugal in the changes we make from here on.
We are pretty sure this will work, no major experiments required, just implementation experience to maybe tweak it some more.
This will be done soon, so go ahead and build the products.”

Conflating these two almost diametrally opposed sets of features into a single class of document increases confusion.

Yes, we need to find a way for implementation drafts to get IANA numbers.
(The IANA numbers problem is bigger, e.g., downrefs from finished specs should also be in a position to get numbers immediately even if not all i’s are crossed and t’s are dotted in the downref spec.)

Grüße, Carsten

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 16 Apr 2014 18:31:43 +0200

> Don’t base any plans on the assumption that this experiment will succeed.”

I'd submit that that would be true for /any/ specification that has not been implemented and experimented with. So I think that it exactly means what I say ;)

> Conflating these two almost diametrally opposed sets of features into a single class of document increases confusion.

<sarcasm>
Oh, oh, oh, I have an idea. This "implementation draft" that you talk about, we could call that "Proposed Standard" then, because that is what we really "propose (after some implementation experience) becomes a standard". 

And when the implementation experiences and tweaks have been done, we will then publish a "Draft Standard" based on it -- and later, once we're absolutely sure, we'll promote it as an "Internet Standard".

I think that I remember a process like this, from somewhere, where might that have been .... ;)
</sarcasm>

Being serious for a moment....the IESG/IETF/IAB/someone recently decided that we needed to reduce the std. track from 3 to 2 levels. This is proposing adding the third level back, perhaps perceived "below" Proposed Standard ...

In your definitions above, "Experimental" and "Implementation Draft" both are ways of saying "Look, this is not mature enough to be a standard yet, but we're at a breaking point where we think we have something stable, that we want to get coded up, and played with".

Either we're ready to "propose a standard" and we hit std. track -- or, we're not, and need to build up some more implementation and experimental basis, in which case Experimental is the way to go. 

I much prefer using that which the RTG ADs have imposed on the RTG Area, which is for Experimental protocols to have a section discussing the experiment.  It gives the flexibility to say exactly what the document is, and why it is written -- without re-introducing a 3rd level on the std. track.

Having an "implementation draft" status that is declared by a WG alone (or by WG chairs, or perhaps the responsible AD) isn't terribly helpful in terms of overall document quality: it excludes the (often extremely valuable) cross-area reviews that occur as part of the IESG processing -- and which almost never occurs before IESG processing -- and which, occasionally, causes design decisions to be revisited profoundly.....

Sure, we can come up with a special status and process for "Implementation Draft" which captures cross-area reviews, etc -- but that'd look a lot like the process for Experimental, and would involve many of the same people.

As I always say: "if it walks like a duck, and it quacks like a duck -- then, it probably tastes good served in orange sauce"

> (The IANA numbers problem is bigger, e.g., downrefs from finished specs should also be in a position to get numbers immediately even if not all i’s are crossed and t’s are dotted in the downref spe…

That, to me, seems to be a much simpler problem to manage ;)

Thomas

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 16 Apr 2014 12:07:56 -0500

I need to go read some drafts, but on one point ...

> Conflating these two almost diametrally opposed sets of features into a single class of document increases confusion.

This was my point in mentioning https://tools.ietf.org/html/rfc3933. The 
parts of my memory of the early 2000s that I haven't successfully 
blotted out lead me to think that we were consistently making two errors 
in those discussions.

We tried to figure out *the* right answer when there probably were right 
answers with (quoting Carsten) "diametrically opposed" characteristics, 
and since we couldn't stretch one right answer over all the problems, 
nothing happened.

And we had to get IETF consensus for one answer that didn't solve all 
the problems, with no actual experience with that answer.

The IETF approved BCP 93 to give people the possibility of experimenting 
with multiple answers, dropping the answers that don't work, and keeping 
the ones that do.

The IETF discussion list has seen a lot of spilled digital ink trying to 
solve problems like these. If people want to chat and move on, that's 
fine. If people want to try to put proposals together, that's fine 
(perhaps even more fine).

But please don't make the mistakes we made more than a decade ago.

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Apr 2014 08:21:46 +1200

On 17/04/2014 03:32, Melinda Shore wrote:
...
> not sure that crappy implementation is much worse than

I don't think we should privilege it particularly. We have at
least 3 modes of working, each of which has its value:

1. Preemptive standardisation: problem statement first,
then requirements, then design, then standardise, then sit
back and wait for implementation.

2. Parallel standardisation: there's some design work and
maybe some code, then retro-fit requirements, write the specs
as the code evolves, then standardise and hope that the code is
updated to match the spec.

3. Retroactive standardisation: there's some running code that
got itself deployed; write the v1 spec to be compatible with
the code, call it a standard, then develop v1.1 or v2 and
hope the code is updated.

We've done all three, and all with varying degrees of success.
I could give examples, but that would just start arguments ;-).
It isn't reasonable to expect all standards to fit the same
model. And people who don't have the desire to work in any
of these models may well prefer to quit standards work (but
still contribute code to one of the three models).

    Brian

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 16 Apr 2014 20:49:50 -0400

> on how they can compliment one another.

	I think its the latter - a make-over or an adjustment are needed to how we work within this organization. The pendulum has clearly swung so far into the direction of over-caution, over-thinking, and over-design (i.e.: requirements, problem statements, architectures and frameworks) that the real cost is too high in terms of real dollars invested on the process, as well as real product development delay where people have to wait for the process to maybe put something out years from its onset. We also need to directly address the interference in the process by individuals and organizations who will never implement the things they are here to "work" on things in theory. In open source, code is the coin of the realm, so its very much a "put up or shut up" model; opinions don't count for much if anything. So if what you bring to the party is a code patch that everyone agrees on, thats cool, but if you just say "hey I'd like to add option X or lets do this another way", you really are out in the cold. We need to get back to a model where the opinions of those implementing things and those really deploying those things is what really is what matters.

	Until then, the most important observation is that the process has ground nearly to a halt in many areas which has resulted in a severe reduction in the speed of innovation. The market has responded and gone elsewhere. That is a fact, and denying it is unrealistic. Take note: many of us have seen and are involved in real examples of this from even traditional service providers, who are now actively demanding open source-based products and/or are even trying to launch their own agile/open source-based initiatives to foster rapid, collaborative AND interoperable product creation in leu of the IETF process.  But we need to get back to running code and rough consensus driving the process, rather than how things are now.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 16 Apr 2014 20:28:22 -0400

> needed to encourage the interactions.

	I think this is where things (start to) go wrong with the existing IETF model. We need drafts of everything is an axiom here that we should challenge. In open source, the code, its associated wiki pages and perhaps auto-gen docs are the draft and implementation agreement/documentation in question. 

	I would also challenge what has become the common new WG "formula" these days. That is the notion that requirements, problem statements or architectures are always needed and must come before the WG can work on any protocols/solutions. These are heavy burdens that have a price of slowing things down. If we want to pay that price, we'd better get something good in return. However, the road is littered with many examples of recent WGs getting nowhere after several years of work. These groups often end up in this state because frankly many of the people involved in those efforts are completely disconnected from the reality of building the things they are apparently designing. In many cases they never have built anything either, so much of the effort goes into explaining to them why things need to be a certain way/etc... Unfortunately their "veto" or influence in the process also dilutes the simplicity that an implementation would reveal (i.e.: useless options).  Its clearly the difference between theory and practice, which I think we all understand is a real thing.   The end result is that this impedance is one quantifiable reason why people have looked to over avenues such as open source, to build interoperable systems/tools/etc... quickly.   

	The solution: join the IETF process to the open source communities *where it makes sense, but not otherwise*. Open source BTW is what we used to call a rough-concensus + running code around here!
If we stick to interfaces that need "on the wire" interoperability, we are in the sweet spot. If we wade into areas where there is little value added - such as requirements/problem statements/architectures, lets not waste our time. For example, there are clearly cases where an RFC standard for something does not makes sense. Something like Open stack is a good example. The APIs are there, implemented in code you can see and documented. There is a well defined change process that identifies stable release points and also allows for quick iteration on that code/interfaces to evolve that works very quickly. Why would anyone every need an RFC for these things?  Now there really are cases where formal standardization makes sense. As I said if we stick to interfaces that need "on the wire" interop, we are squarely somewhere both open source and the IETF can add value. For example, there is a lot of code generation in open source based on yang models these days. Many of the experts around the model creation are at the IETF and not necessarily in those communities, so joining those folks to model creation can help that running code. In cases where vendors really want interop at the model level, then lets get together the vendors/operators that care, and not only build running code to test/prove those models make sense, but then run them through the IETF process in parallel.

	--Tom

---

From: Benoit Claise <[email-masked]>
Date: Thu, 17 Apr 2014 16:14:27 +0200

On 14/04/2014 18:11, Andy Bierman wrote:
>
>
>
> On Mon, Apr 14, 2014 at 8:08 AM, George, Wes 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     and in some of the comments. I think that the problems are real,
>     so there's value in taking the criticism constructively, despite
>     the fact that the author chose to focus on the problems without
>     any suggestions of solutions.
>
>         "while the pace at which standards are written hasn't changed
>         in many years, the pace at which the real world adopts
> The charter milestones are just not that relevant to the process, and 
> it shows.
We discussed during the milestones during one of the last plenaries.
The discussion was around: the milestones are indications and not deadlines.
In Open Source project, these are deadlines.
In the IETF, I would love to find a middle ground between the two.
In the IETF, the only "deadlines" are the meetings, or to be more 
precise, the submission deadlines just before the meetings.
> It takes a long time to go from individual I-D -00 to RFC.
Exactly, and we should understand why!
I like this tool: 
http://www.arkko.com/tools/lifecycle/<draft-name>-timing.html
For example: 
http://www.arkko.com/tools/lifecycle/draft-ietf-netmod-interfaces-cfg-timing.html
Where is the bottleneck? Is this a process issue? The 
authors/shepherd/IESG/RFC-editors?
I don't want to finger point, but understand what we should improve.
> meeting and project management tools might help some.
Fully agreed.
That would effectively some extra deadlines.
>         to be realizable at some point. ... In the name of consensus,
>         we debate frivolous details forever. In the name of patents,
>         we never finish."
>         ...
>         towards practicality, their relevance will soon be questionable."
>
>     I don't have too many big ideas how to fix these problems, but
>     I'll at least take a crack at it in order to spur discussion. My
>     - We've lost sight of consensus and are too often derailed by a
>     Part of the solution to that is reiterating what consensus is and
>     is not, such as draft-resnick-on-consensus so that we don't
>     confuse a need for consensus with a need for unanimity. Part of
>     the solution is IETF leadership helping to identify when we have
>     rough consensus encumbered by a debate that will never resolve
>     itself, without quieting actual disagreement that needs continued
>     discussion in order to find a compromise. I don't have good
>     - We don't have nearly enough focus on running code as the thing
>     that helps to ensure that we're using our limited cycles on
>     getting the right things out expediently, and either getting the
>     design right the first time, or failing quickly and iterating to
>     improve
>
>
> This is a bug and a feature.  The documentation quality is much higher 
> in the IETF.
yes.
IETF is about running code and consensus. Well, sadly, more about 
consensus than running-code these days.
And open source is more about running code and less about consensus
>
>     The solution here may be that we need to be much more aggressive
>     at expecting any standards track documents to have running code
>     much earlier in the process. The other part of that is to renew
>     our focus on actual interop standards work, probably by charter or
>     in-group feedback, shift focus away from BCP and info documents.
>     Perhaps when considering whether to proceed with a given document,
>     we need test as to whether it's actively helpful/needed and ensure
>     that we know what audience would be looking at it, rather than
>     simply ensuring that it is "not harmful" and mostly within the
>     WG's chartered focus.
>
>
> The draft will change so radically and so often before the final RFC 
> is published,
> that lots of code will get re-written in the effort.  People are told 
> "too bad, it's
+1.

Questions for all: practically, how?

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Thu, 17 Apr 2014 16:20:40 +0200

> when such a WG starts to lose momentum and is not latest fashion any 
Or when they made to the famous authors list of the WG document, which 
is considered at THE major achievement.
I've seen that problem a few times and it's very annoying.
I would be in favor to re-evaluate who really contributed to the 
document full life cycle when the document leaves the WG.

Regards, B.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 17 Apr 2014 15:26:36 +0100

On 16 April 2014 14:31, Thomas Clausen <[email-masked]> wrote:

> And, convincing the IESG to start treating "Experimental" as exactly what
> you describe (and what, I believe, they were intended for) is simply not
> doable?
>
> FWIW, my personal belief is that "running code" should be a requirement
> for anything going std. track -- and that a (mandatory) period as
> Experimental prior to go std. track would yield the stable spec against
> which to reasonably build code, and run (interoperability) tests, fix bugs,
> etc. If after (pulling a number out my hat here) a year as Experimental
> there's no running code, then that's probably a good indicator, also, as to
> if this is something the IETF should bother doing....
>
>
Instead of Experimental, maybe a state before the standards-track proper,
called "Proposed Standard", might work, beyond which you'd need two
interoperable implementations to demonstrate utility and functionality.

I appreciate it's a radical suggestion.

Dave.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 17 Apr 2014 16:30:49 +0200

On 17/04/2014 02:28, Thomas Nadeau wrote:
> If we stick to interfaces that need "on the wire" interoperability, we are in the sweet spot. If we wade into areas where there is little value added - such as requirements/problem statements/architectures, lets not waste our time.
> For example, there are clearly cases where an RFC standard for something does not makes sense. Something like Open stack is a good example. The APIs are there, implemented in code you can see and documented. There is a well defined change process that identifies stable release points and also allows for quick iteration on that code/interfaces to evolve that works very quickly. Why would anyone every need an RFC for these things?  Now there really are cases where formal standardization makes sense. As I said if we stick to interfaces that need "on the wire" interop, we are squarely somewhere both open source and the IETF can add value. For example, there is a lot of code generation in open source based on yang models these days. Many of the experts around the model creation are at the IETF and not necessarily in those communities, so joining those folks to model creation can help that running code. In cases where vendors really want interop at the model level, then lets get together the vendors/operators that care, and not only build running code to test/prove those models make sense, but then run them through the IETF process in parallel.
If a WG can't agree on which problem(s) it want to solve, then there is 
a problem, no?
And not sure if Open Source is the solution, unless everybody says: 
"here is my view of the problem, let me provide some code for it"

Note: I've been involved in a couple of WGs where defining a terminology 
was a time-consuming but well-worth effort, in order to produce the 
requirements/problem statement and architecture document. We're all 
engineers, and the fun part is to design protocols or write code.
However, I agree that requirements/problem statement/architecture RFCs 
should be produced way faster within the IETF. And maybe, the IESG 
should be stricter regarding deadlines for problem statements: if the WG 
can't agree on the problem statement by date D, the WG is closed.

Regards, Benoit

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 17 Apr 2014 13:35:06 -0400

On Apr 17, 2014:10:30 AM, at 10:30 AM, Benoit Claise <[email-masked]> wrote:

> If a WG can't agree on which problem(s) it want to solve, then there is a problem, no?
> And not sure if Open Source is the solution, unless everybody says: "here is my view of the problem, let me provide some code for it"

	That is precisely how things work in open source; people huddle together to solve a problem and write code to solve it. There is not much "management" needed here, nor are there any hard requirements to write problem statements, architectures, frameworks, etc.. before that process of code construction can begin.  That is what I am getting at: we need to get back to writing more code around here. Code that is used to build some goal. That is ultimately what defines what can be done.  As we iterate though that process, we arrive at the goal. 

> Note: I've been involved in a couple of WGs where defining a terminology was a time-consuming but well-worth effort, in order to produce the requirements/problem statement and architecture document. We're all engineers, and the fun part is to design protocols or write code.
> However, I agree that requirements/problem statement/architecture RFCs should be produced way faster within the IETF. And maybe, the IESG should be stricter regarding deadlines for problem statements: if the WG can't agree on the problem statement by date D, the WG is closed.

	Its important to understand what needs to be done but not necessarily how in too much detail ahead of time before real work begins; that is what is broken here in the process - we wait for literally years before we can do any real work. The IETF's process is analogous to waterfall software design and open source is more like agile development.  Anyone skilled in the art of modern software engineering knows the trade-offs between these two approaches, as well as what is used by modern software engineering done on a large scale.

	--Tom

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 17 Apr 2014 14:13:02 -0400

Thomas Nadeau wrote:
> run them through the IETF process in parallel.

Well, wait a minute.  That might be how small projects work - but not 
big ones, with large impact - like say the Linux Kernel, or Debian, or 
Apache.  Those projects have policies, procedures, configuration control 
processes, authorized committers -- it's not like a change makes it into 
the Linux kernel without going through multiple levels of review.  Not 
to mention processes for bug reporting and patching.

And... I expect that, in the aftermath of Heartbleed, a number of open 
source projects are going to be taking another look at release processes.

Miles Fidelman

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Apr 2014 23:25:07 +0300

On Apr 17, 2014, at 5:26 PM, Dave Cridland <[email-masked]> wrote:

> 
> Instead of Experimental, maybe a state before the standards-track proper, called "Proposed Standard", might work, beyond which you'd need two interoperable implementations to demonstrate utility and functionality.
> 

That’s not radical. Radical would be getting to this “proposed standard” of which you speak in a few months rather than a few years, and without achieving perfection or even Pete’s definition of rough consensus.

Yoav

---

From: S Moonesamy <[email-masked]>
Date: Thu, 17 Apr 2014 13:48:31 -0700

Hi Benoit,
>We discussed during the milestones during one of the last plenaries.

Yes.

>precise, the submission deadlines just before the meetings.

Lisa used to send monthly progress reports.  It provided some 
visibility into what was happening within the area.

A milestone can be an estimate of when X can be completed.  I might 
suggest one and the group decides whether everyone can target that 
date and plan accordingly.  There are times when deadlines may be 
needed as an effort can end up in failure.

><http://www.arkko.com/tools/lifecycle/>http://www.arkko.com/tools/lifecycle/<draft-name>-timing.html
>For example: 
><http://www.arkko.com/tools/lifecycle/draft-ietf-netmod-interfaces-cfg-timing.html>http://www.arkko.com/tools/lifecycle/draft-ietf-netmod-interfaces-cfg-timing.html

Let's see. :-)  The shepherd write-up does not provide me with much 
information.  There's three years from the first -00 to the latest 
version of the draft.  The author activity looks okay.  There is less 
activity from the document shepherd (there is an explanation for 
that).  There was a Last Call in April 2013.  The AD asked for a 
revised I-D in May 2013.  There was another Last Call in December 
2013.  The IESG didn't like something in the draft and it took seven 
months to address that.

There's still the two and a half years.  There are seven months 
between the date in the charter and the first Last Call.  It would 
take some effort to figure out what happened during the first two 
years.  It looks like the working group was the bottleneck.

Regards,
S. Moonesamy

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Apr 2014 12:12:48 +0200

Hi,
> years.  It looks like the working group was the bottleneck.
Thanks.
I'm more after analyzing trend than inspecting this particular document.
For example, https://datatracker.ietf.org/iesg/discusses/ doesn't look 
like a very long list to me.

Regards, Benoit

> .

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Apr 2014 11:13:48 -0700

On Fri, Apr 18, 2014 at 3:12 AM, Benoit Claise <[email-masked]> wrote:

>> Lisa used to send monthly progress reports.  It provided some visibility
>> into what was happening within the area.
>>
>> suggest one and the group decides whether everyone can target that date and
>> plan accordingly.  There are times when deadlines may be needed as an
>> effort can end up in failure.
>>
>>> I like this tool: <http://www.arkko.com/tools/lifecycle/>
>>> For example: <http://www.arkko.com/tools/lifecycle/draft-ietf-netmod-
>>> interfaces-cfg-timing.html>http://www.arkko.com/tools/
>>> lifecycle/draft-ietf-netmod-interfaces-cfg-timing.html
>> information.  There's three years from the first -00 to the latest version
>> of the draft.  The author activity looks okay. There is less activity from
>> the document shepherd (there is an explanation for that).  There was a Last
>> Call in April 2013.  The AD asked for a revised I-D in May 2013.  There was
>> another Last Call in December 2013.  The IESG didn't like something in the
>> draft and it took seven months to address that.
>>
>> There's still the two and a half years.  There are seven months between
>> the date in the charter and the first Last Call.  It would take some effort
>> to figure out what happened during the first two years.  It looks like the
>> working group was the bottleneck.
>>
> Thanks.

I wonder if this NETMOD draft is typical of other WGs or not.
The idstats say it has been a WG draft for 388 days.
I think the original charter was about 160 days, but I can't tell since
all the relevant milestones were deleted from the WG charter page last week.

The problem is obvious.  The WG spent lots of energy going over and over
the same issues as more new people read the draft for the first time.
 These people
often brought genuine concerns and new insights to the current solution,
and the
WG was quite willing to ignore the milestones and accommodate the new
feature
requests.

Regards, Benoit
Andy

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Apr 2014 10:08:07 -0700

> base specification because the work was already done.

That statement is incorrect.

What we pressed for was to get community rough consensus on the kinds of 
technical work that needed to be done to the -base (core) specification, 
/before/ chartering the effort.

This was explicitly to avoid the trap of declaring the existing spec 
unstable -- and that's what starting an open-ended development effort 
automatically does -- when there was no demonstrated need to do that.

In spite of repeated efforts -- in at least two venues -- to get folks 
to state what work they thought was needed and to get community support 
for that work, no tasks were produced.

That meant that any wg charter permitting changes to the protocol would 
have been entirely without any foundation based on need.

In fact, it would have a foundation of NON-need.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 20 Apr 2014 13:15:16 -0400

On Sunday, April 20, 2014 10:08:07 Dave Crocker wrote:
> > insisted any possible working group charter preclude meaningful changes to
> > the base specification because the work was already done.
> 

Right.  The alternate defense against a WG charter that allowed for anything 
more than wordsmithing was to insist that proponents of a working group go do 
the work of a working group to evaluate the protocol and figure out if it 
needed any changes before such a working group would be chartered.

That didn't make any more sense.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2014 17:20:37 -0000

>for that work, no tasks were produced.

My strong impression is that the DMARC cartel considered fixing the
fundamental problems to be out of scope, so that's kind of
tautological.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Apr 2014 10:34:05 -0700

> fundamental problems to be out of scope, so that's kind of

John,

I have no idea what you are referring to.

d/

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Apr 2014 13:52:09 -0400

> fundamental problems to be out of scope, so that's kind of

I also got the impression that the "IETF DKIM cartel" considered 
fixing fundamental problems of author domain signing practices to be 
out of scope as well.

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Apr 2014 11:18:08 -0700

> needed any changes before such a working group would be chartered.

Defense is an interest choice of words.  It tends to imply an obligation 
to start a working group even when there is no work known to be needed.

Working groups are expensive.  The costs they incur are justified only 
when there is known to be a need.

Requiring clear statements about the need is not 'defensive'; it is 
merely being professional and responsible.

d/

---

From: Douglas Otis <[email-masked]>
Date: Sun, 20 Apr 2014 11:25:56 -0700

On Apr 20, 2014, at 10:08 AM, Dave Crocker <[email-masked]> wrote:

> What we pressed for was to get community rough consensus on the kinds of technical work that needed to be done to the -base (core) specification, /before/ chartering the effort.
> 
> This was explicitly to avoid the trap of declaring the existing spec unstable -- and that's what starting an open-ended development effort automatically does -- when there was no demonstrated need to do that.
> 
> In spite of repeated efforts -- in at least two venues -- to get folks to state what work they thought was needed and to get community support for that work, no tasks were produced.
> 
> That meant that any wg charter permitting changes to the protocol would have been entirely without any foundation based on need.
> 

Dear Dave,

Each group sees need differently.  The need driving DMARC was to prevent recipients being flooded by an onslaught of transactional phishing attempts that also involved establishing improved feedback to facilitate take-downs.  Without this protection, there would be a high rate of customer loss, at least according to numbers provided by PayPal.  They felt handling their domain's email policy by setting up arrangements with each ESP did not scale.

That said, DMARC was never intended to address needs beyond the narrow scope of high value transactional email. There were early warning signs as well. Even Paypal employees initially posted to mailing-lists in clear conflict with their DMARC policy.  That behavior was then replaced by linkedin.com, e-ngine.nl, junc.eu, and yahoo.com.  There should have been clear warnings rather than expecting ESPs to deal with a flood of complaints.  

There is not enough header or transactional bandwidth to expect each email to authorize individual third-parties.  The original TPA specification would have been able to address this with very low overhead.  Is it reasonable to expect user desired third-party services to carry a high cryptographic burden for each unique message destination.  It seems better to expect these services to simply verify their domain by currently available means.  It is also common to find List-ID header fields declaring the path taken that can also be specified using TPA. TPA use could the be declared in conjunction with DMARC to allow each domain seeking protection from DMARC to make specific exceptions and effectively react to abuse.

Had SMTP been properly federated, none of this would have become a problem, and it would have also avoided pervasive monitoring. 

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Apr 2014 15:43:44 -0400

On 4/20/2014 2:25 PM, Douglas Otis wrote:
>
> That said, DMARC was never intended to address needs beyond the
>narrow scope of high value transactional email.

And unfortunately, this attitude was always wrong. Hate to say, but "I 
told you so."   What the design attitude says is this:

     If the domain is high value, then only applied policy.
     For all others, ignore it.

Well, is is "high value?"  How do you distinguish "value" in an 
anonymous world?  Must everyone have a profile in some Good Reputation 
Databases?  Fee based?  Even if we want this, we are not there yet!!

The seed to all this author domain brush back was born in the 
unfortunate RFC5016 DKIM Signing Practice requirements document last 
minute addition of item 10 in section 5.3 where it strongly mandates 
that a 1st party policy MUST NOT override the 3rd party policy.

    RFC 5016, Section 5.3

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

          Refs: Deployment Consideration, Section 4.3.

Just replace the term SSP for DMARC and you have the same thing.  This 
is where all the resistance towards author domain policies began with 
this written stone functional requirement.  This attitude is still 
among us.  Not saying its completely wrong, but it certainly not right 
either.  Yahoo proved it for us.

The irony?

Rather than try to honor policy to keep the security high, we are 
looking for ways to circumvent it.  Ignoring Policy no longer works.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 20 Apr 2014 17:30:39 -0400

>merely being professional and responsible.

That's one theory. Considering the current state of play in which DMARC isn't even being submitted to the IETF, the alternative theory that the developers of DMARC were not interested in anything other than a rubber stamp approval from the IETF seems to me to be much more consistent with the available information. 

I think I'm done with this argument. 

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Apr 2014 14:35:21 -0700

On 4/20/2014 2:30 PM, Scott Kitterman wrote:

>> Requiring clear statements about the need is not 'defensive'; it
>> is merely being professional and responsible.
>
> That's one theory. Considering the current state of play in which
> DMARC isn't even being submitted to the IETF, the alternative theory
> that the developers of DMARC were not interested in anything other
> than a rubber stamp approval from the IETF seems to me to be much
> more consistent with the available information.
>

Yes, it's always good to end with an attack on other people's integrity.

So much more comforting than dealing with the substance of the issue.
Definitely better to dismiss that out of hand.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 20 Apr 2014 18:12:41 -0400

>Definitely better to dismiss that out of hand.

Sigh.  Okay. One more.

I gave my opinion.   

There's a substantial body of discussion on both public DMARC lists and the IETF DMARC list about how we got where we are. I'm sure there were plenty of private discussions too.

Anyone who cares can review the public portions of the record and form their own opinion.   Having a difference of opinion over how it should've been done is not an attack on anyone's integrity. 

I'm certainly not the one who (I'm paraphrasing from memory, so this may not be exactly right) accused unnamed IETF insiders of subverting IETF processes.  That struck me as an attack on someone's integrity, but it wasn't me doing it.

You and I haven't and won't agree on this, so I don't see the point of wasting everyone's time continuing to argue about it. To the extent that there's a substantive issue or question at stake, I think people who care should go read the lists' archives and reach their own conclusions. 

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Sun, 20 Apr 2014 16:12:11 -0700

On Apr 20, 2014, at 12:43 PM, Hector Santos <[email-masked]> wrote:

> And unfortunately, this attitude was always wrong. Hate to say, but "I told you so."   What the design attitude says is this:
> 

Dear Hector,

You missed an important term, "transactional". Transactional email is normally NOT relayed through things like mailing-lists for example.

"high value" are messages likely to invoke responses which in turn invites a high level of phishing.  In such limited scenarios, DMARC makes very good sense.

> Rather than try to honor policy to keep the security high, we are looking for ways to circumvent it.  Ignoring Policy no longer works.

Locking the From header field to a specific source for general user mail clearly does not work and those asserting DMARC policy should know better.  If this continues, at some point many will ignore DMARC when it costs more than it is worth.  I too think we can do better, but the senders should be expected to do the heavy lifting.  Only they know which third-party services their users send messages. The TPA strategy is based on the premise third-party paths can be quickly verified by the recipients without a steep user learning curve.  TPA also creates little impact on how email is normally handled. 

Email security should be structured to support a federated service and not depend on peer to peer communications. 

Regards,
Douglas otis