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
-----Original Message-----
From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Jari Arkko
Sent: Montag, 29. Februar 2016 23:04
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 ietf(_at_)ietf(_dot_)org
mailing list.