IETF Problem Statement BOF and Work IETF 56

["Bound, Jim" <Jim.Bound@hp.com>]

Title: Message

Hi Melinda and Avri,

 

The draft and work is one of the most important pieces of work for the IETF.  In addition it is written extremely well and is very clear. 

 

I cannot attend the BOF so want to send mail I fully support this being a working group.  I must because of my day job leave Thursday night, I have no choice.    Please add me to the WG mail list if this is accepted as WG.  I believe it should be is my absentee vote :--)

 

http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-00.txt

 

I believe it will be impossible to solve all these problems.  Also any organization has many of these problems. Leaders and those in the know will always exist.   Steve Deering told me once that if you replace one good ole boy network, another will just appear at some point in time.  Sad but Steve was correct.  It is just human nature. 

 

Here is some selected initial input for you:

 

1.  Select the problems that are most immediate to make the IETF more efficient.  I would argue that an important issue is time-to-market for specifications.  This is not just our process, but also a search for perfection that will never exist, during technical review. We will always have warts.  What warts are acceptable is the key to resolving.  The section on "tradeoffs" in the spec is a good start to this problem.

 

2.  Select an architecture model to guide the organization.  But it must not be so detailed it cannot be extended or openly discussed over time.  I could argue this should also be a new working group and force the good ole boy network now or the one tomorrow to technically defend their positions in the community, not behind a wall of secrecy or in a backroom.   I could also argue first build a "mode" which is different than an architecture for the engineering process.  The model would feed the architecture.

 

3.  For workshops, architecture, or any process that will provide direction make sure "implementers" are also part of those teams.   This is important, as our belief in "running code" has become secondary to views of architecture that have no "running code".  I realize it is a balance of the two.

 

4.  As far as  being an SDO.  What is wrong with that?  We should accept we are an SDO.  We can never be the group now that defines how networking products are deployed, used, configured, or how those are architected in the market.  That will be done by entities that do everything based on profit and return on investment, and groups that focus totally on deploying technology as a full time job.  I am not speaking of research, education institutions, et al, but the Government and Commercial networking entities worldwide.  They use our specifications for networking, but they do not and should not view us as much more than that in the scheme of networking on planet earth.  We need to put our egos to bed as a community and realize what we do well and start doing it better. 

 

I have many more thoughts but will keep them for the working group which I hope happens.

 

Respectfully,

/jim