Re: Suggest no change: #739 Assuring ISOC commitment to AdminRest
Well, Pete Resnick wrote: That said, let me offer a few thoughts on why I specifically don't think a by-law change is what you want. The by-laws deal primarily in the mechanics of ISOCs structural implementation: Not so of Article VI, sections 2 5, which seem somewhat akin (though less specific) to the kind of thing I've been talking about. With some disbelief that I'm dissecting another organization's by-laws on the IETF discussion list, I will say: what I read in those 2 specific by-laws is the provision of tools to ISOC for getting its work done. I understand you to be reading them as requirements. While your proposed text: I know you would look to a lawyer to provide the specific wording, but I'm trying to grapple with what sort of a thing would be inserted here to meet your need: something that says ISOC will support the IETF per the structure outlined in BCPXX seems vastly out of place. Loosely following the structure of VI.5: The Society will maintain a supporting relationship of the IETF administrative operations as outlined in BCPXX. would be somewhat analogous to those if they were requirements, I don't believe it flies as a tool to ISOC for getting its job done. Which is why I don't (personally) think it is an appropriate addition. Not, however, my decision, either way! So, why not a resolution, then? Because: a future ISOC BoT could adopt a resolution to change or nullify that support with little warning and less than a 4/5 majority vote. I think that sums it up. But, the truth of the matter is, if the ISOC BoT has gotten to the point where that seems like a reasonable course of action, we (the IETF, ISOC,the Internet at large) are in such deep doo-doo in our relationship that the action is not the bad news. As I think I've said before, I have seen in many organizations the ability of leaderships in organizations to (occasionally in the course of their existences) be composed of a significant handful of disruptive and problematic folks. Not a majority of the leadership, but just shy of one. And I've seen those disruptive and problematic folks occasionally shout loud enough to convince just one or two of the good folks to join them in a squeaker of a majority to vote for utterly stupid things. Usually their ability to do that is short lived (both due to the good people figuring out that their ideas are stupid and their inevitably short tenure), and the organization itself survives the period of silliness. But I can't remember a time where the bad people have gotten a super-majority (like 4/5) to go along with them. And, certainly, I've known groups/boards that suffered pathologically, too. But where we apparently disagree is that I believe, if we get to the point where so much of the ISOC board has such a divergent view of the universe than the IETF does, we will have much bigger issues to deal with than whether or not they can change a resolution to support this BCP. Quite frankly, if the ISOC BoT is so inclined, we maybe *want* to be moving on, and will be chafing at the slow nature of the IETF BCP process (as you observed). Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA removability - rephrase IAOC role
Yep, I think that's the right fix. Leslie. Harald Tveit Alvestrand wrote: I think I should apologize for including a modification to the IAOC role in the removability clause in a discussion of finances. It is not relevant to that topic. But the discussion pointed out to me that there is some strangeness here - in that the IAOC is described as having a role in the process for removing IASA from ISOC, while the ISOC president is on the IAOC. Current text: Removability: While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA shall be structured to enable a clean transition in the event that the IETF community decides that such a transition is required and documents its consensus in a formal document (currently called a BCP). In such a case, the IAOC shall give ISOC a minimum of six months notice before the transition formally occurs. During that period, the IAOC and ISOC shall work together to create a smooth transition that does not result in any significant service outages or missed IETF meetings. All contracts executed by ISOC on behalf of IASA shall either include a clause allowing termination by ISOC with six months notice, or shall be transferable to another corporation in the event that the IASA transitions away from ISOC. Any accrued funds, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. I think a more correct phrasing is to make this the IETF's responsibility, not the IAOC's. If the IETF decides to use some part of the IAOC in some fashion in the changeover phase, that's their privillege to decide at the time - one would think that this would be part of the BCP text. New phrasing: Removability: While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA shall be structured to enable a clean transition in the event that the IETF community decides that such a transition is required and documents its consensus in a formal document (currently called a BCP). In such a case, the IETF shall give ISOC a minimum of six months notice before the transition formally occurs. During that period, the IETF and ISOC shall work together to create a smooth transition that does not result in any significant service outages or missed IETF meetings. All contracts executed by ISOC on behalf of IASA shall either include a clause allowing termination by ISOC with six months notice, or shall be transferable to another corporation in the event that the IASA transitions away from ISOC. Any balance in the IASA accounts, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. Other terms will be negotiated between the IETF and ISOC. None of this text has been flagged as controversial in the last month of discussion, so I don't think it should be controversial now. And - again - I don't think we'll ever have to use it, but it's OK to have it written. OK? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Confused about references to I-D when the RFC is published
I will admit to having been a little more focused, during AUTH48, on making sure that the document got back to saying what it had said when it entered the RFC Editor queue some 5 months earlier. Leslie. John C Klensin wrote: --On Sunday, 09 January, 2005 22:22 +0100 Stephane Bortzmeyer [EMAIL PROTECTED] wrote: Last week, one RFC has been published with a reference to an I-D when the final RFC is already published. RFC 3958 says: [11] Atkins, D. and R. Austein, Threat Analysis Of The Domain Name System, Work in Progress, April 2004. while RFC 3833 is five months old. Now, I understand that RFC 3958 was probably approved before RFC 3833 was issued. But I thought (ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-proce ss.gif) that references were supposed to be updated by the RFC editor even after approval by the IESG? Yes. But this is also the sort of thing that authors are supposed to check carefully on RFC Editor 48 hour author's last call. Slip-ups happen; no one is perfect. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA Finances - an attempt at some uplevelling
John, I believe Harald meant ISOC-appointed members of the IAOC, and not folks on the IAOC who happen to be ISOC members. (Hopefully, everyone on the IAOC will be an ISOC member...). That said, I'm not entirely comfortable with the proposal. I don't want to belabour it, because I don't want to give particular importance to something that is intended to be an edge case. I would suggest that the right way to handle it is, either: . to note that this will be rife with potential for conflict of interest, and that IAOC members appointed (or ex officio) by ISOC are expected to recuse themselves from discussion of separation issues (this should amount to what Harald has said, but phrases it in terms of more normal operating procedures); or . define a new committee, that is not the IAOC, but the IETF-specific subset (+ others, as necessary). Leslie. John C Klensin wrote: --On Monday, 10 January, 2005 16:31 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: ... Any IASA account balance, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. Other terms of removal shall be negotiated between the non-ISOC members of the IAOC and ISOC. (the last point is an afterthought. It seems strange to have ISOC members negotiating with ISOC in the case of a separation. While I don't expect to have to use that paragraph, many have argued that it's better to get it written properly while we're starting than to wait until we need it.) Harald, I may have other thoughts on your other suggestions as I think more about them, but this strikes me as just wrong. There are many people who are members of ISOC who are members because it seems like the Right Think to Do, with or without the former $35 fee. Many people became members by virtue of attending one conference or another, and are still on the rolls since the membership fee was eliminated and everyone was carried forward. Unless you want to make non-ISOC-membership a criterion for anyone on the IAOC who is not appointed by ISOC --which I think would be a very serious case of shooting ourselves in the foot-- you run the risk of every IAOC member being also an ISOC member, leaving no one to negotiate or, worse, leaving only one or two people to represent all IETF interests. In addition, because this might discourage IETF participants from becoming ISOC members, there is a case to be made that the ISOC Board could not approve this without violating their duties to ISOC. It would be reasonable to exclude any person who has a position of authority or responsibility within ISOC's structure from participating on both sides of a negotiation (or negotiating for the IETF if you want to force them to the other side), excluding any ISOC member feels to me like it is both excessive and dumb. I'd look to Lynn or Fred for an acceptable way to state position or authority or responsibility in the ISOC context. I don't know what would work and be stable as they evolve their management and volunteer structures. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Conflict of Interest Clause?
Howdy, Margaret Wasserman wrote: I was thinking more of ongoing contracts... For instance, let's say that we contract with Margaret's Meeting Management (MMM -- and no, I am not considering a new career :-)) for our meeting planning. Would it be reasonable for someone who works for MMM to be an IAOC member? Would he/she need to recuse him/herself from every decision having to do with meetings? I think it would be sensible for the IAOC member to resign if it was a problem. If they didn't resign, and the rest of the IAOC thought it was a problem, there are recall measures (because it could be construed as abrogation of IAOC duties). Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Revised IAD hiring plan
The IASA Transition Team (TT) reviewed the comments on the draft IAD job description, paying particular attention to the thread about whether or not the IETF should take this to a professional executive search firm. In reviewing the experiences related by people on the IETF mailing list, as well as our own collective experiences with executive search efforts, we believe the cons of such an approach outweigh the pros in this case. Chiefly, as has been noted on this list, the success of such a search is largely dependent on having an employment opportunity that fits well with existing portfolios, and a serious endeavour takes months to set up and run properly. We feel that the IETF needs to get the IAD on board as soon as possible, and that the right person would be able to take an active part in shaping the role, so rather than spend the time needed to explain the role fully to a search agency, we hope to spend the time explaining it to the candidates for the job. There was also strong suggestion that more expertise should be applied in creating the job description, and that more time should be given for review of the result. While recognizing this is necessarily eating into IAD on board with IASA establishment time, it seems like a sensible adjustment to plans. Accordingly, we plan to change the IASA transition timeline as follows: DEC 23 Send the job description to a professional for review JAN 10 Circulate revised job description to IETF discussion list JAN 14 Post the job description publicly o IETF-Announce list o ISOC announcement lists o NANOG, SANOG, NORDNOG, AFNOG, etc o Ask RIRs to forward to their respective announcement lists FEB 14 (Valentine's day) - evaluation of applicants start MAR 1 (earliest) - decision The IASA TT will manage this process for as long as is appropriate. That is, if the IASA BCP is approved in early January, the initial IAOC will be able to undertake the evaluation from the outset (mid-February). If the BCP approval is delayed (and, therefore, the IAOC is not seated until later), the IASA TT will continue with the initial review of candidates, per the original plan. Leslie, for the IASA TT. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
, because accountancy and auditing cost real money. Brian Wijnen, Bert (Bert) wrote: Inline Biran answered me: Wijnen, Bert (Bert) wrote: I am not a real accountant and kind of simple-minded. So when you say: Lynn == Lynn St Amour [EMAIL PROTECTED] writes: Lynn over 80% of ISOC's org. members donate less than $10K Lynn annually and managing these in a 'restricted accounting Lynn manner' requires more effort and overhead. Also, Lynn organizations/donors expect recognition appropriate to their Lynn contribution and that implies differing levels of value and Lynn distinction. I then wonder - if there is s separate or special bank account for IASA/ETF - if I can just deposit my donation into that bank account - What then is the more effort and overhead ?? I just do not understand. Bert, I'm sure Lynn will answer this too, but from when the ISOC was discussing accounting practices for individual member subscriptions and donations, I remember that the bank account aspect is the least of the worries (and anyway, we already reached consensus not to have a separate bank account). I am not even talking about separate bank account as we did in an early rev of the iasa-bcp doc. I am talking about an ISOC bank account that will ONLY receive donations targeted for a specific purpose. By depositing money on the specific bank account, you IMPLICITLY tell ISOC that the money is intended for a specific purpose, in this case IETF. Again it must be the simple-minded me who does not understand. Bert he issue is that accounting entries have to be made in a very specific way for money which is tied to a specific purpose, and while that is a small overhead if someone donates $100k, it becomes a significant overhead if 100 people donate $1k. It can end up eating money for accounting actions that really serve no useful purpose but have to be done to follow thr accounting rules. So I think Lynn is correct and we have to give ISOC the necessary flexibility. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
Let me try a slightly different cut on the discussion. 1/ I believe the IETF is trying to address the fact we would like to be able to accept support in chunks that are greater than individual meeting fees, and less than $100kUS. IMHO, it's not that the IETF needs to be able to accept donations in *any* size between those, but I have heard people say that they know the person in their company who could write a cheque for $40k, if it will pecifically support the IETF, but there's no way they can get $100k through their budget. 2/ I believe we've also heard the IETF say that it wants to be able to clearly identify its collected assets (and, as the flipside, is willing to pay for all of its expenses). This is driven by a lot of factors, but I think the an important one is that the IETF believes it can and should be financially viable. Taking the bad along with the good, we want to be in an environment where we can prove that out empirically. 3/ We've heard clear explanations that attracting and managing corporate donations is not a simple task. Specifically, that there are reasons that it's not a simple matter to drop the level of donation necessary for designating donations. I don't believe the BCP needs to have specific text about *how* 1/ and 2/ are achieved. The current text is about how, and perhaps that's why it does not reconcile with 3/. The question is, do we all believe 1/ and 2/ are achievable? If we do have a meeting of the minds that they are, given the constrains in 3/, then what we have is only a wording problem to capture that meeting of the minds. If we do not have such a meeting of the minds, then we should figure out fast whether it's a difference of opinion, or whether 1/ and/or 2/ are not reasonably achievable in any universe. Leslie. Brian E Carpenter wrote: Bert, that does not change the need for the ISOC accountants to generate a separate entry for each case and for the auditors to check each of those entries. It's a real cost, because accountancy and auditing cost real money. Brian Wijnen, Bert (Bert) wrote: Inline Biran answered me: Wijnen, Bert (Bert) wrote: I am not a real accountant and kind of simple-minded. So when you say: Lynn == Lynn St Amour [EMAIL PROTECTED] writes: Lynn over 80% of ISOC's org. members donate less than $10K Lynn annually and managing these in a 'restricted accounting Lynn manner' requires more effort and overhead. Also, Lynn organizations/donors expect recognition appropriate to their Lynn contribution and that implies differing levels of value and Lynn distinction. I then wonder - if there is s separate or special bank account for IASA/ETF - if I can just deposit my donation into that bank account - What then is the more effort and overhead ?? I just do not understand. Bert, I'm sure Lynn will answer this too, but from when the ISOC was discussing accounting practices for individual member subscriptions and donations, I remember that the bank account aspect is the least of the worries (and anyway, we already reached consensus not to have a separate bank account). I am not even talking about separate bank account as we did in an early rev of the iasa-bcp doc. I am talking about an ISOC bank account that will ONLY receive donations targeted for a specific purpose. By depositing money on the specific bank account, you IMPLICITLY tell ISOC that the money is intended for a specific purpose, in this case IETF. Again it must be the simple-minded me who does not understand. Bert he issue is that accounting entries have to be made in a very specific way for money which is tied to a specific purpose, and while that is a small overhead if someone donates $100k, it becomes a significant overhead if 100 people donate $1k. It can end up eating money for accounting actions that really serve no useful purpose but have to be done to follow thr accounting rules. So I think Lynn is correct and we have to give ISOC the necessary flexibility. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Suggest new mailing list for IASA stuff
Well, the choice to put this on the ietf-discuss list was deliberate: including making sure that a reasonable cross section of the IETF would see the discussion. It's not at all clear that such a cross section would bother to subscribe to a new mailing list (and a new mailing list often just attracts the people who are interested for the wrong reasons). In my personal opinion, it would be better to leave the discussion here at least until the last call on the BCP is done. At that point, we'll be into implementation, and if there are further matters to discuss, it would be reasonable to say we are now into implementation phase, people who are interested can subscribe here. Also, the threads are pretty easily identifiable (and skippable). Again -- IMO. Leslie. Michael StJohns wrote: The IASA, AdminRest et al discussions appear to be proceeding well, but perhaps it might make sense to craft a mailing list specifically for those discussions ? Its possible the recent (last 2 week) upswing in the number of related posts to the ietf mailing list will die down shortly, but my guess is not. Later, Mike ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Transparency/Openness of the IAOC
Margaret Wasserman wrote: Hi All, In reviewing the IASA BCP draft, I noticed that there are no specific requirements regarding the level of transparency or openness expected from the IAOC. IMO, we should be careful to start this activity with a well-established understanding regarding the level of transparency and openness that we expect. Do we expect the IAOC to keep minutes of their meetings and post them publicly (unless there is a specific reason not to post a certain section)? Specific reasons might include: personnel issue and/or sensitive negotiation-position-related information. Seems reasonable -- as does, eg, the IAB today. Do we expect the IAOC mailing list archives to be publicly available? As you've noted later -- doesn't seem entirely reasonable or needful. Should the IAOC maintain a web site that lists its members and their e-mail addresses? Agree with the ietf.org suggestion. Should the same web site also include a record of all written/legal correspondence received by or sent by the IAOC (with sections removed if absolutely necessary for confidentiality)? Firstly, do you really mean IAOC? Or IAD? Or IASA as a whole? I have a hard time imagining that the IAOC is going to get a lot of formal correspondance. Irrespective of that -- I believe the key requirement is that the material needs to be maintained and accessible to successive generations of IAD/IAOC in support of the IASA function. It's not at all clear to me what problem would be solved by requiring all correspondance to be publicly archived, though, beyond what we already have in the document: [From the current version of the doc:] Transparency: The IETF community shall have complete visibility into the financial and legal structure of the ISOC standards activity. In particular, a detailed budget for the entire standards activity, quarterly financial reports, and audited annual financial reports shall all be available to the IETF community. In addition, key contract material and MOUs shall also be publicly available. The IAD and IAOC are responsible for providing regular overviews of the state of the IASA to the IETF community. Should all of the official IAOC decisions be announced publicly? And/or do we expect a regular (monthly?) report on IAOC activities? What are official IAOC decisions? (As opposed to unofficial ones?). Before we dive down that rathole, perhaps what is really needed here is the statement that decisions should be minuted, and the minutes should be published regularly. If we think that it is reasonable to require any of these things, which ones should apply to the IASA TT that we just formed? Yes. THough I have to admit we've been struggling with the mechanics of getting good notes taken from any discussions. Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: iasa-bcp-01 - Open Issues - Separate bank accounts
Doesn't work for me -- who defines what is supportive? In the context of moving forward with the BCP and working with ISOC, it's obviously clear. But, to the extent that the text is meant ot address the case that the ISOC-IASA relationship is changing, we should not leave it until then to have the discussion about who calls the shots on supporting. Maybe, minimally: Donations to the IETF shall be irrevocably committed to the support of the IETF, by the mechanism defined by IETF consensus process. (I don't think that's quite it... but perhaps a start). Beyond that: get a lawyer or accountant to figure it out! Leslie. Scott Bradner wrote: Harald asks: Donations to the IETF shall be irrevocably committed to the support of the IETF. Does that make sense? works for me Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: iasa-bcp-01 - Open Issues - Separate bank accounts
At this point, I think I am confused. I have paged back through the e-mail thread, and attempted to see whether my version would or would not, should or should not, include meeting fees, and have not been able to put together an authoritative picture... I think I want to see what you think the current text is, in the context of the whole document revision, before I comment further. Leslie. Wijnen, Bert (Bert) wrote: Geoff responded to Leslie I think you are wanting to say that donation of funds to the IETF be placed under the exclusive control of the IETF support program within ISOC. This phrasing is slightly stronger than the irrevocable commitment phrase, but does fall just short of explicitly stating 'distinct fund account held in a financial institution'. I think that neither Leslies, nor Geoff wording includes the meeting fees, does it? And in my (personal) opinion we should include those as well. And indeed: Beyond that: get a lawyer or accountant to figure it out! I think we need to try to get some text in there that states (as good as possible) what we (IETF) want and then have that reviewed by legal, while at the same time doing IETF Last Call maybe. Bert Geoff At 06:57 AM 9/12/2004, Leslie Daigle wrote: Doesn't work for me -- who defines what is supportive? In the context of moving forward with the BCP and working with ISOC, it's obviously clear. But, to the extent that the text is meant ot address the case that the ISOC-IASA relationship is changing, we should not leave it until then to have the discussion about who calls the shots on supporting. Maybe, minimally: Donations to the IETF shall be irrevocably committed to the support of the IETF, by the mechanism defined by IETF consensus process. (I don't think that's quite it... but perhaps a start). Beyond that: get a lawyer or accountant to figure it out! Leslie. Scott Bradner wrote: Harald asks: Donations to the IETF shall be irrevocably committed to the support of the IETF. Does that make sense? works for me Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ 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
Re: Adminrest: created IPR
Hang on... are we not getting too detailed again, at the risk of over-constraining ourselves? As has been mentioned on this thread -- we (IETF) may well want to take advantage of non-open-source software, if it's the most effective efficient choice. I'm thinking specifically of contracting with a provider that has their own software tools. Neither should we be constraining ourselves to choose from providers with open source tools, nor should we be requiring that *all* features we ask to add to those tools be available as open source, or freely to the IETF, etc. Taking the step back -- the principle was that the IETF should retain the rights to, ability to access, and ability to move the data it creates.Period. Sensible ways of achieving that include (but are not limited to) working with open source tools and/or ensuring we retain ownership of any software that touches that data. Others include using reasonably accessible off the shelf software (one Excel program is much the same as the next...), or agreeing on data interchange formats. Let's not try to make the laundry list in this document. Leslie. Harald Tveit Alvestrand wrote: --On fredag, desember 03, 2004 10:19:23 +0100 Henrik Levkowetz [EMAIL PROTECTED] wrote: What about this text, (added to 2.2.6): As a matter of principle the IAOC and IAD should ensure that any contracts for IASA clearly designate that any software, databases, and websites developed should be available to the IETF with no restriction by the contractor. Software should be open source and data should be made available to the IETF in machine-readable format, also in cases where it may be inadvisable to make the data openly available. this works for me (my only problem is stylistic - it's somewhat long for a principle, so may fit better in the details sections, if a place can be found for it). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: created IPR
Henrik, I believe that's true of the principle, expressed this way: [I wrote:] Taking the step back -- the principle was that the IETF should retain the rights to, ability to access, and ability to move the data it creates.Period. I (still) believe that the text that was proposed (detailing *how* to implement that principle) is in danger of locking us out of, say, contracting with a professional meeting organization service that has proprietary software for managing meeting attendee lists. (I.e., software that could do a data dump for us, but that is not open source, for which we will not have license to run in perpetuity, yada yada yada). Leslie. Henrik Levkowetz wrote: No, I think that as a principle that prevents us from inadvertently or short-sightedly putting ourself into a locked-in position vis-a-vis a contractor, this kind of statement of principle is exactly what we need. Henrik on 2004-12-03 5:45 pm Leslie Daigle said the following: Hang on... are we not getting too detailed again, at the risk of over-constraining ourselves? As has been mentioned on this thread -- we (IETF) may well want to take advantage of non-open-source software, if it's the most effective efficient choice. I'm thinking specifically of contracting with a provider that has their own software tools. Neither should we be constraining ourselves to choose from providers with open source tools, nor should we be requiring that *all* features we ask to add to those tools be available as open source, or freely to the IETF, etc. Taking the step back -- the principle was that the IETF should retain the rights to, ability to access, and ability to move the data it creates.Period. Sensible ways of achieving that include (but are not limited to) working with open source tools and/or ensuring we retain ownership of any software that touches that data. Others include using reasonably accessible off the shelf software (one Excel program is much the same as the next...), or agreeing on data interchange formats. Let's not try to make the laundry list in this document. Leslie. Harald Tveit Alvestrand wrote: --On fredag, desember 03, 2004 10:19:23 +0100 Henrik Levkowetz [EMAIL PROTECTED] wrote: What about this text, (added to 2.2.6): As a matter of principle the IAOC and IAD should ensure that any contracts for IASA clearly designate that any software, databases, and websites developed should be available to the IETF with no restriction by the contractor. Software should be open source and data should be made available to the IETF in machine-readable format, also in cases where it may be inadvisable to make the data openly available. this works for me (my only problem is stylistic - it's somewhat long for a principle, so may fit better in the details sections, if a place can be found for it). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for Consensus: IETF Administrative Restructuring
Just to be clear: Brian E Carpenter wrote: 2. I would like to see us stick as closely as possible to the letter and spirit of RFC 2026, even if we don't have process rules that cover exactly what we are doing. Specifically, I'd like to see normal usage of the I-D mechanism for developing successive versions of the necessary documents. I don't consider a web site that I have to remember to look at to be a satisfactory alternative. You I are in agreement. WRT the plan document: it is an open statement of what we (minimally IAB IETF Chairs, more generally IAB/IESG) believe is the sequence of steps necessary to get from here to there (where there cannot be finalized until there is a BCP document that has been through public discussion, revision and has been approved). As such (an open statement), I don't believe I-D is the appropriate form. That said, if there are portions that the community needs to review and approved, they can be pulled out and published as a regularly updated I-D (and even published as an RFC, if that is a useful part of our documentation path). Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Updated adminrest plan document
In further review of the draft administrative restructuring plan that was originally put together as part of the scenario O proposal sent to this list, and subsequently republished as its own Internet-Draft last week, a couple of significant issues have been brought to light. 1/ It wasn't clear that the plan should be an Internet-Draft -- it's not going to ever be an RFC, and it will probably need to get updated more frequently and often than is reasonable for I-D publication. So, it has been posted and will be maintained publicly at http://www.alvestrand.no/ietf/adminrest and Harald and I will undertake to update this mailing list when there are significant issues that impact the plan/cause it to be updated.There will be one more version published as an I-D -- the -01 version has been updated per the notes in 2/, and will include a note that further revisions will be found at that URL. (draft-wasserman-adminrest-plan-01.txt, just submitted). 2/ It has become clearer that there are issues with viewing the interim group as an interim IAOC. In the -01 version, it is renamed to be a transition team, for the following reasons: . The tasking of the group is different than that of the eventual IAOC -- it includes some activities that will be in the province of the eventual IAD, and at the same time this group has not got the decision power that the IAOC will have. . We don't actually know what the final composition of the IAOC will be, or what the process for putting people on it will be, because the BCP I-D that defines that was just published and we are beginning the serious public discussion. Therefore, it seems presumptive to name people (now) for the eventual IAOC. . The requirement that this team get set up quickly, and the desire to have openness and deliberation in the process of picking people for a 2 year term on the IAOC, are at odds with each other. Consequently, the revised plan has the transition team in place until the IASA is established to the point of seating the first IAOC (presumed to be early next year), and then it is disbanded. Note that this does not preclude (IMO) picking the same people for the IAOC, if that's consistent with the structure and population process that is eventually approved. Also, it seems reasonable that the IAB Chair should be a fully-fledged member of the transition team. Note well that it's a VERY separate question as to whether the IAB Chair is a full member of the IOAC going forward. The current BCP says the IAB Chair is not. There was some discussion on the IETF list that the IAB Chair should be a full member. I believe the answer to that will be resolved in BCP discussion and eventual publication. Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
, but in rough consensus, running code, and an extremely open process. So we are trying to make decisions by counting votes in not-particularly-well-crafted polls. The IAB and IESG continue to appoint secret (i.e., not announced and minuted) committees to hold secret (i.e., not announced in advance to the community) meetings, despite promises in San Diego that this would stop. And I think you and others are arguing, with the very best of intentions, that leadership groups, who have not been selected using criteria that include qualifications needed to make these sorts of administrative/legal decisions, and who have never been authorized by the community to do so, should now go off and make precisely those decisions -- decisions that might include options with which the IETF community has no experience and which the experience of other bodies has proven very poor. Especially about the third issue, I see serious contradictions with what we claim to be our principles and with what distinguishes the IETF from the typical, goer-dominated, procedures are more important than content, standards body. I think that is far more serious than the outcome of these particular decisions. If we change things by giving up the no voting, no kings, rough _community_ consensus, and openness principles and start ignoring experience comparable to running code (or the lack thereof) in favor of ideological arguments, then the particular experiment that is the IETF itself is over, regardless of what particular decisions are made in this case and regardless of how long over takes to become obvious. I wish I were wrong, but I'm just out of energy for these particular windmills. john --On Sunday, 03 October, 2004 15:54 +0200 Eliot Lear [EMAIL PROTECTED] wrote: John, I agree with you that there is reason to be concerned about a group of technical people who are not lawyers having to make decisions about the organization. However, I don't see delay at this point in time assisting our cause. In fact, the general membership of the IETF (whatever that means) has very few lawyers, and probably very few MBAs. One would have to wait a LONG time for community consensus. As it is I question the validity of the poll answers simply based on the qualifications of the respondents to answer. Rather I hope that the considerably smaller group has been consulting subject matter experts on the best ways to go forward. As I responded to Margaret, if you want me to lawyer up, fine but that costs time and quite frankly which one of 0 or M (or any other) gets chosen doesn't seem worth waiting. That a decision gets made by people we in fact empowered through the NOMCOM process (the IAB IESG) seems to me more important. If you do not like the decision you have every right to make your displeasure known to the NOMCOM. And If the [Ll]eadership of this organization screws up badly enough, the Internet Community *WILL* route around the damage. It's happened before. That's how W3C came to be. Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Upcoming: further thoughts on where from here
Folks, 10 days ago, some members of the IAB and IESG started to review the IETF discussion on the adminrest subject, attempting to determine what recommendations to draw, or how to elicit more discussion to lead to being able to provide some recommendations for moving forward. It seemed like the 2 paths that were seriously under consideration by the community were: . establishing a separate corporate entity for the administrative function, with continued strong relations with and funding from ISOC (this is basically Scenario C from Carl's document, with some adjustments). . carrying the administrative function out within ISOC itself, as an activity that was formalized by IETF process and largely overseen by IETF-accountable appointees. This has aspects of Scenarios A and B from Carl's document, but differs in that it doesn't make any suggestion of change to the ISOC structure, while it attempts to define and encapsulate the IETF administrative activity. This is referred to as Scenario O, below. It seemed that the best way to stimulate further discussion on the IETF mailing list about these paths was to provide a more fleshed out view of how they each might be accomplished. Accordingly, some people volunteered to write down some text for each, drawing on and extending Carl's documents. The outcome of that writing exercise will be circulated here later today -- i.e., a note describing a possible implementation of Scenario C in more detail, and a separate note describing the derived scenario (dubbed Scenario O). One thing that is important to note about these notes is that there is a lot of commonality in their structure, and a number of places where the text could have been copied from one to the other. For example, both have some form of oversight board or committee. The details as written, however, *do* differ between the notes. This is because the contexts are slightly different for the 2 scenarios, and because the differences amount to details we can debate and fix if we pick one of these to move forward with. I.e., who is a voting member of the oversight group should not be a deciding factor in whether you think the revised Scenario C is better than Scenario O, or vice versa. The IAB and IESG have not discussed these extensively, but have helped to try and get better and clarified documentation of each of those Scenarios. The IESG and IAB are now reviewing them in detail. We are also following your discussions/comments very carefully, and based on that they will evaluate to try and come to a recommendation. So we are eagerly awaiting your thoughts and inputs on whether either of these seems to be a viable path or what further work needs to be done. Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Scenario O Re: Upcoming: further thoughts on where from here
Following up on my note from this morning... Leslie Daigle wrote: Accordingly, some people volunteered to write down some text for each, drawing on and extending Carl's documents. The outcome of that writing exercise will be circulated here later today -- i.e., a note describing a possible implementation of Scenario C in more detail, and a separate note describing the derived scenario (dubbed Scenario O). One thing that is important to note about these notes is that there is a lot of commonality in their structure, and a number of places where the text could have been copied from one to the other. For example, both have some form of oversight board or committee. The details as written, however, *do* differ between the notes. This is because the contexts are slightly different for the 2 scenarios, and because the differences amount to details we can debate and fix if we pick one of these to move forward with. I.e., who is a voting member of the oversight group should not be a deciding factor in whether you think the revised Scenario C is better than Scenario O, or vice versa. The IAB and IESG have not discussed these extensively, but have helped to try and get better and clarified documentation of each of those Scenarios. The IESG and IAB are now reviewing them in detail. We are also following your discussions/comments very carefully, and based on that they will evaluate to try and come to a recommendation. So we are eagerly awaiting your thoughts and inputs on whether either of these seems to be a viable path or what further work needs to be done. Here is some text describing a scenario derived from Carl's Scenarios A B. Not an Internet-Draft L. Daigle VeriSign M. Wasserman ThingMagic September 20, 2004 AdminRest Scenario O: An IETF-Directed Activity Housed Under the Internet Society (ISOC) Legal Umbrella Abstract This document defines an alternative proposal for the structure of the IETF's administrative support activity (IASA) -- an IETF-defined and directed activity that operates within the ISOC legal umbrella. It proposes the creation of an IETF Administrative Oversight Committee (IAOC) that is selected by and accountable to the IETF community. This committee would provide oversight for the IETF administrative support activity, which would be housed within the ISOC legal umbrella. In order to allow the community to properly evaluate this scenario, some draft BCP wording is included. Daigle Wasserman [Page 1] AdminRest Scenario OSeptember 2004 Table of Contents 1. Overview of Scenario O . . . . . . . . . . . . . . . . . . . . 3 2. Draft of Administrative Support BCP . . . . . . . . . . . . . 4 2.1 Definition of the IETF Administrative Support Activity (IASA) . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 Structure of the IASA . . . . . . . . . . . . . . . . 5 2.1.2 IAD Responsibilities . . . . . . . . . . . . . . . . . 6 2.1.3 IAOC Responsibilities . . . . . . . . . . . . . . . . 6 2.1.4 IASA Funding . . . . . . . . . . . . . . . . . . . . . 7 2.2 IAOC Membership, Selection and Accountability . . . . . . 7 2.3 IASA Budget Process . . . . . . . . . . . . . . . . . . . 9 2.4 Relationship of the IAOC to Existing IETF Leadership . . . 10 2.5 ISOC Responsibilities for IASA . . . . . . . . . . . . . . 10 3. Workplan for Formalizing the IETF Administrative Support Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Workplan Goals . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Workplan Overview . . . . . . . . . . . . . . . . . . . . 12 3.3 Approval by the IETF Community and ISOC . . . . . . . . . 13 3.4 Selecting IASA Leadership . . . . . . . . . . . . . . . . 13 3.5 Recruiting the IETF Administrative Director . . . . . . . 14 3.6 Establishing Agreement with Service Providers . . . . . . 14 3.7 Establishing a 2005 Operating Budget . . . . . . . . . . . 15 3.8 Proposed Schedule for IASA Transition . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 7.2 Informative References . . . . . . . . . . . . . . . . . . . 17 Authors
Impending publication: draft-iab-model-02.txt
The IAB is ready to ask the RFC-Editor to publish Writing Protocol Models draft-iab-model-02.txt as an Informational RFC. This document provides methodology for providing protocol models to aid in communicating the functioning and features of a proposed protocol separately from the detailed syntax of the protocol messaging itself. The IAB solicits comments by October 15, 2004. Please send comments to the IAB ([EMAIL PROTECTED]). The document can be found at http://www.ietf.org/internet-drafts/draft-iab-model-02.txt From the Abstract: The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not for reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol models that allow reviewers to quickly grasp the essence of a system. Leslie Daigle, For the IAB. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Options for IETF administrative restructuring
relations with ISOC. We can and should work that out and then document it so we all know what the relationship is. But... this is just my personal view. I hope it helps a constructive discussion. Bert ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
A different cut [was Re: Options for IETF administrative restructuring]
Here's my *personal* perspective on reviewing the scenarios Carl's laid out. By my reading, Scenario A says: an existing organization, ISOC, will bear the responsibility for the administrative support of the IETF, as an extension of its existing commitment to the IETF. Scenario B says: Scenario A is a good start, but the IETF community believes it should be more involved in the forces that shape its destiny. We (the engineering community) are willing and able to stand up and take part in the responsibilities that go along with those rights. So, Scenario B proposes mechanisms to allow the IETF community to be more fully involved in ISOC, on the assumption that the administrative activity is actually carried out there. The increased involvement over today is justified by the increased (financial and work) activity within ISOC that is specific to IETF administration. The document outlines some proposals for how that involvement might happen -- those would have to be refined and reviewed with ISOC, if this is the general *direction* the IETF community decided it wanted to go. Scenario C says: the IETF community is ready and willing to undertake the responsibilities as well as the rights for managing its administrative efforts, and further believes that it would be more appropriately managed at arm's length from the rest of ISOC's activities (including its role in the IETF standards process). Scenario D says: arm's length is not enough, the IETF financial reality should be a completely independent organization which fully undertakes to fund and support the IETF activity. The IETF community is now completely involved in (aka responsible for) ensuring all aspects of its continued and long term financial viability. Again -- that's my personal read on it. IMO, it would be helpful at this point to have some discussion about what level of involvement the IETF community feels it wants or needs at this juncture. Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Options for IETF administrative restructuring
John, We are in agreement that key strategic decisions have to be made with the informed consent of the community. Harald and I have made the commitment to put as much on the table as is possible to have a rational open discussion that should come before that consent phase. That's the commitment that brought this document out, and it will continue to surface material input if, as, and when it comes to light. With respect to this specific point: I note in particular that your first next step reads Have a public discussion on the IETF list on the options presented in the draft. I think that is exactly correct iff the community is reasonably assured that _all_ of the plausible options have been identified, and fairly described, in the draft. I hope and trust that is the case, but any To the best of my knowledge, the set of known scenario classes are described in the document. And I do expect that the public discussion will help to refine the scenarios that are presented, and determine whether there are other classes of scenarios that need to be considered. Although the scenarios are labelled A through D, this is not meant to be a multiple choice exam question :-) Leslie. John C Klensin wrote: Leslie and Harald, I would like to make one suggestion about this process. For suggestions about substance, I will, of course, wait for the final -00 version of the draft. This note is deliberately being sent before I have done so because I don't want my remarks to be biased by how I feel about its specific content. There was considerable confusion in San Diego, and earlier, induced by large numbers of sub-discussions, with different, sometimes designated, groups of people holding discussions and not having access to each other's comments. Harald responded to comments about this during the plenary by indicating that, once the draft was posted, everything would be public. So I would like to suggest that any discussions within or among the IAB and IESG, or subsets of them, or between them and other groups, take place on mailing lists whose archives are public and/or which can be subscribed to (even if only on a read-only basis) by interested members of the community. The key strategic decisions here (as distinct from the fine details) have to be made with the informed consent of the IETF community. To me, that implies that all of the options and their pros and cons have to be on the table: after the fact, there should not be even a suspicion that the choice was influenced by discussions of only a reduced set of options. I note in particular that your first next step reads Have a public discussion on the IETF list on the options presented in the draft. I think that is exactly correct iff the community is reasonably assured that _all_ of the plausible options have been identified, and fairly described, in the draft. I hope and trust that is the case, but any suspicions, engendered by private discussion, that some options have been excluded from discussion by excluding them from the draft, would be extremely harmful and should be avoided. As you said, we need to take the time to get this right. We also need to be sure that the community emerges from the process confident that all of the options have been fairly considered in the process of selecting the right one. thanks, john --On Thursday, August 26, 2004 11:16 AM -0400 Leslie Daigle [EMAIL PROTECTED] wrote: [This is a re-send of a message I sent last night; that message is ... Hello, IETF community. Attached is the document we promised you in San Diego - a report from our consultant, Carl Malamud, which lays out a series of options and recommendations for moving forward with the IETF administrative restructuring process, according to the recommendations laid out in RFC3716 (the Advisory Committee report). It has been submitted to the Internet Drafts repository and should be ... ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Options for IETF administrative restructuring
[This is a re-send of a message I sent last night; that message is caught in the list moderation queue because the attachment put it over the message size limit. It should appear on the list... sometime. The Internet-Draft may appear in the archive before then. In the meantime, there are rumours of some possible math errors, so it's quite possible an -01 version will appear very quickly :-) -- Leslie.] Hello, IETF community. Attached is the document we promised you in San Diego - a report from our consultant, Carl Malamud, which lays out a series of options and recommendations for moving forward with the IETF administrative restructuring process, according to the recommendations laid out in RFC3716 (the Advisory Committee report). It has been submitted to the Internet Drafts repository and should be showing up there shortly. Some important things to note: THIS IS NOT A DOCUMENT TO BE READ IN ISOLATION. Minimally, reviewing the Advisory Committee report (RFC3716) is necessary to understand the context of the proposals laid out in this draft. THIS IS NOT YET AN IETF DECISION. That will be taken later, based on your input and IETF rough consensus. THIS IS NOT THE IESG/IAB's RECOMMENDATION. Our recommendation will come later, based on your input and the evolution of our thinking. THIS IS NOT AN ISOC POSITION. The document describes potential relationships of the IETF administrative activity and ISOC. However, the document is written as a proposal for IETF discussion -- the ISOC Board has not been asked to formulate a position on supporting one or any of these proposals; we need to have that discussion as it becomes clearer what the IETF wants in its future. This IS, however, the culmination of many, many hours of information gathering and a near-infinite number of conversations by Carl Malamud, attempting to give the best basis on which the IETF could make a decision that he could within the timeframe given. We encourage all interested IETF participants to read the report most carefully, and give feedback on it - on the IETF list for public discussion, directly to Carl or the IETF and IAB chairs if you want to make off-list comments. FURTHER STEPS The next steps in this process depend on the community feedback and whether we can gauge a consensus of the IETF on this mailing list. What we think is reasonable so far is: - Have a public discussion on the IETF list on the options presented in the draft - By early September, the IESG and IAB will attempt to distill a set of recommendations that we think capture a reasonable consensus of the community, and publish this as an internet-draft, which will be revised over the next month, possibly several times, based on further discussions - By late September, we emit a Last Call on this set of recommendations, if we deem that we have a reasonable consensus for the proposals - By late October, if the IETF community still shows consensus, we will declare that we have a decision, and will start executing based on that decision. In order to be able to move rapidly when we go into the execution phase, we may initiate some activities of a fact-finding nature - such as investigating possible suppliers of services and candidates for the positions we envisage filling - before that, but irrevocable decisions will await IETF consensus. Please read the attachment - please comment - please THINK. While this in itself should not change the IETF standards process at all, support functions are important to the IETF. We need to take the time to get this one right. Leslie and Harald. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
AdminRest update and plans for next week's discussions
Greetings, As of this upcoming IETF, we will have been examining the issues of administrative restructuring for about a year. We are now reaching the point where we think we can draw some conclusions and propose some actions to the community - we are not quite there, but close. As we have noted earlier, we are still gathering input - as part of that input-gathering, Carl Malamud, our consultant, will be listening to people throughout the IETF meeting - he will have office hours in the Marina 1 room at the hotel from 8am to 10am Mon-Thu, so that it is easy for you to find him. He is also accessible by e-mail ([EMAIL PROTECTED]). At this stage, a recap of the history seems in order. A historical perspective One year ago, the IAB chair and the IETF chair convened an IAB Advisory Committee that reviewed the administrative situation of the IETF. This committee gave its conclusions at the Minneapolis plenary that Fall, and published its findings in the form of a report (RFC3716). A key element of the committee's advice was that the IETF needs to get its overall administrative house in order to ensure continued and appropriate support of its technical activities. We have pursued that goal ever since. Four months ago, at the Seoul IETF, we presented a framework that we saw as a reasonable basis for moving forward: proposing the creation of a new organizational entity (which may be a new organization, or a new piece of ISOC) to coordinate and support the administrative activities that support the IETF effort. This entity would need to be clearly responsive to the needs of the IETF community, and responsible to that same community. The entity would not, however, affect the existing IETF technical processes, as described in RFC2026 and related documents. Any issues with those processes are, and will continue to be, discussed in IETF open fora. As we continued to develop the framework and study its implications, it became obvious that this required a level of expertise and work effort beyond what the IETF leadership had available - we needed to hire help. ISOC, at their May meeting in Barcelona, agreed to fund a hired consultant to assist in the work, and after a short and intensive search for candidates, we hired Carl Malamud to help us with the effort on June 21. Carl has been working on the information we have brought together, talked to many people and, drawing on his own expertise as well as other legal and financial advice, has started putting together concrete proposals for creating such an entity that would be suitably scoped, responsible to the IETF community and appropriately structured to carry out its mandate. You can talk to him at the IETF, and he'll give a short status report at the Thursday night plenary. Harald and I will give more details with respect to any proposed IETF decisions or actions at that time as well. Key points of the proposal -- The full report will be coming out after the IETF meeting week (i.e., after the IETF leadership has had time to review the material, and more listening has been done). By way of preview, we can say Carl has made more specific the vision painted in RFC 3716 of a single administrative organization that will collect meeting fees, administer ISOC funds and any other donations or revenues as appropriate. The organization would disburse these funds to the supporting organizations under contract, and be responsible for changing those contracts to reflect the evolving needs of the IETF when needed. The financial structure of this organization would have to be transparent to the IETF community as a whole, and the management would have to be clearly responsible to the IETF community. RFC3716 also outlined a number of ways in which the current working environment for WG chairs, participants and document editors could be improved. Carl's current material focuses on estabishing the administrative entity from which such activities could be launched, but he has not yet done anything to describe specific work items that should be launched here. Future work will be coordinated with the newly-starting TOOLS team which is working under the guidance of the IESG. Today's situation, and plans for this week -- We know that we are not finished. We still are looking for more input from the community (including next week's plenary meeting), we are working through a list of issues as identified by the IETF leadership and ISOC, and we have to make sure (as far as we are able to) the whole plan is possible to execute. As we go through that, the plans and proposals are likely to change and evolve. What we do today will influence the shape of the IETF support structures for many years to come; we need to respond to the urgency outlined in RFC3716, and yet we owe it to ourselves to not be over-hasty. The IESG and IAB will be meeting Sunday to discuss the
July update on AdminRest activities
The past month of administrative restructuring work has featured more data gathering on the part of our consultant, Carl Malamud. We expect the data gathering to result in an evaluation of option and a recommendation for action, which will be presented in the Thursday plenary at the IETF for the community's feedback, and released as an Internet-Draft shortly after the IETF. Naturally, given the timing, this is not a final action plan - we are still seeking the advice and consent of the IETF community. But we expect the plan to contain significant actions to be taken between the San Diego IETF and the next meeting, so this is an important time to gather community input in a face-to-face manner. In particular, Carl will be in San Diego and and making himself available to folks who'd like to provide some input. To facilitate that, we will be defying Heisenberg and identifying a fixed point time for Carl's location for 8am-10am on Monday - Thursday of the IETF week. Stay tuned, and/or check the notice board, for the location on site. Leslie. - --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: setting up the administrative structures we need
Dave, No, you haven't missed it -- first step in setting up anything is making a (detailed) plan. Leslie. Dave Crocker wrote: Harald, HA 2) However, responding to the point asked - what is being hired now is a consultant to HA help with the activity of setting up the administrative structures we need for the IETF at HA this point in time. Not the permanent general manager of the IETF administrative support HA function. This means that you are proceeding with the changes. Forgive my inattention, but where is a copy of the specific plan that was reviewed and approved by the IETF for these structural changes, and when did the IETF approve it? A separate question: To what extent is this effort taking already-scarce IETF resources and serving as a distraction from making the IETF produce better material in a more timely fashion? Clarifications would be appreciated. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253, fax:+1.866.358.5301 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Update on AdminRest activities
Since the Seoul plenary meetings, Harald and I have been working on our take-away action items. We had the opportunity to talk with the ISOC Board in mid-May. We reviewed briefly the trajectory set in motion from the AdvComm document, and outlined the framework that we presented in plenary in Seoul (the AdminRest framework, draft-daigle-adminrest). Following up on our statements in Seoul, we asked for support to address some of the cross-organization and specific organization tasks for current operational needs, and to support the task of exploring the AdminRest framework to the extent of producing more of a concrete proposal. I'm happy to report that the ISOC BoT was indeed very supportive of this effort. The specifics (i.e., ISOC Board resolution) will be published as part of the ISOC Board meeting minutes. The highlights of that support include the allocation of an ISOC budget sum, not to exceed $250,000, to be spent over a six month period for personnel, incidental expenses, and legal and accounting fees to hire and manage a consultant who will complete the analysis started in RFC 3716 and make recommendations regarding the organizational requirements and potential organizational models of the IETF. The first step, clearly, is to find and hire the appropriate person. We have a few people in mind to talk to, but as we can always use pointers to people we may not have thought of, here's an outline of the characteristics and expectations we're using as guidelines: This is a support function is not intended as a policy-making role, but intended to execute and clarify the policy set forth by the IETF leadership, reporting to the ISOC president (as an ISOC project). Essentially, we are looking for someone we can work with; the kinds of deliverables and requiremed skills are as outlined below. Deliverables for the project will include: Data Flow: a set of requirements for implementing appropriate tracking of IETF documents and reporting of status across the support organizations. RFC Editor contract: a negotiated contract that is agreeable to all concerned parties. Administrative restructuring: documentation and support as appropriate to the continued evolution of the restructuring effort, which is continuously reviewed by the IAB, IESG and the rest of the IETF community. Types of activities/tasks this will include: - Assist in drafting the proposed structure/bylaws for the IETF administrative entity - Revising proposed structure/bylaws based on the public review, including reviews by competent counsel - Negotiate the contracts for RFC Editor as a model for eventual use by the IETF administrative entity - Interacting with the RFC Editor, IANA and Secretariat to determine the requirements for inter-organizational document flow matched to overall IETF process needs So from this, we have the required skill set: - understanding inter-organizational relationships and document flows - ability in contract negotiation - insight into organization formalization - experience with the creation of organizations (preferably nonprofits) - understanding of the legal aspects of such an organization - understanding of the financial aspects of such an organization (all of this with the understanding that specific other expertise, e.g., financial and legal advice, can be brought in on an as-needed basis). We hope to identify a suitable candidate in the upcoming weeks. Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Feb04: Update on administration restructuring
This month's update is primarily a reference -- to 3 documents published 2 weeks ago (listed below). Note that the 2nd of these 3 documents addresses the question I outlined in my January update: One substantive point of discussion that has come up more than once is: why does changing the administration structure of the IETF help deal with the budgetary issues that have been outlined? These 3 documents form the basis for the Administration Restructuring section of the Thursday evening plenary in Seoul. We expect to have plenty of open discussion during that session -- for those who are in the room, and those who care to attend via jabber. And, as with any Internet-Draft, comments on the text to the authors are always welcome. Leslie. --- 3 new documents --- 1/ http://www.ietf.org/internet-drafts/draft-alvestrand-ietf-mission-00.txt A mission statement for the IETF, Harald Alvestrand This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. The appendix giving the debate is intended to be deleted when the RFC is published; it is only given here as a reference and a thank-you note. 2/ http://www.ietf.org/internet-drafts/draft-alvestrand-adminrest-motivation-00.txt IETF Administration Restructuring: Motivation, Harald Alvestrand, Leslie Daigle This document follows up the observations and recommendations outlined in the IAB Advisory Committee report ([1]) with a statement of purpose for the administration restructuring proposed in [3]. A high level definition of the IETF's purpose can be found in [2]. All 4 documents are meant to be read collectively. 3/ http://www.ietf.org/internet-drafts/draft-daigle-adminrest-00.txt A Proposal for IETF Administrative Restructuring, Leslie Daigle, Harald Alvestrand This document outlines a proposal for an administrative oversight entity for the collection of activities that allow the IETF to carry out its work. The current description of the IETF's work can be found in [2]. The proposal is based on the observations and recommendations outlined in the IAB Advisory Committee report ([1]). The motivation for this proposal is described separately ([3]). These 4 documents must be read together for completeness. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Re: The IETF Mission [Re: Summary status of change efforts - Updated Web page]
I'd like to come back to this point, and try a slightly different direction: Fred Baker wrote: The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet. I think I would state it in these words: The Internet Engineering Task Force provides a forum for the discussion and development of white papers and specifications for the engineering issues of the Internet. This seems like a reasonable characterization of the output of the IETF. However, it doesn't seem to capture some of the scoping/delimiting that the original text did -- does the IETF discuss any and all such issues? Is it trying to achieve anything in particular by documenting things? (How) can we detect that there are issues we should be discussing and can't? (How) would you add to your text to provide some boundaries/ guiding lines? Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Jan04: Update on administration restructuring
Consistent with my December update, there have not been many further comments on the IAB Advisory Committee report. The IAB has requested that the RFC-Editor publish the document (draft-iab-advcomm-01.txt). One substantive point of discussion that has come up more than once is: why does changing the administration structure of the IETF help deal with the budgetary issues that have been outlined? Changing structure doesn't make those problems go away, of course. The entire thrust of the proposed restructuring, we believe, is that more coordination of the different IETF activities (in terms of their administration and budgeting) is a necessary first step to giving us, the contributing community, the tools necessary to address the pressing financial questions. We expect to have an Internet-Draft outlining more concrete proposals (and addressing that question in more detail) published by the -00 cutoff deadline for IETF59 (February 9). Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Dec03: Update on administration restructuring
In following up the discussion of the IAB Advisory Committee output, on December 1: http://www.ietf.org/mail-archive/ietf-announce/Current/msg27463.html I noted that I would endeavour to post monthly updates on progress, around mid-month. It's only been 2 weeks, but I thought it was important to get the update process rolling. There have been a few comments on the AdvComm document itself, draft-iab-advcomm-00.txt, but it seems largely ready to consider finished. We're going through it to check for final consistency and editorial fixes, with a view to having a new version out shortly. In terms of follow-on, Harald and I have started to have more formative discussions -- we've met with folks from ISOC and from CNRI to begin the discussions of what we might do, moving forward, to address the concerns laid out in the AdvComm document. There's nothing conclusive to report there, yet. Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
IAB open discussion topic at Thursday's Plenary of IETF58
This is what the IAB is intending as an open discussion topic at Thursday's plenary (total topic time is something like 45 min). As noted below -- it's expected to be an interactive session, so please come prepared to offer considered input! Leslie. Open Architecture Discussion Topic: Are Insecurities at the Edge the Biggest Challenge Yet to the End-to-End Model of the Internet? When we think of DDOS and Internet-propagated virii, we typically focus on the bad behaviour of the instigator. And, as recent years have seen a massive increase in the amount of malicious and/or unsolicited traffic on the Internet -- denial of service attacks, worms, virii, spam -- we are painfully aware of the costs. Not only end-users are impacted, in the case of spam: anyone setting up mail service has to provision it to handle the amount of traffic it will get, not just the amount of legitimate traffic. Looking at the rate of increase of these attacks -- e.g., the spike in spam after the SoBig virus was detected -- it seems that the viral nature of propagation has its own set of implications: not only must we deploy countermeasures within the network to avoid the flattening of endpoints under attack, it is increasingly obvious that endpoints as we know them cannot be trusted. If endpoints cannot be trusted, then the proposed longer term solutions for spam that are based on authenticating senders via credentials will not succeed as the only solution. Imagine if you will a situation where if present trends continue we might project seeing things such as the following: a. Continuous DDOS attacks against the Internet infrastructure. b. Releases of multiple CERT advisories *every day* c. Virus traffic + spam + patches + file sharing traffic comprising the overwhelming fraction of total Internet bandwidth d. Organizations restricting or actually *decommissioning* use of email. The combination of all these trends makes the threat to the end-to-end model from NAT or filtering look fairly minor. This discussion will include brief presentations outlining some metrics used to determine the trendlines and attempt to determine the current scope of the problem and the slope of the trend line. The important points for further discussion are: 1/ what are some of the additional implications, in terms of work the IETF could and should be doing? 2/ since the data shows that a substantial amount of malicious traffic (worms, ddos, virus propagation) is virally generated and operating with the full rights and priviledges of some real user, to what extent is conventional authentication authorization technology useful? This is meant to be an interactive discussion amongst all the engineers and architects in the plenary; please come prepared to share thoughts and pointers. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Re: Lawful interception
Howdy, I don't know if it constitutes something happening in the area, but we're trying to firm up plans for Fred Baker to say some words about it at the IAB plenary on Wednesday evening. Leslie. Iljitsch van Beijnum wrote: With regard to draft-baker-slem-architecture-01.txt and the surrounding issues: is anything happening in this area in Vienna?
Re: [UM] RE: WG Review: Enhancements to Internet email to supportdiverse service environments (lemonade)
Howdy, Dave Crocker wrote: I gather that the IAB is frankly dictating the current wording of the opening paragraph. I don't know how you gathered this, but you'll be relieved to know it isn't true. There were concerns raised within the IAB and IESG with the original phrasing of the charter, and the current text was proposed as a revision back to the IAB and IESG as something that addressed the concerns. It did. Presumably other formulations would as well. Your AD has the challenge of reconciling concerns and revisions (in both directions). Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Re: Appeal against IESG decision
a recommendation to the IESG, that the IPv6 Working Group expeditiously revise RFC-2461 to: - specifically note that it is not valid to configure an IPv6 router such that the 'autonomous configuration' bit is set to TRUE AND the advertised IPv6 prefix length exceeds 64 bits AND the advertised IPv6 prefix does not start with binary 000, and also expeditiously revise RFC-2462 to: - specifically require that a host ignore a Prefix Advertisement Option when the first three bits of the advertised IPv6 prefix do not start with binary 000 AND the advertised IPv6 prefix-length exceeds 64-bits. Leslie Daigle, for the IAB. Robert Elz wrote: This is an appeal to the IAB against the IESG decision to reject my appeal against their earlier decision to approve the publication of draft-ietf-ipngwg-addr-arch-v3-11.txt as a Draft Standard. The issues here are very simple, and no lengthy examination of mailing list archives, taking of evidence, hearing opinions, ... should be necessary in this case. I believe that none of the facts are in any kind of dispute. Those facts are 1) RFC2026 says, in section 4.1.2 ... A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the Draft Standard level. [...] The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. 2) draft-ietf-ipngwg-addr-arch-v3-11.txt contains at least one (and perhaps two) features for which there are not two interoperable implementations. The one is: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. There's no dispute that there are no interoperable implementations of this - there are no implementations of it at all (or no documented ones anyway). Note that the spec actually gives no option here, other than the exceptions (the 000 addresses, and multicast), interface IDs are required to be 64 bits long.While all implementations I'm aware of allow 64 bit IDs, none have been presented that require it. The draft *requires* it. Any reasonable reading of 2026 would require that that feature of the specification be removed from the draft before the draft is permitted to be published as a draft standard. Of course, as an alternative, the WG or IESG could have the draft, as it is, published as a Proposed Standard, and await the necessary two implementations of the feature before requesting advancement. The IESG's opinion of this seems to be that the two implementations of every feature applies only where they consider it important enough to bother checking. I have no problems with drafts advancing when no-one brings to the attention of the IESG that there is a problem in this area. But when a problem is pointed out, the clear words of 2026 really must be enforced. The rationale for this requirement in 2026 is simple (as the IESG should know, as the author of 2026 is a member of the IESG). First, it ensures that the text in the document is clear enough that it can be implemented in an interoperable way. And second, it helps make sure that the document doesn't get cluttered with requirements in practice no-one bothers to implement - that is, that the document is a proper specification, and anyone reading the document can implement from it, with the expectation that their implementation will interoperate with others. The quoted text from the draft fails both of those tests. We have no implementations so we don't know that the text is clear enough to be implemented correctly. It may seem obvious that the text is clear to any reader - but the IETF has always ignored seem obvious and required actual implementation experience as a demonstration. Second, an implementation which did faithfully follow the words of the draft would fail to interoperate correctly with every other known implementation of it. It may be claimed that it is the other implementations, or the way they are configured, that is at fault here, but that's not relevant - the aim is to get interoperability, and if we have operators configuring /112, /226, /227 and similar prefix lengths (that is, interface ID's that are 16, 2, or 1, and other, numbers of bits long) - and we do - then an implementation that enforced the 64 bit IID requirement (allowed only /64 prefix on an interface) would fail to interoperate with other implementations (with all other existing implementations). This seems
After 1 day... Re: text conferencing at the 55th IETF meeting inAtlanta
Let me say I really like the text conferencing experiment so far. It's pretty cool to get a chance to have an idea of what's going on in sessions you can't split yourself to attend. It'd be interesting to see more people attending the text conference; in other (non-IETF) meetings I've seen interaction (as opposed to watching the scribe; or, as helping the scribe). Might, or might not, scale well... Leslie. Patrik Fältström wrote: On tisdag, nov 19, 2002, at 03:37 Europe/Stockholm, Peter Saint-Andre wrote: Admittedly the Jabber clients for MacOS are sub-optimal. Hopefully that situation will be remedied in time for San Francisco. Problem resolved: (a) JabberFox works. I have no clue why it didn't the 50 times I tried earlier yesterday. Now it does. (b) TVJab is unable to connect to a chat room at a conference server which is not the same/known by the jabber server you connect to. I don't really know if this is a server configuration, or bug/lack of feature in the client. So, my recommendation: If you use MacOSX, JabberFox is what you should go with. THANKS to everyone which have sent me private email! paf -- --- An essential element of a successful journey is recognizing when you have arrived. -- ThinkingCat (c.1983 - 2002) Leslie Daigle [EMAIL PROTECTED] ---
Re: Splitting the IETF-Announce list?
I don't really care if they are split -- I can as easily re-join them in my inbox. But I do find the discussion has unearthed something that rather disturbs me... hyperfocus on drafts only in your own WG's strikes me as dangerous. A lot of stuff (even relevant stuff!) comes out as personal submissions (not announced in any WG). And, having a sense of what else is going on gives you a clue about what things not to reinvent/where to inject some clue. Personally, I find it hard to (find the motivation to) keep up with the IETF-discuss list, but I make a point of scanning all the announcements. If I'm that much in the minority, perhaps this explains why we've gotten divergent threads happening. We could help the IESG out a lot if we paid more attention, individually. And, a helped IESG is a happy IESG; a happy IESG means our WGs go more smoothly... IMO. Leslie. Pete Resnick wrote: Just some followups: Re filters: As Paul already joked, I obviously do use an e-mail client with filters. But of course the problem is that filters don't stop the intial problem, which is an awful lot of traffic through my poor little server. Even worse, when I am on the road and over a lowly 33.6K link, downloading the hundreds of I-D announcements just to filter them only serves to slow down the whole process. Re everyone should read the drafts anyway: WGs always get the announcements for the WG drafts, so I always read the one's for WGs with which I am involved. Other drafts can be dealt with by the occasional search. Those who really have lots of time on their hands can subscribe to the I-D announce list. Re announcing all documents separately: Since RFC's are not nearly as numerous, and I am interested to see what's been finalized and published in all areas, I wouldn't be in favor of that split. And again, this might significantly cut traffic out of the secretariat. Any other objections to such a move? pr -- Pete Resnick mailto:[EMAIL PROTECTED] QUALCOMM Incorporated -- --- An essential element of a successful journey is recognizing when you have arrived. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Re: Carrier Class Gateway
Please tell me this is some joke about STD=standard that I'm simply not getting... Leslie. Rahmat M. Samik-Ibrahim wrote: On Thu, 26 Apr 2001, Peter Deutsch wrote: Errr, actually carriers don't have 16 guns, the battleships did. There Arizona had (has?) 14 ones. At least, when I visited Pearl Harbor a couple of years ago Anyway, will this proposed protocol also apply to STD carries over V* cannal ? :-) regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - If ain't broke, ain't fix IT;but I'm broke, so IMFix IT! -- --- The best laid plans are written in pencil. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Re: Deja Vu
Lloyd Wood wrote: Don't call it that. It's officially the area known as 'sub-polar'. Lots of drafts if you leave the door open just a fraction too - they get everywhere. Certainly observed to be a feature of MPLS. (122 of them in the current draft repository...) Leslie. -- --- "The best laid plans are written in pencil." -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Re: Mobile Multimedia Messaging Service
Howdy, "James P. Salsman" wrote: Proposed special document status and process for MMMS specifications: Recognizing that it may be impossible to achieve consensus on topics in which large and diverse corporate concerns have vested interests opposed to open standards, the MMMS working group will have a special goal to produce Internet-Drafts which will identified as "Frozen MMMS RFC-track Internet-Drafts." These documents might never become RFCs I think this is a Bad Idea -- particularly in conjunction with: frozen documents. Developers may rely on such documents as static and vendors and customers will be encouraged to refer to them in their procurement process. These documents would become de facto standards (although they won't have had the standards-review) and they would break the paradigm of Internet-Drafts (which is "don't implement"). If you want to get public documentation on how things are done, it would be more suitable I think to go with traditional Informational RFCs -- and you can label them as "Informal understanding of how to do X", if you like. Leslie. -- --- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Re: Mobile Multimedia Messaging Service
Howdy, Yes, RESCAP should be doing this. (Too many people with full plates, not enough people poking -- so poke ;-) Leslie. Patrik Fältström wrote: At 08.12 -0400 00-09-16, vint cerf wrote: would it be useful, in the context of establishing peer-to-peer communications (or even client/server communications) with limited-function mobile devices, to use SIP as a framework for negotiating the parameters that should guide the nature of the exchange? Maybe. The rescap wg is looking into "capabilies" in a different way (I presume). I'm thinking, for instance, of a web server that may usefully discover the functional limits of a mobile before it starts to send content to that device. The mobile uses SIP to report to the server that it has X amount of memory, Y amount of display area, color or not, average data rate it can send or receive, and so on. This information would be used by the server to configure what it sends to be compatible with the receiving unit. perhaps this is an idea that is already being pursued in an IETF working group? I think "discovery" of capabilities is an interesting discussion, and of course it should be dealt with aswell. Some of this information can be handled by just looking att the tcp control block :-) Now, I would like, to be honest, this wg to more look at what stupid(?) design flaws have been made in the existing protocols given certain capabilities than the actual discovery process. IMAP in disconnected mode is a good idea, maybe, but might be too chatty. I.e. long rtt makes chatty protocols like IMAP and SMTP (just as some examples) quite boring. Can something be done about that (batch smtp?). Say we have a very fat pipe between earth and the moon (which current tcp should be able to handle). Should we run IMAP over that link which have quite some RTT? What happens if we have only a 2.4k inmarsat sattelite phone with 900ms rtt, can we still do useful stuff with normal applications given ppp (the solution is not to change ppp in this discussion)? paf -- --- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Re: recommendation against publication of draft-cerpa-necp-02.txt
Howdy, Stephen Kent wrote: Thus, if anyone is really concerned about know with whom they are communicating, and whether a packet was modified in transit, they should be using these standards security technologies. Many web sites for which these security concerns are significant already make use of SSL/TLS anyway. I think the point was that this will impact many more casual interactions, where one wouldn't necessarily think to have to employ authentication technologies. There are times when I and my ISP, or the ISPs it peers with, have different opinions about what is sufficiently recent/authentic (of a copy of a resource, or even of a final destination address). If unrelated entities in the chain each get to "assert an opinion" about what's "good enough", for their own purposes, it is not at all clear that I get the end-result that I deserve, or am even aware of the fact that things have been changed midstream. Leslie. -- --- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
Re: recommendation against publication of draft-cerpa-necp-02.txt
A fine argument in the abstract, but reality bites. Stephen Kent wrote: sent" in this era of the Internet. Security is not black and white, but the gray area we're discussing does bother me. If one cares about knowing where the data originated, and that it has not been altered, then one needs to make use of the tools provided to address that concern. if one doesn't use the tools, then one does not care very much, and the results may be surprising :-). Who is "one", in your mind? Mail, web, WAP client application writers? Or the poor end-user who gets the surprise without having a clue what hit him? As an end-user, I can be as aware as I like about the security issues, but if client software doesn't support security, and/or my ISP, services don't support it, there's nothing I can do. I am not saying that security isn't the answer -- but I do think you're looking at your chalkboard, not deployed reality, when you suggest it isn't a problem because there are technologies for authenticating packets. Leslie. -- --- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
