home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95apr / poised95-minutes-95apr.txt < prev    next >
Text File  |  1995-05-28  |  9KB  |  196 lines
  1.  
  2. POISED '95 BOF (POISED95)
  3.  
  4. Reported by Paul Mockapetris/Information Sciences Institute
  5.  
  6. Three sessions of the POISED '95 BOF were held at the IETF in Danvers.
  7.  
  8. The Monday session, chaired by Paul Mockapetris, sought to create a list
  9. of issues.  The Tuesday session, chaired by Carl Malamud, was limited to
  10. non-IPR issues, but in fact concentrated on the NOMCOM and its
  11. procedures.  The Wednesday session, chaired by John Curran, concentrated
  12. on the reform of RFC 1602 regarding Intellectual Property Rights (IPR)
  13. such as patents, copyrights, etc.  The object was to create new
  14. procedures which would replace the enduring fun occasioned by the Sun
  15. RPC/XDR episode.
  16.  
  17.  
  18.  
  19. ISOC/IETF Relationship
  20.  
  21. Most felt that the ISOC is the only choice at the moment to execute
  22. legal agreements, but most agreed that progress on these issues was too
  23. slow and RFC 1602 is broken.  The Wednesday session on RFC 1602
  24. intellectual property rights will address this.
  25.  
  26. The insurance coverage is still uncertain, the aggregate coverage is
  27. about one million dollars, and as of the meeting, covers the ISOC Board
  28. of Trustees, IESG, but not the working group chairs, widely seen as
  29. involved in progressing standards.  The ISOC is progressing the issue.
  30.  
  31. At least one person is concerned that the ISOC is competing for research
  32. grants and may come into conflict with certain IETF members seeking the
  33. same grants.  At present no conflict exists, and most of the meeting
  34. participants felt that this was not an issue.
  35.  
  36. The ISOC has proposed support of IETF, and the amount of 250 thousand
  37. dollars has been mentioned, but no funds are available to the IESG,
  38. Secretariat, or IETF. The ISOC Board of Trustees may act.  A partial
  39. dream list for spending such funds is:  expenses related to startup of
  40. the ``hostless IETF'' meeting scheme, legal advice for the IESG/IETF
  41. (ISOC did fund legal talent at the BOF), funds to create standards
  42. tracking systems, professional editing help, and development of
  43. technology to support multimedia (i.e., non-ASCII text) standards.  A
  44. lot of suggestions started to emerge about the use of the Web, but this
  45. was ruled out of order for POISED.
  46.  
  47. The ISOC, through the IAB, sponsors and will create new groups that are
  48. not open, but are self-selecting.  Some feel this is appropriate, some
  49. not.  Most did feel that if the IETF is held to a standard, so should
  50. other groups.
  51.  
  52. Ownership of the IETF, the address space, etc., seems to be a continuing
  53. issue.
  54.  
  55.  
  56. Funding Models
  57.  
  58. There is a general request for information about the IETF and
  59. Secretariat financing.
  60.  
  61. In the future, some feel that integrated funding for the IANA, IESG,
  62. InterNIC, etc., is desirable.  There are various opinions about how this
  63. should happen.
  64.  
  65. One prominent question was non-US support.  Some feel that financial
  66. support will not be forthcoming until an acceptable framework, including
  67. reporting and control to some degree, is set up.  Others say that until
  68. there is money on the table, why set up the framework?  A bit of a
  69. chicken and egg problem?
  70.  
  71.  
  72.  
  73. Suggestions for POISED '95 IPR
  74.  
  75. The discussion regarding the repairs necessary to RFC 1602 to deal with
  76. intellectual property rights highlighted several issues:
  77.  
  78. A single cookie-cutter agreement, particularly one that was as
  79. unfavorable to the technology donors as the current RFC 1602, is
  80. unworkable.  In particular, no business is seen as willing to warrant
  81. that all technology is free of patent problems, especially since such
  82. problems may be unknown at the time the technology is donated.  It is
  83. clear that we need some combination of:
  84.  
  85.  
  86.    o Model agreements for a company that wants to hand over ownership of
  87.      a technology to the IETF. The Sun RPC/XDR agreement may be a good
  88.      start here.  In general, this can be both good for the IETF,
  89.      because it acquires a useful technology, and for the company, since
  90.      it will presumably sees its investment and leadership in the
  91.      donated technology rewarded in the marketplace.
  92.  
  93.    o A simpler agreement whereby the holder of a patent does not give it
  94.      over to the IETF (i.e., change control), but agrees that the IETF
  95.      can use the technology to implement some larger goal.
  96.  
  97.    o Somebody empowered to negotiate variants.  The general idea seemed
  98.      to be that as we built up a history of agreements, any new
  99.      agreement could follow precedent, but where precedent was lacking,
  100.      someone had to be empowered to negotiate.  Clearly, the
  101.      desirability of the technology, availability of alternatives, etc.,
  102.      would have to be taken into account.  There was a vigorous debate
  103.      about whether licensing fees were appropriate, and what form they
  104.      should take.  However, a strong preference for unencumbered
  105.      technology should become a stated objective of the IETF.
  106.  
  107.    o The question of who is party to the agreement was discussed.  Some
  108.      feel that unilateral grants would be an effective mechanism, but
  109.      others noted that somebody would still have to take the
  110.      responsibility for deciding whether the terms of a unilateral grant
  111.      were acceptable when it did not follow a clear precedent.
  112.  
  113.  
  114. (There is some subsequent work from the IAB/IESG to develop an ``escape
  115. clause'' procedure, or a ``procedure for variation negotiation.'')
  116.  
  117.  
  118. Possible Improvements To The Standards Process
  119.  
  120. Several people believe that once an Internet-Draft or other matter
  121. enters into the hands of the RFC Editor, InterNIC, regional registry,
  122. IANA, IESG, or IETF Secretariat, it can be difficult for an ``outsider''
  123. to determine where it sits, and who has the responsibility for
  124. ``progressing'' the matter.  The chair mentioned that the Secretariat
  125. was working on developing a Web-accessible tracking system for IETF
  126. documents, that would provide such tracking for IETF documents.  The
  127. other processes are probably beyond the control of POISED.
  128.  
  129. Openness in the actions of the IETF, IESG, InterNIC, are seen as
  130. essential.
  131.  
  132. There seems to be a need to create a new type of standard, which some
  133. call a ``policy'' standard.  This would be used for things like the
  134. RFC 1602 follow-on, address allocation procedures, etc.  Opinions
  135. differed on the best way to proceed.
  136.  
  137.  
  138. IETF Meeting Site Selection and Criteria
  139.  
  140. What are the criteria for an IETF site, and how should sites be
  141. selected?
  142.  
  143. As the IETF has grown, the difficulty of getting meeting sponsors has
  144. increased.  Various estimates suggest that Sun and FTP Software spent
  145. 50-75 thousand dollars or more on the most recent IETF meeting for the
  146. terminal rooms, MBONE support, etc.  The effort and hassle are also
  147. daunting.  As a result, future IETF meetings may be ``hostless,'' with
  148. meeting fees going up to cover the expense of hiring the terminal room,
  149. etc., out.  This is seen as acceptable, and will probably happen in
  150. 1996.
  151.  
  152. The criteria for a meeting site were seen as:
  153.  
  154.  
  155.    o A state of the art terminal room (X-terms, appletalk, Ethernet)
  156.    o MBONE coverage for multiple parallel sessions
  157.    o Capability to house about 1000 participants nearby (not bussed)
  158.    o A reasonable airport nearby
  159.  
  160.  
  161. Minority opinions included requirements that meetings be scheduled two
  162. years in advance, that the spread of laptops meant a declining need for
  163. X-terminals and the like, and that geographical diversity should be
  164. given more weight.  The current Secretariat was seen as doing a good
  165. job, but there is always a possibility for improvement.
  166.  
  167.  
  168. NOMCOM
  169.  
  170. There is a general need to finish formulating the NOMCOM procedures.
  171. Several NOMCOM members and even past chairs felt that better guidelines
  172. would be welcome.
  173.  
  174. One issue is ``tailoring'' the NOMCOM membership.  It was observed that
  175. the membership of the three NOMCOMs seemed to be fugitives from the law
  176. of averages.  This is due to the small ``gene pool'' of volunteers.  It
  177. was recommended that the IETF Chair and the IETF in general attempt to
  178. broaden the gene pool by aggressive attempts to get people to volunteer.
  179. Another method of tailoring is to prohibit participation by candidates
  180. for office, sitting members of the IAB/IESG, members of the prior
  181. NOMCOM, or various other criteria.
  182.  
  183. There was also debate about whether nominations, candidacy, etc., should
  184. be kept secret or not during the NOMCOM process, and who should announce
  185. results.  Consistency is not a hallmark of past NOMCOMs.
  186.  
  187.  
  188. Other
  189.  
  190. One participant mused for the good old days when the IESG was a
  191. tight-knit team, and believed that the present IESG was not this
  192. Camelot.  More cynical types discussed the tradeoffs between IESG as
  193. Borg vs.  IESG as a bunch of Dirty Harrietts/Harrys.  The truth is
  194. probably somewhere in between.
  195.  
  196.