Re: IETF Challenges

[Hector Santos <[e-mail]>]

These are my opinions and a short list of what has been on my mind come 
IETF related.

I like what I read, in particular the recognition what you called "The 
age of  permissionless innovation."   A long time challenge, but 
something that may be address with seminars on ethical principles and 
global impacts, establishing "Global Commons" and directions.  Invite a 
lawyer to give a talk perhaps at an IETF meeting or an RFC on "Global 
Commons for the IETF" if not already produced in some fashion.

I think overall, improving the IETF presence or "marketing" is an 
important direction.  Getting a person with technical sales/marketing 
and strong engineering experience can help.

I think increase participation is necessary of course, especially among 
the younger.  Part of the marketing, etc.

I think the RFC framework is a good tool for "Technical Writing" for 
most disciplines. The IETF should leverage it as a tool for young 
technical writers in other areas.  Its a blend of functional and 
technical specifications, and it does take a good skill  to make it work 
in the IETF.  The help of others involved certainly helps.  But there 
are things in the IETF that could be "sold" per se to the science and 
math market/schools interest, if only in availability.

I think social media exploration should be done, either using one of the 
current centralized computers (FaceBook, Twitter, etc) or install a open 
source "Social/Private BBS/Network" software at the IETF computers (We 
are willing to donate the group ware software, but I'm sure that is not 
wise in general).    We will have the obvious barriers to overcome of 
the old vs new and the mix. Single source of information should be a 
important requirement in this infrastructure for backward compatibility.

Related with the inability of increasing participation, especially with 
leadership quality, is allowing for monopolization of work to stagnant 
growth as it can put a barrier to synergism and continued interest.   It 
can also increase the potential for conflict of interest (monopolized 
IETF work).   Perhaps a concept of limits of the number of simultaneous 
working groups and/or project a person or group has should be explored. 
   We don't want to overload work on cogs as it can dampen progress.  
This may be a matter of recognizing IETF "Project" research versus 
"Project" research efforts and the development of standards.  Project is 
more for experimental work. Product is for real products or 
implementations out there.  The latter IMV has been problematic with 
conflict of interesting monopolizing directions and work, or the 
progress of the work (i.e. stops interest).

I think the "Rough Consensus" tool is outdated or better, doesn't 
applied as well it did in years past where we working in a large unknown 
growth environment.  We still are, but the difference is the much 
greater potential to have sharper engineering insights and the instant 
ability to simulate, emulate and test conditions unlike ever before.  
Often we have proof of concept with a high statistical presence of data, 
enough to justify a direction to take.  Rough Consensus decisions should 
not trump "good ideas" especially when decided by monopolized groups as 
indicated above.  In any case, I think the Rough Consensus tool should 
be reviewed. I believe Pete Resnick is touching base with how Rough 
Consensus is used in his I-D.

That is it for now, if not done. Thank you for the opportunity to 
provide my viewpoints on IETF matters and its future.

--
Hector Santos, CTO/CEO
Santronics Software, Inc.

On 3/2/2013 4:17 AM, Jari Arkko wrote:
> In my new role, I thought it would be useful to start a discussion about the challenges we are facing,
> and call for input on things that the IETF community feels should be addressed.
>
> Here are my initial thoughts: http://www.ietf.org/blog/2013/03/ietf-challenges/
>
> But please tell your thoughts. Is there something that bothers you in the IETF process, meetings,
> support systems, is there something that we should improve? Which of these issues do you think
> the leadership should take a priority in addressing first? And what technical challenges do you
> see us  addressing in the coming years?
>
> Jari
>
>
>