Consensus? IPR rights and all that
Hi folks, it seems that we are drawing close to a consensus here: - Access to data that the IETF has created and needs to function is a paramount basic principle. Not to be compromised. So it needs to go VERY plainly into section 2.2 principles. - Access to software is a very-nice-to-have, but it's only critical if not having it limits our ability to effectively access the data. And open-source is a quite-nice-to-have; we see a number of advantages in doing things that way, but there may be cases where other considerations apply. So this belongs in the document, but under advice, not principles. So - I'd like to propose a specific text change to address that: Replace the current section from 2.2 that says: 6. The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld or limited in any way by ISOC from the IETF. with the following: 6. The IASA, on behalf of the IETF, shall have an irrevocable, permanent right of access and later use to all data created in support of the IETF's activities, including the right to disclose it to other parties of its choosing. And in section 3.1 IAD Responsibilities, add after paragraph 4 (The IAD negotiates service contracts): The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. This is needed to make sure the IETF has access to the data it needs at all times, and that the IASA can change contractors when needed without disrupting IETF work. If software is developed under an IASA contract, the software should remain usable by the IETF beyond the terms of the contract; this may be accomplished by IASA ownership or an open source license; an open source license is preferable. The IAD will decide how the interest of the IETF is best served when making such contracts. Note: I have tried to write the sentences above without using any of the legal terms copyright, ownership or work for hire - these are all terms of art that I know I don't fully understand, and I believe it's possible to state the principles without using those terms. Reasonable? Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5b (appealability)
Scott Bradner wrote: Harald sez: if decisions of the IAOC can be appealed rather reads: -- If someone believes that the IAOC has violated the IAOC rules and procedures, he or she can ask the IETF leadership to investigate the matter, using the same procedure as is used for appeals of procedural issues in the IETF, starting with the IESG. If the IESG, IAB or the ISOC BoT find that procedures are violated, they may advise the IAOC, but does not have authority to overturn or change a decision. this sort of wording halps deal with the worry I had in that an appeal will not stop the IETF from working and restricts the appeals to those that relate to violating rules and procedures and does not support the idea of allowing an appeal of a decision to hire a particular vendor just because someone did not like the vendor or thought they could do something cheaper True, but it still leaves the field rather open - are you sure we shouldn't include a limitation to matters affecting the standards process? Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: iasa-bcp-01 - variance
Harald Tveit Alvestrand wrote: --On 3. desember 2004 11:24 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: The variance clause that I suggested has been inserted in section 5 on funding. I think it should apply more generally, and should be placed as the second paragraph of section 3, slightly modified (s/the/any/) Disclaimer: The IAOC is authorized to vary any procedures for legal, accounting or practical reasons as long as it reports the variance to the IETF community and triggers an update of this BCP. Hmmm. Getting a BCP through the process (for any reason) is a heavy operation, and updating a BCP of this importance is even heavier. That seems like overkill for what might be an one-off situation. What about this? If the IAOC is unable to comply with the procedures described here for legal, accounting or practical reasons, the IAOC shall report that fact to the community, along with the variant procedure it intends to follow. If the problem is a long-term one, the IAOC shall ask the IETF to update this document to reflect the changed procedure. That should allow startup variances like it's December, we won't get you the 2005 budget in June 2004 to be handled without needing to revise the document for it. Agreed. I had wondered but not typed whether we needed to add within a reasonable time or something, but your formulation is better. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5b (appealability)
--On mandag, desember 06, 2004 10:39:27 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: Scott Bradner wrote: Harald sez: if decisions of the IAOC can be appealed rather reads: -- If someone believes that the IAOC has violated the IAOC rules and procedures, he or she can ask the IETF leadership to investigate the matter, using the same procedure as is used for appeals of procedural issues in the IETF, starting with the IESG. If the IESG, IAB or the ISOC BoT find that procedures are violated, they may advise the IAOC, but does not have authority to overturn or change a decision. this sort of wording halps deal with the worry I had in that an appeal will not stop the IETF from working and restricts the appeals to those that relate to violating rules and procedures and does not support the idea of allowing an appeal of a decision to hire a particular vendor just because someone did not like the vendor or thought they could do something cheaper True, but it still leaves the field rather open - are you sure we shouldn't include a limitation to matters affecting the standards process? I am pretty sure I wouldn't want that limitation - since the IAOC's only business is supporting the standards process, it's not clear that there is anything the IAOC can do that can't be constructed as affecting the standards process. There are cases (instance off the top of my head: IAOC failing to make its decisions public) that would (IMHO) qualify for appeals, and where it would not be possible to tell whether this affects the standards process directly or not before correcting the first problem. And remember - in the text above, the only power the appeals bodies has is to make a rather public statement that the IAOC has overstepped its rules. That limits the power of an appeal as a DoS attack on the IAOC - it's up to the appealed-to bodies to make sure they don't get a DoS attack. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
Harald Tveit Alvestrand wrote: Hi folks, it seems that we are drawing close to a consensus here: - Access to data that the IETF has created and needs to function is a paramount basic principle. Not to be compromised. So it needs to go VERY plainly into section 2.2 principles. - Access to software is a very-nice-to-have, but it's only critical if not having it limits our ability to effectively access the data. And open-source is a quite-nice-to-have; we see a number of advantages in doing things that way, but there may be cases where other considerations apply. So this belongs in the document, but under advice, not principles. So - I'd like to propose a specific text change to address that: Replace the current section from 2.2 that says: 6. The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld or limited in any way by ISOC from the IETF. with the following: 6. The IASA, on behalf of the IETF, shall have an irrevocable, permanent right of access and later use to all data created in support of the IETF's activities, including the right to disclose it to other parties of its choosing. And in section 3.1 IAD Responsibilities, add after paragraph 4 (The IAD negotiates service contracts): The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. This is needed to make sure the IETF has access to the data it needs at all times, and that the IASA can change contractors when needed without disrupting IETF work. If software is developed under an IASA contract, the software should remain usable by the IETF beyond the terms of the contract; this may be accomplished by IASA ownership or an open source license; an open source license is preferable. The IAD will decide how the interest of the IETF is best served when making such contracts. Note: I have tried to write the sentences above without using any of the legal terms copyright, ownership or work for hire - these are all terms of art that I know I don't fully understand, and I believe it's possible to state the principles without using those terms. Reasonable? Reasonable, but I want to be sure that the data rights also include rights to, for example, the domain name ietf.org. Some legal person should advise on how to state that. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
unsubscribe
Kindly me from the list would be appreicated -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harald Tveit Alvestrand Sent: Monday, December 06, 2004 3:27 PM To: Brian E Carpenter; Scott Bradner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Adminrest: section 3.5b (appealability) --On mandag, desember 06, 2004 10:39:27 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: Scott Bradner wrote: Harald sez: if decisions of the IAOC can be appealed rather reads: -- If someone believes that the IAOC has violated the IAOC rules and procedures, he or she can ask the IETF leadership to investigate the matter, using the same procedure as is used for appeals of procedural issues in the IETF, starting with the IESG. If the IESG, IAB or the ISOC BoT find that procedures are violated, they may advise the IAOC, but does not have authority to overturn or change a decision. this sort of wording halps deal with the worry I had in that an appeal will not stop the IETF from working and restricts the appeals to those that relate to violating rules and procedures and does not support the idea of allowing an appeal of a decision to hire a particular vendor just because someone did not like the vendor or thought they could do something cheaper True, but it still leaves the field rather open - are you sure we shouldn't include a limitation to matters affecting the standards process? I am pretty sure I wouldn't want that limitation - since the IAOC's only business is supporting the standards process, it's not clear that there is anything the IAOC can do that can't be constructed as affecting the standards process. There are cases (instance off the top of my head: IAOC failing to make its decisions public) that would (IMHO) qualify for appeals, and where it would not be possible to tell whether this affects the standards process directly or not before correcting the first problem. And remember - in the text above, the only power the appeals bodies has is to make a rather public statement that the IAOC has overstepped its rules. That limits the power of an appeal as a DoS attack on the IAOC - it's up to the appealed-to bodies to make sure they don't get a DoS attack. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
on 2004-12-06 10:29 am Harald Tveit Alvestrand said the following: ... Replace the current section from 2.2 that says: 6. The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld or limited in any way by ISOC from the IETF. with the following: 6. The IASA, on behalf of the IETF, shall have an irrevocable, permanent right of access and later use to all data created in support of the IETF's activities, including the right to disclose it to other parties of its choosing. Works for me, although note that this text covers less material than the original one. Does it now cover all it needs to cover? (Brian mentions domain names; there may be other IPR that should be covered, too, even if there's nothing that comes to mind right now ...) And in section 3.1 IAD Responsibilities, add after paragraph 4 (The IAD negotiates service contracts): The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. This is needed to make sure the IETF has access to the data it needs at all times, and that the IASA can change contractors when needed without disrupting IETF work. If software is developed under an IASA contract, the software should remain usable by the IETF beyond the terms of the contract; this may be accomplished by IASA ownership or an open source license; an open source license is preferable. The IAD will decide how the interest of the IETF is best served when making such contracts. This works for me. Henrik ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
unsubcribe
Kindly unscribe me from the list would be appreicated Thanks -Raghuveer -- ** This email is confidential and is intended for the original recipient(s) only. If you have erroneously received this mail, please delete it immediately and notify the sender. Unauthorized copying, disclosure or distribution of the material in this mail is prohibited. Views expressed in this mail are those of the individual sender and do not bind Gsec1 Limited. or its subsidiary, unless the sender has done so expressly with due authority of Gsec1.** ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
I agree with what you are trying to say, but I'm not sure about this wording: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. Maybe: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the data access rights that are needed...? Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
6. The IASA, on behalf of the IETF, shall have an irrevocable, permanent right of access and later use to all data created in support of the IETF's activities, including the right to disclose it to other parties of its choosing. ... Reasonable, but I want to be sure that the data rights also include rights to, for example, the domain name ietf.org. Some legal person should advise on how to state that. Brian How about all data and other intellectual property? Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
Margaret Wasserman wrote: I agree with what you are trying to say, but I'm not sure about this wording: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. Maybe: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the data access rights that are needed...? rights in data seems to me to cover more than just access; we want the IETF to *own* the data, surely? Ask our lawyer... Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
--On mandag, desember 06, 2004 13:25:31 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: Margaret Wasserman wrote: I agree with what you are trying to say, but I'm not sure about this wording: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. Maybe: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the data access rights that are needed...? rights in data seems to me to cover more than just access; we want the IETF to *own* the data, surely? ownership is too slippery a term for me. Ask our lawyer... I will. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
On Mon, Dec 06, 2004 07:00:32AM -0500, Margaret Wasserman allegedly wrote: I agree with what you are trying to say, but I'm not sure about this wording: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. Maybe: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the data access rights that are needed...? I believe you want the data itself? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Consensus? Variance
After reviewing the discussion on this topic, I think the rough consensus is conformant with this suggestion: - Remove the 2nd (Disclaimer:) paragraph from section 5 - Insert the following as part of section 3 (I suggest just before section 3.1): If the IASA is unable to comply with the procedures described in this document for legal, accounting or practical reasons, the IAOC shall report that fact to the community, along with the variant procedure it intends to follow. If the problem is a long-term one, the IAOC shall ask the IETF to update this document to reflect the changed procedure. (Comparision to previouis suggestion: I changed here to in this document to make sure it covers the whole BCP, not just the section it appears in. I also changed IAOC to IASA in the third word - if the IAD is unable to comply with procedures, IAOC is responsible for reporting that to the community, too.) (Note: A deviation from procedures without appropriate justification is certainly an action of the IAOC that can be appealed. See next message.) OK? Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? Variance
Harald suggests: - Remove the 2nd (Disclaimer:) paragraph from section 5 - Insert the following as part of section 3 (I suggest just before section 3.1): If the IASA is unable to comply with the procedures described in this document for legal, accounting or practical reasons, the IAOC shall report that fact to the community, along with the variant procedure it intends to follow. If the problem is a long-term one, the IAOC shall ask the IETF to update this document to reflect the changed procedure. OK? OK by me Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Regarding SIP messaging format
HiRajat, as per my knowledge,as of now the application that are expecting XML type encoding method for Msg Body are still at draft level (Video control commands, Conferencing). so the application built on the stack has to take care of these things. Rajesh.Kalagarla ---Original Message--- From: Rajat Date: 12/04/2004 04:41:40 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Sipforum-discussion] Regarding SIP messaging format Hi all, Can any on tell me that whether there exist some SIP stack those use xml tags in messageing format. Because right now, As far as I know, most of the intermediate infrastructure is using plain text for request and response(without any xml tags). So if we use xml tags, then there will be a problem in inter-operability. So comments are welcome on this issue. Rajat. __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com -- To unsubscribe from the Sipforum-discussion mailing list visit https://mbox.su.se/mailman/listinfo/sipforum-discussion ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? Variance
Scott Bradner wrote: Harald suggests: - Remove the 2nd (Disclaimer:) paragraph from section 5 - Insert the following as part of section 3 (I suggest just before section 3.1): If the IASA is unable to comply with the procedures described in this document for legal, accounting or practical reasons, the IAOC shall report that fact to the community, along with the variant procedure it intends to follow. If the problem is a long-term one, the IAOC shall ask the IETF to update this document to reflect the changed procedure. OK? OK by me ditto Brian Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: iasa-bcp-01 - ISOC support
Howdy, In-line... Wijnen, Bert (Bert) wrote: Inline -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian E Carpenter Sent: Friday, December 03, 2004 11:33 To: [EMAIL PROTECTED] Subject: iasa-bcp-01 - ISOC support 7. ISOC Responsibilities for IASA ... Independence: The IASA should be financially and legally distinct from other ISOC activities. Since it's a unit of ISOC, it can't be legally distinct. We have discussion elsewhere of the financial arrangements. So I would reduce this sentence to Independence: The IASA shall be distinct from other ISOC activities. makes sense to me personally but also to me as co-editor. Speak up if you (anyone) do not agree, because I intend to make the change. ... IETF meeting fees shall be deposited in a separate IETF-specific financial account and used to fund the IASA under the direction and oversight of the IAOC. Any fees or payments collected from IETF meeting sponsors should also be deposited into this account. The IAD administers this account and uses it to fund the IASA in accordance with a budget and policies developed as described above. This is all repetition of earlier stuff and should be deleted. Not sure. It lists the ISOC responsibilities. We have listed responsibilities of IAD, IAOC etc, and some of that is also a repeat. I think the original authors (text is mainly unchanged from the wasserman-bcp draft) were trying to make sure that the ISOC responsibilities were listed in one place for easy review by ISOC... not sure though. Margaret/Leslie?? Yes. :-) I think Brian is right in saying this section now repeats a lot of the material that has now been fleshed out more, and more usefully, in earlier sections. I think you are correct in observing this section could/should capture ISOC's responsibilities. So trimming this section down to say what the responsibilities are, not how to implement them, makes sense to me. Perhaps: Independence: The IASA shall be distinct from other ISOC activities. ISOC will support the IASA through the mechanisms specified in this document and its successors. (The second line may seem redundant -- but I'm suggesting it to underscore the source of change control for the processes that govern IASA). Support: ISOC may, from time to time, choose to transfer other funds into the IASA account to fund IETF administrative projects or to cover IETF meeting revenue shortfalls. There may also be cases where ISOC chooses to loan money to the IASA to help with temporary cash flow issues. These cases should be documented carefully and tracked on both sides. ISOC will work to provide the operational reserve for IASA functioning described above. This is also repetition. Either delete it, or reduce it to a single sentence referring back to earlier text. same answer as before. reducing some of this text to reference to earlier text seems like a good suggestion to me (personally). Have not concluded yet if we really should do it. Same comments from me as for the previous, and suggested text: Support: ISOC will work with the IAD and IAOC to ensure appropriate financial support for the IASA, following the mechanisms described in this document and its successors. My 0.02CDN. Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Consensus(2)? IPR rights and all that
After a brief trip to the lawyer, and considering current discussion... a new suggestion: Replace principle 6 with the following: 6. The IETF, through the IASA, shall have a perpetual right to use, display, distribute, reproduce, modify and create derivatives of all data created in support of IETF activities. (Jorge liked perpetual better than irrevocable permanent - the stuff after to is a well known legal incantation). And in section 3.1 IAD Responsibilities, add after paragraph 4 (The IAD negotiates service contracts): The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. This is needed to make sure the IETF has access to the data it needs at all times, and that the IASA can change contractors when needed without disrupting IETF work. Whenever reasonable, if software is developed under an IASA contract it should should remain usable by the IETF beyond the terms of the contract. Some ways of achieving this are by IASA ownership or an open source license; an open source license is preferrable. The IAD will decide how the interest of the IETF is best served when making such contracts. (This is giving the IAD a little more room to maneuver, while still stating a clear preference.) Works? Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus(2)? IPR rights and all that
on 2004-12-06 10:36 pm Harald Tveit Alvestrand said the following: After a brief trip to the lawyer, and considering current discussion... a new suggestion: Replace principle 6 with the following: 6. The IETF, through the IASA, shall have a perpetual right to use, display, distribute, reproduce, modify and create derivatives of all data created in support of IETF activities. (Jorge liked perpetual better than irrevocable permanent - the stuff after to is a well known legal incantation). And in section 3.1 IAD Responsibilities, add after paragraph 4 (The IAD negotiates service contracts): The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. This is needed to make sure the IETF has access to the data it needs at all times, and that the IASA can change contractors when needed without disrupting IETF work. Whenever reasonable, if software is developed under an IASA contract it should should remain usable by the IETF beyond the terms of the contract. Some ways of achieving this are by IASA ownership or an open source license; an open source license is preferrable. The IAD will decide how the interest of the IETF is best served when making such contracts. (This is giving the IAD a little more room to maneuver, while still stating a clear preference.) Works? Works for me. Henrik ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: iasa-bcp-01 - Open Issues - Separate bank accounts
Harald writes: Brian, I don't think irrevocably assigned to the IETF works well for money. In all other cases, money going to support the IETF is called credited to the IASA account. In section 5, section 5.2 and 5.3 talk about money credited to the IASA account. I'd rather add a section before section 5.5 that simply says: 5.x IASA expenses The IASA exists to support the IETF. Therefore, only expenses related to supporting the IETF can be debited to the IASA account. I like it, so I have added it to my working copy of the document. Bert That should make it clear enough that the transfer of money into the IASA account is intended to be irrevocable. Makes sense? Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Consensus? Variance
Done -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harald Tveit Alvestrand Sent: Monday, December 06, 2004 10:20 To: [EMAIL PROTECTED] Subject: Consensus? Variance After reviewing the discussion on this topic, I think the rough consensus is conformant with this suggestion: - Remove the 2nd (Disclaimer:) paragraph from section 5 - Insert the following as part of section 3 (I suggest just before section 3.1): If the IASA is unable to comply with the procedures described in this document for legal, accounting or practical reasons, the IAOC shall report that fact to the community, along with the variant procedure it intends to follow. If the problem is a long-term one, the IAOC shall ask the IETF to update this document to reflect the changed procedure. (Comparision to previouis suggestion: I changed here to in this document to make sure it covers the whole BCP, not just the section it appears in. I also changed IAOC to IASA in the third word - if the IAD is unable to comply with procedures, IAOC is responsible for reporting that to the community, too.) (Note: A deviation from procedures without appropriate justification is certainly an action of the IAOC that can be appealed. See next message.) OK? Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: iasa-bcp-01 - ISOC support
Changed text as suggested by Leslie. I had re-send my request for inpout while on the plane. I have now seen both Leslies and Margarets responses. Thanks, Bert -Original Message- From: Leslie Daigle [mailto:[EMAIL PROTECTED] Sent: Monday, December 06, 2004 14:41 To: Wijnen, Bert (Bert) Cc: Brian E Carpenter; [EMAIL PROTECTED] Subject: Re: iasa-bcp-01 - ISOC support Howdy, In-line... Wijnen, Bert (Bert) wrote: Inline -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian E Carpenter Sent: Friday, December 03, 2004 11:33 To: [EMAIL PROTECTED] Subject: iasa-bcp-01 - ISOC support 7. ISOC Responsibilities for IASA ... Independence: The IASA should be financially and legally distinct from other ISOC activities. Since it's a unit of ISOC, it can't be legally distinct. We have discussion elsewhere of the financial arrangements. So I would reduce this sentence to Independence: The IASA shall be distinct from other ISOC activities. makes sense to me personally but also to me as co-editor. Speak up if you (anyone) do not agree, because I intend to make the change. ... IETF meeting fees shall be deposited in a separate IETF-specific financial account and used to fund the IASA under the direction and oversight of the IAOC. Any fees or payments collected from IETF meeting sponsors should also be deposited into this account. The IAD administers this account and uses it to fund the IASA in accordance with a budget and policies developed as described above. This is all repetition of earlier stuff and should be deleted. Not sure. It lists the ISOC responsibilities. We have listed responsibilities of IAD, IAOC etc, and some of that is also a repeat. I think the original authors (text is mainly unchanged from the wasserman-bcp draft) were trying to make sure that the ISOC responsibilities were listed in one place for easy review by ISOC... not sure though. Margaret/Leslie?? Yes. :-) I think Brian is right in saying this section now repeats a lot of the material that has now been fleshed out more, and more usefully, in earlier sections. I think you are correct in observing this section could/should capture ISOC's responsibilities. So trimming this section down to say what the responsibilities are, not how to implement them, makes sense to me. Perhaps: Independence: The IASA shall be distinct from other ISOC activities. ISOC will support the IASA through the mechanisms specified in this document and its successors. (The second line may seem redundant -- but I'm suggesting it to underscore the source of change control for the processes that govern IASA). Support: ISOC may, from time to time, choose to transfer other funds into the IASA account to fund IETF administrative projects or to cover IETF meeting revenue shortfalls. There may also be cases where ISOC chooses to loan money to the IASA to help with temporary cash flow issues. These cases should be documented carefully and tracked on both sides. ISOC will work to provide the operational reserve for IASA functioning described above. This is also repetition. Either delete it, or reduce it to a single sentence referring back to earlier text. same answer as before. reducing some of this text to reference to earlier text seems like a good suggestion to me (personally). Have not concluded yet if we really should do it. Same comments from me as for the previous, and suggested text: Support: ISOC will work with the IAD and IAOC to ensure appropriate financial support for the IASA, following the mechanisms described in this document and its successors. My 0.02CDN. Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Consensus(2)? IPR rights and all that
In line -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harald Tveit Alvestrand Sent: Monday, December 06, 2004 16:36 To: [EMAIL PROTECTED] Subject: Consensus(2)? IPR rights and all that After a brief trip to the lawyer, and considering current discussion... a new suggestion: Replace principle 6 with the following: 6. The IETF, through the IASA, shall have a perpetual right to use, display, distribute, reproduce, modify and create derivatives of all data created in support of IETF activities. So does the above include the copy-right on RFCs? Or is it covered elsewhere? Anyway, I have put above text in my working copy of the doc. (Jorge liked perpetual better than irrevocable permanent - the stuff after to is a well known legal incantation). And in section 3.1 IAD Responsibilities, add after paragraph 4 (The IAD negotiates service contracts): The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. This is needed to make sure the IETF has access to the data it needs at all times, and that the IASA can change contractors when needed without disrupting IETF work. Whenever reasonable, if software is developed under an IASA contract it should should remain usable by the IETF beyond the terms of the contract. Some ways of achieving this are by IASA ownership or an open source license; an open source license is preferrable. The IAD will decide how the interest of the IETF is best served when making such contracts. Done (This is giving the IAD a little more room to maneuver, while still stating a clear preference.) Works? Works for me Bert Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
Harald, I am enroute back to Washington at the moment, but did want to comment on IP matters. I think it fair to state in the document what the IETF thinks appropriate for it to manage its own affairs going forward, but one of the matters we will have to work out is the fact that there is considerable IP generated over the past almost twenty years. At present, CNRI owns most of this IP, but the US Government may have certain continuing rights in the data as well. As you know, I have committed publicly to working with the IETF on the administrative restructuring issues. Over the coming year, I hope we can work out how best to handle matters such these, but at best the document ought to recognize this fact of life and that it will be necessary to address these matters in due course going forward. bob At 04:29 AM 12/6/2004, Harald Tveit Alvestrand wrote: Hi folks, it seems that we are drawing close to a consensus here: - Access to data that the IETF has created and needs to function is a paramount basic principle. Not to be compromised. So it needs to go VERY plainly into section 2.2 principles. - Access to software is a very-nice-to-have, but it's only critical if not having it limits our ability to effectively access the data. And open-source is a quite-nice-to-have; we see a number of advantages in doing things that way, but there may be cases where other considerations apply. So this belongs in the document, but under advice, not principles. So - I'd like to propose a specific text change to address that: Replace the current section from 2.2 that says: 6. The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld or limited in any way by ISOC from the IETF. with the following: 6. The IASA, on behalf of the IETF, shall have an irrevocable, permanent right of access and later use to all data created in support of the IETF's activities, including the right to disclose it to other parties of its choosing. And in section 3.1 IAD Responsibilities, add after paragraph 4 (The IAD negotiates service contracts): The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. This is needed to make sure the IETF has access to the data it needs at all times, and that the IASA can change contractors when needed without disrupting IETF work. If software is developed under an IASA contract, the software should remain usable by the IETF beyond the terms of the contract; this may be accomplished by IASA ownership or an open source license; an open source license is preferable. The IAD will decide how the interest of the IETF is best served when making such contracts. Note: I have tried to write the sentences above without using any of the legal terms copyright, ownership or work for hire - these are all terms of art that I know I don't fully understand, and I believe it's possible to state the principles without using those terms. Reasonable? Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
At 03:41 07/12/2004, Bob Kahn wrote: Harald, I am enroute back to Washington at the moment, but did want to comment on IP matters. I think it fair to state in the document what the IETF thinks appropriate for it to manage its own affairs going forward, but one of the matters we will have to work out is the fact that there is considerable IP generated over the past almost twenty years. At present, CNRI owns most of this IP, but the US Government may have certain continuing rights in the data as well. If there a break down of who is supposed to owe what? I thought all the IETF IP rights were consolidated under ISOC? What does belong to the USG? Who is owning IP rights on the IANA data? jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Consensus(2)? IPR rights and all that
--On tirsdag, desember 07, 2004 02:20:38 +0100 Wijnen, Bert (Bert) [EMAIL PROTECTED] wrote: After a brief trip to the lawyer, and considering current discussion... a new suggestion: Replace principle 6 with the following: 6. The IETF, through the IASA, shall have a perpetual right to use, display, distribute, reproduce, modify and create derivatives of all data created in support of IETF activities. So does the above include the copy-right on RFCs? Or is it covered elsewhere? This is actually very similar to the rights that RFC 3667 states is given to the IETF on usage of IETF contributions. In that particular case, copyright is used as the mechanism to make sure we (the IETF) have those rights - so you could see RFC 3667 as an application of the principle. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
Dr. Kahn, I am sure that if we so desire, we can keep laywers entertained for several years sorting out the ownership of reserves, data and systems created using funds from IETF meeting fees. But we should not allow this potential for trouble prevent us from making a clear picture of what we want to achieve going forward. Our experience with Foretec, where (for instance) our request for a database dump of the I-D tracker has been stonewalled for more than a year, was indeed a reason for trying to establish the principle of data access firmly going forward. My reluctance to mention the word ownership in our principles is, among other things, based on a desire to be able to negotiate mutually acceptable solutions to problems like the one you mention - a desire I am sure you share. The IETF's ability to use the data it needs to function, now and going forward, is a principle that I am not willing to compromise on. What the formalities are that allow this to happen is something I think you and I should allow people with more experience in legal and financial matters to sort out, without placing more restrictions on them than are absolutely necessary. Harald --On mandag, desember 06, 2004 21:41:00 -0500 Bob Kahn [EMAIL PROTECTED] wrote: Harald, I am enroute back to Washington at the moment, but did want to comment on IP matters. I think it fair to state in the document what the IETF thinks appropriate for it to manage its own affairs going forward, but one of the matters we will have to work out is the fact that there is considerable IP generated over the past almost twenty years. At present, CNRI owns most of this IP, but the US Government may have certain continuing rights in the data as well. As you know, I have committed publicly to working with the IETF on the administrative restructuring issues. Over the coming year, I hope we can work out how best to handle matters such these, but at best the document ought to recognize this fact of life and that it will be necessary to address these matters in due course going forward. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'RTP Payload for Text Conversation' to Proposed Standard
The IESG has approved the following document: - 'RTP Payload for Text Conversation ' draft-ietf-avt-rfc2793bis-09.txt as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This specification describes how to carry real time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text. This RTP payload description also recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. It uses the payload format format specified in RFC 2198, and updated in draft-ietf-avt-text-red, in current IETF review. The document obsoletes RFC 2793. The text clarifies ambiguities in RFC 2793, improves on the specific implementation requirements learned through development experience, and gives explicit usage examples. Working Group Summary The material in this document was strongly supported by the AVT working group. There has been considerable IETF review of the text/red media type; in this document, the RTP domain usage is clearly indicated, as was carefully discussed as the context for that text mediatype. Protocol Quality The document was reviewed for the IESG by Allison Mankin and the AVT Working Group chairs. RFC Editor Notes Abstract OLD: This memo describes how to carry real time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. NEW: This memo obsoletes RFC 2793; it describes how to carry real time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. IANA Considerations OLD: This document defines one RTP payload format named t140 and an associated MIME type text/t140, to be registered by IANA. NEW: This document updates the RTP payload format named t140 and the associated MIME type text/t140, in the IANA RTP and Media Type registries. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Simple Network Time Protocol Configuration Option for DHCPv6' to Proposed Standard
The IESG has approved the following document: - 'Simple Network Time Protocol Configuration Option for DHCPv6 ' draft-ietf-dhc-dhcpv6-opt-sntp-01.txt as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This document describes a new DHCPv6 option for passing a list of SNTP server addresses to a client. Working Group Summary This document was developed by the DHC WG. The document was updated to address AD Review comments, including the removal of the timezone option (which may be published separately) and changing the document to indicate that it configures SNTP clients, not full NTP clients. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. RFC Editor note: In Section 4, paragraph one, change the last sentence from: The server MAY list the SNTP servers in the order of preference. to The server MAY list the SNTP servers in decreasing order of preference. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Management Information Base for the User Datagram Protocol (UDP)' to Proposed Standard
The IESG has approved the following document: - 'Management Information Base for the User Datagram Protocol (UDP) ' draft-ietf-ipv6-rfc2013-update-04.txt as a Proposed Standard This document is the product of the IP Version 6 Working Group Working Group. The publication of this document will move RFC 2454 'IP Version 6 Management Information Base for the User Datagram Protocol' to Historic status. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. Working Group Summary The IPv6 working group has reviewed this document and this document reflects the consensus of the group. Protocol Quality This document has been reviewed by members of the [EMAIL PROTECTED] mailing list, the IPv6 working group chairs, and members of the ipv6mib mailing list. A MIB doctor review was performed by Bert Wijnen, and a review was performed during IETF LC by Mike Heard. This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
