Re: Legal review results 1: Intellectual property
(explicit CC to Jorge, since I'm interpreting his words) --On fredag, januar 21, 2005 10:49:21 -0500 Bruce Lilly [EMAIL PROTECTED] wrote: Verbosity aside, I don't believe that sole control and custodianship applies to open source software. I am not a lawyer, but the Old text seems not only more easily comprehended [I am reminded of Jonathan Swift's satirical look at lawyers in Gulliver's Travels, and dismayed that things haven't improved in 275 years] but seems to be considerably more favorable to open source software than the proposed new text; the latter appears to be heavily biased towards commercial software. On reading the text again, I think this text: (B) If an IASA Contract provides for the creation, development or modification of any software (including, without limitation, any search tools, indexing tools and the like) (Developed Software) then the IAD shall, whenever reasonable and practical, ensure that such contract either (a) grants ownership of such Developed Software to ISOC, or (b) grants ISOC a perpetual, irrevocable right, on behalf of IASA and IETF, to use, display, distribute, reproduce, modify and create derivatives of such Software (including, without limitation, pursuant to an open source style license). It is preferred that Developed Software be provided and licensed for IASA and IETF use in source code form. ISOC will permit IASA and its designee(s) to have sole control and custodianship of such Developed Software, and ISOC will not utilize or access such Developed Software in connection with any ISOC function other than IETF without the written consent of the IAD. The foregoing rights are not required in the case of off-the-shelf or other commercially-available software that is not developed at the expense of ISOC. actually is OK for making software free - that would come under the section that says: or (b) grants ISOC a perpetual, irrevocable right, on behalf of IASA and IETF, to use, display, distribute, reproduce, modify and create derivatives of such Software (including, without limitation, pursuant to an open source style license). If we assume that the IETF will never be interested in preventing others from using its software, we can remove the stuff that says .. and ISOC will not utilize or access. without the written consent of the IAD. Jorge - see any problems with removing this? The IASA and its designee(s) says that IASA, not ISOC, decides to give others permission to use it - ISOC can't give orders to IASA to limit it. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: My current timeline for IASA BCP action
--On fredag, januar 21, 2005 12:14:32 -0500 John C Klensin [EMAIL PROTECTED] wrote: --On Friday, 21 January, 2005 10:44 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: As you will probably be totally unsurprised to see, I'm pushing back the prospective dates for IASA BCP approval again. I think we are close, but not finished with the various clarifications and process polishing - and still don't have a workable consensus on the appeals issue. ... On my previous timeline, January 12, I promised to ask the questions relative to the -04 draft: - Is the draft now good enough? - Do we need to reissue, lengthen or restart the Last Call? I think the first question got answered with a no - hence this plan, and the new revisions. Does anyone wish to argue that the second question need to be answered yes, or that there are other things that make this timetable an unreasonable one? Harald, I'm not prepared to argue a personal need for another several-week Last Call, but want to make two observations: (1) When one looks at the number of changes that have been made since the initial Last Call, and the number of those that have actually been substantive, I think a narrow reading of our procedures _requires_ such a Last Call and that proceeding without it would be easily appeal-able. From that perspective, what you are asking for is broad community consent to not hold that Last Call. That is perfectly reasonable, but we should all understand it in the same way. I understand it - we could argue about whether the procedures were written with the intent that such a narrow reading entails, but that's a long and separate discussion. I do think we have to have broad community consent (as represented by the readership of the IETF list) to not hold a second Last Call. (2) While I don't think we need four weeks, I'm concerned about having only three working days (between the announcement sometime on Friday 28 Jan to the IESG approval call on 3 February) to review the final document. While I think the editors have done an astonishingly good job of pulling all of this together, it is a lot of work and we know that a few things that were agreed to slipped through the cracks of -04. So I want all of us to be able to study -06 or whatever the IESG is going to vote on. Three working days is not enough -- if I recall, it even violates the IESG's internal minimum for WG document availability ahead of a decision. My recommendation is that: * You not try to take a formal IESG decision until Monday, 7 February. I'll make that seven days after the last version of the I-D is published. Makes sense to me. However, sooner or later we've got to stop fixing the small bugs - at the time when the presumed to be final I-D is published, I will have to ask people to only raise new issues that they feel are show-stoppers - this is the same discipline that we've tried to enforce in the IESG with regard to second and subsequent reviews. (Note: According to Friday's schedule, -05 is not presumed to be final.) * Because this is not a standards action that is clearly within the IESG's responsibility, and because the foundation documents that got us here were joint IESG/IAB responsibilities, the IAB should be polled on its opinion of the community consensus. The information from that poll should be supplied to the IESG well in advance of that Monday decision window and, if there are dissent(s), the dissenter(s) should be encouraged to post their concerns to the IETF list. Reasonable thing to do. * If the IESG is unanimous on the decision, you should be able to take that decision by email and to do so quickly. * If the IESG is not unanimous, then the concerns of the dissenting IESG members should be posted to the IETF list for comments and further input (and a period of at least a could of days) before the IESG meets (presumably by phone) to determine if it can reach consensus under its ordinary voting rules. I am assuming that, if doing this quickly is important enough to justify any accelerated handling (i.e., not a four-week Last Call on -06), then the IESG can find time for an extra teleconference if that is really needed (and, conversely, that the desire to avoid such a call may motivate people to reach consensus :-( ). We discussed this in the IESG telechat on Thursday last - the IESG members agreed that they would raise DISCUSS-sized issues on the list, not via the balloting mechanism. So given that these can be resolved, I believe there should be few problems in achieving IESG consensus. If there is really adequate community consensus behind this, and the IAB poll and IESG action reflect that consensus, this costs only a weekend and will, IMO, leave us all feeling much more secure about the result. If there is still significant dissent --either in the community or
Re: Legal review 2: Trademarks
Suggestion: Add to section 3, one paragraph before section 3.1: The IASA is responsible for undertaking any and all required actions that involve trademarks on behalf of the IETF. Should be broad enough to let it do what needs to be done - registering, defending or attacking trademarks as needed (remember Internet(TM)?) Harald --On fredag, januar 21, 2005 18:51:48 -0500 Jeffrey Hutzelman [EMAIL PROTECTED] wrote: On Friday, January 21, 2005 17:10:01 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: Harald Tveit Alvestrand wrote: More from Jorge: 2. Trademarks. There has been a lot of discussion about ownership and maintenance of IETF-related trademarks. I would suggest that one of the IAD/IASA duties be to consider appropriate trademark protection for the IETF's identifying names (such as IETF, IRTF, etc.), and then oversee the prosecution and maintenance of such trademarks. This activity should be identified as part of the IASA budget. Good catch, but does it belong in the BCP? Seems like good advice to the IAOC. It would seem appropriate for the BCP to contain language authorizing the IASA to register, maintain, and defend trademarks on behalf of the IETF. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
I suppose that I am one of those at the other end of the scale, looking for a solution that allows full and direct IETF community review/appeal. On 23 jan 2005, at 21.35, Spencer Dawkins wrote: I agree with the idea that there are extremes when we talk about our ideas on review, but please don't assume that JohnK and Michael are the only people at that end of the pool... I had assumed that the IETF would let IASA run things with periodic general feedback and rare specific feedback (only in situations when the feedback begins we can't imagine why you ...). The further we move from that end of the spectrum, the less I understand why we need an IASA in the first place. My main reason for supporting the creation of the IAOC specifically, is to offload most of the administrative effort from the IESG/IAB. That is also, incidentally one of my reasons for not wanting the IESg/IAB to be involved in every review/appeal, but only in those that get escalated. The other reason is that it is the IAOC that will be the IETF community's representatives in administration and therefore they should be directly responsible to that community. I agree with the role of IAD becaue I think that job needs to focused in one person. But that does not mean that the person should not be accountable to the community. I know it is harder to do a job with accountability and transparency, but I see any other solution as being problematic for reasons that have outlined earlier. I remain in favor of Margaret's formulation as the compromise position from what I would truly prefer which is for all IAD/IAOC actions and decisions being reviewable in the same manner that the actions and decisions of the ADs, IESG and IAB are currently appealable. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
Sam, Let's take another look at your example, from my point of view (I can't speak for Mike). --On Sunday, 23 January, 2005 22:39 -0500 Sam Hartman [EMAIL PROTECTED] wrote: I'd like to present one other example that motivates why I think having the review process is important. Say that the IASA has decided to pursue a meeting in Beijing. No contract has been signed yet, but that's getting close. Many contributors indicate they will be unable to attend. The IAOc has been focusing on the business aspects of the meeting: how affordable is it, are the necessary facilities available. The IESG and/or IAB formally asks for a review, arguing that whether the right set of people will attend a particular meeting is an important factor to consider in meeting site selection. Regardless of whether the IAOC ends up deciding to reverse its decision, having this review be available is important. Ok. If we are doing meeting planning the way we have been doing meeting planning, there is no announcement to the community before a contract is signed. The IETF Chair knows, but the IAB and IESG generally don't, and random IETF participants certainly don't know. If we are going to change that, then changes need to be made elsewhere than in this section.Under current practice, the window you assume simply doesn't exist. If we want it to exist, we need to make procedural changes elsewhere -- probably not in the BCP, but in some way that makes expectations extremely clear to the IAOC and IAD. If, via those changes, the window is opened sufficiently that the IESG and/or IAB can complain, then, under the scenario you are describing, the IESG/IAB aren't involved with any of what I (and I think Mike) are worried about.What you describe is providing input to the IAD and IAOC _before_ a decision is made. I think the IAOC should be open to pre-decision community input, formal or otherwise. I think it would be seriously bad news if the IAOC closed its collective ears to such input. I think that, if the IAD stops listening to community input, and especially IAB and IESG input, it would be a good sign that the individual in that job should be re-educated or forced out of the position. But that isn't what I (and probably Mike, Spencer, and others) are concerned about. We are concerned about the decision gets made and then someone tries to second-guess it scenarios, on which we want to place extreme limits. So, from my perspective, if the case you describe is the one that is of interest, you should be concentrating less on the review (or appeal) procedures and other mechanisms for questioning or correcting decisions already made and more on being certain that, in areas where it is appropriate, the IAOC is sufficiently open about what it is considering that pre-decision/ pre-contract input is feasible. Now, for some cases, that won't be practical for particular situations or potential contracts. But there too, I think there is a useful make a window for comments process. Taking your meeting case as an example, I personally believe that the IAOC should be setting criteria for meeting site selection, that those criteria should be public, and they should be set independent of particular sites and with full IETF community involvement (a radical change from either the IETF Chair approves or the IETF Chair decides). The right set of people needs to be able to go is an important criterion which has nothing specific to do with possible meetings in Beijing (or, for that matter, in Fiji or Washington). If that is an established criterion, than an IAD who doesn't do due diligence on who could or could not attend prior to making a decision is failing in the job. IAD job failure problems aren't managed by reviews or appeals; that is what we have the IAOC for. And, if they can't manage the job failures in an effective way... well, that gets us back to discussions of group firing, but it isn't, IMO, a post-decision review issue either. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Confidentiality obligations (Re: Legal review 4: Minor editorial)
--On Monday, 24 January, 2005 08:23 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: 7 (Transparency): While I understand the desire for transparency, there may be some contracts that contain items that are justifiably treated as confidential (such as individual performance rewards, terms of settlement of litigation). To address this point, I might add the following words at the end of the penultimate sentence: , subject to any reasonable confidentiality obligations approved by the IAD. Harald, given the general commitment in the community and document to transparancy whenever possible, I wonder whether the IAD should be empowered to do this or should, e.g., be required to report the terms and nature of what confidentiality obligations are being assumed to the IAOC so that they can review it as appropriate. Note that I'm not proposing disclosing the confidential information to them, but it seems to me to be reasonable to tell them the nature of what is being kept secret and why. hm. I could certainly argue that the IAOC should approve at least the criteria that the IAD uses to determine that some confidentiality is OK, and could also argue that the IAOC, being IASA oversight, ought to be able to look at all the confidential parts of things if it needed to. We could move the approval up to the IAOC with no loss in confidentiality, and with some gain in transparency/accountability, I think. That would certainly be consistent with what I was suggesting. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Legal review 2: Trademarks
Harald Tveit Alvestrand wrote: Suggestion: Add to section 3, one paragraph before section 3.1: The IASA is responsible for undertaking any and all required actions that involve trademarks on behalf of the IETF. Works for me Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Legal review 3: Legal advice
John C Klensin wrote: --On Friday, 21 January, 2005 15:42 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: From Jorge: 3. Legal Advice. (Apologies if I sound biased about this one, but) Although the IAD and IASA have responsibility for negotiating and approving all contracts relating to IETF, there is no indication that they are expected or even encouraged to seek legal advice regarding these contracts. Given the unclear language of some of the historical IETF-related contracts, I think it would be advisable to set forth a principle that the IAD should seek legal advice regarding any material contract that he/she negotiates. This would exclude routine contracts for things like office services, but should definitely apply to the contracts with ISOC, IANA, ICANN, the RFC Editor, the conference organizer (whether it's CNRI, Fortec, or somebody else), and any contract that relates to the development of data, software or other IP. Good catch. And yes. Moreover, I think that an express statement should be made that the IAD/IASA should obtain independent legal advice. That is, from legal counsel who are not ISOC's counsel. This will serve to reinforce the independence of IETF from ISOC. While it isn't easy to think of cases where conflicts of interest might arise, this seems to be to be useful at best and harmless at worse. And, as you point out, it has useful symbolic value, although I would have stated that last sentence as ...of IASA from ISOC. It seems fairly clear that for things such as contracts, which will commit ISOC, ISOC's own counsel will be involved. But there may be other issues, such as IPR policy, where IETF having its own counsel will continue to be a good idea. But I don't think the BCP prevents this, so I'm not sure what text change is needed. Briab ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Legal review results 1: Intellectual property
Harald Tveit Alvestrand wrote: (explicit CC to Jorge, since I'm interpreting his words) --On fredag, januar 21, 2005 10:49:21 -0500 Bruce Lilly [EMAIL PROTECTED] wrote: Verbosity aside, I don't believe that sole control and custodianship applies to open source software. I am not a lawyer, but the Old text seems not only more easily comprehended [I am reminded of Jonathan Swift's satirical look at lawyers in Gulliver's Travels, and dismayed that things haven't improved in 275 years] but seems to be considerably more favorable to open source software than the proposed new text; the latter appears to be heavily biased towards commercial software. On reading the text again, I think this text: (B) If an IASA Contract provides for the creation, development or modification of any software (including, without limitation, any search tools, indexing tools and the like) (Developed Software) then the IAD shall, whenever reasonable and practical, ensure that such contract either (a) grants ownership of such Developed Software to ISOC, or (b) grants ISOC a perpetual, irrevocable right, on behalf of IASA and IETF, to use, display, distribute, reproduce, modify and create derivatives of such Software (including, without limitation, pursuant to an open source style license). It is preferred that Developed Software be provided and licensed for IASA and IETF use in source code form. ISOC will permit IASA and its designee(s) to have sole control and custodianship of such Developed Software, and ISOC will not utilize or access such Developed Software in connection with any ISOC function other than IETF without the written consent of the IAD. The foregoing rights are not required in the case of off-the-shelf or other commercially-available software that is not developed at the expense of ISOC. actually is OK for making software free - that would come under the section that says: or (b) grants ISOC a perpetual, irrevocable right, on behalf of IASA and IETF, to use, display, distribute, reproduce, modify and create derivatives of such Software (including, without limitation, pursuant to an open source style license). If we assume that the IETF will never be interested in preventing others from using its software, we can remove the stuff that says .. and ISOC will not utilize or access. without the written consent of the IAD. Jorge - see any problems with removing this? The IASA and its designee(s) says that IASA, not ISOC, decides to give others permission to use it - ISOC can't give orders to IASA to limit it. We should perhaps ask Jorge to modify his words to ensure that they don't preclude IASA from using or contributing to open source software. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Legal review results 1: Intellectual property
Date: 2005-01-24 08:12 From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org CC: Jorge Contreras [EMAIL PROTECTED] (explicit CC to Jorge, since I'm interpreting his words) On reading the text again, I think this text: (B) If an IASA Contract provides for the creation, development or modification of any software (including, without limitation, any search tools, indexing tools and the like) (Developed Software) then the IAD shall, whenever reasonable and practical, ensure that such contract either (a) grants ownership of such Developed Software to ISOC, or (b) grants ISOC a perpetual, irrevocable right, on behalf of IASA and IETF, to use, display, distribute, reproduce, modify and create derivatives of such Software (including, without limitation, pursuant to an open source style license). It is preferred that Developed Software be provided and licensed for IASA and IETF use in source code form. ISOC will permit IASA and its designee(s) to have sole control and custodianship of such Developed Software, and ISOC will not utilize or access such Developed Software in connection with any ISOC function other than IETF without the written consent of the IAD. The foregoing rights are not required in the case of off-the-shelf or other commercially-available software that is not developed at the expense of ISOC. actually is OK for making software free - that would come under the section that says: or (b) grants ISOC a perpetual, irrevocable right, on behalf of IASA and IETF, to use, display, distribute, reproduce, modify and create derivatives of such Software (including, without limitation, pursuant to an open source style license). Several concerns with the specific text re. open source software: 1. ISOC will permit IASA and its designee(s) to have sole control and custodianship of such Developed Software seems inconsistent (in particular the word sole) with the spirit of open source software. 2. The foregoing rights are not required in the case of off-the-shelf or other commercially available software ... specifically seems to favor commercial software, but not open source software, by providing exemptions for commercial software. 3. It is not clear (to this non-lawyer) what the status of parenthetical remarks is -- I'd be more comfortable if the including, without limitation, pursuant to an open source style license were not parenthesized. I think Brian Carpenter's suggestion for review and modification to ensure that use of or contribution to open source software is not precluded is a path forward. To which I'd add that use of open source software shouldn't be disadvantaged. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
A little more feedback? #818 Hiring and firing the IAD
I believe that the text Scott proposed for section 3 to replace paragraph 3 is acceptable (minor edit). But John Klensin suggested one additional edit - adding a nomcom-appointed member - which got no further feedback. So we have 3 alternatives: OLD Although the IAD is an ISOC employee, he or she works under the direction of the IAOC. The IAD is selected and hired by a committee of the IAOC. The members of this committee are appointed by the IAOC, and consist at minimum of the ISOC President and the IETF Chair. This same committee is responsible for setting the IAD's initial compensation, reviewing the performance of the IAD periodically, and determining any changes to the IAD's employment and compensation. NEW(1) Although the IAD is an ISOC employee, he or she works under the direction of the IAOC. A committee of the IAOC is responsible for hiring and firing of the IAD, for reviewing the performance and for setting the compensation of the IAD. The members of this committee are appointed by the IAOC, and consist at minimum of the ISOC President and the IETF Chair. NEW(2) Although the IAD is an ISOC employee, he or she works under the direction of the IAOC. A committee of the IAOC is responsible for hiring and firing of the IAD, for reviewing the performance and for setting the compensation of the IAD. The members of this committee are appointed by the IAOC, and consist at minimum of the ISOC President, the IETF Chair and one IAOC member that has been selected by the Nomcom. I don't see any world-shaking difference between these, but I slightly prefer the last one (with nomcom-selected member). I'd like this one, too, nailed before -05 rolls Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Edits - #819 - Elwyn's editorials
There has apparently been no comments on these I thought I'd make a pass... Some thoughts: S1, para 3: s/Such support includes/The support for current work includes/ this works either way for me - current seems to say the next sentences describe what is currently done, and the future may be different. Suggest that we accept the edit. S1, Para 3: The IASA is also ultimately responsible for the financial activities associated with IETF administrative support such as collecting IETF meeting fees, paying invoices, managing budgets and financial accounts, and so forth. Given that IETF/IASA is operating as some sort of subsidiary of ISOC, I'm not sure that IASA can be ultimately responsible for anything. s/ultimately/day-to-day/ or some such? I'd go for just deleting ultimately. The work may be contracted out, so it's not day-to-day, but ultimately is just trouble. S1, para 4: 'and met well' ? Nice thought but what does it *actually* mean? That we (the IETF) like the result? I would like this to stay, undefined as it is. S2.2: I know that US data protection laws and practices are not as well developed as European ones, but I think there ought to be some duty to protect the data and generate a suitable privacy policy, as well as keep it available. (Item 7). I think there should be - but don't see a good way of capturing it here. I'd let it go for now and try to instruct the IASA later S2.2: Should the IASA be responsible for ensuring that the IETF (especially if it is run as a subsidiary) fulfils its legal and regulatory responsibilities? It certainly needs to maintain any records that might be needed for such purposes beyond just financial matters. I am not expert in US company law but I am sure there must be *some* things they would need to do. Hm. Yes. It needs to deal with subpoenas and other irritations, for instance. But this is a bit like saying you are responsible for staying wet while in water. I can't think of text at the moment S3.1, para 3: This para states that signing powers will be delegated to the IAD up to some specified limit. Who has signing powers beyond this? This is just part of a much wider point about the actual powers of the IETF/IAOC and the relationship with ISOC which I will discuss at the end of these notes. The text at the moment doesn't say exactly that - it says that we'll work it out.. I don't know what more it CAN say S3.1: I think this whole section should be much clearer about exactly what powers are delegated to the IAD to make commitments, as opposed to just negotiating: ISOC executes the contracts but the IAD will want to know that ISOC is a rubber stamp/back stop for this process and is not going to start second guessing him if he operates within the parameters set for him. This is related to the long discussion on Issue 739. There is also the potential for dispute between IAOC and IAD/ISOC which is not really addressed. Not sure what to add here, if anything - this will have to be worked out in practical terms, and the IAOC will have to work out the details in cooperation with the ISOC President. Should there be specific language? s3.4: It would be nice to see a requirement that minutes were published in a set period or at least in a timely fashion after meetings, rather than just regularly. Suggest s/regularly/in a timely fashion/. Easy change s4: While there are no hard rules regarding how the IAB and the IESG should select members of the IAOC, such appointees need not be current IAB or IESG members (and probably should not be, if only to avoid overloading the existing leadership). The IAB and IESG should choose people with some knowledge of contracts and financial procedures, who are familiar with the administrative support needs of the IAB, the IESG, or the IETF standards process. The IAB and IESG should follow a fairly open process for these selections, perhaps with an open call for nominations or a period of public comment on the candidates. The procedure for IAB selection of ISOC Board of Trustees [RFC3677] might be a good model for how this could work. After the IETF gains some experience with IAOC selection, these selection mechanisms should be documented more formally. Given the comments in S3, para 1, should the appointees by 'regular members' of the IETF (i.e., people with a good track record of attending IETF meetings) as with NomCom members are their appointees? Actually previous discussion indicates that we do NOT want to impose such a requirement - the people who know how to supervise a business construct like IASA are not the same people who know how to design an efficient transport protocol. So we want to have this open for getting the right people, I think. Makes sense? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
--On Monday, 24 January, 2005 10:18 -0500 Sam Hartman [EMAIL PROTECTED] wrote: I agree with you that pre-decision comments are preferable and that processes and procedures should allow these comments. I also agree that the example I proposed cannot happen under current procedures because there is not a comment window for meeting locations. I do not intend to speak to whether such a window would be a good idea. Understood. Let me only make the observation that I think it would be better to have clear criteria that the IASA is expected to follow than to have discussions of individual decisions, either before or after the fact. One of the reasons is that, for some sites that might otherwise be completely reasonable, having it be known that the site was considered and then rejected might turn out to be an embarrassment for the site and/or the IETF and such things should be avoided when possible. However, failure to take adequate comments before making a decision seems like a reasonable justification from my standpoint for reviewing that decision. Depending on the consequences of doing so it may even be appropriate to reverse such decisions. There is significant but *not infinite* cost to reversing a decision. There can also be significant cost to having a bad decision. There is also a cost to the review process itself. This may go to the core of the difference in my position and yours. Let's review the composition of the IAOC. The IETF and IAB Chairs are members. If the are doing their jobs there, they are aware of decisions before they are made, can argue the IAOC to establish appropriate rules for the IAD to engage in consultation before a decision is made, and so on. If they are dissatisfied with the amount of review a pending decision is getting, they can request reviews or reconsideration internally, take the issue up with the IAB or IESG which might then demand a review, or even initiate an IETF-wide discussion about recalls. Conversely, if they fail in those regards and decisions are made without adequate comments and that fact takes the IETF community by surprise, then perhaps they should be the first people recalled. I'm making an assumption here which might not be valid. I'm assuming that, generally, possible IAOCs will fall into one of two categories. One --the one we want-- will be open and transparent whenever possible, will try to design things to allow for community input before decisions are made whenever possible, and will try to establish principles, in conjunction with the community, about how things should be done and then follow them. At the other extreme, one might imagine an IAOC that tried to do everything in secrecy, that was relatively insensitive to community input, and that tried to arrange its decision-making processes (and that of the IAD) so that there was as little opportunity for distracting input or comment as possible.I think it is extremely unlikely that we would end up with an IAOC that would be open about some things but as secretive as possible about others, at least unless the openness was used as a deliberate cover for the secrecy. Now, in my view, the problem of the second or third styles of IAOC operation is not solved by better techniques for reviewing and/or changing individual decisions. The solution is replacing the IAOC membership (serially if needed) with a group that will get the notion of being open and responsive to the IETF community. If we all understand that the expectation of the IAOC is as much openness and opportunity for comment as is possible and sensible given the particular issue, and we hold the IETF-appointed members of the IAOC (including especially the two Chairs) responsible for reminding the IAOC about that norm, then we won't need post-decision reconsideration procedures for individual decisions. Conversely, if the IAOC doesn't act according to that norm, we should focus on that fact and fixing it (in a hurry) and not on the particular decisions that result... if only because a good decision that is made without adequate opportunity for contact is as much of a problem as a bad decision made under the same circumstances. Question: do you see cases where if a problem developed we'd be unable to deploy safeguards fast enough or unwilling to deploy the safeguards even given an actual instead of theoretical problem? How likely do you see these situations? I think it is up to the Nomcom and to the IAB. The IETF community's main insurance against IAOC misbehavior with regard to decision-making is the presence of the two Chairs on the IAOC and how those people behave, not provisions of the BCP. Were the two Chairs to start behaving as if they took their instructions and guidance direct from some deity, rather than from the community, the IAB and the IESG, and to encourage the IAOC to behave on a similar basis, then I can imagine all sorts of problems that none of the safeguards we have
FYI: Unicode proposal to break NFKC backwards compatibility
I have not seen this apparently IETF related Unicode news mentioned here, so FYI: If anyone is interested in Unicode normalization issues, especially wrt to Stringprep or Internationalized Domain Names (IDN), you might be interested in a current public review issue in the UTC: Issue #61 Proposed Update UAX #15 Unicode Normalization Forms A proposed update to UAX #15 for Unicode 4.1.0 is available at the link above. The proposed changes are listed in the Modifications section of the document. The UTC accept comments from the public until January 31th. The above abstract isn't informative, but when you look at the proposed changes: http://www.unicode.org/reports/tr15/tr15-24.html It is clear that this is the next step of the backwards incompatible NFC/NFKC normalization change first discussed in: http://www.unicode.org/review/pr-29.html That change affect all StringPrep profile that uses NFKC normalization. The change may imply interoperability problems, or at worst security problems, when/if IETF wants to use Unicode 4.1 or later in StringPrep. As far as I am aware, the IETF has not given implementors advice on whether to follow the proposed UTC change or not. My experience is that deployed IDN implementations are not implemented the same way. Regards, Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
But that isn't what I (and probably Mike, Spencer, and others) are concerned about. We are concerned about the decision gets made and then someone tries to second-guess it scenarios, on which we want to place extreme limits. This is exactly what Spencer is concerned about... this, and the bozo factor that results from us making and remaking decisions (is this the last zig, or will we be zagging again?). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A little more feedback? #818 Hiring and firing the IAD
I prefer NEW(2) Although the IAD is an ISOC employee, he or she works under the direction of the IAOC. A committee of the IAOC is responsible for hiring and firing of the IAD, for reviewing the performance and for setting the compensation of the IAD. The members of this committee are appointed by the IAOC, and consist at minimum of the ISOC President, the IETF Chair and one IAOC member that has been selected by the Nomcom. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
MIME Type Registration Request Approval: application/csta+xml
The IESG has approved a request to register the application/csta+xml MIME media type in the standards tree. This media type is a product of Ecma International. The IESG contact persons are Ted Hardie and Scott Hollenbeck. MIME media type name: application MIME subtype name: csta+xml Required parameters: (none) Optional parameters: (none) Encoding considerations: This content type uses XML, employing UTF-8 character encoding. Security considerations: This content type is designed to carry information about users involved with communications which may be considered private information. For example, the identity of a calling party in a voice call. This content type is also designed to be used to control communication calls and communication devices such as telephones. Appropriate precautions should be taken to insure that applications observing and controlling communications and communication devices using CSTA are authorized to do so. Interoperability considerations: application/csta+xml documents are specified by the XML schemas standardized in ECMA-323. Published specification: The published Standard ECMA-323 is available at: http://www.ecma-international.org/publications/standards/Ecma-323.htm Applications which use this media type: The application/csta+xml MIME type can be used to identify CSTA XML (ECMA-323) instance documents. Additional information: CSTA XML (ECMA-323) is an application level protocol that enables an application to control and observe communications involving various types of media (voice calls, video calls, instant messages, Email, SMS, Page, etc.) and devices associated with the media. Person email address to contact for further information: Ecma Secretariat Rue du Rhone114 CH-1204 Geneva Switzerland [EMAIL PROTECTED] Intended usage: common Author/change controller: The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11 Working Group. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP' to Experimental RFC
The IESG has approved the following document: - 'F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP ' draft-ietf-tcpm-frto-02.txt as an Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary This document describes an algorithm for detecting spurious TCP retransmission timeouts called F-RTO. In contrast to alternative algorithms proposed for detecting unnecessary retransmissions, F-RTO does not require any TCP options for its operation, and it can be implemented by modifying only the TCP sender; however, F-RTO detects only unnecessary retransmissions after an RTO, not retransmissions caused by events such as packet reordering. This document does not describe the response to spurious timeout, merely the detection algorithm. The mechanisms described in this document are also applicable to SCTP. Working Group Summary This document is one of several approaches to the detection of spurious retransmissions that have been considered in the TSVWG and TCPM working groups. The community believes that the publication of more than one experimental approach to this problem will help to expose the pros and cons of the respective methods. Protocol Quality This document was reviewed for the IESG by Jon Peterson. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Addition of Camellia Ciphersuites to Transport Layer Security (TLS)' to Proposed Standard
The IESG has approved the following document: - 'Addition of Camellia Ciphersuites to Transport Layer Security (TLS) ' draft-ietf-tls-camellia-06.txt as a Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Russ Housley and Sam Hartman. Technical Summary This document specifies the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. Working Group Summary The TLS Working Group reached consensus on this document. Protocol Quality This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Things MULTI6 Developers should think about' to Informational RFC
The IESG has approved the following document: - 'Things MULTI6 Developers should think about ' draft-ietf-multi6-things-to-think-about-01.txt as an Informational RFC This document is the product of the Site Multihoming in IPv6 Working Group. The IESG contact persons are David Kessens and Bert Wijnen. Technical Summary This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution either. Working Group Summary This document is a product of the multi6 working group. Protocol Quality This document was reviewed for the IESG by David Kessens. IANA Note This document doesn't need any IANA actions. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
