Subject: Was the ISOC the original PSO?

From: "Rahmat M. Samik-Ibrahim" <[email-masked]>
Date: Sat, 05 Dec 1998 18:28:24 +0800

Hello:

This following is just yet another compilations which is grounded
in the archive. Please let me know, if I am wrong, and where.

-------------------------------------------------------------------

Table of Content:

1.  The Internet Standards Process -- Revision 3
2.  The Organizations Involved in the IETF Standards Process.
3.  The Internet Engineering Task Force (IETF)
4.  ICANN's Summary of Suggestions and Comments Regarding
    Accountability and Representation
5.  URLs

-------------------------------------------------------------------

1.  "The Internet Standards Process -- Revision 3."
    RFC-2026 (BCP-9) October 1996 [1]:
    - standardization of protocols and procedures by the 
      Internet community.
    - an ISOC activity.
    - organized and managed by the IAB and IESG.
    - concerned with all protocols, procedures, and conventions 
      that are used in or by the Internet, 
    - it might or might not be a part of the TCP/IP protocol suite.

...................................................................

   Therefore, the ISOC is the original Protocol Supporting 
   Organization (PSO). Furthermore, the ISOC outsources all those 
   processes to the IAB and IESG which have their own independent
   nomination process [2].
 
   - How will a light weight shim organization fit here? 
   - Does it need yet another legal umbrella, or is the ISOC
     sufficient?
   - Perhaps, this shim should be called the IPSG (Internet 
     Protocol Steering Group). It could be still under the 
     ISOC/IAB, whereas its members should be nominated by the 
     NomCom with the standard procedure [2]. Nonetheless, whether
     the NomCom is happy with this additional task is yet another
     story.
   - The IPSG might take over a part of the IESG's function of
     "recommending approval", and IAB's function of "approving".
     [Assumption: there wil be many PSOs in the ICANN].
   - How many people will it need?

-------------------------------------------------------------------
 
2.  "The Organizations Involved in the IETF Standards Process."
    RFC-2028 (BCP-11) October 1996 [3]:
    - describes the IESG, the IETF WGs and the IETF - ISOC 
      relationship.
    - the IETF Standard Process complies BCP-9.

....................................................................

   The IETF Standard Process is a sub-set of the Internet Standard 
   Process (BCP-9). The IETF is a leading protocol PRODUCER, however 
   it does not mean that it should be the only one. It seems that 
   the IETF is not a PSO? So, what is it?

--------------------------------------------------------------------
 
3. "The Internet Engineering Task Force (IETF)"

   - an principal Internet Standard developer [3]:
     - the protocol engineering arm of the Internet [4].
     - the protocol development arm of the Internet [4]. 
    
   - objective, mission and concern:
       - identifying, and proposing solutions to, pressing 
         operational and technical problems in the Internet [6];
       - specifying the development or usage of protocols and 
         the near-term architecture to solve such technical 
         problems for the Internet [6]; 
       - making recommendations to the IESG regarding the 
         standardization of protocols and protocol usage in the 
         Internet [6]; 
       - facilitating technology transfer from the IRTF to the 
         wider Internet community [6]; and  
       - providing a forum for the exchange of information within 
         the Internet community between vendors, users, researchers, 
         agency contractors and network managers [6]. 
       - the evolution of the Internet architecture [5, 7]
       - the smooth operation of the Internet [5, 7]
       - who make technical and other contributions to the 
         engineering and evolution of the Internet and its 
         technologies [6].

   - organization and membership:
     - loosely self-organized [6].   
     - not a traditional standards organization, although
       many specifications are produced that become standards [6].
     - the General Area Director also serves as the chair of the 
       IESG and of the IETF, and is an ex-officio member of the 
       IAB [3]. 
     - not a membership organization (no cards, no dues, no
       secret handshakes :-) [6, 7].  
     - a large open international community [3,5,7]
     - any interested  individual, including network designers, 
       operators, vendors, and researchers [3,5,7]
     - the closest thing there is to being an IETF member is 
       being on the IETF or working group mailing lists [6].
     - anyone may register for and attend any meeting [6].
     - registration ain't free, currently US $425 [8].
     - bonus: pay two registration within a year, and get a
       free opportunity of being MD-5 randomly selected as a 
       NomCom [2].

   - working groups and meetings:
     - were the actual technical work are done [5, 7].
     - organized by topic into several areas (e.g., routing, 
       transport, security, etc.).[5, 7].
     - the mailing list is more important than the meetings [5, 7].
     - meetings are three times a year [6].
     - in IETF meeting is not a conference, although there are 
       technical presentations [6].

   - an informal survey about perceptions of the IETF process [9]
     - the  IETF is a gang of hippies, too informal to be taken 
       seriously --- if it weren't for the success track record. 
     - IETF openness is a more than virtue --- it's the core.
     - IETF openness allows anybody to filibuster --- however not if:
       - the chair has proper mandate to run the meeting and uses
         it, and 
       - the rest of the group concurs.
     - IETF rejects ideas without formal procedure or explanation.
       --- Anyone may air any thought. If others agree, it gets
       pursued. Otherwise it doesn't. 
     - Lack of formal voting in WGs perpetuates self-perpetuation 
       (people who are shouted down just give up) --- however, you 
       don't have to shout to get heard and you don't have to bluster 
       to get supporters.  With supporters forming a constituency,
       opponents who bluster lose.
     - IETF process fails to produce well-engineered standards
       --- kinda raises questions about the definition of
       'well-engineered'.
     - LOTS of working groups don't work, maybe more now than 
       previously. (filibuster, obstruction, aimless changes to 
       documents) --- Might be worth some review.
     - Some working groups are too big to reach consensus and 
       make progress. --- That's why design teams do the core of 
       the work.
     - Too much focus on open fair process? --- Like, what's the
       alternative?  Benign neglect?
     - Difficult to get "volunteers" to march together. --- But 
       then it's difficult to get ANY diverse collection of
       people to march together.
     - IETF has become bureaucratic, crusty and ineffective.
       --- It's the great danger facing us.
     - TCP/IP cheated on OSI by bypassing international 
       standardization. (Bureaucrats don't like to be be shown 
       that bureaucracy fails.) (OSI was widely viewed as an 
       instrument of international trade policy.)
       --- TCP waited 10 years for OSI to do its thing and only
       stepped in as the OSI failure became clear.
     - IETF should be open to outside groups submitting their docs 
       for "rubber stamp" with change control but without breaking 
       existing practice. -- This is not the Internet Standards Task 
       Force.
     - New WGs are formed bottom-up: causes gaps and overlap.
       --- We need MUCH better integration efforts.
     - Unclear how formal comments on last calls are handled.
       --- A groundswell of negative feedback has huge effect. Best 
       example probably is ESMTP.  Big win. --- This difference of
       interpretation continues to be interesting.  The "groundswell 
       of negative feedback" produced major changes in the form and
       style of the standards document.  It produced major changes 
       in the list of editors. It produced some changes in 
       terminology (one very useful).  It caused some material about 
       how ESMTP (and SMTP itself) should actually be used to vanish,
       material that we will now have to pick up again with DRUMS.
       And it cost a few months.
    -  other perceptions [10]
       - a code of ethics would be nice, but it will stop rudes.
       - any other large organization, needs good managers.
         WG chairs are the "low level managers" and deal with the 
         most people directly.
    - yet another perception [11]
      - The IETF (or better, his horizontal union, let it to be ISOC, 
        or who knows who) is the appropriate authority but its
        organized "vertical" groups are not able to make such kind
        of declarations. This is an example of limitation which 
        could be solved confronting the question. (And it is a real
        limitation, as it blocks the spreading of internet in some
        "progressive" staments).

   - history:
     - Though it existed informally for some time, the group 
       was formally established by the IAB in 1986 with Phill 
       Gross as the first Chair [4].

-----------------------------------------------------------------

4. "ICANN's comments Summary Selection [12]":

   - All problems and changes should be investigated by a publicly 
     protected research community pattered on the original ARPANET 
     effort and the original IETF. 
   - IETF is the natural protocol supporting organization ("PSO"). 
     They could be a de facto PSO, or an independent body that 
     performed the functions that would otherwise be performed by 
     ICANN/PSO. It would be wise for ICANN to recognize the reality 
     of the IETF, while at the same time the IETF recognizes the 
     value of an internationally sanctioned and recognized ICANN.
   - Technical representation on the Board, selected directly by, 
     and responsive to, the various technical communities, is vital.
     "Technical," in this context, reflects the different communities 
     that the IANA function has traditionally served: Protocol design 
     and standardization bodies in the protocol areas; registrar, 
     registry, and names/intellectual property interests in the domain 
     names area; and registry, ISP, and major user interests in the 
     address allocation area. 
   - Supporting Organizations should have advisory roles only, 
     within the corporate structure. 
   - Make ICANN a stand alone organization, not the sum of its 
     Supporting Organizations.
   - Persons representing non-telecommunications entities should be 
     the majority membership.

----------------------------------------------------------------------

5. "URLs":

[1]  RFC-2026: <http://www.isi.edu/in-notes/rfc2026.txt>

[2]  RFC-2282: <http://www.isi.edu/in-notes/rfc2282.txt>

[3]  RFC-2028: <http://www.isi.edu/in-notes/rfc2028.txt>

[4]  IETF Glossary: <http://www.ietf.org/glossary.html#IETF>

[5]  IETF Overview: <http://www.ietf.org/overview.html>

[6]  IETF Tao: <http://www.ietf.org/tao.html#What_Is_IETF>

[7]  IETF Join: <http://www.ietf.org/join.html>

[8]  IETF meetings: <http://www.ietf.org/meetings/meetings.html>

[9]  POISED list: BC-950810 DC-950809 JK-950810

[10] POISED list: JB-950818

[11] POISED list: AR-970402

[12] ICANN's ICANN's Summary of Suggestions and Comments 
     Regarding Accountability and Representation
<http://cyber.law.harvard.edu/icann/archive/comments-summary.html>

-- 
Rahmat M.Samik-Ibrahim VLSM-TJT http://www.geocities.com/Tokyo/6825
- Negative Heuristic: the HARDCORE of the program (Imre Lakatos,70)