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

[Dirk Kutscher <[e-mail]>]

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:[e-mail]] 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 [e-mail] mailing list.
>