CURRENT MEETING REPORT Minutes of the Poised95 Working Group (poised95) Reported by Erik Huizer, Surfnet Intellectual Property Rights Bob Steen presents a brief overview on the intellectual property rights issues regarding RFC1602bis (draft-ietf-poised95-std-proc-3-01.txt). o exists as a body of law o trace secrets, etc. o copyrights o patents Section 8.2 of draft-ietf-poised95-std-proc-3-01.txt states that anything published as part of a contribution will not be considered a protected trade secret. IETF o open protocols & standards o rough consensus & running code Copyright Section 8.3.1 and 8.4 of draft-ietf-poised95-std-proc-3-01.txt cover two issues with copyrights. Section 8.3.1 discusses material that you contribute to the IETF will be copy-written by the IETF. While you do not give up rights to the material, but you are granting them a perpetual non-exclusive royalty free permission to reproduce/distribute and produce derivative works. An "Applicable Notice" will appear in all documentation and contributions stating this. Robert Elz points out that by placing a document in the public domain, the author no longer has the right to grant copyright. This should not be a problem assuming the IETF has the ability to establish its objectives with regard to publication. Bill Simpson points out that the current document does not mandate that the document and derivative works must carry proper attribution. Patents Patent holders who contribute material to the IETF relevant to their patents must disclose such relevancy to the IETF. This gives the working group and the IESG the data required to determine if work should be continued using the patented technology or find alternatives. Section 8.3.2a states that patents must be made available in a specified, reasonable, and non-discriminatory fashion. When moving from PS to DS, the two separate implementations must have two separate exercises of the patent license process. This is an attempt to exercise the "license process" as part of the standardization process. Robert Elz points out that we may be forced into dealing with a patent holder who won't follow our non-discriminatory rules. We need an escape clause to override this mandate. Robert further believes that the IETF may not be able to enforce the "must disclose patents" clause because participants are individuals, not representatives of organizations. Robert will propose a rewording of the clause on the mailing list. Quick Issue Clarification o Do authors keep rights? Yes o Can IETF/ISOC charge for reproductions in the future? No o Contributors are responsible for granting permission to IETF o What license is the contributor of a document granting? o What about granting sub-licenses to other organizations? o Does the contributor have permission of the owner? Authors of documents are often not owners. (documents written on company time are owned by the company) o Can work submitted to the IETF be sent to other organizations? o Who are the "authors" of a working group document? Discussion on Patents o Will holders give prior permission to reasonable and non- discriminatory patent licenses? o Does the Working Group need to get involved with whether terms are OK? The intent was that the separate license applications would force the responsibility onto the implementors, but this doesn't really show if the license applications were reasonable and non- discriminatory. Steve Knowles points out that it should be the Working Group's responsibility to track down the licensing issues, and the area director makes the decision about "reasonable" and "non- discriminatory." Paul Mockapetris suggests that when a working group chooses to use patent technology, the working wroup must immediately report that decision to the IESG so the IESG isn't put into the position where they must kill two years worth of work once things are ready to standardize. Bill Simpson raised issue with ISOC holding copyright on material. He feels that we should hold the copyrights within the IETF ourselves. What followed was a long discussion about eliminating the ISOC's connection to the IETF. Paul Mockapetris suggested we either create a new parent organization or propose an ultimatum to the ISOC stating our demands. A straw-poll was taken about continuing our relationship with ISOC: o do it ourselves? 2 o do it with ISOC, offer them terms for relationship? 25 o find another body? 0 The Chair takes action item to send summary of discussion to ISOC. A suggestion was made for a formal liaison relationship between ISOC and IETF. Scott Bradner says he holds that position for ISOC, and it was suggested that Scott hold that position for IETF so that he can hold meetings with himself. Nomcom procedures document discussion o Why should there be an IRTF liaison? IRTF reports to the IAB, so IRTF should have a say in the process. Consensus is for two liaisons (IESG and IAB) plus other liaisons at the discretion of the chair. o Section 3.7: Sitting IAB and IESG appoint liaison. It cannot be anyone up for re-election o Section 2.5 a, b and recall procedure, and mid-term vacancies. How long left in the term versus how long the mid-term appointee should stay. There needs to be a time-out before a recalled person can be re-appointed. A discussion follows on which body selects candidates for midterm vacancies. Consensus is that the Nomcom will also deal with mid-term vacancies. o Section 2.4: Start of new terms. Term begins on or after end of open plenary at the Spring IETF so that IAB Chair election can happen. In relation to Nomcom announcements, he list of vacancies should be advertised at Nomcom sign-up time so that people know whether they should volunteer for Nomcom or not. (This is because they may want to run for one of the vacancies.) Guy Almes introduces the current nomcom at this point. Some people did not see the call for volunteers message this year. o Nomcom selection. Randomization is good. However, there is nothing in the process to ensure representation by diverse communities (e.g., geographic), for example, there is only one non-US person this time. We need more volunteers, not new rules; more information should be given when the call for volunteers is sent. o Size of the Nomcom. Concensus is that ten is a good number. o Timing. To push up process by one month, for example, begin four months prior to the Spring IETF so that Nomcom can exist and meet at the December IETF. There were no objections. Thus ends the discussion on the Nomcom procedures. The editor (Jim Galvin) will produce a new version. o Best Current Practice document series. John Stewart presents a modified approach to BCP's. He argues that the name is not right and that ICS (Internet Concensus Specification) might be a better name. There is concensus that the current name and description are not suitable. Discussion will be taken up on the list. In the meantime, practice will prove how well the current definition works. o Discussion of draft-ietf-poised95-ietf-charter-00.txt The document has too much overlap with 1602bis; it needs to be removed. Tow other documents discussed were the IETF Charter and that which presents the organization of the IETF. This leads to the following diagram showing document relations (THIS IS *NOT* AN ORGANIZATIONAL CHART!) Document relations: Standards process (1602bis) ---------IESG charter \ / IETF Organization --------+------------+--------- IAB charter |IETF charter| Nomcom proc. -------------+------------+--------- ISOC charter / | IETF Guidelines and proc.---/ | / Appeals procedures ------------/ Thus the IETF charter ties all other documents together. o Discussion on the current document. The process for Working group approval is discussed. People complain that this takes too long. Is more streamlining needed? The gropu is unable to reach a clear consensus. The IESG decides IAB has a say. The Working Group may suggest the number of chairs and the people for the position(s). However, final responsibillity lies with the Area Director. The Area Director chooses the chair and the number of chairs. BOFs should be announced to IETF list. Editors will make a new version of the document. o Discussion on IESG tasks. Robert Elz notes that Kobe has too many responsibilities (and the IAB has none). The IESG manages the IETF, Working Group process, the standards process, and guards the quality. It is suggested that the IESG be split, but that the IAB not be like it was before. A new body would include seven people with a chair. The group would be responsible for the standards process. In turn, the original IESG would manage the working groups. It was then argued that there was already enough bureaucracy. This approval body would make sure procedures have been met or if it is broken then, even if processes are followed, it needs to be rejected. It is also argued that the IESG should do architecture by coordination between groups. The area concept should be abolished. The problem with the IESG is that you can't stop a bad idea. It is suggested that the IESG be horizontally with technical people on one side and the process on the other. Technical people should be given the ability to say "no" to a working group or spec. There is no concensus on any of these issues. Discussions will continue on the list. It is not yet a main work item for the group. The Poised Working Group encourages Mike O'Dell to go ahead and publish his "code of conduct for IETF participants" after a discussion on the IETF list.