> From my perspective, the best approach involves keeping the general > case simple. I concur. I think we should continue to use the RFC3978 rules as the default, and to allow WGs to choose to assign, or not, the new rights on new documents. I was author of 4663, and I coordinated the whole effort to transfer the rights to the Bridge MIB documents from IETF to IEEE. I can state that getting permission from the authors and their companies was not onerous, but I would not want to do that for documents that were not being transferred. I will observe that the requirement we met for RFC4663 was to get permission from the authors of the current drafts, and the authors of the previous revisions, and their companies. We did not try to determine the complete list of people who contributed to the works as WG members. I think THAT task would have been so onerous that I would have argued against doing the transfer, and told IEEE persons to just come work in the IETF instead. In actuality, for RFC4663, the IEEE lawyers got the permissions. I just helped by identifying the authors and their companies. I suggest the right way to handle this in the future is to let the copying organization go get the permissions and assume any related risk. To make that easier, I would not have a problem with a WG deciding to include the right to copy. But then the question becomes "is rough consensus adequate?" or must it be unamimous? If it has to be unanimous, then we apparently would need a membership and voting system, so we know who has a say, and whether they have voted or not. I have been an editor of IETF documents for years, and have never tried to document where every contribution came from, or tried to track the legal permissions granted by each contributor for their text. If I am expected to assume legal risk for asserting that all rights have been granted for text in documents being transferred or being copied into other documents, for all contributors to a WG document, then I would gladly give up editing. I really do not like the changes this new boilerplate forces onto the IETF process. I would rather continue to use RFC2026/3978 rules. David Harrington dbharrington@xxxxxxxxxxx ietfdbh@xxxxxxxxxxx dharrington@xxxxxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf