home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / poised95 / poised95-minutes-95dec.txt < prev    next >
Text File  |  1996-06-03  |  10KB  |  277 lines
  1. CURRENT MEETING REPORT
  2.  
  3.  
  4. Minutes of the Poised95 Working Group (poised95)
  5.  
  6. Reported by Erik Huizer, Surfnet
  7.  
  8.  
  9. Intellectual Property Rights
  10.  
  11. Bob Steen presents a brief overview on the intellectual property rights 
  12. issues regarding RFC1602bis (draft-ietf-poised95-std-proc-3-01.txt).
  13.  
  14. o  exists as a body of law
  15. o  trace secrets, etc.
  16. o  copyrights
  17. o  patents
  18.  
  19. Section 8.2 of draft-ietf-poised95-std-proc-3-01.txt states that 
  20. anything published as part of a contribution will not be considered a 
  21. protected trade secret.
  22.  
  23.  
  24. IETF
  25.  
  26. o  open protocols & standards
  27. o  rough consensus & running code
  28.  
  29.  
  30. Copyright
  31.  
  32. Section 8.3.1 and 8.4 of draft-ietf-poised95-std-proc-3-01.txt cover two 
  33. issues with copyrights.  Section 8.3.1 discusses  material that you 
  34. contribute to the IETF will be copy-written by the IETF.  While you do 
  35. not give up rights to the material, but you are granting them a 
  36. perpetual non-exclusive royalty free permission to reproduce/distribute 
  37. and produce derivative works.
  38.  
  39. An "Applicable Notice" will appear in all documentation and 
  40. contributions stating this.
  41.  
  42. Robert Elz points out that by placing a document in the public domain, 
  43. the author no longer has the right to grant copyright.  This should not 
  44. be a problem assuming the IETF has the ability to establish its 
  45. objectives with regard to publication.
  46.  
  47. Bill Simpson points out that the current document does not mandate 
  48. that the document and derivative works must carry proper attribution.
  49.  
  50.  
  51. Patents
  52.  
  53. Patent holders who contribute material to the IETF relevant to their 
  54. patents must disclose such relevancy to the IETF.  This gives the 
  55. working group and the IESG the data required to determine if work 
  56. should be continued using the patented technology or find alternatives.
  57.  
  58. Section 8.3.2a states that patents must be made available in a 
  59. specified, reasonable, and non-discriminatory fashion.  When moving 
  60. from PS to DS, the two separate implementations must have two 
  61. separate exercises of the patent license process.  This is an attempt to 
  62. exercise the "license process" as part of the standardization process.
  63.  
  64. Robert Elz points out that we may be forced into dealing with a patent 
  65. holder who won't follow our non-discriminatory rules.  We need an 
  66. escape clause to override this mandate.
  67.  
  68. Robert further believes that the IETF may not be able to enforce the 
  69. "must disclose patents" clause because participants are individuals, not 
  70. representatives of organizations.  Robert will propose a rewording of 
  71. the clause on the mailing list.
  72.  
  73.  
  74. Quick Issue Clarification
  75.  
  76. o  Do authors keep rights?  Yes
  77. o  Can IETF/ISOC charge for reproductions in the future?  No
  78. o  Contributors are responsible for granting permission to IETF
  79.  
  80. o  What license is the contributor of a document granting?
  81. o  What about granting sub-licenses to other organizations?
  82. o  Does the contributor have permission of the owner?
  83.  
  84. Authors of documents are often not owners. (documents written on 
  85. company time are owned by the company)
  86.  
  87. o  Can work submitted to the IETF be sent to other organizations?
  88. o  Who are the "authors" of a working group document?
  89.  
  90.  
  91.  
  92. Discussion on Patents
  93.  
  94. o  Will holders give prior permission to reasonable and non-
  95. discriminatory patent licenses?
  96. o  Does the Working Group need to get involved with whether terms are 
  97. OK?
  98.  
  99. The intent was that the separate license applications would force 
  100. the responsibility onto the implementors, but this doesn't really 
  101. show if the license applications were reasonable and non-
  102. discriminatory.
  103.  
  104. Steve Knowles points out that it should be the Working Group's 
  105. responsibility to track down the licensing issues, and the area 
  106. director makes the decision about "reasonable" and "non-
  107. discriminatory."
  108.  
  109. Paul Mockapetris suggests that when a working group chooses to use 
  110. patent technology, the working wroup must immediately report 
  111. that decision to the IESG so the IESG isn't put into the position 
  112. where they must kill two years worth of work once things are ready 
  113. to standardize.
  114.  
  115. Bill Simpson raised issue with ISOC holding copyright on material.  
  116. He feels that we should hold the copyrights within the IETF 
  117. ourselves.
  118.  
  119. What followed was a long discussion about eliminating the ISOC's 
  120. connection to the IETF.  Paul Mockapetris suggested we either create a 
  121. new parent organization or propose an ultimatum to the ISOC stating 
  122. our demands.
  123.  
  124. A straw-poll was taken about continuing our relationship with ISOC:
  125.  
  126. o  do it ourselves? 2
  127. o  do it with ISOC, offer them terms for relationship? 25
  128. o  find another body? 0
  129.  
  130. The Chair takes action item to send summary of discussion to ISOC.
  131.  
  132. A suggestion was made for a formal liaison relationship between ISOC 
  133. and IETF.  Scott Bradner says he holds that position for ISOC, and it 
  134. was suggested that Scott hold that position for IETF so that he can 
  135. hold meetings with himself.
  136.  
  137.  
  138.  
  139. Nomcom procedures document discussion
  140.  
  141. o  Why should there be an IRTF liaison?
  142.  
  143. IRTF reports to the IAB, so IRTF should have a say in the process.  
  144. Consensus is for two liaisons (IESG and IAB) plus other liaisons at 
  145. the discretion of the chair.
  146.  
  147.  
  148. o  Section 3.7: Sitting IAB and IESG appoint liaison.
  149.  
  150. It cannot be anyone up for re-election
  151.  
  152.  
  153. o  Section 2.5 a, b and recall procedure, and mid-term vacancies.
  154.  
  155. How long left in the term versus how long the mid-term appointee 
  156. should stay.  There needs to be a time-out before a recalled person 
  157. can be re-appointed.  A discussion follows on which body selects 
  158. candidates for midterm vacancies. Consensus is that the Nomcom 
  159. will also deal with mid-term vacancies.
  160.  
  161.  
  162. o  Section 2.4: Start of new terms. 
  163.  
  164. Term begins on or after end of open plenary at the Spring IETF so 
  165. that IAB Chair election can happen.
  166.  
  167. In relation to Nomcom announcements, he list of vacancies should be 
  168. advertised at Nomcom sign-up time so that people know whether 
  169. they should volunteer for Nomcom or not. (This is because they may 
  170. want to run for one of the vacancies.)
  171.  
  172. Guy Almes introduces the current nomcom at this point.  Some people 
  173. did not see the call for volunteers message this year.
  174.  
  175. o  Nomcom selection.
  176.  
  177. Randomization is good.  However, there is nothing in the process to 
  178. ensure representation by diverse communities (e.g., geographic), for 
  179. example, there is only one non-US person this time.  We need more 
  180. volunteers, not new rules; more information should be given when the 
  181. call for volunteers is sent.
  182.  
  183.  
  184. o  Size of the Nomcom.
  185.  
  186. Concensus is that ten is a good number.
  187.  
  188.  
  189. o  Timing.
  190.  
  191. To push up process by one month, for example, begin four months prior to 
  192. the Spring IETF so that Nomcom can exist and meet at the December 
  193. IETF.  There were no objections.
  194.  
  195. Thus ends the discussion on the Nomcom procedures.  The editor (Jim 
  196. Galvin) will produce a new version.
  197.  
  198.  
  199. o  Best Current Practice document series.
  200.  
  201. John Stewart presents a modified approach to BCP's.  He argues 
  202. that the name is not right and that ICS (Internet Concensus 
  203. Specification) might be a better name.
  204.  
  205. There is concensus that the current name and description are not 
  206. suitable.  Discussion will be taken up on the list.  In the meantime, 
  207. practice will prove how well the current definition works.
  208.  
  209.  
  210. o  Discussion of draft-ietf-poised95-ietf-charter-00.txt
  211.  
  212. The document has too much overlap with 1602bis; it needs to be 
  213. removed.  Tow other documents discussed were the IETF Charter and 
  214. that which presents the organization of the IETF.  This leads to the 
  215. following diagram showing document relations (THIS IS *NOT* AN 
  216. ORGANIZATIONAL CHART!)
  217.  
  218. Document relations:
  219.  
  220. Standards process (1602bis)              ---------IESG charter
  221.                          \              /
  222. IETF Organization --------+------------+--------- IAB charter
  223.                           |IETF charter|
  224. Nomcom proc. -------------+------------+--------- ISOC charter
  225.                              /   |
  226. IETF Guidelines and proc.---/    |
  227.                                 /
  228. Appeals procedures ------------/
  229.  
  230. Thus the IETF charter ties all other documents together.
  231.  
  232.  
  233. o  Discussion on the current document.
  234.  
  235. The process for Working group approval is discussed.  People 
  236. complain that this takes too long.  Is more streamlining needed?  The 
  237. gropu is unable to reach a clear consensus.  The IESG decides IAB has 
  238. a say.  The Working Group may suggest the number of chairs and the 
  239. people for the position(s).  However, final responsibillity lies with 
  240. the Area Director.  The Area Director chooses the chair and the 
  241. number of chairs.
  242.  
  243. BOFs should be announced to IETF list.
  244.  
  245. Editors will make a new version of the document.
  246.  
  247.  
  248. o  Discussion on IESG tasks.
  249.  
  250. Robert Elz notes that Kobe has too many responsibilities (and the 
  251. IAB has none).  The IESG manages the  IETF, Working Group process, 
  252. the standards process, and guards the quality.  It is suggested that 
  253. the IESG be split, but that the IAB not be like it was before.  A new 
  254. body would include seven people with a chair.  The group would be 
  255. responsible for the standards process.  In turn, the original IESG 
  256. would manage the working groups.  It was then argued that there 
  257. was already enough bureaucracy.
  258.  
  259. This approval body would make sure procedures have been met or if 
  260. it is broken then, even if processes are followed, it needs to be 
  261. rejected.
  262.  
  263. It is also argued that the IESG should do architecture by 
  264. coordination between groups.  The area concept should be abolished.
  265.  
  266. The problem with the IESG is that you can't stop a bad idea.  It is 
  267. suggested that the IESG be horizontally with technical people on 
  268. one side and the process on the other.  Technical people should be 
  269. given the ability to say "no" to a working group or spec.
  270.  
  271. There is no concensus on any of these issues. Discussions will continue 
  272. on the list. It is not yet a main work item for the group.
  273.  
  274. The Poised Working Group encourages Mike O'Dell to go ahead and 
  275. publish his "code of conduct for IETF participants" after a discussion 
  276. on the IETF list.
  277.