Subject: RE: Observations on (non-technical) changes affecting IETF operations

From: Linda Dunbar <[email-masked]>
Date: Tue, 1 Mar 2016 18:17:04 +0000

Jari,

Very interesting write up. IMHO, the hardest challenge facing IETF is that "Internet has been working over several decades".
All the obvious technologies needed to enable Internet have been developed already. All that left are tweaks and minor improvement.

Maybe it is the time to update the goal of the IETF.
(is it still true: "The IETF brand is core Internet technology, and improving the Internet, not specifically new things.?)

We all know that the future belongs to the App & services. But people from those emerging App & services companies are way under represented in IETF.

Maybe more Heckathons effort should be invested into attracting Apps & Services companies to utilize the work developed by IETF, ...

My two cents,

Linda Dunbar

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Monday, February 29, 2016 4:04 PM
To: IETF
Subject: Observations on (non-technical) changes affecting IETF operations

A while back I had asked for volunteers to join a design team to look at (non-technical) trends and changes that relate to IETF operations.

The team has been working and they have today published an -00 draft. We'd love to have your feedback and thoughts on this topic!

The document details are below:

Title: IETF Trends and Observations

Team: Jari Arkko, Alia Atlas, Avri Doria, Tobias Gondrom, Olaf Kolkman, Steve Olshansky, Benson Schliesser, Robert Sparks, Russ White

URL:
https://tools.ietf.org/html/draft-arkko-ietf-trends-and-observations-00

Abstract:

While most of the work in the IETF is technical, the IETF should and does regularly examine itself, including its processes and goals, to determine if the technical community is truly serving the larger network engineering community effectively.  Changes in this area tend to be incremental, as is fitting for an organization with decades of experience and history in developing and managing the process of building technical specifications.

The rapid and ongoing changes in the world have recently caused a number of IETF participants to examine the current processes and operation of the IETF, particularly in the context of the culture of the IETF.  This memo discusses some cultural and global trends in relation to the IETF's operating environment, how these trends might affect the operation of the IETF, and notes some topics for further exploration.

Writing this memo has been inspired by involvement in various decisions that the IETF leadership has to take part in, often wishing to be able to draw more on understanding trends and their impact on the IETF.

This memo is also input for discussion that the IETF community should have.

The memo has no particular official standing, nor does it claim to represent more than the authors' thinking at the time of writing.
There is no intent on the part of the authors for this to be published as a RFC.  Please direct discussion about this topic to the [email-masked]<mailto:[email-masked]> mailing list.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 6 Mar 2016 16:58:19 +0000

Linda,

> All the obvious technologies needed to enable Internet have been developed already. All that left are tweaks and minor improvement.

I think it is a good point — I like to think of this as enabling truly “permissionless innovation” where there’s such a good technology platform that little need for permissions or standards are needed. The web for instance is very close to such a model.

Yet, I would like to disagree with the “tweaks and minor improvement” part.

It was never the intent that all apps or application protocols be developed at the IETF. The number of applications and new forms of communication running over the Internet has multiple probably by millionfold since the beginning of the Internet. It is a *good thing* that the work and the technology scaled to allow this.

Even if it meant that we are done and can go home, it would be a very worthwhile thing to do develop a platform that enables other people to build everything they need.

But, I don’t think we’re seeing that all development stops. It has changed, sure. And there’s a natural slowing in the rate of adaption. Long tails and all that. However, from my perspective there are some pretty big things in the works and big problems that people should solve, for instance:

* rapid re-design of the web protocol stack (H2, QUIC, maybe COAP etc)
* SDN
* real-time communications on your browser
* privacy in the Internet
* security in the Internet of Things

Perspectives differ, and I realise some people could call these minor tweaks. But the point is, the industry and users seem to need new technology. The world isn’t ready.

> We all know that the future belongs to the App & services. But people from those emerging App & services companies are way under represented in IETF.

Yes, and that is a problem (IMHO).

> Maybe more Heckathons effort should be invested into attracting Apps & Services companies to utilize the work developed by IETF, …

I think that is something that we should look into. We’ve had some discussions of taking the Hackathons elsewhere (outside the IETF) as a forum for building things on top of the IETF technology. We haven’t done that yet, but if we wanted to reach more applications people, that would be one way of doing it.

Jari

---

From: Dave Cridland <[email-masked]>
Date: Sun, 6 Mar 2016 22:13:19 +0000

On 1 Mar 2016 18:17, "Linda Dunbar" <[email-masked]> wrote:
>
>
> Jari,
>
> Very interesting write up. IMHO, the hardest challenge facing IETF is
that "Internet has been working over several decades".
> All the obvious technologies needed to enable Internet have been
developed already. All that left are tweaks and minor improvement.

This put me in mind of the following, probably apocryphal quote:

"There is nothing new to be discovered in physics now, All that remains is
more and more precise measurement." - Attributed to Lord Kelvin, circa 1900.

> (is it still true: "The IETF brand is core Internet technology, and
improving the Internet, not specifically new things.?)
>
> We all know that the future belongs to the App & services. But people
from those emerging App & services companies are way under represented in
IETF.
>
> Maybe more Heckathons effort should be invested into attracting Apps &
Services companies to utilize the work developed by IETF, ...
> A while back I had asked for volunteers to join a design team to look at
(non-technical) trends and changes that relate to IETF operations.
>
> The team has been working and they have today published an -00 draft.
We’d love to have your feedback and thoughts on this topic!
> Team: Jari Arkko, Alia Atlas, Avri Doria, Tobias Gondrom, Olaf Kolkman,
Steve Olshansky, Benson Schliesser, Robert Sparks, Russ White
> While most of the work in the IETF is technical, the IETF should and does
regularly examine itself, including its processes and goals, to determine
if the technical community is truly serving the larger network engineering
community effectively.  Changes in this area tend to be incremental, as is
fitting for an organization with decades of experience and history in
developing and managing the process of building technical specifications.
>
> The rapid and ongoing changes in the world have recently caused a number
of IETF participants to examine the current processes and operation of the
IETF, particularly in the context of the culture of the IETF.  This memo
discusses some cultural and global trends in relation to the IETF's
operating environment, how these trends might affect the operation of the
IETF, and notes some topics for further exploration.
>
> Writing this memo has been inspired by involvement in various decisions
that the IETF leadership has to take part in, often wishing to be able to
draw more on understanding trends and their impact on the IETF.
> The memo has no particular official standing, nor does it claim to
represent more than the authors' thinking at the time of writing.
> There is no intent on the part of the authors for this to be published as
a RFC.  Please direct discussion about this topic to the [email-masked]
mailing list.

---

From: Randy Bush <[email-masked]>
Date: Sun, 06 Mar 2016 19:54:57 -0800

>> developed already. All that left are tweaks and minor improvement. 

one of my faves

It's perfectly appropriate to be upset.  I thought of it in a slightly
different way--like a space that we were exploring and, in the early days,
we figured out this consistent path through the space: IP, TCP, and so on.
What's been happening over the last few years is that the IETF is filling
the rest of the space with every alternative approach, not necessarily any
better.  Every possible alternative is now being written down.  And it's not
useful.  -- Jon Postel

---

From: Melinda Shore <[email-masked]>
Date: Sun, 6 Mar 2016 19:26:49 -0900

> better.  Every possible alternative is now being written down.  And it's not

I keep going back and forth on this.  If we're going to let
the market decide there's inevitably going to be some waste,
but we really have put a pile of time and effort into standardizing
things that have never seen any uptake and almost certainly
never will.  That doesn't bother me that much, but what does
bother me about it is that that's one of the reasons we're slow.

Melinda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 6 Mar 2016 23:29:29 -0500

As far as I can tell, the assertion that the space has been fully 
explored is simply not supported by the facts.  In every area where I 
have enough familiarity to know, we are finding new things, making new 
mistakes, and finding new ways to make things work better.

Yours,
Joel

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 7 Mar 2016 08:39:44 -0500

On Sun, Mar 06, 2016 at 04:58:19PM +0000, Jari Arkko wrote:
> However, from my perspective there are some pretty big things in the
> works and big problems that people should solve, for instance:

[snip]

> * security in the Internet of Things

These are connected and in desperate need of serious attention.  I've
spent some of the past few years studying these areas and the situation
is awful...and getting worse in a hurry.  The rush to market new devices
has turned into a stampede, with the accompanying construction of enormous
data-rich repositories, often stuffed full of data collected without
informed consent and lacking even a token level of security.

I think the IETF could (and should) make substantial contributions
in this area.  But if we're going to do so, we need to dive in now.

---rsk

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Mar 2016 13:51:40 +0000

Hiya,

> informed consent and lacking even a token level of security.

Yes, the security and privacy properties of many small devices
that people sell are horrible.

> in this area.  But if we're going to do so, we need to dive in now.

Can you be more specific? (Bearing in mind that we're not the Internet
police and nor are we the "crap small device" police;-)

We do have some work going on in this space (e.g. cose, ace) and I'd
not be at all surprised if people were up for more of that if there
are topics that are good ones for the IETF to tackle.

Cheers,
S.

PS: If a lot of discussion ensues, we might be better off having
that discussion on the [email-masked] list, but let's see how it
goes for now.

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Mar 2016 07:56:44 -0800

> police and nor are we the "crap small device" police;-)

make it really easy for widget makers to make reasonably secured
widgets by designing protocols and supporting crypto which is easy to
implement and deploy [0].  then, as the social and legal pressures
build, they have a path and no excuse.

randy

--

[0] oh, and end world hunger too

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Mar 2016 14:17:15 -0500

First, I disagree with Jari's original analysis of the problem. The
Internet security problem is not limited to IoT:

* The use of TLS in most protocols is subject to downgrade attack

* DNSSEC zones are being signed but virtually no-one is changing
behavior based on signature verification results.

* Only 0.1% of email users have enabled an end-to-end security
solution and most of those use it less than 1% of the time.

* We still use passwords as these are the only ubiquitous
authentication mechanism that is compatible with every protocol.

* The set of secure SMTP authentication mechanisms that are supported
by every widely used email client is the null set, as is the
intersection between the set of secure authentication mechanisms
supported by the default clients on many widely used platforms and
many of the major mail services.

* It takes an expert user over 15 minutes to configure Thunderbird to
use an S/MIME certificate. To configure OpenPGP it is necessary to
download a plugin.

And I could go on and on and on.

So what is different about IoT?

I think the big difference is that in IoT it is impossible to ignore
the usability problem that cripples most IETF security protocols. With
the new EC curves we can now do public key crypto on 16 bit and even 8
bit devices (just don't do it too often). But we are still constrained
by the affordances of the devices:

* IoT devices don't always have display capability

* IoT devices often don't have a keyboard device.

Once we recognize the fact that our principal constraints are
usability constraints, we can develop an architecture that addresses
the problems of the IoT world and also the Internet in general.

We are not going to be able to configure cryptography or any other
settings on an IoT device. But we have a variety of protocols that can
be used to connect an IoT device to a 'secure console' where
administration takes place:

* Device has an LED status light and a QR Code with the SHA-2 digest
of a public key printed thereon. Administrator connects device through
a mobile app that uses the camera.

* Device has an SD Card with a site specific O/S build that includes
the 'connection authentication key' of the site. This is then used
together with the MAC address to bootstrap a connection.

Now I am not going to go through the math or the protocol here, but
those of you with crypto knowledge will know how to solve those use
cases. Configuring wireless is harder than wired of course as you have
to configure the WiFi settings. But that could be sorted with a change
to the WiFi specs to add a standardized 'calling channel' SSID.

This is the set of problems I think I have solved with the
Mathematical Mesh. If you go to my Web site http://prismproof.org/ you
will see a demonstration of the Mesh in action. First a Mesh profile
is created on one machine.  The profile manager automatically adds in
S/MIME configuration data to the email account on the first machine
(will be OpenPGP as well in the future).

Then a second machine is connected to the profile. This is initially a
completely blank machine with no email account settings at all. When
the machine is connected to the Mesh profile (using mutual
authentication, naturally), all the email account settings are copied
into the second machine.

The problem of connecting up a lightswitch or a light is essentially
the same. I am using the same exact approach to connect up components
within my robots. My plans to motorize my dalek prop involve three
separate controller boards, one for the base, another for the
shoulders with the gun and manipulator arm, a third for the eyestalk
and lights on the dome. The controller boards all exchange secure
messages with a controller hub.

http://prismproof.org/

---

From: Jari Arkko <[email-masked]>
Date: Tue, 8 Mar 2016 16:36:54 +0000

Phillip,

> Internet security problem is not limited to IoT:

Of course. That’s not the only security problem we have… didn’t think I said it was. But apologies if I was unclear. Anyway...

> the usability problem that cripples most IETF security protocols.

The usability problem is big in IOT. Although I would probably call it the manageability, deployment, and usability problem.

> With

Yup.

> the problems of the IoT world and also the Internet in general.

We can, but having been on the field for some time, I have a feeling that this isn’t an easy problem. Step 1 of the path to an improvement is recognising that we have a problem. We do! And at least a subset of the engineers working in this space have understood that. The world as a whole is beginning to understand that given many news stories about this. And I’m eager for us and others to do more here. But solutions aren’t necessarily clear cut or easy. It will take time and effort.

> …  Configuring wireless is harder than wired of course as you have
> Mathematical Mesh.

Thanks! And these are all useful things, probably good components for solutions.

I want to add that the security problem for IOT is wider than setting up the secure wireless connectivity. I’m going out on a limb and say that that in the networks that I work with, that’s a largely solved problem modulo many non-IOT related updates that are being handled. However, it would be a mistake to think that it is all we need. We obviously do need wireless security, we obviously need transport level crypto to protect our COAP and other transactions, but perhaps even more than those things, we need to protect the data that is passed around, protect data that is stored, safeguard applications that process that data and necessarily have to have access to many sources of information, figure out how metadata such as directories and semantic definitions need to be protected, figure out how we authorise various applications and actors to act, and so on.

I think that’s a tall order, and we better get moving!

Jari

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 9 Mar 2016 10:16:30 +0000

Hi,

good discussion starter.

Two comments:

1) Open Source / Hackathon:

The objective of the IETF should IMO be to develop open, high-quality specifications (in a timely manner...). We have been working with running code for ensuring implementability and interoperability. That's still a good thing, however, we could think about how we can make better use of Open Source for the specification process. (Following up on Dave Ward's lunch presentation some IETF meetings back.)

For example, some IRTF RGs are working with reference implementations (of their core protocols) to promote experimentation, more research, future adoption.

Would it make sense to promote similar models for the protocol specification process in IETF WGs (beyond the Hackathon concept)?

Potential benefits:

- more running code -- better specification quality
- FOSS as standards reference implementations -- promoting standards adoption
- potentially: speeding up the process

This could also help us with working better with industry Open Source Projects, e.g., OpenDaylight, OPNFV.

2) SDN

I'd like to add one point (IMO the main point) to the description of SDN in the current draft:

Network programmability: the ability to define the functions and the behavior of individual network elements and thus of the network overall dynamically, beyond management and configuration.

Instead of seeing this as a risk ("who would need standards anymore?"...), I think we could do better in finding a constructive role for the IETF: For example, network programmability can enable and require new IETF protocol work -- e.g., evolving IP, transport protocol support in the network -- things that have been difficult in the past.

Finding a good role for the IETF here would IMO be useful, for example between ONF and systems SDOs like 3GPP...

Disclaimer: I am aware that this is a difficult discussion. I also don't think that SDN solves all problems...

Cheers,
Dirk

> Sent: Montag, 29. Februar 2016 23:04
> To: IETF
> A while back I had asked for volunteers to join a design team to look at (non-
> technical) trends and changes that relate to IETF operations.
> 
> The team has been working and they have today published an -00 draft. We'd
> love to have your feedback and thoughts on this topic!
> 
> Team: Jari Arkko, Alia Atlas, Avri Doria, Tobias Gondrom, Olaf Kolkman, Steve
> Olshansky, Benson Schliesser, Robert Sparks, Russ White
> 
> URL:
> regularly examine itself, including its processes and goals, to determine if the
> technical community is truly serving the larger network engineering community
> effectively.  Changes in this area tend to be incremental, as is fitting for an
> organization with decades of experience and history in developing and
> managing the process of building technical specifications.
> 
> The rapid and ongoing changes in the world have recently caused a number of
> IETF participants to examine the current processes and operation of the IETF,
> particularly in the context of the culture of the IETF.  This memo discusses some
> cultural and global trends in relation to the IETF's operating environment, how
> these trends might affect the operation of the IETF, and notes some topics for
> further exploration.
> 
> Writing this memo has been inspired by involvement in various decisions that the
> IETF leadership has to take part in, often wishing to be able to draw more on
> understanding trends and their impact on the IETF.
> 
> The memo has no particular official standing, nor does it claim to represent
> more than the authors' thinking at the time of writing.
> There is no intent on the part of the authors for this to be published as a RFC.
> Please direct discussion about this topic to the [email-masked] mailing list.
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 9 Mar 2016 10:19:16 +0000

> Finding a good role for the IETF here would IMO be useful, for example between ONF and systems SDOs like 3GPP…

Very good points. Thanks.

Jari

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Mar 2016 09:35:50 -0500

I think that I understand what you are saying, so let me repeat it back to
you in my own words.

    > Internet security problem is not limited to IoT:

I tend to agree... the only reason we aren't as "concerned" about non-IoT
things is because we can (in theory) update them, the devices are used
directly by humans who sometimes notice if they are broken (or p0wned),
and the passwords, as weak as they are, can in theory, be stored in the
human, rather than in the system.  (In practice: it's better to let the
browser store them)

    > by the affordances of the devices:

So, I see this as an opportunity...

It's like the book with no letter e:
     https://en.wikipedia.org/wiki/Gadsby_(novel)

artists impose arbitrary restrictions on themselves in order to do better
work.

The IoT space is restrictive, and has no humans to pick options or store
passwords, so we have to do it correctly.  It's also much more of a
greenfield with no clear incumbent.  Therefore we can throw away many of the
things that turned out to be unworkable/insecure, like passwords.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Mar 2016 09:39:05 -0500

Jari Arkko <[email-masked]> wrote:
    > I want to add that the security problem for IOT is wider than setting
    > up the secure wireless connectivity. I’m going out on a limb and say
    > that that in the networks that I work with, that’s a largely solved
    > problem modulo many non-IOT related updates that are being
    > handled.

I think the the problem of setting up the "secure" wireless connectivity is
largely a distraction, and leads regularly to insecurity.

I also think that the networks you speak of are largely vertically integrated.

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 09 Mar 2016 16:36:01 +0100

> largely a distraction, and leads regularly to insecurity.

Hear, hear.
This is really the crux of the matter.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Wed, 9 Mar 2016 16:40:42 +0100

Hi Michael and others,

This is a very interesting discussion.

> human, rather than in the system.  (In practice: it's better to let the

Things being what they are will vary in shape, size, function,
capability, and support.  It's that latter issue that I get worked up
about.  There are a number of different connection models that will all
be in play, one of them being CoAP, but as common one being where
devices "call home".  In the latter case there will be no password.  In
the former, there needs to be a step to somehow initialize credentials. 
I think the work you're doing in ANIMA is a really good example of that,
and deserves a lot more eyes.  Many different work flows need to be
worked out.  I am somewhat less concerned about industrial or
enterprise, since we know how to do 802.1X and the 802.1AR, but I am
very concerned about the consumer case.

But even once that happens, the Thing remains at risk, due to
vulnerabilities.  What's more, Things that we think are secure today (we
don't really know) will assuredly not be in the future, because at some
point the manufacturer is going to stop supporting the device.  This can
take as little as 90 days and as long as 40 years, but it will happen. 
And then what?  Even if the manufacturer is still supporting the device,
the ability to update it may be limited, depending on how it is
implemented and deployed, and what its duty cycle is.

And so the question turns to this: how do we add layers of protection to
Things when they may not be in a good position to protect themselves? 
I've floated an idea in draft-lear-mud-framework-00.txt which talks a
little about this.  The idea is to learn what the Thing is and then have
its manufacturer communicate to a deployment how the thing is intended
to be used.  This is not meant as the Be All End All of Thing
Protection, but to reduce its threat surface.  Hopefully substantially. 
And I'm looking for ways (and dare I say collaborators) to improve the work.

Eliot

---

From: Theodore V Faber <[email-masked]>
Date: Wed, 9 Mar 2016 15:53:03 +0000

On 3/9/16 07:11, Michael Richardson wrote:
> I think the the problem of setting up the "secure" wireless
> connectivity is largely a distraction, and leads regularly to
> insecurity.

Amen.

- -- 
Ted Faber <[email-masked]>
Engineering Specialist
Computer Systems Research Department
310-336-7373

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 9 Mar 2016 16:53:01 -0000

Eliot,

Picking one piece out of your MUD...

> to be used.

This approach worries me. While the manufacturer might not object to this, the user and the system integrator should. The fact that a device was manufactured for foo should not stop it being used for bar. 

Adrian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 09 Mar 2016 18:02:02 +0100

> This approach worries me. While the manufacturer might not object to this, the user and the system integrator should. The fact that a device was manufactured for foo should not stop it being used f…

... and here we have the tussle.

Grüße, Carsten

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 9 Mar 2016 17:06:32 +0000

> This approach worries me. While the manufacturer might not object to this, the user and the system integrator should. The fact that a device was manufactured for foo should not stop it being used f…

Indeed, and too often manufactures already  do this as part of their 
business model.

A classic example is where performance is throttled, or features are 
enabled only by
licence.

It is but a short step to application specific restriction, although if 
an application has
third party IPR there can be a liability that rests with the 
manufacturer, in which
case you can understand the concern.

As distasteful and frustrating as this is, restriction of application 
may be an unfortunate necessity.

- Stewart

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 09 Mar 2016 18:19:59 +0100

> may be an unfortunate necessity.

It may also be mandated and(!)/or disallowed by regulation.

Grüße, Carsten

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 9 Mar 2016 17:57:31 +0000

> It may also be mandated and(!)/or disallowed by regulation.
Unfortunately yes.

Stewart

---

From: Eliot Lear <[email-masked]>
Date: Wed, 9 Mar 2016 19:14:04 +0100

Hi Adrian and thanks for your comment.

> This approach worries me. While the manufacturer might not object to this, the user and the system integrator should. The fact that a device was manufactured for foo should not stop it being used f…

I imagine you'll not be surprised to know that you're not the first to
raise this concern.  And it plays in at least two directions: devices
are given too little or too much access.  Some time ago, Cullen pointed
me to the case of a television that he would like not to have access to
the Internet, lest its microphone send stuff upstream to the
manufacturer.  That is actually the harder problem because the
manufacturer will offer other services, perhaps some of them vital, that
the network will not be able to distinguish from the unwanted services,
perhaps through HTTP2/TLS.

But let's stick to your concern for the moment.  First, a great many
devices will have a limited number of uses.  In these cases, there is
little if any tussle, as Carsten put it.  Printers print.  They may
accept numerous protocols to accomplish this task (such as LPD, IPP,
etc).  Limiting inbound access to those protocols seems reasonable and
addresses the cases where-

  * someone accidentally left the SSH (or some other) code in;
  * the device is misbehaving (e.g., stepping out of that profile);
  * someone is attempting to talk to that device that has no business
    printing (this might be the null set as far as the example of
    printing is concerned, but you can envision many cases where that
    would not be true).

Moreover, in this case, because these rules are intended as guidance to
the router, it should be possible for the administrator to override or
modify them.  The administrator might want to apply different rules
based on the class of device.  The approach taken separates identity of
the type of device from the usage description itself, and the former may
be used without the latter if that is desired.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Mar 2016 08:20:49 +1300

> Would it make sense to promote similar models for the protocol specification process in IETF WGs (beyond the Hackathon concept)?

I was tempted to write "Well, Duh!" but maybe this *isn't* obvious to everybody. So yes, there is no doubt
that running code is a vital adjunct to successful standards work.

> - more running code -- better specification quality

Very specifically, WGs where somebody can say "When writing the code, I couldn't understand X",
or "When testing the code, I found that Y is wrong" produce better specifications.

> - FOSS as standards reference implementations -- promoting standards adoption

Perhaps equally important: providing a basis for interoperability tests.

BTW the choice of OS license is important: pick the wrong one and some people aren't
allowed to look at your code.

> - potentially: speeding up the process

Maybe not speeding up the IETF process itself, but certainly speeding up the time
to market (or the time to deciding the whole thing was a bad idea).

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Mar 2016 14:25:29 -0500

Adrian Farrel <[email-masked]> wrote:
    >> little about this.  The idea is to learn what the Thing is and then
    >> have its manufacturer communicate to a deployment how the thing is
    >> intended to be used.

    > This approach worries me. While the manufacturer might not object to
    > this, the user and the system integrator should. The fact that a device
    > was manufactured for foo should not stop it being used for bar.

I haven't read Eliot's document yet.

I imagine the manufacturer initially says:
    Device FOO with Version BAR is believed to be safe on open
    Internet at date BAZ.

then they say:
    Device FOO with Version BAR is known to be unsafe on open
    Internet as of date BAZ, but is safe with ports X,Y,Z blocked.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 09 Mar 2016 20:37:55 +0100

>     Device FOO with Version BAR is believed to be safe on open

I'd like to have the legal department that lets that statement pass...

>     Internet as of date BAZ, but is safe with ports X,Y,Z blocked.

More likely.  But the device knows nothing about that.

The device does know what software runs on it.
Making that information available in the constrained space in such a way
that security automation can act on it is one of our immediate objectives.
(I'll probably talk briefly about this in next week's T2TRG meeting, in
the context of managing "unmanaged" networks.  With luck, we'll have a
draft for Buenos Aires.)

Grüße, Carsten

---

From: Medel Ramirez <[email-masked]>
Date: Thu, 10 Mar 2016 07:14:32 +0800

Adrian,
I can *attest* to that 😉

Have a nice day
Medel
+++++*+++

Sent from my V6 Engine!
メデル ラミレズ

> On Mar 10, 2016, at 1:10 AM, Stewart Bryant <[email-masked]> wrote:
>
>
>
> Indeed, and too often manufactures already  do this as part of their business model.
>
> A classic example is where performance is throttled, or features are enabled only by
> licence.
>
> It is but a short step to application specific restriction, although if an application has
> third party IPR there can be a liability that rests with the manufacturer, in which
> As distasteful and frustrating as this is, restriction of application may be an unfortunate necessity.
>
> - Stewart
>
>

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Mar 2016 23:34:50 -0500

On Wed, Mar 9, 2016 at 12:41 PM, Livingood, Jason
<[email-masked]> wrote:
> Sure, WiFi security is an issue for IoT. But there are probably much more
> fundamental IoT security issues. IMHO I think one of the largest is the
> lack of a secure & automatic (no end user interaction) software update
> channel.

I think Jari has a very different set of concerns to mine.

My first concern is to bind a device to my portfolio in such a way that:

* The device can recognize data (commands, requests, data) from other
devices in my portfolio as such

* Other devices in my portfolio can recognize that device.

So in PKI terms, what I need to achieve is to 1) install my personal
root of trust onto that device and 2) sign the cryptographic public
keys of the new device with an administration key authorized for that
purpose under my personal root of trust.

If I can achieve those two things, I have a framework of trust that I
can then leverage to securely support any machine configuration or
management operation. I could send the device a message to the effect
'download and install the latest BIND updates, check the sigs match
this root, signed <me>'

Once you have bilateral authentication, many things that are now
complex become straightforward.

Now that is not all I would want from a software update scheme. I
would probably want to have some mechanism that makes it possible to
know that updates exist, that this is the latest one. And that leads
to blockchain like constructs. I am probably also going to want some
means of engaging a third party to curate updates for me. For example,
check that the patch works on my devices. If I have redundant systems,
I certainly don't want them both to patch at the same time.

If I get the binding I describe, all things become possible. But
achieving that binding requires a communication of some sort between
my devices. And that gets me into a bootstrap problem. How does my
device know what the network configuration parameters are to connect
to the network and download the parameters?

Yes, this can be made easy but I have yet to see it made easy in
practice. Once upon a time, my Linksys boxen came with a button that
was 'all I needed to press' to connect up a device. Only it didn't
work because I would have to download the proprietary software drivers
to make it work with their PCMCIA cards.

I am pretty uncompromising where ease of use is concerned. This is not
a problem I have seen any commercial product solve to my satisfaction
to date.

---

From: Gmail <[email-masked]>
Date: Thu, 10 Mar 2016 07:01:32 +0000

Sent from my iPad

> On 9 Mar 2016, at 18:14, Eliot Lear <[email-masked]> wrote:
> Some time ago, Cullen pointed me to the case of a television that he would like not to have access to the Internet, lest its microphone send stuff upstream to the manufacturer. 

You mean like the Amazon Fire voice search, which if not encumbered with IPR is bound to turn up on the next iteration of sat boxes, cable boxes and digital terrestrial boxes aka the television itself.

> 
> But let's stick to your concern for the moment.  First, a great many devices will have a limited number of uses. 

They may have limited use in the mind of the original engineering team, or probably product management team, but that does not mean they have limited use. Think of all the uses that the accelerometer in a smart phone gets used for. 

> In these cases, there is little if any tussle, as Carsten put it.  Printers print. 

Yes but they are, for example, also a lan monitor with a print out device. There are lots of things you might want to do with that facility. Admittedly some are good and some are bad, but the owner should decide, not the manufacturer.

-Stewart

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 9 Mar 2016 17:41:43 +0000

- Jason

On 3/9/16, 9:39 AM, "ietf on behalf of Michael Richardson"
<[email-masked] on behalf of [email-masked]> wrote:

>    > up the secure wireless connectivity. I¹m going out on a limb and say
>    > that that in the networks that I work with, that¹s a largely solved

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 11 Mar 2016 10:01:40 -0500

Even worse, I'm not sure people who deploy this stuff are even trying:

http://mjg59.dreamwidth.org/40505.html

Scott K

On Wednesday, March 09, 2016 05:41:43 PM Livingood, Jason wrote:
> >    > I want to add that the security problem for IOT is wider than
> >
> >setting
> >

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Mar 2016 16:22:49 +0100

> lack of a secure & automatic (no end user interaction) software update

Even if it's there day 0, it won't be there at some point.  And the
device will be.

Eliot

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 11 Mar 2016 16:50:39 +0000

> Even if it's there day 0, it won't be there at some point.  And the

A conventional s/w update channel is only appropriate for some devices.

For very cheap sealed devices, the update channel is via the garbage can.

For devices that only offer one way (outbound) communications the
update channel is via physical access.

For devices that only offer one way (inbound) communications the
update channel could be over the communications channel (STB's
do this today) but will be very much resource (device and
communications channel) constrained.

- Stewart

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 15 Mar 2016 20:40:12 +0000

On 3/9/16, 8:20 PM, "ietf on behalf of Brian E Carpenter" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

It is obviously not obvious :)
There is still very little emphasis in most working groups on running code. Anyone written a tool to check the percentage of drafts that include a non null "Implementation Status" section [RFC 6982<https://tools.ietf.org/html/rfc6982>]?
The hackathons are a good first step. They serve primarily as a cultural event to raise awareness, engage open source communities, and shine a positive light on the value of running code early in the standards process. The majority of the code will obviously be produced outside of the hackathon, but the hackathon is a catalyst.

Potential benefits:

Exactly. Some of the most useful work that came out of the previous hackathons were negative results regarding existing drafts.

    Brian

We need to consider how to make open source code readily available to community that might be interested in it, and to do so in a timely manner. We also need to consider the target audience, the end users of the code and specification. Much of the great work the IETF does never gets adopted. We need more focus on end user community and adoption. We need to consider barriers to deployability. Hackathons are a small step in right direction, but I thing we should consider offering training and keep end users in mind from the start and throughout the standardization process.

Cheers,
Charles

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Mar 2016 12:46:39 -0700

On 3/6/2016 8:26 PM, Melinda Shore wrote:
>  If we're going to let

I'll suggest that that's not the reason we're slow.  Rather, there are 
two other reasons:

      1. When we start an effort, we do not press for demonstrated 
community need -- but more importantly, demonstrated community interest 
in /using/ the output.  So the folk who work on a topic tend to have no 
sense of urgency.  (Even when there is a claimed sense of urgency, such 
as for STIR, the work often is not pursued in a fashion that matches the 
claim, with an eye towards rapid development and deployment.)

      2. The folk making IETF approvals feel an unfortunate fear of 
letting flawed specifications through the process, even though the fear 
does not produce obviously superior results.  So we impose high barriers 
to entry and high barriers to completion.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 20 Mar 2016 14:51:58 -0400

> Would it make sense to promote similar models for the protocol specification process in IETF WGs (beyond the Hackathon concept)?

Over the past few years, I have been assembling tools that allow me to
automate different part of the standards writing process.

Last week, I used them to produce a first draft for a proposal for a
LURK protocol. In three days, I produced:

1) A draft describing the protocol
   a) Text describing protocol
   b) Examples from running code
   c) Reference section
2) Reference implementation

The code generator I use targets C# by default as it has many
advantages when using code generation tools over Java. But it can also
generate C code for production use.

The tools are all on GitHub and SourceForge under PHB Build Tools. The
draft is here:

https://tools.ietf.org/html/draft-hallambaker-lurk-00

One important side effect of this work is that the specs are a lot
more consistent and a lot more flexible than those created the hard
way, by hand. If someone wants to have the protocol in XML rather than
JSON, I can do that. Or I can do ASN.1 or TLS Schema or CBOR. If
someone wants a code library in PHP or a particular flavor of C++, no
problem, just write your own output scripts.

Another advantage is that it encourages you to factor out pieces that
can be used as common modules in other application layer protocols.

This is what WS-* should have been. All the functionality but without
the complexity.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Mar 2016 16:17:42 +0200

Phillip, Charles,

> 2) Reference implementation

Yes, excellent!

> We need to consider how to make open source code readily available to community that might be interested in it, and to do so in a timely manner. We also need to consider the target audience, the en…

Yes, but I would approach this from a slightly different end-point. It is always the case that convincing others of something new is a lot of work. In my mind, standards or open source work both succeed best when performed by those who actually are deploying and in charge of building mainstream systems (commercial or open source) for the topic. So it is not so much about IETF folk reaching the adopters, but having the adopters drive the IETF work…

Jari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Mar 2016 11:27:42 -0400

> Yes, but I would approach this from a slightly different end-point. It is always the case that convincing others of something new is a lot of work. In my mind, standards or open source work both su…

One of the problems I see is that 'consensus' is wielded as an input
to the process rather than being the output.

People are already telling me that there is 'no consensus' for my
proposal for the LURK BOF. How on earth is there supposed to be
consensus if we haven't even met yet?

The mode of failure I keep seeing in IETF is the following:

1) A very narrow scope is decided 'to focus'

2) Poorly thought out aspects of the proposal are defended because the
problems they cause are 'out of scope'

3) The resulting RFC describes a protocol that is worse than useless.

4) The proposal fails in the market.

5) The experience is used as 'proof' that the problem is insoluble. (optional)

What should be obvious, I hope, is that the narrower your scope, the
narrower the appeal of your solution.

The risk in considering a wide scope is that the solution becomes
overly complex. But it can also make the solution simpler by forcing
the designers to consider what the fundamental issues are and deal
with them in a modular, extensible fashion.

I have a proposal:

* Use cases are not subject to consensus calls.
* Requirements derived from the use cases are.

What I want to use a specification for is really none of anyone else's
business. When a person proposes a use case, what they are essentially
saying is 'this is what the specification has to do if you want my
support'. So why should that be subject to a consensus requirement?

During the SAML design, there was a working group on use cases that
spent a lot of time voting on use cases. Some of the work was useful
in that it did help clarify what the use case was. But the time they
spent arguing over whether given use cases were in or out was a total
waste of time because I was writing the architecture specification and
I made sure that I could meet every use case anyone ever proposed.

In design, I actually find the more absurd use cases turn out to be
the most useful because they can lead to a different way of thinking
about the problem.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 21 Mar 2016 16:41:19 +0000

On 3/21/16, 10:17 AM, "Jari Arkko" <[email-masked]> wrote:

>> We need to consider how to make open source code readily available to
>>community that might be interested in it, and to do so in a timely
>>manner. We also need to consider the target audience, the end users of
>>the code and specification. Much of the great work the IETF does never
>>gets adopted. We need more focus on end user community and adoption. We
>>need to consider barriers to deployability. Hackathons are a small step
>>in right direction, but I thing we should consider offering training and
>>keep end users in mind from the start and throughout the standardization
>>process.
>
>Yes, but I would approach this from a slightly different end-point. It is
>always the case that convincing others of something new is a lot of work.
>In my mind, standards or open source work both succeed best when
>performed by those who actually are deploying and in charge of building
>mainstream systems (commercial or open source) for the topic. So it is
>not so much about IETF folk reaching the adopters, but having the
>adopters drive the IETF workŠ

Excellent point. I have seen many examples of active participation of a
core set of people across related open source communities yielding great
results. The same principle applies to the IETF and open source
communities. The hackathons are one way to raise awareness and promote
collaboration, but what we really need is to have these adopters in the
open source community and elsewhere participating actively in IETF working
groups and vice versa.

Cheers,
Charles

---

From: <[email-masked]>
Date: Tue, 22 Mar 2016 01:03:15 +0000

> 5) The experience is used as 'proof' that the problem is insoluble. (optional)

This holds for the IRTF too - though step 5 there is 'let's form an IETF workgroup to push it into adoption! This time for sure!'

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: ietf <[email-masked]> on behalf of Phillip Hallam-Baker <[email-masked]>
Sent: Tuesday, 22 March 2016 2:27 AM
To: Jari Arkko
Cc: IETF
Subject: Re: Observations on (non-technical) changes affecting IETF operations

I have a proposal:

---

From: George Michaelson <[email-masked]>
Date: Tue, 22 Mar 2016 11:50:48 +1000

The concrete counter-instantiation of why new groups might need to be
spun up to reconsider old problems, might be the textual

  Subject: why your proposal to fix spam will fail [check applicable]

message, with a list of instances of:

  [x] "because we tried this before and it failed"
  [x] "because it cannot scale"
  [x] "because all known algorithms which satisfy your condition are infeasible"

reasons.

Basically, its a variant of the appeal to authority: prior experience
in the IETF is not always a good indicator of future experience,
because O(hard) problems are a function of both algorithms and Moore's
law, and are subject to change.

Obviously, where the message retains its authority, unappealling or
otherwise, is the implicit:

  [x] "because we don't like this class of solution and it has no
chance of getting adopted"

In this list (regarding SPAM but more generally)

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 22 Mar 2016 10:02:02 +0000

> This holds for the IRTF too - though step 5 there is 'let's form an IETF workgroup to push it into adoption! This time for sure!'

No, it doesn't "hold for the IRTF." Please don't generalize from your dislike of the DTNRG's bundle protocol to the DTNRG as a whole, and then to the entire IRTF.

Lars

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Mar 2016 14:57:27 -0400

> No, it doesn't "hold for the IRTF." Please don't generalize from your dislike of the DTNRG's bundle protocol to the DTNRG as a whole, and then to the entire IRTF.

I don't see how it applies to IRTF since the output there isn't meant
to be a widely used protocol.

I don't object to taking complex, difficult issues off the table in a
WG. But what I do object to is that folk take a whole load of use
cases and requirements off the table because they don't personally
care for them and then argue that there is 'no difference' between two
protocol choices because it doesn't affect their pet use case.

---

From: <[email-masked]>
Date: Wed, 23 Mar 2016 09:08:05 +0000 (UTC)

Lars, 

My distaste for the bundle protocol and DTNRG is more
a distaste for both poor engineering decisions and poor
process.

the DTNRG (formerly the Interplanetary Internet IPNRG, now 
the DTNWG - third time's the charm, eh?) played fast and
loose with IRTF conventions:

rfc2014:
  The IRTF does not set standards

rfc4440:
  This is necessary to ensure that RGs don't become a part of 
  the standards process itself.
[..]
  IRTF groups are not trying to produce standards of 
  any kind

and yet, setting standards (blue book standards for the CCSDS
ISO subgroup) is what the IPNRG, DTNRG, and their participants have
been doing the work for all along:
http://public.ccsds.org/publications/archive/734x2b1.pdf

and the motivation for transitioning to DTNWG is to finally
get to the holy grail of a CCSDS book standard and an IETF
standard that might gain popular adoption, because the last
two attempts haven't managed to do so.

Partly because of poor engineering design
decisions that have to be revisited ("should a protocol
intended for the harshest of conditions have any internal
error detection or sanity-checking? No, of course not!"),
partly because of a whole bunch of other debatable factors.

But, since you've just finally closed down DTNRG, this
problem and the question of hewing to what the IRTF is
supposed to do for a now-closed research group is no longer
your problem as IRTF chair. Be thankful.

So, how should the IRTF cooperate with other communities?
Good question, worth asking for a research organisation
cooperating with other peer research organisations,
just as the IETF cooperates with W3C, 3GPP, et al. between
peer standards bodies.

How should the IRTF do work for standards
bodies, either the IETF or outside the IETF? The RFCs
I've quoted seem clear. I don't think it's supposed to,
and I don't think the IRTF should be trying to do standards
development for anyone, as that immediately narrows the
research focus to a single solution that can be standardised
with intent to fast-track as a standard inside (and outside)
the IETF, regardless of its merits. There's an immediate
conflict of interest for the participants, especially
those wearing more than one body's hat.

There isn't a win-win in doing that, as much as the
participants might wish there was.

So, either the DTNRG is a spectacularly unique failure
because it flouted the IRTF conventions put in place
for good reason (and, oh yeah, those engineering
decisions, partly driven by not wanting to disrupt
the CCSDS standards process by revisiting anything),
or it's an example of wider failings across the IRTF
as a whole. Take your pick.

Lloyd Wood

----- Original Message -----
From: "Eggert, Lars" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Tuesday, 22 March 2016, 21:02
Subject: Re: Observations on (non-technical) changes affecting IETF operations

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 23 Mar 2016 12:30:34 +0000

Hi,

> http://public.ccsds.org/publications/archive/734x2b1.pdf

the paragraph from RFC2014 that you quote one sentence from also goes on to say:

   In addition, it is expected that technologies
   developed in a Research Group will be brought to the IETF as input to
   IETF Working Group(s) for possible standardization.   However,
   Research Group input carries no more weight than other community
   input, and goes through the same standards setting process as any
   other proposal.

The "are not to produce standards of any kind" sentence from RFC4440 continues with "and that the output of IRTF groups does not require consensus within the RG, or broad consensus from the IETF."

The DTNRG has not set standards. It has not produced standards track RFCs. What has happened is EXACTLY what the two RFCs you quote prescribe as the route in which IRTF output can influence the standardization process: as input from the community. This is how the experimental protocols developed in the DTNRG ended up as input into the DTN WG in the IETF. And now we'll see if that output will see sufficient IETF consensus to become an IETF standard.

What you mean when you say "setting standards is what the IPNRG, DTNRG, and their participants have been doing" is that bodies OTHER than the IETF have taken some of the DTNRG output and decided to use them as if they were standards documents. And yes, this was probably promoted by some DRNRG participants. But this is not unusual. Participants who believe in a technical approach will try and promote it within the IETF/IRTF as well as outside.

What's the alternative? If an ISO group believes that IRTF output is suitable for them, how do you envision us stopping them using it as they see fit? We are not the network or protocol police. If an IRTF-developed protocol fits their needs, why would they not use it?

> just as the IETF cooperates with W3C, 3GPP, et al. between

There aren't really any parallel organizations to the IRTF that I'm aware of. Sure, IEEE has a bunch of technical societies, but they are much more academic than the IRTF is. All other research organizations (ACM, USENIX, etc.) I'm familiar with are much more academic than the IRTF. Their output is peer-reviewed papers, and the ideas may make it into standards, but there is no defined route. So I don't know whom to ask.

> development for anyone,

See above. That is not what the DTNRG in particular or the IRTF in general have done or are doing.

> as that immediately narrows the
> the IETF, regardless of its merits.

"Immediately" - seriously? The DTNRG has been around since 2002, and has looked at a very wide variety of topics over the years.

> There's an immediate

Everyone wears more than one hat. Open processes are how we deal with that fact of life.

> as a whole. Take your pick.

No, thank you. The two options you present are a little too removed from reality.

Lars

---

From: "Russ White" <[email-masked]>
Date: Sun, 27 Mar 2016 07:33:15 -0400

>       1. When we start an effort, we do not press for demonstrated
community
> need -- but more importantly, demonstrated community interest in /using/
> the output.  So the folk who work on a topic tend to have no sense of
> urgency.  (Even when there is a claimed sense of urgency, such as for
STIR,
> the work often is not pursued in a fashion that matches the claim, with an
> eye towards rapid development and deployment.)

This is certainly true... 

But I think there is a second reason in this neighborhood that also relates
to this one --

>       2. The folk making IETF approvals feel an unfortunate fear of
letting
> flawed specifications through the process, even though the fear does not
> produce obviously superior results.  So we impose high barriers to entry
and
> high barriers to completion.

We've lost the art of base spec -- leave other stuff to later. Maybe I'm
just being nostalgic, but I seem to remember a time when we would pass
through a base protocol with extensibility, and then start talking about
extensions on a case by case basis. Now we seem to see 15-20 drafts proposed
in a few months, all with interlocking bits and pieces, totaling hundreds of
pages of text, and sounding more like a bill being presented before some
legislative body rather than a technical specification. These large scale
"boil the ocean" efforts constructed (apparently) by off line meetings
outside the mailing list and the "normal process," are challenging (to say
the least) to even read, must less to fully participate in. When someone
does try to discuss one of these monstrosities on list, the reply is either
"you're stupid," or "you didn't really read all the drafts," or some such,
shutting the discussion down. Of course no-one has really read the drafts --
they're essentially unreadable, and they describe a system of massive
complexity that few people probably understand -- even the authors. I'm
certain each author understand some small bit, but the overall system is far
too complex to be understood by anyone who doesn't have time to dedicate
themselves full time for several weeks to understand it.

This doesn't "improve the speed," as some folks claim--biting off smaller
chunks would actually be faster, as it would increase community
participation, and help us to drive simpler specifications that people
outside the IETF could actually read and understand. If we could get out of
the habit if "boiling the ocean," then we could, possibly, get back to doing
simple things quickly in a serial fashion with a lot of participation. What
we seem to be doing, instead, is a lot of large scale systems that often
overlap in parallel with specifications so complex and so poorly written
that we don't have high overlapping participation rates, which means speed
and innovation suffer, and quality creeps towards atrocious.

At least that's my view of the process at this point.

What we have on the speed front is a culture issue as much as anything else.

:-)

Russ

---

From: Melinda Shore <[email-masked]>
Date: Sun, 27 Mar 2016 10:27:34 -0800

On 3/27/16 3:33 AM, Russ White wrote:
> legislative body rather than a technical specification.

Yes, this is definitely a problem.  Sometimes it's
necessary to grind out metadocuments, when participants
refuse to come to agreement.  But more often this seems
related to a bigger problem, which is that we've got a
bunch of participants who are being given incentives to
publish documents rather than to produce technology.

Someone once told me that he'd implemented an important
piece of IETF technology and that while there were five
or six documents in the core set, he really only needed
two of them to produce a full implementation.

We're running into this issue (completeness before core spec
publication) in a working group I chair and we really don't
have mechanisms to push on past someone really determined
to do this.  In fairness, it's produced a better core
specification, but in honesty it hasn't produced a core
specification that's sufficiently better to justify the
consequent delay (over a year, I'd guess).

As with so many things this can be a chairing issue -
maybe we need to come up with a clearer shared understanding
of what "ready" is, and make sure the IESG shares it as well.
And, be prepared to deal with appeals from participants who
are bound and determined to make perfection be the enemy of
the good enough.

Melinda

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Mar 2016 10:15:05 +0200

Hi Dave,

On 3/19/16 8:46 PM, Dave Crocker wrote:
> community need -- but more importantly, demonstrated community
> interest in /using/ the output.  So the folk who work on a topic tend
> to have no sense of urgency.  (Even when there is a claimed sense of
> urgency, such as for STIR, the work often is not pursued in a fashion
> that matches the claim, with an eye towards rapid development and
> deployment.)

This is not so straight forward as one might think.  Some markets are
quite complex and some will stall or fragment without standards, even if
the key players in those spaces know nothing of the IETF.  I think in
these circumstances it's incumbent on the IESG to be perceptive and
reach beyond our normal community to take a "best guess" as to what is
needed.  IMHO this is the case with ITS, for example.

Sometimes the guesses will be wrong, and we should simply allow for some
efforts that may not succeed.  So long as those are the exception and
not the rule, we're in a good space.
> letting flawed specifications through the process, even though the
> fear does not produce obviously superior results.  So we impose high
> barriers to entry and high barriers to completion.
>

Indeed.  And there are many dimensions to that fear.

Eliot